This is starting to become a recurring topic, but anyway…
Anyway, after a mishap with my udev rules, my RSP1a stopped to be recognized and accessible by Gqrx and other software (such as Sdrangel and sdrpp), mainly with the access denied error, and second on the OS log (using dmesg) the famous Maybe the USB cable is bad? error log message.
Changing the cable with other cables did not solved the issue and I was starting to think the RSP1a might had deliver his last breath. Anyway it would be strange if it was an hardware issue, so it might be the original udev rule that might be wrong…
SUBSYSTEM=="usb",ENV{DEVTYPE}=="usb_device",ATTRS{idVendor}=="1df7",ATTRS{idProduct}=="3000",MODE:="0666"Specifically for the RSP1a, the vendor ID is 1df7 and the product id is 3000, as it can be seen by running the lsusb command:
...
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 1df7:3000 SDRplay RSP1a
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
...So the device is recognized, but programs are unable to access it. Running, as the user root the command udevadm monitor I was seeing the RSP1a connecting and disconnecting continuously in a loop while the system log (dmesg -w) was printing out the “Maybe the USB cable is bad?” while the system tried to associate an USB port/device.
Anyway to keep things short of describing the debugging progress, running the following commands as the user root:
udevadm control --log-priority=debug
journalctl -fAllows us to see in real time what it was happening, and lo and behold among the messages of connecting and disconnecting loop one was among them:
mtp-probe: bus: 1, device: 2 was not an MTP deviceSo changing the original udev rule 66-mirics.rules located on /etc/udev/rules.d to
SUBSYSTEM=="usb",ENV{DEVTYPE}=="usb_device",ATTRS{idVendor}=="1df7", ATTRS{idProduct}=="3000", MODE="666", GROUP="plugdev", ENV{MTP_NO_PROBE}="1"adding the ENV{MTP_NO_PROBE}=”1″ stopped the loop and, the RSP1a started to work!
Anyway, that was not enough to solve all the problems, since that now, gqrx and other programs required to run as root. This was solved with two changes to the original rule: One to change the format of the MODE parameter and the other to add the USB device to the plugdev system group where my normal user is a member. With this all is working now fine with no issues whatsoever.
Anyway, we will need to reload the new rules after changing them with the following commands:
udevadm control --reload-rules && udevadm triggerAnd return back the udev logging level to the standard info level:
udevadm control --log-priority=infoFinal thoughts:
Copying udev rules from the internet might be relatively secure, but an important point must be checked: On blogs, just like this, sometimes the ” character does not translate to a real ” double comma character when copying and pasting to a local file. After saving the file with the copied rule one must check if those double comma characters are not an UTF character but a real double comma character. This may also apply to other characters.
od -c 66-mirics.rules
0000000 S U B S Y S T E M = = " u s b "
0000020 , E N V { D E V T Y P E } = = "
0000040 u s b _ d e v i c e " , A T T R
0000060 S { i d V e n d o r } = = " 1 d
0000100 f 7 " , A T T R S { i d P r o
0000120 d u c t } = = " 3 0 0 0 " , M
0000140 O D E = " 6 6 6 " , G R O U P
0000160 = " p l u g d e v " , E N V {
0000200 M T P _ N O _ P R O B E } = " 1
0000220 " \n
So before reloading the rules, make sure that the file has no UTF characters, and using a standard editor, like vi, delete and type again the character.
Primal Cortex's Weblog 