Hello all,
I have been feeding ADS-B with MLAT enabled via a raspberry pi 2 for several months now.
While looking at my ADS-B stats page, I have noticed that my receiver is not being used for MLAT >90% of the time. If I look at the hourly messages chart, I see that the receiver will send messages for a couple of minutes-hours, then drop out for many hours at a time.
When I click on the “view anomalies” link I get this message: “This feeder is not being used for multilateration because it’s timing information appears to be unreliable…” It goes on to say that my location is wrong, or the pi is low on CPU.
My location is set dead on, and there is plenty of free CPU on my pi. My SDR dongle is the flightaware pro (plus?) with the integrated 1090mHz filter, so I doubt that it is the issue.
I only have a very general understanding of how MLAT works, so I’m not sure where to start troubleshooting. Is the timing information referenced in the “anomalies” message from the pi system time, an internal clock oscillator on the SDR, or something else? Should I be trying to fix the pi system time, or looking at a hardware issue? Could this be caused by signal reflection from surrounding buildings? There are plenty around to cause interference.
1 Like
The clock timing is from the SDR. The raw RF data is streamed in packets from the SDR to the the raspberry pi for processing and if the USB packet is dropped the timing gets off. We usually see the problem of dropped packets from lower quality USB extension cables. If you can try connecting the SDR to another USB extension cable or directly to an USB port you can rule out USB problems.
The other way that the timing gets off is if the RPi CPU is busy and the decoder will drop the packet instead of processing it. This is easy to check if the cpu usage is high with a program like top. Anything over 90% CPU will cause packets to be dropped.
There are some timing checks done on the server side and the location of the site should match up with the expected location of planes. Having the location of the receiver within a few hundred feet of the actual location is good enough. The closer to the actual position the more actual the MLAT calculation.
From what you are saying it looks like you have a USB connection problem that is causing dropped packets.
1 Like
Ok, thanks. I do have the SDR hooked up via a cheap 3" extension (to make it fit into an enclosure). I’ll try connecting directly to see if that improves the situation. CPU usage looked good when I checked with htop the other day, but I suppose it’s possible that it is briefly spiking above 90% for some reason.
1 Like
Thanks David. I’ll give it a couple of days to be sure, but that seems to have fixed the issue.
1 Like
