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

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

    Comment


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

      Comment


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

        Comment


        • #49
          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.
          http://www.liveatc.net/search/?icao=LSGG

          Comment


          • #50
            @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)

            Comment


            • #51
              Originally posted by solibra View Post
              @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?
              The VRATE scale only show positive values. It is possible that it went negative and went out of the chart boundaries.

              EDIT: Nope you're right, I checked the raw data and no VRATE data after the 0930Z mark
              Last edited by SolarLiner; 2015-03-28, 16:33.
              The A380 is my favorite local product.

              Comment


              • #52
                Originally posted by Charky View Post
                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.
                Well, the FR24 box is not a tamper-proof device itself. These are (semi) hobbyist equipment. I think adequate accuracy and certainty of data validity is reached by crossreferencing the GPS-timestamped data dumps at the FR24 central infrastructure end.

                External USB drive support would be nice, but it has to be built in a fashion where all forms of abuse (like USB stick removal) is handled gracefully - at least a reboot should recover the normal usage situation.

                Those of us who use the USB port to power the active antenna bias-T would need a passthrough USB cable. Power consumption of bias-T + USB-memorystick should be able to be handled with ease (NO spinning HD:s)

                Comment


                • #53
                  flight 4U9525.zip

                  I attach my version of Google Earth KML file for final trajectory, and the Excel Macro I used to obtain it from your raw data (thanks for them):

                  Code:
                  Const PM = "    <Placemark>" & vbCrLf & _
                          "<name></name>" & vbCrLf & _
                          "    <TimeStamp><when>2015-03-24T#timestamp#Z</when></TimeStamp>" & vbCrLf & _
                          "<LookAt>" & vbCrLf & _
                                  "<begin>2015-03-24T#begin#Z</begin>" & vbCrLf & _
                                  "<end>2015-03-24T#end#Z</end>" & vbCrLf & _
                              "<longitude>#lon#</longitude>" & vbCrLf & _
                              "<latitude>#lat#</latitude>" & vbCrLf & _
                              "<altitude>#alt#</altitude>" & vbCrLf & _
                              "<heading>#head#</heading>" & vbCrLf & _
                              "<tilt>65.15523262280593</tilt>" & vbCrLf & _
                              "<range>23315.45141798362</range>" & vbCrLf & _
                              "<gx:altitudeMode>absolute</gx:altitudeMode>" & vbCrLf & _
                          "</LookAt>" & vbCrLf & _
                          "<styleUrl>#msn_shaded_dot</styleUrl>" & vbCrLf & _
                          "<Point>" & vbCrLf & _
                              "<altitudeMode>absolute</altitudeMode>" & vbCrLf & _
                              "<coordinates>#lon#,#lat#,#alt#</coordinates>" & vbCrLf & _
                          "</Point>" & vbCrLf & _
                      "</Placemark>"
                      
                      
                  Const HEADER = "<?xml version=""1.0"" encoding=""UTF-8""?>" & vbCrLf & _
                  "<kml xmlns=""http://www.opengis.net/kml/2.2"" xmlns:gx=""http://www.google.com/kml/ext/2.2"" xmlns:kml=""http://www.opengis.net/kml/2.2"" xmlns:atom=""http://www.w3.org/2005/Atom"">" & vbCrLf & _
                  "<Document>  <name>esempio.kml</name>    <open>1</open>  <StyleMap id=""msn_shaded_dot"">" & vbCrLf & _
                          "<Pair>          <key>normal</key>           <styleUrl>#sn_shaded_dot</styleUrl>     </Pair>     <Pair>          <key>highlight</key>            <styleUrl>#sh_shaded_dot</styleUrl>" & vbCrLf & _
                          "</Pair> </StyleMap> <Style id=""sh_shaded_dot"">        <IconStyle>         <scale>0.466667</scale>         <Icon>              <href>http://maps.google.com/mapfiles/kml/shapes/shaded_dot.png</href>" & vbCrLf & _
                              "</Icon>     </IconStyle>        <ListStyle>     </ListStyle>    </Style>    <Style id=""sn_shaded_dot"">" & vbCrLf & _
                          "<IconStyle>         <scale>0.4</scale>          <Icon>              <href>http://maps.google.com/mapfiles/kml/shapes/shaded_dot.png</href>" & vbCrLf & _
                              "</Icon>     </IconStyle>        <ListStyle>     </ListStyle>    </Style>"
                      
                  Const FOOTER = "</Document></kml>"
                  
                      
                  
                      
                  Sub ProcessData()
                  Filename = "N:\Users\luca\Downloads\GWI18G_mode_s+adsb.txt"
                  OutFile2 = "N:\Users\luca\Downloads\out.txt"
                  OutFile3 = "N:\Users\luca\Downloads\out-metric.txt"
                  OutFile4 = "N:\Users\luca\Downloads\out-metric.kml"
                  Open Filename For Input As #1
                  Open OutFile2 For Output As #2
                  Open OutFile3 For Output As #3
                  Open OutFile4 For Output As #4
                  Print #4, HEADER
                      While Not EOF(1)
                          Tempo = "09:18:17"
                          Line Input #1, a$
                          Debug.Print vbCrLf & a$;
                          If InStr(a$, "TTRACK") > 0 Then
                              Heading = LTrim(Replace(Mid$(a$, InStr(a$, "TTRACK") + 7, 4), Chr(194), ""))
                          End If
                          If InStr(a$, "GWI18G") > 0 Then
                              TempoPrec = Tempo
                              Tempo = Mid$(a$, 1, 8)
                              Lat = Mid$(a$, 24, 8)
                              Lon = Mid$(a$, 34, 8)
                              lun = InStr(43, a$, ",") - 43
                              Quota = Mid$(a$, 43, lun)
                              KML_Line = Replace(PM, "#lat#", Lat)
                              KML_Line = Replace(KML_Line, "#lon#", Lon)
                              KML_Line = Replace(KML_Line, "#alt#", Quota * 0.3048)
                              KML_Line = Replace(KML_Line, "#head#", Heading)
                              KML_Line = Replace(KML_Line, "#begin#", TempoPrec)
                              KML_Line = Replace(KML_Line, "#end#", Tempo)
                              KML_Line = Replace(KML_Line, "#timestamp#", Tempo)
                              Print #2, Tempo, Lat, Lon, Quota
                              Print #3, Tempo, Lat, Lon, Quota * 0.3048
                              Print #4, KML_Line
                              Debug.Print "***"
                          End If
                      Wend
                  Print #4, FOOTER
                  Close #4
                  Close #3
                  Close #2
                  Close #1
                  
                  End Sub
                  Of course you must change the paths of the input and output files.

                  I wonder why media declare the plane crashed at 2600 meters, when it actually crashed 1100 meters lower and 3 km before the point visible in most pictures!

                  Real impact site:

                  http://www.gettyimages.it/detail/fot...naca/467431104

                  Media impact site:

                  Comment


                  • #54
                    Originally posted by Patrick Reeves View Post
                    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.
                    Was that a change of track (course) from the FO pulling the heading knob on the FCU or from the FMGS changing the course as set in the flight plan (ie, Lateral navigation in Managed mode)? If it's the former, then that has VERY significant ramifications, because it means the FO was following standard Emergency Descent procedures (due to depressurization).

                    Is there anyway the FR24 system can determine whether the FCU Heading had been changed?

                    Comment


                    • #55
                      Originally posted by SolarLiner View Post
                      The A380 is my favorite local product.
                      It's my favorite local product too! Even though i am from HAM and not TLS

                      Comment


                      • #56
                        Was that a change of track (course) from the FO pulling the heading knob on the FCU or from the FMGS
                        After replaying flight 4U9524 from 3/23/15, I think it was FMS- the heading changes from 42 to 24 in the same place. It's still odd because the descent begins immediately after the heading change and the news is now reporting that he used to visit the Alps very close to the crash site as a child.




                        http://www.flightradar24.com/2015-03...GWI18G/5d219f2
                        F-KDAG1

                        Comment


                        • #57
                          Originally posted by GMR234 View Post
                          Was that a change of track (course) from the FO pulling the heading knob on the FCU or from the FMGS changing the course as set in the flight plan (ie, Lateral navigation in Managed mode)?
                          The heading change to 25 dgr occurs just above the ADITA navaid. I think its fair to assume that this was part of their FMS flight plan. Also, as Patrick already noted, they were doing the same thing on previous flights.

                          I think the allegation that he planned to crash at this specific location is bollocks. First of all, south of France, especially Aix-en-Provence/Nizza is a very popular holiday destination for Germans. So the fact that he was there before means exactly nothing. Secondly, this theory would require not only psychotic but also psychic capabilities on the FO side (as in knowing at what moment of the flight the PIC would feel the urge to empty his bladder).
                          Last edited by solibra; 2015-03-28, 20:03.

                          Comment


                          • #58
                            Originally posted by NorthObserver View Post
                            Well, the FR24 box is not a tamper-proof device itself. These are (semi) hobbyist equipment. I think adequate accuracy and certainty of data validity is reached by crossreferencing the GPS-timestamped data dumps at the FR24 central infrastructure end.

                            External USB drive support would be nice, but it has to be built in a fashion where all forms of abuse (like USB stick removal) is handled gracefully - at least a reboot should recover the normal usage situation.

                            Those of us who use the USB port to power the active antenna bias-T would need a passthrough USB cable. Power consumption of bias-T + USB-memorystick should be able to be handled with ease (NO spinning HD:s)
                            As far as I am aware the use of active antennae's is not permitted on the FR24 box, you agree to operate it with the equipment supplied and nothing else unless they have given you specific permission.
                            Therefore the USB port should always be unused and such issues don't arise, however if you are a non 'F' feeder with your own equipment you can connect whatever you like.
                            Data security should also be a non-issue as it can be encrypted and timestamped.
                            Ben.
                            FR24 F-EGLF1, Blitzortung station 878, OGN Aldersht2, PilotAware PWAldersht, PlanePlotter M7.

                            Comment


                            • #59
                              After investigating the route which they took out of Barcelona, I have deduced that the airways they would have planned from LEBL to EDDL is via UN870 and UT853/T853.

                              The turning points along these airways, I assume are LEBL - DIBER SOSUR ROTIS MAXIR LUSOL IRMAR MOLUS PENDU IXILU GIVOR SORAL DIK ARCKY NOR - EDDL

                              Of course 4U 9525 never got any further than MAXIR, but it is after the waypoint at ROTIS that interests me.

                              The track from ROTIS to MAXIR is 043. If this was infact in the FMGS flight plan, and the aircraft was in managed NAV mode for lateral navigation when it crashed, then it would have stayed on this track during its descent.

                              If you look at the track from Flightradar 24, it's final track was actually 026. That is, it turned 17 degrees to the left from its assumed FMGS flight plan track, that's if the airways they intended to take is the one I have above.

                              If that's the case, then the FO pulled the heading on the FCU and set it to the left of track. This happened before the descent according to the raw data presented here, and this is consistent with standard emergency procedure (memory item procedure) for an emergency descent for the A320. This has substantial implications if true, because it could then suggest a sudden depressurization event occurred by which, the FO then took action as per the operating procedures for such an event.

                              Comment


                              • #60
                                Originally posted by F-EGLF1 View Post
                                As far as I am aware the use of active antennae's is not permitted on the FR24 box, you agree to operate it with the equipment supplied and nothing else unless they have given you specific permission.
                                Therefore the USB port should always be unused and such issues don't arise, however if you are a non 'F' feeder with your own equipment you can connect whatever you like.
                                Data security should also be a non-issue as it can be encrypted and timestamped.
                                Ben.
                                Yeah, my point was meant to those who operate Radarcape with Active Diapason antenna (10m cable prevents overloading issues..)

                                It would be nice if the full data buffering + extra storage -features could be available to Radarcape at some stage.

                                Comment

                                Working...
                                X