Hello, have been running my current configuration for awhile with no issues but several days ago started seeing the following message in the piaware log.
Feb 7 10:35:46 Rasp-ADSB2 piaware[486]: NOTICE from adept server: 13% of multilateration messages (UDP) are not reaching the server - check your network?
It would repeat a few times and appeared maybe once or twice during a 24 hour period. It has slowly gotten to repeating now constantly and is causing the mlat client to stop and restart. Its basically disabled the mlat client.
Feb 7 11:16:02 Rasp-ADSB2 piaware[622]: Starting multilateration client: /usr/lib/piaware/helpers/fa-mlat-client --input-connect localhost:30005 --input-type dump1090 --results beast,connect,localhost:30104 --results beast,listen,30105 --results ext_basestation,listen,30106 --udp-transport 70.42.6.197:9030:1536653464
Feb 7 11:16:02 Rasp-ADSB2 piaware[622]: mlat-client(2388): fa-mlat-client 0.2.10 starting up
Feb 7 11:16:02 Rasp-ADSB2 piaware[622]: mlat-client(2388): Using UDP transport to 70.42.6.197 port 9030
Feb 7 11:16:02 Rasp-ADSB2 piaware[622]: mlat-client(2388): Listening for Beast-format results connection on port 30105
Feb 7 11:16:02 Rasp-ADSB2 piaware[622]: mlat-client(2388): Listening for Extended Basestation-format results connection on port 30106
Feb 7 11:16:02 Rasp-ADSB2 piaware[622]: mlat-client(2388): Input connected to localhost:30005
Feb 7 11:16:02 Rasp-ADSB2 piaware[622]: mlat-client(2388): Input format changed to BEAST, 12MHz clock
Feb 7 11:16:03 Rasp-ADSB2 piaware[622]: mlat-client(2388): Beast-format results connection with ::1:30104: connection established
Feb 7 11:17:30 Rasp-ADSB2 piaware[622]: 23850 msgs recv’d from dump1090-fa (3347 in last 5m); 20929 msgs sent to FlightAware
Feb 7 11:18:03 Rasp-ADSB2 piaware[622]: NOTICE from adept server: 19% of multilateration messages (UDP) are not reaching the server - check your network?
Feb 7 11:22:05 Rasp-ADSB2 piaware[622]: NOTICE from adept server: 10% of multilateration messages (UDP) are not reaching the server - check your network?
Feb 7 11:22:30 Rasp-ADSB2 piaware[622]: 27314 msgs recv’d from dump1090-fa (3464 in last 5m); 24393 msgs sent to FlightAware
Feb 7 11:24:05 Rasp-ADSB2 piaware[622]: NOTICE from adept server: 20% of multilateration messages (UDP) are not reaching the server - check your network?
Feb 7 11:26:06 Rasp-ADSB2 piaware[622]: NOTICE from adept server: 30% of multilateration messages (UDP) are not reaching the server - check your network?
Feb 7 11:27:02 Rasp-ADSB2 piaware[622]: data isn’t making it to FlightAware, reconnecting…
Feb 7 11:27:02 Rasp-ADSB2 piaware[622]: multilateration data no longer required, disabling mlat client
Feb 7 11:27:03 Rasp-ADSB2 piaware[622]: fa-mlat-client exited normally
Feb 7 11:27:03 Rasp-ADSB2 piaware[622]: reconnecting in 49 seconds…
Feb 7 11:27:03 Rasp-ADSB2 piaware[622]: mlat-client(2388): Disconnecting from localhost:30005: Lost connection to multilateration server, no need for input data
Feb 7 11:27:03 Rasp-ADSB2 piaware[622]: mlat-client(2388): Exiting on connection loss
Feb 7 11:27:30 Rasp-ADSB2 piaware[622]: 30816 msgs recv’d from dump1090-fa (3502 in last 5m); 27576 msgs sent to FlightAware
Feb 7 11:27:52 Rasp-ADSB2 piaware[622]: Connecting to FlightAware adept server at piaware.flightaware.com/1200
Feb 7 11:27:52 Rasp-ADSB2 piaware[622]: Connection with adept server at piaware.flightaware.com/1200 established
Feb 7 11:27:52 Rasp-ADSB2 piaware[622]: TLS handshake with adept server at piaware.flightaware.com/1200 completed
Feb 7 11:27:52 Rasp-ADSB2 piaware[622]: FlightAware server certificate validated
Feb 7 11:27:52 Rasp-ADSB2 piaware[622]: encrypted session established with FlightAware
Feb 7 11:27:53 Rasp-ADSB2 piaware[622]: logged in to FlightAware as user makeitwrite
Feb 7 11:27:53 Rasp-ADSB2 piaware[622]: my feeder ID is 007839be-a49d-43fc-b1ec-a445e24f7a5d
Feb 7 11:27:53 Rasp-ADSB2 piaware[622]: site statistics URL: makeitwrite ADS-B Feeder Statistics - FlightAware
Feb 7 11:27:53 Rasp-ADSB2 piaware[622]: multilateration data requested
Feb 7 11:27:53 Rasp-ADSB2 piaware[622]: Starting multilateration client: /usr/lib/piaware/helpers/fa-mlat-client --input-connect localhost:30005 --input-type dump1090 --results beast,connect,localhost:30104 --results beast,listen,30105 --results ext_basestation,listen,30106 --udp-transport 70.42.6.254:5015:1408230772
Feb 7 11:27:53 Rasp-ADSB2 piaware[622]: mlat-client(2639): fa-mlat-client 0.2.10 starting up
Feb 7 11:27:53 Rasp-ADSB2 piaware[622]: mlat-client(2639): Using UDP transport to 70.42.6.254 port 5015
Feb 7 11:27:53 Rasp-ADSB2 piaware[622]: mlat-client(2639): Listening for Beast-format results connection on port 30105
Feb 7 11:27:53 Rasp-ADSB2 piaware[622]: mlat-client(2639): Listening for Extended Basestation-format results connection on port 30106
Feb 7 11:27:53 Rasp-ADSB2 piaware[622]: mlat-client(2639): Input connected to localhost:30005
Feb 7 11:27:53 Rasp-ADSB2 piaware[622]: mlat-client(2639): Input format changed to BEAST, 12MHz clock
Feb 7 11:27:54 Rasp-ADSB2 piaware[622]: mlat-client(2639): Beast-format results connection with ::1:30104: connection established
Feb 7 11:28:54 Rasp-ADSB2 piaware[622]: NOTICE from adept server: 32% of multilateration messages (UDP) are not reaching the server - check your network?
Feb 7 11:29:54 Rasp-ADSB2 piaware[622]: NOTICE from adept server: 16% of multilateration messages (UDP) are not reaching the server -
There is noting I have done to the network at all, but I have 1) repooted the pi, forced it to a 2nd AP I have, rebooted the router, etc… and no change. Any way to check connections back to flightaware?? other log files seem OK - Any suggestions appreciated.
Thanks for the rapid reply. Yes, possible - signal level reasonable but now notice excessive transmit retries… Also, I have dual band AP’s but I never noticed the PI connect via 5G…
wlan0 IEEE 802.11 ESSID:“xxxxxxxxxxxxx”
Mode:Managed Frequency:5.18 GHz Access Point: xx:xx:xx:xx:xx:xx
Bit Rate=60 Mb/s Tx-Power=31 dBm
Retry short limit:7 RTS thr:off Fragment thr:off
Power Management:on
Link Quality=33/70 Signal level=-77 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:15465 Invalid misc:0 Missed beacon:0
I’m gonna try and switch to 2.4G and see if its more stable…
You can also try reorienting the Pi, that can improve reception quite a bit.
(The antenna built into the board obviously has a lot of Raspberry Pi in the way at least in one direction.)
I’m not sure you can force a frequency selection without giving the different frequencies different names in the AP configuration.
It is also always worth trying another power supply, pretty much no matter the problem with the RPi
That was it - For some reason the PI’s WiFi adapter switched from 2.4Ghz to 5Ghz a few days ago (AP’s here are dual band and devices will switch occasionally I guess due to interference or congestion) and that is when the issue started. 5Ghz has better bandwidth, but less range. My PI is outside, about 80 feet from the closest indoor AP so signal strength is marginal at best even at 2.4Ghz and it obviously wasn’t smart enough to switch back to 2.4Ghz…
I just ran sudo iwconfig wlan0 freq 2.422G and for the last 45 minutes has been fine. I’ll try to reorient the PI but not sure which way (??) - I assume point the ‘top’ flat / main circuit side / of the PI toward the AP?
As long as the side USB ports or the power input aren’t pointing towards the AP you are good.
At least that is my impression, mostly trial and error anyway.
I’m not sure if the frequency setting sticks after a reboot or it may even switch again to 5 without a reboot.
Only solution i know of is to give the 2 and 5 GHz WLANs different names.
(mywifi2 and mywifi5 for example)
Makes the automatic switchover unlikely if the connections is not lost completely though. I still prefer picking it manually.
On the pi you can then define priorities in the wpa_supplicant.conf if you use that.
I’ll keep trying to research ways of making iwconfig changes persistent which seems the ideal way to approach this. I have a wireless network (UniFi USG router and 2 UniFi Pro AP’s) where the same SSID is used for everything and clients are free to roam between AP’s and between bands. I’m pretty sure I can create a 2nd unique SSID and apply it on the 2.4Ghz radios only / not of the 5Ghz radios, and tie the new SSID to the PI only. It seems excessive for one device and not sure of performance impact of having multiple SSID’s on the hardware but it seems like it might be a way to set once and forget it… My USG controller keeps detailed event logs and I just find it odd that after many months of stability on 2.4Ghz, it decides to switch bands just a few days ago for the first time… May just let it sit to see if it happens again…
Appreciate all the assistance !!
All the best,
There’s no penalty performance wise. Save both names in the desired devices and they will choose the stable one.
My router has band steering too, moves devices from one 5GHz band to another 5GHz based on load. Has two 5GHz radios and one 2.4
# freq_list: Array of allowed frequencies
# Space-separated list of frequencies in MHz to allow for selecting the BSS. If
# set, scan results that do not match any of the specified frequencies are not
# considered when selecting a BSS.
#
# This can also be set on the outside of the network block. In this case,
# it limits the frequencies that will be scanned.
#
Never knew that… Well, I added the line and included all 11 channels on 2.4Ghz and did a sudo reboot and comes up with no complaints… It selected the 1st channel (1) in the list so wonder if it tries the scan in order. Also wonder if this is only during a full network restart like a reboot. I’ll leave as is and keep an eye on it - Many thanks.
wpa_supplicant settings are active permanently, not just on reboot.
In the standard raspbian configuration wpa_supplicant is invoked by dhcpcd, but that doesn’t matter.
Pretty sure it scans all listed channels.
Which channels are your 2.4 GHz networks on anyway, you have two right?
If you want you could probably make two network entries with the same SSID, different frequency lists (for example just one frequency), and then give the network blocks different priorities.
you can check signal strength like this:
wpa_cli -i wlan0
scan
# wait a bit till the results are in
scan_results
Could well be that channel 1 just had the strongest signal
(Also i think this freq_list option is new, couple years back i googled a lot for an option like this and i’m sure it didn’t exist, was quite surprised when i found something on google!)
Doing the scan (besides showing my immediate neighbors SSID’s…) , channel one is indeed the strongest signal of the 2 AP’s I have on 2.4Ghz. so all good. I’ll leave this as is and keep adding the additional SSID in my back pocket just in case. Yes, love google for everything except self medical diagnosis…
