Light aircraft down near McKinlay, Qld
I know of one event on ADSB that showed 500’ out from what actually occurred. Im sure that there are many others.
The most likely reason for that would be due to the ADSB feed being based on a QNH of 1013.2.
I don't know how good ADSB data is but presumably if it's good enough to determine that there was in fact a turn to the left at event onset, then the data must be pretty good.
The following users liked this post:
The ADSB feed from the recent SR22 accident was super detailed. Posters here were posting speed, altitude, graphs, heading and a graphical representation of the flight path. That’s presumably based on FR24 ADSB receivers and not the ASA ones… I presume someone may know, they may be able to provide more detailed info.
IIRC, the ADS-B squit (transmission) is 2Hz, so if you can recieve it, you can build a very detailed 3D picture of the flightpath. And from that, if you have the right software, in some cases you can derive the FCU selected or commanded modes from the relevant data. Such detailed info isn't always displayed on FR24 or FA, but it is there a lot of the time. For example, from a PC-12 overflying our hacienda right now we have:
Hopefully we’ll get some answers sooner rather than later.
RIP to the 3 crew
If it was a training exercise, surely the trainer would have intervened long before the stall.
TUC at 28,000 ft is 2.5 to 3 minutes… given some people can march up Everest without oxygen, that 3 minute number is probably (rightfully) on the conservative side.
I would assume the 695 has a cabin altitude alert together with a chime should the cabin altitude exceed something like 10,000 which makes it hard to believe the crew failed to recognize a surreptitious depressurisation.
Not a lot makes sense with this incident. Structural failure? But in all likelihood it was smooth air up at FL280, so that rules it out.
TUC at 28,000 ft is 2.5 to 3 minutes… given some people can march up Everest without oxygen, that 3 minute number is probably (rightfully) on the conservative side.
I would assume the 695 has a cabin altitude alert together with a chime should the cabin altitude exceed something like 10,000 which makes it hard to believe the crew failed to recognize a surreptitious depressurisation.
Not a lot makes sense with this incident. Structural failure? But in all likelihood it was smooth air up at FL280, so that rules it out.
The following users liked this post:
From a training perspective, because we so diligently brief our pilots about the exercise we are about to do, there's an expectation that it will unfold as planned. You can tell how often it doesn't by the finger print marks around the freeze button in the sim lol. We know it as human factors.
TUC at 28,000 ft is 2.5 to 3 minutes… given some people can march up Everest without oxygen, that 3 minute number is probably (rightfully) on the conservative side.
There's a difference. The people who "march up" Everest spend several days, if not weeks, working up to higher altitudes and thus become acclimatized. They don't go up there at ~1000 fpm.
The following users liked this post:
Like all electronic trickery these days, Garbage In = Garbage Out. When it comes to baro readings, a faulty sender can very easily indicate something significantly different to GPS altitude with the folks on the light deck none the wiser... one reason both are sent in an ADS-B feed.
a) what has been done to the data since it came from the aircraft
b) what sensor input is fed into the ADS-B output
For a), all public data sources I'm aware of are adulterating the data in some form or another. They either interpolate data between known positions/altitudes/speeds, and lead you to believe that those points in-between are true, when in fact they are estimated. FR24 is particularly guilty of that to create a smooth web browser flight tracking experience. Their internal data resolution is 5 seconds, but on the website, the positions update a couple of times per second. That means 20 positions you're following as "real" are educated guesses. Now you know.
For b), you can read up on this in the standards document RTCA DO-260B that defines the ADS-B standard, and in DO-181E defining the ATCRBS/Mode S Airborne equipment standard.
ADS-B / Mode S ES (extended squitter) transmissions are taking place at a staggering rate. Some messages like state vector reports (altitude, speed, position) are broadcast up to 50 times per second, while operational status reports such as the callsign are broadcast only once per second, and additional information messages that may contain autoflight/FMC configuration information, indicated airspeed, and atmospheric parameters are broadcast only every few seconds and only when interrogated by an ATS system (i.e. a ground based radar) wanting to know that information. That's why in FlyRealTraffic.com's radar screens for example, you see data from suitably equipped aircraft flying in radar coverage in Australia and Europe showing the autopilot modes as well as current IAS, TAS, wind vector and outside temperature, while the same aircraft flying in the US will often only show the autopilot modes but no weather information - because ATS are not requesting the weather info in the US.
Flight tracking services are aggregating that information into snapshots, in the case of FR24 in 5s intervals, in the case of FlyRealTraffic.com in 2s intervals. So if you see a target in your web browser with many different parameters, those parameters are not all true at that particular point in time. They're a mish mash of parameters *around* that time. And some may be well out of date.
The most basic errors pprune users often make pertain to the basic information provided:
- Altitude is always from a barometric source, and always reported to standard pressure, i.e. it's a FL that's being reported. The resolution is bit encoding limited to 25ft.
- vertical speed has its own message that is often transmitted at an even higher rate than altitude and position. So a particular VS may be completely separate from the reported altitude.
- Position, track, and speed are always in reference to the ground and broadcast in an "Airborne position message". In normal ops they are directly fed from the GNSS systems, but in IRS equipped aircraft, the IRS is used as an automatic failover source should GNSS be U/S. The "type" subfield code in the DF (downlink format) 17 or 18 messages tells the receiver to what horizontal containment radius limit (Rc) the position is known - that's similar to an RNP parameter. So if the GNSS receiver has failed and the aircraft is using IRS navigation, that parameter will be updated with the estimated position uncertainty from the FMC. An Rc of 9 means better than 7.5 meters. An Rc of 17 means better than 20NM. You get the drift. Yet you won't find that parameter in any flight tracking website derived ADS-B feed.
So when "investigating" an accident from afar based on ADS-B data, you have to keep all these factors in mind. There may be faulty input that leads to faulty ADS-B data - garbage in, garbage out. There may be "hanging" data fields in the ADS-B data providers feed, data that is stale and no longer applicable at the particular point in time.
Use the data by all means to try and make sense of what happened, but use it with caution.
The following 3 users liked this post by physicus:
The following users liked this post:
I'd say that's pretty basic error from a pprune user right there!!
No, PiperCameron that is incorrect. The altitude in the ADS-B message is *always* in reference to 1013.25 hPa. And the reason is exactly as you state: A falsely set QNH on the altimeter would then report the wrong altitude. This way, ALL aircraft are reporting to the same pressure level.
Here a screenshot from RTCA DO-260B defining what altitude shall be reported:
Here a screenshot from RTCA DO-260B defining what altitude shall be reported:
I remember when the first mode charlie transponders where being offered to unpressurized bug smashers were self contained units, most altimeters weren't capable of providing that information, so the unit had its own pressure referencing output. It makes sense that it would be referencing standard pressure. In any case we are only talking 300 feet.
That’s a big mistake PC and you need to get your head around that for future discussion.
The QNH that you are entering into your altimeter via the dial is in no way linked to the transponder.
The reason the transponder reports based on 1013.2 (as noted in the post above) is so that ATC knows exactly what your altitude is, as the ATC system does the conversion at their end based on the current area QNH. Therefore if you have incorrectly set the QNH or not set it at all on your dial, or you’re on a long flight and have moved into a different pressure system, then they will still know pretty much your exact height.
This explains why if you’re watching your ADSB-IN feed from your EFB you may notice someone zipping along at 200 ft across an area where the buildings are bigger than that, because their OUT is in Barometric pressure and Flight Radar 24 isn’t smart enough to know the area QNH for the conversion.
My EFB shows me traffic with a +003 next to it for example so that the QNH is never an issue as I simply know that the other aircraft is 300ft above me. That’s a clever way to do it as if it said 3,500 and you thought you were at 3,200 but your QNH was wrong you’ll be in the poo.
This safety measure assumes that you’re diligently getting your transponder serviced every 2 years and it’s maintained it’s calibration between servicing.
The QNH that you are entering into your altimeter via the dial is in no way linked to the transponder.
The reason the transponder reports based on 1013.2 (as noted in the post above) is so that ATC knows exactly what your altitude is, as the ATC system does the conversion at their end based on the current area QNH. Therefore if you have incorrectly set the QNH or not set it at all on your dial, or you’re on a long flight and have moved into a different pressure system, then they will still know pretty much your exact height.
This explains why if you’re watching your ADSB-IN feed from your EFB you may notice someone zipping along at 200 ft across an area where the buildings are bigger than that, because their OUT is in Barometric pressure and Flight Radar 24 isn’t smart enough to know the area QNH for the conversion.
My EFB shows me traffic with a +003 next to it for example so that the QNH is never an issue as I simply know that the other aircraft is 300ft above me. That’s a clever way to do it as if it said 3,500 and you thought you were at 3,200 but your QNH was wrong you’ll be in the poo.
This safety measure assumes that you’re diligently getting your transponder serviced every 2 years and it’s maintained it’s calibration between servicing.