Write to /dev/hidraw* fails when using PTT(and PTT fails) with digirig lite (usb audio device) #559
Comments
livingstack
changed the title
|
This is not a defect report or enhancement request so it really belongs in the discussion forum. There are many who can answer routine questions. Having the questions and answers in the forum would help others with the same issue. |
|
If you can run as root but not another user, it is a permissions problem. The direwolf installation procedure should install /etc/udev/rules.d/99-direwolf-cmedia.rules which allows cmedia devices to be accessed by the audio group. During reboot, the permissions should be set like: Your account must be in the 'audio' group. Check by typing "id" command. 73, |
|
My account is in the "audio" permissions group already prior to posting this. braden@direwolf3:~$ id braden The only version of linux that it worked with sudo permissions was bootable usb Desktop Ubuntu linux 24.04 LTS. It still fails with every version of raspberry pi OS, and Ubuntu server 24.04 LTS for Raspberry pi. I have already used "chown" and "chmod" and "stat" to ensure the permissions are correct. stat /dev/hidraw3 It gives me no other feedback other than: "Audio input device 0 error code -19: No such device". Please provide more specific logging capabilities or error messages specific to what the exact issue is. |
|
Let's concentrate on the Raspberry Pi with Raspberry Pi OS first. You mentioned digirig lite. https://digirig.net/product/digirig-lite/ It's very simple with a CM108/CM119, PTT connected to GPIO3, like many others. What does the "cm108" utility report? What does "arecord -L" report |
|
CM108 command output: ** = Can use Audio Adapter GPIO for PTT. Notice that each USB Audio adapter is assigned a number and a name. These are not predictable so you could "Yes I have created the file "/etc/udev/rules.d/85-my-usb-audio.rules" it recommends with no change in results. arecord -L command output: arecord -l braden@direwolf3:~$ arecord -L I'm also using the command "PTT CM108" or "PTT /dev/hidraw3" interchangeably(one commented at a time) in my direwolf script for troubleshooting purposes. |
|
The cm108 utility told us: Use Simply use The corresponding hidraw device will be determined automatically. 73, |
|
Both have been adjusted with the following results: Dire Wolf version 1.7 Reading config file direwolf.conf |
|
Let's leave direwolf out of it and see if another application can record audio from the device. pi@rpi5:~ $ arecord -l pi@rpi5:~ $ arecord --device=plughw:2,0 zzz (( Run for a few seconds then press control C. )) ^CAborted by signal Interrupt... pi@rpi5:~ $ ls -l zzz |
|
I'm at lunch right now, so this was a good time for testing. Here are the results: braden@direwolf3: arecord -l |
|
I've been doing some more testing and research and have an update that may or may not prove useful. In summary I have tried with multiple PI's from version pi zero and pi 2 to version 4. Here is the error I get across all of them that we're familiar with: Write to /dev/hidraw3 failed, n=-1, errno=71 What I have also been doing simultaneously is monitoring journalctl -f in a separate window and these are the results I get when the digirig is plugged into a usb 2.0 port: 13:04:03 direwolf4 kernel: retire_capture_urb: 494 callbacks suppressed See the similar error message? Error -71? I know the cable isn't bad because this works on windows and with Ubuntu desktop. What I decided to test next was with ubuntu desktop on usb 3.0 ports vs usb 2.0 ports. It works like a charm on 3.0! I move it back to usb 2.0 and it fails next time I load it. The same behavior for every pi up until pi v4 (which has different behavior). The common thread? Every single pi until pi v4 ONLY has usb 2.0. When I plug it into 3.0 ports on the pi 4 it works. I did some deeper digging compared to what others have found. This is definitely a driver issue, and I suspect it's in the way that the software is leveraging usb 2.0 device drivers instead of usb 3.0 device drivers. Oddly enough when I plug the digirig lite into the usb 2.0 ports on the rpi4 it works, but I still get weird dmesg errors like this: Feb 03 06:37:14 direwolf4 kernel: usb 1-1.4-port4: cannot reset (err = -71) Again, the cable is not bad though as it works on Windows and still activates PTT, despite the error when in usb 2.0. The only difference is usb 3.0 does not give this error. So what can be done about this so that people can use the rpi3 and rpi zero instead having to use an rpi4 that is more power hungry and clunky than the zero? |
|
The Rpi4 uses a different USB controller than earlier board versions but the needed support is there in the kernel (at least in Raspberry Pi OS (Buster / Debian 10 or newer OS - kernels 4.19). Support for Ubuntu might be lower so I would start with the official OS to start with. That said, have you tried a different USB cable and make sure there aren't any hubs in the USB chain? Maybe the cable is marginal. Beyond that, you might want to start a support thread with the vendor ( https://digirig.net/contact/ ). I did search for "cannot reset (err = -71)" in their forums and didn't get any hits. |
|
I actually have two digirigs and have tested both cables with multiple radios, so I know the cable isn't bad. With that being said I was only testing ubuntu server to see if it had different libraries available than rpi os, and since your last message have switched back. I'll keep experimenting with other variables in the meantime. I think I'm also going to find/experiment with other usb audio adapters that are known to work with direwolf already. Do you have any suggestions on something relatively compact and affordable that others have had good success rates with? |
On both the latest version of Raspberry pi os, ubuntu server 24.04 (for rpi) and server 22.04(for rpi)
Direwolf is failing to write to any /dev/hidraw* (substitute * for device number)
I get the following errors on all flavors of rpi:
Audio input device 0 error code -19: No such device
Write to /dev/hidraw3 failed, n=-1, errno=32
ERROR: PTT for channel 0 has failed. See User Guide for troubleshooting tips.
Audio input device 0 error code -19: No such device
This is with both the latest version of direwolf AND 1.7 on rpi across all OS versions listed above.
Oddly enough it starts to key up the radio and then fails with the errors above and then exits direwolf.
My config looks like this:
ADEVICE plughw:2,0
CHANNEL 0
MYCALL K*******
MODEM 1200
PTT CM108 (I have also tried with /dev/hidraw* where * represents hid device output when using cm108 utility)
GPSD
AGWPORT 8000
KISSPORT 8001
Now here is the interesting part:
Direwolf successfully keys up the radio (without gps puck data, not sure how to incorporate this) on windows 10 and windows 11 with version 1.7
Additionally when booting up from a Ubuntu USB of 24.04 for OS demo and running direwolf I get the following errors:
could not open /dev/hidraw1 for write, errno=13
Type "ls -l /dev/hidraw1" and verify that it has audio group rw similar to this:
crw-rw---- 1 root audio 247, 0 Oct 6 19:24 /dev/hidraw1
rather than root-only access like this:
crw------- 1 root root 247, 0 Sep 24 09:40 /dev/hidraw1
ERROR: PTT for channel 0 has failed. See User Guide for troubleshooting tips.
But I have modified the permissions to look like this VERBATIM.
--------Now here is the most interesting part------:
If I run direwolf as sudo in the usb bootable ubuntu (even though I shouldn't), it keys up the radio just fine, everytime and the packets sound normal with out ANY of the above errors.
The text was updated successfully, but these errors were encountered: