OK folks, what could be causing this?
MLAT is enabled but I’m getting not synchronised.
Aircraft and messages/second are the highest they’ve been for a long time but not as high as they were last summer.
As a result of this, my ‘other’ count is going up and I don’t like that.
Airspy options are
OPTIONS= -v -f 1 -e 9.9 -w 5 -t 300
I don’t have any lost samples.
Is this just a case of -e being fractionally too high, should I drop it a knats?
Is it possible that there aren’t enough MLAT aircraft in range for MLAT to work?
My MLAT keeps dropping and then resyncing this afternoon
Currently I am synced with 3 nearby receivers, whereas I am normally synced with about 1000
That’s pretty unlikely for his receiver range, but the full log entry would confirm. I’m seeing the same issue:
Jul 17 15:33:40 adsbpi piaware[918]: mlat-client(2075): Receiver status: connected
Jul 17 15:33:40 adsbpi piaware[918]: mlat-client(2075): Server status: not synchronized with any nearby receivers
Jul 17 15:33:40 adsbpi piaware[918]: mlat-client(2075): Receiver: 2042.5 msg/s received 354.5 msg/s processed (17%)
Jul 17 15:33:40 adsbpi piaware[918]: mlat-client(2075): Server: 0.1 kB/s from server 0.0kB/s TCP to server 4.2kB/s UDP to server
Jul 17 15:33:40 adsbpi piaware[918]: mlat-client(2075): Results: 34.1 positions/minute
Jul 17 15:33:40 adsbpi piaware[918]: mlat-client(2075): Aircraft: 22 of 82 Mode S, 87 of 121 ADS-B used
Looks like there is some problem with the server, since the client is reporting sending data.
Unlikey, considering the amount of aircraft there are.
I wonder if this is a backend issue. I’m seeing similar at the MTG receiver.
I have something similar here at least every 30 minutes all day I’ve been getting…
[2020-07-17 16:18 BST] reconnecting to beast-splitter
[2020-07-17 16:18 BST] faup1090 exited normally
[2020-07-17 16:18 BST] lost connection to beast-splitter via faup1090
The traffic definitely seems up today here, wonder if we are hitting some sort of load balance / server overload situation? Another thread reported an issue with RED MLAT indicator this morning.
I’ve had 11 occurrences of…
Server status: synchronized with NNN nearby receivers
…since 14:20, where NNN for me is in the range 750 to 950 (the latter more typical)
See also:
This may or may not be significant, but certainly a coincidence, my MLAT dropped to zero at the moment I hit a peak message rate (2066)…
My situation is different to yours but as you can see from my stats, I’ve actually seeing more MLAT messages than usual recently.
This is also apparent in VRS where about 30% of the total messages I’m receiving currently are MLAT when normally it is only about 10%.
I’m currently synced with more than 830 other stations on each receiver.
That doesn’t sound like a backend issue to me - unless it is due to our different locations.
This is being discussed here:
The problem has been fixed already several hours ago.
Thanks - It hadn’t been fixed when I posted and I hadn’t seen the other thread.
MLAT is still playing up again today
Seems to be localized to your MLAT node, not seeing the same in Germany.
Same here, but not necessarily at the same time as @keithma is seeing it.
One of the mlat server regions is, indeed, overloaded. I’m looking at rebalancing the load now (once that is done, you will likely see fewer synchronized receivers - that’s expected)
Thanks - The number isn’t really important and this sort of figure has always seemed a bit high really.
I’m also seeing higher numbers of synchronized nearby receivers just recently
But I’m also noticing practically NO (or at least very little) mlat before 8:15 am
It’s almost like somebody’s flicked a switch: then the mlat starts picking up and my synchronized nearby receivers then reduces to more typical numbers.
I’m assuming the overload in this mlat server region is also causing this symptom?
I have this affect especially on Saturdays/Sundays (especially with good weather conditions) with all that recreation flights. Start somewhere in the morning and goes until the afternoon. Most of these are reported on my receiver as MLAT.
much less during weekdays.
Development last eight hours:
Looks like the load balancing kicked in fully around 15:20z as that’s when my synchronised receivers dropped from over 1000 to around 600. It had been varying between 600 and 1000 since 12:00z but stabilised from around 15:20z onwards.
I’ve not seen any loss of sync since then, thank you @obj
Sounds good. The switching between 600 and 1000 would have been when the original region was overloaded, but you were also connected to the new region which was OK (previously, this would have dropped to “not synchronized”, rather than 600). The permanent drop at ~1520Z was when the old region was finally turned off after everything had migrated to the new regions.
There’s now a similar migration in progress for some other regions which were also approaching capacity.
According to my notes, the last rebalancing was over 3 years ago, at least I don’t have to do this often 
