Page 8 of 8 FirstFirst ... 678
Results 71 to 76 of 76

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

  1. #71
    Super Moderator
    Join Date
    May 2011
    Location
    T-NZCH1, PP:PH New Zealand
    Posts
    5,046
    You have to wonder if this was made based on the data released here, or if infact we will see some backed up info confirming it..

    On Apr 3rd 2015 the French BEA reported that the flight data recorder was received by the BEA on Apr 2nd 2015, it was opened and a first read out of the data showed, that the pilot in the cockpit used the autopilot to descend the aircraft down to 100 feet, on several occasions the speed of the aircraft was adjusted during the descent.

  2. #72
    Captain
    Join Date
    Apr 2010
    Location
    FR24 Feeder
    Posts
    1,232
    The Flight is 'PINNED' on this page for safe keeping.
    http://www.flightradar24.com/data/pinned/

    Quote Originally Posted by HeicoH View Post
    Is it possible to "freeze" 4U9525 at March 24 in the database? IMHO, it does not make sense to display "data" of flights after March 24 which did never occur using this flight number, but a lot of Internet sites, including Wikipedia, link to FR24 because of the published data of 4U9525 on March 24.

  3. #73
    First officer
    Join Date
    Mar 2015
    Location
    T-KSJC28
    Posts
    335
    FDR has been found and supports the data extracted by FR24 through the radio signals.
    Congratulations again to FR24 that the data corresponds to the flight data recorder. I.E. FR24 published the first data that showed that a pilot intentionally changed the autopilot down to less than 100 feet.

    This has been recently verified by the data reported by the investigators who found the actual flight data recorder.
    Congratulations again to the FR24 team for being the first to know that is what happened before the FDR was found.
    Last edited by Sam26K; 2015-04-05 at 10:08.

  4. #74
    Passenger TrentXWB's Avatar
    Join Date
    Oct 2011
    Posts
    4
    A small explanation.
    Among all transponders flying above our heads we can find 3 different specification families:
    + Do260: The older one, these transponders are the majority of transponders airborne today.
    + Do260A: An enhancement of the previous one where additionnal parameters (such as FCU altitude,....) are broadcasted
    + Do260B: The latest specification (fitted basically on A380, A350 and some other Airbuses by retrofit) with different parameters regarding GPS signal quality.

    GermanWings aircrafts are fitted with Do-260B transponders. Analysis of the raw data broadcasted shows that Selected FCU altitude is located inside a specific BDS (4.0 I think) at a regluar rate.
    Then pilot action on FCU altitude knob can be precisely known and then compared to data stored inside the DFDR.

  5. #75
    First officer
    Join Date
    Mar 2015
    Location
    T-KSJC28
    Posts
    335
    Thanks for that explanation. Not surprising that a German airline would upgrade to the best transponders even under a "budget" airline's name.
    All commercial airlines should be required to carry the 'B' transponder version as soon as possible.

    I don't blame Lufthansa for this disaster. It's not a simple thing to prevent a suicidal pilot and it's not the first time that has happened. My prayers are with the Airline and especially the families affected.
    Last edited by Sam26K; 2015-04-09 at 07:35.

  6. #76
    Team FR24 Mike's Avatar
    Join Date
    Feb 2010
    Location
    Sweden
    Posts
    3,110
    Quote Originally Posted by NorthObserver View Post
    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.
    I don't have the information about how Radarcape is handling the raw data but I will check with Gunther.

  7. #77
    Team FR24 Mike's Avatar
    Join Date
    Feb 2010
    Location
    Sweden
    Posts
    3,110
    Quote Originally Posted by F-EGLF1 View Post
    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.
    In the beginning I think we tried to store the data on the SD-card inside the receiver but the card is not made for repeated writing. Some of the first 200 receivers we had to switch SD cards because of SD card issues. Today the data is stored in memory which storage amount of course is limited. We will add some packing of the data that should make it possible to extend the amount of data we save.

    USB sticks probably have a similar issue as SD cards I suspect, repeated writing at some point destroys the stick. But maybe we will do a test.

  8. #78
    Passenger
    Join Date
    Mar 2014
    Location
    Belgium
    Posts
    21
    Quote Originally Posted by Mike View Post
    USB sticks probably have a similar issue as SD cards I suspect, repeated writing at some point destroys the stick.
    Avoid usb sticks or sd cards, they're not designed to be rewritten many times. And if they break - and they will - they do so beyond repair. Stick to plain sata ssd or - if space is a constraint - to msata ssd, or whichever is the cheapest to buy in. I'm an ICT manager (not selling), contact me if you think I can help.

Posting Permissions

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