Some of the parameters that the FlightAware multilateration system uses are changing today (the 20th)
This may produce changes to where multilateration can be done, in particular in areas with fewer receivers.
(it is a tradeoff of coverage vs. reliability)
So my MLAT stats will likely go down and other will go up then? Not a lot of receivers in my area.
Some will go down, none will go up.
We’re trying to decrease the number of very bad positions.
Is this a failure of feeder site internet connections or something else?
No, nothing to do with feeder site internet connections.
no MLAT on FF v6.4 ???
Probably a good thing, I get some pretty wild MLAT results sometimes.
Can you elaborate a little on what this changes are?.
What are the new parameters to get MLAT working?
P.S.
When will the upgrade from FF V6.4 to v7.X come out? 
The changes are entirely server side. No changes on the client side to get MLAT working.
I’ve been pretty impressed with MLAT performance when the plane is flying fairly straight. One plane flew overhead the other day and MLAT was reasonable accurate to its position (showed it flying two residential blocks over and residential blocks are small where I live). When the plane is landing on the runway, it shows it landing no worse than the parallel taxiway to the main runway so it’s within several hundred feet. When a plane is turning like getting ready to make its final approach or turning just after takeoff, I do get some weird positions but you can still see it’s a general curve if you smooth out the positions in your head.
Does MLAT stop at wheel touch? I notice there doesn’t seem to be any MLAT activity when a plane is taxiing and you’d think maybe there is the opportunity to MLAT its taxiing if you can get enough feeders to receive ADS-B while the aircraft is on the ground in order to MLAT it.
In theory ground messages should be multilaterated, but the behaviour of the transponders does change at touchdown so it may just be that there aren’t enough messages seen by all receivers to be useful.
The class of error we are trying to eliminate here are where an aircraft first enters multilateration coverage and there are two solutions that fit well (because the geometry of the receivers versus the aircraft is poor); the wrong solution can be tens of miles away from the right solution.
The poor performance for aircraft that are maneuvering is a known problem, it is because the current solver assumes a constant-velocity model for the aircraft, really it should switch to a constant-turn-rate model when it decides that the aircraft is turning but that’s not an entirely trivial problem.
Indeed. I see this effect come up frequently when observing NATO fighter jets training over Germany. They maneuver quite hard and the MLAT algorithms have difficulty keeping up. This yields some interesting tracks.
Of course, that’s an extreme example and I don’t expect a system optimized for tracking predictable civil aircraft to accurately track fighter jets. I just thought it’d be interesting to mention.
The MLAT system does much better tracking the NATO AWACS airborne radar aircraft and tankers, since they just tool around in circles or racetrack patterns, respectively.
What determines how many and which receivers my receiver is synced with? my system untouched by me varies between 1 and 6 nearby receivers.
The number of nearby mlat-enabled receivers that can see frequent ADS-B position messages that your receiver also sees. So it depends on where nearby ADS-B equipped aircraft are.
Was there another adjustment 5/27-5/28? I’m seeing a noticeable drop in MLAT aircraft seen (and a slight jump in other aircraft seen).
No changes, but it’s a long weekend so it may be a real change in the flight patterns.
Something changed in my area. I looked at several other Daily Collection Graphs in the KBWI vicinity and they display a distinct change in Aircraft Seen between 5/27 and 5/28. MLAT Aircraft Seen drops and Other Aircraft Seen increases. Even after the holiday weekend it’s clear that they are continuing with this trend.