RTL SDR gone bad?

FlightAware ADS-B Flight Tracking
1

I have a Nooelec NESDR Mini R820T SDR & DVB-T dongle using with Raspberry pi, which has been working fine for few months, suddenly stopped generating any data.

have already tried to power cycle the whole setup twice.

Wanted to see if this indicates a likely failure with the dongle or some level of further troubleshooting can be done?

Setup and version details are below:

$ cat /sys/firmware/devicetree/base/model
Raspberry Pi 5 Model B Rev 1.0

$ cat /etc/*-release
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=debian

$ dump1090-fa --version
-----------------------------------------------------------------------------
| dump1090 ModeS Receiver                                   dump1090-fa 9.0 |
| build options: ENABLE_RTLSDR ENABLE_BLADERF ENABLE_HACKRF ENABLE_LIMESDR  |
-----------------------------------------------------------------------------
  detected runtime CPU features:
  selected DSP implementations:
    magnitude_uc8                            neon_vrsqrte_armv8_neon_simd
    magnitude_uc8_aligned                    neon_vrsqrte_armv8_neon_simd
    magnitude_power_uc8                      neon_vrsqrte_armv8_neon_simd
    magnitude_power_uc8_aligned              neon_vrsqrte_armv8_neon_simd
    magnitude_sc16                           neon_vrsqrte_armv8_neon_simd
    magnitude_sc16_aligned                   neon_vrsqrte_armv8_neon_simd
    magnitude_sc16q11                        neon_vrsqrte_armv8_neon_simd
    magnitude_sc16q11_aligned                neon_vrsqrte_armv8_neon_simd
    mean_power_u16                           u32_armv8_neon_simd
    mean_power_u16_aligned                   u32_armv8_neon_simd
    count_above_u16                          generic_armv8_neon_simd
    count_above_u16_aligned                  generic_armv8_neon_simd_aligned
 
$ piaware -v
9.0.1

Following logs are observed for dump1909-fa from which don’t see anything stand out

Apr 29 16:14:01 octopi dump1090-fa[881]: Mon Apr 29 16:14:01 2024 IST  dump1090-fa 9.0 starting up.
Apr 29 16:14:01 octopi dump1090-fa[881]: rtlsdr: using device #0: Generic RTL2832U OEM (Realtek, RTL2838UHIDIR, SN 00000001)
Apr 29 16:14:01 octopi dump1090-fa[881]: Detached kernel driver
Apr 29 16:14:01 octopi dump1090-fa[881]: Found Rafael Micro R820T tuner
Apr 29 16:14:01 octopi dump1090-fa[881]: rtlsdr: tuner gain set to about 58.6 dB (gain step 29) (tuner AGC enabled)
Apr 29 16:14:01 octopi dump1090-fa[881]: adaptive: using 50% duty cycle
Apr 29 16:14:01 octopi dump1090-fa[881]: adaptive: enabled adaptive gain control with gain limits 0.0dB (step 0) .. 58.6dB (step 29)
Apr 29 16:14:01 octopi dump1090-fa[881]: adaptive: enabled dynamic range control, target dynamic range 30.0dB
Apr 29 16:14:01 octopi dump1090-fa[881]: adaptive: enabled burst control
Apr 29 16:14:01 octopi dump1090-fa[881]: Allocating 4 zero-copy buffers
Apr 29 16:14:11 octopi dump1090-fa[881]: adaptive: reached upper gain limit, halting dynamic range scan here

from the piaware logs I can see its not getting any data

Apr 29 16:14:07 octopi piaware[1274]: creating pidfile /run/piaware/piaware.pid
Apr 29 16:14:07 octopi piaware[1274]: ****************************************************
Apr 29 16:14:07 octopi piaware[1274]: piaware version 9.0.1 is running, process ID 1274
Apr 29 16:14:07 octopi piaware[1274]: your system info is: Linux octopi 6.1.0-rpi7-rpi-2712 #1 SMP PREEMPT Debian 1:6.1.63-1+rpt1 (2023-11-24) aarch64 GNU/Linux
Apr 29 16:14:09 octopi piaware[1274]: Connecting to FlightAware adept server at piaware.flightaware.com/1200
Apr 29 16:14:09 octopi piaware[1274]: Connection with adept server at piaware.flightaware.com/1200 established
Apr 29 16:14:09 octopi piaware[1274]: TLS handshake with adept server at piaware.flightaware.com/1200 completed
Apr 29 16:14:09 octopi piaware[1274]: FlightAware server certificate validated
Apr 29 16:14:09 octopi piaware[1274]: encrypted session established with FlightAware
Apr 29 16:14:10 octopi piaware[1274]: ADS-B data program 'dump1090-fa' is listening on port 30005, so far so good
Apr 29 16:14:10 octopi piaware[1274]: Starting faup1090: /usr/lib/piaware/helpers/faup1090 --net-bo-ipaddr localhost --net-bo-port 30005 --stdout --lat 12.899 --lon 77.709
Apr 29 16:14:10 octopi piaware[1274]: Started faup1090 (pid 1598) to connect to dump1090-fa
Apr 29 16:14:10 octopi piaware[1274]: UAT support disabled by local configuration setting: uat-receiver-type
Apr 29 16:14:10 octopi piaware[1274]: adept reported location: 12.89878, 77.70895, 150ft AMSL

Apr 29 16:14:10 octopi piaware[1274]: multilateration data requested
Apr 29 16:14:10 octopi piaware[1274]: Starting multilateration client: /usr/lib/piaware/helpers/fa-mlat-client --input-connect localhost:30005 --input-type dump1090 --results beast,connect,localhost:30104 --results beast,listen,30105 --results ext_basestation,listen,30106 --udp-transport 206.253.84.198:19597:1230057416
Apr 29 16:14:10 octopi piaware[1274]: mlat-client(1601): fa-mlat-client 0.2.13 starting up
Apr 29 16:14:10 octopi piaware[1274]: mlat-client(1601): Using UDP transport to 206.253.84.198 port 19597
Apr 29 16:14:10 octopi piaware[1274]: mlat-client(1601): Listening for Beast-format results connection on port 30105
Apr 29 16:14:10 octopi piaware[1274]: mlat-client(1601): Listening for Extended Basestation-format results connection on port 30106
Apr 29 16:14:10 octopi piaware[1274]: mlat-client(1601): Route MTU changed to 1500
Apr 29 16:14:10 octopi piaware[1274]: mlat-client(1601): Input connected to localhost:30005
Apr 29 16:14:10 octopi piaware[1274]: mlat-client(1601): Input format changed to BEAST, 12MHz clock
Apr 29 16:14:11 octopi piaware[1274]: mlat-client(1601): Beast-format results connection with ::1:30104: connection established
Apr 29 16:14:42 octopi piaware[1274]: 0 msgs recv'd from dump1090-fa; 0 msgs sent to FlightAware
Apr 29 16:19:25 octopi piaware[1274]: mlat-client(1601): Disconnecting from localhost:30005: No data (not even keepalives) received for 150 seconds
Apr 29 16:19:25 octopi piaware[1274]: mlat-client(1601): Input connected to localhost:30005
Apr 29 16:19:25 octopi piaware[1274]: mlat-client(1601): Input format changed to BEAST, 12MHz clock
Apr 29 16:19:42 octopi piaware[1274]: 0 msgs recv'd from dump1090-fa (0 in last 5m); 0 msgs sent to FlightAware
Apr 29 16:24:42 octopi piaware[1274]: 0 msgs recv'd from dump1090-fa (0 in last 5m); 0 msgs sent to FlightAware

Apr 29 16:19:25 octopi piaware[1274]: mlat-client(1601): Disconnecting from localhost:30005: No data (not even keepalives) received for 150 seconds

no under voltage issues seen

Status: 0x0
Undervolted:
   Now: NO
   Run: NO
Throttled:
   Now: NO
   Run: NO
Frequency Capped:
   Now: NO
   Run: NO
Softlimit:
   Now: NO
   Run: NO

I do see PLL not locked, is that again indicative of dongle failure?

881 /usr/bin/dump1090-fa --quiet --device-type rtlsdr --gain 60 --adaptive-range --adaptive-burst --fix --lat 12.8987 --lon 77.7090 --max-range 360 --net-ro-port 30002 --net-sbs-port 30003 --net-bi-port 30004,30104 --net-bo-port 30005 --json-location-accuracy 1 --write-json /run/dump1090-fa
-----
Lost samples in the first 2 seconds after starting the test are common and not a problem!
Starting 30 second rtl_test, standby!
-----
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
[R82XX] PLL not locked!
Sampling at 2400000 S/s.

Info: This tool will continuously read from the device, and report if
samples get lost. If you observe no further output, everything is fine.

Reading samples in async mode...
Allocating 15 zero-copy buffers
lost at least 48 bytes
Signal caught, exiting!

User cancel, exiting...
Samples per million lost (minimum): 0
-------
Test finished!
More than 2 lost samples per million or other errors probably mean the receiver isn't working correctly.
Try another power supply before condemning the receiver though!
-------
-------
No undervoltage detected, looking fine!
If the dongle is not directly plugged into the Raspberry Pi, lack of power/voltage could still be an issue.
Even without detected undervoltage a better power supply can often improve reception!
For optimum performance i would recommend the Official Raspberry Pi power supply.
2

You have a signal graph for the last months by chance? (graphs1090)

1 Like
3

yes, I have the graphs data. Surprisingly I checked it again today and was seeing better signals. Going to pull the logs and see if something interesting was logged.

48 hours signal graph, see the dip for yesterday

Screenshot 2024-04-30 at 12.23.08 PM
Screenshot 2024-04-30 at 12.23.08 PM1228Ă—638 103 KB

4

new users only allowed 1image per post, thus adding 1 month graph here

Screenshot 2024-04-30 at 12.25.32 PM
Screenshot 2024-04-30 at 12.25.32 PM1230Ă—642 95 KB

5

Possibly a loose connection from the SDR to the antenna?

Or an intermittent fault in one of the analog stages of the SDR.
Might have to get a new SDR.

6

Could it be the power supply? I was impressed by what a proper wall-wort does for my bad hack job. I’ve used Cana-kit in north america.

On to Buster/Debian/Linux open-source.

I learned do-loops in fortran iv and I am completely lost software-wise.

1 Like
7

Curiously, mine also failed at about the same time yours did.
I was previously running 1090 and 978 receivers on the same 3B+, with the Noolec running 1090. Now I only have 978 running and switching out RTLSDR dongles has had no effect. I suspect PiAware cooked my SD card (after running for over two years straight on the same card, mind).

8

Anopther possibility is that microSD card is OK, but software got corrupted.

First re-image microSD card with latest image. If this does not solve the problem, then use a new microSD card.

2 Likes
9

Yeah, I’ll be giving that a shot but I had planned on making another feeder anyway, to get the 1090 and 978 stations on separate SBC’s. Also - glad to see you’re still here!

10

Nope. Card was fried after all. :
Edit: Now that I’m only running 1090 on that with an old flightaware pro stick and filter on a cantenna… good lord. I think I’m seeing three times as many 1090 aircraft.

1 Like
11

Happy Aniversary. You are member since 2015. I am also member since nearly the same time (since 2014)
Screenshot_20240503_004105_Samsung Internet

12

Wow, Great
Congratulations :+1: :clap:

13

apologies for getting back a bit late, I had checked the connectivity to the antenna and even tried to swap out with a known working one. So don’t think it was an antenna connectivity issue.

Ruled out power issues as well, as the setup is hooked to a UPS. And only reboots were done by me manually.

I went through the logs and couldn’t find anything conclusive. From the piaware logs all I could see was MLAT client connected by not in sync with peers and a non-zero log for out of order timestamps

Apr 29 09:06:18 octopi piaware[1280]: mlat-client(1632): Receiver status: connected
Apr 29 09:06:18 octopi piaware[1280]: mlat-client(1632): Server status:   not synchronized with any nearby receivers
Apr 29 09:06:18 octopi piaware[1280]: mlat-client(1632): Receiver:    0.3 msg/s received        0.1 msg/s processed (34%)
Apr 29 09:06:18 octopi piaware[1280]: mlat-client(1632): Server:      0.0 kB/s from server    0.0kB/s TCP to server     0.0kB/s UDP to server
Apr 29 09:06:18 octopi piaware[1280]: mlat-client(1632): Aircraft: 0 of 0 Mode S, 0 of 0 ADS-B used
Apr 29 09:06:18 octopi piaware[1280]: mlat-client(1632): Out-of-order timestamps: 3

On two instances I’d see the piaware would go ahead and restart dump1090, due to lack of receiving any data

Apr 29 12:39:36 octopi piaware[1280]: no new messages received in 3820 seconds, it might just be that there haven't been any aircraft nearby but I'm going to try to restart everything, just in case...
Apr 29 12:39:37 octopi piaware[1280]: faup1090 exited with SIG SIGHUP
Apr 29 12:39:37 octopi piaware[1280]: attempting to restart dump1090..

Apr 29 20:16:01 octopi piaware[18106]: no new messages received in 3602 seconds, it might just be that there haven't been any aircraft nearby but I'm going to try to restart everything, just in case...
Apr 29 20:16:02 octopi piaware[18106]: faup1090 exited with SIG SIGHUP
Apr 29 20:16:02 octopi piaware[18106]: attempting to restart dump1090..
Apr 29 20:16:02 octopi systemd[1]: dump1090-fa.service: Deactivated successfully.

One thing which did stand out to me was that the entire day fr24feed service would log messages indicating issues with syncing time from NTP server.

Apr 29 09:17:26 octopi fr24feed[1352]: [time][i]Synchronizing time via NTP
Apr 29 09:17:29 octopi fr24feed[1352]: [feed][n]ping 31
Apr 29 09:17:30 octopi fr24feed[1352]: [feed][n]syncing stream result: 1
Apr 29 09:17:35 octopi fr24feed[1352]: [time][e]Failed to synchronize time
Apr 29 09:17:41 octopi fr24feed[1352]: [time][i]Synchronizing time via NTP
Apr 29 09:17:48 octopi fr24feed[1352]: [reader][i]Timestamp source changed from SYSTEM-VALIDATED to SYSTEM-UNCERTAIN
Apr 29 09:17:51 octopi fr24feed[1352]: [time][e]Failed to synchronize time
Apr 29 09:17:59 octopi fr24feed[1352]: [feed][n]ping 32
Apr 29 09:18:00 octopi fr24feed[1352]: [feed][n]syncing stream result: 1
Apr 29 09:18:01 octopi fr24feed[1352]: [time][i]Synchronizing time via NTP
Apr 29 09:18:06 octopi fr24feed[1352]: [time][i]Time synchronized correctly, offset +0.011 seconds, drift +0.000 seconds/minute
Apr 29 09:18:29 octopi fr24feed[1352]: [feed][n]ping 33
Apr 29 09:18:30 octopi fr24feed[1352]: [feed][n]syncing stream result: 1
Apr 29 09:18:48 octopi fr24feed[1352]: [reader][i]Timestamp source changed from SYSTEM-UNCERTAIN to SYSTEM-VALIDATED

I checked the system and as per timedatectl the clock was in sync

Apr 29 15:30:44 octopi systemd[1]: Starting systemd-timesyncd.service - Network Time Synchronization...
Apr 29 15:30:44 octopi systemd[1]: Started systemd-timesyncd.service - Network Time Synchronization.
Apr 29 15:33:12 octopi systemd-timesyncd[558]: Contacted time server 162.159.200.1:123 (time.cloudflare.com).
Apr 29 15:33:12 octopi systemd-timesyncd[558]: Initial clock synchronization to Mon 2024-04-29 15:33:12.179486 IST.
Apr 29 15:53:49 octopi systemd[1]: Stopping systemd-timesyncd.service - Network Time Synchronization...
Apr 29 15:53:49 octopi systemd[1]: systemd-timesyncd.service: Deactivated successfully.
Apr 29 15:53:49 octopi systemd[1]: Stopped systemd-timesyncd.service - Network Time Synchronization.

The fr24feed logs are present only on the day (April 29th) on which I saw the SDR misbehaving , though the logs are present outside of the window (i.e when SDR was working), so not sure if I can correlate these to the issue.

14

Be careful with this line of reasoning. When these things have “power issues”, it’s not usually “wall power” or 120/240v that cause the problem - and that’s the only thing that a UPS will help with. The problem is is almost always an inadequate “wall wart” which either can’t provide the required 2.5a at 5v DC at all, or can’t do it consistently over time.

A lot of folks try to repurpose a cell phone charger that they have laying around to power their Pi. And it works sometimes. But most of those top out at 2 amps, and most aren’t rated for a 100% duty cycle.

If you are just using your Pi to run PiHole, it often works fine. But when you add the load of powering the dongle, and maybe a bias tee, you can start seeing the power fluctuate. And that can cause errors and unexpected and inconsistent behaviors that can be extremely hard to troubleshoot.

I would only feel confident that I wasn’t having power issues if I were using the official Raspberry Pi power supply - or at least a known equivalent like the Cana-Kit one.

There is a command that you can run (sorry I don’t have it handy) that will search your logs for any power-related errors. I’m sure someone will share it shortly.

1 Like
15

replace it.
get an SDR with integrated LNA / filter: one of those:

  • adsbexchange filtered SDR: Amazon.com
  • FA Pro Plus

FR24 is beyond bad software, such logs are very normal.

1 Like
16

The process of stopping fr24feed takes 1-min 30-sec (90 sec). when Pi is rebooted.
​​​​​This is too long as all other processes and feeders (piaware, planefinder etc etc) take hardly 5 to 10 seconds to stop​​

Click on Screeshot to See Larger Size

fr24feed-takes-too-long-to-stop
fr24feed-takes-too-long-to-stop892Ă—233 47.6 KB

 

I solved this by editing service file and adding a line, as detailed below.
After following workaround, the 1min 30sec (90 sec) delay in stopping fr24feed disappeared, and reboot became very fast.

(1) Issued following command to open fr24feed service file

sudo nano /etc/systemd/system/fr24feed.service

(2) Added following line

ExecStop=/usr/bin/pkill fr24feed

(3) After adding above line and saving service file, issued following commands

sudo systemctl daemon-reload 
sudo systemctl restart fr24feed

Please see screenshot below

Click on Screeshot to See Larger Size

fr24feed-takes-too-long-to-stop-WORKAROUND
fr24feed-takes-too-long-to-stop-WORKAROUND829Ă—484 22.3 KB

 

4 Likes
17

10-4 on the Cana-kit USB-C PS product. I am enjoying the CanaKit model DCAR-RSP-3A5C. Output is 5.1v at 3.5 A. My intermittent power issues have disappeared since the install of that power supply.

2 Likes
18

I use the latest official Raspberry Pi 5.1v 5 amp (27 watt ) power supply. The unit was released to power the RPi 5 but it is good for all Pi’s with USB C.

19

Sounds like a good one. CanaKit came out with a 45w unit for the RPi 5 for $20. Nice to have choices.

1 Like