Just upgraded my PiZero to 6.0 about 5 hours ago and I noticed most of the time my homepage reports MLAT in Orange “local clock source is unstable” most of the time.
It sometimes turns green but only lasts a minute or two before going back to orange.
I configured adaptative gain both on and off, but the issue persists.
Any idea?
Thanks.
I have on-and-off loss of UDP traffic though the MLAT marker stays green. Just the triangle pops up.
Me to 11% upto 18%
really annoying
im sure we will sort it soon
Im between 10-12 percent.
What do those percentages mean?
Percentage of traffic lost between your feeder and the FA servers.
Low-ish loss is just the internet being the internet. If it starts getting above 20% there might be an issue.
No changes I can think of that would affect this. It’s probably confirmation bias. Check your power supply and USB connections, try a different dongle.
Is this what you sre talking about? If not, where you see that?
3.5 msg/s processed (71%) Sep 3 06:19:01 piaware piaware[675]: mlat-client(890): Receiver: 23.8 msg/s received 14.3 msg/s processed (60%) Sep 3 06:34:01 piaware piaware[675]: mlat-client(890): Receiver: 24.1 msg/s received 14.9 msg/s processed (62%) Sep 3 06:49:01 piaware piaware[675]: mlat-client(890): Receiver: 18.9 msg/s received 11.8 msg/s processed (63%) Sep 3 07:04:02 piaware piaware[675]: mlat-client(890): Receiver: 42.1 msg/s received 25.2 msg/s processed (60%) Sep 3 07:19:02 piaware piaware[675
I have the same issue after update on 2 different feeders, one withe Debian Pkg and Airspy Mini, the second Piaware SD card with RTL Dongle. Both showing warning messages after update and have seen up to 43% in the message…
Hey all, thanks for the reports… We’re looking into the issue and will keep you updated.
If you saw the UDP loss problem earlier, check if you’re still seeing it now (after 1528Z) – we asked one of our network providers to make some changes which should help.
There were some network changes done recently at about the same time as 6.0 was released, which is where some of the confusion is coming from (just an unfortunate coincidence with the timing)
Looks like it’s what i reported in a different thread already:
Now i have connected my Jetvision device which is still on PiaWare 5.0.
After rebooting the Repeater and reconnect of the device, the issue seem to be gone:
Sep 03 16:08:34 AirSquitter piaware[363]: mlat-client(686): Route MTU changed to 1492
Sep 03 16:08:54 AirSquitter piaware[363]: mlat-client(686): Route MTU changed to 1476
Sep 03 16:14:28 AirSquitter piaware[363]: mlat-client(1093): Route MTU changed to 1500
This was after i exchanged the devices. It started with the adept server notice. Then i rebooted the repeater:
Sep 03 16:08:32 AirSquitter piaware[363]: Connecting to FlightAware adept server at piaware.flightaware.com/1200
Sep 03 16:08:32 AirSquitter piaware[363]: Connection with adept server at piaware.flightaware.com/1200 established
Sep 03 16:08:32 AirSquitter piaware[363]: TLS handshake with adept server at piaware.flightaware.com/1200 completed
Sep 03 16:09:34 AirSquitter piaware[363]: NOTICE from adept server: 30% of multilateration messages (UDP) are not reaching the server - check your network?
Sep 03 16:10:34 AirSquitter piaware[363]: NOTICE from adept server: 27% of multilateration messages (UDP) are not reaching the server - check your network?
Sep 03 16:11:35 AirSquitter piaware[363]: NOTICE from adept server: 36% of multilateration messages (UDP) are not reaching the server - check your network?
Sep 03 16:12:35 AirSquitter piaware[363]: NOTICE from adept server: 29% of multilateration messages (UDP) are not reaching the server - check your network?
Sep 03 16:13:51 AirSquitter piaware[363]: Connecting to FlightAware adept server at piaware.flightaware.com/1200
Sep 03 16:13:51 AirSquitter piaware[363]: Connection to adept server at piaware.flightaware.com/1200 failed: couldn't open socket: Temporary failure in name resolution
Sep 03 16:13:57 AirSquitter piaware[363]: Connecting to FlightAware adept server at piaware.flightaware.com/1200
Sep 03 16:13:57 AirSquitter piaware[363]: Connection to adept server at piaware.flightaware.com/1200 failed: couldn't open socket: Temporary failure in name resolution
Sep 03 16:14:01 AirSquitter piaware[363]: Connecting to FlightAware adept server at 70.42.6.232/1200
Sep 03 16:14:01 AirSquitter piaware[363]: Connection to adept server at 70.42.6.232/1200 failed: couldn't open socket: network is unreachable
Sep 03 16:14:06 AirSquitter piaware[363]: Connecting to FlightAware adept server at 70.42.6.224/1200
Sep 03 16:14:21 AirSquitter piaware[363]: Connection attempt with adept server at 70.42.6.224/1200 timed out
Sep 03 16:14:26 AirSquitter piaware[363]: Connecting to FlightAware adept server at 70.42.6.156/1200
Sep 03 16:14:26 AirSquitter piaware[363]: Connection with adept server at 70.42.6.156/1200 established
Sep 03 16:14:26 AirSquitter piaware[363]: TLS handshake with adept server at 70.42.6.156/1200 completed
Time is UTC as the Jetvision gets it via GPS
With this PiaWare 5.0 device, i am getting only the warning about PiaWare itself:
Once i connect the Raspbery 4 where PiaWare 6.0 is running, the errors are coming back.
Can you please confirm that it’s not a local issue and i can connect the RPi 4 again?
Here in US, Verizon FIOS (fiber to home), I don’t see any problems.
Good point, maybe only people from a specific region.
I am based in Germany, connected by “Deutsche Telekom”
UK BT Fibre to the home seeing the issue
Hi All,
i’ve just noticed the same issue myself. I am running a Pi4B hard cabled off a BT Router in the UK. (using SD Card Image ver 6)
I had no issues at all prior to upgrading to Version 6, the upgrade was good and the auto gain is working very well. (thank you:))
I am getting a continuous Anomaly warning now where it says i’m losing anywhere between 12 - 26% Mlat to flightaware…
I don’t know if this is assoc with the issue, when the Pi cold starts it identifies the correct MTU of 1492 for my home network. (This is hard set in the UK BT Router and cannot be changed).
When the mlat service starts it changes the MTU to 1476, then back again and toggles between the two. worst example is below…
[2021-09-03 16:40 BST] mlat-client(11351): Route MTU changed to 1492
[2021-09-03 16:41 BST] mlat-client(11351): Route MTU changed to 1476
[2021-09-03 16:51 BST] mlat-client(11351): Route MTU changed to 1492
[2021-09-03 16:52 BST] mlat-client(11351): Route MTU changed to 1476
Piaware is working fine i’m just concerned that not all my Mlat data is reaching Flightaware. It used to , but now some is going missing and there is nothing I can do my end to change it.
cheers Andy
I still have it in San Francisco Bay Area. MLAT has the green connection; just the triangle
Sep 03 09:45:03 raspberrypi piaware[16091]: NOTICE from adept server: 26% of multilateration messages (UDP) are not reaching the server - check your networ
Sep 03 09:46:04 raspberrypi piaware[16091]: NOTICE from adept server: 22% of multilateration messages (UDP) are not reaching the server - check your networ
Sep 03 09:47:04 raspberrypi piaware[16091]: NOTICE from adept server: 20% of multilateration messages (UDP) are not reaching the server - check your networ
Sep 03 09:48:05 raspberrypi piaware[16091]: NOTICE from adept server: 29% of multilateration messages (UDP) are not reaching the server - check your networ
Sep 03 09:49:05 raspberrypi piaware[16091]: NOTICE from adept server: 22% of multilateration messages (UDP) are not reaching the server - check your networ
We are aware of the MLAT UDP issues and are working on a fix.
I’m the original poster, based in Mexico City.
My log only shows the UDP problem for about one hour yesterday (probably a network problem). But the issue with MLAT staying orange (local clock ustable) most of the time persits.
Besides high temperatures (normal here), nothing wrong on any of my devices:
