USB Claim Error 6 Hail Mary

I am running three RTLSDR dongles. Sometimes it all works, other times I get a usb claim error. Other times dump1090-fa grabs the wrong dongle which allows things to start but gets no data per being the wrong dongle with the wrong antenna.

I have done all the blacklisting and compiling and add rules to whatever that the University Of Google says should have fixed things.

Starting up, unplugging all USB devices and then plugging in one at a time as I manually start up services seems to work. But reboots are problematic.

I have changed the serial numbers of devices and modified piaware.conf to reflect.

I installed dump1090-fa and piaware per these instructions: – PiAware - dump1090 ADS-B integration with FlightAware - FlightAware

I have disabled automatic startup of dump1090-fa and piaware. I ust sytemctl to start them up so as to diagnose this issue. I start dump1090-fa, run rtl_test or rtl_eeprom, and get the usb claim error 6 or the wrong dongle is claimed by dump1090-fa.

What seems to be happening is that my dongle settings in piaware.conf are being ignored, sometimes!

So, any ideas on how to make dump1090-fa respect my settings in piaware.conf? I have tried both rtlsdr-device-index xxx and rtlsdr-device-index Dump1090.

Is there an rtlsdr-device-serial option that I have missed?

Dump1090 is the serial number I assigned to the dongle meant for Piaware. The other two dongles have custom serial numbers.

rtlsdr-device-index 0-based device index or serial number 0 SD card installs only: for receiver-type “rtlsdr”, configures which dongle to use if there is more than one connected

piaware-config does not help you as you are not using a piware sd-card.

You need to change the configuration of dump1090-fa:
/etc/default/dump1090-fa

and change the option
--device 0
to the correct serial number
dump1090-fa --help shows:
--device <index|serial> select device by index or serial number

THANK YOU!!!

It works. And it works every time. I cannot tell you how much time I have spent pondering on this because it would be embarrassing.

Note that I was not using piaware-config.txt but piaware.conf. No matter because neither was dependable. Apparently it only worked when I did some voodoo but not for the reasons I thought. Now it works every time. No voodoo required.

I nominate wiedehopf to be best person in the world on March 1st, 2019.

1 Like

Yeah it’s a dump1090-fa setting.
Those are only controlled by piaware-config when you have the piaware sd-card image.

If you use a normal Raspbian image and then install piaware, the setting will not have any effect.

Doesn’t matter where you configure piaware it will have zero effect.

Don’t be hard on yourself, you described the problem perfectly and also described how you set everything up.
The problem is that piaware is a name for an sd-card image and the image for the feeder program. That is just plain confusing.

What are you using the other 2 dongles for?

Just as an example, the Flightradar24 are using two very distinct names:

  • Pi24 for SD card image
  • fr24feed for the data feeder

Apart from good naming scheme, they have some bad aspects also

  • They use dump1090-mutability ver 1.14, which requires a Google API key, else a darkened map with water mark.

  • The dump1090-mutability v1.14 is blocked to start at boot by its init file. Instead fr24feed starts it, with config arguments passed by it, ignoring the config in the file /etc/init.d/dump1090-mutability

Editing the above file for gain and network options has no effect. All arguments required for dump1090 should be added in fr24feed’s config file /etc/fr24feed.ini by adding in it following line

procargs="--net --gain nn --lat xx.xxxx --lon yy.yyyy"

If you dont have --net, no data is made available at port 30005. (by default all data output to ports 30003 and 30005 are blocked). So effectively you cannot feed Flightaware even if you install Piaware package untill you add line procargs="--net" :frowning:

One dongle is for picking up local aviation chatter at our airport. That one was the one that started all the USB_Claim_Problems

The other is meant to grab images from NOAA and Russian Weather Satellites. That one is a work in progress. I also have a dAISy HAT for picking up AIS signals, (boat traffic). That one is working.

The goal is to run all four services on one Pi. Once perfected, I hope to offer a Raspberry Pi class at our local library. This SDR radio stuff is new to me. I am OK with Linux but after this project, I expect to be better. I already am as I have learned a lot tracking down the dreaded USB Claim Error #6. Of course nothing I learned fixed the problem but it did help me in the end to ask a good question.

I have learned how to build antennas and a bit about signal theory. Had fun doing it too. Never would have except for the project required I learn something. I think that the some of the kids in our town would enjoy these kinds of Raspberry projects and would learn something too!

@ Piaware. This USB_Claim_Error has terrorized the internet for a long time. Google for proof. Anybody who tries to run a second dongle is going to run up against this. documentation should be updated so as to explain where one modifies the dump1090-fa rtl device info.

Could this be related to the need to blacklist the dongle?

Nope. Well yeah it could have been but I have blacklisted every dongle in the know universal. Nothing worked.

The solution was simple. The setting in the dump1090-fa configure for selecting the device was the issue. It was set to grab index = 0 dongle. Sometimes ) was the right dongle. Other times not. And other times something else already had dongle 0. Change to index = MyCustomSerialNumber, boom!

Used rtl_eeprom to set serial numbers of my dongles to Space, Chatter, and Dump1090.

Thanks for input.

1 Like