FR24feed on Raspberry Pi - Frequent DNS requests for NTP

[pete318]

You would think that artificially changing the source it uses from our neighbors feeding down the road who are all using the local ntp will all of a sudden make the bundled time (or distance) differ for the same apparent time.

The problem I think stems from your misunderstanding, or lack of understanding as to what the pool ntp servers are doing, and/or how the NTP protocol works in general.

The pool servers are generally stratum 2/3 servers (some strat 1). That means they are between 1 and 3 steps away from an original time source (GPS/PPS/Atomic). They will generally have 1 or more ms difference from a true time source (my S2 server seems to be mostly within +/- 1ms, but can occasionally be up to 5ms out for example. But, that true time IS the GPS time the other poster was referring to. There aren't different idea of "true" time.

The other poster has set up a stratum 1 server. This means they are generally going to be within 1ms (and depending on a variety of circumstances, considerably better than that) of actual GPS time.

I think that maybe you're assuming there's a constant "added" latency to true time that all users of the same pools will get. This is just not true. NTP tries to account for your latency by using multiple NTP servers (if you set it up thus) measuring latency as best it can and trying to work out the overall "closest" to the original time sources it can get. That difference will be + and - to the original time and different for everyone. Even if all people used the same time servers.

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.

I think there's a catch here though. It's much more likely that having a +/- 1ms time source matters little when the stream of data coming from the SDR dongle likely has an unknown and possibly variable delay. So, it can all be quite moot.

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.

However, I won't stake my life on that, since this latter point is moving into an area of my own relative ignorance.

[hnapel]

Somehow MLAT works by using math that can throw out the time the receivers think it is.

[Anmer]

First, NTP is far to crude to have any use for the MLAT timestamp. So it is not used for that.

Really? FR24 has a major competitor using NTP for MLAT timestamps as too are numerous private MLAT networks.

[F-EGLF1]

Really? FR24 has a major competitor using NTP for MLAT timestamps as too are numerous private MLAT networks.

The main competitor uses NTP only to get a rough time stamp for the packets, each receiver used for MLAT calculations must be able to see 1 or more aircraft with full mode-s giving time and location, this is then used as the reference and the difference in the reception times of the position less aircraft from all the stations is compared to this known time and position, the NTP is just used to time stamp the bundle of reports before they get sent to a SMU to calculate the position, this ensures that only reports received at approximately the same time are used. (An error of up to 2 seconds is acceptable otherwise the packets are rejected) the NTP time stamp plays no part in the position calculations.
Things are different with FR24 as the boxes they supply have a highly accurate GPS time stamp allowing the received time to be time stamped with much greater accuracy than NTP allows so positions can be calculated from the different reception times as ALL the boxes are effectively stratum-1 time sources.

[Anmer]

The main competitor uses NTP only to get a rough time stamp for the packets,

the NTP is just used to time stamp the bundle of reports before they get sent to a SMU to calculate the position

Are you suggesting that NTP plays NO part in calculating an MLAT position?

I was only questioning this post

First, NTP is far to crude to have any use for the MLAT timestamp. So it is not used for that.

The GPS time stamp, as employed by FR24 receivers and those of its competitors, provides for greater position accuracy. But at a cost.

Low cost SDR receivers, without GPS reception, can achieve MLAT at a much lower cost of acquisition.

https://en.wikipedia.org/wiki/Multilateration

Accuracy of multilateration is a function of several variables, including:
The antenna or sensor geometry of the receiver(s) and transmitter(s) for electronic or optical transmission.
The timing accuracy of the receiver system, i.e. thermal stability of the clocking oscillators.
The accuracy of frequency synchronisation of the transmitter oscillators with the receiver oscillators.
Phase synchronisation of the transmitted signal with the received signal, as propagation effects as e.g. diffraction or reflection changes the phase of the signal thus indication deviation from line of sight, i.e. multipath reflections.
The bandwidth of the emitted pulse(s) and thus the rise-time of the pulses with pulse coded signals in transmission.
Inaccuracies in the locations of the transmitters or receivers when used as a known location

[MrMac]

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.

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.

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

[MrMac]

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

[Anmer]

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?

[MrMac]

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

[Anmer]

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.

[elljay]

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

[SpaxmoidJAm]

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

[pete318]

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.

[elljay]

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.

[pete318]

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.