FlightAware Discussions

No data since PiAware 6.0 update on RPi Zero W

Hi Folks,

Pre-September my Pi Zero W was happily reporting ~500 positions per day.

Since upgrading to 6.0, and subsequently 6.1, I’m not seeing any positions being reported into FA.

The system itself seems to be running just fine, dump1090 is running, mlat-client is running, everything is connected back to FA, it’s just not seeing any positions. Quick snippet from the logs:

Oct  5 07:45:24 piaware piaware[1783]: mlat-client(1802): Receiver status: connected
Oct  5 07:45:24 piaware piaware[1783]: mlat-client(1802): Server status:   not synchronized with any nearby receivers
Oct  5 07:45:24 piaware piaware[1783]: mlat-client(1802): Receiver:    0.0 msg/s received        0.0 msg/s processed (0%)
Oct  5 07:45:24 piaware piaware[1783]: mlat-client(1802): Server:      0.0 kB/s from server    0.0kB/s TCP to server     0.0kB/s UDP to server
Oct  5 07:45:24 piaware piaware[1783]: mlat-client(1802): Aircraft: 0 of 0 Mode S, 0 of 0 ADS-B used
Oct  5 07:45:42 piaware piaware[1783]: 0 msgs recv'd from dump1090-fa (0 in last 5m); 0 msgs sent to FlightAware
Oct  5 07:50:42 piaware piaware[1783]: 0 msgs recv'd from dump1090-fa (0 in last 5m); 0 msgs sent to FlightAware
Oct  5 07:55:12 piaware piaware[1783]: no new messages received in 3890 seconds, it might just be that there haven't been any aircraft nearby but I'm going to try to restart everything, just in case...
Oct  5 07:55:12 piaware piaware[1783]: faup1090 exited with SIG SIGHUP
Oct  5 07:55:12 piaware piaware[1783]: attempting to restart dump1090..
Oct  5 07:55:12 piaware piaware[1783]: attempting to restart dump1090-fa using 'systemctl --no-block try-restart dump1090-fa.service < /dev/null'...
Oct  5 07:55:13 piaware piaware[1783]: dump1090 restart appears to have been successful
Oct  5 07:55:14 piaware piaware[1783]: mlat-client(1802): Lost connection to localhost:30005
Oct  5 07:55:14 piaware piaware[1783]: mlat-client(1802): Reconnecting in 30.0 seconds
Oct  5 07:55:14 piaware piaware[1783]: mlat-client(1802): Beast-format results connection with 127.0.0.1:30104: connection lost
Oct  5 07:55:23 piaware piaware[1783]: ADS-B data program 'dump1090-fa' is listening on port 30005, so far so good
Oct  5 07:55:23 piaware piaware[1783]: Starting faup1090: /usr/lib/piaware/helpers/faup1090 --net-bo-ipaddr localhost --net-bo-port 30005 --stdout --lat 51.440 --lon -1.043
Oct  5 07:55:23 piaware piaware[1783]: Started faup1090 (pid 3745) to connect to dump1090-fa
Oct  5 07:55:43 piaware piaware[1783]: 0 msgs recv'd from dump1090-fa (0 in last 5m); 0 msgs sent to FlightAware
Oct  5 07:55:44 piaware piaware[1783]: mlat-client(1802): Input connected to localhost:30005
Oct  5 07:55:44 piaware piaware[1783]: mlat-client(1802): Input format changed to BEAST, 12MHz clock
Oct  5 07:55:44 piaware piaware[1783]: mlat-client(1802): Beast-format results connection with ::1:30104: connection established
Oct  5 08:00:24 piaware piaware[1783]: mlat-client(1802): Receiver status: connected
Oct  5 08:00:24 piaware piaware[1783]: mlat-client(1802): Server status:   not synchronized with any nearby receivers
Oct  5 08:00:24 piaware piaware[1783]: mlat-client(1802): Receiver:    0.0 msg/s received        0.0 msg/s processed (0%)
Oct  5 08:00:24 piaware piaware[1783]: mlat-client(1802): Server:      0.0 kB/s from server    0.0kB/s TCP to server     0.0kB/s UDP to server
Oct  5 08:00:24 piaware piaware[1783]: mlat-client(1802): Aircraft: 0 of 0 Mode S, 0 of 0 ADS-B used
Oct  5 08:00:42 piaware piaware[1783]: 0 msgs recv'd from dump1090-fa (0 in last 5m); 0 msgs sent to FlightAware
Oct  5 08:05:42 piaware piaware[1783]: 0 msgs recv'd from dump1090-fa (0 in last 5m); 0 msgs sent to FlightAware
Oct  5 08:10:42 piaware piaware[1783]: 0 msgs recv'd from dump1090-fa (0 in last 5m); 0 msgs sent to FlightAware

I spent some time yesterday tweaking some of the piaware-config settings to switch off adaptive dynamic range, set “slow -cpu” to “no”, also set rtlsdr-gain to “max”.

Any other things I should be looking at that might help here? It was running PiAware 5 as the SDcard image and upgraded with “apt dist-upgrade” first to 6.0 then to 6.1 when it was released.

Thanks

What do the dump1090-fa logs say? (journalctl -u dump1090-fa)

set “slow -cpu” to “no”

Your site is currently reporting 100% CPU use, so that may have been a bad idea (though a vanilla piaware sdcard image with no changes & adaptive gain off should not take that much…). Maybe take a look at top to see whether it’s dump1090-fa taking all the CPU or if you have some other runaway process there.

Agreed, possibly not the best idea but I turned it off yesterday to see if that was causing the issue.

100% CPU must be an occasional occurrence. not sure where the stats page is pulling that from, monitoring top for a while shows dump1090-fa sitting around 40% CPU, give or take 5% or so.

Nothing interesting in the dump1090-fa logs, just repeats the same info:

Oct 05 09:54:07 piaware dump1090-fa[7606]: Tue Oct  5 09:54:07 2021 BST  dump1090-fa 6.1 starting up.
Oct 05 09:54:07 piaware dump1090-fa[7606]: rtlsdr: using device #0: Generic RTL2832U OEM (Realtek, RTL2838UHIDIR, SN 00000001)
Oct 05 09:54:07 piaware dump1090-fa[7606]: Detached kernel driver
Oct 05 09:54:07 piaware dump1090-fa[7606]: Found Rafael Micro R820T tuner
Oct 05 09:54:08 piaware dump1090-fa[7606]: [R82XX] PLL not locked!
Oct 05 09:54:08 piaware dump1090-fa[7606]: rtlsdr: tuner gain set to about 58.6 dB (gain step 29) (tuner AGC enabled)
Oct 05 09:54:08 piaware dump1090-fa[7606]: [R82XX] PLL not locked!
Oct 05 09:54:08 piaware dump1090-fa[7606]: [R82XX] PLL not locked!
Oct 05 09:54:08 piaware dump1090-fa[7606]: Allocating 4 zero-copy buffers

That looks like a hardware problem with the dongle…

Unfortunately I can’t check any logs far back enough to see if that was happening pre-6.0.

Not sure how a software update would have caused a hardware issue though…

Correlation doesn’t necessarily equal causation. It could be that the dongle just chose that particular moment to malfunction if that’s what the problem is.

Why don’t you take a laptop with SDR software and driver installed to where the Pi is, connect the dongle to the laptop, tune the SDR app to 1090MHz and look for ADS-B messages in the waterfall display?

So to further my investigations on this one, today I rebuilt the device with a new PiAware 6.1 sdcard image and set things back up again.

Flight tracking came back straight away and I was able to see planes on the SkyAware WebUI.

Since the PiAware image didn’t have the latest updates, I installed them via SSH with “sudo apt dist-upgrade”. Once all the packages had installed, I rebooted the Pi and now I’m seeing no flight tracking data again. For reference, the following package updates were installed:

pi@piaware:~ $ sudo apt dist-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
  firmware-amd-graphics firmware-atheros firmware-brcm80211 firmware-intelwimax firmware-iwlwifi firmware-libertas firmware-linux
  firmware-linux-nonfree firmware-misc-nonfree firmware-realtek firmware-ti-connectivity libc-bin libc-dev-bin libc-l10n libc6 libc6-dbg
  libc6-dev libraspberrypi-bin libraspberrypi-dev libraspberrypi-doc libraspberrypi0 linux-libc-dev locales multiarch-support pi-bluetooth
  raspberrypi-bootloader raspberrypi-kernel raspberrypi-sys-mods rpi-eeprom
29 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 167 MB of archives.
After this operation, 2,844 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 http://flightaware.com/mirror/raspberrypi/debian buster/main armhf libc6-dbg armhf 2.28-10+rpt2+rpi1 [10.7 MB]
Get:2 http://flightaware.com/mirror/raspberrypi/debian buster/main armhf libc6-dev armhf 2.28-10+rpt2+rpi1 [2,113 kB]
Get:3 http://flightaware.com/mirror/raspberrypi/debian buster/main armhf libc-dev-bin armhf 2.28-10+rpt2+rpi1 [266 kB]
Get:4 http://flightaware.com/mirror/raspberrypi/debian buster/main armhf linux-libc-dev armhf 1:1.20211007-2~buster [1,012 kB]
Get:5 http://flightaware.com/mirror/raspberrypi/debian buster/main armhf libc6 armhf 2.28-10+rpt2+rpi1 [2,356 kB]
Get:6 http://flightaware.com/mirror/raspberrypi/debian buster/main armhf libc-bin armhf 2.28-10+rpt2+rpi1 [647 kB]
Get:7 http://flightaware.com/mirror/raspberrypi/debian buster/main armhf libc-l10n all 2.28-10+rpt2+rpi1 [847 kB]
Get:8 http://flightaware.com/mirror/raspberrypi/debian buster/main armhf locales all 2.28-10+rpt2+rpi1 [4,061 kB]
Get:9 http://flightaware.com/mirror/raspberrypi/debian buster/main armhf firmware-linux all 1:20190114-2+rpt3 [19.1 kB]
Get:10 http://flightaware.com/mirror/raspberrypi/debian buster/main armhf firmware-amd-graphics all 1:20190114-2+rpt3 [3,429 kB]
Get:11 http://flightaware.com/mirror/raspberrypi/debian buster/main armhf firmware-linux-nonfree all 1:20190114-2+rpt3 [18.8 kB]
Get:12 http://flightaware.com/mirror/raspberrypi/debian buster/main armhf firmware-misc-nonfree all 1:20190114-2+rpt3 [3,340 kB]
Get:13 http://flightaware.com/mirror/raspberrypi/debian buster/main armhf firmware-atheros all 1:20190114-2+rpt3 [4,012 kB]
Get:14 http://flightaware.com/mirror/raspberrypi/debian buster/main armhf firmware-brcm80211 all 1:20190114-2+rpt3 [4,600 kB]
Get:15 http://flightaware.com/mirror/raspberrypi/debian buster/main armhf firmware-intelwimax all 1:20190114-2+rpt3 [1,195 kB]
Get:16 http://flightaware.com/mirror/raspberrypi/debian buster/main armhf firmware-iwlwifi all 1:20190114-2+rpt3 [5,319 kB]
Get:17 http://flightaware.com/mirror/raspberrypi/debian buster/main armhf firmware-libertas all 1:20190114-2+rpt3 [3,425 kB]
Get:18 http://flightaware.com/mirror/raspberrypi/debian buster/main armhf firmware-realtek all 1:20190114-2+rpt3 [506 kB]
Get:19 http://flightaware.com/mirror/raspberrypi/debian buster/main armhf firmware-ti-connectivity all 1:20190114-2+rpt3 [1,034 kB]
Get:20 http://flightaware.com/mirror/raspberrypi/debian buster/main armhf libraspberrypi-doc armhf 1:1.20211007-2~buster [31.4 MB]
Get:21 http://flightaware.com/mirror/raspberrypi/debian buster/main armhf libraspberrypi-dev armhf 1:1.20211007-2~buster [400 kB]
Get:22 http://flightaware.com/mirror/raspberrypi/debian buster/main armhf raspberrypi-kernel armhf 1:1.20211007-2~buster [79.8 MB]
Get:23 http://flightaware.com/mirror/raspberrypi/debian buster/main armhf libraspberrypi-bin armhf 1:1.20211007-2~buster [342 kB]
Get:24 http://flightaware.com/mirror/raspberrypi/debian buster/main armhf libraspberrypi0 armhf 1:1.20211007-2~buster [847 kB]
Get:25 http://flightaware.com/mirror/raspberrypi/debian buster/main armhf raspberrypi-bootloader armhf 1:1.20211007-2~buster [4,527 kB]
Get:26 http://flightaware.com/mirror/raspberrypi/debian buster/main armhf multiarch-support armhf 2.28-10+rpt2+rpi1 [215 kB]
Get:27 http://flightaware.com/mirror/raspberrypi/debian buster/main armhf raspberrypi-sys-mods armhf 20211005 [12.4 kB]
Get:28 http://flightaware.com/mirror/raspberrypi/debian buster/main armhf pi-bluetooth all 0.1.18 [5,508 B]
Get:29 http://flightaware.com/mirror/raspberrypi/debian buster/main armhf rpi-eeprom armhf 12.14-1 [865 kB]
Fetched 167 MB in 2min 58s (937 kB/s)
Reading changelogs... Done

Any known issues with the above packages installed from the FlightAware package mirrors?

Haven’t tested that; you’ll need to look into what broke. The FA mirror is, as the name implies, a mirror of the upstream archive; we don’t individually validate package updates.

(You will also have some version skew going on as the primary FA mirror of the Raspbian OS packages is deliberately frozen from late August, for now, to avoid problems for upgrades of older Buster installs, but the mirror of the Pi-specific packages which you picked up updates from is not; I don’t know if that’s significant here)

Given that you had a hardware problem before, I would not be surprised if you still have a hardware problem now and the update is entirely unrelated.

Would need to see the logs again to be able to diagnose anything.

Seems pretty clear at this point that it’s not a hardware issue since the issue went away by reinstalling piaware and only started again after the packages were updated.

The logs aren’t showing anything different from pre-update vs post-update so I guess I’ll trawl through the system logs to see if anything has changed there.

How do you know this without at least looking at the dump1090 logs? Hardware problems can be notoriously intermittent and it’s the obvious first thing to check here.

Please post dump1090 and piaware logs.