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?
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)
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)
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:
After compiling, I used my customized version to dump the contents of the problematic stick:
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!
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)
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.
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)
