Turkish Airlines cargo 747 crashes in Kyrgyzstan
Hint: Look back at the last 50 seconds of flight as plotted in the Additional Decoded ADS-B Data. Count how many points there are during those 50 seconds where the aircraft appears to be flying backwards (i.e. east). Then think about what in the dataset might be causing that to (apparently) happen.
Join Date: Jun 2001
Location: Rockytop, Tennessee, USA
Posts: 5,898
Likes: 0
Received 1 Like
on
1 Post
Hint: Look back at the last 50 seconds of flight as plotted in the Additional Decoded ADS-B Data. Count how many points there are during those 50 seconds where the aircraft appears to be flying backwards (i.e. east). Then think about what in the dataset might be causing that to (apparently) happen.
https://blog.flightradar24.com/blog/...ta-TK6491.xlsx
It will open as a spreadsheet and you can see that the track is consistently about 260 degrees.
For some reason, when you open a .kml file with Google Earth, the little arrows seem to swing around in unison sometimes as you zoom in and zoom out.
Last edited by Airbubba; 19th Jan 2017 at 17:49.
Join Date: Oct 1999
Location: LHR
Posts: 556
Likes: 0
Received 0 Likes
on
0 Posts
@Kulverstukas:
Your image shows a constant descent from published platform altitude of 3400' (1400' AAL), NOT evidence of a 'TOGA Fail' remaining in 'Flare' mode as incorrectly suggested by aviator17.
The altitude component of ADSB is based on pressure altitude. It's certainly possible that damage to the pressure altitude reporting system occurred during the last two data points.
Join Date: Feb 2007
Location: here and there
Age: 69
Posts: 76
Likes: 0
Received 0 Likes
on
0 Posts
For some reason, when you open a .kml file with Google Earth, the little arrows seem to swing around in unison sometimes as you zoom in and zoom out.
for the additional ponts from fr24 xls file. you must create the points and then 'extend to ground' in altitude tab.
UCFM-TK6491-path.jpg
Last edited by vmandr; 19th Jan 2017 at 18:20. Reason: addnl info & typo
Join Date: Jan 2008
Location: Hotel Sheets, Downtown Plunketville
Age: 76
Posts: 0
Likes: 0
Received 0 Likes
on
0 Posts
As it seems rather unlikely that the whole mass of the aircraft could have assumed the characteristics of a ballistic missile. If the final ADS-B spike is coincidental with the impact point, could the transmissions be resultant from impact forces acting on systems, instruments and equipment. Perhaps someone with good knowledge of ADS-B architecture may explain the likely signal emission from an event where the system does is not disabled instantaneously along with the whole airframe.
Join Date: Jun 2001
Location: Rockytop, Tennessee, USA
Posts: 5,898
Likes: 0
Received 1 Like
on
1 Post
if you need to see the vertical profile, as in the file below, just right-click the kml file on google earth, properties, stye/color tab, click share style button. then on altitude tab click the checkbox 'exntend to ground'. after that, back to style/color tab and change colors etc. pres ok to exit. Finally tilt the image, from right hand side command bar (top) top arrow. HTH
Attachment 1630
Attachment 1630
What I think maybe what Dave was looking at was the way the little blue track arrows swing around off course in lemme's Google Earth rendering of the additional ADS-B data:
Here's a previously posted link to the 'additional' data:
https://blog.flightradar24.com/blog/...ta-TK6491.xlsx
It will open as a spreadsheet and you can see that the track is consistently about 260 degrees.
https://blog.flightradar24.com/blog/...ta-TK6491.xlsx
It will open as a spreadsheet and you can see that the track is consistently about 260 degrees.
Certainly if you look at the 130 or so transmissions from the aircraft in those last 50 seconds that specify track, groundspeed and Vrate, they all show a consistent track of around 260°. After all, you would expect the aircraft to know which direction it's moving in.
But if you try to plot the similar number of position reports in chronological order, you will find several points where the implied track is reversed such that the aircraft appears to be moving briefly eastwards.
The reason for that isn't hard to work out for anyone who understands how FR24 and ADS-B work, and it should ring alarm bells with anyone who is thinking of trying to derive second-order parameters (not just track) from the sequence of static data points.
Unfortunately it doesn't seem to have ...
Join Date: Jun 2001
Location: Rockytop, Tennessee, USA
Posts: 5,898
Likes: 0
Received 1 Like
on
1 Post
Can you explain what you are saying down on my level?
Are you saying jitter or quantization in the received ADS-B data is such that subsequent changes in position may indicate erroneous rates and accelerations unless some form of smoothing or filtering is done?
The data, as received from the aircraft (lat/lon, altitude, track, groundspeed, Vrate), is basically good.
So you can be pretty confident that a plot of, say, altitude or groundspeed vs position will be accurate.
The problem is that the chronological order in which FR24 lists the data doesn't necessarily match the order in which it was transmitted (those thousandth-of-a-second precision timestamps that FR24 shows are nonsense and haven't originated from the aircraft). So, for an aircraft that's on final approach on a constant track, out-of-sync position reports will typically manifest themselves as a spurious 180° change in track, as is apparent in the TK6491 data at 01:16:37 and 01:16:55, for example.
It follows that if one tries to use those unreliable timestamps to derive second-order parameters, it's asking for trouble, as in that absurd "33,000 ft/min" climb rate that several posters have quoted.
Join Date: Jun 2001
Location: Rockytop, Tennessee, USA
Posts: 5,898
Likes: 0
Received 1 Like
on
1 Post
That makes sense, if the ADS-B positions are timestamped (in Unix Epoch time 
) by the FR24 servers when they are received, changes in network latency could reorder things.
) by the FR24 servers when they are received, changes in network latency could reorder things.
Join Date: Oct 2012
Location: SF Bay area, CA USA
Posts: 254
Likes: 0
Received 0 Likes
on
0 Posts
Time stamping
When receiving GPS signals you have a very accurate universal time reference. Would that not be used to stamp the ADS-B output meaning received order would not be limiting?
Join Date: Sep 2014
Location: Canada
Posts: 1,257
Likes: 0
Received 0 Likes
on
0 Posts
When receiving GPS signals you have a very accurate universal time reference. Would that not be used to stamp the ADS-B output meaning received order would not be limiting?
It follows that if one tries to use those unreliable timestamps to derive second-order parameters, it's asking for trouble, as in that absurd "33,000 ft/min" climb rate that several posters have quoted.
Even if we conservatively double the possible timestamp error, the bounds for vertical rate for the last few data points is still between 17,000 fpm and 30,000 fpm. Not physically realistic.
And even if we ignore the timestamps completely, we also have space constraints. The lat/long and altitude data shows the aircraft climbing at least 500 ft in altitude in about 350 ft horizontal distance (conservatively assuming 50 ft of ADS-B altitude errors due to granularity).
That means the aircraft achieved a 55 degree up vertical flight path in less than twice the aircraft's on length. Again not physically realistic.
Join Date: Dec 2001
Location: what U.S. calls Žold EuropeŽ
Posts: 941
Likes: 0
Received 0 Likes
on
0 Posts
Certainly the investigators have seen the engines by now and know what power they were at when they hit the ground.
And even if we ignore the timestamps completely, we also have space constraints. The lat/long and altitude data shows the aircraft climbing at least 500 ft in altitude in about 350 ft horizontal distance (conservatively assuming 50 ft of ADS-B altitude errors due to granularity).
Exactly. And not just multiple receivers, but very possibly multiple receiver types. FlightRadar24 allows feeders to use their own choice of hardware. Often when FR24 publish data, they include a "source" column so we can tell which data came from which feeder, but unfortunately they haven't in this instance.
Why does that matter? Because some ADS-B receiver/software combinations allow users to make their own pressure altitude correction by plugging a QNH value into the processing software. When the data gets to the FR24 server, it has no way of knowing whether or not this correction has been applied (let alone whether it was based on an accurate, currrent QNH) and so it gets published verbatim.
Obviously we know that many of the values in the dataset are uncorrected (because some of the heights are below the runway elevation). But to assume that all the values need to be adjusted by the same amount may well be wrong. A bit like the assumption that all the timestamps were correct, in fact.
Join Date: Dec 2006
Location: Florida and wherever my laptop is
Posts: 1,350
Likes: 0
Received 0 Likes
on
0 Posts
The timestamp on the actual ADS-B transmission from the aircraft transponder is the time that the position being sent was generated in the aircraft avionics. The timestamps are like that so out of sequence transmission receipts can be rebuilt by the air traffic management systems . I am not sure what FR24 / Flight Aware and others do with received ADS-B data from the amateur networks they use.
Join Date: Sep 2014
Location: Canada
Posts: 1,257
Likes: 0
Received 0 Likes
on
0 Posts
Because some ADS-B receiver/software combinations allow users to make their own pressure altitude correction by plugging a QNH value into the processing software. When the data gets to the FR24 server, it has no way of knowing whether or not this correction has been applied (let alone whether it was based on an accurate, currrent QNH) and so it gets published verbatim.
Depending on the setup, the FR24 feeder either controls the ADS-B receiver directly (e.g., via USB) or receives ADS-B traffic via two different protocols (SBS or Beast). Both protocols simply pass transmitted Mode C altitudes, not corrected altitudes.
The timestamp on the actual ADS-B transmission from the aircraft transponder is the time that the position being sent was generated in the aircraft avionics.
Join Date: Jan 2008
Location: EFHK
Age: 53
Posts: 3
Likes: 0
Received 0 Likes
on
0 Posts
Looking the last two fr24 data points, the lat/lon values seems to be ok. The logical explanation for steep climb could be a crash damage to the pitot/static port system.
Also if the altitude data would be correct, that would mean that the speed would have approximately doubled in less than 2 seconds.
Also if the altitude data would be correct, that would mean that the speed would have approximately doubled in less than 2 seconds.
Join Date: Aug 2000
Posts: 1,501
Likes: 0
Received 0 Likes
on
0 Posts
Seriuosly, are you guys relying on FR24 data for the last part of the approach?
FR24 is notoriously unreliable for this phase.
Just try any random flight on FR24 into an airport (any airport apart from the major ones where coverage is presumably very good). Select 3D view and watch the appoach and landing.
Most of the time you will see an aircraft drifting left and right during the approach. Then the aircraft appears to go high on the profile. It may look like they are going around. It then will dropp (1 second) straight down onto the runway, followed by a landing roll sometimes on the runway, sometimes off the runway.
This happens 90 % of the time.
Try it.
Then imagine how this would look if somebody tried to use this data to analyze an accident.
FR24 is notoriously unreliable for this phase.
Just try any random flight on FR24 into an airport (any airport apart from the major ones where coverage is presumably very good). Select 3D view and watch the appoach and landing.
Most of the time you will see an aircraft drifting left and right during the approach. Then the aircraft appears to go high on the profile. It may look like they are going around. It then will dropp (1 second) straight down onto the runway, followed by a landing roll sometimes on the runway, sometimes off the runway.
This happens 90 % of the time.
Try it.
Then imagine how this would look if somebody tried to use this data to analyze an accident.
Last edited by ManaAdaSystem; 20th Jan 2017 at 11:00.