ADS-B messages volumes up and down

[deepquest]

Running latest PiAware and flightaware on my raspberry pi is now acting a bit strange. The volume of plane detect goes up and down. Sometimes when planes are above me I don’t see them detected (I understand that there’s almost no flights between 00:00 and 6am). See my the performance graph for the past 7 days.

Rebooting my raspberry and doing a “sudo service dump1090-fa stop && cd ~/rtl_biast/build/src && ./rtl_biast -b 1 && sudo service dump1090-fa start”

will immediately show some planes, then after a certain time no more detections. The ADS-B them stick seems like working and is attached to noise filter and a 10 m high quality cable to the antenna.

piaware-status

PiAware master process (piaware) is running with pid 602.
PiAware ADS-B client (faup1090) is running with pid 10087.
PiAware ADS-B UAT client (faup978) is not running (disabled by configuration settings)
PiAware mlat client (fa-mlat-client) is running with pid 1220.
Local ADS-B receiver (dump1090-fa) is running with pid 9949.
dump1090-fa (pid 9949) is listening for ES connections on port 30005.
faup1090 is connected to the ADS-B receiver.
piaware is connected to FlightAware.
dump1090 is producing data on localhost:30005.

Your feeder ID is xxxxxxxxxxx (from /var/cache/piaware/feeder_id)

sudo systemctl status dump1090-fa -l
● dump1090-fa.service - dump1090 ADS-B receiver (FlightAware customization)
Loaded: loaded (/lib/systemd/system/dump1090-fa.service; bad; vendor preset: enabled)
Drop-In: /etc/systemd/system/dump1090-fa.service.d
└─bias-t.conf
Active: active (running) since Tue 2022-04-26 09:09:52 +07; 18min ago
Docs: PiAware - ADS-B and MLAT Receiver - FlightAware
Main PID: 9949 (dump1090-fa)
Tasks: 3 (limit: 4915)
CGroup: /system.slice/dump1090-fa.service
└─9949 /usr/bin/dump1090-fa --quiet --device-type rtlsdr --device-index 0 --gain 60 --fix --lat 13.71753 --lon 100.60002 --max-range 360 --net-ro-port 30002 –

Apr 26 09:09:52 piaware systemd[1]: Started dump1090 ADS-B receiver (FlightAware customization).
Apr 26 09:09:52 piaware dump1090-fa[9949]: Tue Apr 26 09:09:52 2022 +07 dump1090-fa 7.2~bpo10+1 starting up.
Apr 26 09:09:52 piaware dump1090-fa[9949]: rtlsdr: using device #0: Generic RTL2832U OEM (Realtek, RTL2838UHIDIR, SN 00000001)
Apr 26 09:09:52 piaware dump1090-fa[9949]: Detached kernel driver
Apr 26 09:09:52 piaware dump1090-fa[9949]: Found Rafael Micro R820T tuner
Apr 26 09:09:52 piaware dump1090-fa[9949]: rtlsdr: tuner gain set to about 58.6 dB (gain step 29) (tuner AGC enabled)
Apr 26 09:09:52 piaware dump1090-fa[9949]: Allocating 4 zero-copy buffers
Apr 26 09:27:08 piaware systemd[1]: /etc/systemd/system/dump1090-fa.service.d/bias-t.conf:1: Invalid section header '[Service] ExecStartPre=/home/pi/rtl_biast/build/src/r

I also check the very useful page about testing the feeder:

Debug commands · wiedehopf/adsb-wiki Wiki

sudo bash -c “$(wget -nv -O - https://raw.githubusercontent.com/wiedehopf/adsb-scripts/master/rtl_test.sh)”

2022-04-26 09:33:48 URL:https://raw.githubusercontent.com/wiedehopf/adsb-scripts/master/rtl_test.sh [2387/2387] → “-” [1]

14532 /usr/bin/dump1090-fa --quiet --device-type rtlsdr --device-index 0 --gain 60 --fix --lat 13.71753 --lon 100.60002 --max-range 360 --net-ro-port 30002 --net-sbs-port 30003 --net-bi-port 30004,30104 --net-bo-port 30005 --json-location-accuracy 2 --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
Detached kernel driver
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 144 bytes
Signal caught, exiting!
Samples per million lost (minimum): 1

Reattached kernel driver

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.

Any ideas where should start to look?

[send2gl]

I’m no expert on the Pi programming or of aircraft but I do know we expect a lot of the Pi. The power supply is a weak point, as is the microSD card, if that is how you run it.

Which Pi do you use, are any other programs or services installed on the Pi that might be using the CPU? What type of antenna, inside or out? This can be a major factor.

Radio waves can be affected by so much, buildings, trees, hills, reflected signals etc

Hopefully some more knowledgeable than me may offer some tips.

Geoff

[wiedehopf]

@deepquest

Any ideas where should start to look?

Do you need to reboot to fix it?

It’s pretty clear it’s some noise issue as you can see in the signal level graph.
Have you tried just restarting the dump1090-fa service?

Might be the SDR going bad to be quite honest, such loud noise isn’t a good sign.
It could be external interference but then rebooting wouldn’t fix it.

[deepquest]

I pass few tests for the power supply and sd card but they seem fine.

[deepquest]

First thank you for all your hard work and useful informations.

Yes I restarted sudo service dump1090-fa stop && cd ~/rtl_biast/build/src && ./rtl_biast -b 1 && sudo service dump1090-fa restart

Thank you you it’s been fixed using your recommendations: RTL Bias Tee · wiedehopf/adsb-wiki Wiki · GitHub