Why Mode S Transponders Give Wrong Altitude Readings

What Mode S Actually Reports and Where It Comes From

Mode S altitude reporting has gotten complicated with all the misinformation flying around. Most pilots assume a wrong altitude readout means a broken transponder. It usually doesn’t. The transponder is faithfully repeating whatever the altitude encoder feeds it — and that distinction matters more than most briefings ever mention.

So here’s the actual setup. Your altimeter shows indicated altitude — the reading on the dial, adjusted for local QNH. Your altitude encoder is a completely separate box. Its only job is converting that needle position into electrical signals the transponder can broadcast. What shows up on ATC scopes and flight trackers as your Mode S altitude? That’s the encoder’s output. Not the altimeter. The encoder.

Think of it like a translator at a conference. The speaker knows exactly what they’re saying. But if the translator mishears one word, the audience walks away with bad information — and the speaker was never the problem. That’s the relationship between your altimeter and your encoder. One can be perfectly accurate while the other quietly sends garbage upstream.

That’s what makes this particular failure mode so endearing to us troubleshooters. A 50-foot altimeter drift produces a 50-foot Mode S drift — clean, predictable, easy to spot. An encoder fault produces something far stranger. Random jumps. Impossible altitudes. Numbers that make no sense against what the pilot is actually reading.

The Gillham Code Problem Most Pilots Never Hear About

Inside every altitude encoder lives something called Gillham code. In essence, it’s a modified Gray code — a binary encoding system transmitting altitude in 100-foot increments across nineteen separate wires to the transponder. Each wire is either on or off. Each combination of on/off states maps to a specific altitude. But it’s much more than that.

Gillham’s original design built in redundancy so single bit errors wouldn’t cascade into catastrophic misreadings. Mostly works. When it fails, though, it fails spectacularly.

Here’s a concrete example. Say your encoder is supposed to report 5,000 feet — a specific pattern across those nineteen wires. Now one wire corrodes. Just one contact, degrading slowly. Sometimes it connects. Sometimes it doesn’t. The transponder starts receiving inconsistent signals. Occasionally a bit flips that shouldn’t.

That single corrupted bit can shift reported altitude by thousands of feet. I watched this happen to a Beechcraft Baron at my home field — a 2003 B58 with just under 3,400 hours on the airframe. The pilot was sitting at 6,500 feet by his altimeter. ADS-B Exchange showed him bouncing between 6,200 and 9,100 feet in random jumps. Not a steady offset. Not a gentle drift. Hard jumps, several times per minute. A failing solder joint on one altitude transmission line was the whole problem.

Fixing it meant replacing the entire encoder unit. Around $2,400 with installation at our shop. One bad connection. That was it.

Don’t make my mistake — I initially assumed the transponder itself had failed and nearly authorized swapping the whole Garmin GTX 345 before someone smarter caught it during bench testing. The really insidious part is that Mode C altitude readouts often check out fine on the ground. The failure is intermittent. Temperature changes, vibration, power load variations — any of these can open or close that marginal contact. It only misbehaves in the air, under conditions ground testing never replicates.

Pressure Settings and Why QNH Mismatches Cause Confusion

Mode S transponders transmit pressure altitude. Always. That means altitude calculated using 1013.25 millibars as the reference — not your local QNH setting, not whatever you’ve dialed into your Kollsman window.

Your altimeter respects your local QNH. The transponder doesn’t. So when you’re at what your altimeter reads as 10,000 feet with QNH set to 29.75 inches, the transponder is quietly reporting something closer to 10,200 feet. Nothing is broken. The system is doing exactly what the design spec says. But it looks wrong to anyone on the ground who isn’t accounting for the pressure reference difference.

That’s what makes this endearing to ground observers watching ADS-B Exchange — they see your transponder altitude, compare it to your filed altitude, and assume something has gone wrong. It hasn’t. They just missed the pressure reference in the footnotes.

The bigger issue shows up mid-flight. Flying from a high-pressure system into a low-pressure system, the discrepancy between your indicated altitude and your transponder altitude can swing 300 feet or more over a few hours. Totally normal behavior. Completely bizarre-looking on a tracker with no context.

How to Tell If the Problem Is the Encoder, the Transponder, or the Data Feed

Diagnosing Mode S altitude errors means separating three distinct failure modes. Probably should have opened with this section, honestly.

First, check whether the discrepancy is a consistent offset. Always 150 feet high? Always 300 feet low? That’s encoder calibration drift or an altimeter needing service. Slow, steady, predictable. Call your avionics shop and schedule a ramp check — it’s not an emergency, but it needs fixing before your next IFR flight.

Second, watch for random jumps. Altitude bouncing unpredictably is classic Gillham code corruption or a failing encoder contact. That’s the Baron scenario. The altitude being reported to ATC is unreliable. Ground the aircraft and schedule immediate maintenance — this isn’t a “monitor it” situation.

Third, look at whether the discrepancy only appears on certain trackers. If ADS-B Exchange shows one altitude and FlightRadar24 shows something different, you’re probably seeing the gap between raw data and filtered data. Many tracking platforms apply local QNH corrections or smoothing algorithms on top of the raw transponder output. The transponder is fine. The tracker is doing math on top of it.

You can verify this by pulling raw ADS-B message data from a local receiver — an RTL-SDR dongle running dump1090 costs about $28 and will show you exactly what your encoder is broadcasting before any site-level processing touches it. The encoder outputs what it outputs. Everything downstream is interpretation.

What Pilots and Controllers Actually Do When Altitude Looks Wrong

ATC doesn’t trust Mode S altitude in isolation. A report comes in, and controllers immediately cross-reference it against primary radar returns, TCAS alerts from surrounding traffic, and verbal pilot readbacks. Two of three sources disagree — they start asking questions.

I was on a visual approach into a Class C once when my Mode C was showing 4,200 feet on the scope while my altimeter read 5,000 feet. Another aircraft’s TCAS was agreeing with my altimeter. The controller asked me to verify my altitude. I read back 5,000 feet. He sequenced the other traffic around me and flagged my transponder as suspect. After shutdown I called my avionics contact — the encoder had drifted and needed recalibration. $400 flat, done in an afternoon, offset completely gone.

If your transponder’s altitude looks suspicious, the fastest diagnostic is a Mode C ramp test. An avionics tester plugs in, steps through a range of simulated altitudes, and verifies the encoder’s output against the altimeter reading at each increment. The test takes about an hour. Runs around $150 at most shops. It tells you definitively whether you’re dealing with encoder drift, a Gillham code fault, or something else entirely.

Mode S altitude errors stop being mysteries once you’ve separated the three potential culprits — the encoder hardware, the Gillham code transmission, and the pressure reference gap between indicated and pressure altitude. I’m apparently someone who had to learn this the expensive way, and the Baron story convinced me to run ramp tests annually whether the squawk looks clean or not. Identify which failure mode you’re actually dealing with, and you’ve solved half the problem before you’ve touched a single wire.