MLAT Feed Anomaly

FlightAware ADS-B Flight Tracking
1

I have fed continuous data now for several months through my Pi 2 B without any problems & have always been syncronized with around 60 local mlat receivers, but for the last week or so my mlat feed has more or less stopped & is constantly showing the following anomaly:

*This feeder is not being used for multilateration because its timing information appears to be unreliable. This can be caused by the site location being incorrect, or because your Pi is running out of free CPU. *

Nothing has changed on the Pi that I am aware of, locations correct & the stats below seem to look ok, any thoughts on what I can try to get it feeding mlat data once again?

top - 21:29:48 up 21 min, 3 users, load average: 0.37, 0.46, 0.41
Tasks: 108 total, 1 running, 107 sleeping, 0 stopped, 0 zombie
%Cpu(s): 7.3 us, 1.5 sy, 1.5 ni, 89.0 id, 0.0 wa, 0.0 hi, 0.7 si, 0.0 st
KiB Mem: 948016 total, 227480 used, 720536 free, 20444 buffers
KiB Swap: 102396 total, 0 used, 102396 free. 113380 cached Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
386 dump1090 15 -5 29320 10580 2144 S 26.3 1.1 5:17.18 dump1090-m+
869 root 20 0 13232 9868 5576 S 7.9 1.0 1:48.12 fa-mlat-cl+
416 mlat 25 5 12856 9200 5384 S 6.9 1.0 1:26.87 mlat-client
524 root 20 0 23088 8260 4864 S 1.3 0.9 0:17.52 piaware
613 root 20 0 2952 1716 1544 S 1.0 0.2 0:10.88 faup1090

2

Usually most of the time this would be a bad power supply causing the issue that I have seen. Although I have had to replace one Pi that I started getting this message on that just seemed to be going bad. Replaced everything but the Pi and still got the message so I ended up changing the Pi out.

3

Give following comand in a terminal
pi@raspberrypi ~ $: date

This will display current date & time.
If the time is not correct, you might have to force update it. This is because, by default, ntp will not sync if the difference between the system time and the real-time is greater that 1000 seconds.

To force update, run
pi@raspberrypi ~ $: sudo ntpd -gq

Then restart the ntp server
pi@raspberrypi ~ $: sudo /etc/init.d/ntp restart

After few minutes, check time again
pi@raspberrypi ~ $: date

Now reboot RPi
pi@raspberrypi ~$: sudo reboot

Most likely this will solve the problem.

4

NTP has nothing to do with mlat sync/timing, messing with NTP won’t help, mlat does not use the system clock at all.

If the location is OK and you have spare CPU then the remaining explanation is a hardware problem - the dongles do not tolerate a noisy USB bus well and data will get silently dropped which turns into a mlat timing problem. This can happen with bad mechanical connections, long USB runs, EMI, or just getting unlucky with the particular dongle+Pi combination. For example I have one dongle that works fine and another apparently identical dongle that shows intermittent timing problems.

5

Thanks for the replies.

I never got to find out the cause of the problem but I’ve managed to get the Pi re-feeding MLAT data once again by formatting the sd card & reinstalling a backup of the image that I had made after I first set this Pi up.

6

It seems I have good luck and my shot in dark (i.e. forced synchronizing time with ntp) has succeeded in restoring MLAT on more than one occasion!

7

Confirmation bias, it was probably the reboot that helped, if you have a system that is unstable over the long term but is sometimes OK in the short term then restarting it will make it work for a little while until the mlat server sees enough instability that it decides to stop using the receiver.

8

You are right. On all these forced time synchronization events, final step was reboot.

9

It might be good to add a note to the error message that this has nothing to do with NTP/system clock. It’s clear to the majority, but some keep venturing down the NTP rabbit hole…