I apologize in advance if this has already been answered, a cursory search revealed nothing. I’m a debian noob so please be kind. It appears as though my dump1090 stops approximately once a day requiring a manual (ssh’ing in) $ sudo fadump1090.sh restart I’ve looked at the logs and it has the following excerpt over-and-over:
03/06/2016 09:41:52 no ADS-B data program seen listening on port 30005 for 360 seconds, trying to start it…
03/06/2016 09:41:53 attempting to start fadump1090.sh using ‘invoke-rc.d fadump1090.sh start’…
03/06/2016 09:41:53 dump1090 start appears to have been successful
03/06/2016 09:41:57 mlat(15094): Connection to localhost:30005 lost: [Errno 111] Connection refused
03/06/2016 09:41:57 mlat(15094): Reconnecting in 30.0 seconds
03/06/2016 09:41:57 mlat(15094): Beast-format results connection with localhost:30104: [Errno 111] Connection
Piaware remains connected, hence the following:
dump1090 is not running.
faup1090 is not running.
piaware is running.
no program appears to be listening for connections on port 30005.
faup1090 is NOT connected to port 30005.
piaware is connected to FlightAware.
got ‘couldn’t open socket: connection refused’
maybe dump1090 is NOT producing data on port 30005.
A manual fadump1090 restart will result in the following:
dump1090 is running.
faup1090 is running.
piaware is running.
dump1090 is listening for connections on port 30005.
faup1090 is connected to port 30005.
piaware is connected to FlightAware.
dump1090 is producing data on port 30005.
It looks as though the system is attempting a restart in the logfile, but it never takes and requires a manual restart. Thoughts?
Probably power or USB problems. Check the output of “dmesg” for any USB-related disconnects. Consider getting a better power supply or using an external USB hub.
You will likely see the RTL dongle disconnecting and reconnecting. dump1090 doesn’t like this at all and basically becomes a zombie until the other processes on the PiAware image notice they’re not getting data and restart the process. Running the fadump1090sh restart command manually initiates the restart and you’ll be connected again as you noticed.
I had this exact same problem, and solved it by replacing the USB hub the dongle was connected to the Pi through. I was using an el-cheapo powered hub (literally the one I had sitting around because it came with the game “rockband” a decade ago.
**If you’re using a hub, I’d replace it with a high-quality powered hub. If you’re using an extension cable, I’d replace that. **
If you have the dongle directly connected to the Pi, you might try a powered hub - I find the dongles we’re using can be right on the edge of the pi’s power capacity at times - though when that is the issue the whole thing usually reboots so I’d bet you’re using an extension and or a hub
I am not sure why people have so many power issues.
I run two RPI2s each with two dongles (R820T 1ppm or better) and GPS GPIO units. They both run fine without USB hubs. I do use good 2A P.S. units.
The device is powered by 5V micro-USB. Exactly how much current (mA) the Raspberry Pi requires is dependent on what you hook up to it. We have found that purchasing a 1.2A (1200mA) power supply from a reputable retailer will provide you with ample power to run your Raspberry Pi for most applications, though you may want to get a 2.5A (2500mA) power supply if you want to use all 4 USB ports on the Models B+/2B/3B without using an external powered USB hub. The table below outlines the power requirements of each model.
I beleive the PiAware image has the max_usb_current=1 setting enabled by default.
I think that most of these dongle disconnect issues aren’t caused by Pi power issues but instead caused by the cabling or hubs between the pi and the dongle.
(Also - and this might just be me - but even with a 3A power supply my pi won’t boot with the dongle directly plugged in. I think there’s something wrong with the Pi TBH, but I don’t want to switch it out because I’d have to create a new site as the mac address would change. Other people might have the same issue, so that’s why I default to suggesting the hubs)
You can change the MAC address in the configuration and retain the old site. There have been a couple of posts on the syntax, I just haven’t found them yet.
Thanks everyone. I am using a “quality” power supply 2.4A. There’s nothing in dmesg about the USB disconnecting. I have stopped piaware and have just been running dump1090 now for days without a hiccup. It’s only when running piaware that dump1090 stops. There’s seems to be nothing in the logs.
Just adding my 2 cents to this slightly old thread. I have been noticing the occasional failure of dump1090 myself. For kicks I downloaded the source for dump1090 v1.09.0608.14 (has --forward-mlat) and built it myself replacing the FlightAware 1.2-3 version. I also built a new librtlsdr from the May 2015 source code. There are no issues reported in dmesg. I am running a powered USB hub with an Rpi 3. To keep it up and running I have a cron job running every ten minutes that does a pgrep for “dump1090” and does a service restart if it is missing. It also sends me a text alert and logs the restart in a /var/log file. It is a solution but I am curious why dump1090 abends. The service shell script does not redirect stderr or stdout to a file so there is nothing to check for an exit message. I may have to modify the script do that if these stoppages keep happening.
Your setup is very much unique. Which version of Dump1090 are you using? There are many versions. And which librtlsdr? Some have different bugs.
It should be noted: There are thousands of units running without issue on the FlightAware or Mutability version of Dump1090. Based on that alone, most issues are due to a specific issue to the feeder - not a fleet wide bug.
Did you fully remove the FlightAware 1.2-3 version?
Yes the FlightAware v1.2-3 version was installed as /usr/bin/dump1090 via “dump1090_1.2-3_armhf.deb” that I downloaded last year from flightaware.com/adsb/piaware/install. I shutdown the instance, renamed the image and moved the newly built image to the same location. The README.md for this dump1090 starts with:
“Dump1090 MR is a FlightAware fork of Malcolm Robb’s fork of
Salvatore Sanfilippo’s dump1090 program. FlightAware uses it as an
important element of PiAware (flightaware.com/adsb/piaware/),
a Debian package for forwarding ADS-B data to FlightAware.”
I found it looking for a fork that supported “–forward-mlat” like the binary version I had without source code. That turned up a discussion here at ads-b-flight-tracking-f21/where-is-dump1090-ver-flightaware-1-2-3-t36749.html that has a link to a tarball of the project. The only difference is I did not use the dump1090_builder to change the version string. The dump1090.h file has:
#define MODES_DUMP1090_VERSION “1.09.0608.14”
Dates are September 2015.
librtlsdr was built from source I cloned from github.com/steve-m/librtlsdr.git. Did the requisite cmake, make and “make install”, after shutting down dump1090 first.
The simplest solution is probably to add logging and see what gives.
The mystery continues. dump1090 is stopping on average about twice a day. This problem basically started when I moved my ADS-B antenna to a higher unobstructed location and dramatically improved the number of aircraft seen. This receiver is at my work location in the NYC metro area (Babylon, NY) and I have traffic from KFRG (closest), KISP (next closest), KJFK (#3), KLGA (#4), KHPN (#5) and KEWR (#6). I routinely see high altitude traffic as far away as southern Vermont and New Hampshire now.
I am running a Raspberry Pi 3 which I had to upgrade to in order to handle the load as my original Raspberry Pi started running at 100% load due to the increased reception traffic. I modified the service script to send stdout and stderr to log files so that I could see what is happening. Unfortunately, dump1090 is not reporting any errors when it stops. All I see in the stderr log repeated over and over again due to appending is (stdout log is empty):
Found 1 device(s):
0: Realtek, RTL2838UHIDIR, SN: 00000001 (currently selected)
Found Rafael Micro R820T tuner
Using automatic gain control.
Exact sample rate is: 2000000.052982 Hz
Gain reported by device: 0.00
My watchdog cron job checks if a restart is needed every 10 minutes and sends me a text message when it does do a restart.
In the past when I had power issues (before upgrading to a powered hub), I would get exit codes returned prior to dump1090 terminating so I could tell what the issue was. With no status codes being returned, I am quite puzzled.
You could try running it from a shell and see why it terminates (the shell should report if it’s dying from a signal which is the most likely reason here)
If you’re exposing port 8080 to the internet at large, stop doing that and see if the crashes go away. The internal dump1090 webserver is not particularly stable…
BINGO! That is it! I fired up top and then tried accessing port 8080. It stayed up but then I put in a bogus URL and it died. Restarted it, put in the bogus URL again and it died. Thanks for pointing that out. I will nuke that ASAP.
Next project is installing an ADS-B bandpass filter from FlightAware on the receiver. Will be interesting to see what improvement (if any) it makes. There is a lot of RF around my work community and providing some front end protection for the R820T should improve things even more.
The FA Filter is a band-pass filter, not a notch filter. The two are opposites. A notch filter blocks a specific frequency. The band-pass allows a specific frequency(range).
I ran a FA Pro-stick last week, accidentally with one, with the gain set to 48. I saw 2 aircraft. I added the filter and it went back up to over 100. I had to reduce the gain to about 38.6 to work the best(I have a great antenna, cavity filter and coax).
Silly me notch vs. bandpass! I knew that. I use a notch filter on my scanner to block local FM stations.
I was tired this morning (turned 54 yesterday). Glad I didn’t have to take my Amateur Radio and GROL tests today
For dump1090, I set --net-http-port to 0 which appears to have disabled the web server. I do not see it listening anywhere now so hopefully it will no longer stop unexpectedly.
