It is going to be whatever the Mode C altitude squawk is, which is pressure altitude (29.92), or so I would think. ADSB could be reporting GPS altitude though, not sure. Interesting question though, as I do see a lot of tracks reporting exactly 34000 feet (or whatever), which is no surprise given most airliners are going to be on autopilot with altitude hold during the encounter phase of flight.
All the references I’ve seen say pressure altitude. I am very new to this, though, so it’s possible I’m not looking at the right references. As to the exactly 34000, it’s likely there’s some rounding going on. I haven’t seen anything more precise than 25 feet. And I think the format allows for less precision.
I would think it would be pressure altitude as well; however, altitudes do change for me when the planes are closer to the ground. I also took a plane on approach into KORD who was told to maintain 7000 for the approach. He indicated 7275. I took the KMDW altimeter setting (the closest to the A/C) and did the math: 29.92-29.64=.28. That means the A/C’s altimeter should be indicating 280’ above what it is actually at. So in other words, it measures the aircraft at 29.92. So to figure out what the A/C is actually at in MSL (ASL), you need to do the math every time. I think my math checks out, but if anyone else knows better, let me know! Thanks!
The local altimeter setting. Transponders squawk pressure altitude though, uncorrected for local baro, and ATC computers apply the appropriate offset to the track to display “MSL” on their scopes.
My weather station console is literally inches away from my Raspberry Pi. Seems like something should be possible. If I had the time and inclination, I might come up with something. Really, it should be done in PiAware, though, I think. It could periodically poll nearby airports for current pressure…
There’s probably a better way to dump the XML info but for one or two variables, it’s not worth the time required to code a script to extract them all. If I had to do more than 3 or so, I would write a script for it.
OK - quick explanation of the technology involved (in small aircraft):
Transponder - this is the box in the plane sending data to the ground
Blind Encoder - this is the box in the plane which converts the pressure sensed by the static ports on the plane to an altitude referenced to 29.92"Hg (standard pressure)
The transponder can’t work out the altitude itself and doesn’t take GPS altitude. It needs the altitude to be fed from the “blind encoder”.
Below 18,000ft a local pressure adjustment is issued that is used by aircraft in that local area. Above 18,000ft all aircraft in the USA set their altimeters to 29.92"Hg so when planes are high in cruise you are very likely to see exact altitudes which are dead on XX,000ft.
Blind encoders vary in the resolution they provide. Good encoders provide resolution down to 10ft. With better avionics, you can get down to 1ft resolution. It looks to me that there is rounding to the nearest 25’.
As I said at the start, that is a little explanation of the system in a light aircraft - the principles apply to the larger aircraft although the avionics are more complicated.
A.1.4.2.4 Altitude
This 12-bit field (ME bits 9 – 20, Message bits 41 – 52) will provide the aircraft altitude.
Depending on the TYPE Code, this field will contain either:
Barometric altitude encoded in 25 or 100 foot increments (as indicated by the Q Bit)
or,
GNSS height above ellipsoid (HAE).
Note: GNSS altitude MSL is not accurate enough for use in the position report.
I’m not sure if dump1090 even looks at the different reporting types, but I don’t know of any reason an airplane would be reporting GNSS HAE and not baro… maybe supersonic? I’m still not clear on if this section is referencing the Mode-S data or if it’s part of the Extended Squitter block. Dump1090 reports the Mode-S portion.