Everything appears fine with my feeder and I feed multiple different services but I cannot get MLAT to go green on my FlightAware page: davewill2010 ADS-B Feeder Statistics - FlightAware
Any idea on how I can get this fixed?
Thanks in advance
How accurate is your site location?
I believe it is spot on but if you can suggest how I can check and adjust I would be very interested to hear any suggestions.
Go to the paddle wheel and select “edit location”
Drag the map / pointer somewhere close to your actual location
OK I have dragged the pointer to the exact location of the antenna and will see if that helps.
Many Thanks for your help
I made the change about 25 minutes ago and it went green temporarily but then went back to red.
If I click on “View Anomaly” it shows this: Site 43072
- 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.
What does the piaware log tell you ?
If you get the RTC Clock unstable message then the issue is that the timing is not accurate enough for piaware.
Since the Pi doesn’t have a RTC module this is not something you can easily fix as far as I know, I’ve experimented with RTC modules for a Pi but it never was capable to get rid of the incidental red MLAT box.
I take it for granted now since it usually pops up when there is very little traffic around in my setups.
The “Clock Unstable” message is basically never about the actual system time, it’s about the SDR oscillator.
I’m not even aware that there is a “RTC Clock unstable” message, i don’t think there is.
1 Like
I’m referring to
[2026-08-27 15:53 CEST] mlat-client(2458694): Server status: clock unstable
There’s no mention of the RTC clock indeed but that has always been my assumption since the server sees the clock as unstable but that could be the SDR as well indeed.
Not sure i’ve corrected you specificially on this exact error but it sure feels like it 
Pointing at the system time for that error is … a red herring.
It can be a wrong position or data getting lost between SDR and decoder (on USB).
The reason for data getting lost can be multiple things, bad SDR or not enough voltage making it to the SDR (extension / power supply / pi board)
1 Like
Actually you’re pointing out that the logic I’m using isn’t as straightforward as I was thinking. So no offense taken in your reply, I’m still learning everyday from others on these boards.
1 Like
The strange thing Tom is that its so intermittent. Sometimes its green for quite a while then all of a sudden it goes red for a considerable amount of time and then back to green (wash, rinse, repeat) without intervention.
1 Like
MLAT continues to be a problem for me despite buying a new ProStick Plus and adjusting my location to as close to exact as possible. Sometimes MLAT stays green for a while but then goes red. It IS intermittent but its red more than its green.
Is this fixable or do I just need to live with it ?
On reading some other posts regarding MLAT not working I saw it mentioned that it can be caused by there not being being enough close by receivers but on checking mine I find there are lots!
If an intermittent problem seems difficult to resolve:
Could you post your Feeder log so other users can check for anomalies? Just go to your page and click on the gear circled in red on the right side of the image.
Check if the location accuracy is set to “precise/exactly.”
Enter the location with a precision of 5 decimal places.
And the installation height as well.
Finally, post the log when this anomaly is occurring so other users can see it…
I can’t tell you whether the problem is hardware-related or due to a configuration conflict between the various sites you manage. However, there are many users here who also manage multiple services, and they might be able to give you a valuable tip.
1 Like
Some problems with MLAT generally caused by hardware:
Saturation of one of the RPi CPU cores (over 100% usage). Since you are feeding data to multiple sites, CPU usage spikes at times, causing delays and message loss, which makes MLAT unstable.
Long USB cable causing voltage drop
Using an SDR in an unventilated area or one subject to rapid temperature fluctuations (this primarily affects generic dongles that do not use a TCXO).
Low air traffic region: In areas where, at certain times, there are no aircraft flying—or none being detected by at least four stations simultaneously—MLAT loses synchronization. (MLAT relies on the aircraft’s GPS for time-stamping; without an aircraft present, synchronization cannot be maintained and is lost, only resuming once an aircraft passes by and its signal is picked up by multiple stations.)
That doesn’t affect the calculations, it’s just a privacy option to hide your exact location to other viewers.
1 Like
Thanks for the correction.
It is somewhat a problem with pi3s.
And their load.
And their power supplies.
And just depending on luck.
You can have better luck if you don’t run adsb.im in this very specific case.
It’s a combination of load and the pi3 just being very bad USB hardware.
1 Like