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.
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.
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.
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.
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.
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.
Thanks.
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).