ATC and Mode C inaccuracy

[John Collins]

I typed 170 -- the original quote was 150

The transponder only sends pressure altitude with 100 foot precision, so the controller only sees 3000, 3100, 3200. Typically the encoder will jump to the next higher altitude corresponding to the 50 ft mark on the altimeter if they are in perfect correspondence. So assuming the altimeter reads 2950 to 3049, the encoder would read 3000, at 3050 to 3149 the encoder would read 3100 and so on. Of course one never has perfect correspondence between an altimeter and the encoder and mere mortals don't always fly at precisely the assigned altitude. So it is easy to be within IFR standards for holding altitude and to have an encoder reporting 200 ft off assigned altitude as this can be a result of a difference of only 50 ft in correspondence between the altimeter and encoder.

Most aircraft use a parallel encoder which transmits the altitude using a "gray" code. This is not the standard binary value sequence, 0000 0001 0010 0011 0100 0101 0110 0111 1000 1001 ... . In the gray code, only a single bit is allowed to change at any time when the altitude changes between two adjacent values. This is because if the encoder signal is sampled during the transition between altitudes, any bit that needs to change may be sampled as either a 1 or a 0 while in transition. So when a value of 0011 is changing to 0100, three of the four bits are changing at the same time, which means that any altitude that these three bits can represent may be read by the transponder and sent to ATC in error. The gray code solves this problem by only allowing one bit at a time to change when the altitude changes, so the gray code sequence is something like this for the same values represented by the regular binary sequence: 0000 0001 0011 0010 0110 0100 0101 0111 0110 0100 ... . This way the altitude reported will only be the original value or the new value and an erroneous value will not be reported.

Note: this is why when an encoder or transponder has a error that one of the signal lines being open or shorted, the reported altitude can be way off by several thousand feet.

 

[gismo]

FWIW, when there's a discrepancy between the controller's altitude readout of your airplane and your altimeter, the error could be in the altimeter and that's the primary reason I would have the two checked for correspondence. If the transmitted readout is jumping around it's clearly a problem with the encoder, transponder, or wiring between them but a relatively consistent difference could easily be an altimeter problem.

Also for those who don't already know this, the transponder sends pressure altitude with 100 ft resolution no matter what resolution your transponder has. The result of this is that even in a perfectly calibrated setup there can be a 50 ft difference and 150 is not uncommon. The correspondence check that's required every two years has much tigher tolerances than that to allow for some drift between checks.

 

[azure]

I'd have to look at the airplane logs to know when the transponder was last checked. I'm estimating that it's on average 150 feet off because we've frequently queried controllers about what our Mode C is reading, and it is always either 100 or 200 feet above indicated but never more or less, and goes from 100 feet to 200 feet above assigned when we are indicating somewhere between assigned and assigned + 50. So the difference between our Mode C and altimeter could be anywhere between 150 and 199 feet, but I'm confident it's not more than 200.

Our altimeter, on the other hand, was checked and recalibrated at last annual in October. I've noticed, though, that at home base with the on-field AWOS altimeter setting, the indicated altitude at the same spot on the field can vary over a range of about 20-30 feet and don't quite know what to make of that. Obviously, if the altimeter was indicating 30 feet high, it could mean that our Mode C was off by somewhat more than 200 feet. Most often, though, I suspect it's reading low, since in front of the hangar when I first copy the AWOS, it often reads 50 feet lower than the TDZE at the approach end of rwy 9, and I'm sure the difference in elevation can't be more than about 20 feet.

 

[flyingcheesehead]

edit: Folks, I mentioned the fact that he briefly started to descend us just for completeness. Yes, I told him last time that I thought it was a bad move. Now could we please not get hung up on this?

I think the reason we get hung up on this is that rocks, towers, and other obstacles don't care what your mode C readout is, and we like you here.

 

[gismo]

The transponder only sends pressure altitude with 100 foot precision, so the controller only sees 3000, 3100, 3200.

I'm curious about one thing here (sorry for the thread drift Liz). Given the altitudes reported by FlightAware are always an integral number of hundred feet I assume that's what's displayed on a controller's scope as well. And if that's true, it seems to me that the controller's altitude readout could be as much as 99.9 feet off from what the airplane's altimeter reads even if the altimeter and encoder are perfectly calibrated. The worst case scenario would be when the altimeter setting is something that would result in a pressure altitude that's an odd multiple of 50 ft different than the corrected altimeter reading e.g. about 29.42 inHg.

Combine that with 75 feet of allowable correspondence error plus a pilot deviation of 26 feet and there would be a 200 ft difference between the altimeter reading and the controller's display.

 

[gismo]

Our altimeter, on the other hand, was checked and recalibrated at last annual in October. I've noticed, though, that at home base with the on-field AWOS altimeter setting, the indicated altitude at the same spot on the field can vary over a range of about 20-30 feet and don't quite know what to make of that. Obviously, if the altimeter was indicating 30 feet high, it could mean that our Mode C was off by somewhat more than 200 feet. Most often, though, I suspect it's reading low, since in front of the hangar when I first copy the AWOS, it often reads 50 feet lower than the TDZE at the approach end of rwy 9, and I'm sure the difference in elevation can't be more than about 20 feet.

First, AFaIK the altimeter setting broadcast by an ASOS doesn't change more often than 15 minutes so if the pressure is raising rapidly your altimeter could indicate something a bit low unless the ASOS altimeter setting was just updated. I've seen this more often at towered airports with ATIS where the update is hourly most of the time.

Second, the ASOS isn't perfect either. I don't know what the specs say the tolerance is on the altimeter setting but it wouldn't surprise me if 20 feet was in tolerance.

 

[N801BH]

So what's the problem with Mode C that indicates 170' high?

Ya know.. I just have to ask.

I had my transponder/ pitot/ static system tested last Tues for its bi annual blessing. The tech, who travels to Jackson Hole and does several planes in one day to hold down costs said " Maximum allowable range is 125 feet off". Now it appears some guys here claim it is 200 feet. I did goggle it and I came up with the 125 number.... Which is it ?

Thanks in advance.

Ben.

 

[gismo]

Ya know.. I just have to ask.

I had my transponder/ pitot/ static system tested last Tues for its bi annual blessing. The tech, who travels to Jackson Hole and does several planes in one day to hold down costs said " Maximum allowable range is 125 feet off". Now it appears some guys here claim it is 200 feet. I did goggle it and I came up with the 125 number.... Which is it ?

Thanks in advance.

Ben.

AFaIK, 125 is the allowable deviation from the test set (and the test set can be off a little as well) but I also think that's up high and that the tolerance is less at low to mid altitudes. As I pointed out in my last post I believe that it's possible for the controller's readout to be almost 100 ft different than what the altimeter in the airplane reads if the correspondence between the altimeter and the encoder has zero error.

The other number that matters is what ATC policy allows and that's up to a 300 ft difference between the pilot's altimeter and the controller's readout. More offset than that and I believe that ATC is required to tell you to stop altitude squawk.

 

[azure]

I think the reason we get hung up on this is that rocks, towers, and other obstacles don't care what your mode C readout is, and we like you here.

I like being here too!

Trust me, I wouldn't get in a plane with him if I had the slightest reason to think he was so panic-prone that he might do something really dangerous, like risk a CFIT incident. We've always been at safe IFR altitudes or above whenever he's done this, and he knows the terrain around here so well I can't believe he'd ever go low enough that obstacle clearance would be an issue. There's also never been any IFR traffic below us that I'm aware of, though it's possible there could be traffic departing a nearby field IFR and not yet with Departure, or on a different frequency.

What I think he's doing is bending over backwards to accommodate the controller's concerns, thinking that if he doesn't, the controller might try to hit him with a trumped up pilot deviation. It's really ironic in a sad way, because I believe that going deliberately off altitude the way he does is the only thing he's done that could be used against him. I can't believe that a charge of altitude deviation based only on a Mode C readout could possibly stick, but once we've said we're at our assigned altitude and then they see the readout go down by 200 feet just as he's asking if this would be okay, and they haven't provided any clearance to do so, that's exactly what a controller who really wanted to deviate him would need.

 

[azure]

First, AFaIK the altimeter setting broadcast by an ASOS doesn't change more often than 15 minutes so if the pressure is raising rapidly your altimeter could indicate something a bit low unless the ASOS altimeter setting was just updated. I've seen this more often at towered airports with ATIS where the update is hourly most of the time.

Hmm, I never knew that about ASOS! I assumed it was a "live" readout and would change as soon as the pressure changed by 0.01". But I've never heard it change more often than 15 minutes either.

Second, the ASOS isn't perfect either. I don't know what the specs say the tolerance is on the altimeter setting but it wouldn't surprise me if 20 feet was in tolerance.

Yes, that was my first guess too. But I wonder whether the ASOS is subject to random error or only systematic error. Last month I flew to PTK and then returned home soon after takeoff from there because the wx was starting to deteriorate. I was away no more than about 75 minutes. When I left the altimeter was reading about 720 feet on the numbers at the approach end of 9, which is about 20 feet below surveyed elevation. When I returned I did one more run around the pattern and noticed that at the same place, it was reading over 750 (with the updated altimeter setting).

 

[Everskyward]

Hmm, I never knew that about ASOS! I assumed it was a "live" readout and would change as soon as the pressure changed by 0.01". But I've never heard it change more often than 15 minutes either.

ASOS changes more than once every 15 minutes. It actually changes every minute.

http://maps.avnwx.com/help/asos.html

Generally, they consist of a 20 to 30 second message updated each minute.

 

[gismo]

ASOS changes more than once every 15 minutes. It actually changes every minute.

http://maps.avnwx.com/help/asos.html

OK, I checked the specs and it does say that the SLP is updated every minute. I must have gotten the 15 minutes from the METAR issue rate. I also found that the design requirements call for an accuracy of +/-0.02 inHg which would allow for about 40 ft of variability and a maximum error of 20 ft. I also read that there are two or three pressure sensors per ASOS that get averaged and if one sensor is more than .04 inHg different than another the pressure value gets flagged.

And to answer Liz's question about the kinds of error, the pressure transducers would likely be fairly linear over a small change but most such transducers have some hysteresis (reading may differ depending on whether it's increasing or decreasing) and many also suffer from "sticktion" which means that the output value may advance less smoothly than a perfect sensor would.

 

[azure]

Generally, they consist of a 20 to 30 second message updated each minute.

Yup, I know that wx conditions are updated every minute, and assumed (until reading Lance's message) that the altimeter setting was updated as well. But I'm not actually sure and have never heard it change that frequently, even when the pressure was changing rapidly. I'd hope the altimeter was updated as needed along with the rest of the wx, of course.

 

[Everskyward]

Here's the math behind it if you can make heads or tails of it.

http://wahiduddin.net/calc/refs/ASOS_Pressure.htm

But the important part is this.

Once every minute, the current 1-minute average from the algorithm is used to obtain the reportable sea level pressure values and altimeter setting for use in the coded METAR observation.

 

[Areeda]

Liz, perhaps you could call Detroit Approach on the phone and discuss the procedure they would like you to follow in such a case. I think the phone number is (734) 955-5000.

I have called SoCal on occasion and they've been helpful.

Joe

 

[roncachamp]

The other number that matters is what ATC policy allows and that's up to a 300 ft difference between the pilot's altimeter and the controller's readout. More offset than that and I believe that ATC is required to tell you to stop altitude squawk.

The limit is 200 feet.

 

[azure]

Liz, perhaps you could call Detroit Approach on the phone and discuss the procedure they would like you to follow in such a case. I think the phone number is (734) 955-5000.

I have called SoCal on occasion and they've been helpful.

Joe

I've thought about doing that if it happens again, just to find out what the issue was and if they had any suggestions for us. Then I decided that since my CFII is PIC under IFR, I'd suggest it to him and leave it up to him. But I guess there's no reason I couldn't call without referencing a specific incident, for future reference as it were.

Thanks.

edit: I see today the plane is down because the panel is disassembled to replace the encoder. I guess it was too far off to be recalibrated, or they found some other issue with it yesterday.

 

[dmccormack]

I've thought about doing that if it happens again, just to find out what the issue was and if they had any suggestions for us. Then I decided that since my CFII is PIC under IFR, I'd suggest it to him and leave it up to him. But I guess there's no reason I couldn't call without referencing a specific incident, for future reference as it were.

I think the better approach to an ATC call is a hypothetical -- don't provide a call sign, and don't say "I was flying N1234 at 1430 on Tuesday when...."

 

[gismo]

The limit is 200 feet.

ICAO says "more than 300 ft" is a problem and 7110.65 says "varies less than 300 feet from the pilot reported altitude". I guess that if the pilot reports 4000 and your readout says 4300 you'd have to instruct the pilot to stop mode C. But what if the pilot's altimeter is actually showing 4030 ft? Do you expect pilots to report with more resolution than 100 ft in this case?

Also have you discovered that when the altimeter setting is close to XX.X7 the errors increase? My analysis shows that the inherent error increases to 100 ft in that case (it's 50 ft when the altimeter setting is 29.92 or 29.82).

Edit: Corrected the example altimeter settings

 

[SkyHog]

There's also never been any IFR traffic below us that I'm aware of, though it's possible there could be traffic departing a nearby field IFR and not yet with Departure, or on a different frequency.

I hate to harp on this, but what about VFR traffic? Remember, ATC has no obligation to separate an IFR plane from VFR traffic.

 

[roncachamp]

I hate to harp on this, but what about VFR traffic? Remember, ATC has no obligation to separate an IFR plane from VFR traffic.

Except in Class B airspace, Class C airspace, the Outer Area associated with Class C airspace, TRSAs, and on runways.

 

[azure]

I hate to harp on this, but what about VFR traffic? Remember, ATC has no obligation to separate an IFR plane from VFR traffic.

I can't speak to that since I'm under the hood, remember? But in IMC there shouldn't be any VFR traffic, and in VMC, he seems to already have nearly everything ATC points out, before they point it out. In other words, my impression is that he's a pretty eagle-eyed safety pilot.

 

[azure]

Also have you discovered that when the altimeter setting is close to XX.42 the errors increase? My analysis shows that the inherent error increases to 100 ft in that case (it's 50 ft when the altimeter setting is 29.92 or 30.92). [/FONT]

Err... I think you have a decimal point off in there. 0.5 inches Hg is 500 feet, not 50. It's 50 feet when the altimeter setting is 29.87 or 29.97.

 

[gismo]

Err... I think you have a decimal point off in there. 0.5 inches Hg is 500 feet, not 50. It's 50 feet when the altimeter setting is 29.87 or 29.97.

You're right I posted the wrong example altimeter settings. I meant to give XX.X7 (e.g. 29.87, 29.77 etc) for cases where the inherent error approaches 100 ft. And I suspect that when you get very far from 29.92 the worst case setting doesn't end in .X7 since the one inHg isn't exactly 1000 ft of altitude.