Announcement

Collapse
No announcement yet.

We have analysed the raw data from the transponder of #4U9525 and found some more dat

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • aligot
    replied
    @solibra: can you share with us the tools you use for parsing & graphing? Nice work!

    Leave a comment:


  • F-EGLF1
    replied
    Is there any way to improve the raw data buffering on the FR24 boxes? Would it help to plug a usb memory stick in? If so what capacity and how should it be formatted? (FAT, FAT32, NTFS etc)
    If this is not currently supported then could it be implemented in the next firmware update?
    I am sure many who host the boxes would be happy to do this.
    Ben.

    Leave a comment:


  • NorthObserver
    replied
    Originally posted by Mike View Post
    We normally never upload this data to FR24 as it would consume too much data traffic for hosts (and for us). But after MH370 we learned that the raw data could have a very big value afterwards, and since live uploading of the raw data is not an option, we store it in the FR24 receiver for as long as possible. Depending on coverage we can store last received data for about 4-10 hours. If something happens we can go back and download the data from a receiver, and this is what we did with the receivers near 4U9525 when we heard about the accident.

    As the data cannot be easily identified it took us almost 2 days to make the analysis and find the autopilot data.
    As this type of information could be really, _really_ important on accident investigation, it should be considered that local buffering of full transponder data
    and on-request hold / release for analysis purposes should be implemented by all ADS-B monitoring device / software manufcturers. Hobbyist ADS-B monitoring
    is a bit gray area in many countries. This kind of accident analysis support could help making hobbyist ADS-B monitoring activity more accepted to the authorities.

    Some development ideas:
    -support development of the receiver base (other than already supperted FR24/Radarcape) to provide GPS-timestamped data
    -encourage local buffering of the full feed to the internal memory maximum of the receiver platform
    -mechanism for FR24 to request a hold and dump of all stored data frames of a spesific HEX (this might be a type of request that would require an OK by the
    receiver owner for the data to be delivered, the release request could contain a reasoning for the request)

    Spesifically related to Radarcape..as the hardware base is very similar / identical to the FR24 receiver, this type of full feed buffering and HEX-based release request
    should be quite easy to implement. Maybe something to consider together with FR24 and Radarcape?

    I really would like to see crowdsourced ADS-B monitoring to be universally accepted from legislation point of view. Internet aviation enthusiast community has already proven to provide valuable data. There are also other areas where crowdsourced sensor networks could provide added value: weather monitoring and thunderstorm detection are good examples.

    Leave a comment:


  • Mike
    replied
    @solibra Very nice visualization of the data!

    Leave a comment:


  • solibra
    replied
    @Mike, if you are not too busy giving interviews to CNN could you maybe check the 4th/5th data subfield in the BDS40h message register? Like from any BDS40h message around 09:33. This would tell which vertical mode was engaged on the autopilot (V/S, EXPEDIATE, OPEN DESCENT,etc).
    BDS40h
    MCP MODE (A320):
    bit-48 STATUS OF MCP MODE BITS
    bit-49 MANAGED VERTICAL MODE
    bit-50 ALT HOLD MODE
    bit-51 APPROACH MODE

    ALTITUDE SOURCE:
    bit-54 STATUS OF ALT SOURCE BITS
    bit-55
    --- I --- = 2-bit value
    bit-56

    Leave a comment:


  • solibra
    replied
    @Mike, so awesome that you shared the transponder raw data with us. I parsed the ADS-B and Mode-S streams to a database and visualized the data in the chart below.
    Last edited by solibra; 2015-03-28, 03:48.

    Leave a comment:


  • Patrick Reeves
    replied
    I extracted the course change and corresponding ALT data:

    09:18:19Z.244 ROLL: 0R TTRACK: 66 TAS: 458kt 30000
    09:21:11Z.791 ROLL: 0R TTRACK: 42 TAS: 446kt 32075
    09:30:15Z.542 ROLL: 0L TTRACK: 41 TAS: 448kt 38000
    09:30:20Z.539 ROLL: 0L TTRACK: 40 TAS: 450kt 38000
    09:30:22Z.831 ROLL: 0L TTRACK: 39 TAS: 450kt 38000
    09:30:25Z.545 ROLL: 0L TTRACK: 38 TAS: 450kt 38000
    09:30:27Z.756 ROLL: 0L TTRACK: 37 TAS: 450kt 38000
    09:30:32Z.682 ROLL: 0L TTRACK: 36 TAS: 450kt 38000
    09:30:36Z.513 ROLL: 0L TTRACK: 34 TAS: 450kt 38000
    09:30:40Z.295 ROLL: 0L TTRACK: 33 TAS: 452kt 38000
    09:30:42Z.535 ROLL: 0L TTRACK: 32 TAS: 450kt 38000
    09:30:47Z.461 ROLL: 0L TTRACK: 30 TAS: 450kt 38000
    09:30:50Z.559 ROLL: 0L TTRACK: 29 TAS: 452kt 38000
    09:30:55Z.570 ROLL: 0L TTRACK: 28 TAS: 450kt 38025
    09:30:57Z.311 ROLL: 0L TTRACK: 27 TAS: 450kt 38025
    09:30:59Z.248 ROLL: 0L TTRACK: 26 TAS: 450kt 38000
    09:31:07Z.164 ROLL: 0L TTRACK: 25 TAS: 450kt 37950
    09:34:24Z.063 ROLL: 0R TTRACK: 26 TAS: 446kt 28050
    09:34:40Z.358 ROLL: 0L TTRACK: 25 TAS: 450kt 26875
    09:36:15Z.159 ROLL: 0R TTRACK: 26 TAS: 458kt 20350
    09:38:17Z.046 ROLL: 0L TTRACK: 26 TAS: 414kt 13700


    If your a data wonk, this is interesting.

    This is a summary of 247 ttrack records
    Last edited by Patrick Reeves; 2015-03-28, 00:15. Reason: add text

    Leave a comment:


  • Gerald
    replied
    How is it possible that a co pilot is authorized to change manual the altitude from 38000 ft to 13.000 ft to 96 ft leading to the middle of an alp in three seconds by his own? Why not authorized this strange pattern by head pilot or ATC is restricted?

    Leave a comment:


  • Patrick Reeves
    replied
    09:30:17Z.905 ROLL: 0L TTRACK: 41 TAS: 450kt

    The autopilot initiated a course change from 420to 250 30 seconds before ALT was manually changed.

    New course of 250 was achieved as AC began descent.


    09:38:17Z.046 ROLL: 0L TTRACK: 26

    last ttrack data transmit at 13700 ft.

    Leave a comment:


  • twellington
    replied
    thanks for providing this analysis
    FCYYC2 @can_kiwi

    Leave a comment:


  • Charky
    replied
    thanks, Mike.
    to you and your analysts. You all did a good but timeconsuming job

    Leave a comment:


  • bmn
    replied
    @Mike the altitude in the kml file for the placemarks seems incorrect. For example at the highest point it's listed as 3800 meters in stead of 38000 feet. So there seems to be a zero missing and it is in Meters in stead of Feet. The other placemarks seem to be affected as well.
    Just wanted to let you know, thanks for all the data and effort, it's much appreciated!

    Leave a comment:


  • Mike
    replied
    I have attached .kml file with full ADS-B data of flight 4U9525
    5d42675.kml
    Alternative link https://dl.dropboxusercontent.com/u/5175572/5d42675.kml

    and .txt file with ADS-B + ModeS data of flight 4U9525 with MACH, IAS, TAS, ROLL, VRATE
    GWI18G_mode_s+adsb.txt
    Alternative link https://dl.dropboxusercontent.com/u/...e_s%2Badsb.txt
    Please note that we are only 99% sure that IAS data has been correctly decoded.

    Leave a comment:


  • Patrick Reeves
    replied
    Originally posted by henningz View Post
    He needed two seconds (actually three) to turn the button on the autopilot from 38000 ft to zero...



    The MODE switch would be turned clockwise to 1000 (if it wasn't already selected), the ALT dial would be turned counter clockwise 2 times, landing on 13008ft during the first twist, then 100ft on the second. No doubt this is being replicated in a simulator somewhere.

    Leave a comment:


  • jumpjack
    replied
    Using "raw" data (*) taken from this site, I was able to reconstruct following 3d scene, which can be downloaded as a Google Earth KML file:



    Looking closer, it looks like there's a discrepancy between expectdc impact site and actual impact site, which could lead to think to a final attempt to regain altitude:


    But it can also depend on too coarse and approximate data. If exact altitude, longitude, latitude and time (with seconds) was available, I could reconstruct a much more precise scene.



    (*) click on chart, write down altitude&speed, click on other point, write down,... and eventually grabbing data from HTML sources and manually converting them to suitable format...

    Leave a comment:

Working...
X