FlightAware Discussions

Bricked Pro Stick just from setting serial numbers?

FlightAware ADS-B Flight Tracking
#1

I wanted to add an orange 978 dongle to my RasPi setup, and serialized my blue Pro Stick Plus as 00001090 and the orange Pro Stick as 00000978 as per the instructions found in various threads. However, after rebooting the Pi, neither one was detected. I even tried using a different Pi, and rtl_test comes back with “No supported devices found.” However, dmesg shows the device:

[ 1610.715247] usb 1-1.1.2: new high-speed USB device number 7 using dwc_otg
[ 1610.856981] usb 1-1.1.2: New USB device found, idVendor=41a0, idProduct=28a0, bcdDevice= 1.00
[ 1610.857001] usb 1-1.1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1610.857015] usb 1-1.1.2: Product: RTL2832U
[ 1610.857028] usb 1-1.1.2: Manufacturer: Realtek
[ 1610.857041] usb 1-1.1.2: SerialNumber: 00001090

Did I brick both my dongles just by trying to set separate serial numbers?

#2

Try with only one connected, make sure you completely power cycle it so it all reads correctly.

Then

sudo rtl_test

If it says claim error then you have something else using it.
Or you’re using a really old Raspbian …

#3

Completely power cycled, only the blue dongle connected:

pi@adsb:~ $ sudo rtl_test
No supported devices found.
#4

I think you can try connecting in Windows and maybe there resetting the serial number.
Not sure.

Or see if the utility to write the serial number will find it.
I haven’t dealt with this issue.

@abcd567 i remember you dealing with something like this at some point?

#5

Those vendor/product IDs don’t look right (and librtlsdr finds the dongle by those IDs, so if they’re wrong, it won’t find the dongle). They are read from the EEPROM. Check your rtl_eeprom settings.

(You will probably have difficulty getting rtl_eeprom to talk to the dongle now, since it also won’t recognize it… You may need to recompile librtlsdr with those wrong IDs to make it work)

#6

 

Please see these two posts:

 

 

#7

I did a little more testing, and it appears that my orange dongle is still able to be found by rtl_test and rtl_eeprom. So it’s just the blue dongle that is misbehaving, I think. I did find abcd567’s posts on using “rtl1090.exe /eeprom” on Windows, but the dongle wasn’t recognized by rtl1090 there either.

@obj thanks for the tip on the VID/PID being used to identify. Do you know what they should be for a Pro Stick Plus v1.0? (sticker on the side indicates Mar. 2017 manufacture)

#8

The default values are (IIRC) VID=0x0BDA, PID=0x2832

Full list of values that librtlsdr recognizes

1 Like
#9

Thanks for the tip! I could have just given up and tossed the dongle, but I decided to muscle through trying to fix it instead. I did buy a second blue dongle to use in the meantime and successfully changed the serial number on it to ‘00001090’ with no ill effects. I used rtl_eeprom to get an eeprom dump of the contents to compare to the messed up one:

gooddump

I then followed Rtl-sdr - rtl-sdr - Open Source Mobile Communications to get the current rtl-sdr source, and inserted the VID/PID being reported by my misbehaving unit into librtlsdr.c:

lib

After compiling, I used my customized version to dump the contents of the problematic stick:

baddump

Thankfully, it looks like only the VID/PID got corrupted, other than those 3 bytes further down getting switched from 0xff to 0xa0. I simply used the ‘-w’ option to write the known good .bin file to the problem stick. After writing, I plugged it into my ADSB RasPi, and all is back to normal!

Thanks @obj !

4 Likes
#10

Good that you got it working again!

I’ve seen similar failures before (rarely) and I’m not sure what triggers it. It seems like a strange failure mode; I wonder if it is something like noise on the I2C bus at just the wrong time during the EEPROM write command (error-checking in I2C is very limited)

#11

Yeah, after I was successful, I found that this issue is rare, but not unheard of: KA7OEI's blog: Un-Bricking an RTL-SDR Dongle after an EEPROM write

It would be nice if there was a utility that was able to accept any VID/PID (instead of having to custom compile) to rewrite the EEPROM for these rare cases.

#12

It should be possible to write something small using libusb directly (or e.g. a python script using pyusb). It’s somewhere on my todo list (though that is the List of Doom at the moment, so don’t hold your breath)

3 Likes