Hubbry Logo
Gillham codeGillham codeMain
Open search
Gillham code
Community hub
Gillham code
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Gillham code
Gillham code
Gillham code
View on Wikipedia
from Wikipedia

Gillham code
Digits12
Tracks9..11[1][2]
Continuityno
Cyclicyes
Minimum distance1
Maximum distance1
Lexicographyno
A Cessna ARC RT-359A transponder (the beige box) in the instrument panel of an American Aviation AA-1 Yankee light aircraft. The transponder gets its altitude information from an encoding altimeter mounted behind the instrument panel that communicates via the Gillham code.

Gillham code is a zero-padded 12-bit binary code using a parallel nine-[1] to eleven-wire interface,[2] the Gillham interface, that is used to transmit uncorrected barometric altitude between an encoding altimeter or analog air data computer and a digital transponder. It is a modified form of a Gray code and is sometimes referred to simply as a "Gray code" in avionics literature.[3]

History

[edit]

The Gillham interface and code are an outgrowth of the 12-bit IFF Mark X system, which was introduced in the 1950s. The civil transponder interrogation modes A and C were defined in air traffic control (ATC) and secondary surveillance radar (SSR) in 1960.

The code is named after Ronald Lionel Gillham, a signals officer at Air Navigational Services, Ministry of Transport and Civil Aviation, who had been appointed a civil member of the Most Excellent Order of the British Empire (MBE) in the Queen's 1955 Birthday Honours.[4] He was the UK's representative to the International Air Transport Association (IATA) committee developing the specification for the second generation of air traffic control system, known in the UK as "Plan Ahead", and is said to have had the idea of using a modified Gray code.[nb 1] The final code variant was developed in late 1961[5] for the ICAO Communications Division meeting (VII COM) held in January/February 1962,[6] and described in a 1962 FAA report.[7][8][9] The exact timeframe and circumstances of the term Gillham code being coined are unclear, but by 1963 the code was already recognized under this name.[10][11] By the mid-1960s the code was also known as MOA–Gillham code[12] or ICAO–Gillham code. ARINC 572 specified the code as well in 1968.[13][14]

Once recommended by the ICAO for automatic height transmission for air traffic control purposes,[9][15] the interface is now discouraged[2] and has been mostly replaced by modern serial communication in newer aircraft.

Altitude encoder

[edit]
A typical altitude encoder, the ACK Technologies A-30. Note the 15-way D-type connector to send the Gillham code to the transponder and the port on the top of the case that connects to the aircraft's static pressure system.

An altitude encoder takes the form of a small metal box containing a pressure sensor and signal conditioning electronics.[16][17] The pressure sensor is often heated, which requires a warm-up time during which height information is either unavailable or inaccurate. Older style units can have a warm-up time of up to 10 minutes; more modern units warm up in less than 2 minutes. Some of the very latest encoders incorporate unheated 'instant on' type sensors. During the warm-up of older style units the height information may gradually increase until it settles at its final value. This is not normally a problem as the power would typically be applied before the aircraft enters the runway and so it would be transmitting correct height information soon after take-off.[18]

The encoder has an open-collector output, compatible with 14 V or 28 V electrical systems.[citation needed]

Coding

[edit]

The height information is represented as 11 binary digits in a parallel form using 11 separate lines designated D2 D4 A1 A2 A4 B1 B2 B4 C1 C2 C4.[3] As a twelfth bit, the Gillham code contains a D1 bit but this is unused and consequently set to zero in practical applications.

Different classes of altitude encoder do not use all of the available bits. All use the A, B and C bits; increasing altitude limits require more of the D bits. Up to and including 30700 ft does not require any of the D bits (9-wire interface[1]). This is suitable for most light general aviation aircraft. Up to and including 62700 ft requires D4 (10-wire interface[2]). Up to and including 126700 ft requires D4 and D2 (11-wire interface[2]). D1 is never used.[19][20]

Gillham binary code [D124 A124 B124 C124] Squawk octal code [ABCD] Height [m] Height [ft]
000 000 000 001 0040 −365.76 −1200
000 000 000 011 0060 −335.28 −1100
000 000 000 010 0020 −304.8 −1000
000 000 000 110 0030 −274.32 −900
000 000 000 100 0010 −243.84 −800
000 000 001 100 0410 −213.36 −700
000 000 001 110 0430 −182.88 −600
000 000 001 010 0420 −152.4 −500
000 000 001 011 0460 −121.92 −400
000 000 001 001 0440 −91.44 −300
000 000 011 001 0640 −60.96 −200
000 000 011 011 0660 −30.48 −100
000 000 011 010 0620 0 0
000 000 011 110 0630 30.48 100
000 000 011 100 0610 60.96 200
000 000 010 100 0210 91.44 300
000 000 010 110 0230 121.92 400
000 000 010 010 0220 152.4 500
000 000 010 011 0260 182.88 600
000 000 010 001 0240 213.36 700
000 000 110 001 0340 243.84 800
000 000 110 011 0360 274.32 900
000 000 110 010 0320 304.8 1000
000 000 110 110 0330 335.28 1100
000 000 110 100 0310 365.76 1200
000 000 111 100 0710 1300
000 000 111 110 0730 1400
000 000 111 010 0720 1500
000 000 111 011 0760 1600
000 000 111 001 0740 1700
000 000 101 001 0540 1800
000 000 101 011 0560 1900
000 000 101 010 0520 2000
000 000 101 110 0530 2100
000 000 101 100 0510 2200
000 000 100 100 0110 2300
000 000 100 110 0130 2400
000 000 100 010 0120 2500
000 000 100 011 0160 2600
000 000 100 001 0140 2700
… … … …
010 000 000 110 0032 126400
010 000 000 010 0022 126500
010 000 000 011 0062 126600
010 000 000 001 0042 126700

Decoding

[edit]

Bits D2 (msbit) through B4 (lsbit) encode the pressure altitude in 500 ft increments (above a base altitude of −1000±250 ft) in a standard 8-bit reflected binary code (Gray code).[19][21][22][23][24] The specification stops at code 1000000 (126500±250 ft), above which D1 would be needed as a most significant bit.

Bits C1, C2 and C4 use a mirrored 5-state 3-bit Gray BCD code of a Giannini Datex code type[12][25][26][27][28] (with the first 5 states resembling O'Brien code type II[29][5][23][24][27][28]) to encode the offset from the 500 ft altitude in 100 ft increments.[3] Specifically, if the parity of the 500 ft code is even then codes 001, 011, 010, 110 and 100 encode −200, −100, 0, +100 and +200 ft relative to the 500 ft altitude. If the parity is odd, the assignments are reversed.[19][21] Codes 000, 101 and 111 are not used.[30]: 13(6.17–21) 

The Gillham code can be decoded using various methods. Standard techniques use hardware[30] or software solutions. The latter often uses a lookup table but an algorithmic approach can be taken.[21]

See also

[edit]

Notes

[edit]

References

[edit]

Further reading

[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Gillham code

View on Grokipedia
from Grokipedia
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. 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. This binary code format ensures that only one bit changes per altitude step, minimizing errors during transmission. The code plays a critical role in systems, particularly for Mode C altitude reporting in and Traffic Alert and (TCAS) operations, where accurate altitude data is vital for maintaining aircraft separation and issuing resolution advisories. Standardized under 572, it has been a foundational element of technology since the mid-20th century, interfacing with legacy equipment via dedicated output pins on devices like airdata computers. 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. As a result, aviation authorities recommend avoiding its sole use in modern installations, favoring instead digital protocols such as with cross-verification from multiple altitude sources to enhance system integrity. Ongoing maintenance procedures, including static system tests and code verification tables, ensure its accuracy within ±125 feet during operational checks.

History and Development

Origins

The Gillham code emerged from the (IFF) Mark X system, developed in the mid-1950s primarily for identification during the 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 data, addressing the growing demands of post-war aviation surveillance. As international expanded in the late 1950s and early 1960s, efforts intensified to adapt military technologies for civilian use under the (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 systems, facilitating safer 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. 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 , who contributed significantly to its design as the UK's representative on the (IATA) committee tasked with Mode C specifications. The idea for the code was conceived during a dinner as a modified . 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. This timeline marked the code's evolution from military roots to a cornerstone of protocols.

Standardization

The (ICAO) adopted the Gillham code in the early 1960s as part of Mode C transponder specifications for automatic altitude transmission to enhance surveillance. This integration into ICAO Annex 10, Volume IV, defined the code as the standard for reporting in increments of 100 feet, ensuring global interoperability for systems. In 1968, the Aeronautical Radio, Incorporated () published specification ARINC 572, which formalized the 12-bit interface for altitude encoders, specifying the parallel wiring and signal characteristics for inputs. This standard complemented ICAO requirements by providing detailed engineering guidelines for implementation in air . ARINC 572 underwent revisions in the 1970s and 1980s, including ARINC 572-1, which refined wiring diagrams, interface tolerances, and integration with emerging systems to address reliability and compatibility issues in expanding fleets. These updates ensured the code's alignment with evolving aircraft electrical systems and technologies. By the 2000s, ICAO began discouraging the use of the due to its amid advances in digital , with the last major reference appearing in the 2009 amendments to Annex 10, Volume IV, favoring serial data protocols like for new installations.

System Overview

Purpose and Function

The serves as a digital encoding scheme that transmits uncorrected data from an aircraft's encoding to its (SSR) , enabling the inclusion of altitude information in Mode C replies. This uncorrected is referenced to the standard 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 . The code facilitates the relaying of this data as parallel binary signals to the , which then incorporates it into interrogation responses for transmission to (ATC) systems. In aviation operations, the primary function of the Gillham code is to support ATC in maintaining vertical separation between aircraft by providing real-time 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. 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. The system's integration within replies allows for automated altitude reporting during SSR interrogations, enhancing and collision avoidance without relying on voice communications. 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. This is critical for international , where discrepancies in local settings could otherwise compromise safety margins.

Altitude Encoding Basics

Gillham code employs a 12-bit binary format to digitally represent pressure altitude, with 11 active bits dedicated to encoding the altitude value and the D1 bit left unused and set to zero. This structure utilizes a modified scheme, where consecutive altitude values differ by only a single bit, enhancing error resistance in transmission over the parallel interface. The code is derived from encoding altimeters that measure based on relative to the standard datum of 29.92 inHg (1013.25 hPa). 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. 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. 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. This property is critical for maintaining reliable altitude reporting in systems, where accuracy directly impacts separation assurance.

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 connectors in systems. The altitude in 500-foot increments is encoded using an 8-bit reflected binary across the bits D2 (MSB), D4, A1, A2, A4, B1, B2, B4 (LSB). This Gray code represents the integer value of ( + 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. 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. 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.

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.

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. This Gray code ensures that only one bit changes between consecutive altitude values, minimizing errors during transmission over parallel wires. 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 nn, is then used in the formula Altitude500=(n×500)−1,000 ft\text{Altitude}_{500} = (n \times 500) - 1,000 \, \text{ft} where 0≤n≤1270 \leq n \leq 127. Low values of nn (e.g., n=0n = 0 for -1,000 ft) cover negative altitudes; the D1 bit is unused in standard implementations. 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 EquivalentnnAltitude (ft)
00000000000000000-1,000
00000001000000011-500
0001100000010000167,000
010000000111111112762,500

100-Foot Offsets

The 100-foot offsets in provide fine resolution to the altitude encoding, allowing adjustments in 100-foot increments from the base 500-foot level established by the 8-bit (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. The offset value is calculated as Offset = (C1 × 100 + C2 × 200 + C4 × 400) feet when the D2 bit (from the ) 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 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. 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.

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). 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). 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. With the binary value b obtained (0 to 126), the 500-foot base altitude is calculated as: Altitude500=(b−2)×500 ft\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. To ensure , 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. 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.

100-Foot Offsets Decoding

The 100-foot offsets in Gillham code are decoded by extracting the values from bits C1, C2, and C4, which form a mirrored 3-bit Gray BCD representation of the fine altitude adjustment within each 500-foot block. The offset value depends on the parity p (LSB of the 500-ft binary value): if p = 0 (even), the mappings are 001 (1) = 100 ft, 011 (3) = 300 ft, 101 (5) = 500 ft; if p = 1 (odd), the mappings are 000 (0) = 600 ft, 010 (2) = 0 ft, 100 (4) = 200 ft, 110 (6) = 400 ft. The code value is computed as code = 4 × C4 + 2 × C2 + C1. Combinations yielding code 7 (111) or unused codes (e.g., 101 or 011 when odd, 000 or 110 when even) are invalid and flagged as erroneous. This structure ensures single-bit changes for 100-ft steps while covering 0 to 600 ft offsets. The full altitude is obtained by combining the decoded 500-foot base (from bits D1, D2, A1, A2, A4, B1, B2, B4) with the offset: Total Altitude=Altitude500+Offset\text{Total Altitude} = \text{Altitude}_{500} + \text{Offset}. The maximum reportable altitude is capped at 62,500 feet, as higher values are not supported in standard Mode C implementations. For example, a base of 62,000 feet with an offset of 600 feet would be limited to 62,500 feet. Error handling during decoding focuses on invalid C1–C2–C4 patterns, such as code 7 (C1=1, C2=1, C4=1), which are flagged as erroneous since they do not correspond to valid Gillham encodings. Implementations often use lookup tables mapping the 8 possible C1–C2–C4 combinations (considering parity) to valid offsets, rejecting invalid entries to prevent faulty altitude reports and ensuring computational efficiency in hardware decoders.

Hardware Implementation

Altitude Encoders

Altitude encoders are compact electro-mechanical or solid-state devices that measure barometric altitude via a static port connected to a barometric capsule or sensor and convert this into Gillham code for transmission to transponders. These units are typically mounted near the 's primary to ensure accurate uncorrected readings, with dimensions often around 6 inches in length, 2.5 to 3 inches in width, and 1 to 2 inches in height, weighing approximately 5 to 11 ounces depending on the model. Power requirements for these encoders generally involve a 14- to 32-volt DC supply drawn from the aircraft's bus, with current draw ranging from 100 mA quiescent to 300 mA during operation, protected by a 2-ampere . Older models, such as the Shadin Avionics 8800 series, require a warm-up period of up to 10-12 minutes from cold temperatures to stabilize the pressure sensing element, while modern designs like the Sandia Aerospace SAE 5-35 feature innovative pressure circuitry that reduces warm-up to under 2 minutes or eliminates it entirely above 20°C. The output interface consists of open-collector, TTL-compatible parallel signals delivered over 9 to 11 active wires carrying the Gillham code bits, supplemented by ground, power, and sometimes strobe or serial lines, all connected via a standard 15-pin connector. This wiring configuration adheres to 575 specifications for the Gillham interface, ensuring compatibility with Mode C and Mode S transponders while providing 100-foot resolution altitude data from -1,000 to 35,000 feet or higher. Prominent manufacturers include ACK Technologies with the A-30 series, with the 8800 series, and with the SAE 5-35, all certified to FAA TSO C88a and RTCA DO-160 environmental standards for use.

Transponder Integration

is interfaced with transponders through a parallel wiring connection from the altitude encoder to the transponder's input buffer, typically using 11 discrete wires to transmit the 12-bit code (with one bit for sign). This interface employs open-collector or similar transistor-based outputs from the encoder, allowing direct connection to transponder inputs without additional buffering in many installations, and uses shielded cabling for runs longer than a few feet to minimize noise. The wiring follows standardized pin assignments, such as those on a 15-pin D-sub connector, where specific pins correspond to each Gillham bit (e.g., A1, B2, C1). Upon receiving an signal in Mode C, the reads the Gillham code bits from the input buffer and incorporates them directly into the reply frame's data block, occupying bits 1 through 12 to represent the . This process occurs in real-time during each interrogation cycle, with the transponder prioritizing parallel Gillham input over serial alternatives if both are present, ensuring the altitude data is transmitted without intermediate processing delays. The reply is formatted per ICAO Annex 10 standards, where the Gillham-encoded altitude is modulated onto the 1090 MHz carrier for reception. Gillham code integration is compatible with Mode A, C, and S transponders that support parallel altitude inputs, including models from manufacturers such as (e.g., GTX 320/327), (e.g., ATC 2000), and Avidyne (e.g., AXP340), provided the encoder meets TSO-C88a standards. For systems using serial data protocols like or (e.g., Icarus format at 9600 ), the parallel Gillham interface can be bypassed, allowing higher-resolution altitude reporting (e.g., 25-foot increments) in Mode S operations while maintaining . Verification of the integration is performed through ramp checks, where a certified encoder or test set simulates various altitudes (e.g., 0, 1,900, 3,500, and up to the aircraft's service ceiling such as 31,000 feet) by applying suction to the static system, and the transponder's output is compared to the indicated altitude on the pilot's for accuracy within ±125 feet. These tests, required under 14 CFR §§ 91.411 and 91.413, use Mode S or C test equipment to decode the reply and confirm proper bit transmission, often including checks for wiring integrity by monitoring individual lines. Post-installation functional checks ensure no ground loops or interference affect the parallel signals.

Limitations and Alternatives

Known Limitations

Gillham code systems are highly susceptible to errors due to their reliance on parallel binary signaling without built-in error detection or correction mechanisms. A single "stuck bit" failure, often caused by wiring faults or component degradation, can result in significant altitude misreads, potentially altering the reported value by thousands of feet and leading to incorrect Traffic Alert and Collision Avoidance System (TCAS) resolution advisories. Additionally, the code's inherent 100-foot resolution limits its precision compared to modern requirements, such as the 25-foot or finer increments needed for enhanced TCAS II performance, making it inadequate for applications demanding higher accuracy. The obsolescence of Gillham code stems from its parallel wiring architecture, which uses up to 11 discrete wires and is particularly vulnerable to and noise in contemporary aircraft environments equipped with advanced . This multi-wire setup increases the risk of signal corruption over long runs, a problem exacerbated in high-electrical-noise settings common in modern airframes. Furthermore, Gillham code is designed exclusively for barometric encoding and provides no interface for integrating GPS-derived altitudes, rendering it incompatible with current satellite-based navigation systems. Maintenance of Gillham code altitude encoders presents ongoing challenges, particularly in older units that require extended warm-up periods—sometimes up to 10 minutes—to stabilize before reliable output is achieved. drift over time is another common issue, as environmental factors and component aging can cause gradual inaccuracies in altitude reporting, necessitating frequent bench testing and adjustments to maintain compliance. Safety concerns with Gillham code have been highlighted by historical incidents involving transponder altitude errors, primarily due to wiring faults in single-input configurations. Prior to 2000, at least 11 such events were reported, where Mode C s transmitted erroneous altitudes, prompting near mid-air collisions and leading to FAA airworthiness directives mandating dual altitude sources for mitigation. These cases underscore the code's vulnerability to undetected failures, which can compromise separation and collision avoidance.

Modern Replacements

In modern aviation, serial digital protocols such as and have largely supplanted the parallel Gillham code for transmitting altitude data within , particularly in designs produced after 2010. , a unidirectional data bus standard, enables the transmission of via specific labels like 203 for barometric altitude, allowing integration with air data computers and other without the wiring complexity of parallel interfaces. Similarly, serial outputs are common in encoders, providing digital altitude streams alongside or in place of traditional Gray code for compatibility with GPS, autopilots, and transponders. Integrated systems, including those compliant with the 2020 ADS-B Out mandate from the FAA and ICAO regions, incorporate hybrid baro-altitude reporting derived from digital sources, often combining with GPS-derived geometric altitude for enhanced accuracy and surveillance. These systems, such as electronic flight instrument sets (EFIS) with built-in air data computers, output serial data directly to ADS-B transceivers, reducing reliance on dedicated Gillham encoders while maintaining barometric altitude for compatibility. The mandate requires ADS-B equipage in , driving adoption of these digital hybrids that report altitude integrity via codes like NICBARO to indicate source quality beyond basic Gillham encoding. For legacy aircraft, retrofit converter modules address the transition by converting serial digital altitude data to parallel Gillham code for older transponders that lack native serial inputs. Devices like the Dynon Encoder Converter Module or Sandia Z-16 ARINC 429 to Gray code interfaces enable this compatibility, allowing upgrades to modern air data systems without full transponder replacement. These solutions are particularly prevalent in general aviation, where cost-effective integration preserves existing Mode C functionality during phased upgrades. The shift toward fully digital altitude reporting continues in commercial fleets, with remaining a for new designs due to its reliability in high-speed data exchange across networks. While Gillham code persists in some older installations, ongoing ADS-B implementations and avionics modernization favor serial protocols, improving data precision and reducing installation complexity.

References

  1. https://www.faa.gov/documentLibrary/media/Advisory_Circular/AC_20-151C.pdf
  2. https://sandia.aero/wp-content/uploads/2023/06/SAC-7-35-Rev-F.pdf
  3. https://aviation.stackexchange.com/questions/72014/how-are-mode-2-pulses-encoded
  4. https://www.faa.gov/documentLibrary/media/Advisory_Circular/AC_43-6D.pdf
  5. https://www.govinfo.gov/content/pkg/FR-1999-11-12/pdf/99-29328.pdf
  6. https://euro-sd.com/2023/03/articles/30007/who-are-you/
  7. https://apps.dtic.mil/sti/tr/pdf/AD0694569.pdf
  8. https://bugs.freedesktop.org/attachment.cgi?id=50285
  9. https://www.easa.europa.eu/en/downloads/523/en
  10. https://www.govinfo.gov/content/pkg/FR-1999-11-12/html/99-29472.htm
  11. https://www.manualslib.com/manual/1959667/L-3-Communications-Skywatch-Hp-Sky899-Series.html?page=68
  12. https://www.easa.europa.eu/en/downloads/963/en
  13. https://www.faa.gov/documentLibrary/media/Advisory_Circular/AC%2043-6C.pdf
  14. https://www.spilve.lv/library/law/Annex%2010%20Volume%20IV.pdf
  15. https://support.michiganavionics.com/portal/en/kb/articles/transponder-gray-code-gillham-code-reference
  16. https://docs.lib.purdue.edu/cgi/viewcontent.cgi?article=1222&context=jate
  17. https://apps.dtic.mil/sti/tr/pdf/ADA196757.pdf
  18. https://patents.google.com/patent/US3487460A
  19. https://assets.mcico.com/assets/products/UsersGuides/MD23-215_ug.pdf
  20. https://www.redimec.com.ar/contenido/productos/pdf/1431090402_1.pdf
  21. https://fcc.report/FCC-ID/2ACTZMSS9019/4478020.pdf
  22. https://www.scribd.com/document/486773667/Ghilam-Code
  23. https://sandia.aero/wp-content/uploads/2014/07/Sandia-SAE-5-35-Installation-Manual.pdf
  24. https://www.ccsinfo.com/forum/viewtopic.php?p=140960
  25. https://www.allaboutcircuits.com/technical-articles/gray-code-basics/
  26. https://webthesis.biblio.polito.it/18301/1/tesi.pdf
  27. https://www.reddit.com/r/aviation/comments/a5b7ke/does_anybody_know_how_to_convert_gillham_graycode/
  28. https://sandia.aero/product/sae-5-35-altitude-encoder/
  29. http://www.ackavionics.com/wp-content/uploads/2018/03/A-30-MOD-9.pdf
  30. https://www.shadin.com/wp-content/uploads/2021/10/OP8800MC.pdf
  31. http://www.horntech.cn/techDocuments/ARINCTutorial.pdf
  32. https://www.logic-fruit.com/blog/arinc/arinc/
  33. https://mglavionics.co.za/Infinitec/Manuals/CNV-ALT.pdf
  34. https://www.avidyne.com/wp-content/uploads/2025/05/AXP340_STC_600-00308-000-Rev05.pdf
  35. https://www.faa.gov/documentLibrary/media/Advisory_Circular/AC_43-6C_CHG_1.pdf
  36. https://aviationconsumer.com/avionics/altitude-encoders-more-than-mode-c/
  37. https://aviationconsumer.com/uncategorized/altitude-encoders-transcal-sandia-prevail/
  38. https://www.pilotsofamerica.com/community/threads/altitude-encoding-errors-where-do-i-start-looking.109074/
  39. https://www.federalregister.gov/documents/2001/01/05/01-341/airworthiness-directives-various-transport-category-airplanes-equipped-with-certain-air-traffic
  40. https://thommen.aero/wp-content/uploads/2017/02/04_AD32_DEA80_DIGITAL-ENCODING-ALTIMETER_THOMMEN.pdf
  41. https://www.faa.gov/documentLibrary/media/Advisory_Circular/AC%252020-165.pdf
  42. https://www.dynonavionics.com/encoder-converter-module.php
  43. https://aviationconsumer.com/industry-news/editorial/altitude-encoders-cheaper-if-not-smaller/
  44. http://www.helitavia.com/avionics/TheAvionicsHandbook_Cap_2.pdf
Add your contribution
Related Hubs
User Avatar
No comments yet.