MLAT Timing Issue (Error) & Configuration Check

[M0CRT]

Good afternoon fellow ADSB and flight tracking enthusiasts

Since the migration to version 6/6.1 of PIAware, I’ve been seeing more frequent messages from the ‘mlat-client’ (journalctl) with ‘Server Status: Clock Unstable’…and thus red MLAT on the status page. Very much more so since Sept.

Nigel Hall ADS-B Feeder Statistics - FlightAware

I am running the Debian add-on package within an Ubuntu VM on Unraid with a passthrough USB controller and thus highly important I check all this out on a dedicated Rasp Pi shortly (and I will). The issue is that this has been working solidly for 2 years and only since v6.0 I’ve been seeing issues.

I’ve now upgraded to 6.1 and still see the issues. ADSB Exch isn’t reporting issues (green all the way), nor is the FR24 feeder. However, it could still be something that’s changed my end.

Could someone check out my port mappings and clients running to ensure everything looks ok? I’ve excluded VRS connections to keep the mapping simple.

Checks:

• Upgrade to 6.1
• Changed USB pass-through from USB2 to a USB3 card. No change.
• Detailed client connection mapping exercise.

I wonder / worry if there’s something nasty with the VM and UDP connectivity. I’ve read that VMs sometimes get quite angry with UDP connectivity and, seeing that FA uses UDP rather than ADSBX (which is TCP based)…this may be an issue?

Checking this all out tomorrow on a clean Pi with existing hardware.

Further question, could the FlightAware Pro Stick be faulty and could this be causing the issues and nothing to do with config / USB ports or VM? I’ll try a swap too.

The mapping was very carefully done via NETSTAT -alptun etc. Anything surprising / issues I should consider? Good if someone could comment on the minimum connectivity required between clients and potential good practice (if there isn’t a pointer to something already! )

Finally, ref VRS, If I wish to pull ADSB and MLAT separately, pulling the MLAT traffic directly from the FA-MLAT-CLIENT on 30105 is correct isn’t it?

Thanks all! Spent sooo much time looking at this.

Mo

[obj]

@M0CRT

I wonder / worry if there’s something nasty with the VM

VMs tend not to play well with the bulk USB endpoint used by the rtlsdr dongle and often drop a lot of data even in passthrough modes. Dropping data like this directly affects mlat timing as the timing relies on counting the number of samples that arrive (so if you drop data, it’s like your clock suddenly stopped for a while). I would strongly suggest running dump1090, at least, on bare metal.

[M0CRT]

Thanks Sir.

Just as an update, clean Pi4 install…perfect.

Hmmm. Maybe I’ve been lucky last few years…no issues. Guess, as you mention, best to run dump1090 on the Pi.

Thanks