Gillham code
Gillham code is a variant of the Gray code employed in aviation as a digital encoding method to transmit uncorrected barometric pressure altitude data from an encoding altimeter or blind encoder to a transponder.[1] It utilizes a parallel interface, typically comprising eleven wires including a strobe signal, to represent altitude in 100-foot increments ranging from -1,000 feet to 126,700 feet.[2][3] This binary code format ensures that only one bit changes per altitude step, minimizing errors during transmission.[4] The code plays a critical role in secondary surveillance radar systems, particularly for Mode C altitude reporting in air traffic control and Traffic Alert and Collision Avoidance System (TCAS) operations, where accurate altitude data is vital for maintaining aircraft separation and issuing resolution advisories.[4] Standardized under ARINC 572, it has been a foundational element of transponder technology since the mid-20th century, interfacing with legacy equipment via dedicated output pins on devices like airdata computers.[5][2] Despite its reliability in bit transitions, the Gillham code lacks inherent error detection or correction mechanisms, earning it the designation of a "blind encoder" that can propagate faults like stuck bits, potentially leading to hazardous discrepancies in displayed altitudes.[1] As a result, aviation authorities recommend avoiding its sole use in modern installations, favoring instead digital protocols such as ARINC 429 with cross-verification from multiple altitude sources to enhance system integrity.[1] Ongoing maintenance procedures, including static system tests and code verification tables, ensure its accuracy within ±125 feet during operational checks.[4]History and Development
Origins
The Gillham code emerged from the Identification Friend or Foe (IFF) Mark X system, developed in the mid-1950s primarily for military aircraft identification during the Cold War era. This system, an advancement over earlier IFF technologies like Mark V, introduced expanded coding capabilities that included rudimentary altitude reporting to enhance air traffic coordination and threat assessment. Adopted by both military and civilian sectors, IFF Mark X's Mode C functionality provided the foundational framework for encoding pressure altitude data, addressing the growing demands of post-war aviation surveillance.[6] As international civil aviation expanded in the late 1950s and early 1960s, efforts intensified to adapt military transponder technologies for civilian use under the International Civil Aviation Organization (ICAO) framework. The initial purpose of what became the Gillham code was to enable reliable transmission of uncorrected barometric altitude from aircraft altimeters to ground-based secondary surveillance radar systems, facilitating safer air traffic management during the shift from proprietary military standards to global interoperability. This transition was driven by the need for precise, error-resistant altitude data in Mode C interrogations, building directly on IFF Mark X's pulse-coded replies.[7] The code is named after Ronald Lionel Gillham, a signals officer at the United Kingdom's Air Navigational Services within the Ministry of Transport and Civil Aviation, who contributed significantly to its design as the UK's representative on the International Air Transport Association (IATA) committee tasked with Mode C transponder specifications. The idea for the code was conceived during a family dinner as a modified Gray code. Gillham, honored with an MBE in 1955 for his aviation signaling work, passed away in March 1968 before the code's finalization, leading to its posthumous naming in his memory.[8] This timeline marked the code's evolution from military roots to a cornerstone of global aviation safety protocols.Standardization
The International Civil Aviation Organization (ICAO) adopted the Gillham code in the early 1960s as part of Mode C transponder specifications for automatic altitude transmission to enhance air traffic control surveillance.[9] This integration into ICAO Annex 10, Volume IV, defined the code as the standard for pressure altitude reporting in increments of 100 feet, ensuring global interoperability for secondary surveillance radar systems.[9] In 1968, the Aeronautical Radio, Incorporated (ARINC) published specification ARINC 572, which formalized the 12-bit Gillham code interface for commercial aviation altitude encoders, specifying the parallel wiring and signal characteristics for transponder inputs.[10] This standard complemented ICAO requirements by providing detailed engineering guidelines for implementation in air transport aircraft. ARINC 572 underwent revisions in the 1970s and 1980s, including ARINC 572-1, which refined wiring diagrams, interface tolerances, and integration with emerging avionics systems to address reliability and compatibility issues in expanding fleets.[11] These updates ensured the code's alignment with evolving aircraft electrical systems and transponder technologies. By the 2000s, ICAO began discouraging the use of the Gillham code due to its obsolescence amid advances in digital avionics, with the last major reference appearing in the 2009 amendments to Annex 10, Volume IV, favoring serial data protocols like ARINC 429 for new installations.[12]System Overview
Purpose and Function
The Gillham code serves as a digital encoding scheme that transmits uncorrected pressure altitude data from an aircraft's encoding altimeter to its secondary surveillance radar (SSR) transponder, enabling the inclusion of altitude information in Mode C replies.[13] This uncorrected pressure altitude is referenced to the standard atmospheric pressure of 1013.25 hPa (29.92 inHg), without adjustments for local barometric settings such as QNH, distinguishing it from the corrected altitude displayed to the pilot on the altimeter.[14] The code facilitates the relaying of this data as parallel binary signals to the transponder, which then incorporates it into interrogation responses for transmission to air traffic control (ATC) systems.[13] In aviation operations, the primary function of the Gillham code is to support ATC in maintaining vertical separation between aircraft by providing real-time pressure altitude readings, typically encoded in 100-foot increments up to a maximum of 62,750 feet, with an extended range up to 126,750 feet for altitudes above 20,750 feet.[14] This resolution ensures that ATC can monitor aircraft positions in the vertical plane with sufficient precision for safe spacing, as required under international standards for SSR operations.[14] The system's integration within transponder replies allows for automated altitude reporting during SSR interrogations, enhancing situational awareness and collision avoidance without relying on voice communications.[13] Unlike corrected altitudes that account for local pressure variations, the Gillham code's use of standard pressure ensures consistency across different atmospheric conditions, promoting uniform data interpretation by ground-based radar systems worldwide.[14] This standardization is critical for international air traffic management, where discrepancies in local settings could otherwise compromise safety margins.[14]Altitude Encoding Basics
Gillham code employs a 12-bit binary format to digitally represent aircraft pressure altitude, with 11 active bits dedicated to encoding the altitude value and the D1 bit left unused and set to zero.[15] This structure utilizes a modified Gray code scheme, where consecutive altitude values differ by only a single bit, enhancing error resistance in transmission over the parallel interface.[16] The code is derived from encoding altimeters that measure pressure altitude based on atmospheric pressure relative to the standard datum of 29.92 inHg (1013.25 hPa).[16][14] The encoding covers an altitude range from -1,000 feet to 62,750 feet, with an extended range up to 126,750 feet for altitudes above 20,750 feet, reported in 100-foot resolution steps.[16][14] Higher-order bits (D2, D4, A1–A4) primarily encode altitude in 500-foot increments above a base of -1,000 feet, while lower-order bits (B1–B2, C1–C2, and select combinations) provide the 100-foot and 200-foot offsets within each 500-foot block.[16] This hierarchical approach allows precise representation without requiring full binary counting, leveraging the Gray code's adjacency property. A key benefit of the modified Gray code is its error minimization: a single-bit error alters the decoded altitude by at most 500 feet, preventing large discrepancies from minor transmission faults.[16] This property is critical for maintaining reliable altitude reporting in air traffic control systems, where accuracy directly impacts separation assurance.[16]Code Structure
Bit Assignments
The Gillham code employs a parallel interface with 11 dedicated wires labeled D2, D4, A1, A2, A4, B1, B2, B4, C1, C2, and C4. The D1 position is unused and assumed to be zero for compatibility with the 12-bit format, but no wire is provided for it. These bits are output via standard 15-pin D-subminiature connectors in avionics systems.[2] The altitude in 500-foot increments is encoded using an 8-bit reflected binary Gray code across the bits D2 (MSB), D4, A1, A2, A4, B1, B2, B4 (LSB). This Gray code represents the integer value of (pressure altitude + 1000 ft) / 500 ft, allowing a range from -1000 ft to approximately 126,500 ft. Systems for lower altitudes may omit the D2 wire, limiting the range to about 62,500 ft using the remaining 7 bits. The single-bit-change property of the Gray code minimizes transmission errors.[17] The C bits—C1, C2, and C4—encode the 100-foot offsets from the nearest 500-foot multiple (0 to 700 ft in 100-ft steps) using a 3-bit mirrored Gray BCD variant known as the Datex code. Only five states (000, 001, 011, 010, 110) are used for offsets 0–400 ft, with higher offsets handled by incrementing the 500-ft code and using lower C values; invalid states like 101 and 111 are not used to aid error detection.[18] Electrically, the bit outputs are open-collector with low active state (on resistance <5 Ω, off leakage <10 µA), supporting pull-up to 5–50 V and maximum 20 mA per bit, compatible with 14 V or 28 V aircraft systems.[19][20]Parity and Mirroring
Gillham code relies on the Gray code's single-bit-change property for redundancy rather than explicit parity bits. Transponders validate received data by decoding the 8-bit Gray code to ensure it corresponds to a valid altitude and by checking that the C bits use only permitted states. Invalid codes trigger error flags, preventing faulty altitude transmission in SSR Mode C replies, per ARINC 572. No dedicated parity or A/B mirroring is present.[17]Encoding Process
500-Foot Increments
The primary altitude in Gillham code is encoded in 500-foot increments using an 8-bit reflected binary Gray code formed by the D2, D4, A1, A2, A4, B1, B2, B4 bits (with D2 as the most significant bit and B4 as the least significant bit), which represent values from 0 to 127 corresponding to altitudes from -1,000 feet to 62,500 feet.[15][21] This Gray code ensures that only one bit changes between consecutive altitude values, minimizing errors during transmission over parallel wires.[15] To compute the coarse altitude, the 8-bit Gray code is first converted to its binary equivalent through a bitwise XOR operation, where each bit is XORed with the preceding bit starting from the most significant bit (D2). The resulting binary value, denoted as n, is then used in the formula \text{Altitude}_{500} = (n \times 500) - 1,000 \, \text{ft} where $0 \leq n \leq 127. Low values of n (e.g., n = 0 for -1,000 ft) cover negative altitudes; the D1 bit is unused in standard implementations.[15][21] For illustration, the following table shows select examples of Gray-to-binary conversions for the D2 D4 A1 A2 A4 B1 B2 B4 bits (formatted as 8-bit sequences, MSB to LSB):| Gray Code (D2 D4 A1 A2 A4 B1 B2 B4) | Binary Equivalent | n | Altitude (ft) |
|---|---|---|---|
| 00000000 | 00000000 | 0 | -1,000 |
| 00000001 | 00000001 | 1 | -500 |
| 00011000 | 00010000 | 16 | 7,000 |
| 01000000 | 01111111 | 127 | 62,500 |
100-Foot Offsets
The 100-foot offsets in Gillham code provide fine resolution to the altitude encoding, allowing adjustments in 100-foot increments from the base 500-foot level established by the 8-bit Gray code (D2, D4, A1, A2, A4, B1, B2, B4 bits). These offsets are handled by the C bits, specifically C1, C2, and C4 (with C3 unused in standard implementations), which form a 3-bit binary-coded decimal (BCD) representation. C1 corresponds to the 100s place, C2 to the 200s place, and C4 to the 400s place, enabling combinations that cover offsets from 0 to 600 feet without ambiguity.[15] The offset value is calculated as Offset = (C1 × 100 + C2 × 200 + C4 × 400) feet when the D2 bit (from the Gray code) is 0, representing a direct addition to the 500-foot base. However, when D2 = 1, the interpretation flips to complement the offset relative to 500 feet, yielding Offset = 500 - (C1 × 100 + C2 × 200 + C4 × 400) feet, which applies to altitudes ending in 100 to 500 feet. This D2 interaction ensures single-bit changes for adjacent altitudes, maintaining the Gray code property for error resilience during transmission. A key restriction is that a 700-foot offset (C1=1, C2=1, C4=1) is prohibited, as it would duplicate the 0-foot offset under the flipped interpretation, potentially causing decoding errors; instead, such combinations are avoided in the encoding logic.[22][23] For example, a 100-foot offset (D2=0) is encoded with C1=1, C2=0, C4=0, resulting in Offset = 100 feet added to the base. Similarly, a 600-foot offset uses C1=0, C2=1, C4=1 (D2=0), yielding Offset = (200 + 400) = 600 feet. In the flipped case (D2=1), the same C bits for 100 feet would instead produce 500 - 100 = 400 feet, illustrating how the system covers all 100-foot steps up to 500 feet without overlap. These encodings are output via dedicated wires in the Gillham interface, ensuring compatibility with transponder systems for Mode C replies.[15]Decoding Process
500-Foot Decoding
The 500-foot decoding process in Gillham code extracts the coarse altitude component from the received bits D1, D2, A1, A2, A4, B1, B2, and B4, which collectively form a 9-bit Gray code representation of the altitude in 500-foot increments (ranging from -2 to 126, offset by +2 for negative altitudes).[15] These bits are transmitted in parallel via the Gillham interface and must first be converted from Gray code to standard binary to obtain the numerical value. The standard bit order for the Gray code is D1 (MSB), D2, A1, A2, A4, B1, B2, B4 (LSB).[24] The Gray-to-binary conversion uses an iterative exclusive-OR (XOR) operation, starting from the most significant bit (MSB, D1) to the least significant bit (LSB). The MSB of the binary output equals the corresponding Gray bit. For each subsequent bit position i, the binary bit is computed as the XOR of the Gray bit at i and the binary bit at position i-1. This successive XOR method, often implemented via repeated right-shift XORs for efficiency (e.g.,temp ^= (temp >> 1); temp ^= (temp >> 2); temp ^= (temp >> 4); temp ^= (temp >> 8);), reconstructs the binary equivalent while leveraging the Gray code's property of single-bit transitions between adjacent values.[25][24]
With the binary value b obtained (0 to 126), the 500-foot base altitude is calculated as:
\text{Altitude}_{500} = (b - 2) \times 500 \, \text{ft}
This yields the altitude rounded to the nearest 500 feet, ranging from -1,000 ft to 62,000 ft.[24]
To ensure data integrity, mirroring between the A and B bits is validated post-conversion. The B bits (B1, B2, B4) should correspond to a shifted or complemented version of the A bits (A1, A2, A4), specifically matching for even thousands of feet and inverting for odd thousands, as determined by the parity of the binary value from the 500-foot calculation. Mismatches indicate potential encoding errors.[24]
Additionally, the parity bit D4 provides error detection for the 500-foot bits. D4 is set to achieve even parity across A1, A2, A4, B1, B2, and B4; the XOR of these six bits should equal D4 such that the total XOR of all seven bits (including D4) is 0. A failed parity check signals transmission corruption, prompting rejection of the altitude data.[26]