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)
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:
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).
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?
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 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.
Hi, just wanted to chime in here to say that I had a similar problem and this thread was the most helpful in resolving the issue.
The issue was dump978-fa was attempting to utilize the wrong USB device on a two dongle system. It was really all my fault: all of the instructions I had Googled for “how to add 978 to an existing 1090 piaware setup” assumed use of the piaware SD card image. I did my own install of buster lite, so obviously the piaware-config commands did nothing and I had to edit the /etc/default/dump* files manually. I should have known this, I had it fresh in my mind less than a week ago when changing the gain required the same /etc/default/dump* editing.
Just a thought: wouldn’t it be nice if the SD card image and the manual package install method had different names? I feel there’s some confusion in that “piaware” could refer to the SD card image or the main process and package/glue logic that feeds data to flightaware.
Quick second thought: adjust the piaware package system such that piaware-config can be used when the piaware package is manually installed and not part of the SD card image.
Ha ha, I only discovered the confusion myself a few months after initial package setup when 1) I searched for instructions on how to add/enable UAT 978 with an FA orange stick on my Pi that already had a FA blue stick. 2) When I did random Google searches for things like serializing dongles or tweaking PiAware or Dumpxxx(x)-fa settings.
In the end it was just a couple hours of initial confusion with instructions. Lessons learned, part of learning how things work like anything else.
I remember wanting to give feedback that a few guides in general could do better with a simple caveat at the top explaining the guide is for PiAware image vs package install.
Basically the links to PiAware setup pages and those pages themselves should reference more frequently something along the lines of “See here if you use the PiAware package install”
Again, no big deal, but too easy to take a wrong turn for noobs.
Ya, but finding those perfect helpful community posts and guides when you are new and overwhelmed isn’t easy. It takes several searches and a lot of reading to find the right guidance.
I’m pretty fluent and advanced myself now, but there were a few bumps and confusing missteps early on. I guess that is my point. It’s pretty easy to find the wrong instructions, and pretty hard to find the right ones.
I’m having a laugh here because the naming thing could be directed at the Pi people as well since Raspbian is now Rasperry Pi OS.
Does this forum software allow editing of the the post title? If so sir, may I suggest adding “Raspberry Pi OS” to your post title for #2? A quick Google check shows you are result #3 for “piaware raspbian os” but do not show up at all on the first page for “piaware raspberry pi os”.
There should just be a warning if the commands won’t do anything.
Along these lines I have a question. On the help page for adding piaware to an existing Raspbian installation (should probably update that page to say Raspberry Pi OS too) here:
These exist on the page for adding piaware to a non-SD image install so I’m assuming they are an exception to the rule?
If this exception exists that means there already exists code to look at piaware-config, would it be too much of a stretch to make this work for all commands instead of just those two?
Those USB ports sure are cramped when you try to fit in two dongles at once…