Page 3 of 4 FirstFirst 1234 LastLast
Results 21 to 30 of 36

Thread: FR24feed on Raspberry Pi - Frequent DNS requests for NTP

  1. #21
    Purser
    Join Date
    Feb 2012
    Location
    ESGG1
    Posts
    190
    Quote Originally Posted by pete318 View Post
    However, the user using the GPS time source is going to have a much more reliable time source on their local LAN and as such can provide much more reliable values for MLAT data.
    No, there will be absolutely no difference.

    Quote Originally Posted by pete318 View Post
    As I understand it, multilateration is more about using other signals of KNOWN location in order to get a temporal inference, rather than relying on home users being able to get the nanosecond accuracy needed for multilateration without known references.
    Unless the hardware does the GPS timestamp in an FPGA, like the FR24 receiver, it is absolutey fundamental with ADSB-derived relative sync.

    Quote Originally Posted by Anmer View Post
    Really? FR24 has a major competitor using NTP for MLAT timestamps as too are numerous private MLAT networks.
    No they don't. millisecond accuracy is completely useless for mlat synchronization and it is technically impossible to use NTP for the TOA. Just do your math to see how far light travels during a millisecond and it should be obvious.


    Receivers and feeder softwares all use some kind of real time, NTP-derived timestamps for all their data, but this is just to help the server decide what data is reasonably recent and what is outdated. It helps reduce the problem with transmission delays, and makes the servers job of de-duplication easier, trying to prevent aircraft jumping backwards. It also aids the initial mlat pre-calculation when needing to decide which receivers are candidates for a solution, i. e which receivers actually do hear the interesting packet simultaneously. For this, tens, or even hundreds of millisecosnds is enough, and any difference between different time servers, remote or local, is completely irrelevant.

    But, for the actual TOA (time-of-arrival) of a message used for mlat calculations, there are currently 2 methods

    1. A purpose-built hardware can do GPS-synchronized timestamps on a specific point of the received message, based on the pps pulse from the GPS.. For example commercial WAM systems, FR24-Rx/ Radarcape and also the Planefinder hardware as I understand it. This can be called absolute sync.

    2. All other dongle- or separate receiver based systems including Flightaware & PlanePlotter uses the method of synching to ADSB-transmitting a/c with known positions. This is relative sync. The FR24 systems also correlates these relative synced Rx to an FR24 box to convert it into a pseudo-absolute sync, as their system seems to need at least one part of the equation to have absolute synch.

    So, as has been explained here numerous times, the NTP time quality in a Rpi has NO effect on the quality of the mlat data whatsoever. But to be a candidate for any calculation, it needs to have reasonably correct time to begin with, but that is just a "pre-selection" process. That is why adding a GPS to an Rpi-based receiver won't improve mlat.

    /M
    Last edited by MrMac; 2017-01-06 at 22:33.
    F-ESDF1, F-ESGG1, F-ESGP1, F-ESNK1, F-ESNV2, F-ESNV3 F-ESSL4, F-LFMN3
    P-ESGR, P-ESIA, P-ESIB, P-ESGF

  2. #22
    Purser
    Join Date
    Feb 2012
    Location
    ESGG1
    Posts
    190
    Quote Originally Posted by F-EGLF1 View Post
    The main competitor uses NTP only to get a rough time stamp for the packets,
    Exactly.

    This was posted while I was writing, but we say precisely the same thing.

    /M
    F-ESDF1, F-ESGG1, F-ESGP1, F-ESNK1, F-ESNV2, F-ESNV3 F-ESSL4, F-LFMN3
    P-ESGR, P-ESIA, P-ESIB, P-ESGF

  3. #23
    Captain Anmer's Avatar
    Join Date
    Apr 2010
    Posts
    1,383
    Quote Originally Posted by MrMac View Post
    Receivers and feeder softwares all use some kind of real time, NTP-derived timestamps for all their data, but this is just to help the server decide what data is reasonably recent and what is outdated.
    Maybe I'm totally missing the point, it has been known, but this seems to suggest that an NTP time stamp does play a part in MLAT calculations?
    Mike


    www.radarspotting.com

    Radarspotting since 2005

  4. #24
    Purser
    Join Date
    Feb 2012
    Location
    ESGG1
    Posts
    190
    Quote Originally Posted by Anmer View Post
    Maybe I'm totally missing the point, it has been known, but this seems to suggest that an NTP time stamp does play a part in MLAT calculations?
    You are.

    NTP is used to set the real-time clock, but it would do just as fine if set by the user to a reasonably, sub-second accuracy. NTP is just a way to ensure that this is automated, and that the user doesn't input the wrong time. That is why an automated process is required in many networks, not that it needs the accuracy of NTP.

    NTP accuracy is completely irrelevant, and that was the question at hand here.

    And, read what I actually said again:

    NTP is far to crude to have any use for the MLAT timestamp

    TIMESTAMP. NTP plays NO part in the MLAT TIMESTAMP, which is crucial part of the accuracy of the position.

    /M
    F-ESDF1, F-ESGG1, F-ESGP1, F-ESNK1, F-ESNV2, F-ESNV3 F-ESSL4, F-LFMN3
    P-ESGR, P-ESIA, P-ESIB, P-ESGF

  5. #25
    Captain Anmer's Avatar
    Join Date
    Apr 2010
    Posts
    1,383
    Quote Originally Posted by MrMac View Post
    TIMESTAMP. NTP plays NO part in the MLAT TIMESTAMP, which is crucial part of the accuracy of the position.
    I still beg to differ.

    NTP is used to set the real-time clock, but it would do just as fine if set by the user to a reasonably, sub-second accuracy.
    Left to the "user" to set a "reasonably, sub-second accuracy", I suspect 95% of those helping make MLAT plots with non-GPS solutions would fail.

    Let's leave it at that. I know when I'm urinating in the wind.
    Mike


    www.radarspotting.com

    Radarspotting since 2005

  6. #26
    Purser
    Join Date
    Jan 2015
    Location
    T-EGKK39
    Posts
    112
    Getting back to the question of FR24 doing multiple DNS lookups to the NTP Pool, I've sent a support request asking if it's still the case. If it is then it would be a rather rude use of the volunteer servers in the NTP Pool.

    I send data to both FR24 and the NTP Pool so I know the NTP Pool recently almost had a meltdown due to misconfigured software (https://community.ntppool.org/t/rece...ic-increase/18).

    If anyone has a server or two they could help the NTP Pool with they would be very welcome! http://www.pool.ntp.org/en/join.html

  7. #27
    First officer
    Join Date
    Sep 2013
    Location
    Farnborough, UK
    Posts
    204
    I agree that the use of NTP is just to get everyone in the same ball park.

    due to the coarseness of MLAT positions, i very much doubt that the few ms difference will make any difference.

    I'm reasonably sure that FR24 use of NTP is just so the time is set rather than just whatever the pi happens to be at so when data is sent in it can be instantly tossed away if its to old (due latency on the internet etc.. i iamge were talking seconds here)

    It does make most sense if they did use time stamp's from known positions and then referenced that to the local clock (on data sent in) to create a time offset (for that client) so MLAT calculations can be done. So the local accuracy could a little out but not appearing to old when sent to FA
    Last edited by SpaxmoidJAm; 2017-01-07 at 10:46.
    T-EGLF8

  8. #28
    Passenger
    Join Date
    Feb 2013
    Posts
    11
    Quote Originally Posted by MrMac View Post
    No, there will be absolutely no difference.
    If you mean there will be no difference for the use in MLAT calculations, then I'll agree. As I say later, I suspect they use other received known references to work out an accurate time for position calculation.

    If you mean there will be no difference between a stratum 1 NTP server running from GPS or PPS sources and a stratum 2+ NTP pool server, then I disagree wholeheartedly.

  9. #29
    Purser
    Join Date
    Jan 2015
    Location
    T-EGKK39
    Posts
    112
    I had a reply from FR24 support - they confirm the client does make the NTP Pool lookups but are going to review - I've pointed them them in the direction of the Pool Vendor page and copied in Ask.

  10. #30
    Passenger
    Join Date
    Feb 2013
    Posts
    11
    Quote Originally Posted by elljay View Post
    I had a reply from FR24 support - they confirm the client does make the NTP Pool lookups but are going to review - I've pointed them them in the direction of the Pool Vendor page and copied in Ask.
    I think it would be nice if yes 1: They did get a vendor zone. But 2: It's possible to disable if you do have ntpd running already. Since an established NTP server that is syncing even with pool servers will usually have a pretty stable +/- 5-10ms accurate clock and will account for local drift.

    Regardless of how much an accurate clock matters for MLAT, some people will have better solutions operating already.

Posting Permissions

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