Did the upgrade to 5.0 and now the MLAT box is red. Will it start working again or do I need to do something?
I think there may be backend issues.
I noticed my 2 sites both had red mlat status earlier this morning, and raised a helpdesk incident with flightaware.
Looking into it now.
edit: Should be fixed now, check again?
All good here, both of my sites now showing “Green” MLAT statuses.
Hopefully also issue is resolved for OP.
Yep, MLAT up and running.
Can you elaborate, @obj?
I’ve been having the same issue and folks said it was hardware related even though it only appeared after the 5.0 upgrade. At first I thought it might have to do with a new trunked internet connection but you said even MLAT packets were self-contained so wouldn’t be a factor.
So my MLAT goes red after the 5.0 upgrade and it’s my hardware, but A1TopGun goes red and it’s a fixable back end issue? What is different?
We recently (last few days) added some new endpoint servers that were in a new IP allocation; the backend mlat server firewalls hadn’t been updated for the new range, so the endpoint servers couldn’t reach them.
That’s great and all, but could this have been why my MLAT flag was turning red and a reboot would fix it?
Possibly more to the point, mlat’d aircraft are only appearing on ‘SkyAware Anywhere’ but they don’t appear on locaaly on PiAware SkyAware. Looking at PH-EZO specifally now which close to Hull at FL290
I also don’t seem to have any feed on 30105 anymore.
Well, you did ask me to elaborate. It wouldn’t have caused the behaviour you describe; it was an all-or-nothing problem (on affected systems, the mlat client wouldn’t even have started). The server-side changes also only happened very recently, well after the 5.0 release and your upgrade (the timing the OP saw was coincidence)
Having clock-sync problems that a reboot “fixes” is fairly normal if you have marginal hardware. The mlat server takes a while to decide that your data is unreliable; rebooting resets that decision. Alternatively, if the unreliability goes away, the server will eventually start using it again without needing to reboot/reconnect, but this can take a while before the server trusts you enough. So a reboot/reconnect might make you think that it was the reconnection that “fixed” the problem, rather than the actual situation which is you have hardware that is intermittently unreliable and you caught it at a point where it was reliable again, but the server hadn’t reached that decision yet.
tl;dr: you have a different problem than the OP.
This implies that mlat itself is OK but there’s a problem in the bit of the infrastructure that feeds results back to piaware. There’s nothing obviously wrong from a quick look, it will be Tuesday before I can take a proper look.
Something may have just changed.
I’ve just had a very small feed on 30105 & one aircraft has appeared that’s mlat.
obj - you may have done something ??
@spotter1844 Can you take a screenshot next time you see an MLAT aircraft on Skyaware Anywhere? There should not be MLAT aircraft at this moment. We are currently look at the issue.
We’ve resolved an issue on the backend that fixes some connections that feed MLAT to you.
Thanks for keeping keen eye and let us know if you see anymore issues
I’ve been out for that few hours so haven’t seen one since.
However, mlats are now on my PiAware SkyAware and on 30105
I am also having problems with Mlat my status say’s Multilateration (MLAT): Supported / Enabled but know sync? Also on the Local page the Mlat is in orange and says no clock syncronization ? Can someone tell me the terminal cmd to check if mlat is working please.