The Message Error (ME) bit is one of those interesting status bit settings that gives some reasonable information if you know when to go fetch it. Here is a short discussion about its usage.
The ME bit is all about the settings of the hardware decoder that are often done by the software application. In some platforms, the hardware will also set the RT address, but most of the other setup is performed by a software application.
The following two paragraphs from MIL-STD-1553 will help to understand how the ME bit is used and when the bit is set. The MIL-STD-1553 Reference Guide is available for download on the Abaco web site.
The Mil-Std-1553B definition
18.104.22.168.3.3 Message error bit. The status word bit at bit time nine shall be utilized to indicate that one or more of the data words associated with the preceding receive command word from the bus controller has failed to pass the RTs validity tests as specified in 22.214.171.124. This bit shall also be set under the conditions specified in 126.96.36.199, 188.8.131.52, and 184.108.40.206. A logic one shall indicate the presence of a message error, and a logic zero shall show its absence. All RTs shall implement the message error bit.
The MIL-HDBK-1553A Notice A status bit
The key to understanding the message error (ME) bit lies in 220.127.116.11. First, the command word must be valid and have the RTs assigned address. Then, if there is a data word validity problem or any words are not contiguous, the ME bit is set to a logic 1 in the status word, but the status word is not transmitted. The ME bit can be obtained by using either of the two-mode commands: transmit status or transmit the last command. The only time the ME bit is set, and the status word is transmitted in response to valid receive or transmit commands is per the illegal command detection response of 18.104.22.168.
The Bill Tilman interpretation
For everything in the 1553 world, it starts with the Bus Controller (BC) command word. If the Remote Terminal (RT) can decode the command word and the word belongs to that RT, then that RT MUST do something in response with that command word. All other RTs at this point should have also decoded the command word and found that it does not belong to them. The other RTs will do nothing and ignore this command word message.
If the command word decodes to the RTs address, then that RT must do something because it is addressed to itself. It will then use the rest of the command word to further decide if it is validated to a list of TRbit (TR) and SubAddress (SA) and Word Counts (WC) that are allowed for it to respond to. If the command is valid for that list of TR, SA, WC with a proper parity then it will respond accordingly with a clear status - normal operation.
The RT will have a list of Sub Addresses that are valid for it to put data in or for the BC to place data into. It further has a list of valid word counts that can be used to put or get data from its local memory, this is normal operation. Other Sub Addresses and word count combinations are considered "Illegal" to be used. If the command word uses any of these combinations that are "Illegalized" then the RT is not allowed to respond to that command with a status. It will not respond with status or data, but it will set an internally held register with its status word with the ME bit set. The BC will not see this status unless the next command to that RT is a Mode Code (MC) called Last Status. The Mil-Std-1553 requires the RT to then send that internal register called last status out to the BC. This status word will have that ME bit set, which indicates to the BC that there was something incorrect about the last command sent to that RT. The BC must have the smarts to look at the prior message and send it again or notify/log an error for future reference.
If indeed the BC is sending an "Illegalized Command"--a command to a known illegalized SA and WC combination--that is up to the BC design to fix before it is released. An “Illegalized Command” is one that has been set by the RT to not be allowed to be used by any device external to that RT. Think of this as a command that would provide only half of the data that must be contiguous with the rest of the data of that buffer to be properly or meaningfully used. If the system were to use this partial data, it would be using errant data. An example might be like only half of the latitude and longitude data for a point location. This information should be documented for that RT and therefore well-known not to use that command combination. This must be caught during development, as it is not useful during normal operation because of errant operation during in-flight glitches.
If it is a valid command, then the BC should retry the command and it should work as normal. It would likely be chalked up to EMI, Noise, or lightning. That kind of thing would happen only once. The valid commands would expect to have a clear status response.
If you enjoyed this blog, you will also enjoy:
Using MIL-STD-1553 to Add New Capabilities
Designing for MIL-STD-1553
Why do I have intermittent and unreliable MIL-STD-1553 message data?
Simplify MIL-STD-1553 troubleshooting with the BT3-USB-MON (VIDEO)
Abaco Announces Integrated MIL-STD-1553 Cyber Resiliency Solution
Mil-Std-1553 UCA Reference Manual
What Zero Trust Is and Why You Should Implement It