Print Friendly, PDF & Email

Standards: MIL-STD-1553 FAQs

Q. Can two RTs communicate even though the BC is not available? eg. Initially a BC to RT and RT-RT communication was there between the systems. In case a BC equipment failed and RTs are still live, can they communicate in between (RT-RT)?


No, the BC must initiate all communication.

Q. Can two RTs can be configured on the same channel?


Yes, on one device you can configure two RTs, each of which has its own RT address.

Q. Can we have two RT units with the same RT address, providing that only one of the RT will be powered at a given time?


Yes, you can have two units with the same RT address provided one is powered off.  The standard states that all RTs on the bus must have unique RT addresses.  So, these RTs must never be on the bus at the same time.

Q. We are developing a MIL-STD-1553 remote terminal application and would like to ask an expert if a validation test plan and production test plan are mandated by the mil standard to demonstrate compliance to the MIL standard 1553, or are those suggested test plans and can be looked at as examples for customized test plans?


The validation test plan and production test plans are not mandated by Mil-STD-1553. They are requirements invoked by customers. The validation test plan is to make sure the designer did not miss designing in any of the MIL-STD-1553 requirements. Passing the test at room temperature does not mean the part meets all the design specs. The design must function as an RT over all the environmental requirements.

Q. If we broadcast a mode code for self-test to the RTs, and then during the self-test an error is found, would the RT then transmit some kind of message to indicate the error? I am asking this because I read somewhere that RT's don't respond to broadcast messages.


When a remote terminal receives a broadcast command it must never respond.  The Bus Controller will get an updated status from the remote terminal when it sends its next non-broadcast command, this is when the BC will be flagged if an error occurred.

Q. How can you test a 1553B to see if it is working correctly?


To validate that 1553B you need to pass the MIL-STD-1553 Validation Test Plan.  There is a test plan for a BC and one for an RT. To run the test plan you need a MIL-STD-1553 simulator board that plugs into a PC and you need validation software.  Both are available from a number of vendors. The simulator output gets connected to a bus coupler and then to the 1553 device you want to validate.

Q. I have never found a good explanation of the RT address parity bit. Does it behave the same way on all 1553 systems or can a vendor decide if their system uses even or odd parity on RT address strapping?


For all 1553 systems RT Parity bit shall be used to set odd parity for the RT address.

Q. In an RT-RT transfer, do the receive word count and transmit word count have to be the same? Is it permissible to have the receiving unit setup to receive the first 27 words of a 30 word transmit, so the BC can capture all 30 words in the same transmit? (Receiving RT is not able to receive all 30 words.)


Yes, the receive word count must be equal to the transmit word count or you will get a decoder error because the receiver would see a high word count when the message is longer than what is expected.

Q. We want to implement 1553B IP core in FPGA. For this we are trying to purchase the complete 1553B specification documents. From where can it be purchased?


The MIL-STD-1553 standard can be found on

Q. Does both channels A & B share the same common shield in a bus?


There is a shield for channel A and a shield for channel B.

Q. How does the BCC take control of a defected BC bus?


The BCC can always switch channels if the other bus is defective.

Q. I am working on a system in an aircraft, and its RT is receiving both channel A & B failures intermittently?


You need to make sure the bus is terminated correctly.

Q. Can two RTs be connected to the same stub cable?


According to MIL-STD-1553, the stubs are technically not part of the RTs. Therefore, the two RTs, tested individually, should each be able to pass the MIL-STD-1553B input impedance test (1000 ohms minimum, transformer coupled).

In terms of input impedance testing, if the two RTs connected together were to be considered (and therefore tested) as a single "RT,” it is highly doubtful that the two RTs taken in parallel would pass the MIL-STD-1553B input impedance spec.

Depending upon the overall electrical configuration of the main bus on a platform (e.g., an aircraft), i.e., the number of stubs, lengths, spacings, impedances, etc., it would be highly likely to be able to connect two RTs using the same stub cable and have a reliably functional system. The most likely outcome is that such a configuration would work reliably, especially for a relatively short bus, low number of stub taps, and short stub lengths.

Note however, that in terms of bus system topology, that connecting two RTs to the same stub is not compliant to MIL-STD-1553.

Q. Is it allowable to use a 25 foot stub between a bus coupler and a terminal?


For a transformer-coupled (stub-coupled) RT, MIL-STD-1553B recommends (but does not require) a maximum stub length of 20 feet connecting between a bus coupling box and a single terminal (BC, RT, or monitor). The main intent of this stipulation is to minimize the stub loading on the main bus. Excessively long stubs and/or stubs terminated in low impedances can load down the main bus and result in transmission line reflections, and therefore waveform distortions. This can have the effect of increasing the bit error rate for terminals receiving data on the bus or, in extreme circumstances, cause terminals to stop receiving completely.

However, it is not all that uncommon for implementations to exceed the 25 foot recommendation. If you don't have too many of these types of loads on a particular 1553 bus (and the bus is not too long), then the terminals on it should operate reliably.

A transformer-coupled BC or RT is required to transmit a stub voltage of 18 to 27 volts peak-to-peak on its stub, which translates to a voltage on the main bus in the range of 6.36 to 9.54 volts peak-to-peak. A direct-coupled BC or RT is required to transmit 6.0 to 9.0 volts on the bus. Using the lower (direct-coupled) number and assuming a very short data bus (i.e., no attenuation on the main bus) this results in a minimum received voltage of 4.24 volts peak-to-peak on the stub
for a transformer-coupled BC or RT.

In considering cable attenuation, MIL-STD-1553B requires that a bus network must be designed to provide a voltage between 1.0 and 14.0 volts peak-to-peak at the input to every stub-coupled terminal. The minimum stub signal of 1.0 volt corresponds to a voltage of 1.41 volts peak-to-peak on the main bus. Assuming a minimum voltage transmitter, this allows for an attenuation ratio for the main bus of 4.24 to 1 (6/1.41), or 12.6 dB. This provides for a wide margin, in terms of cable lengths as well as terminal transmitter output and receiver threshold characteristics.

MIL-STD-1553B also requires that a transformer-coupled receiver must accept (in the case of an RT, must respond to) any voltage in the range of 0.86 to 14.0 volts peak-to-peak. This provides 0.14 volts margin between the lowest terminal input voltage and the maximum receiver threshold voltage. In addition, a BC or RT is required to not accept a voltage below 0.2
volts peak-to-peak (i.e., an RT receiving a voltage below this level must not respond).

Of course, the other consideration is transmission line reflections. Reflection problems can interfere with the operation of terminals on the bus. However, assuming there is a limited number of long stubs (longer than 20 feet), the bus should  operate reliably.

For the effect of the 25 foot stub cable, refer to Figure I-1.7 on page I-16 in our MIL-STD-1553 Designer's Guide, Sixth edition. For a transformer-coupled terminal, assuming a "1553B transformer", increasing the stub length from 20 to 25 feet will have the effect of reducing the (worst-case) impedance looking from the bus from about 500 ohms to 400 ohms,  representing a 25% increase in the stub loading.

Note that a "1553B transformer" implies a bus coupling transformer with a minimum open circuit impedance of 3000 ohms, as specified in paragraph of MIL-STD-1553B.

Q. We are thinking of using MIL-STD-1553B in an application where the length of the bus will be on the order of 100 meters (300 feet). My question is whether or not it is possible to use a 300 foot long bus with a high degree of confidence.


MIL-STD-1553B has no maximum bus length, and I have heard of instances where 1000 foot buses have operated successfully. You need to consider the following:

  1. You may want to perform a bus loading analysis/simulation. That is, consider the cable attenuation (for a long bus, you can buy heavier twinax cable with lower resistance per foot, and therefore lower attenuation), the number of bus taps (stubs), and the length and spacing of the stubs. I suggest that you either simulate this or build a mock-up. However, for a 300 foot bus with a reasonable number of terminals, it is unlikely that you will see a problem.
  2. You need to consider the BC response timeout time value. A 1000 foot bus results in a roundtrip time of 3 to 4 μs. With our ACE, Mini-ACE, and Enhanced Mini-ACE series bus controllers, the minimum nominal BC timeout value is 18.5 µs. In addition, you may program this parameter for higher nominal timeout values of 22.5, 50.5, or 128.0 µs.


Standards: 1553 Validation Testing FAQs

Q. How is MIL-STD-1553 terminal input impedance measured?


For the impedance measurement, we (DDC) use an HP 4192 impedance analyzer. The correct voltage for measuring input impedance, per the 1553 test plan, is in the range from 1.0 to 2.0 Vrms, applied on the stub. Assuming a 15 volt transceiver and therefore a stub-coupled turns ratio of 2:1, this results in a voltage of 2.0 to 4.0 Vrms applied at receiver inputs to the 1553 terminal hybrid. In order to get a stable impedance measurement, the guard conductor from the analyzer needs to be connected to the transformer center tap on the stub side.

Q. For performing the RT Validation Test Plan noise (bit error rate) test, is it necessary to use the noise gate?


At one time, the noise gate was required for our older generation series terminals, the BUS-61553 (AIM-HY) and the BUS-61559 (AIM-HY'er).

 However, the need for the noise gate has been eliminated by the decoder design used in the ACE, Mini-ACE (Plus), the Enhanced Mini-ACE, and the SP'ACE. The new decoder provides improved filtering at the end of a received message, eliminating the need for the noise gate.

Standards: MIL-STD-1760 FAQs

Q. What are the additional requirements for aMIL-ST-1760 RT, beyond the requirements of MIL-STD-1553?


There are several additional requirements:

  1. The stub-coupled transmitter voltage must be a minimum of 20 volts peak-to-peak (the requirement for MIL-STD-1553B is 18 volts peak-to-peak).
  2. There are requirements regarding the RT address. Part of these may be satisfied by latching the RT address (from the 1760 connector) soon after power turn-on. For more details, refer to the answer to the next question.
  3. A 1760 compliant RT must be able to respond on the bus within 150 ms following power turn-on. At this time, it is permitted to respond with the "Busy" status word set. This indicates that while the RT is "alive," it is not yet able to transfer data. Alternatively, it may respond with valid data.
  4. Within 500 ms following power turn-on, the RT must be responding with data as defined by the 1760 standard, with the "Busy" status bit not set. This means that the RT's host processor must be fully up and running at this time.
  5. For a bus controller, most of the MIL-STD-1760 requirements are fulfilled by means of software, rather than by hardware. One "gray area" is with regards to the 1760 requirement to transmit and verify (at the receiving end) a checksum with every message.The checksum requirement may be implemented by either hardware or software. DDC's opinion is that it is better to fulfill this requirement in software rather than hardware. The reason for this is that a software verification provides for a complete "end-to-end" integrity verification.

    What we mean by "end-to-end" is that the checksum, if implemented in software, encompasses the operation not only of the 1553 (1760) communications interface, but also of the BC's and RT's host microprocessors and memory, along with the BC's and RT's embedded processor and firmware.

    Keep in mind that the integrity of the 1553 (1760) communication link is still checked by the BC and RT hardware, by means of the parity bit transmitted and checked with each word of every message transmitted across the bus.

Q. Are there special considerations for MIL-STD-1760 regarding RT address?


Yes, There are several considerations:

  1. For MIL-STD-1760, the RT address must be provided from the 1760 connector. That is, it must not be programmed by the RT's host processor software.
  2. When any of the RT address signals are connected to logic "0," there must be a minimum of 5 mA of current in the wire to the 1760 connector. Assuming a 5V power supply, this implies the need for pull-up resistors of less than 1KΩ between +5V and each of the RT address signals.
  3.  Note that for routing the RTAD signals to the 1760 connector, it is suggested that some form of ESD protection - either capacitors or clamping diodes - be used. Note that this is just a suggestion, it is not a MIL-STD-1760 requirement.
  4. The RT address must be latched into the RT within 10 ms following power turn-on. In addition, it must not change after it has been latched. There are a few different methods for doing this, depending on one's interpretation of the 1760 standard.