I have an older RPi which is working fine. The newer one, which I thought would be performing better, is having issues, disconnecting occasionally. Today I noticed a warning that the clock was off. I think that is sorted. I also sent commands to upgrade piaware and dump, so now it’s running 9.0.1. But I’m getting:
[2024-02-19 14:16 CST] no ADS-B data program seen listening on port 30005 for 244 seconds, next check in 60s
[2024-02-19 14:16 CST] no ADS-B data program is serving on port 30005, not starting multilateration client yet
What else do I need to check? I will try a cold boot as I wait for replies.
[2024-02-19 14:27 CST] upgrade of dump1090-fa seemed to go OK
[2024-02-19 14:27 CST] update request complete
[2024-02-19 14:27 CST] no ADS-B data program is serving on port 30005, not starting multilateration client yet
[2024-02-19 14:27 CST] logged in to FlightAware as user ExCalbr
[2024-02-19 14:27 CST] my feeder ID is fc8e7018-5f0d-4180-43ca-0a8d9a6597d0
[2024-02-19 14:27 CST] site statistics URL: Victor Engel ADS-B Feeder Statistics - FlightAware
[2024-02-19 14:27 CST] adept reported location: 30.35751, -97.72341, 780ft AMSL
[2024-02-19 14:27 CST] multilateration data requested
[2024-02-19 14:27 CST] UAT support disabled by local configuration setting: uat-receiver-type
[2024-02-19 14:27 CST] no ADS-B data program seen listening on port 30005 for 3 seconds, next check in 60s
[2024-02-19 14:28 CST] 0 msgs recv’d from dump1090; 0 msgs sent to FlightAware
Mon Feb 19 20:37:08 2024 UTC dump1090-fa 9.0~bpo11+1 starting up.
rtlsdr: no supported devices found.
Since it reported no supported devices found I decided to go up into the attic and check - maybe the dongle got disconnected. Nope - it did not. However, I unplugged it from the USB port and plugged it into the other one, then ensured the antenna wire was screwed in firmly. It seems to be working now. So maybe a USB port that went bad or something.
There are some newer RPis with one set of USB that are USB2.0 and one set that are USB3.0. I forget which one is the better option, but one tends to work better than the other. Also, I don’t know what else you might have plugged in, but if you have a device on one bus and one on a different bus, it can cause timing issues with ADS-B.
Since you said it’s a “newer Pi” and you swapped USB ports and it now works, that sounds like it might have been your problem.
Newer is a relative term (newer than my other one, which is a 2. It seems I can go about 2 weeks with this “newer” one before it stops working. I have an uptime robot checking if it’s up, and it doesn’t kick in. The RPi is still going, and pings are good, so the uptime robot doesn’t notice the feeder is not working. When I notice it’s not working I always try restarting dump1090 and piaware and rebooting the RPi. None of those options ever works. What I have to do is climb up into the attic and disconnect the dongle and plug it into a different USB port, then reboot. That always works and doesn’t seem to matter which USB port I use.
I’m tired of going up into the attic every couple weeks to do this and think it may be time to replace the RPi. Meanwhile my old one keeps chugging along without an issue.
So now my question is, what should I replace it with? It would be nice if I could get something where I can simply insert the SD card and it works. Will that work with an RPi 4? I’m seeing comments that the RPi5 requires something else so probably will not go that route.
I guess it’s actually an RPi 4 that has the issues. Here’s a link to the product I ordered. If I were to replace it with another RPi, what would people recommend?
I just tested using an 64 bit RPi 4 SD to boot my RPi 5. It worked perfectly. The requirement is that the OS must be 64 bit to be interchangeable. When I added RPi 5’s to my network, I updated all of the RPi 4’s with the same 64 bit OS.
Is your dongle directly connected to the Pi? My Pi4 and FA blue dongle always gave me erratic performance similar to what you describe when I had the dongle directly connected. For other reasons, I installed a short USB extension cable and a side effect of that was the connectivity problem disappeared. If you have a short cable handy, you could try that.
White 2.0 devices like FA blue dongles that I use, don’t like being connected to 3.0 blue protocol USB ports. Probably some 2.0/3.0 conversion overhead that goes astray but don’t know the technicals on that performance. My Rpi4 has both 2.0 and 3.0 and I have the antenna dongle connected via a short USB extension cable to the white 2.0 USB on the Rpi4. USB extension removes physical connection stresses and provides heat isolation.
I thought I had a cable, but I don’t. All my USB cables have some other connector at the other end: USB-C, lightning, the USB connector used by most hard drives, etc. - it didn’t seem to matter if I used the USB2 or USB3 ports. I will try with a cable, though, when I get one. Yep, I’m using the blue dongle. My orange one connected to my other RPi has never dropped out like this one. What bothers me most about this is that simply power-cycling doesn’t work. I have to remove the dongle and put it in another port and THEN power cycle. That requires my climbing up into the attic.
I had a similar problem, and added a line in /etc/crontab file to reboot the system every Saturday night around 1 am local time when the fewest planes were flying. It seemed to work. This is the line I added to /etc/crontab:
# Example of job definition:
# .---------------- minute (0 - 59)
# | .------------- hour (0 - 23)
# | | .---------- day of month (1 - 31)
# | | | .------- month (1 - 12) OR jan,feb,mar,apr ...
# | | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# * * * * * user-name command to be executed
I do not. It’s just the FA image. I suspect this crontab will not help, unless as a preventative somehow. The reason I say that is that when the problem happens, restarting the RPi, even disconnecting the power and reconnecting after a minute or so doesn’t help. I have to disconnect the dongle and plug it back in to a different port. That’s probably not exactly the situation, but I don’t have time to do thorough troubleshooting.
Never had any issues running FA sticks on the USB 3.0 port of a RPi 4 device. I was operating two of them.
If it is used for flight tracking only with a FA stick, even a PI zero would work.
Only if you plan to run it for other tasks as well or using an Airspy device, higher CPU power is required.
The problem could be with the USB system on the pi4. The pi4 has gone through a number of hardware revisions, with Rev 1.2 and earlier using a separate EEPROM for the USB firmware - this can get corrupted, resulting in the sort of flakey behaviour you are seeing.
To check the version of your pi, use:
tail /proc/cpuinfo
To look for evidence of firmware corruption use the following (it doesn’t actually update anything, just reports the current state):
sudo rpi-eeprom-update
Corrupted firmware looks like this:
BOOTLOADER: up to date
CURRENT: Wed 11 Jan 17:40:52 UTC 2023 (1673458852)
LATEST: Wed 11 Jan 17:40:52 UTC 2023 (1673458852)
RELEASE: default (/lib/firmware/raspberrypi/bootloader/default)
Use raspi-config to change the release.
VL805_FW: Dedicated VL805 EEPROM
VL805: up to date
CURRENT:
LATEST: 000138c0
The VL805_FW reports it is up to date, but the CURRENT installed version is blank.
In my experience the corruption can return, so given your issues in accessing it, getting a new pi is probably the way to go. The more recent revisions of the pi4 don’t have a separate EEPROM and (to me at least) seem more stable. A 1GB pi4 is more than adequate for a dedicated flight tracker.
