Why do I have intermittent and unreliable MIL-STD-1553 message data?

This is often due to improper cable termination. The following is an explanation of correct cable termination and coupling.

The 1553 spec (MIL-STD-1553B, para. 4.5.1.4 "Cable termination") states that "The two ends of the cable shall be terminated with a resistance, equal to the selected cable nominal characteristic impedance (Zo) +-2.0 percent.". A 1553 bus consists of a length of cable, terminated at both ends with a resistance. Connections to the bus are made using either direct- or transformer-coupling. These couplings provide a "stub" which connects to the Remote Terminal, Bus Controller, or Bus Monitor. Only one device should be connected to a single stub... multiple devices require multiple stubs, for example:

Termination         1553 Bus Cable             Termination
Resistance ----------------------------------- Resistance
            |                |            |
         Coupler          Coupler      Coupler
            |                |            |
            |                |            |      (Stubs)
            |                |            |
        Device 1          Device 2      Device 3 

People often use transformer coupling, since direct coupled stubs should be less than 1 foot long (para. 4.5.1.5.2), while transformer coupled stubs can be up to 20 feet.

Although the 1553 bus is robust (and often operates correctly in the face of massive mis-connections), very strange errors can result from incorrect coupling or termination of the bus. Many 1553 encoders/decoders (including Condor's) rely on the fact that the bus is "dead" between the command from the BC and the response from the RT (4-12 microseconds) for correct operation. This dead time is what tells the decoder that the BC has stopped transmitting, and has not gotten into a fault condition like transmitting too many bits.

If there is ringing on the bus (caused by improper termination) a bus monitor has no way to determine when a command completes and the response starts, especially since a command word and a status word have exactly the same format on the bus. The only difference between a command word and a status word on the bus is that a status word is transmitted in response to a command word, e.g., the difference is in the timing. Ringing prevents a bus monitor from determining that timing difference, and un-explainable errors are reported. One common response is to associate the RT status response with the command word from the BC, thus reporting both a bad command word and no response from the RT.

If such responses are detected, you should check for an un-terminated bus.

The real problem is that the BC and the RT might be "happy" on an improper bus. A BC or a RT which is not designed to catch and report bus errors might ignore the ringing, since, for example, the BC already knows when the RT is supposed to respond, and is often "dead" during the ringing interval. Also, depending on the coupling setup, the ringing might have enough amplitude to trigger the Bus Monitor, but not enough amplitude to trigger the BC or RT (depending on where everything is physically located on the bus).