The problem is that there’s no way to correlate the GPS time information with the time that the to-be-MLATted message arrived at the receiver with enough precision if they’re arriving as two separate signals.
There’s an unknown (and variable) amount of latency between the message wavefront arriving at the dongle’s ADC, and that sample arriving in dump1090 or equivalent.
USB in particular adds a lot of unknown delays there - milliseconds.
You really need microsecond-level precision to do MLAT.
If you could use a GPS PPS signal to timestamp the samples that would work. However the SDR dongles won’t do that directly. I guess you could build some external hardware that mixed the PPS signal into the RF feed at 1090MHz in a form that the decoder could pick it out again, but that’s going to be nontrivial…
However - I don’t think you actually need the receiver clocks to be directly synchronized for this particular case.
You can derive a common clock from other ADS-B position messages that are received by all receivers.
You know the position of the transmitter and the positions of each receiver, and the approximate propagation speed, so you know the expected difference in reception times.
By comparing that to the actual difference in reception time as measured by each receiver’s clock, you can find the offsets between the receiver clock.
I would speculate that this is how Planeplotter’s MLAT works.
Writing something to do this is on my todo list somewhere… the main challenge is in getting a group of receivers to test with.
I was going to look for volunteers at some point
NTP runs fine on a pi, but that does not help with the USB delay. You know when the sample arrived over USB, but not when the signal arrived at your antenna.
Also NTP from a network time reference won’t generally give you microsecond accuracy anyway…
It’s not just range - the ideal setup is 4+ receivers located around the aircraft, all being able to hear messages from it.
It’ll be easiest to test against a bit of airspace that is busy at cruising altitudes since the higher you go the more receivers will be able to see it.
My suggestion would be for somewhere off the Belgian coast - there’s a fair amount of traffic there and that should be visible to lots of receivers in the UK / Belgium / Netherlands.
e.g. receivers in this 350km radius circle
Guess this is moving up my todo list then
Might have something to try this weekend (not mlat, but the groundwork to do the clock sync part)
It will probably be in the form of a python script that talks to an existing dump1090 and feeds summary data back to me for aggregation with other receivers.
They don’t use NTP-based timestamps, they use the 12MHz sample timestamps. NTP is irrelevant other than as a simple way to weed out very out of date reports that aren’t useful.
I have a test system working now, but it could use a couple more receivers around the UK, Benelux or nearby to improve the coverage.
Send me an email (oliver@mutability.co.uk) if you’re willing to be a guinea pig
excellent,
can we get midmarsh (Coningsby, Lincs),
someone with a good range near Mancester (StephenWhitfield?)
Someone with good cover South London / Kent / Sussex
I’d need my hand holding though as I’m new to Pi, Linux, ADS-B etc.