I worked on ATC software development in the infancy of ADS-B, I haven't been involved for sometime but -
LFRT posted the raw ADS-B data recorded by FR24 and others.
Following is all the ADS-B data i could gather from 1642 to 1721 UTC :
255 cue points with time, altitude and speed data (and discontinued lat/long, climb rate and squawk data).
.
.
.
SOURCES/METHOD USED :
- "FR24 Gr" = FlightRadar24 graph (MH370 - Malaysia Airlines - Flight history - Flightradar24). The raw figures (time, alt & speed) for the 185 cue points of the FR24 graph are included in the page's source code, all i had to do was grab them and translate them in the right units.
- "FR24 Pn" = FlightRadar24 "pinned" page (same url). The data you get each time you press the FWD button. Adds location and heading to some of the 185 "FR24 Gr" points.
- "GE" = Google Earth. For the first "FR24 Pn" points (just after takeoff, in the 327° straight line), i got the lat and long data from Google Earth. Presumably it can be done with every other "FR24 Pn" cue point, that's why i marked their missing lat/long data with a "*"
- "FR24 Pb" = FlightRadar24 "playback" page (Flightradar24.com - Live flight tracker!). Oddly enough, the points are not the same as in the "pinned" page. And these ones also include the climb rate, the squawk and the data feeder (registered ADS-B receiver which the data came from)
- "FA" = FlightAware data (Registre de suivi des vols ? MAS370 ? 08-03-2014 ? WMKK / KUL - ZBAA / PEK ? FlightAware). No squawk data on this one, and some minor discrepancies when compared to FR24 heading and velocity data.
- "PF" = PlaneFinder. 3 additional cue points, still better than nothing.
Once all this data collected, i ordered them by growing altitude until FL350, and adjusted the remaining cue points, based on their timestamp (feel free to interpolate the points where seconds are replaced by XX).
T[UTC];LAT[°];LONG[°];HDG[°];ALT[ft];SPD[kts];RoC[ft/mn];Squawk;ADS-B feeder;Data Source
.
.
.
17:20:22;;;;35000;471;;;;FR24 Gr
17:20:33;;;;35000;471;;;;FR24 Gr
17:20:49;;;;35000;471;;;;FR24 Gr
17:20:XX;6,9300;103,5900;040;0;471;0;2157;F-WMKC1;FR24 Pb
17:21:XX;6,9700;103,6300;040;0;471;0;2157;F-WMKC1;FR24 Pb
I am assuming that the raw data presented reflects directly what was received by the ADS-b ground station.
It is the last two transmissions that I find of interest.
ADS-b data is primarily derived from GPS, however there is a requirement that the altitude data should correspond to that displayed to the pilot, so at cruise it will be pressure altitude.
I believe that because of this requirement the altitude data is not generated in the ADS-b equipment, but provided externally via a data bus from the pressure altimeter/FMC?.
The last two ADS-b transmission do not have any altitude data (it has presumably been set to zero as there is no valid data).
All previous messages contained credible altitude data.
IMHO there is no physical control that would enable just a single field of an ADS-b message to be selectively suppressed and even if there was for what purpose?
If, as seems to be accepted, the SSR/ADS-b was disabled by someone on the flight deck, how was suppression of altitude data accomplished?
The other possibility is of course that the source of the pressure altitude (altimeter/FMC?) failed / was disabled just before the SSR/ADS-b.
So T7 pilots/MX'ers
Is there some way to suppress altitude output? and if so why would someone want to do that when he is disabling the SSR/ADS-b.
Why wouldn't the ADS-b switch to an alternate altimeter, or is a manual input required?
Are the SSR/ADS-b and pressure altimeter on the same CB?
What would be the consequences of losing all pressure altimeters?