I am experiencing random feeder outages. I don’t even know where to start to troubleshoot this. My fix thus far has been to reboot. It will work fine for a day or two and then out…
Any ideas??
I’m running Piaware 6.1 under Buster.
System info (what is installed?).
Logs: https://github.com/wiedehopf/adsb-wiki/wiki/Debug-commands#dump1090-fa
Collect the logs during an outage by connecting via ssh.
Put the log on pastebin.com and link it here.
Does it stop feeding only or is the whole device losing the network connection?
Are you feeding FA only or other sites as well? Are these impacted then as well?
I immediately thought network issues, as well. I had a 16-hour outage last month and had to reboot because my device randomly lost its WiFi connection. It’s one reason why I have 50-foot (15m) ethernet cables being delivered this week (I’m on Raspberry Pi 3B+ so I can plug in). Wired connections will always be more stable and reliable than WiFi.
That still doesn’t answer the question if the device is unreachable completely or just stopped feeding (e.g. losing access to the Internet)
My devices here at home are all Wifi as i cannot drill holes into walls. Not a single issue so far related to it. But wired connections are pretty much reliable
I do have the advantage of being able to drill holes. I knew my device was disconnected because I pinged its IP and got no response. Either the Raspberry Pi froze or the WiFi just disconnected. Either way, rebooting solved my issue that time. For a more reliable connection I’ve been planning to wire it in for a while now.
Have you tried replacing the PSU?
A soft PSU is the most common cause of problems.
1 Like
I have, I think, a similar problem. Every now and then (usually a few weeks apart), FlightAware will stop receiving my feed even though data is still being collected locally (I look at the web interface on my Pi, and it looks fine). I can still ssh to the Pi, so it’s not a general network problem. To resolve it, I just ssh in (the Pi is in the attic, but adequately cooled, and in any case heat isn’t a problem at this time of year) and tell it to reboot itself, and that resolves the issue. The problem for me is, the first time I’m aware there’s a problem is when I get an email from FlightAware telling me it’s been offline for 12 hours. I don’t really have time/motivation to wait for the next time it fails and then try to analyze the logs to figure out why. What I would like to do is find some way to query FlightAware every so often to see how long it’s been since it received data from me, and if it’s been a while either send me an alert or just reboot the bloody thing, or both. But short of scraping the web site (which I understand to be a no-no), I can’t figure out how to check my flightaware status. Any suggestions?
Instead of rebooting the device, you could also restart the service piaware with
sudo systemctl restart piaware
However without taking a look at the logs it’s a mission impossible to identify why the stream fail intermittently
There are solutions to start services based on conditions, but i would rather try to identify the root cause.
As above, the most common cause for problem like this is a soft PSU.
I assume you haven’t tested it?
Personally, knowing there is a problem lurking that will repeatedly cause a failure is unsatisfactory.
This is from the log; it’s just repeated over and over:
Jan 07 06:43:35 raspberrypi dump1090-fa[24009]: usb_claim_interface error -6
Jan 07 06:43:35 raspberrypi dump1090-fa[24009]: rtlsdr: error opening the RTLSDR device: Device or resource busy
Jan 07 06:43:35 raspberrypi systemd[1]: dump1090-fa.service: Main process exited, code=exited, status=1/FAILURE
Jan 07 06:43:35 raspberrypi systemd[1]: dump1090-fa.service: Failed with result ‘exit-code’.
Jan 07 06:44:05 raspberrypi systemd[1]: dump1090-fa.service: Service RestartSec=30s expired, scheduling restart.
Jan 07 06:44:05 raspberrypi systemd[1]: dump1090-fa.service: Scheduled restart job, restart counter is at 5400.
Jan 07 06:44:05 raspberrypi systemd[1]: Stopped dump1090 ADS-B receiver (FlightAware customization).
Jan 07 06:44:05 raspberrypi systemd[1]: Started dump1090 ADS-B receiver (FlightAware customization).
Jan 07 06:44:05 raspberrypi dump1090-fa[24059]: Fri Jan 7 06:44:05 2022 GMT dump1090-fa 6.0 starting up.
Jan 07 06:44:05 raspberrypi dump1090-fa[24059]: rtlsdr: using device #0: Generic RTL2832U (Realtek, RTL2832U, SN 00001000)
The only thing on the pi is Piaware. The pi is still connected to my network; it’s just not feeding FA.
What’s a PSU? Where is it? How do I determine whether it needs replacing? How to replace?
A PSU is a Power Supply Unit.
That’s the power source for the Raspberry Pi. Check if you have any undervoltage messages in your logs.
Command
sudo cat /var/log/syslog | grep -i voltage -A1 -B1
If there are issues you will see something like this
raspberrypi kernel: [ 2604.162635] Under-voltage detected! (0x00050005)
So if you see those messages then you might want to consider to replace the power supply unit
Bingo! Thanks. Will see what a new power supply does.
I had this in my logs also. Reason was a not 100% connected USB Stick.
You could also try to "squeeze the connector a bit that it’s more tight at the USB port.
Just another option…
This means that you have a misconfiguration and something else is already using the dongle, so dump1090 cannot use it.
Just to elaborate, that would typically be FR24 or Radarbox feed clients being configured wrong (easy to do, the configuration isn’t clear).
You could also be using it for something else like 978 or airband or whatever.
I’ve replaced the power supply, but the problem persists.
This is the dump of the 1090 log
Jan 15 05:30:13 raspberrypi systemd[1]: Started dump1090 ADS-B receiver (FlightAware customization).
Jan 15 05:30:13 raspberrypi dump1090-fa[484]: Sat Jan 15 05:30:13 2022 GMT dump1090-fa 7.1~bpo10+1 starting up.
Jan 15 05:30:13 raspberrypi dump1090-fa[484]: rtlsdr: using device #0: Generic RTL2832U (Realtek, RTL2832U, SN 00001000)
Jan 15 05:30:14 raspberrypi dump1090-fa[484]: Detached kernel driver
Jan 15 05:30:14 raspberrypi dump1090-fa[484]: Found Rafael Micro R820T tuner
Jan 15 05:30:14 raspberrypi dump1090-fa[484]: rtlsdr: tuner gain set to about 58.6 dB (gain step 29) (tuner AGC enabled)
Jan 15 05:30:14 raspberrypi dump1090-fa[484]: adaptive: using 50% duty cycle
Jan 15 05:30:14 raspberrypi dump1090-fa[484]: adaptive: enabled adaptive gain control with gain limits 0.0dB (step 0) .. 58.6dB (step 29)
Jan 15 05:30:14 raspberrypi dump1090-fa[484]: adaptive: enabled dynamic range control, target dynamic range 30.0dB
Jan 15 05:30:14 raspberrypi dump1090-fa[484]: Allocating 4 zero-copy buffers
Jan 15 05:30:24 raspberrypi dump1090-fa[484]: adaptive: available dynamic range (22.3dB) < required dynamic range (30.0dB), switching to downward scan
Jan 15 05:30:24 raspberrypi dump1090-fa[484]: adaptive: changing gain from 58.6dB (step 29) to 49.6dB (step 28) because: probing dynamic range gain lower bound
Jan 15 05:30:24 raspberrypi dump1090-fa[484]: rtlsdr: tuner gain set to 49.6 dB (gain step 28)
Jan 15 05:30:34 raspberrypi dump1090-fa[484]: adaptive: available dynamic range (32.6dB) >= required dynamic range (30.0dB), stopping downwards scan here
Jan 15 06:30:46 raspberrypi dump1090-fa[484]: adaptive: start periodic scan for acceptable dynamic range at increased gain
Jan 15 06:30:46 raspberrypi dump1090-fa[484]: adaptive: changing gain from 49.6dB (step 28) to 58.6dB (step 29) because: periodic re-probing of dynamic range gain upper bound
Jan 15 06:30:46 raspberrypi dump1090-fa[484]: rtlsdr: tuner gain set to about 58.6 dB (gain step 29) (tuner AGC enabled)
Jan 15 06:30:56 raspberrypi dump1090-fa[484]: adaptive: available dynamic range (23.0dB) < required dynamic range (30.0dB), switching to downward scan
Jan 15 06:30:56 raspberrypi dump1090-fa[484]: adaptive: changing gain from 58.6dB (step 29) to 49.6dB (step 28) because: probing dynamic range gain lower bound
Jan 15 06:30:56 raspberrypi dump1090-fa[484]: rtlsdr: tuner gain set to 49.6 dB (gain step 28)
Jan 15 06:31:06 raspberrypi dump1090-fa[484]: adaptive: available dynamic range (32.9dB) >= required dynamic range (30.0dB), stopping downwards scan here
Jan 15 07:23:03 raspberrypi systemd[1]: dump1090-fa.service: Main process exited, code=killed, status=11/SEGV
Jan 15 07:23:03 raspberrypi systemd[1]: dump1090-fa.service: Failed with result 'signal'.
Jan 15 07:23:33 raspberrypi systemd[1]: dump1090-fa.service: Service RestartSec=30s expired, scheduling restart.
Jan 15 07:23:33 raspberrypi systemd[1]: dump1090-fa.service: Scheduled restart job, restart counter is at 1.
Jan 15 07:23:33 raspberrypi systemd[1]: Stopped dump1090 ADS-B receiver (FlightAware customization).
Jan 15 07:23:33 raspberrypi systemd[1]: Started dump1090 ADS-B receiver (FlightAware customization).
Jan 15 07:23:33 raspberrypi dump1090-fa[9200]: Sat Jan 15 07:23:33 2022 GMT dump1090-fa 7.1~bpo10+1 starting up.
Jan 15 07:23:33 raspberrypi dump1090-fa[9200]: rtlsdr: using device #0: Generic RTL2832U (Realtek, RTL2832U, SN 00001000)
Jan 15 07:23:33 raspberrypi dump1090-fa[9200]: usb_claim_interface error -6
Jan 15 07:23:33 raspberrypi dump1090-fa[9200]: rtlsdr: error opening the RTLSDR device: Device or resource busy
Jan 15 07:23:33 raspberrypi systemd[1]: dump1090-fa.service: Main process exited, code=exited, status=1/FAILURE
Jan 15 07:23:33 raspberrypi systemd[1]: dump1090-fa.service: Failed with result 'exit-code'.
Jan 15 07:24:03 raspberrypi systemd[1]: dump1090-fa.service: Service RestartSec=30s expired, scheduling restart.
Jan 15 07:24:03 raspberrypi systemd[1]: dump1090-fa.service: Scheduled restart job, restart counter is at 2.
Jan 15 07:24:03 raspberrypi systemd[1]: Stopped dump1090 ADS-B receiver (FlightAware customization).
Jan 15 07:24:03 raspberrypi systemd[1]: Started dump1090 ADS-B receiver (FlightAware customization).
Jan 15 07:24:03 raspberrypi dump1090-fa[9241]: Sat Jan 15 07:24:03 2022 GMT dump1090-fa 7.1~bpo10+1 starting up.
Jan 15 07:24:03 raspberrypi dump1090-fa[9241]: rtlsdr: using device #0: Generic RTL2832U (Realtek, RTL2832U, SN 00001000)```
I have no clue what's going on. But I can say that nothing else is using the pi or the flightaware dongle.I neglected to mention that the piaware control panel in my browser shows piaware, flightaware, and mlat all in the green, but the skyaware page shows a map of Italy; I’m in Anchorage. Reboot usually sets things right–until the next time. Something’s not right.