Page 5 of 8 FirstFirst ... 34567 ... LastLast
Results 41 to 50 of 76

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

  1. #41
    Passenger
    Join Date
    Mar 2015
    Posts
    1
    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?

  2. #42
    Purser
    Join Date
    Mar 2015
    Location
    Mojave Desert, USA
    Posts
    133
    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 at 00:15. Reason: add text
    F-KDAG1

  3. #43
    Passenger
    Join Date
    Mar 2015
    Posts
    8
    @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 at 03:48.

  4. #44
    Passenger
    Join Date
    Mar 2015
    Posts
    8
    @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

  5. #45
    Team FR24 Mike's Avatar
    Join Date
    Feb 2010
    Location
    Sweden
    Posts
    3,110
    @solibra Very nice visualization of the data!

  6. #46
    Passenger
    Join Date
    Mar 2015
    Posts
    9
    Quote 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.

  7. #47
    First officer
    Join Date
    Feb 2014
    Location
    Aldershot, Hampshire. UK
    Posts
    252
    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.
    FR24 F-EGLF1, Blitzortung station 878, OGN Aldersht2, PilotAware PWAldersht, PlanePlotter M7.

  8. #48
    Passenger
    Join Date
    Mar 2015
    Posts
    2
    @solibra: can you share with us the tools you use for parsing & graphing? Nice work!

  9. #49
    First officer
    Join Date
    Apr 2010
    Posts
    262
    I think it is ok to store this kind of data inside the box/sdcard (encrypted?). If you store it "outside" like on an USB-device the data could be changed easily and you might lose confidence.

  10. #50
    Passenger
    Join Date
    Mar 2015
    Posts
    8
    @Mike, it seems a bit strange that as soon as the aircraft descends VRATE is not reported anymore. There should be negative rates there.
    Are you sure that the VRATE subfield in the BDS60h register packets after 09:30:50 is not populated during the entire 10 minutes of descend?

    @aligot Python script + plot.ly API (They have a web app too)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •