This article includes a list of general references, but it lacks sufficient corresponding inline citations. Please help to improve this article by introducing more precise citations. (March 2010) (Learn how and when to remove this message)

MIL-STD-1553 is a military standard published by the United States Department of Defense that defines the mechanical, electrical, and functional characteristics of a serial data bus. It was originally designed as an avionic data bus for use with military avionics, but has also become commonly used in spacecraft on-board data handling (OBDH) subsystems, both military and civil, including use on the James Webb space telescope. It features multiple (commonly dual) redundant balanced line physical layers, a (differential) network interface, time-division multiplexing, half-duplex command/response protocol, and can handle up to 31 Remote Terminals (devices); 32 is typically designated for broadcast messages. A version of MIL-STD-1553 using optical cabling in place of electrical is known as MIL-STD-1773.

MIL-STD-1553 was first published as a U.S. Air Force standard in 1973, and first was used on the F-16 Falcon fighter aircraft. Other aircraft designs quickly followed, including the F/A-18 Hornet, AH-64 Apache, P-3C Orion, F-15 Eagle and F-20 Tigershark. It is widely used by all branches of the U.S. military and by NASA.^[1] Outside of the US it has been adopted by NATO as STANAG 3838 AVS. STANAG 3838, in the form of UK MoD Def-Stan 00-18 Part 2,^[2] is used on the Panavia Tornado; BAE Systems Hawk (Mk 100 and later); and extensively, together with STANAG 3910 "EFABus", on the Eurofighter Typhoon.^[3] Saab JAS 39 Gripen uses MIL-STD-1553B.^[4] The Russian made MiG-35 also uses MIL-STD-1553.^[5] MIL-STD-1553 is being replaced on some newer U.S. designs by IEEE 1394 (commonly known as FireWire).^[6]

MIL-STD-1553B, which superseded the earlier 1975 specification MIL-STD-1553A, was published in 1978. The basic difference between the 1553A and 1553B revisions is that in the latter, the options are defined rather than being left for the user to define as required. It was found that when the standard did not define an item, there was no coordination in its use. Hardware and software had to be redesigned for each new application. The primary goal of the 1553B was to provide flexibility without creating new designs for each new user. This was accomplished by specifying the electrical interfaces explicitly so that electrical compatibility between designs by different manufacturers could be assured.

Six change notices to the standard have been published since 1978.^[7] For example, change notice 2 in 1986 changed the title of the document from "Aircraft internal time division command/response multiplex data bus" to "Digital time division command/response multiplex data bus".

MIL-STD-1553C is the last revision made in February 2018. Revision C is functionally equivalent to Revision B but contains updated graphics and tables to ease readability of the standard.^[8]

The MIL-STD-1553 standard is maintained by both the U.S. Department of Defense and the Aerospace branch of the Society of Automotive Engineers.

A single bus consists of a wire pair with 70–85 Ω impedance at 1 MHz. Where a circular connector is used, its center pin is used for the high (positive) Manchester bi-phase signal. Transmitters and receivers couple to the bus via isolation transformers, and stub connections branch off using a pair of isolation resistors and, optionally, a coupling transformer. This reduces the impact of a short circuit and ensures that the bus does not conduct current through the aircraft. A Manchester code is used to present both clock and data on the same wire pair and to eliminate any DC component in the signal (which cannot pass the transformers). The bit rate is 1.0 megabit per second (1-bit per μs). The combined accuracy and long-term stability of the bit rate is only specified to be within ±0.1%; the short-term clock stability must be within ±0.01%. The peak-to-peak output voltage of a transmitter is 18–27 V.

The bus can be made dual or triply redundant by using several independent wire pairs, and then all devices are connected to all buses. There is provision to designate a new bus control computer in the event of a failure by the current master controller. Usually, the auxiliary flight control computer(s) monitor the master computer and aircraft sensors via the main data bus. A different version of the bus uses optical fiber, which weighs less and has better resistance to electromagnetic interference, including EMP. This is known as MIL-STD-1773.^[9] NASA's "AS 1773" experiment has a dual rate of 1 Mbit/s or 20 Mbit/s – probably a predecessor of STANAG 3910.^[10]

A MIL-STD-1553 multiplex data bus system consists of a Bus Controller (BC) controlling multiple Remote Terminals (RT) all connected together by a data bus providing a single data path between the Bus Controller and all the associated Remote Terminals. There may also be one or more Bus Monitors (BM); however, Bus Monitors are specifically not allowed to take part in data transfers, and are only used to capture or record data for analysis, etc. In redundant bus implementations, several data buses are used to provide more than one data path, i.e. dual redundant data bus, tri-redundant data bus, etc. All transmissions onto the data bus are accessible to the BC and all connected RTs. Messages consist of one or more 16-bit words (command, data, or status). The 16 bits comprising each word are transmitted using Manchester code, where each bit is transmitted as a 0.5 μs high and 0.5 μs low for a logical 1 or a low-high sequence for a logical 0. Each word is preceded by a 3 μs sync pulse (1.5 μs low plus 1.5 μs high for data words and the opposite for command and status words, which cannot occur in the Manchester code) and followed by an odd parity bit. Practically each word could be considered as a 20-bit word: 3-bit for sync, 16-bit for payload and 1-bit for odd parity control. The words within a message are transmitted contiguously and there has to be a minimum of a 4 μs gap between messages. However, this inter-message gap can be, and often is, much larger than 4 μs, even up to 1 ms with some older Bus Controllers. Devices have to start transmitting their response to a valid command within 4–12 μs and are considered to not have received a command or message if no response has started within 14 μs.

All communication on the bus is under the control of the Bus Controller using commands from the BC to the RTs to receive or transmit. The sequence of words, (the form of the notation is <originator>.<word_type(destination)> and is a notation similar to CSP), for transfer of data from the BC to a terminal is

master.command(terminal) → terminal.status(master) → master.data(terminal) → master.command(terminal) → terminal.status(master)

and for terminal to terminal communication is

master.command(terminal_1) → terminal_1.status(master) → master.command(terminal_2) → terminal_2.status(master) → master.command(terminal_1) → terminal_1.data(terminal_2) → master.command(terminal_2) → terminal_2.status(master)

This means that during a transfer, all communication is started by the Bus Controller, and a terminal device cannot start a data transfer on its own. In the case of an RT to RT transfer the sequence is as follows: An application or function in the subsystem behind the RT interface (e.g. RT1) writes the data that is to be transmitted into a specific (transmit) sub-address (data buffer). The time at which this data is written to the sub-address is not necessarily linked to the time of the transaction, though the interfaces ensure that partially updated data is not transmitted. The Bus controller commands the RT that is the destination of the data (e.g. RT2) to receive the data at a specified (receive) data sub-address and then commands RT1 to transmit from the transmit sub-address specified in the command. RT1 transmits a Status word, indicating its current status, and the data. The Bus Controller receives RT1's status word, and sees that the transmit command has been received and actioned without a problem. RT2 receives the data on the shared data bus and writes it into the designated receive sub-address and transmits its Status word. An application or function on the subsystem behind the receiving RT interface may then access the data. Again the timing of this read is not necessarily linked to that of the transfer. The Bus Controller receives RT2's status word and sees that the receive command and data have been received and actioned without a problem.

If, however, either RT fails to send its status or the expected data or indicates a problem through the setting of error bits in the status word, the Bus Controller may retry the transmission. Several options are available for such retries including an immediate retry (on the other data bus of a redundant pair of data buses) and a retry later (on the same bus) in the sequence of transfers.

The sequences ensure that the terminal is functioning and able to receive data. The status word at the end of a data transfer sequence ensures that the data has been received and that the result of the data transfer is acceptable. It is this sequence that gives MIL-STD-1553 its high integrity.

However, the standard does not specify any particular timing for any particular transfer — that's up to the system designers. Generally (the way it is done on most military aircraft), the Bus Controller has a schedule of transfers that covers the majority of transfers, often organized into a major frame or major cycle, which is often subdivided into minor cycles. In such a cyclic executive schedule structure, transfers that occur in every minor cycle (rate group 1) happen at the highest rate, typically 50 Hz, transfers that occur in every other minor cycle, of which there are two groups (rate group 2.1 and 2.2) happen at the next highest rate, e.g. 25 Hz. Similarly, there are four groups (3.1, 3.2, 3.3, and 3.4) at, e.g., 12.5 Hz and so on. Hence, where this scheduling structure is used, the transfers are all at harmonically related frequencies, e.g. 50, 25, 12.5, 6.25, 3.125, and 1.5625 Hz (for a major frame comprising 32 minor cycles at 50 Hz). Whilst RTs cannot start a transfer directly on their own, the standard does include a method for when an RT needs to transmit data that is not automatically scheduled by the Bus Controller. These transfers are often called acyclic transfers as they are outside the structure used by the cyclic executive. In this sequence, an RT requests transmission through a bit in the status word, the Service Request bit. Generally, this causes the Bus Controller to transmit a Transmit Vector Word Mode Code command. However, where an RT only has one possible acyclic transfer, the Bus Controller can skip this part. The vector word is transmitted by the RT as a single 16-bit data word. The format of this vector word is not defined in the standard, so the system designers must specify what values from what RTs mean what action the Bus Controller is to take. This may be to schedule an acyclic transfer either immediately or at the end of the current minor cycle. This means that the Bus Controller has to poll all the Remote Terminals connected to the data bus, generally at least once in a major cycle. RTs with higher-priority functions (for example, those operating the aircraft control surfaces) are polled more frequently. Lower-priority functions are polled less frequently.

Six types of transactions are allowed between the BC and a specific RT or between the Bus Controller and a pair of RTs:

1. Controller to RT Transfer. The Bus Controller sends one 16-bit receive command word, immediately followed by 1 to 32 16-bit data words. The selected Remote Terminal then sends a single 16-bit Status word.
2. RT to Controller Transfer. The Bus Controller sends one transmit command word to a Remote Terminal. The Remote Terminal then sends a single Status word, immediately followed by 1 to 32 words.
3. RT to RT Transfers. The Bus Controller sends out one receive command word immediately followed by one transmit command word. The transmitting Remote Terminal sends a Status word immediately followed by 1 to 32 data words. The receiving Terminal then sends its Status word.
4. Mode Command Without Data Word. The Bus Controller sends one command word with a Sub-address of 0 or 31 signifying a Mode Code type command. The Remote Terminal responds with a Status word.
5. Mode Command With Data Word (Transmit). The Bus Controller sends one command word with a Sub-address of 0 or 31 signifying a Mode Code type command. The Remote Terminal responds with a Status word immediately followed by a single Data word.
6. Mode Command With Data Word (Receive). The Bus Controller sends one command word with a Sub-address of 0 or 31 signifying a Mode Code type command immediately followed by a single data word. The Remote Terminal responds with a Status word.

MIL-STD-1553B also introduced the concept of optional broadcast transfers, in which data is sent to all RTs that implement the option, but to which no RTs respond, as this would cause conflicts on the bus. These can be used where the same data is sent to multiple RTs, to reduce the number of transactions and thus reduce the loading on the data bus. However, the lack of explicit responses by the RTs receiving these broadcasts means that these transfers cannot be automatically re-tried in the event of an error in the transaction.

Four types of broadcast transactions are allowed between the BC and all capable RTs:

1. Controller to RT(s) Transfer. The Bus Controller sends one receive command word with a Terminal address of 31 signifying a broadcast type command, immediately followed by 1 to 32 data words. All Remote Terminals that implement broadcasts will accept the data but no Remote Terminals will respond.
2. RT to RT(s) Transfers. The Bus Controller sends out one receive command word with a Terminal address of 31 signifying a broadcast type command, immediately followed by one transmit command. The transmitting Remote Terminal sends a Status word immediately followed by 1 to 32 data words. All Remote Terminals that implement broadcasts will accept the data but no Remote Terminals will respond.
3. Mode Command Without Data Word (Broadcast). The Bus Controller sends one command word with a Terminal address of 31 signifying a broadcast type command and a sub-address of 0 or 31 signifying a Mode Code type command. No Remote Terminals will respond.
4. Mode Command With Data Word (Broadcast). The Bus Controller sends one command word with a Terminal address of 31 signifying a broadcast type command and a sub-address of 0 or 31 signifying a Mode Code type command, immediately followed by one Data word. No Remote Terminals will respond.

The Command Word is built as follows. The first 5 bits are the Remote Terminal address (0–31). The sixth bit is 0 for Receive or 1 for Transmit. The next 5 bits indicate the location (sub-address) to hold or get data on the Terminal (1–30). Note that sub-addresses 0 and 31 are reserved for Mode Codes. The last 5 bits indicate the number of words to expect (1–32). All zero bits indicate 32 words. In the case of a Mode Code, these bits indicate the Mode Code number (e.g., Initiate Self Test and Transmit BIT Word).

The Status Word decodes as follows. The first 5 bits are the address of the Remote Terminal that is responding. The rest of the word is single bit condition codes, with some bits reserved. A 'one' state indicates condition is true. More than one condition may be true at the same time.

The image below exemplifies many of the protocol and physical layer concepts explained above. For example, the RT address contained in the Command Word has a value of 0x3 (in range of 0 to 31). The sixth bit is 1, indicating a Transmit from the RT. The sub-address is 0x01. The last 5 bits indicate the number of words to expect, which has a value of 1, which is matched by the single Data Word (value 0x2) after the Status Word.

Also as explained above, devices have to start transmitting their response to a valid command within 4–12 microseconds. In the example, the Response Time is 8.97 μs, therefore within specifications. This means that the Remote Terminal (RT) number 3 has responded to the Bus Controller query after 8.97 μs. The amplitude of the query is lower than the amplitude of the response because the signal is probed at a location closer to the Remote Terminal.

In the Status Word, the first 5 bits are the address of the Remote Terminal that is responding, in this case 0x3. A correct Transfer exhibits the same RT address in the Command Word as in the Status Word.

Figure 1 shows a sample MIL-STD-1553B system that consists of:

• redundant MIL-STD-1553B buses
• a Bus Controller
• a Backup Bus Controller
• a Bus Monitor
• a standalone Remote Terminal with one or more subsystems communicating with it
• a subsystem with an embedded Remote Terminal

There is only one Bus Controller at a time on any MIL-STD-1553 bus. It initiates all message communication over the bus.

Figure 1 shows 1553 data bus details:

• operates according to a command list stored in its local memory
• commands the various Remote Terminals to send or receive messages
• services any requests that it receives from the Remote Terminals
• detects and recovers from errors
• keeps a history of errors

The 1553B spec dictates that all devices in the system be connected to a redundant pair of buses to provide an alternate data path in the event of damage or failure of the primary bus. Bus messages only travel on one bus at a time, determined by the Bus Controller.

While there may be only one BC on the bus at any one time, the standard provides a mechanism for handover to a Backup Bus Controller (BBC) or (BUBC), using flags in the status word and Mode Codes. This may be used in normal operation where handover occurs because of some specific function, e.g. handover to or from a BC that is external to the aircraft, but connected to the bus. Procedures for handover in fault and failure conditions generally involve discrete connections between the main and backup BCs, and the backup monitoring the actions of the main BC during operation. For example, if there is a prolonged quiescence on the bus indicating that the active BC has failed, the next highest priority backup BC, indicated by the discrete connections, will take over and begin operating as the active BC.

A Bus Monitor (BM) cannot transmit messages over the data bus. Its primary role is to monitor and record bus transactions, without interfering with the operation of the Bus Controller or the RTs. These recorded bus transactions can then be stored, for later off-line analysis.

Ideally, a BM captures and records all messages sent over the 1553 data bus. However, recording all of the transactions on a busy data bus might be impractical, so a BM is often configured to record a subset of the transactions, based on some criteria provided by the application program.

Alternatively, a BM is used in conjunction with a Backup Bus Controller. This allows the Backup Bus Controller to "hit the ground running", if it is called upon to become the active Bus Controller.

A Remote Terminal can be used to provide:

• an interface between the MIL-STD-1553B data bus and an attached subsystem
• a bridge between a MIL-STD-1553B bus and another MIL-STD-1553B bus.

For example, in a tracked vehicle, a Remote Terminal might acquire data from an inertial navigational subsystem, and send that data over a 1553 data bus to another Remote Terminal, for display on a crew instrument. Simpler examples of Remote Terminals might be interfaces that switch on the headlights, the landing lights, or the annunciators in an aircraft.

Test Plans for Remote Terminals:

The RT Validation Test Plan is intended for design verification of Remote Terminals designed to meet the requirements of AS 15531 and MIL-STD-1553B with Notice 2. This test plan was initially defined in MIL-HDBK-1553, Appendix A. It was updated in MIL-HDBK-1553A, Section 100. The test plan is maintained by the SAE AS-1A Avionic Networks Subcommittee as AS4111.

The RT Production Test Plan is a simplified subset of the validation test plan and is intended for production testing of Remote Terminals. This test plan is maintained by the SAE AS-1A Avionic Networks Subcommittee as AS4112.

The bus hardware encompasses (1) cabling, (2) bus couplers, (3) terminators and (4) connectors.

The industry has standardized the cable type as a twinax cable with a characteristic impedance of 78 ohms, which is almost the midpoint of the specification range of 70 to 85 ohms.

MIL-STD-1553B does not specify the length of the cable. However, the maximum length of cable is directly related to the gauge of the cable conductor and time delay of the transmitted signal. A smaller conductor attenuates the signal more than a larger conductor. Typical propagation delay for a 1553B cable is 1.6 nanoseconds per foot. Thus, the end-to-end 100-foot bus (30 m) would have a 160 nanosecond propagation delay, which is equal to the average rise time of a 1553B signal. According to MIL-HDBK-1553A, when a signal's propagation delay time is more than 50% of the rise or fall time, it is necessary to consider transmission line effects. This delay time is proportional to the distance propagated. Also, consideration must be given to the actual distance between the transmitter and receiver, and the individual waveform characteristics of the transmitters and receivers.

MIL-STD-1553B specifies that the longest stub length is 20 feet (6.1 m) for transformer coupled stubs, but can be exceeded. With no stubs attached, the main bus looks like an infinite length transmission line with no disturbing reflections. When a stub is added, the bus is loaded and a mismatch occurs with resulting reflections. The degree of mismatch and signal distortion due to reflections are a function of the impedance presented by the stub and terminal input impedance. To minimize signal distortion, it is desirable that the stub maintain high impedance. This impedance is reflected back to the bus. At the same time, however, the impedance must be kept low so that adequate signal power will be delivered to the receiving end. Therefore, a tradeoff between these conflicting requirements is necessary to achieve the specified signal-to-noise ratio and system error rate performance (for more information, refer to MIL-HDBK-1553A).

Each terminal, RT, BC, or BM, is connected to the bus through a stub, formed of a length of cable of the same type as the bus itself. MIL-STD-1553B defines two ways of coupling these stubs to the bus: transformer coupled stubs and direct coupled stubs. Transformer coupled stubs are preferred for their fault tolerance and better matching to the impedance of the bus, and consequent reduction in reflections, etc. The appendix to MIL-STD-1553B (in section 10.5, Stubbing) states "The preferred method of stubbing is to use transformer coupled stubs… This method provides the benefits of DC isolation, increased common mode rejection, a doubling of effective stub impedance, and fault isolation for the entire stub and terminal. Direct coupled stubs… should be avoided if at all possible. Direct coupled stubs provide no DC isolation or common mode rejection for the terminal external to its subsystem. Further, any shorting fault between the subsystems [sic] internal isolation resistors (usually on a circuit board) and the main bus junction will cause failure of that entire bus. It can be expected that when the direct coupled stub length exceeds 1.6 feet (0.49 meters)], that it will begin to distort the main bus waveforms."

The use of transformer coupled stubs also provides improved protection for 1553 terminals against lightning strikes. Isolation is even more critical in new composite aircraft where the skin of the aircraft no longer provides an inherent Faraday shield as was the case with aluminum skinned aircraft.^[11]

In a transformer coupled stub, the length of the stub cable should not exceed 20 feet (6.1 m), but this may be exceeded "if installation requirements dictate." The coupling transformer has to have a turns ratio of 1:1.41 ± 3.0 percent. The resistors R both have to have a value of 0.75 Zo ± 2.0 percent, where Zo is the characteristic impedance of the bus at 1 MHz.

In a direct coupled stub, the length of stub cable should not exceed 1-foot, but again this may be exceeded if installation requirements dictate. The isolation resistors R have to have a fixed value of 55 ohms ± 2.0 percent.

Stubs for RTs, the BC, or BMs, are generally connected to the bus through coupling boxes, which may provide a single or multiple stub connections. These provide the required shielding (≥ 75 percent) and, for transformer coupled stubs, contain the coupling transformers and isolation resistors. They have two external connectors through which the bus feeds, and one or more external connectors to which the stub or stubs connect. These stub connectors should not be terminated with matching resistors, but left open circuit when not used, with blanking caps where necessary. One of the bus connectors may be terminated where the bus coupler is physically at the end of the bus cable, i.e. it is not normally considered essential to have a length of bus cable between the last bus coupler and the termination resistor.

Both ends of the bus, whether it includes one coupler or a series of couplers connected together, must be terminated (in accordance with MIL-STD-1553B) with "a resistance, equal to the selected cable nominal characteristic impedance (Zo) ± 2.0 percent." This is typically 78 ohms. The purpose of electrical termination is to minimize the effects of signal reflections that can cause waveform distortion. If terminations are not used, the communications signal can be compromised causing disruption or intermittent communications failures.

The standard does not specify the connector types or how they should be wired, other than shielding requirements, etc. In lab environments concentric twinax bayonet style connectors are commonly used. These connectors are available in standard (BNC size), miniature and sub-miniature sizes. In military aircraft implementations, MIL-DTL-5015 and MIL-DTL-38999 circular connectors are generally used.

STANAG 3910 (EFABus) mates a 1553 or 1773 link with additional high-speed 20 Mbps buses, either optical or electrical. In the STANAG form, the 1553/1773 low-speed link serves as the control channel for the high speed link. In the EFABus Express (EfEx) form, the high-speed link acts as its own control channel. Either way, high and low-speed buses share the same addressing model and can communicate with each other.^[12]

STANAG 7221 (E1553) expands a 1553 link with the capability to carry a 100 Mbps signal on the same wire without interfering with old signaling.^[13] The concept is similar to how ADSL avoids voice frequencies, but done at higher bandwidths.^[14] In addition to 1553B, it also runs over coax, twisted pair, Power-Line Carrier, and existing ARINC 429 links.^[15]

DIGIBUS (or Digibus, GAM-T-101) is the French counterpart to MIL-STD-1553. It is similar to MIL-STD-1553 in the same notion of Bus Controller, Remote Terminal, monitor, same transmission speed, but the difference is that DIGIBUS uses separate links for data and commands.^[16]

GOST 26765.52-87 and its descendant GOST R 52070-2003 are the Soviet and Russian, respectively, equivalents of MIL-STD-1553B. The encoding, data rate, word structure, and control commands are fully identical.

GJV289A is the Chinese equivalent of MIL-STD-1553. Aircraft utilizing this system can reportedly use both Soviet (GOST bus)^[17] and western (MIL-STD-1553 bus) weapons.^[18]

H009 (also called MacAir H009), introduced by McDonnell in 1967, was one of the first avionics data buses. It is a dual redundant bus controlled by a Central Control Complex (CCC), with up to 16 Peripheral Units (PUs), synchronously communicating using a 1 MHz clock. H009 was used in early F-15 fighter jets, but due its noise sensitivity and other reliability issues was replaced by MIL-STD-1553.

When developing or troubleshooting for MIL-STD-1553, examination of the electronic signals is useful. A logic analyzer with protocol-decoding capability, also a bus analyzer or protocol analyzer, are useful tools to collect, analyze, decode and store the waveforms of the high-speed electronic signals.

Intel M82553 Protocol Management Unit (PMU) using the CHMOS III technology. This device meets full bus interface protocol standard.^[19]

• MIL-STD-1760
• MIL-STD-704
• Aircraft flight control systems
• Fly-by-wire
• Avionics Full-Duplex Switched Ethernet (AFDX) – a faster Ethernet-based technology
• ARINC 429 Commercial Avionics Counterpart
• Bus coupler – A brief description of bus coupler
• TTEthernet – Time-Triggered Ethernet (SAE AS6802)
• SpaceWire

• MIL-STD-1553C: Digital Time Division Command/Response Multiplex Data Bus. United States Department of Defense, February 2018.
• SAE AS15531: Digital Time Division Command/Response Multiplex Data Bus.
• SAE AS15532: Data Word and Message Formats.
• SAE AS4111: RT Validation Test Plan.
• SAE AS4112: RT Production Test Plan.

• MIL-STD-1553, Digital Time Division Command/Response Multiplex Data Bus. United States Department of Defense, February 2018.
• MIL-STD-1773, Fiber Optics Mechanization of an Aircraft Internal Time Division Command/Response Multiplex Data Bus. United States Department of Defense, October 1989.
• MIL-STD-1553 Tutorial from AIM, Avionics Databus Solutions, Interface Boards for MIL-STD-1553/1760
• MIL-STD-1553 Tutorial from Avionics Interface Technologies (registration required)
• MIL-STD-1553 Tutorial (video) from Excalibur Systems Inc.
• MIL-STD-1553 Couplers Tutorial (video) from Excalibur Systems Inc.
• MIL-STD-1553 Tutorial by GE Intelligent Platforms (registration required)
• MIL-STD-1553 Tutorial and References from Ballard Technology (includes MIL-STD-1553B & MIL-HDBK-1553A Notice2)
• MIL-STD-1553 Designer's Guide from Data Device Corporation
• MIL-STD-1553 Tutorial and Reference from Alta Data Technologies
• INTRODUCTION TO THE MIL-STD-1553B SERIAL MULTIPLEX DATA BUS by D. R. Bracknell, Royal Aircraft Establishment, Farnbourogh, 1988.
• Introduction to MIL-STD-1553 Short Course from Georgia Tech Professional Education
• MIL-STD-1553 Complete online reference from Data Device Corporation
• Military Computer with MIL-STD-1553 Interface Archived 2017-03-07 at the Wayback Machine from AMDTEC Defence