Friday, October 28, 2011

Mil Std 1553

I've been playing with a Mil Std 1553 bus for several weeks now, and I wanted to record what I've learned here.

1553 is a shared bus consisting of a Bus Controller (BC) and one or more Remote Terminal (RT). It is possible to go into "dynamic mode" where any device can act as a BC, but that is not how it is usually used. Instead, the BC normally knows everything about the systems- each RT, which messages they want to send, when and how often they can send what messages, etc. The BC is the only one that is allowed to use the bus- it polls the RTs for specific messages and the RTs must respond then and only then. It is possible for two RTs to talk if allowed by the devices themselves, but even then the BC asks one to talk to the other- they never start talking by themselves.

The polling that the BC does either tells an RT to send or receive a data message of a maximum of 32 words (with a word as 2 bytes). This poll is called a command message which consists of 20 bits of data, with 3 sync in the beginning, 16 bits of data, and an odd parity bit at the end. The data section contains a 5 bit RT address, where 0 and 31 are reserved as the broadcast address (although you can play with that a little), a bit indicating whether to send data or receive it, a 5 bit subaddress (which I'll get into in a minute), and 5 bits indicating the length of the message (where 0 indicates a message of length 32, so no 0 length messages are possible).

The subaddress is what tells the RT what type of message to send. We might even have 32 buffers of 32 words on the RT, where it just sends out the data in the 32 word section when it is requested. In practice its a lot more complex, but conceptually the subaddress is just an index into an array of 32 word messages structures. If the subaddress is given as 31 then it is not a request for data, but a mode-code. For mode codes, the 5 length bits indicate which mode messages is being sent rather then the length of a data transfer. Some mode messages will send out a single word of data, but that is simple specified in the standard, and must be known beforehand as it is not containing in the message itself except implicitly in the meaning of the code given. The mode codes are mostly for checking status, setting options, etc. The only one I've actually made use of is mode code 17, sync with data. This can be used periodically by the BC to keep the RTs in sync with it and to tell them a single word of data. It might, for example, be polling in a predetermined fashion, and the sync word might tell the RTs where it is in its schedule of message polls.

32 words of data is not enough to transport most messages. To extend the size of a message one can place it in multiple subaddresses and poll each one in turn, or poll the same subaddress multiple times and concatenate the results. The only problem with polling the same subaddress is that the RT or BC must be able to handle the rate at which it is requested, which can be fairly fast. A hardware mechanism for handling this is the easiest to deal with.

It is common for the BC to have a schedule giving a certain time slot to each message (1 ms for example) and always doing the same schedule each time period (1 second, for example). This schedule can change to only poll for messages that are needed, or to account for period messages like an occasional file transfer. Again, hardware support is important here, as the timing may have to be very accurate.

I think thats all I will say about Military Standard 1553 for now.

No comments:

Post a Comment