Welcome to Radarspotting. Please login or sign up.

April 27, 2024, 05:10:32 PM

Login with username, password and session length

New Members

New Members

You should get an activation email when you join.  If not, please use the Contact option.

Problem with dump1090 on Raspberry Pi

Started by yetti15A, March 13, 2024, 11:47:46 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

yetti15A

Hi all.
The essence of the issue is that the working dump1090 on the Raspberry Pi stops receiving planes. CPU load drops from 40....50% to 1% or even less. The dump1090 process itself remains present in the system. After a reboot, dump1090 again works for several hours with a load of 40...50% and drops to 1% or even 0%.
As a USB receiver I tried both a simple USB R820T2 and a FlightAware Pro Stick.
How can I solve this problem?

Anmer

Welcome to the forum.

Have you had this issue since you first started using Dump1090 or is it a recent occurence?

What version of Dump1090 are you using?

Do you have a different SD card you could try?
Here to Help.

yetti15A

Previously, dump1090 worked fine for several years. And recently this problem has started to appear.

The version of dump1090 does not matter, I installed different ones. Installed dump1090-mutability, MalcolmRobb, now works
antirez.

I tried different SD cards. Moreover, after uploading the system to the card, it works stably for several months, then these problems begin. The Raspberry boards themselves, I have two of them, I ran them on both. The problem remains. The +5 volt power supply is also reliable and powerful, I am familiar with the problems of running a Raspberry Pi.

It's not clear to me - the dump1090 process itself remains present in the system, but with 0...1% processor load.

Anmer

Thanks.

Sorry for the questions but I don't know the member's skills and experience.

From your feedback, RPi, SD card, Dump1090 and power upply are not thought to be the problem.

What about the receiver, antenna and cables? 
Here to Help.

rikgale

Also, which type of Pi and which OS?
40-50% seems rather high for a Pi4/5 with just dump1090, so I going to take punt at it being a Pi3.
A 'reliable power supply' can look reliable under testing, but is not reliable in use. Several of my Pi4 PSU have gone to electical recycling for this reason. Have you actually tried a new, offical Rpi PSU? 90% of the time the symptoms you've given point to PSU problems. Are you able to post any logs from dump1090 so we can see what is happening at the time it stops recieveing planes.
Also do you use a USB extenstion cable, or plug the SDR directly into the Pi?

Auto updated daily ZIP files on GitHub

yetti15A

Quote from: rikgale on March 13, 2024, 01:38:35 PMAlso, which type of Pi and which OS?
40-50% seems rather high for a Pi4/5 with just dump1090, so I going to take punt at it being a Pi3.
A 'reliable power supply' can look reliable under testing, but is not reliable in use. Several of my Pi4 PSU have gone to electical recycling for this reason. Have you actually tried a new, offical Rpi PSU? 90% of the time the symptoms you've given point to PSU problems. Are you able to post any logs from dump1090 so we can see what is happening at the time it stops recieveing planes.
Also do you use a USB extenstion cable, or plug the SDR directly into the Pi?

Raspberry Pi version 1. Two pieces. Previously we worked for many years and there were no problems.
Raspbian Buster OS is currently installed.
Power supply +5 volts at 7 amps.
One such block works for me on a pi4 raspberry, and the second on a pi1 raspberry.
There are no problems on the Raspberry Pi4, I swapped the power supplies. Raspberry Pi4 runs dump1090, modesmixer2, VirtualRadar, an SSD hard drive is used as an SD card. There are no problems.
There is a problem with the receiver based on the Raspberry1 board; previously these boards worked fine for me. I tried to install the Modesdeco2 reception program, but I could not run it on Buster OS.
I don't know where to look at the dump1090 log.
The USB receiver is inserted directly into the board, there is no cable.
The power of the USB port has also been increased by software (max_usb_current=1).

yetti15A

Quote from: Anmer on March 13, 2024, 12:37:31 PMThanks.

Sorry for the questions but I don't know the member's skills and experience.

From your feedback, RPi, SD card, Dump1090 and power upply are not thought to be the problem.

What about the receiver, antenna and cables?


Antenna collinear. Andrew CNT-400 cable.

rikgale

When this CPU drops to 1% does the SDR show up in lsusb
This command will show you what is attached to the USB bus (You might know this already, but I don't know where your skill level sits)

I note that you are using some very old kit with some older software, so I am not 100 sure how to get at the log for dump1090. Might be worth try using the readsb decoder which is still activly maintained/developed.

Auto updated daily ZIP files on GitHub

yetti15A

Quote from: rikgale on March 14, 2024, 02:36:31 PMWhen this CPU drops to 1% does the SDR show up in
lsusb
This command will show you what is attached to the USB bus (You might know this already, but I don't know where your skill level sits)

I note that you are using some very old kit with some older software, so I am not 100 sure how to get at the log for dump1090. Might be worth try using the readsb decoder which is still activly maintained/developed.

Yes, everything shows correctly.


The lsusb command
  Bus 001 Device 003: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T

rtl_test -t
Found 1 device(s):
   0: Realtek, RTL2838UHIDIR, SN: 00000001

Using device 0: Generic RTL2832U OEM
Found Rafael Micro R820T tuner
Supported gain values (29): 0.0 0.9 1.4 2.7 3.7 7.7 8.7 12.5 14.4 15.7 16.6 19.7 20.7 22.9 25.4 28.0 29.7
32.8 33.8 36.4 37.2 38.6 40.2 42.1 43.4 43.9 44.5 48.0 49.6
Sampling at 2048000 S/s.
No E4000 tuner found, aborting.


yetti15A

I deleted dump1090 and installed readsb.
Over the course of three days, the planes disappeared once and the processor load level dropped to 1%.
After restarting the program (sudo systemctl restart readsb) everything worked well.
  readsb loads the processor up to 30%.
The obvious solution is if planes still disappear, add a cron job to restart.


rikgale

Before restarting - once the planes go away run

sudo journalctl --no-pager -u readsb
Post the output.

Test the above command when you get the chance to make sure you can see the logs

Auto updated daily ZIP files on GitHub