FlightAware Discussions

Planes Vanishing after 5.0

Hello All,

Have a strange issue after upgrading to 5.0, hoping the community can shed some insight.

Had PiAware running for over a year straight on an RPi 3B+ (r1.3). Connected to the following: Pro Stick (orange), the 1090MHZ filter, and a beefy 1090 MHz Antenna sitting about 20’ off the ground. Was working perfectly fine for over 500 days.

Recently upgraded to 5.0 a week ago, and all of a sudden it started having issues.

Upon booting and loading, the feeder would display all the flights as expected, but then within about 30 seconds the icons stop moving, then turn a pastel color, then disappear altogether. Reboot, same cycle. Starts off strong, then within a minute it begins to fade then clear out. Local and PiAnywhere Maps themselves still display, no errors, and METAR map is refreshing. My ADS-B page shows all green and does not recognize any connection or transmitting issues. It just seems like all the planes vanished.

Tried several other configurations, checked all the components, ports, voltage of pi, and even moved the dongle to different USB ports. Reboot, same thing.

Tried re-installing using several OS bases on fresh SDcards (base raspian, with desktop, PiAware stand-alone, etc.). Same issue.

I had a couple other Pis laying around (older RPi 3B r1.2). When I popped the SD card into those Pis tracking resumed like normal. No issues. So it seems like the dongle, filter and antenna are still just fine.

Now, I know the obvious answer is “use the other Pis” and I will certainly do that, but I am fairly competent with things like this, and I feel like there is a solve for it. The original Pi is otherwise perfectly fine.

Does the dongle have a cache or other bios that could be stuck when contacting the original pi? Can I reset something? Appreciate any insight.

What is the output of

sudo journalctl --no-pager -n50 -u dump1090-fa

when it’s having problems?

Thank you for the reply. Did the following commends:

  • /opt/vc/bin/vcgencmd get_throttled
    Returned: throttled=0x0
  • sudo journalctl --no-pager -n50 -u dump1090-fa
    Returned:

– Logs begin at Tue 2021-04-20 06:17:01 EDT, end at Tue 2021-04-20 07:18:38 EDT. –

Apr 20 06:49:52 Station systemd[1]: Started dump1090 ADS-B receiver (FlightAware customization).

Apr 20 06:49:53 Station dump1090-fa[448]: Tue Apr 20 06:49:53 2021 EDT dump1090-fa 5.0 starting up.

Apr 20 06:49:53 Station dump1090-fa[448]: rtlsdr: using device #0: Generic RTL2832U (Realtek, RTL2832U, SN 00001000)

Apr 20 06:49:53 Station dump1090-fa[448]: Detached kernel driver

Apr 20 06:49:54 Station dump1090-fa[448]: Found Rafael Micro R820T tuner

Apr 20 06:49:54 Station dump1090-fa[448]: rtlsdr: enabling tuner AGC

Apr 20 06:49:54 Station dump1090-fa[448]: Allocating 4 zero-copy buffers

Apr 20 06:49:59 Station dump1090-fa[448]: Tue Apr 20 06:49:59 2021 EDT No data received from the SDR for a long time, it may have wedged

Apr 20 07:13:55 Station dump1090-fa[448]: Tue Apr 20 07:13:55 2021 EDT No data received from the SDR for a long time, it may have wedged

Apr 20 07:14:56 Station dump1090-fa[448]: Tue Apr 20 07:14:56 2021 EDT No data received from the SDR for a long time, it may have wedged

Apr 20 07:15:56 Station dump1090-fa[448]: Tue Apr 20 07:15:56 2021 EDT No data received from the SDR for a long time, it may have wedged

Apr 20 07:16:56 Station dump1090-fa[448]: Tue Apr 20 07:16:56 2021 EDT No data received from the SDR for a long time, it may have wedged

Apr 20 07:17:56 Station dump1090-fa[448]: Tue Apr 20 07:17:56 2021 EDT No data received from the SDR for a long time, it may have wedged

Just tried it again:

– Logs begin at Tue 2021-04-20 06:17:01 EDT, end at Tue 2021-04-20 07:32:22 EDT. –

Apr 20 06:49:52 Station systemd[1]: Started dump1090 ADS-B receiver (FlightAware customization).

Apr 20 06:49:53 Station dump1090-fa[448]: Tue Apr 20 06:49:53 2021 EDT dump1090-fa 5.0 starting up.

Apr 20 06:49:53 Station dump1090-fa[448]: rtlsdr: using device #0: Generic RTL2832U (Realtek, RTL2832U, SN 00001000)

Apr 20 06:49:53 Station dump1090-fa[448]: Detached kernel driver

Apr 20 06:49:54 Station dump1090-fa[448]: Found Rafael Micro R820T tuner

Apr 20 06:49:54 Station dump1090-fa[448]: rtlsdr: enabling tuner AGC

Apr 20 06:49:54 Station dump1090-fa[448]: Allocating 4 zero-copy buffers

Apr 20 06:49:59 Station dump1090-fa[448]: Tue Apr 20 06:49:59 2021 EDT No data received from the SDR for a long time, it may have wedged

Apr 20 07:13:55 Station dump1090-fa[448]: Tue Apr 20 07:13:55 2021 EDT No data received from the SDR for a long time, it may have wedged

Apr 20 07:14:56 Station dump1090-fa[448]: Tue Apr 20 07:14:56 2021 EDT No data received from the SDR for a long time, it may have wedged

Apr 20 07:15:56 Station dump1090-fa[448]: Tue Apr 20 07:15:56 2021 EDT No data received from the SDR for a long time, it may have wedged

Apr 20 07:16:56 Station dump1090-fa[448]: Tue Apr 20 07:16:56 2021 EDT No data received from the SDR for a long time, it may have wedged

Apr 20 07:17:56 Station dump1090-fa[448]: Tue Apr 20 07:17:56 2021 EDT No data received from the SDR for a long time, it may have wedged

Apr 20 07:18:56 Station dump1090-fa[448]: Tue Apr 20 07:18:56 2021 EDT No data received from the SDR for a long time, it may have wedged

Apr 20 07:19:57 Station dump1090-fa[448]: Tue Apr 20 07:19:57 2021 EDT No data received from the SDR for a long time, it may have wedged

Apr 20 07:20:57 Station dump1090-fa[448]: Tue Apr 20 07:20:57 2021 EDT No data received from the SDR for a long time, it may have wedged

Apr 20 07:21:57 Station dump1090-fa[448]: Tue Apr 20 07:21:57 2021 EDT No data received from the SDR for a long time, it may have wedged

Apr 20 07:22:57 Station dump1090-fa[448]: Tue Apr 20 07:22:57 2021 EDT No data received from the SDR for a long time, it may have wedged

Apr 20 07:23:57 Station dump1090-fa[448]: Tue Apr 20 07:23:57 2021 EDT No data received from the SDR for a long time, it may have wedged

Apr 20 07:24:57 Station dump1090-fa[448]: Tue Apr 20 07:24:57 2021 EDT No data received from the SDR for a long time, it may have wedged

Apr 20 07:25:58 Station dump1090-fa[448]: Tue Apr 20 07:25:58 2021 EDT No data received from the SDR for a long time, it may have wedged

Apr 20 07:26:58 Station dump1090-fa[448]: Tue Apr 20 07:26:58 2021 EDT No data received from the SDR for a long time, it may have wedged

Apr 20 07:27:58 Station dump1090-fa[448]: Tue Apr 20 07:27:58 2021 EDT No data received from the SDR for a long time, it may have wedged

Apr 20 07:28:58 Station dump1090-fa[448]: Tue Apr 20 07:28:58 2021 EDT No data received from the SDR for a long time, it may have wedged

Apr 20 07:29:42 Station systemd[1]: dump1090-fa.service: Main process exited, code=killed, status=11/SEGV

Apr 20 07:29:42 Station systemd[1]: dump1090-fa.service: Failed with result ‘signal’.

Apr 20 07:30:12 Station systemd[1]: dump1090-fa.service: Service RestartSec=30s expired, scheduling restart.

Apr 20 07:30:12 Station systemd[1]: dump1090-fa.service: Scheduled restart job, restart counter is at 1.

Apr 20 07:30:12 Station systemd[1]: Stopped dump1090 ADS-B receiver (FlightAware customization).

Apr 20 07:30:12 Station systemd[1]: Started dump1090 ADS-B receiver (FlightAware customization).

Apr 20 07:30:13 Station dump1090-fa[3026]: Tue Apr 20 07:30:13 2021 EDT dump1090-fa 5.0 starting up.

Apr 20 07:30:13 Station dump1090-fa[3026]: rtlsdr: using device #0: Generic RTL2832U (Realtek, RTL2832U, SN 00001000)

Apr 20 07:30:13 Station dump1090-fa[3026]: Found Rafael Micro R820T tuner

Apr 20 07:30:13 Station dump1090-fa[3026]: rtlsdr: enabling tuner AGC

Apr 20 07:30:13 Station dump1090-fa[3026]: Allocating 4 zero-copy buffers

Apr 20 07:30:44 Station dump1090-fa[3026]: Tue Apr 20 07:30:44 2021 EDT No data received from the SDR for a long time, it may have wedged

Apr 20 07:31:45 Station dump1090-fa[3026]: Tue Apr 20 07:31:45 2021 EDT No data received from the SDR for a long time, it may have wedged

That deleted post shows “SDR wedged” messages.
Typically means SDR is faulty or is not getting sufficient voltage.
As it works on another pi … low voltage on the USB ports of that pi is the most likely reason.
Note that it can sometimes also be too much ripple (capacitors on the SDR going bad not being able to deal with the ripple anymore).
Other pi might have less ripple on the USB ports thus making it work.

Try one of those power supplies on the Pi you’re having issues with.
As mentioned with ripple and things sometimes it’s the power supply despite the Pi not having undervoltage messages.

Thank you for the reply. Yeah I has some computer/connection issues and deleted those posts by accident.

I just tried going through all 3 Pis, all 4 USB ports, with 3 different power supplies, 36 different trials, all the same issue. Seems like one of the other Pis is starting to act up now as well, so maybe the dongle is a problem. The capacitance issue on the dongle seems likely and maybe I was just getting lucky with the other Pis testing positive (but I ran them for a while the first time and checked well).

I already have a new dongle on the way, this time the blue one with built-in filter. Side Question on that - I already have an external filter (the cylindrical one), should I add that one as well, anyway, or leave it off since the new dongle has a filter built-in.

Thank you!

Well that’s not great either … but as wiedehopf says, the “wedged” messages definitely indicate a hardware problem.

(In the next dump1090-fa release, it will more aggressively restart itself if this type of failure happens - sometimes that is enough to un-stick the dongle)

Test both over a week, check what gives better results.
For comparing setups, these can be useful:
GitHub - wiedehopf/tar1090: Provides an improved webinterface for use with ADS-B decoders readsb / dump1090-fa
GitHub - wiedehopf/graphs1090: Graphs for dump1090 (based on dump1090-tools by mutability)

Adjusting gain is a good idea as well before you start the comparison.
Automatic gain optimization for readsb and dump1090 fa · wiedehopf/adsb-scripts Wiki · GitHub

The FA Pro+ LNA is before the filter and can get overloaded by out of band signals.
But the filter lowers the signal level a bit so it’s not without drawbacks.
Thus just test both configurations.
Usually adding the filter is not detrimental thus i’d just add it.

I just got the new blue dongle in the mail.

Same issue with the old Pi. But it worked on the other Pis.

This is so strange. Maybe just pure coincidence some electrical issue blew through the Pi and the dongle around the time I upgraded. Or maybe the update requires more power from the hardware, highlighting an already trending issue.

It seems to be working for now, but still not as stable, or solid, as before. Almost seemed like getting pinged from web-host for the display agitates it, also. I see discrepancies between my local host display, and the new SkyAware Anywhere feature in both messages seen and how many airplanes are being tracked. It is not simply a lag issue.

Not sure, but I appreciate all the insight. Thank you, so much.

Not meant to be identical. Anywhere is only what is uploaded to FA.

I don’t suppose you have a USB current meter that also shows voltage?
Or i suppose you could check with a multimeter while under load.
If you’re really into finding the root cause.
(though you’d almost need an oscilloscope to also check the ripple)

The new version using more power could for sure cause an existing power issue to get worse.

No, but I will have a USB current meter tomorrow, and I will let you know. Now, I am just curious. My bud has an osci, so will check that as well.

Appreciate the feedback!

I would concur. Have a Pi3B+ at the base of an outdoor antenna, power via POE breakout not HAAT. Ran fine for 9 months with 2 dongle (1090 and 978) and small fan. Upgraded to 5.0. I believe they said some increased messaging occurs and in increase ADS-B dongle utilization will be seen.

Sure enough, saw increase in ADS-B CPU utilization. Wasn’t stable for days. Removed the 978 stick (only like 1 or 2 planes a week). Fine since. Now just 1090 and fan.