CHIRP

Yep, Operation not permitted (EPERM) doesn't usually mean a permission issue (as in the filesystem permissions, which is EACCES). That error can be something else like "the driver for this device doesn't support this type of operation" or "the device is not in the proper mode right now". I'd compare the kernel versions between the two machines where one works and one doesn't, and also make sure that they're assigning the same driver/module to the ttyUSB0 device. Linux knows which module to use for a device based on the vendor:model information, which (a) can be changed on many of these USB devices for vendoring reasons and (b) is loaded from a list, which can be wrong, changed, or incorrect depending on that particular device. It's not uncommon to have vendored USB serial devices show up as, for example, an FTDI device because linux thinks that's what it needs, when in reality the chip is a Prolific one. Icom uses the same (or similar) vendor:model strings on their devices even when they use different chips and require you to use the actual driver they ship with the device, knowing that windows users can specifically choose a driver per device. That actually gets messed up when you reorder your devices, which is why they shouldn't do it, but alas.

That said, this really can't be a CHIRP issue - there's nothing CHIRP can do to cause the OS to return an EPERM, and that open mode that pyserial is doing is very basic, so nothing special or funky going on there.

Hi, Dan, Thanks for the reply. I may be starting to remember what I did now. I also don't think its a Chirp specific issue but I found the solution using some combination of Chirp/pyserial/linux google words, or maybe something totally different. I usually make a note to myself about things like this because I know I'll run across it again, but can't find my notes either :(

I ran the open() command originally mentioned in a python3 command window, and it seemed to work. At least I got what appears to be a valid FD back.

I'm starting to recall maybe it was a driver issue. The 2 computers that can and cannot access my radio both seem to be using the same driver, a char ch341-uart driver. BUT the one that CAN still open /dev/ttyUSB0 has been powered off for the last 2 weeks and is running linux Kernel 6.9.6 and the computer I tried a new install on that cannot access it is running 6.9.9. I can't easily check at the moment but am pretty sure the other computer that USED to be able to access my radio 2 weeks ago is now also using 6.9.9.

I'm happy to say I got it working. Rather than using Chirp Next-20240410 from snap, I installed chirp-20240706-py3-none-any.whl and it works :) Nice app.

Back when I ran the classic CHIRP snap build on Linux Mint, I always executed the command below on a new install to get access to the serial port.

First Time Installation Notes

To give chirp-snap access to your USB to serial adapter, open a terminal and run sudo snap connect chirp-snap:raw-usb

Reference: https://snapcraft.io/chirp-snap

YES that was it Jim. That was the command I used before and was searching for. Thanks very much :)