FlightAware Discussions

MLAT and motion

Yesterday I noticed that my stats page was showing MLAT was down. On my device I saw in the log entries like: “mlat-client(873): Server status: clock unstable”.

Noting the time that entry started appearing I looked at other logs and saw that was when I had installed and set up the motion app in order to use a USB web cam to feed my surveillance system. Disabling that app and restarting the system fixed the issue.

It does not appear to be a CPU usage problem as top showed nothing with high CPU, so I’m thinking either a network port conflict or something in the USB device access. I’m running on a Raspberry Pi 3B.

Has anyone else seen this?


The USB bus on RPIs are shared. ie ethernet and the four USB ports share the bus (not sure about the SD card). It is easy for the bus to become overloaded. If it does, then a lot of ADS-B data will be dropped. This can affect MLAT.

1 Like

Using a USB web cam might just not work as it is probably using a lot of USB bandwidth.

Could also be that the dongle doesn’t get sufficient voltage with 2 USB devices connected to the RPi.
Sadly the power design of the RPi is not good.

Connecting both devices via a powered USB hub might help.
Or if it is the bandwith you can try reducing the webcam resolution.

1 Like

Makes sense, thanks.

I wasn’t sure I’d hit limitations like that. I’ll experiment a little (though the idea was not to have too many extra things like USB hubs). If not practical I’ll just leave the older Pi 3 B dedicated to PiAware and use my other Pi 3 B+ for other experiments. :slight_smile:

This is what I do. I have 3 RPis. The first is the main FlightAware ‘station’. The second is for FlightAware experimentation. The third is for everything else, usually hamradio related.


That’s now my plan. I actually also have three (got the RPi 3B as a bundle for PiAware, then when I realized how cool they are I got two RPi 3B+ to play with). I work on computers for a living, developing network security software at Cisco, so this is kind of natural for me other than the Linux part. One RPi will definitely be used to experiment with ham stuff. In fact I’m doing a presentation to my ham club tomorrow night on SDR / ADS-B. :slight_smile:

Erik W1QED


I see that semi-regularly. Restarting the Pi fixes it as does ignoring it (just takes longer).

I’ve even had an Anomaly claiming MLAT wasn’t being used due to timing information - the Pi hadn’t been powered up for a week.


Generally those anomalies reflect whatever the state of the feeder was the last time it connected - so if it hasn’t connected for a week, the info will be a week old.

Yep, I’ve seen that too, but this time all my sites suddenly started reporting the same thing (on two different continents) (I think only two had MLAT enabled).

I have 7 or 8 RPIs. A few are used for ads-b with Airspy, mode S beast, or FA dongles.
One is used for APRS, one for cacti(SNMP monitoring and config backups), one for sniffing(netflow/span monitoring) and one for iperf testing. They are great low power devices.

Got another one - three sites suddenly report: “23% of UDP mlat traffic …”

Site103772 hasn’t been powered up in a month.

It’s odd that three sites are all reporting “23%” when they are on two different continents.


30 min later, the report was not so bad - only “18% of UDP mlat …”
but it still hasn’t been powered up in a month.

Sounds like a problem with the join used to collect data for display; if you view the single site it’s normal but if you view your user page with multiple sites then the mlat anomaly repeats itself. The underlying db data doesn’t show mlat loss for 103772 but does for 85260. Thanks for the report, I’ll pass it on to the web team to look at.

Site 85260 is perhaps a little unusual.
The Pi is connected to a wifi client (by cable).
This talks over an 850m wifi link to an outdoor AP.
This in turn is cabled to a 4G router/modem.

I assume the path is double NAT’d (my router plus the ISP).

I turned off MLAT for 85260 and the error cleared for all three sites.