Go Back  PPRuNe Forums > Flight Deck Forums > Rumours & News
Reload this Page >

Turkish Airlines cargo 747 crashes in Kyrgyzstan

Rumours & News Reporting Points that may affect our jobs or lives as professional pilots. Also, items that may be of interest to professional pilots.

Turkish Airlines cargo 747 crashes in Kyrgyzstan

Old 19th Jan 2017, 17:30
  #181 (permalink)  
 
Join Date: Jan 2008
Location: Reading, UK
Posts: 14,627
Likes: 0
Received 29 Likes on 13 Posts
Originally Posted by peekay4 View Post
Well considering a fully-loaded 747 at 164 kts, to go from a -320 fpm descent to a +30,000 (!) fpm climb in 1.1 seconds isn't credible and might possibly violate a few laws of physics. So I think excluding the suspect data may be reasonable in this case.
Your healthy scepticism is commendable, but I fear you are applying it to the wrong elements of the data.

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.
DaveReidUK is online now  
Old 19th Jan 2017, 17:47
  #182 (permalink)  
 
Join Date: Jun 2001
Location: Rockytop, Tennessee, USA
Posts: 5,899
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by DaveReidUK View 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.
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.

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 18:49.
Airbubba is offline  
Old 19th Jan 2017, 17:49
  #183 (permalink)  
 
Join Date: Oct 1999
Location: LHR
Posts: 474
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.
Magplug is offline  
Old 19th Jan 2017, 18:58
  #184 (permalink)  
 
Join Date: Oct 2004
Location: California
Posts: 362
Likes: 0
Received 0 Likes on 0 Posts
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.
MarcK is offline  
Old 19th Jan 2017, 19:13
  #185 (permalink)  
 
Join Date: Feb 2007
Location: here and there
Age: 68
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.
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. press ok to exit. Finally tilt the image, from right hand side command bar (top) top arrow. HTH

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 19:20. Reason: addnl info & typo
vmandr is offline  
Old 19th Jan 2017, 19:33
  #186 (permalink)  
 
Join Date: Jan 2008
Location: Hotel Sheets, Downtown Plunketville
Age: 75
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.
Chronus is offline  
Old 19th Jan 2017, 19:39
  #187 (permalink)  
 
Join Date: Jun 2001
Location: Rockytop, Tennessee, USA
Posts: 5,899
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by vmandr View 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
Thanks for the tip, I appreciate it!

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:

The .csv data in the .xlsx file linked above shows a consistent track along the runway but when you display the corresponding .kmz file with Google Earth, the arrows seem to swing around as you zoom in and play with the tilt on my Windows based web browser. You zoom back out and the arrows line up with the runway once more.
Airbubba is offline  
Old 19th Jan 2017, 19:42
  #188 (permalink)  
 
Join Date: Jan 2008
Location: Reading, UK
Posts: 14,627
Likes: 0
Received 29 Likes on 13 Posts
Originally Posted by Airbubba View Post
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.
Well yes and no.

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 ...
DaveReidUK is online now  
Old 19th Jan 2017, 20:08
  #189 (permalink)  
 
Join Date: Jun 2001
Location: Rockytop, Tennessee, USA
Posts: 5,899
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by DaveReidUK View Post
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.
How about for someone like me who doesn't rightly understand this stuff?

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?
Airbubba is offline  
Old 19th Jan 2017, 20:37
  #190 (permalink)  
 
Join Date: Jan 2008
Location: Reading, UK
Posts: 14,627
Likes: 0
Received 29 Likes on 13 Posts
Originally Posted by Airbubba View Post
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?
No, it's much simpler than that.

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.
DaveReidUK is online now  
Old 19th Jan 2017, 21:19
  #191 (permalink)  
 
Join Date: Jun 2001
Location: Rockytop, Tennessee, USA
Posts: 5,899
Likes: 0
Received 0 Likes on 0 Posts
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.
Airbubba is offline  
Old 19th Jan 2017, 23:43
  #192 (permalink)  
 
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?
jack11111 is offline  
Old 20th Jan 2017, 01:14
  #193 (permalink)  
 
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?
Remember that the data stream is from multiple receivers with different (and non-constant) latencies to the server. So occasionally packets may arrive at the server in a different order from when they were originally transmitted.

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.
It's trivial to show that the last ~ 16 packets were not affected by reordering and that the max likely timestamp error for any packet would be 0.4 seconds.

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.
peekay4 is offline  
Old 20th Jan 2017, 01:59
  #194 (permalink)  
 
Join Date: Mar 2015
Location: Yekaterinburg
Posts: 3
Likes: 0
Received 0 Likes on 0 Posts
Maybe they wanted to get DME information on ND MAP and deselected FMC direct to. Should have chosen raw VOR on right for switching after passing the marker.
powtough is offline  
Old 20th Jan 2017, 07:43
  #195 (permalink)  
 
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.
The one engine we have seen so far from its front end has one fragment of one single fan blade left in the hub, all the others are gone. This should indicate that at least that engine was running at full power when it hit the ground.
Volume is offline  
Old 20th Jan 2017, 09:28
  #196 (permalink)  
 
Join Date: Jan 2008
Location: Reading, UK
Posts: 14,627
Likes: 0
Received 29 Likes on 13 Posts
Originally Posted by peekay4 View Post
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).
Not necessarily.

Originally Posted by peekay4 View Post
Remember that the data stream is from multiple receivers
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.
DaveReidUK is online now  
Old 20th Jan 2017, 10:49
  #197 (permalink)  
 
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.
Ian W is offline  
Old 20th Jan 2017, 10:56
  #198 (permalink)  
 
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.
No. Whatever altimeter setting is set for UI display does not affect the data sent to FR24.

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.
There is no timestamp on the actual ADS-B transmission.
peekay4 is offline  
Old 20th Jan 2017, 11:08
  #199 (permalink)  
 
Join Date: Jan 2008
Location: EFHK
Age: 52
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.
Andersin is offline  
Old 20th Jan 2017, 11:34
  #200 (permalink)  
 
Join Date: Aug 2000
Posts: 1,495
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.

Last edited by ManaAdaSystem; 20th Jan 2017 at 12:00.
ManaAdaSystem is offline  

Thread Tools
Search this Thread

Contact Us - Archive - Advertising - Cookie Policy - Privacy Statement - Terms of Service - Do Not Sell or Share My Personal Information

Copyright © 2023 MH Sub I, LLC dba Internet Brands. All rights reserved. Use of this site indicates your consent to the Terms of Use.