One of my RPi0 installations is having hiccups recently despite no change in infrastructure or location except for the periodic update/upgrade headless interventions. It appears that dump1090 stops working intermittently.
I found an old (circa 2014) command in this forum to restart dump1090 if it has stopped:
/etc/init.d/dump1090.sh start
Unfortunately, this command does not run on my installation (presumably owing to changes in running daemons in the more recent versions of the OS):
Try sudo systemctl restart dump1090 or sudo systemctl restart dump1090-fa if flightaware image to restart and sudo systemctl status dump1090 or sudo systemctl status dump1090-fa
I’m only advising from what I use on the fa image but I’m no specialist when it comes to RPI lol
I managed to get it up and running for a short while but then the issue(s) recurred:
$ piaware-status
PiAware master process (piaware) is running with pid 9632.
PiAware ADS-B client (faup1090) is not running.
PiAware ADS-B UAT client (faup978) is not running (disabled by configuration settings)
PiAware mlat client (fa-mlat-client) is not running.
Local ADS-B receiver (dump1090) is not running.
no program appears to be listening for ES connections on port 30005.
faup1090 is NOT connected to the ADS-B receiver.
piaware is connected to FlightAware.
got 'couldn't open socket: connection refused'
dump1090 is NOT producing data on localhost:30005.
Also, I messed up the systemctl command. Which one(s) should I use (to have my custom restart)? The command line top utility displays piaware as consuming < 2% CPU cycles. dump978-fa shows up at the 6% utilization range when given the slice by the OS presumably.
$ sudo systemctl restart faup1090
Failed to restart faup1090.service: Unit faup1090.service not found.
$ sudo systemctl restart dump1090
Failed to restart dump1090.service: Unit dump1090.service not found.
$
Your suggestions will help me to streamline my newbie bash script. Hopefully, (big hope, of course) I’ll patch an NRPE plugin to streamline the monitoring (and restart).
Before I get a new (and improved) Pro Stick (with the in-built filter), I’d like to run by my observations with the wider audience, please:
Here are the official troubleshooting recommendations:
There are multiple reasons that the timing information may be bad. The most common explanations are:
1. The USB cable is dropping information. This usually occurs when you are using low quality USB extension cables. Try connecting the RTL-SDR (e.g., Pro Stick) directly to the Raspberry Pi’s USB port.
2. The power supply is not supplying enough power. Try another 5V USB power supply.
3. The receiver location is not set correctly. The server-side MLAT timing calculations depend on knowing your receiver location. Go to your FlightAware “My ADS-B” page and set your location (click the gear icon).
4. The RTL-SDR (e.g., Pro Stick) is dropping information. Try a different RTL-SDR device.
5. The clock chip on the RTL-SDR device is bad. Try a different RTL-SDR device.
My logs have the following entries even after:
$ sudo service dump1090-fa restart
Jun 12 08:40:50 raspbari15 piaware[601]: mlat-client(28502): Lost connection to localhost:30005
Jun 12 08:40:50 raspbari15 piaware[601]: mlat-client(28502): Reconnecting in 30.0 seconds
Jun 12 08:40:50 raspbari15 piaware[601]: lost connection to dump1090-fa via faup1090
Jun 12 08:40:50 raspbari15 piaware[601]: faup1090 exited normally
Jun 12 08:40:50 raspbari15 piaware[601]: will reconnect to dump1090-fa in 30 seconds
Steps 1-3 didn’t remediate the issue.
Is the replacing the Pro Stick the only remaining viable option (Steps 4-5)? Thanks.
Maybe you should start by telling what you are using now and how you are trying to get this running. The messages indicate a loss of the connection to the stick.
What stick are you using, how is it connected etc etc. Then we can determine from there if there’s something that can aid you in the fix. And yes sometimes sticks break down so that could be a cause but first we need to rule out other possibilities.
Platform
OS: Raspbian GNU/Linux 11 (bullseye) armv7l
Host: Raspberry Pi Zero 2 W Rev 1.0
Kernel: 6.1.21-v7+
CPU: BCM2835 (4) @ 1.000GHz
Memory: 88MiB / 426MiB
CPU Usage: 15% (immediately after boot)
Disk (/): 7.3G / 59G
My initial troubleshooting efforts (prior to posting the 1st message at this forum) involved:
Changing LAN cables
Using a different port on the (unmanaged) network switch
Using a different (managed) network switch
Connecting to main network switch directly (current operation mode)
Changing OTG hub (heard many stories about this specific cheap SKU but I have many in productive use currently that have never failed but some do get hot)
Rebooting the computer after update/upgrade (and sometimes just after restarting the relevant services as a precautionary step)
No known (or recorded) power surge; even though transformer based UPS units protect the infrastructure power requirements, there are no “surge protectors” for the LAN cable (just dangling a red herring here)
None of these steps resolved the issue. Some additional observations:
Wasn’t able to monitor the computer a month or so ago (i.e. computer was periodically going offline)
However, Nagios (network monitoring software) has not recorded a single issue regarding simple connectivity since the first alert from FA central a week or so ago
Can SSH to computer without issue and examine piaware status
The only other Pro Stick at hand is committed to another piaware instance (i.e. do not want to swap)
I’d love to learn more about troubleshooting so that I have something to tinker with. In the meantime, I have placed an order for Pro Stick® Plus!
When the service stops, observe the logging. Not just from the dump1090-fa service but all.
Is there any indication that maybe the OS is causing the issue ?
Random going offline spikes the interest there. What is causing it ?
Is there a heat problem ?
Alternative, prepare a 2nd SD card with the software loaded.
Swap the card, check if the problem persists.
If so the issue is probably hardware related. If the issue disappears it is software related or your SD card is failing.
From there on you can eliminate possible causes and zoom in to find the culprit of your problem.
Many, many thanks for the guidance. It was the SD Card!! Re-built on another card and the system has been stable for more than that during previous cycles:
$ piaware-status
PiAware master process (piaware) is running with pid 567.
PiAware ADS-B client (faup1090) is running with pid 1413.
PiAware ADS-B UAT client (faup978) is not running (disabled by configuration settings)
PiAware mlat client (fa-mlat-client) is running with pid 1079.
Local ADS-B receiver (dump1090-fa) is running with pid 1287.
dump1090-fa (pid 1287) is listening for ES connections on port 30005.
faup1090 is connected to the ADS-B receiver.
piaware is connected to FlightAware.
dump1090 is producing data on localhost:30005.
Now I will have an extra Stick shortly. Will have to wait for a local retailer to provide the RPi02 (been waiting for one since Aug '21).
Yes, your observation is correct. The RPi4 power supply demands (and the quality of the products) provide hands-on lessons for those of us who want to wade into the weeds.
Nearly 20 years ago, I was given a tear down on why “Compaq” power supplies (for notebooks) were more expensive than the ones from Round Rock. The consumer could care less about the “over engineering” of the Compaq PS (for EMI protection) but gravitated towards the competitor’s products because they were inevitably $10+ cheaper. Sorry, off-topic but your reply trigger a reflex response on my part. The notebooks incidentally were assembled by the same ODM.
I’ve been trying to adjust gain and I added @wiedehopf’s autogain script after seeing a significant drop in reception this afternoon. Since adding it, I haven’t been able to view the standard Flight Aware web interface. It gives me a 403 Forbidden error (Sky Aware works, though). I tried to restart dump1090 and it tells me the service is masked.
[user]@raspberrypi:~ $ piaware-status
PiAware master process (piaware) is running with pid 670.
PiAware ADS-B client (faup1090) is running with pid 23299.
PiAware ADS-B UAT client (faup978) is not running (disabled by configuration settings)
PiAware mlat client (fa-mlat-client) is running with pid 1508.
Local ADS-B receiver (dump1090) is not running.
readsb (pid 23268) is listening for ES connections on port 30005.
faup1090 is connected to the ADS-B receiver.
piaware is connected to FlightAware.
dump1090 is producing data on localhost:30005.
Your feeder ID is b1040fc2-769f-4d06-9e4d-356a5c4abb5d (from /var/cache/piaware/feeder_id)
[user]@raspberrypi:~ $ sudo service dump1090-fa restart
Failed to restart dump1090-fa.service: Unit dump1090-fa.service is masked.
