-
Notifications
You must be signed in to change notification settings - Fork 19
mlat thoughts
USB extensions have the issue of often not providing enough voltage to the SDR (no matter active / passive). Active USB extensions can have data issues as well.
The number one reason for MLAT synchronization issues is loss of data on USB. (wrong location configured is reason #2)
The top reasons for USB data loss: Undervoltage or using a VM with USB passthrough (container USB passthrough is fine in 99.9% of cases)
MLAT uses the SDR sample clock derived from its oscillator.
The sample count is NOT transferred via USB so the receiver software merely counts the samples. If any samples get lost from the SDR to the receiver software, the "clock" jumps.
While the realtime clock can also cause issues ... and you don't want endless delay from the SDR to the mlat-client, this is not as critical as one might think without understanding the whole system. (i've spent a long time working on mlat-server / mlat-client so i know pretty much exactly what happens)
The beast data contains the sample count associated with every received message, this is the timestamp the mlat-server uses to do the sync between receivers and do time of arrival calculations.
To correlate identical messages, the system clock on the mlat-client system is used. This is just rough correlation and some offset / delay of maybe up to 250 ms is acceptable. (while not preferred ... and your setup will have a smaller offset)
For the sample clock, a sudden jump of less than 1 ms is problematic. Data loss from SDR to receiver software caused by any USB issues will usually cause a rather large jump of about 50 ms (one USB data transfer for readsb / dump1090-fa). Such a jump will be detected by mlat-server and you will get temporarily banned from participating in MLAT calculations as your setup is deemed unreliable. FA might temporarily ban you for hours, most other aggregators typically will ban you for usually 15 minutes.
so first you need to synchronize the oscillators of two SDR receivers. because the system clock isn't nearly precise enough. so you just count the samples you get from the SDR, that turns into a timestamp that just starts at 0 when you start dump1090 mlat-client gets that timestamp with every message it gets from dump1090 certain messages are sent to the server for synchronization. for sync ADS-B location message pairs are used. for an ADS-B location message you don't know when it happened, but it is sent at a certain point in time. using its location you can calculate travel time to the receiver who received that message. now if two receivers get the same message pair and that information makes it to the server, the server can build a conversion how to translate the oscillator timestamps of the one receiver into the clock of the other one .... then you have a synchronization. now you need at least 4 synced receivers .... and then you can calculate a position from the arrival time at the 4 receivers for any message you choose. suffice it to say ... it's somewhat complicated.
other guy: heh. It will take a little more time before I understand everything there. Is it way off to say that it uses signal time difference between synced receivers to geolocate aircraft?
wiedehopf: no. and it syncs using ADS-B location messages
other guy: ah
wiedehopf: basically ... you know the plane location and the distance to the receiver. so you know the exact travel time for the message. you never sync with real time ... all clocks are just offsets towards each other.
other guy: So on my adsbx sync stats, it says 75 peers. Does that mean I'm synced with 75 other feeders?
wiedehopf: yes.
other guy: Got it
wiedehopf: the sync count for each peer tells you how many common ADS-B location message pairs you've seen. how much overlap there is between you so to say (in regards to ADS-B planes) how well you receive those ADS-B planes is also relevant obviously. if you only receive every 10th message from an ADS-B plane, syncing based on it will be unlikely.