Anything we can do to better MLAT?

[jprochazka]

@adsbxchange You mentioned MLAT accuracy being effected by time settings which yes is true. Anything I can do to help out here with the script that you can think of? I have noticed a few jagged tracks especially in one area of my receivers range while others are smooth. I am guessing someone's timing is off in that area. Maybe somehow making sure the time on their device is proper and set to a reliable NTP server?

[adsb-related-code]

We have these same issues across feeders in all MLAT areas. Keeping NTP server timings up to date is the easiest way without adding a GPS dongle. A GPS dongle with a Python script to keep the time updated would work but adds $20 and more complexity to the feeder setup.

MLAT just compares the receive time of the 1090MHZ Mode-S packet to on the others feeders receiving the same packet in the matrix. => since RF is predictable speed (roughly) .. that gives use a radius probability where the aircraft could be and it just solves for probable position using a bunch of feeders. I think I got that right. :)

Just the beast of MLAT.

EDIT: Not a good MLAT explanation. That's better way to explain it.

EDIT: MODE-C to MODE-S

[adsb-related-code]

As for jaggy tracks. That's just what happens when timings aren't in sync or signals are wonky. Solving the matrix is pretty CPU intensive as well.

[adsb-related-code]

Can we do better? Probably .. but also the problem can be people not using Pi images, or VRS, or Windows timings, etc etc

[eroom1966]

can I ask for clarification on this statement

MLAT just compares the receive time of the 1090MHZ Mode-C packet to on the others

Do you really mean Mode-C ?
or do you mean Mode-S, my understanding is that pure Mode-C is not considered for MLAT, am I wrong, MLAT is tracking Mode-C transponders ?

[adsb-related-code]

ahh yes. mode s only. mlat can monitor - it just doesn't in this implementation