Does the FF needs to get an update?.. I have the following message…
Feeder Type: FlightFeeder 6.4
Multilateration (MLAT): Receiver Not Supported
Loving the new updated Control Panel to now include MLAT data.
Although, I am unable to use MLAT as I keep getting this 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.
1: My site location is accurate to within a few feet, as I have correctly put my Lat and Lon in the Location.
2: I am running RPI2 Mod B with only Piaware 2.1-3 image installed and recently re imaged my SD Card for a clean install.
So, how can I either be in the incorrect location or my RPI running out of free CPU?
dump1090 27.4% cpu
fa-mlat-client 24.4% cpu
piaware 0.7% cpu
faup1090 0.7% cpu
Edited: Unable to add image to post.
You will also get that message if attempting to run multiple dongles feeding a single piaware. …but looking at your page, I see MLAT a/c in today’s accumulating stats.
No, I’m only running one Dongle but the mlat a/c count is nowhere near what it should be. Something isn’t right. I’ve tried going back to Piaware 2.1-2 as that was working perfectly but the certificate is no longer valid on Piaware’s SSL server.
So, as this Piaware 2.1-3 isn’t working properly, I will just have to feed ADS-B and Disable mlat.
Will you look at that!
My first ever MLAT!
1 a/c 18 positions at 1500L
Now if I only knew how to contact that person and get them to leave their pi on longer!
Phill
EDIT
Apologies, I appreciate this isn’t the perfect place for this post but has a tenuous link.
Only three feeders created this MLAT fix. We each got the credit 1 a/c and 18 positions. As far as I can see there was never a forth so how did the fix come about?
There have been no recent changes to the clock stability logic. It is probably an intermittent environmental hardware problem. That’s just what you get with these cheap dongles. Leave mlat on, it’s not doing any harm.
I am loving the update so far but it happened on exactly the same day that I installed the FlightAware filter inline to my antenna. I am seeing a huge jump in total stats so I think it is working very well but I didn’t know if the MLAT updates could have bumped up my numbers as well? Either way I am happy it is just that the engineer/scientist in me is going crazy because I accidentally changed two variables at once!
Thanks Oliver. Just don’t like seeing “server unstable” for the mlat clock in the piaware.out log. Worries me it’ll crash lol.
It’s a clock stability problem not a system stability problem
This specific case (where it looks like a hardware thing), sometimes the dongle drops a handful of samples (10-100us) which messes up the inter-message timing measurements enough for the server to consider those measurements unreliable for a while. It does fix itself (until the next time it happens).
The other two main causes, which the anomaly message alludes to, are CPU overload causing samples to be dropped (this involves 1000x more samples - 100ms or more) or a bad receiver location (which shows up as clock synchronization offsets that jump around a lot, because synchronization requires accounting for the travel time of the ADS-B signal from the aircraft to the receiver, which depends on receiver location)
BTW - if you were looking specifically in the piaware logs for this - the reason you don’t see it with 2.1-2 is that the mlat-client shipped with 2.1-2 doesn’t understand the server status messages - so it is still happening, just you don’t get log messages about it.
Thank you for explaining. I’ve kept the mlat enabled but in the past 5 hours, it has only uploaded 16 mlat a/c to FA compared to quadruple that to what I’ve seen on my local web interface but has retained the anomaly throughout, as shown on my FA control panel.
It has to be a server unstable clock issue, as upon calculating the cpu % with the “top” command within putty, I have at least 40% cpu free and my receiver location is accurate to within a couple of feet, as I inputted my Lat and Lon for where my antenna/single dongle is situated.
No one else seems to have this problem using the same presumed setup. I just hope it can fix itself and become stable sooner rather than later 
It is actually relatively common (maybe 5-10% of receivers see it; of the two receivers I have running longterm here, one is affected and the other isn’t). It’s some sort of tolerance issue with the dongles, I suspect, where they are skirting close to the edge of the USB specs and depending on the particular Pi you plug it into and temperature variation and so on, sometimes it works, sometimes it doesn’t. Just something you have to live with.
Can some explain how the new stats are derived? One of my sites went from seeing 171,xxx total positions on Thursday to seeing 554,xxx on Friday. Aircraft seen went from 2,69x total aircraft on Thursday to 4,54x on Friday.
I find these increases too large to be valid.
flightaware.com/adsb/stats/user/ … stats-5844
Marty
The position rates for mlat and ADS-B are not comparable to each other, they use entirely different rules for deciding when to emit a position. Arguably they shouldn’t be totalled.
You’re right by KORD so it’s quite possible that half of the aircraft you see are Mode S only. What proportion of aircraft do you see with mlat positions on your local dump1090?
The ADS-B and MLAT comprise over 90%, split by about half for each. The rest are positionless.
Prior to this upgrade, were only ADS-B aircraft being counted in the stats?
Marty
Thanks Oliver. I’m using a Pi2 Mod B and cpu temp within the Pi is in the 20’s celcius and my dongle is currently 14 celcius.
It seems to have become stable overnight, as the anomaly has disappeared and currently synchronised with 50 or so receivers but as the traffic starts building throughout the day, the anomaly may reappear. I’ll just keep the mlat enabled, as you originally suggested.
Thanks again.
Oh right I think I see what you’re looking at.
The table data says that you are seeing about the same number of ADS-B and MLAT “aircraft seen”, and the ADS-B “aircraft seen” count hasn’t changed when stats changed over. That’s consistent with what you see locally - about a 50/50 split between ADS-B and MLAT - so I think those numbers are OK.
The “total”, which should be ADS-B + Mode S (old stats) or equivalently ADS-B + Mode-S-with-MLAT + Mode-S-without-MLAT (new stats) shows a big jump which is I think what you’re talking about? The new values seems approximately consistent with the ADS-B/MLAT numbers, so possibly there was a bug with the old total, or a reporting interaction with mlat (e.g. if the existence of mlat results ended up causing piaware to suppress the normal Mode S reports). I’ll take a closer look later.
Thanks! I looked at some European feeders and they do not have these large increases in the last couple of days. I suspect this is the case because they see a large majority of ADS-B aircraft vs. positionless aircraft.
Marty
Yeah, the US environment has a lot more Mode-S-only aircraft.
Additionally, my other site, which is co-located with my site in question, does not have the large increase.
flightaware.com/adsb/stats/user/ … stats-2740
This site has better coverage since the antenna is in the attic, verses an antenna in the window of the other site, and it does not have MLAT enabled because it is an older Model B RPi and cannot handle the extra MLAT processing load.
Marty
Regarding the new stats totals, I think I understand the following. There are three types of aircraft in the total, ADS-B planes, Mode-S planes that have been MLAT’ed and Mode-S planes that for whatever reason have not been MLAT’ed. Consequently in the “flights” total ALL aircraft are added up whether they are MLAT’ed or not and ADS-B.
So my suggestion would be:
POSITIONS REPORTED and FLIGHTS REPORTED
ADS-B
MLAT
POSLESS
TOTAL
This way, mere mortals would not be confused. Love the new stats. Great job. K4AA