Anyone else getting MLAT Anomalies
Anomaly report for PiAware site 40150 - ConligWX:
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.
can’t see anything wrong my end, but have read older post of this issue has cropped up before.
Looks like its my end. dump1090-fa still running but cannot ssh or use the Send command to device feature here.
PiAware defaults to SSH off. Instruction to turn on SSH is here:
flightaware.com/adsb/piaware/build/optional
Basically you can create a “ssh” file in the SD card’s boot directory or run the “sudo raspi-config” program.
MLAT timing is usually due to your site’s location not set. Go to your “My ADS-B” page through the link at the top of this webpage.
Go to the location section and check if the value is set correctly.
The other MLAT problems are usually due timing on your PiAware.
Timing problems can be hard to diagnose since it can come from delays in the USB system to delays in the CPU.
[quote=“david.baker”]PiAware defaults to SSH off. Instruction to turn on SSH is here:
flightaware.com/adsb/piaware/build/optional
Basically you can create a “ssh” file in the SD card’s boot directory or run the “sudo raspi-config” program.
MLAT timing is usually due to your site’s location not set. Go to your “My ADS-B” page through the link at the top of this webpage.
Go to the location section and check if the value is set correctly.
The other MLAT problems are usually due timing on your PiAware.
Timing problems can be hard to diagnose since it can come from delays in the USB system to delays in the CPU.
[/quote]
SSH was enabled and Location was set it - it was all working fine until today. The only thing I can think was, that I had running on PiAware that was extra was FlightRadar24, Planefinder and I added yesterday Opensky.
maybe I had overloaded the pi? I dunno, I have uninstalled Planefinder and Opensky for now. I will monitor the situation.
Just wondering, from about 0800 to 1700 local time my mlat count goes down, sometimes to zero. I have looked to other systems near my location and they seem to have the same issue. I have looked at some sites near me in rankings in other parts of the country, i.e. NY, and they do not seem to have this issue.
Do I have an issue, or is this a “DFW” server issue?
[2017-04-20 11:34 CDT] mlat-client(2515): Receiver status: connected
[2017-04-20 11:34 CDT] mlat-client(2515): Server status: synchronized with 90 nearby receivers
[2017-04-20 11:34 CDT] mlat-client(2515): Receiver: 1314.6 msg/s received 434.9 msg/s processed (33%)
[2017-04-20 11:34 CDT] mlat-client(2515): Server: 0.0 kB/s from server 0.0kB/s TCP to server 5.0kB/s UDP to server
[2017-04-20 11:34 CDT] mlat-client(2515): Results: 5.2 positions/minute
[2017-04-20 11:34 CDT] mlat-client(2515): Aircraft: 96 of 172 Mode S, 28 of 88 ADS-B used
flightaware.com/adsb/stats/user/ … tats-19502
Thanks,
Larry
Practically neighbors… Been having the problem for a long while now. That bottom line shows the issue. For some reason the server is rejecting over half of the Mode-S positions, and less than one quarter of the ADS-B positions.
[2017-04-20 15:51 CDT] mlat-client(24786): Receiver status: connected
[2017-04-20 15:51 CDT] mlat-client(24786): Server status: synchronized with 93 nearby receivers
[2017-04-20 15:51 CDT] mlat-client(24786): Receiver: 1115.9 msg/s received 418.8 msg/s processed (38%)
[2017-04-20 15:51 CDT] mlat-client(24786): Server: 0.1 kB/s from server 0.0kB/s TCP to server 4.4kB/s UDP to server
[2017-04-20 15:51 CDT] mlat-client(24786): Results: 59.9 positions/minute
[2017-04-20 15:51 CDT] mlat-client(24786): Aircraft: 81 of 164 Mode S, 23 of 107 ADS-B used
Hey neighbor, wonder if this is system wide or just our neck of the woods. As I was putting together my system, I used your site as a bench mark to try to emulate. I’m down in a low area at the house, but I do the best I can.
Thanks,
Larry
That is normal, expected behaviour; the server doesn’t ask you for all traffic, only the traffic that’s actually needed.
The dropouts are probably server load relaed.
That is not what the message means.
/M
Haha, I did the same thing with the biggest site in the area when I got going. It was a proud day when I doubled him. ewhalvorsen must have some voodoo magic (or no trees and a 2 story house), because I can’t tweak enough to beat him on any given day.
It was an uneducated WAG. Consider me informed.
I too have been having the MLAT reception fall to very very low numbers around 6pm CST everyday for the last few days.
Hi, I started to get a similar issue on my Pi 2 based setup and found that after updating the Pi firmware to 4.9.x kernels I got the dreaded “This feeder is not being used for multilateration because its timing information appears to be unreliable” message on my My ADS-B page
I downgraded the firmware of the pi using this command —>
sudo rpi-update 52241088c1da59a359110d39c1875cda56496764
Which is to kernel version 4.4.50-v7+ (the last one before 4.9.x) after which everything appears to be working as advertised again…
Hope this is of use! 
Were you using the full piaware image or Debian Jessie lite and dump1090/mutability?
I am running one of my Pi 3’s with Kernel 4.9 (ADS-B Receiver Project Setup Scripts image) and dont have this issue.
I’m running Rasbian Jessie with dump1090-mutability v1.15-dev so its not the FA Piaware image. I’m inclined to think its a Pi2 thing but there you go! I’ve got 3 other feeder running on the same Pi2. An old PC is running Virtual Radar Server (Linux/Mono) with the FA MLAT helper outputting to it over my LAN. It’s a system that’s normally very reliable however the Pi kernel 4.9.x upgrade definitely broke the MLAT side of things. YMMV 'natch but worth posting I felt! 
cheers for the info, will keep an eye on it for now, hopefully I wont need to downgrade, though if I do I may just move to the piaware image since I dont really need all the bells and whistles of mutability
I am also getting this “clock unstable” issue after the running apt-get update/upgrade a few days ago on my Pi 2. Firmware was updated to 4.9.24-v7+. I am running Raspbian Jessie, dump1090-mutability 1.15~dev and the PiAware 3.5.0 package.
This looks like a good opportunity to test this kernel issue! Have you reverted to the older kernel version as per my earlier post? It’ll be interesting to see if it resolves the problem… 
That’s an unrelated issue.
I’ll try reverting to kernel 4.4.50 and see if that fixes things.