Serialized receivers stopped working, now 1090-fa2 isnt running

FlightAware ADS-B Flight Tracking
1

Ive had 2 receivers working off a splitter on my 1090 antenna for… 6 months or so.
yesterday I got a notice there was no data coming on 30005. Checked status and both receivers were down. So I rebooted. nothing
rtl_test -t no receivers. weird. unplugged everything and rebooted. finally I was able to plug in 1 receiver and get dump1090-fa /piaware working. whew, streak saved!
but since then Im unable to get my other receiver working.
Status output:
● dump1090-fa2.service - dump1090 ADS-B receiver (FlightAware customization)

Loaded: loaded (/lib/systemd/system/dump1090-fa2.service; enabled; vendor preset: enabled)

Active: activating (auto-restart) (Result: exit-code) since Mon 2023-07-17 12:25:49 EDT; 2s ago

Docs: PiAware - ADS-B and MLAT Receiver - FlightAware

Process: 8181 ExecStart=/usr/share/dump1090-fa/start-dump1090-fa2 --write-json /run/dump1090-fa2 --quiet (code=exited, status=1/FAILURE)

Main PID: 8181 (code=exited, status=1/FAILURE)

Jul 17 12:25:49 raspberrypi systemd[1]: dump1090-fa2.service: Unit entered failed state.

Jul 17 12:25:49 raspberrypi systemd[1]: dump1090-fa2.service: Failed with result ‘exit-code’.
rte_test :
0: Realtek, RTL2832U, SN: 00010902
1: Realtek, RTL2832U, SN: 00010908

/etc/default/dump1090-fa2

dump1090-fa2 won’t automatically start unless ENABLED=yes

ENABLED=yes

RECEIVER_OPTIONS2=“–device-index 00010902 --gain 48 --ppm 0 --net-bo-port 31005”

DECODER_OPTIONS2=“–max-range 360”

NET_OPTIONS2=“–net --net-heartbeat 60 --net-ro-size 1000 --net-ro-interval 1 --net-ri-port 0 --net-ro-port 31002 --net-sbs-port 31003 --net-bi-port 31004,31104 --net-bo-port 31005”

JSON_OPTIONS2=“–json-location-accuracy 1”

dump1090-fa: status
● dump1090-fa.service - dump1090 ADS-B receiver (FlightAware customization)
Loaded: loaded (/lib/systemd/system/dump1090-fa.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2023-07-17 12:28:51 EDT; 7s ago
Docs: PiAware - ADS-B and MLAT Receiver - FlightAware
Main PID: 10614 (dump1090-fa)
Tasks: 3 (limit: 4915)
CGroup: /system.slice/dump1090-fa.service
└─10614 /usr/bin/dump1090-fa --quiet --device-type rtlsdr --device-index 00010908 --gain 20.7 --adaptive-range-target 48 --lat 40.73875 --lon -74.45491 --max-range 360 --net-ro-port 30002 --net-sbs-port 30003 --net-bi-port 30004,30104 --net-bo-port 30005 --json-location-accuracy

any ideas or tests I can run?
I checked both receivers on a 2nd PI running piaware and both run without issue so hardware is ok.

2

 

Please post outpits of followinf commands:

rtl_test -t

apt-cache policy dump1090-fa

 

3

Welcome to my world…Sounds like you and I are in the same boat.

1 Like
4

$ rtl_test -t

Found 2 device(s):

0: Realtek, RTL2832U, SN: 00010902

1: Realtek, RTL2832U, SN: 00010908

Using device 0: Generic RTL2832U

usb_claim_interface error -6

Failed to open rtlsdr device #0.

5

Your /etc/default/dump1090-fa2 file (quoted above) shows you are using a very old version of dump1090-fa

Please post output of following command:

apt-cache policy dump1090-fa

 

NOTE
The dump1090-fa2 does not output data on port 30005. It outputs data on port 31005.

6

apt-cache policy dump1090-fa
dump1090-fa:
Installed: 8.2~bpo9+1
Candidate: 8.2~bpo9+1
Version table:
*** 8.2~bpo9+1 500
500 http://flightaware.com/adsb/piaware/files/packages stretch/piaware armhf Packages
100 /var/lib/dpkg/status

It should be the latest dump1090-fa, just an older config file format, from the guide I followed specific to setting up 2 dump1090-fa instances for dual receivers for different gains.

just for fun I copied the dump1090-fa file to dump1090-fa2 and changed to settings, but no difference.

7

I only have my alert checking for data on 1090-fa, mainly ensure the network is up, and pi is running.

8

Try this:

sudo systemctl stop dump1090-fa2    

sudo dump1090-fa --device-index 00010902  

sudo dump1090-fa --device-index 00010902 --interactive
9

sudo systemctl stop piaware2
sudo systemctl stop dump1090-fa2
sudo dump1090-fa --device-index 00010902

Mon Jul 17 17:22:22 2023 EDT dump1090-fa 8.2~bpo9+1 starting up.

rtlsdr: using device #0: Generic RTL2832U (Realtek, RTL2832U, SN 00010902)

usb_claim_interface error -6

rtlsdr: error opening the RTLSDR device: Device or resource busy

sudo dump1090-fa --device-index 00010902 --interactive

Mon Jul 17 17:22:27 2023 EDT dump1090-fa 8.2~bpo9+1 starting up.

rtlsdr: using device #0: Generic RTL2832U (Realtek, RTL2832U, SN 00010902)

usb_claim_interface error -6

rtlsdr: error opening the RTLSDR device: Device or resource busy

I did move it to a different port, and when I did the non-interactive version it spit out a ton of data.
I tried to restart piaware2 and dump1090-fa2 however, it failed and now im back to usb claim error 6, and unplugging doesnt help.

10

This shows that dongle serial 00010902 is being used by dump1090-fa. We will now test dongle serial 00010908

sudo systemctl stop piaware dump1090-fa  

sudo systemctl stop piaware2 dump1090-fa2  

sudo dump1090-fa --device-index 00010908
11

I did need to unplug and replug for the other receiver to show up again. I think maybe my lsusb command was throwing off the usb ports??

sudo dump1090-fa --device-index 00010902

Mon Jul 17 17:56:13 2023 EDT dump1090-fa 8.2~bpo9+1 starting up.

rtlsdr: using device #0: Generic RTL2832U (Realtek, RTL2832U, SN 00010902)

Detached kernel driver

Found Rafael Micro R820T tuner

rtlsdr: tuner gain set to 49.6 dB (gain step 28)

^CMon Jul 17 17:56:21 2023 EDT Caught SIGINT, shutting down…

Mon Jul 17 17:56:21 2023 EDT Waiting for receive thread termination

Reattached kernel driver

Mon Jul 17 17:56:21 2023 EDT Normal exit.

$** sudo dump1090-fa --device-index 00010908

Mon Jul 17 17:56:24 2023 EDT dump1090-fa 8.2~bpo9+1 starting up.

rtlsdr: using device #1: Generic RTL2832U (Realtek, RTL2832U, SN 00010908)

Detached kernel driver

Found Rafael Micro R820T tuner

rtlsdr: tuner gain set to 49.6 dB (gain step 28)

*8da21bea5877131929360f003137;

CRC: 000000

RSSI: -2.8 dBFS

Score: 25 (DF17_UNKNOWN)

Time: 1111.50us

DF:17 AA:A21BEA CA:5 ME:5877131929360F

Extended Squitter Airborne position (barometric altitude) (11) (reliable)

ICAO Address: A21BEA (Mode S / ADS-B)

Air/Ground: airborne

Baro altitude: 22625 ft

CPR type: Airborne

CPR odd flag: even

CPR latitude: (101524)

CPR longitude: (79375)

and systemctl restart dump1090-fa piaware
dump1090-fa is failing

and now unplug and replug both devices and they’re both running again… what?

12

When dump1090-fa was upraded to ver 8.2, most likely its file /etc/default/dump1090-fa also got replaced by new version and does not have serial number of dongle. As a result at start it randomly uses whichever dongle it first finds.

Please open file /etc/default/dump1090-fa and check it contains dongle serial number.

13

it does - that was one of the things I checked first.

14

As you have mentioned that both are working now, so just keep an eye to make sure this failure does not occure again. Most likely it was temporary thing caused by upgrade, and fixed itself by unplugging replugging the dongles and restarting the dump1090-fa.

15

unplugging and replugging, and then unplugging and shutting down and powering off were my first 2 solutions and didnt bring anything back. Then I tried to update dump1090-fa, but that didnt solve it. did another port swap and that finally fixed dump1090-fa but dump1090-fa2 was still down.
also, LSUSB didnt show any devices except
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter

Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. SMC9514 Hub

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
wondering if my Pi /USB port is failing…

16

Possible.
Or may be the dongle is failing.
Wait and see which hardware finally dies permanently.

17

I’ll keep an eye on it, and update this if it happens again / something fails. Thanks for the help!

18

I think we need details of what in particular you changed to set up two instances.

For example, did you point the second instance at a different start-dump1090-fa helper script that knows to use a different config file? Is that helper up to date with respect to the version that the main package installed?

19

@obj

If my “two-receivers” script was use to install 2 instances, then

First instance:
It is installed from Flightaware repo. as a normal installation. When updates are apolied then the executable binary /usr/bin/dump1090-fa, the startup file, the config file all get updated to the new version as is normal with update/upgrade.

Second instance:
During original installation, it uses same executeable binary (/usr/bin/dump1090-fa), but the installation script creates separate copies of startup file, config file, and service files with dump1090-fa replaced by dump1090-fa2 in their names as well as in contents of these files. These files do NOT get updated during upgrade of dump1090-fa. As a result after upgrade, the 2nd instance becomes a mixture of updated/upgraded binary executeable with old startup, config & service files

Following files are NOT updated/upgraded by command sudo apt upgrade:

/usr/share/dump1090-fa/start-dump1090-fa2
/etc/default/dump1090-fa2
/lib/systemd/system/dump1090-fa2.service

NOTE:
In 2nd instance’s config file (/etc/default/dump1090-fa2), different port numbers are used to have a system without port conflict, as given below. The config of 2nd instance of piaware (piaware2) also uses these revised port numbers:

31002 instead of 30002
31003 instead of 30003
31004,31104 instead of 30004,30104
31005 instead of 30005

 

 

20

@obj

I think @RdRocket16’s original installation was pre ver 6. In this case 2nd instance’s startup file (which are not changed by upgrade to ver 8) will be as follows:

File 1 of 2:
Startup file of 2nd instance of dump1090-fa (pre ver 6)

/usr/share/dump1090-fa/start-dump1090-fa2

#!/bin/sh
# Helper script that reads /etc/default/dump1090-fa2
# and either starts dump1090-fa2 with the configured
# arguments, or exits with status 64 to tell systemd
# not to auto-restart the service.
if [ -f /etc/default/dump1090-fa2 ]
then
    . /etc/default/dump1090-fa2
fi
if [ -f /var/cache/piaware2/location.env ]
then
    . /var/cache/piaware2/location.env
fi
if [ "x$ENABLED" != "xyes" ]
then
    echo "dump1090-fa2 not enabled in /etc/default/dump1090-fa2" >&2
    exit 64
fi
if [ -n "$PIAWARE_LAT" -a -n "$PIAWARE_LON" ]
then
    POSITION="--lat $PIAWARE_LAT --lon $PIAWARE_LON"
fi
exec /usr/bin/dump1090-fa \
     $RECEIVER_OPTIONS2 $DECODER_OPTIONS2 $NET_OPTIONS2 $JSON_OPTIONS2 $POSITION \
     "$@"
# exec failed, do not restart
exit 64

 

File 2 of 2:
Config file of 2nd instant of dump1090-fa (pre ver 6)

/etc/default/dump1090-fa2

# dump1090-fa2 configuration
# This is sourced by /usr/share/dump1090-fa/start-dump1090-fa2 as a
# shellscript fragment.
# If you are using a PiAware sdcard image, this config file is regenerated
# on boot based on the contents of piaware-config.txt; any changes made to this
# file will be lost.
# dump1090-fa2 won't automatically start unless ENABLED=yes
ENABLED=yes
RECEIVER_OPTIONS2="--device-index 00000102 --gain -10 --ppm 0 --net-bo-port 31005"
DECODER_OPTIONS2="--max-range 360"  
NET_OPTIONS2="--net --net-heartbeat 60 --net-ro-size 1000 --net-ro-interval 1 --net-ri-port 0 --net-ro-port 31002 --net-sbs-port 31003 --net-bi-port 31004,31104 --net-bo-port 31005"  
JSON_OPTIONS2="--json-location-accuracy 1"

.