I recently tried to move my RPI to my office. Once there PiAware wouldn’t start. I relocated the whole setup back home with the same results. I wiped and re-installed everything but now I’m getting erroneous messages in the log files and it’s not pushing the MLAT data out even though it seems to be running on dump1090 if I view with ./view1090. Everything worked perfectly before I moved it. I have ordered a second RPI to use to rebuild again as I don’t want to shut my present feeder down even though it’s got some obvious errors.
I’m a confessed noobie to PiAware and RPI and haven’t done command line UNIX in 15+ years, I sorta remember some stuff but not enough to correctly diagnose and resolve these issues. Any help would be greatly appreciated!
last log file capture…
[2015-12-20 21:15 CST] mlat(15007): Exiting on exception
[2015-12-20 21:15 CST] mlat(15007): Traceback (most recent call last):
[2015-12-20 21:15 CST] mlat(15007): File “/tmp/buildd/piaware-2.1/debian/venv/bin/fa-mlat-client”, line 48, in
[2015-12-20 21:15 CST] mlat(15007): File “/tmp/buildd/piaware-2.1/debian/venv/bin/fa-mlat-client”, line 40, in main
[2015-12-20 21:15 CST] mlat(15007): File “/tmp/buildd/piaware-2.1/debian/venv/lib/python3.2/site-packages/mlat/client/options.py”, line 156, in build_outputs
[2015-12-20 21:15 CST] mlat(15007): File “/tmp/buildd/piaware-2.1/debian/venv/lib/python3.2/site-packages/mlat/client/output.py”, line 38, in init
[2015-12-20 21:15 CST] mlat(15007): File “/usr/lib/python3.2/asyncore.py”, line 342, in bind
[2015-12-20 21:15 CST] mlat(15007): socket.error: [Errno 98] Address already in use
[2015-12-20 21:15 CST] got EOF from multilateration client
[2015-12-20 21:15 CST] the system told us that process 15007 exited cleanly
[2015-12-20 21:15 CST] the system confirmed that process 15007 exited with an exit status of 0
There might be other issues but right off the bat I see some oddness. You have software running from the /tmp directory; I would expect those files to be under your user home directory. The /tmp directory is wiped clean every time the system boots. This likely explains why when you shut down your system and took it to the office it didn’t work. You may want to start completely fresh, and if you aren’t comfortable with the setup, follow the step by step instructions at
One more thing, I don’t believe you need a new RPi, but you might want a new SD card. One safe way to start fresh is to leave your existing SD card alone, go pick up a new SD Card, and then follow the install instructions from the link using the new card.
The /tmp thing is not an issue, those are not the real paths in use, they are the paths that were used when freezing fa-mlat-client during the package build.
The socket error means that you have specified a listening port via “piaware-config -mlatResultsFormat” that is already in use by something else on the system.
You can reset that setting to the default setting (which does not listen) by “sudo piaware-config -mlatResultsFormat default”, then restart piaware.
Thanks, I have a new SD card, just don’t want to shut the feeder down to rebuild, also wanted to have feeder at home and office. Office has 360 degree clear view of the sky and I already mounted an antenna 10’ above the uppermost part of the roof on an existing structure.
Are you saying that I need to just run sudo piaware-config -mlatResultsFormat default? Will that affect the other configuration options? I.e. beast, local host etc… Or just change the listening port? Either way I just want to run the simplest, easiest and most reliable way. I’ll give it a whirl and see if it solves my problem. Maybe I’m over complicating my setup unnecessarily
I just ran “sudo piaware-config -mlatResultsFormat default” and Shazam!.. MLAT is now populating on the stats chart! I haven’t been able to check the log files to see if I’m still getting errors but my guess is that it’s resolved too. That’ll teach me to get all fancy with my “mlatResultsFormat” commands… I should have just left it alone.
I’m slowly getting the hang of RPI/PiAware and I actually haven’t had this much fun/stress since I left IT in 2k
“default” is the same as “beast,connect,localhost:30104” in the current version.
If you also want a basestation listener for mlat results (e.g. to feed VRS separately), the settings you had were OK except that they try to use port 30005, which is already used by dump1090. Pick another port e.g. 30106. There’s a more comprehensive guide here: ads-b-flight-tracking-f21/vrs-show-both-dump1090-adsb-and-fa-mlat-positions-t36086.html
Just turned over 0 hours and the got a timing error, I restarted everything and now I’m getting…
2015-12-21 18:16 CST] Starting multilateration client: /usr/lib/piaware/helpers/fa-mlat-client --input-connect localhost:30005 --results beast,connect,localhost:30104 --udp-transport 70.42.6.198:5045:2737755693
[2015-12-21 18:16 CST] mlat(958): fa-mlat-client 0.2.4 starting up
[2015-12-21 18:16 CST] mlat(958): Using UDP transport to 70.42.6.198:5045
[2015-12-21 18:16 CST] mlat(958): Input connected to localhost:30005
[2015-12-21 18:16 CST] mlat(958): Beast-format results connection with localhost:30104: connection established
[2015-12-21 18:17 CST] 0 msgs recv’d from dump1090; 0 msgs sent to FlightAware
[2015-12-21 18:19 CST] mlat(958): Disconnecting from localhost:30005: No data (not even keepalives) received for 150 seconds
[2015-12-21 18:19 CST] mlat(958): Input connected to localhost:30005
[2015-12-21 18:21 CST] mlat(958): Disconnecting from localhost:30005: No data (not even keepalives) received for 150 seconds
[2015-12-21 18:21 CST] mlat(958): Input connected to localhost:30005
I haven’t set anything to 30005, I know dump1090 is running and collecting data, I have no idea why it’s not feeding Flightaware… any thoughts?
30005 is the data port where dump1090 provides all its data on. piaware and fa-mlat-client are not seeing any data on that port. Do you see data on the dump1090 map? Check your antenna connections.
If I run ./view1090 it’s streaming tons of data & when I stop and restart dump1090 I can see the data running just fine. For some reason the internal web server isn’t running correctly so I can’t pull up a map.
piaware currently insists on connecting to 30005 for data.
You should investigate why dump1090 is not producing data there. (you should be able to verify that there’s no data with “nc localhost 30005”)
Another possibility is that it’s producing data, but in the wrong format. This would only happen if you’ve played with the dump1090 settings. piaware needs beast binary format data on 30005.
Yesterday I set the mlatResultsFormat -default and everything started working fine.
I just ran “nc localhost 30005” and got no result? When I ran netstat before reboot there were a number of items attached to 30005 but now when I run it I don’t even see 30005?
Ok, so that is consistent with what piaware and fa-mlat-client say: there is no data being produced on 30005.
I suggest you create a separate sdcard with an unchanged piaware image and check if that works OK. Everything here points to a configuration problem that you have introduced somehow; it’s hard to say what it is without knowing what you’ve actually changed.
I broke down and recreated the feeder on a new card and it looks as if everything is running again but now the MLAT stats are not getting populated on the web site (again). This is the problem I solved yesterday by setting the mlatResultsFormat to -default… WTH?
[2015-12-21 21:13 CST] autoUpdate in adept config is enabled, allowing update
[2015-12-21 21:13 CST] manualUpdate in adept config is enabled, allowing update
[2015-12-21 21:13 CST] multilateration support enabled (use piaware-config to disable)
[2015-12-21 21:15 CST] multilateration support enabled (use piaware-config to disable)
[2015-12-21 21:15 CST] multilateration data requested, enabling mlat client
[2015-12-21 21:15 CST] Starting multilateration client: /usr/lib/piaware/helpers/fa-mlat-client --input-connect localhost:30005 --results beast,connect,localhost:30104 --udp-transport 70.42.6.197:5739:644940432
[2015-12-21 21:15 CST] mlat(961): fa-mlat-client 0.2.4 starting up
[2015-12-21 21:15 CST] mlat(961): Using UDP transport to 70.42.6.197:5739
[2015-12-21 21:15 CST] mlat(961): Input connected to localhost:30005
[2015-12-21 21:15 CST] mlat(961): Beast-format results connection with localhost:30104: connection established
[2015-12-21 21:17 CST] 48 msgs recv’d from dump1090 (46 in last 5m); 38 msgs sent to FlightAware
[2015-12-21 21:18 CST] mlat(961): Disconnecting from localhost:30005: No data (not even keepalives) received for 150 seconds
[2015-12-21 21:18 CST] mlat(961): Input connected to localhost:30005
[2015-12-21 21:20 CST] mlat(961): Disconnecting from localhost:30005: N
[2015-12-21 21:30 CST] mlat(961): Receiver status: connected
[2015-12-21 21:30 CST] mlat(961): Server status: not synchronized with any nearby receivers
[2015-12-21 21:30 CST] mlat(961): Receiver: 0.0 msg/s received 0.0kB/s from receiver
[2015-12-21 21:30 CST] mlat(961): Server: 0.0 kB/s from server 0.0kB/s TCP to server 0.0kB/s UDP to server
[2015-12-21 21:30 CST] mlat(961): Aircraft: 0 of 0 Mode S, 0 of 0 ADS-B used
It keeps dropping the connection now and I’m getting the message that USB is occupied in /var/dump1090 log file . if I replug the dongle it runs for a little while and then drops. I know i’ve read about this on another post but don’t remember how I found it.
I rebuilt the SD card again, set up dump1090-mutability in init.d and it all seems to be running fine. (as a side note the auto config for init.d hangs on one of the last questions, and I have to kill the terminal)
I got a new Pi and tried to duplicate the setup so I could run it at my office. I had it working fine at home, moved it to my warehouse today and connected to rooftop antenna. It started populating fine then I got anomaly error about location being incorrect. I reset the LAT/LON using “select on map” then updated init.d with the same address. Now it’s not getting the amount of data I would expect. I can physically see aircraft at the warehouse location and my home setup is still cranking out the data but the warehouse Pi has only updated 2 MLAT positions in the last hour, normally it would have been several hundred.
I figured I’d let it run for a while just in case it needs to make nice with the FA connection, but so far no luck. It’s possible when I edited the init.d I moved a " or put a misplaced character in somewhere that is causing dump1090-mutability to pass over data.
[2016-01-01 09:32 CST] autoUpdate in adept config is enabled, allowing update
[2016-01-01 09:32 CST] manualUpdate in adept config is enabled, allowing update
[2016-01-01 09:32 CST] multilateration support enabled (use piaware-config to disable)
[2016-01-01 09:32 CST] multilateration support enabled (use piaware-config to disable)
[2016-01-01 09:32 CST] multilateration data requested, enabling mlat client
[2016-01-01 09:32 CST] Starting multilateration client: /usr/lib/piaware/helpers/fa-mlat-client --input-connect localhost:30005 --results beast,connect,localhost:30104 --udp-transport 70.42.6.197:5662:2251587093
[2016-01-01 09:32 CST] mlat(903): fa-mlat-client 0.2.4 starting up
[2016-01-01 09:32 CST] mlat(903): Using UDP transport to 70.42.6.197:5662
[2016-01-01 09:32 CST] mlat(903): Input connected to localhost:30005
[2016-01-01 09:32 CST] mlat(903): Beast-format results connection with localhost:30104: connection established
[2016-01-01 09:36 CST] 0 msgs recv’d from dump1090-mutabi (0 in last 5m); 0 msgs sent to FlightAware
[2016-01-01 09:41 CST] 0 msgs recv’d from dump1090-mutabi (0 in last 5m); 0 msgs sent to FlightAware
[2016-01-01 09:46 CST] 0 msgs recv’d from dump1090-mutabi (0 in last 5m); 0 msgs sent to FlightAware
[2016-01-01 09:47 CST] mlat(903): Receiver status: connected
[2016-01-01 09:47 CST] mlat(903): Server status: not synchronized with any nearby receivers
[2016-01-01 09:47 CST] mlat(903): Receiver: 0.0 msg/s received 0.0kB/s from receiver
[2016-01-01 09:47 CST] mlat(903): Server: 0.0 kB/s from server 0.0kB/s TCP to server 0.0kB/s UDP to server
[2016-01-01 09:47 CST] mlat(903): Aircraft: 0 of 0 Mode S, 0 of 0 ADS-B used
[2016-01-01 09:51 CST] 0 msgs recv’d from dump1090-mutabi (0 in last 5m); 0 msgs sent to FlightAware
[2016-01-01 09:56 CST] 0 msgs recv’d from dump1090-mutabi (0 in last 5m); 0 msgs sent to FlightAware
[2016-01-01 10:01 CST] 0 msgs recv’d from dump1090-mutabi (0 in last 5m); 0 msgs sent to FlightAware
[2016-01-01 10:02 CST] mlat(903): Receiver status: connected
[2016-01-01 10:02 CST] mlat(903): Server status: not synchronized with any nearby receivers
[2016-01-01 10:02 CST] mlat(903): Receiver: 0.0 msg/s received 0.0kB/s from receiver
[2016-01-01 10:02 CST] mlat(903): Server: 0.0 kB/s from server 0.0kB/s TCP to server 0.0kB/s UDP to server
[2016-01-01 10:02 CST] mlat(903): Aircraft: 0 of 0 Mode S, 0 of 0 ADS-B used
[2016-01-01 10:06 CST] 0 msgs recv’d from dump1090-mutabi (0 in last 5m); 0 msgs sent to FlightAware
[2016-01-01 10:11 CST] 0 msgs recv’d from dump1090-mutabi (0 in last 5m); 0 msgs sent to FlightAware
[2016-01-01 10:16 CST] 1 msgs recv’d from dump1090-mutabi (1 in last 5m); 1 msgs sent to FlightAware
[2016-01-01 10:17 CST] mlat(903): Receiver status: connected
[2016-01-01 10:17 CST] mlat(903): Server status: not synchronized with any nearby receivers
[2016-01-01 10:17 CST] mlat(903): Receiver: 0.0 msg/s received 0.0kB/s from receiver
[2016-01-01 10:17 CST] mlat(903): Server: 0.0 kB/s from server 0.0kB/s TCP to server 0.0kB/s UDP to server
[2016-01-01 10:17 CST] mlat(903): Aircraft: 0 of 0 Mode S, 0 of 0 ADS-B used
[2016-01-01 10:21 CST] 1 msgs recv’d from dump1090-mutabi (0 in last 5m); 1 msgs sent to FlightAware
[2016-01-01 10:26 CST] 2 msgs recv’d from dump1090-mutabi (1 in last 5m); 2 msgs sent to FlightAware
[2016-01-01 10:31 CST] 2 msgs recv’d from dump1090-mutabi (0 in last 5m); 2 msgs sent to FlightAware
[2016-01-01 10:32 CST] mlat(903): Receiver status: connected
[2016-01-01 10:32 CST] mlat(903): Server status: not synchronized with any nearby receivers
[2016-01-01 10:32 CST] mlat(903): Receiver: 0.0 msg/s received 0.0kB/s from receiver
[2016-01-01 10:32 CST] mlat(903): Server: 0.0 kB/s from server 0.0kB/s TCP to server 0.0kB/s UDP to server
[2016-01-01 10:32 CST] mlat(903): Aircraft: 0 of 0 Mode S, 0 of 0 ADS-B used
[2016-01-01 10:36 CST] 2 msgs recv’d from dump1090-mutabi (0 in last 5m); 2 msgs sent to FlightAware
[2016-01-01 10:41 CST] 2 msgs recv’d from dump1090-mutabi (0 in last 5m); 2 msgs sent to FlightAware
[2016-01-01 10:46 CST] 2 msgs recv’d from dump1090-mutabi (0 in last 5m); 2 msgs sent to FlightAware
[2016-01-01 10:47 CST] mlat(903): Receiver status: connected
[2016-01-01 10:47 CST] mlat(903): Server status: not synchronized with any nearby receivers
[2016-01-01 10:47 CST] mlat(903): Receiver: 0.0 msg/s received 0.0kB/s from receiver
[2016-01-01 10:47 CST] mlat(903): Server: 0.0 kB/s from server 0.0kB/s TCP to server 0.0kB/s UDP to server
[2016-01-01 10:47 CST] mlat(903): Aircraft: 0 of 0 Mode S, 0 of 0 ADS-B used
[2016-01-01 10:51 CST] 2 msgs recv’d from dump1090-mutabi (0 in last 5m); 2 msgs sent to FlightAware
[2016-01-01 10:56 CST] 2 msgs recv’d from dump1090-mutabi (0 in last 5m); 2 msgs sent to FlightAware
Ok, so we are back to “dump1090 is not producing any data”. There’s not much that piaware or mlat-client can do about that, and nothing that piaware or mlat-client do will influence it. I think you need to investigate your USB cabling & power.
What, exactly, is dump1090-mutability logging? It’s probably telling you there are USB problems, and librtlsdr is unstable in the face of USB problems and can just outright hang.
