Thanks Oliver, I guess that means this thread is effectively dead now 
Thanks Oliver, I guess that means this thread is effectively dead now
…well, actually, possibly not!
I’ve noticed a recurrence of a connection problem since 17:38:14 yesterday.
I get this repeated about every 5 minutes…
@obj should I reboot my raspberry Pi(s) to pick up a new configuration following the rebalancing?
Perhaps I am still pointing at stale addresses? I certainly have no network problems for other applications, despite the “check your network” NOTICE from adept server.
UPDATE:
I’ve just looked in my /var/log/piaware.log and suspiciously it appears that around time 17:38 it looks like fa-mlat-client started up a transport connection to cetgu.hou.flightaware.com [70.42.6.224] for the UDP
In one way I’m surprised I’m not connecting to a more local node (for me 20 hops, min 106 ms), but I’m hardly unsurprised that I am seeing "multilateration messages (UDP) are not reaching the server " with such a long route being used. Is this a case of: Houston, we have a problem ? 
Needs more context, what happened before the “lost connection” message?
Also check the beast-splitter logs.
There is no more local node; all the servers are located in a Houston datacenter.
25% packet loss is enough to make TCP completely unusable (anything above single digits is enough to do that), you won’t be getting that sort of loss on the route as a whole; something is preferentially dropping UDP, which is somewhat expected. Mlat doesn’t really care about the packet loss, other than the obvious effect that the lost messages can’t be used for multilateration.
Thanks @obj I have rebooted my pi for site 117925 around 11:17 and have not seen the loss of UDP messages since. The only difference appears to be I am now connecting to a different port.
Using UDP transport to 70.42.6.224 port 11700
To expedite matters I’ll just reboot my other site and hopefully the issue will be resolved.
UPDATE:
Both sites now behaving correctly. No loss of UDP messages. All seems fine.
Still MLAT problems?
PiAware has been showing some strange tracks. I had a zig-zag KLM plane, but didn’t get a screenshot. And now this guy.
Odd enough, my VRS did get it right. FR24 confirms that route to. Could not find the plane on FA’s map. (DTR170/OY-RUO)
You might be getting MLAT results from another MLAT network.
Where you might be unfortunately located at a zone boarder which tends to give some not so great MLAT results at least in one direction.
In case of adsbexchange, you can just put a # in front of this line:
RESULTS="--results beast,connect,localhost:30104"
in this file:
/etc/default/adsbexchange
Thanks,
I’ll look further at it.
What I don’t understand is… How did VRS calculate the correct route, while PiAware didn’t? The info must come from the same place?
Why?
Where is VRS getting the data?
From ip-of-the-pi:30105 Are there other MLAT instances?
Yes there are if you feed for example adsbexchange or radarbox.
radarbox will by default not show you the results i believe, but adsbexchange will.
(that’s why i explained how to turn it off, you should also reboot after making the change)
So by default dump1090-fa (which is what you see when you look at the skyaware page) has an open port 30004 where it accepts input data.
Normally via that you get FA mlat results.
In your case you are also getting mlat results from a second MLAT process fed in via that port.
Arhh, that makes more sense now 
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.