Can I improve my range? And why does my feeder stop after a while?

Question 1

I am currently using the default antenna that comes with many sdr dongles trimmed down to about 68mm (give or take a bit). (I also just built the cantenna recommended by abcd567 but I have not been able to try it as the adapter is taking a long time to get here) If I am reading this graph correctly


Is there a way to increase my range as my noise very low? Also will the cantenna increase my performance as it really is not good at the moment (the chart is in kilometers not nautical miles)

Question 2

Another problem I am having is my feeders randomly all stop working about 1 time a day (as you can see in the graph in the first question) and they will not work until I restart my pi, after that they start working perfectly for about a day.

Thanks!

Regarding Question 1 on range: you need a better antenna. You didn’t say what your situation was: house, apartment… whatever it is, get the antenna to the highest possible location. Preferably outdoors. Also get a 6 dBi gain antenna.

For Question 2: Possibly you have a flakey RPi or maybe an insufficient power supply. Try another power supply as a first resort.

2 Likes

For question 2 - are you connecting rpi to network via ethernet or wifi?

The better antenna should be a big help. Additional height inside and outside make the major improvements for all of us.

Performance of these systems is based on all the hardware, software, and the interactions between them. Improvements are made bit by bit.

Assuming software causes your random stops, you could spend days digging and tweaking trying to find the problem. Or you can do a complete reinstall, in less than 15 minutes, starting over with a known good image on a different or same microSD card. Highly recommend the FlightAware images like PiAware - PiAware Image on Raspbian Linux 8.2 ZIP (682MB). Simple, reliable, and just works.

Hardware problems can be a major pain to resolve. Most of us substitute a different hardware component and see if that helps. Power supplies are notorious for being the source of random problems.

Personally, I would try the new image SD card first, then move on to the hardware aspects. Break the problem down into steps and rule out the easy to fix things first. Best wishes on getting your systems up and running reliably.

1 Like

@astrodeveloper
I just did a reinstall but should I try again and see if it fixes the problem?

@dongerrard204 : @dongerrard204 I can’t connect the Pi with an ethernet cable, but I can ssh into it while it’s not working so it’s not a Wi-Fi problem.

@jimMerk2 : Inside my house on the second floor on a window sill my house is almost on the highest point for about 210 km but it is surrounded by trees. Will look into antennas but I am most likely going to diy all my antennas.

About the power supply, Is there any tests that you can run on your power supply or do you just get a new one? Also before I redownloaded my os it was working fine and what I was previously was running was up 24/7.

1 Like

Regarding the power supply, unless you have test equipment, probably the only thing to do is try another power supply.

Edit to add:
I guess prior to doing anything with the hardware, you could check the piaware log with journalctl, see what you get from: sudo journalctl -u piaware -e. Might give a clue as to what is going wrong.

2 Likes

Just checked while there are other things happening, good and bad, alot of what I see is something like this:

Jan 05 20:38:27 raspberrypi piaware[1850]: mlat-client(10701): Connection to localhost:30005 lost: [Errno 111] Connecti> Jan 05 20:38:27 raspberrypi piaware[1850]: mlat-client(10701): Reconnecting in 30.0 seconds Jan 05 20:38:29 raspberrypi piaware[1850]: mlat-client(10701): Beast-format results connection with ::1:30104: [Errno 1> Jan 05 20:38:44 raspberrypi sudo[1386879]: piaware : PWD=/ ; USER=root ; COMMAND=/bin/netstat --program --tcp --wide -> Jan 05 20:38:44 raspberrypi sudo[1386879]: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=995) Jan 05 20:38:45 raspberrypi sudo[1386879]: pam_unix(sudo:session): session closed for user root

Is this something that is seen quite a bit? I know that problems like this are quite common in some programs and are not bad if they reconnect quickly. Heres a photo of the cpu image stats where you can see that the program stopped:


(I did try reinstalling raspbian)

You can check for undervoltage messages in dmesg:

sudo dmesg | grep -i voltage

No messages means it’s mostlly fine.

Because the piaware sd-card image was mentioned, i’ll mention an sd-card image that provides a webinterface to configure most aggregators that exist: https://adsb.im

Really you have to check the log for the decoder mostly.
On the piaware image that would be:

sudo journalctl -u dump1090-fa -e

That is most likely to show useful information if the reception is interrupted.
Most likely it’s a bad SDR or the SDR isn’t getting sufficient power (could be a USB extension with too much resistance).

3 Likes

That would be to bad if it is the sdr seeing as I just got it. I would of used a preconfigured feeder, but I will be hosting other stuff soon and I could not find information on if you can use the PI for stuff other then feeding.

well post the output of the journalctl command i posted.
it should show what’s going on.

Oh sorry I did not see the command:

Jan 05 20:37:05 raspberrypi dump1090-fa[1386000]: Sun Jan  5 20:37:05 2025 PST  dump1090-fa 9.0 starting up.
Jan 05 20:37:05 raspberrypi dump1090-fa[1386000]: rtlsdr: using device #0: Generic RTL2832U OEM (Realtek, RTL2838UHIDIR, SN 00000001)
Jan 05 20:37:05 raspberrypi dump1090-fa[1386000]: usb_claim_interface error -6
Jan 05 20:37:05 raspberrypi dump1090-fa[1386000]: rtlsdr: error opening the RTLSDR device: Device or resource busy
Jan 05 20:37:05 raspberrypi systemd[1]: dump1090-fa.service: Main process exited, code=exited, status=1/FAILURE
Jan 05 20:37:05 raspberrypi systemd[1]: dump1090-fa.service: Failed with result 'exit-code'.
Jan 05 20:37:35 raspberrypi systemd[1]: dump1090-fa.service: Scheduled restart job, restart counter is at 952.
Jan 05 20:37:35 raspberrypi systemd[1]: Stopped dump1090-fa.service - dump1090 ADS-B receiver (FlightAware customization).
Jan 05 20:37:35 raspberrypi systemd[1]: Started dump1090-fa.service - dump1090 ADS-B receiver (FlightAware customization).
Jan 05 20:37:35 raspberrypi dump1090-fa[1386094]: Sun Jan  5 20:37:35 2025 PST  dump1090-fa 9.0 starting up.
Jan 05 20:37:35 raspberrypi dump1090-fa[1386094]: rtlsdr: using device #0: Generic RTL2832U OEM (Realtek, RTL2838UHIDIR, SN 00000001)
Jan 05 20:37:35 raspberrypi dump1090-fa[1386094]: usb_claim_interface error -6
Jan 05 20:37:35 raspberrypi dump1090-fa[1386094]: rtlsdr: error opening the RTLSDR device: Device or resource busy
Jan 05 20:37:35 raspberrypi systemd[1]: dump1090-fa.service: Main process exited, code=exited, status=1/FAILURE
Jan 05 20:37:35 raspberrypi systemd[1]: dump1090-fa.service: Failed with result 'exit-code'.
Jan 05 20:38:05 raspberrypi systemd[1]: dump1090-fa.service: Scheduled restart job, restart counter is at 953.
Jan 05 20:38:05 raspberrypi systemd[1]: Stopped dump1090-fa.service - dump1090 ADS-B receiver (FlightAware customization).
Jan 05 20:38:05 raspberrypi systemd[1]: Started dump1090-fa.service - dump1090 ADS-B receiver (FlightAware customization).
Jan 05 20:38:05 raspberrypi dump1090-fa[1386748]: Sun Jan  5 20:38:05 2025 PST  dump1090-fa 9.0 starting up.
Jan 05 20:38:06 raspberrypi dump1090-fa[1386748]: rtlsdr: using device #0: Generic RTL2832U OEM (Realtek, RTL2838UHIDIR, SN 00000001)
Jan 05 20:38:06 raspberrypi dump1090-fa[1386748]: usb_claim_interface error -6
Jan 05 20:38:06 raspberrypi dump1090-fa[1386748]: rtlsdr: error opening the RTLSDR device: Device or resource busy
Jan 05 20:38:06 raspberrypi systemd[1]: dump1090-fa.service: Main process exited, code=exited, status=1/FAILURE
Jan 05 20:38:06 raspberrypi systemd[1]: dump1090-fa.service: Failed with result 'exit-code'.
Jan 05 20:38:36 raspberrypi systemd[1]: dump1090-fa.service: Scheduled restart job, restart counter is at 954.
Jan 05 20:38:36 raspberrypi systemd[1]: Stopped dump1090-fa.service - dump1090 ADS-B receiver (FlightAware customization).
Jan 05 20:38:36 raspberrypi systemd[1]: Started dump1090-fa.service - dump1090 ADS-B receiver (FlightAware customization).
Jan 05 20:38:36 raspberrypi dump1090-fa[1386844]: Sun Jan  5 20:38:36 2025 PST  dump1090-fa 9.0 starting up.
Jan 05 20:38:36 raspberrypi dump1090-fa[1386844]: rtlsdr: using device #0: Generic RTL2832U OEM (Realtek, RTL2838UHIDIR, SN 00000001)
Jan 05 20:38:36 raspberrypi dump1090-fa[1386844]: usb_claim_interface error -6
Jan 05 20:38:36 raspberrypi dump1090-fa[1386844]: rtlsdr: error opening the RTLSDR device: Device or resource busy
Jan 05 20:38:36 raspberrypi systemd[1]: dump1090-fa.service: Main process exited, code=exited, status=1/FAILURE
Jan 05 20:38:36 raspberrypi systemd[1]: dump1090-fa.service: Failed with result 'exit-code'.
Jan 05 20:39:06 raspberrypi systemd[1]: dump1090-fa.service: Scheduled restart job, restart counter is at 955.
Jan 05 20:39:06 raspberrypi systemd[1]: Stopped dump1090-fa.service - dump1090 ADS-B receiver (FlightAware customization).
Jan 05 20:39:06 raspberrypi systemd[1]: Started dump1090-fa.service - dump1090 ADS-B receiver (FlightAware customization).
Jan 05 20:39:06 raspberrypi dump1090-fa[1387516]: Sun Jan  5 20:39:06 2025 PST  dump1090-fa 9.0 starting up.
Jan 05 20:39:06 raspberrypi dump1090-fa[1387516]: rtlsdr: using device #0: Generic RTL2832U OEM (Realtek, RTL2838UHIDIR, SN 00000001)
Jan 05 20:39:06 raspberrypi dump1090-fa[1387516]: Detached kernel driver
Jan 05 20:39:06 raspberrypi dump1090-fa[1387516]: Found Rafael Micro R820T tuner
Jan 05 20:39:06 raspberrypi dump1090-fa[1387516]: rtlsdr: tuner gain set to about 58.6 dB (gain step 29) (tuner AGC enabled)
Jan 05 20:39:07 raspberrypi dump1090-fa[1387516]: adaptive: using 50% duty cycle
Jan 05 20:39:07 raspberrypi dump1090-fa[1387516]: adaptive: enabled adaptive gain control with gain limits 0.0dB (step 0) .. 58.6dB (step 29)
Jan 05 20:39:07 raspberrypi dump1090-fa[1387516]: adaptive: enabled dynamic range control, target dynamic range 30.0dB
Jan 05 20:39:07 raspberrypi dump1090-fa[1387516]: Allocating 4 zero-copy buffers
Jan 05 20:39:17 raspberrypi dump1090-fa[1387516]: adaptive: reached upper gain limit, halting dynamic range scan here

Thanks!!!

Could you post the exact brand of the SDR that you have got ? Judging by the gain settings this isn’t a FA dongle
Additionally run the following commands and list the output here:

lsusb
sudo systemctl stop dump1090-fa
rtl_test -t

The outcome will show if your SDR dongle is capable of running Dump1090-FA

wvzack
This looks like a graphs1090 problem. When you have SSH into the pi, you can modify a file to make some necessary changes. Edit this file : ```
sudo nano /etc/default/graphs1090
and change the chart to read nautical for mph. In that file, you can change from Celsius to Fahrenheit. Change to number zero to a 1.

Also the graphs1090 halt at 23:42 daily, This is by default.
Enter this line while at your prompt, to stop the pi from halting at the 23:42 hour.

sudo bash /usr/share/graphs1090/git/stopMalarky.sh

Hope this might help.
KB4ERT

so for the first command I got

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 009: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

third I got:

-bash: rtl_test: command not found

which is weird because I have ran this command previously. Also I can get data it just randomly cuts out about 1 time a day so I am guessing my SDR can run Dump1090 FA.

Thanks

PS thanks for the help @KB4ERT

That’s not at all what’s going on here.

This means that some other program is using the SDR.
Probably a misconfigured rbfeeder or fr24feed or something like that.

Or whatever else you installed that uses the SDR.

1 Like

Okay I do have fr24feed the adsbexchange one opensky and flightaware. Is there a way to fix this or is restarting on a new Raspbian image a better idea?

I’d just recommend adsb.im image as it’s easier to configure.

Otherwise fix /etc/fr24feed.ini to not use dvb-t.
(if you want to go that route, pretty sure someone else will be happy to help out with that :slight_smile: )

Or possibly you enabled 978?

Actually I remember downloading it, do I just run sudo apt purge dump978-fa
or is there more to it?

so if you do that would it still be running or not?