Announcement

Collapse
No announcement yet.

How does MLAT timing work without GPS?

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

  • How does MLAT timing work without GPS?

    MLAT relies the time difference of arrival from various modes messages based on the speed of light. To compute this time difference requires extremely precise timing between the various base stations.

    Traditionally, MLAT calculations have used the timing signal from GPS satellites to precisely determine the time of arrival. However, the new Fr24 pi software does not need GPS to participate in MLAT calculations. I understand that users need to input their own coordinates - no issue there - but how is the timing so precisely computed? There must be a timing signal coming from somewhere?

  • #2
    ...and I managed to answer my own question. NTP (Network Time Protocol) together with an ADS-B reference aircraft. Makes sense.
    Last edited by davedlg; 2017-07-10, 22:05.

    Comment


    • #3
      yep. Been a few in-depth discussion on it. While some providers use it to calculations, fr seem to use it as a reference point only to assist where their own feed boxes are lacking in numbers

      Sent from my XT1092 using Tapatalk
      Posts not to be taken as official support representation - Just a helpful uploader who tinkers

      Comment


      • #4
        Timing is done with ADS-B aircraft as reference. NTP is far, far to bad to be used for MLAT.

        Comment


        • #5
          Originally posted by Mike View Post
          Timing is done with ADS-B aircraft as reference. NTP is far, far to bad to be used for MLAT.
          Thanks Mike

          Can you confirm that Raspberry PI feeders (T-xxxx) are ACTUALLY used for MLAT calculations alongside Flightradar24 own feeders (F-xxxx)?

          Comment


          • #6
            Yes, if you are running the latest software and it says on status screen that MLAT is running.

            Comment


            • #7
              Originally posted by Mike View Post
              Yes, if you are running the latest software and it says on status screen that MLAT is running.
              Thanks, Mike!

              Comment


              • #8
                We are working on improve MLAT tracking all the time, and we have several nice improvments planned for the next months, that should improve MLAT coverage even more.

                Comment


                • #9
                  Originally posted by Mike View Post
                  We are working on improve MLAT tracking all the time, and we have several nice improvments planned for the next months, that should improve MLAT coverage even more.
                  Hi,

                  I'm feeding FR24 with RPi3 + RTL since some months ago (T-LEBL50) and providing MLAT. In our area (LELL) are many flights in Mode-S under 3000 ft and rarely shown in FR24, probably due the lack of FR24 receivers coverage

                  Could a GPS based NTP server in RPi improve something ? Some solutions as ... (sorry, I cannot include link as I'm new in the forum) are really interesting. I know that not controlled delays in USB path and O.S. are a bottleneck, but any possible improvement could be considered

                  Anyway your effort in computing and correcting delays down to microsecond and actual results are really impressive

                  Thanks,

                  Jordi

                  Comment


                  • #10
                    Originally posted by jcosta View Post
                    Hi,

                    I'm feeding FR24 with RPi3 + RTL since some months ago (T-LEBL50) and providing MLAT. In our area (LELL) are many flights in Mode-S under 3000 ft and rarely shown in FR24, probably due the lack of FR24 receivers coverage

                    Could a GPS based NTP server in RPi improve something ? Some solutions as ... (sorry, I cannot include link as I'm new in the forum) are really interesting. I know that not controlled delays in USB path and O.S. are a bottleneck, but any possible improvement could be considered

                    Anyway your effort in computing and correcting delays down to microsecond and actual results are really impressive

                    Thanks,

                    Jordi
                    Actually a microsecond is nowhere precise enough. Light travels at about 30 cm per nanosecond or 300 meter per microsecond. That means that the difference between right and left side of a 45 meter wide runway is only 150 nanoseconds.
                    The problem with the NTP servers are that there is no way to know the delay, compared to other FR24 receivers. You may get accurate time +/- delay, but the delay will be different from other receivers.
                    Therefore the signal from an ADS-B equipped aircraft is used to synchronize the 3-4 receivers used to plot a MLAT aircraft. (as fare as I understand)

                    Comment


                    • #11
                      Originally posted by Kpin View Post
                      Actually a microsecond is nowhere precise enough. Light travels at about 30 cm per nanosecond or 300 meter per microsecond. That means that the difference between right and left side of a 45 meter wide runway is only 150 nanoseconds.
                      The problem with the NTP servers are that there is no way to know the delay, compared to other FR24 receivers. You may get accurate time +/- delay, but the delay will be different from other receivers.
                      Therefore the signal from an ADS-B equipped aircraft is used to synchronize the 3-4 receivers used to plot a MLAT aircraft. (as fare as I understand)
                      Right, I should have written well below a microsecond

                      But the main question was: Could an RPi + GPS timing reference improve the MLAT situation ? ... or could it replace in some way an FR24 "master receiver" in MLAT ?

                      And another question ... could Mode A replies (Only A/C equipped aircrafts) be decoded, MLAT localised and shown by its Squawk codes, for example ?

                      Comment


                      • #12
                        Originally posted by jcosta View Post
                        Right, I should have written well below a microsecond

                        But the main question was: Could an RPi + GPS timing reference improve the MLAT situation ? ... or could it replace in some way an FR24 "master receiver" in MLAT ?

                        And another question ... could Mode A replies (Only A/C equipped aircrafts) be decoded, MLAT localised and shown by its Squawk codes, for example ?
                        RPi + GPS timing - I think not. Because you would still not know the local system delay in the individual Pi receivers. In the FR24 setup, the synchronization is done server side based on the common reference (the ADS-B aircraft). That means that even if the measurements are delayed from each of the receivers, the MLAT server will know the timing relative to the known expected delay of the ADS_B signal.

                        As for mode A, in theory yes. But not all aircraft are assigned an individual squawk code. VFR traffic will squawk 7000 in Europe and 1200 in other parts of the world, unless specifically assigned a squawk code. And in Germany for example the same code can be assigned to more than one aircraft.
                        So the those aircraft can not be uniquely identified just by there squawk.

                        Comment


                        • #13
                          There is no way to use a GPS on an Rpi, the timings are too bad as there is a very "big" delay in the USB port.

                          Comment


                          • #14
                            Originally posted by Kpin View Post
                            RPi + GPS timing - I think not. Because you would still not know the local system delay in the individual Pi receivers. In the FR24 setup, the synchronization is done server side based on the common reference (the ADS-B aircraft). That means that even if the measurements are delayed from each of the receivers, the MLAT server will know the timing relative to the known expected delay of the ADS_B signal.

                            As for mode A, in theory yes. But not all aircraft are assigned an individual squawk code. VFR traffic will squawk 7000 in Europe and 1200 in other parts of the world, unless specifically assigned a squawk code. And in Germany for example the same code can be assigned to more than one aircraft.
                            So the those aircraft can not be uniquely identified just by there squawk.
                            Regarding mode A: Yes, local VFR traffic in LELL ATZ are given unique codes in the range 74xx, but I know it's not a general rule and aircrafts squawking 7000 and crossing the area are often seen

                            Comment


                            • #15
                              Originally posted by Mike View Post
                              There is no way to use a GPS on an Rpi, the timings are too bad as there is a very "big" delay in the USB port.
                              Understood. Thank you

                              Anyway, any advance in RPi and MLAT will be kindly appreciated

                              Comment

                              Working...
                              X