This special newsletter goes out to my colleagues at Sandia National Laboratories, in celebration of 10 years of working together.
Thanks so very much for your support over the years. I am looking forward to returning to your site on April 18-19, 2005, to teach High-Speed Digital Design to a new group of engineers. This will be my only visit to Sandia in 2005, so I ask for your help in spreading the word about the class to your colleagues and co-workers.
Thanks again to all of your who have written me over the years. It’s been a pleasure working with you and I look forward to continued visits to Albuquerque.
I've recently noticed an increase in the number of aerospace products using serial connections for internal data exchange. Several factors support this choice:
- A reduction in the number of wires, and therefore weight and bulk, made possible by high-speed serial communications,
- Availability of transceivers fast enough to move suitable amounts of data through serial connections, and
- Standard serial interface protocols.
The existence of standards helps in two ways. First, any design based on standards doesn't start from scratch—it starts with a number available, working system components. That puts you way ahead on your project schedule.
Second, the serial link components sold for LAN, consumer, and automotive applications are produced in such high volumes, compared to aerospace demand, that those components are as close as you can get to zero-cost without actually having negative mass.
Consumer-level components are not be appropriate for all applications. For example, if you require radiation hardening or wide temperature range capability, then you will have to "roll your own" transceivers. Nevertheless, even in military-rated applications, defining a standards-based architecture and then designing components to meet those standards will produce a finished product in less time, with fewer mistakes, than starting with a blank slate.
If you are responsible for selecting a serial interface standard, I'd like to pass along a few ideas for your selection criteria, starting with some concepts having to do with the physical link protocol, particularly DC balance.
The DC-balance property says that the number of ones and zeroes in a data pattern balance out over a certain period of time, where the averaging time depends on the coding standard. DC balance makes it possible to couple your signal through transformers without significantly distorting the signal.
To see how this works, consider Manchester coding. This approach codes each data bit into a pattern of two successive chips. Each logical one codes into a one-zero pattern of chips on the wires, and each logical zero codes as a zero-one pattern. I call the patterns on the wires "chips" to distinguish them from the useful data-carrying bits that are to be conveyed by this arrangement.
Averaged over any interval longer than two chips, the number of ones and zeros on the wire never falls out of balance by more than one chip in either direction. Regardless of the data pattern the DC content of a Manchester-coded signal is fixed at a value halfway between zero and one. In other words, there is no useful information-carrying content at low frequencies, which explains why you can pass a Manchester-coded data signal through a transformer. The transformer strips out the DC content, but if you just add back in a fixed value of 1/2 at the other end you can completely reconstruct the transmitted signal.
Manchester coding also provides a high number of transitions on the line (at least one per transmitted bit), which simplifies the design of PLL clock-recovery units used with this data code. As a result, it is possible to construct a data recovery unit for a Manchester coded link that does not required a crystal oscillator.
The DC balance and high transition-density requirements are not unique to Manchester coding. Many other data codes incorporate similar properties. In particular, I should draw you attention to the 8B10B code, popularized in several LAN standards. It provides good DC balance averaged over groups of ten chips, with no less than three transitions in each group of ten chips.
DC balance also makes possible the use of AC-coupled amplifier stages within an optical receiver (mentioned in "Fiber-Optic Encoding"), and some other tricks for shifting DC bias levels between different logic families.
What, you may be wondering, has DC-balance to do with aerospace architecture? The link between those two subjects has to do with transformer coupling, and the possibility of eliminating shielding on serial cables.
Lacking an extremely well-balanced transformer-coupled output stage, no serial link will meet reasonable standards for noise emission and susceptibility. Specifically, the common-mode component of the transmitted signal radiates very efficiently. Even if a well-balanced twisted-pair media connects your devices, radiation from the common-mode imbalance of a typical digital driver violates all known FCC and EN emissions requirements. Even if your product is totally enclosed in a solid metal casing (or operates in space, where you might not care about incidental radiation), you've got to consider radiation from the digital signals interfering with your navigation hardware. Unshielded twisted-pair links without transformer coupling don't cut it.
How about adding a shield? A shield adds weight, cost, complicates the connectors, and can in some cases actually deteriorate your noise performance. For example, suppose you have a low-impedance shield tied between two boxes located in different areas of a large-scale product. Any time-varying magnetic fields (from motors, radar, radio signals, or what-have-you) in the vicinity of that shield will induce current on the shield conductor. If the shield ties to the chassis of one of the boxes, that current, once coupled into the shield, flows through the box. It's easy to test your susceptibility to such shield currents.
Wrap a piece of tinfoil around one of your shielded cables and zap it with an ESD tester. The blast of current from the tester runs onto the foil, from whence it couples capacitively onto the cable shield, and from there travels towards the shielded box. You hope that the connection between the shield and the external chassis of the box is sufficiently well-sealed to conduct all of the noise current safely around the exterior of your box, with none penetrating to the sensitive circuits within. I call this test the serial link killer. In practical testing you will find vast differences between the immunity of various chassis constructions to this form of noise coupling.
If, on the other hand, you use well-balanced, transformer-coupled interface magnetics (such as are used on the Ethernet 100BASE-TX system) then, for commercial applications at least, no shield is required on the twisted pair link. Common-mode noise currents induced on the link are then stopped, to a large degree, by the transformer, and do not enter your product. Rather than accepting the coupled noise current and attempting to divert it around the chassis, this approach blocks the noise current from entering by presenting a high common-mode impedance at its input terminals.
You may be interested to read the following related article about serial links, dealing with automatic detection of failure conditions ("Carrier Detection"). To the list of possible error conditions detailed in that document I should like to add "long burst of data errors caused by serial-link-killer test". If you can design a system that quickly detects and recovers from such errors, you will have made a terrifically reliable system.
Dr. Howard Johnson