**Change description:**

The following changes were made to this document:

-   [Action Items are identified by being highlighted in yellow to make
    them easy to remove from the document.]{.mark}

-   [Examples and other things that will, hopefully, be moved to a users
    guide are highlighted in turquoise to make them easy to remove from
    the document.]{.mark}

As of 3-24-00 we have reached the following **tentative** conclusions:

-   [We are concluding that two fixed formats are required.]{.mark}

-   [We are agreeing on the need for both source and destination
    addresses (in the long header).]{.mark}

-   [TBIMs above Tier 0 will handle both packet sizes.]{.mark}

-   [We have agreed that there will be an 8-bit field in the format
    section that indicates the word (syllable) size of the data
    field.]{.mark}

-   [The error correction/detection of the data itself will be
    transparent to the TBC. The application software will learn from the
    TEDS of the TBIM how to decode the data itself.]{.mark}

-   [The format field will have sufficient CRC length to protect against
    undetected errors (probably 16 bits, may be 32)]{.mark}

-   [The standard will allow TBIM to TBIM communication, even though it
    has not been a priority. It will most likely utilize data channels
    (not TBIM communication channels) and its main purpose is to
    accommodate applications needing a tight loop between a sensor and
    an actuator such as in active noise cancellation.]{.mark}

-   [The default format will be the short format. The devices can be
    switched to the long format.]{.mark}

-   [The Bus Management Communications channel will only use the short
    format.]{.mark}

## Functional Elements

The functional elements portion of the standard gives the requirements
for the addressing schemes and the structure of the data frames that are
passed between the elements of the system.

### Introduction

This standard deals with data at the lowest levels of the protocol
stack. Figure 1 shows the three lowest layers of the protocol stack. In
the top layer in the figure the data is sampled and packaged in a format
that may or may not include error correction/detection and may or may
not include status bits along with the data (data interpretation layer
(presentation or application layer in some texts)). In the Data Link
layer these data words get packaged into a framed packet that includes
addresses, start and stop flags, etc. Then in the Physical layer the
frame may have one or more words added to accommodate the physical
media, such as spread-spectrum preambles and multiplication by the
spreading code (physical layer).

[The data and addressing schemes are divided into three categories or
layers.]{.mark}

[The data is sampled and packaged in a format that may or may not
include error correction/detection and may or may not include status
bits along with the data (data interpretation layer (presentation or
application layer in some texts)).]{.mark}

[These data words get packaged into a framed packet that includes
addresses, start and stop flags, etc. (data link layer).]{.mark}

[Finally, the frame packet may have one or more words added to
accommodate the physical media, such as spread-spectrum preambles and
multiplication by the spreading code (physical layer).]{.mark}

This section of the standard deals primarily with the packets at the
data link layer.

![](media/image1.wmf){width="2.1381944444444443in"
height="1.6381944444444445in"}

Figure 1 Truncated protocol stack

Currently, the data interpretation layer definition is wide open and
will be addressed in the T-block section of the standard. The following
paragraphs describe a possible format for the data link layer. The
physical layer format considerations are discussed in the CDMA/FDMA/TDMA
section. See ??

### Data Link Layer Frame Format

The frame format for the data link layer is composed of five fields as
follows:

-   The Start Frame/End Frame Flag field at the beginning of the frame.

-   The Format Field is the header ahead of the data.

-   The data field

-   The Frame Check Sequence field

-   The flag field at the end of the frame.

The Start Frame Flag and the End Frame Flag fields are the same as shown
in Figure 2. However, they will probably be different after the physical
layer is defined. The remaining fields are discussed in more detail in
the following paragraphs.

#### Data Link Layer Primary Frame Format

The primary frame format for the data link layer is composed of the four
fields as shown in Figure 2. The address field is the destination
address for transfers from the TBC to the TBIMs and the source address
for transfers from a TBIM to the TBC. Another way to look at this field
is to say that it always contains the TBIM address. The data count is a
single byte. This limits the Data Field to 255 bytes maximum. A Frame
Check Sequence is for the overall frame is not required.

![](media/image2.wmf){width="3.6868055555555554in"
height="1.7805555555555554in"}

Figure 2---Data Link Layer Primary Frame Format

This would provide 72 bits of overhead for all messages. This format
could be used for small systems. If we provide two alternatives like
this and the one in 1.1.2.2, the system will start out assuming the
primary frame format sequence and only change to the alternate format on
command.

#### Data Link Layer Alternate Frame Format

An alternate frame format for the data link layer is composed of the
same four fields as were required in 1.1.2.1 with the addition of the
Frame Check Sequence. However, the structure of the format field is
changed. The field would be fixed. The address fields would be fixed at
two bytes each, the command field would be fixed at two bytes, the
Sequence Number/message ID field would be one byte, and the data count
would be two bytes.

![](media/image3.wmf){width="5.947916666666667in"
height="1.9569444444444444in"}

Figure 3---Data Link Layer Alternate Frame Format

This would provide a 104-bit header for all messages exclusive of the
Frame Check Sequence. If we assume a sixteen-bit Frame Check Sequence it
becomes 120 bits of overhead for each message. This is not the most
efficient possible format but it probably is more than adequate for most
systems.

#### Choosing a Data Link Layer Frame Format

The consensus opinion at the moment seems to be that a format should be
available that contains both a source and destination address. The
primary reason for this is to be able to support deterministic systems.
Having both addresses present allows another level of checking on the
validity of the message by the receiving device before accepting the
message.

The next question seems to be should we use one or two fixed format
fields. The following discussion is based upon trying to use both of the
format fields proposed in 1.1.2.1 and 1.1.2.2. The added complexity of
having to deal with two fixed formats is not very high. Figure 4 shows a
possible hardware implementation if the decoding of the format field is
to be done in software. To accomplish the same thing using a system that
could handle two fixed formats the hardware of Figure 5 could be used.
The state machine would need to more complex but not very much. This
logic would convert the fields to exactly the same number of bytes
written into the FIFO regardless of the length of the format. Bytes that
were not used by the short format would be zero. This would have some
impact on the CRC calculation but the remainder of the software could
not tell the difference.

![](media/image4.wmf){width="4.950694444444444in"
height="1.9506944444444445in"}

Figure 4 Hardware for a software decoder

![](media/image5.wmf){width="4.950694444444444in"
height="2.0076388888888888in"}

Figure 5 Alternate hardware for a software decoder

Figure 6 and Figure 7 show similar diagrams for a purely hardware
decoder. The decoder of Figure 6 is designed to handle the alternate
frame format. The decoder of Figure 7 is designed to handle both. The
additional hardware required to use the two fixed formats is probably
less than fifty gates in an FPGA.

![](media/image6.wmf){width="4.316666666666666in"
height="4.316666666666666in"}

Figure 6 Hardware for a hardware decoder

![](media/image7.wmf){width="4.316666666666666in"
height="4.347916666666666in"}

Figure 7 Alternate hardware for a hardware decoder

### Start Frame/End Frame Flag Field

The flag field is a fixed pattern that is used to detect the beginning
of a transmission and to synchronize with the incoming data.

### Format Field

The Format Field is made up of six distinct fields. Only four of these
fields are required with the primary frame format.

#### Address Fields

The primary frame format uses a single address field. It is the
destination address for messages transmitted from the TBC to a TBIM or
TBIMs. It is the source address for messages transmitted from a TBIM to
the TBC.

##### Destination Address

This address is used to specify the particular device on the bus that
will receive this particular frame.

The destination address may be the address of a specific transducer or
it may be a group address. This raises the question, again, of how we
define a group address. If we want to follow the pattern set by 1451.2
and use an address of zero as the special case of a group address called
the global address that addresses all active devices, then it makes
sense to expand on that scheme. For sixteen bit addresses, all addresses
between 1 and 255 could be reserved for group addresses. An address of
zero would still be the global address. This means that transducer
specific addresses would begin at 256 and go up to 65,535. This works
well with the idea that the eight most significant bits define a TBIM
and the lower eight bits define a transducer but does not mandate that
arrangement.

Another approach to group addresses would be to define them by how they
are assigned. A special command would be defined that assigned a
transducer to a group. The transducer would then flag this as a group
address. A command that was received for a group address that was not
appropriate would be ignored. This has the advantage of not arbitrarily
limiting the number of addresses but it makes the address decoding more
complex.

For some commands a group destination address is not valid. Examples of
this would be a read command for a specific TEDS or change the gain of
an amplifier. This means that the TBIM and transducer need to be able to
distinguish between group and transducer specific addresses.

#### Source Address

This address is used to specify the device on the bus that is
transmitting this particular frame.

Reading data from groups of transducers within the same TBIM should be
possible. This would include things like reading a data word and its
associated time tag in the same frame. This makes it simpler to keep the
pair together. However, this raises the question of what to use for a
source address in this case.

Perhaps a better way to handle groups in this field is to specify
special commands that apply when a group is being addressed. This
command could be addressed to a particular transducer and it would have
one argument. The argument would be the group identifier. The reply
would contain the requested information for the group. The source
address for the reply would be the same as the destination address for
the command. This prevents a system from trying to read data from a
group that is spread across several TBIMs.

#### Command

This field contains the command to be executed. A frame that is intended
to transmit a command from the TBC to a transducer may or may not
contain a data field. The use of a data field in a command frame is a
function of the command. See 1.3 for more details.

#### Sequence Number/Message ID

This field has a dual purpose. In some cases it is a sequence number for
frames that must be received in a particular sequence. This is important
when transmitting large blocks of data such as TEDS. In other cases this
field would be used as a message ID. This is important when ??.

[Sequence number/message id field needs more thought. Should it be one
field or two?]{.mark}

#### Data Count

This field identifies the total number of data syllables that will be
found in the Data Field.

#### Format Check Sequence

[This area is still being worked. The first analysis allowed for burst
errors but not random errors.]{.mark}

This is a required field. The standard CRC polynomial to generate the
CRC for the Format Check Sequence field is as follows:

> X^16^+X^15^+X^2^+1.

It can detect following errors:

\- All burst errors of length \<= 16

\- All burst errors affecting an odd number of bits

\- Burst errors of length 17 bits with high probability

\- Burst errors of length \>17 bits with good probability (2x10^-10^)

The receiving device shall ignore any transmission with an incorrect
CRC.

### Data Field

The number of data syllables in this field shall be as specified in
1.1.4.5. All syllables must be the same length.

There are some questions that need to be answered with this field
particularly in the area of peer-to-peer communications. The most likely
area for peer-to-peer communications, at least from my knothole, is for
streaming sensors to talk to streaming actuators. For these cases the
receiver need a way to interpret the data field. If the data field
contains a single sample of a single variable then this is relatively
simple but if multiple words from the same or different sensors are in
the packet it becomes a more serious task. For data sent to the TBC we
have been ignoring this saying that it will be handled by a higher level
in the protocol but with peer-to-peer communications it doesn\'t seem
possible to pass it off that lightly. In addition we need to provide
some method of defining the format of the data field to the TBIM that
will need to transmit it. I do not believe that it should be \"hard
coded\" into the TBIM. Even if it were built into the TBIM we would
still have the same problem in reverse. How do we define it to the
system?

A method that has been in use with telemetry systems is to define for
each parameter in the data frame an initial position in the frame and an
increment. The initial position in the data frame is just the syllable
number of the first occurrence of the parameter in the frame. The
increment is the number of syllables between any two appearances of the
word. For example assume that we have video data in a frame with 10 bit
syllables and one syllable per word. Further let us assume that there is
a scan line number at the beginning of the frame and that it occupies
two syllables. The initial position for the scan line number would be
zero and the increment would also be zero since it only appears once in
the frame. The initial position for the first word of the video data
would be two since it starts after the scan line number word and the
increment would be one. Using an increment of one means that it is in
all other syllables in the data frame. For a second example lets assume
a TBIM that wants to transmit a data set that consists of a CRC an
initial sample time and then ten samples of pressure interleaved with
tens samples of temperature in a data frame with eight bit syllables. In
this example we see some of the limitations of the technique. The CRC
and the initial sample time only occur once in the data frame so they
must be the first two words in the data frame. So lets put the sixteen
bits of CRC first followed by the initial sample time that is an 18-bit
word. Following this we put the 32 bits of the first pressure word
followed by the eight bits of the temperature. Now the initial position
for the CRC would be zero and the increment would also be zero. The
initial position for the time interval would be two and the increment
would be zero. Then the initial position for the first pressure sample
would be five since the CRC used positions zero and one and the time
interval used positions two, three and four. The increment for the
pressure would be five since the pressure requires four syllables and
the temperature requires one. The initial position for the temperature
would be nine and the increment would be the same as the increment for
pressure.

### Frame Check Sequence

[We still need to determine if this field is required or not and what it
is.]{.mark}

### Default Capabilities of a TBIM

Unless we adopt the alternate approaches to the frame structure we will
need to define the default characteristics for a TBIM.

The default settings for a TBIM shall be those required for a TBC to set
up the device. They shall be as shown in Table 1 and Table 2. This
results in an Address Format Field containing the bit pattern 0000 0000
0000 1000 (binary) for TBIM replies to the TBC. For commands from the
TBC to the TBIM the bit pattern is 0000 0000 0010 0010.

Table 1 Default Address Format Field for TBIM Replies to commands

  ----------------- --------- -----------------------------------------------
  Address Format    Bit       Comments
  Field             Pattern   

  Destination       00        At this stage the TBIM can only communicate
  Address                     with the TBC so the destination address is not
                              required.

  Source Address    10        This is an arbitrary choice so I picked two
                              bytes. It is easy to change.

  Command Size      00        The TBIM is not issuing commands to the TBC.

  Sequence          0         Initially this field should be set to zero to
  Number/Message ID           indicate that no Sequence Number or Message ID
                              is required.

  Data Count        0         The default shall be an eight-bit data size
                              field.
  ----------------- --------- -----------------------------------------------

Table 2 Default Address Format Field for TBC commands

  ----------------- --------- -----------------------------------------------
  Address Format    Bit       Comments
  Field             Pattern   

  Destination       10        This is an arbitrary choice so I picked two
  Address                     bytes. It is easy to change.

  Source Address    00        At this stage the only the TBC communicates
                              with the TBIMs so the source address is not
                              required.

  Command Size      10        The TBC is issuing commands to the TBIM.

  Sequence          0         Initially this field should be set to zero to
  Number/Message ID           indicate that no Sequence Number or Message ID
                              is required.

  Data Count        0         The default shall be an eight-bit data size
                              field.
  ----------------- --------- -----------------------------------------------

[All TBIMs will have a default mode with predefined values for the
address format. They will also have a minimum set of capabilities that
will most likely include some variations on the default settings. For
example, the default settings might be: 1) 8-bit words, 2) 1-word source
address, 3) 2-word destination address, 4) No sequence number word, 5)
1-word command field, 6) no frame checking. The minimum capability set
might include the default settings plus the options of frame checking
and sequence numbering.]{.mark}

[Higher end TBIMs might include word size options and the other options
mentioned above. The chosen TBC must be compatible with the desired
functionality of the system.]{.mark}

### Minimum Capabilities of a TBIM

I couldn\'t remember why this paragraph was in here so I deleted it.

## Triggering

text

## Control

text

## Status

text

## Interrupts

text

## Hot Swap

text

## Channel Identification

text

## Channel Groupings

text

# Data Formats

text

## Control Words

text

# TEDS

text

# Physical Specifications

Text