MLAT stopped working with the message lat/lon not set. The log says “no ADS-B data program seen listening on port 30005”. The service was running for months without issues. Settings for lat/lon (to 5 decimals) has not changed. I’ve reinstalled dump1090-fa, piaware and rebooted, but mlat still does not work. I swapped power supplies with another working system. Same results.
You have larger problems than mlat then - dump1090 itself isn’t running. Often means a hardware problem where it can’t see the dongle.
1 Like
The check uses netstat if i’m not mistaken and requires root or sudo?
But i’m not certain if that check is used before starting the mlat-client.
First check there is data on 30005:
view1090-fa
interrupt with Ctrl-C
Then check piaware / MLAT:
sudo systemctl restart piaware
sleep 20
sudo journalctl --no-pager -u piaware
This should maybe give a clue?
Actually looking at your screenshot, the precision for the -82.72 seems insufficient.
Use 5 decimals for each.
Google Maps - Find GPS coordinates, longitude, latitude, altitude
There is a continuous stream of data seen by view1090-fa.
My actual configured location is lat 28.03396 lon -82.72000. It has worked flawlessly since the initial Buster setup.
Here are the last 20 entries from the piaware log.
Blockquote
Mar 21 13:02:53 CS4 piaware[30584]: 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.198:19263:2935388399
Mar 21 13:02:53 CS4 piaware[30584]: mlat-client(30669): fa-mlat-client 0.2.11 starting up
Mar 21 13:02:53 CS4 piaware[30584]: mlat-client(30669): Using UDP transport to 70.42.6.198 port 19263
Mar 21 13:02:53 CS4 piaware[30584]: mlat-client(30669): Listening for Beast-format results connection on port 30105
Mar 21 13:02:53 CS4 piaware[30584]: mlat-client(30669): Listening for Extended Basestation-format results connection on port 30106
Mar 21 13:02:53 CS4 piaware[30584]: mlat-client(30669): Route MTU changed to 1500
Mar 21 13:02:53 CS4 piaware[30584]: mlat-client(30669): Input connected to localhost:30005
Mar 21 13:02:53 CS4 piaware[30584]: mlat-client(30669): Input format changed to BEAST, 12MHz clock
Mar 21 13:02:54 CS4 sudo[30672]: piaware : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/bin/netstat --program --tcp --wide --all --numeric
Mar 21 13:02:54 CS4 sudo[30672]: pam_unix(sudo:session): session opened for user root by (uid=0)
Mar 21 13:02:54 CS4 sudo[30672]: pam_unix(sudo:session): session closed for user root
Mar 21 13:02:54 CS4 piaware[30584]: ADS-B data program ‘dump1090-fa’ is listening on port 30005, so far so good
Mar 21 13:02:54 CS4 piaware[30584]: Starting faup1090: /usr/lib/piaware/helpers/faup1090 --net-bo-ipaddr localhost --net-bo-port 30005 --stdout --lat 28.034 --lon -82.720
Mar 21 13:02:54 CS4 piaware[30584]: Started faup1090 (pid 30681) to connect to dump1090-fa
Mar 21 13:02:54 CS4 piaware[30584]: UAT support disabled by local configuration setting: uat-receiver-type
Mar 21 13:02:54 CS4 piaware[30584]: mlat-client(30669): Beast-format results connection with ::1:30104: connection established
Mar 21 13:02:54 CS4 piaware[30584]: piaware received a message from dump1090-fa!
Mar 21 13:02:55 CS4 piaware[30584]: piaware has successfully sent several msgs to FlightAware!
Mar 21 13:03:25 CS4 piaware[30584]: 400 msgs recv’d from dump1090-fa; 400 msgs sent to FlightAware
Mar 21 13:08:25 CS4 piaware[30584]: 3287 msgs recv’d from dump1090-fa (2887 in last 5m); 3287 msgs sent to FlightAware
pi@CS4:~ $
After MLAT spontaneously stopped working yesterday, it spontaneously started working again. In the past 4 hours there were no changes of any kind. Go figure.
Your statistics do not seem to have a break in MLAT aircraft, if this is site 101435 which it appears to be.
Strange that it was feeding MLAT data whilst giving that message.
You are correct. I just looked at the station stats. They did not show an MLAT interruption, but they didn’t show a synchronization count either. Currently the stats show synchronization with 276 nearby receivers.
Those logs look fine to me. Without logs from the time of the problem there’s not much that can be diagnosed.
The issue occurred again with piaware 3.8.1. The MLAT button is red, but the graphs show MLAT activity. The piaware.log is here.
I had a similar thing yesterday when upgrading to 3.8.1 on Buster. I didn’t wait for long enough to notice if MLAT positions were being reported, and just rebooted due to a Piaware restart not fixing it.
1 Like
Hi all. Just thought I’d share my experience with this in case someone lands up here from Google et al and the solutions abovve don’t work.
My experiencce with MLAT not working started when I moved from my RPi4 to an Intel NUC. Lots happened - architecture change and OS change.
I noticed MLAT was working for a few moments after reboot, then dropped off.
My solution was to change NTP servers from the default configured in Ubuntu Server to NTP servers closer to my location. This resulted in more stable time sync and the restoration of MLAT positions. Haven’t had MLAT position issues since.
2 Likes