Bug #11252
openUpdated rpttool Issue
0%
Description
What is the behavior you are seeing?
While it trys to get the frequancy from the Radio in a ID-RP2000V Repeater, it returns "No frequency frame received". This was ran as root using sudo.
What is the behavior you were expecting?
It is expected to return the frequency of the Radio and move on to the menu where it can be set.
Can you reproduce the problem all the time?
Happens on both radios (Transmitter and Receiver).
What are the steps required to reproduce the problem?
-Plug in an ID-RPx000V reptear into a linux system
-Confirm port with ls /dev/ (should show up as ttyUSB0)
-Run rpttool (./rpttool /dev/ttyUSB0)
-Software says "Looking for a repeater..."
-Software says "Unable to read memory from device: No frequency frame received"
-Software ends
Is this specific to a certain radio model (driver) or something that you can reproduce with another radio?
I do not have another ID-RPx000V Repeater for testing. Unknown radio models within the unit.
Notes:
The Repeater is used and was pulled as the owner through there was a problem, however the new repeater they installed had the same problem so they don't think it was an issue with the repeater (at least that is the story I got). The repeater could still have an issue, but I have limited tools and ability to verify this. A cap on the radio has power, so I assume the radio is getting the 13.8 volts I am feeding the unit. I didn't see any LED's on the outside or inside to indicate power to the Radio. Plugging the USB in without power to the radio shows /dev/ttyUSB0 and lsusb shows "ID 0c26:0012 Prolific Technology Inc. ID-RP2000V SERVICE
Debug log is not supplied as this is not part of the normal application, it is an additional application that is ran by command line and has hooks into the Chirp library.
Updated by Dan Smith about 1 month ago
That's the same thing you get if you use a random unconnected serial port, so it's not getting anything from the repeater. Can you confirm that ttyUSB0 comes and goes when you plug in the repeater? The old script used to run icomsio.sh automatically. Can you try running that manually (as root) and see what /dev/icom points to?
Updated by Dan Smith about 1 month ago
This branch (not yet merged) will add a --debug flag:
https://github.com/kk7ds/chirp/pull/996
Which will provide some more information, but because you're just getting nothing I expect it's not actually communicating.
Updated by Dan Smith about 1 month ago
Sorry I missed the last paragraph when reading via email, I see now that ttyUSB0 reports as the repeater. The weird thing is that these did not (when I had one) use prolific chips, they used ftdi ones, but with a different vendor/model. That's what the icomsio.sh script does - it re-inserts the ftdi driver in a way that will detect these. So I guess I'm not sure why they're being detected as prolific chips, or whether or not some revision of them were implemented with different serial devices in some way. 0x0C26 is the vendor code for Icom (not prolific or ftdi) so I wonder if someone made a linux kernel change since then that just assumes any of those devices might be prolific serial (their radio cables often use that chip) or maybe Icom re-used a product id.
You might try unloading the prolific driver (not sure the name of the one that is loading for you) with modprobe -r and then run icomsio.sh which should make the ftdi driver load with the proper vendor/product id (or just do that part yourself).
Updated by Kyle Brown about 1 month ago
I do not see the Prolific driver when I do a lsmod. I did do sudo modeprobe -r pl2303 to try and remove it (from what I can find on Google Searches), but it still shows up when I plug the repeater in. I do see the ftdi in the lsmod command, but lsusb still shows the Prolific driver. The script does create the /dev/icom as a link, but it doesn't seem to change anything else.
I am running Ubuntu 22.04.4 LTS with Kernel 5.15.0-100-generic.
Updated by Dan Smith about 1 month ago
If you unplug and replug then udev will just load the driver it thinks it needs, so removing pl2303 and then doing any plug or unplug will undo that. You need to:
- Plug it in, verify ttyUSB0 and that it claims to be a prolific device
modprobe -r pl2303to remove the driver while it's plugged in- Run the script (or insert
ftdimanually) with the right vendor/model to load the driver while it's plugged in - Try
rpttool
If it works, and you move to the other device, you'll have to do the dance again. If that works and is the problem, I can try modifying the script to do the full dance above so it's less cumbersome.
Updated by Kyle Brown about 1 month ago
That is what I tried. I even added pl2303 to the blacklist and restarted. Doing lsusb still whos the Prolific, but dmesg shows something interesting.
usb 2-1.3: new full-speed USB device number 8 using ehci-pci
usb 2-1.3: New USB device found, idVendor=0c26, idProduct=0013, bcdDevice= 4.00
usb 2-1.3: New USB device strings:Mfr=1, Product=2, SerialNumber=3
usb 2-1.3: Product: ID-RP2000V SERVICE R
usb 2-1.3: Manufacture: ICOM
usb 2-1.3: SerialNumber: FTV7ZE7B
ftdi_sio 2-1.3:1.0: FTDI USB Serial Device converter detected
usb 2-1.3: Detected FT232BM
usb 2-1.3: FTDI USB Serial Device converter new attached to ttyUSB0
usb 2-1.3: new full-speed USB device number 8 using ehci-pci
usb 2-1.3: New USB device found, idVendor=0c26, idProduct=0012, bcdDevice= 4.00
usb 2-1.3: New USB device strings:Mfr=1, Product=2, SerialNumber=3
usb 2-1.3: Product: ID-RP2000V SERVICE T
usb 2-1.3: Manufacture: ICOM
usb 2-1.3: SerialNumber: FTMCCDY8
ftdi_sio 2-1.3:1.0: FTDI USB Serial Device converter detected
usb 2-1.3: Detected FT232BM
usb 2-1.3: FTDI USB Serial Device converter new attached to ttyUSB0
I tried running the rpttool on both /dev/icon and /dev/ttyUSB0. This was also done as root. It seems like it is using the ftdi and the fact I get serial numbers (and I have seen data from the radio when powering up) suggest the radios are good. The data I got in the terminal was symbols, do I am not sure what it was sending. I tried other baud rates (not all of them though), but didn't correct the issue.