I notice that every once in a while my Piaware will stop feeding, but it has checked in recently. For example, the Data Feed will show 8 hours ago, but Feeder-Check in will show Live (1 minute ago). For the interim, I was thinking about putting the reboot command in crontab, but I would like some help in finding the route cause.
Can someone point me in the right direction?
Thank you
Check /var/log/syslog for dump1090-fa errors, that sounds like a hardware problem where the dongle gets wedged (often caused by poor power)
I’ll check, but a simple reboot clears the problem until the next time, so I am not sure it is hardware related.
Maybe try another power supply with a higher output. 2.0+ amps would be ideal. If the red light on the Pi is blinking at all, the voltage is dropping too low.
Try another high quality power supply USB cable if separate from the wallwart. I have a couple USB cables that look fine but make the Pi do weird things. Those $.99 cables on eBay are sometimes iffy even with a 5V 2A power supply.
I see you are a ham, so you might have a ferrite bead to clamp on the power cable right before it enters the Pi.
Try putting the FA receiver in an externally powered USB hub which will reduce the power load on the Pi itself.
If the Pi is in the attic or somewhere that gets warm, pop the FA receiver out of it’s plastic case and just stick the internal circuit board in the USB hub. The receiver gets pretty warm inside the plastic case.
I also had a weird intermittent Pi problem that I pulled my hair out for weeks tracking down. It seemed to act up completely at random. Turned out whenever I transmitted from my base station (440 MHz @ 5w) it was flooding the FA antenna with RFI. Adding the external FA filter inline solved my problem. I have the blue dongle with the built in filter and gain amp, but it filters AFTER the signal goes through the amplifier circuit. By the time it gets to the filter, the RFI has already done its damage. The external filter keeps the RFI from ever reaching the FA receiver. Turns out lots of folks in high RFI areas run the external FA filter with the blue dongle.
Just some thoughts off the top of my head…
Jason
KK4PP
Rebooting the Pi powercycles the dongle
i may try the ferrite beads. I have the orange plastic cover dongle and the blue filter on the feedline.
Just an update: I have a 2.5A power supply. Ferrite bead at the power supply / Pi interface. Didn’t change a thing. I will try the external powered USB hub plus taking the USB stick/PCB out of the orange plastic case.
Thanks for the suggestions. I’ll keep you posted.
I made the mistake of touching my Flightaware Orange USB device at the metal (USB) end and boy did I burn myself. The thing was incredibly HOT. I took it out of the plastic case, and took a small 12v fan and have the fan blowing across the thing to cool it. While it is in the garage, i don’t think the ambient temp is what is causing the over heating. Does anyone know if the blue plastic ones get as hot?
I really had to go get some ice cubes and hold them because my fingers were close to burned.
-Kevin
Funny… Mine is doing pretty much the same exact thing - and this is a bit of a recent development as well.
I’ve noticed when I find the dongle in a wedged state (I haven’t checked the logs yet) - that there’s a white LED illuminated on the Pro Stick.
My PiAware set up has been running strong for months - so I wonder if the Pi’s power supply is just starting to tank and needs replacing?
Edit: I guess the white led is always on :mrgreen:
I’m not sure why my piaware stops sending ADS-B data. It had been running flawlessly for over six months and then 2 months ago I receive the email notifying me about the outage. I’ve tried another dongle and I tried a 3A power supply purchased from the Raspberry Pi supplier. Still goes out after 6 hours. I’m using Buster Lite 2019-07-10 .img and the latest piaware. The dongles and P/S work fine with FR24. Sorry guys, I like piaware but I’m tired of messing with it. I’ll look at it in a few months and see if I can sort it out.
Maybe you didn’t configure FR24 correctly?
Then FR24 will take over the receiver and prevent FA from getting data.
This will correct the FR24 configuration, there is also a link describing a manual method: Automatic installation for dump1090 fa · wiedehopf/adsb-scripts Wiki · GitHub
No, FR24 works flawlessly…it’s Piaware that is problematic.
You misunderstood: FR24 is causing piaware to not work if it’s not configured correctly.
The SDR can only be used by one application, and depending on the FR24 configuration it will grab the SDR and not expose the data on 30005 as dump1090-fa/piaware does.
Or is FR24 on another sd-card?
I’m not quite clear on that.
No, two separate RPi’s. For the past 6 months when piaware was working, it was the only plane spotter running. Then it stopped reporting. Over the weekend I set up FR24 and it works great but as I said in the first post, even with the 3a power supply, piaware runs for about 4 or 5 hours then stops sending data.
http://www.qsl.net/wa4chq/godspeed.html
Slackware Linux-
MX-19 Linux-
March 10
wa4chq:
FR24 works flawlessly…it’s Piaware that is problematic.
You misunderstood: FR24 is causing piaware to not work if it’s not configured correctly.
The SDR can only be used by one application, and depending on the FR24 configuration it will grab the SDR and not expose the data on 30005 as dump1090-fa/piaware does.
Or is FR24 on another sd-card?
I’m not quite clear on that.
Ah, no clue then …
I’m using a RasPi 2 with a usb Wi-Fi dongle. When I have to restart our modem/router, the pi doesn’t reconnect and I don’t remember to go and unplug/plug it back in to reboot it. So I got curious about the possibility of writing a script to detect and handle this situation. I’ve had a Pi for various things for a couple years but never got this deep into the configuration of it. I learned a lot 
I found and repurposed a script to check if 8.8.8.8 was reachable, and if not, reboot the device. (nano, bash scripting, if, then, else)
Then I learned how to change the permissions on that script to make it executable. (chmod)
Then I learned how to schedule that script to run every 15 minutes. (cron… */15 * * * *)
I also learned how to search the system log for entries from cron to see that the script was running (grep) but it was not logging the result.
So then I learned how to log the result of the script to the messages.log file (logger), and how to monitor the file in real time (tail).
I can see the script running and logging status every 15 minutes. Will be interesting to see how it handles the next time it can’t connect.