No announcement yet.

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

  • Filter
  • Time
  • Show
Clear All
new posts

  • #76
    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 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.


    • #77
      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.
      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.


      • #78
        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.