FlightAware Discussions

978 setup help -- ongoing usb_claim_interface errors

Good afternoon fine people! I’m currently about 50% down with the flu and using the energy I have to update my PiAware setup to allow me to see both the 1090 and 978 traffic. After creating a fresh 3.8.0 PiAware install on Buster (and fixing my site ID and all that) I have the system booting properly showing both radios on the status page. The 978 radio never connects though, I think in part due to the usb_claim_interface errors. I’m not coming here having tried nothing, but I am stumped…

What I’ve done:

  • I’ve serialized both USB sticks, one to 00001090 and one to 00000978. 1090 works great so some things are right

  • I’ve followed the Quickstart guide and configured UAT (after all it, it does show up in the status fine, just doesn’t work)

sudo piaware-config uat-sdr-device driver=rtlsdr,serial=00000978

  • I’ve blacklisted the RTL devices

And still nothing. Here’s the log I get, repeating every 30 seconds…

Jan 04 02:50:19 piaware systemd[1]: dump978-fa.service: Service RestartSec=30s expired, scheduling restart.

Jan 04 02:50:19 piaware systemd[1]: dump978-fa.service: Scheduled restart job, restart counter is at 5.

Jan 04 02:50:19 piaware systemd[1]: Stopped dump978 ADS-B UAT receiver.

Jan 04 02:50:20 piaware systemd[1]: Started dump978 ADS-B UAT receiver.

Jan 04 02:50:20 piaware dump978-fa[877]: raw-port: listening for connections on 0.0.0.0:30978

Jan 04 02:50:20 piaware dump978-fa[877]: raw-port: listening for connections on [::]:30978

Jan 04 02:50:20 piaware dump978-fa[877]: json-port: listening for connections on 0.0.0.0:30979

Jan 04 02:50:20 piaware dump978-fa[877]: json-port: listening for connections on [::]:30979

Jan 04 02:50:20 piaware dump978-fa[877]: usb_claim_interface error -6

Jan 04 02:50:20 piaware dump978-fa[877]: Found Rafael Micro R820T tuner

Jan 04 02:50:20 piaware dump978-fa[877]: usb_claim_interface error -6

Jan 04 02:50:20 piaware dump978-fa[877]: SoapySDR: using maximum manual gain 49.6 dB

Jan 04 02:50:20 piaware dump978-fa[877]: SoapySDR: using stream setting buffsize=262144

Jan 04 02:50:24 piaware dump978-fa[877]: [::]:30978: accepted a connection from [::1]:38756

Jan 04 02:50:25 piaware dump978-fa[877]: Message source reports error: TIMEOUT

Jan 04 02:50:25 piaware dump978-fa[877]: Abnormal exit

Jan 04 02:50:25 piaware systemd[1]: **dump978-fa.service: Main process exited, code=exited, status=1/FAILURE**

Jan 04 02:50:25 piaware systemd[1]: **dump978-fa.service: Failed with result 'exit-code'.**

And obviously I’m missing some magic for correctly pasting a log. Sorry about that.

The first claim interface error is probably a red herring (it’s a result of soapysdr trying to scan across all devices and hitting the 1090 one that’s already in use).

However the soapysdr rtlsdr driver isn’t great about reporting real errors, so if it really can’t claim the right dongle then you get very similar output, but the error doesn’t make it out dump978 proper, and it tries to continue and then doesn’t get any data (because the dongle never got connected properly) and gets a TIMEOUT.

Are you sure that dump1090 is using the right dongle?
Try this and see if it works OK:

sudo systemctl stop dump978-fa
rtl_test -d 00000978 -s 2083333

FWIW, this is what a “normal” dump978 startup on a dual-dongle system looks like (note the extra messages compared to yours - I suspect it is a dongle conflict)

Jan 04 04:54:44 piaware systemd[1]: Started dump978 ADS-B UAT receiver.
Jan 04 04:54:45 piaware dump978-fa[29749]: raw-port: listening for connections on 0.0.0.0:30978
Jan 04 04:54:45 piaware dump978-fa[29749]: raw-port: listening for connections on [::]:30978
Jan 04 04:54:45 piaware dump978-fa[29749]: json-port: listening for connections on 0.0.0.0:30979
Jan 04 04:54:45 piaware dump978-fa[29749]: json-port: listening for connections on [::]:30979
Jan 04 04:54:45 piaware dump978-fa[29749]: Detached kernel driver
Jan 04 04:54:45 piaware dump978-fa[29749]: Found Rafael Micro R820T tuner
Jan 04 04:54:45 piaware dump978-fa[29749]: Reattached kernel driver
Jan 04 04:54:45 piaware dump978-fa[29749]: usb_claim_interface error -6
Jan 04 04:54:45 piaware dump978-fa[29749]: Detached kernel driver
Jan 04 04:54:46 piaware dump978-fa[29749]: Found Rafael Micro R820T tuner
Jan 04 04:54:46 piaware dump978-fa[29749]: Exact sample rate is: 2083333.135571 Hz
Jan 04 04:54:46 piaware dump978-fa[29749]: [R82XX] PLL not locked!
Jan 04 04:54:46 piaware dump978-fa[29749]: SoapySDR: using maximum manual gain 49.6 dB
Jan 04 04:54:46 piaware dump978-fa[29749]: SoapySDR: using stream setting buffsize=262144
Jan 04 04:54:46 piaware dump978-fa[29749]: Allocating 15 zero-copy buffers
Jan 04 04:54:46 piaware dump978-fa[29749]: 0.0.0.0:30978: accepted a connection from 127.0.0.1:34768
Jan 04 04:54:46 piaware dump978-fa[29749]: Detected Kernel usbfs mmap() bug, falling back to buffers in userspace

… and if I make dump1090 use the “wrong” dongle, then I get exactly the same log output as you see (fewer messages, TIMEOUT error). So I’m definitely leaning towards “dump1090 is using the 978 dongle”.

Failing that, the TIMEOUT means that data isn’t flowing from the dongle properly for some reason. You may have power problems.

Thanks. After a moment of doubt, I checked that dump1090 was using the correct dongle and it is. When I run the rtl_test command I get this:

**pi@piaware** : **~ $** rtl_test -d 00000978 -s 2083333

Found 2 device(s):

0: Realtek, RTL2832U, SN: 00001090

1: Realtek, RTL2832U, SN: 00000978

Using device 1: Generic RTL2832U

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

Exact sample rate is: 2083333.135571 Hz

[R82XX] PLL not locked!

Sampling at 2083333 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 168 bytes

Pawing through my junk bin looking for a powered hub to try next (unpowered hub currently).

A couple of other simple things to try:

  • try stopping dump1090-fa and see if it helps
  • try disconnecting the 1090 dongle and see if it helps

The power thing seems to have done the trick, or at least gotten me to the next question. Couldn’t find a powered hub, but found a USB extension cable that allows me to ditch the unpowered up and have both dongles connected directly to the RPi.

In this case, everything initializes fine, and the status screen shows the UAT radio as yellow with the note “Connected to UAT receiver but no recent data seen”.

No shocker there, as my Stratux doesn’t see any UAT aircraft in range either. BUT, I am in line of sight of the FAA tower and on the Stratux I see a constant bombardment of FIS-B data.

Does the dump978 instance ignore all that when it says it has no data, or is it seemingly deaf?

Thanks again for all the help.

dump978 should be hearing that (try connecting to port 30978, you should see the uplink messages) but faup978/piaware doesn’t process FIS-B or TIS-B which will be why you see the warning.

FWIW, this is exactly the setup I tested here :slight_smile: Those USB ports sure are cramped when you try to fit in two dongles at once…

Thanks again for all the help. I did not get to listening to the port to see the the FIS-B data, but I am seeing actual 978 traffic right now so that’s my signal to stop breaking stuff.