Bug #11252
closedUpdated rpttool Issue
100%
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 2 months 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 2 months 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 2 months 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 2 months 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 2 months 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 2 months 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.
Updated by Conrad Lara 4 days ago
Using Commit e95140ff433b805ca16df04cba501b7332a9ec95 I am able to duplicate.
NOTE: The Prolific detour appears to be a red-herring. It appears VENDOR ID 0x0c26 was used by ICOM in the past, however it may also be assigned to Prolific. I'm not sure if ICOM just sub-licensed the vendor ID, if it was a random assignment, or if the the vendor ID perhaps belong to another organization that Prolific bought.
https://the-sz.com/products/usbid/index.php?v=0x0c26 (random USB ID database)
http://www.linux-usb.org/usb.ids (Linux Kernel USB ID List)
0c26 Prolific Technology Inc.
0018 USB-Serial Controller [Icom Inc. OPC-478UC]
002b Icom Inc. IC-R30
Even though lsusb reports it is a Prolific device the kernel continues to use the FTDI driver.
Here are debug dumps from a RP2000V T and R ports, along with a RP2D port. Like the original poster I don't have access to spare systems either and these are in unknown condition (I'm told the 2000 had a bad TX amp and the RP2D was in working condition)
cmlara@donald:~/chirp$ ./venv/bin/python --version Python 3.10.12
cmlara@donald:~/chirp$ sudo tools/icomsio.sh Device ID-RP2000V TX is /dev/ttyUSB0 -> /dev/icom cmlara@donald:~/chirp$ sudo ./venv/bin/python rpttool --debug /dev/ttyUSB0 Looking for a repeater... DEBUG:chirp.drivers.idrp:Sending magic wakeup DEBUG:chirp.drivers.idrp:Got: 000: fe fe 7f 01 19 29 25 01 .....)%. 008: 00 00 01 01 74 72 fd ....tr.. DEBUG:chirp.drivers.idrp:Sent 0 bytes, received 15 DEBUG:chirp.drivers.idrp:Got: 000: fe fe 7f 01 fb fd fe fe ........ 008: 7f 01 19 29 25 01 00 00 ...)%... 016: 01 01 74 72 fd fe fe 7f ..tr.... 024: 01 03 00 50 11 45 01 fd ...P.E.. 032: fe fe 7f 01 1a 04 00 00 ........ 040: fd fe fe 7f 01 1c 00 00 ........ 048: fd fe fe 7f 01 1a 93 00 ........ 056: 01 85 fd fe fe 7f 01 1a ........ 064: 93 01 00 94 fd fe fe 7f ........ 072: 01 1a 93 02 00 83 fd fe ........ 080: fe 7f 01 1a 93 03 01 29 .......) 088: fd fe fe 7f 01 1a 93 04 ........ 096: 01 fd fe fe 7f 01 1a 93 ........ 104: 05 01 66 fd fe fe 7f 01 ..f..... 112: 1a 93 06 00 65 fd ....e... DEBUG:chirp.drivers.idrp:Sent 0 bytes, received 118 DEBUG:chirp.drivers.idrp:Unhandled frame type 251 DEBUG:chirp.drivers.idrp:Unhandled frame type 25 DEBUG:chirp.drivers.idrp:Unhandled frame type 3 DEBUG:chirp.drivers.idrp:Unhandled frame type 26 DEBUG:chirp.drivers.idrp:Unhandled frame type 28 DEBUG:chirp.drivers.idrp:Unhandled frame type 26 DEBUG:chirp.drivers.idrp:Unhandled frame type 26 DEBUG:chirp.drivers.idrp:Unhandled frame type 26 DEBUG:chirp.drivers.idrp:Unhandled frame type 26 DEBUG:chirp.drivers.idrp:Unhandled frame type 26 DEBUG:chirp.drivers.idrp:Unhandled frame type 26 DEBUG:chirp.drivers.idrp:Unhandled frame type 26 Unable to read memory from device: No frequency frame received cmlara@donald:~/chirp$ lsusb Bus 001 Device 012: ID 0c26:0012 Prolific Technology Inc. ID-RP2000V SERVICE T
cmlara@donald:~/chirp$ sudo tools/icomsio.sh Device ID-RP2000V RX is /dev/ttyUSB0 -> /dev/icom cmlara@donald:~/chirp$ sudo ./venv/bin/python rpttool --debug /dev/ttyUSB0 Looking for a repeater... DEBUG:chirp.drivers.idrp:Sending magic wakeup DEBUG:chirp.drivers.idrp:Got: 000: fe fe 7f 01 19 29 25 01 .....)%. 008: 00 00 01 01 74 72 fd ....tr.. DEBUG:chirp.drivers.idrp:Sent 0 bytes, received 15 DEBUG:chirp.drivers.idrp:Got: 000: fe fe 7f 01 fb fd fe fe ........ 008: 7f 01 19 29 25 01 00 00 ...)%... 016: 01 01 74 72 fd fe fe 7f ..tr.... 024: 01 03 00 50 51 44 01 fd ...PQD.. 032: fe fe 7f 01 1a 04 00 00 ........ 040: fd fe fe 7f 01 1c 00 00 ........ 048: fd fe fe 7f 01 1a 93 00 ........ 056: 01 86 fd fe fe 7f 01 1a ........ 064: 93 01 00 94 fd fe fe 7f ........ 072: 01 1a 93 02 00 59 fd fe .....Y.. 080: fe 7f 01 1a 93 03 00 00 ........ 088: fd fe fe 7f 01 1a 93 04 ........ 096: 01 fd fe fe 7f 01 1a 93 ........ 104: 05 01 15 fd fe fe 7f 01 ........ 112: 1a 93 06 01 15 fd ........ DEBUG:chirp.drivers.idrp:Sent 0 bytes, received 118 DEBUG:chirp.drivers.idrp:Unhandled frame type 251 DEBUG:chirp.drivers.idrp:Unhandled frame type 25 DEBUG:chirp.drivers.idrp:Unhandled frame type 3 DEBUG:chirp.drivers.idrp:Unhandled frame type 26 DEBUG:chirp.drivers.idrp:Unhandled frame type 28 DEBUG:chirp.drivers.idrp:Unhandled frame type 26 DEBUG:chirp.drivers.idrp:Unhandled frame type 26 DEBUG:chirp.drivers.idrp:Unhandled frame type 26 DEBUG:chirp.drivers.idrp:Unhandled frame type 26 DEBUG:chirp.drivers.idrp:Unhandled frame type 26 DEBUG:chirp.drivers.idrp:Unhandled frame type 26 DEBUG:chirp.drivers.idrp:Unhandled frame type 26 Unable to read memory from device: No frequency frame received cmlara@donald:~/chirp$ lsusb Bus 001 Device 013: ID 0c26:0013 Prolific Technology Inc. ID-RP2000V SERVICE R
cmlara@donald:~/chirp$ sudo tools/icomsio.sh Device ID-RP2D is /dev/ttyUSB0 -> /dev/icom cmlara@donald:~/chirp$ sudo ./venv/bin/python rpttool --debug /dev/icom Looking for a repeater... DEBUG:chirp.drivers.idrp:Sending magic wakeup DEBUG:chirp.drivers.idrp:Got: 000: fe fe 7f 01 19 27 31 01 .....'1. 008: 00 00 01 01 74 56 fd ....tV.. DEBUG:chirp.drivers.idrp:Sent 0 bytes, received 15 DEBUG:chirp.drivers.idrp:Got: 000: fe fe 7f 01 fb fd fe fe ........ 008: 7f 01 19 27 31 01 00 00 ...'1... 016: 01 01 74 56 fd fe fe 7f ..tV.... 024: 01 03 00 00 50 99 12 fd ....P... 032: fe fe 7f 01 04 d1 01 fd ........ 040: fe fe 7f 01 0c 00 00 00 ........ 048: fd fe fe 7f 01 0f 10 fd ........ 056: fe fe 7f 01 10 04 fd fe ........ 064: fe 7f 01 16 4a 00 00 fd ....J... 072: fe fe 7f 01 14 0a 02 55 .......U 080: fd fe fe 7f 01 1a 04 00 ........ 088: 00 fd fe fe 7f 01 1a 04 ........ 096: 01 00 00 fd fe fe 7f 01 ........ 104: 1a 05 04 00 fd fe fe 7f ........ 112: 01 1c 00 00 fd ........ DEBUG:chirp.drivers.idrp:Sent 0 bytes, received 117 DEBUG:chirp.drivers.idrp:Unhandled frame type 251 DEBUG:chirp.drivers.idrp:Unhandled frame type 25 DEBUG:chirp.drivers.idrp:Unhandled frame type 3 DEBUG:chirp.drivers.idrp:Unhandled frame type 4 DEBUG:chirp.drivers.idrp:Unhandled frame type 12 DEBUG:chirp.drivers.idrp:Unhandled frame type 15 DEBUG:chirp.drivers.idrp:Unhandled frame type 16 DEBUG:chirp.drivers.idrp:Unhandled frame type 22 DEBUG:chirp.drivers.idrp:Unhandled frame type 20 DEBUG:chirp.drivers.idrp:Unhandled frame type 26 DEBUG:chirp.drivers.idrp:Unhandled frame type 26 DEBUG:chirp.drivers.idrp:Unhandled frame type 26 DEBUG:chirp.drivers.idrp:Unhandled frame type 28 Unable to read memory from device: No frequency frame received
Updated by Dan Smith 4 days ago
NOTE: The Prolific detour appears to be a red-herring. It appears VENDOR ID 0x0c26 was used by ICOM in the past, however it may also be assigned to Prolific. I'm not sure if ICOM just sub-licensed the vendor ID, if it was a random assignment, or if the the vendor ID perhaps belong to another organization that Prolific bought.
Yeah, this is what I was trying to explain before. I think what happened is that Icom uses the same vendor/model for many of their "usb serial devices" even though some are prolific and some are ftdi. The linux kernel has a list of things it thinks it should load the prolific driver for, which includes that vendor/model because there are some out there that advertise it, but need a prolific driver.
Here are debug dumps from a RP2000V T and R ports, along with a RP2D port. Like the original poster I don't have access to spare systems either and these are in unknown condition (I'm told the 2000 had a bad TX amp and the RP2D was in working condition)
Thanks, this looks a lot more active, so something to actually chase. I'll have a look at them and let you know.
--Dan
Updated by Conrad Lara 3 days ago
Opened draft MR 1031 with WIP so far. Have not figured out bcd_encode yet.
Looked at the code a bit with the debugger.
Realized Frame type 3 is what we are looking for.
DEBUG:chirp.drivers.idrp:Unhandled frame type 3
Each position in the binary sequence returned from idrp::send() is an integer.
int(3) !== b'\x03'
Easy fix, look for an integer 3.
The ord calls are now out of place as its not a string its direct integer so we can remove them.
Fix those up and get:
KK7DS ID-RP* Frequency Tool Current Setting: 145.115000 -------------------------------- 1. Set repeater frequency 2. Re-read current frequency 3. Quit --------------------------------
Great! Progress!
Ok lets try and set a frequency....
TypeError('set_freq() takes 0 positional arguments but 1 was given')
Ok no problem, add dev back into rpttool set_freq() and its subsequent call to open_device().....
New frequency [145.115000]:
Great! now we are asked to set the freq!...
145.125000 Failed to set frequency to 145.125000: unsupported operand type(s) for <<: 'float' and 'int'
And now we have hit problems in util::bcd_encode()...
Updated by Anonymous 1 day ago
- Status changed from New to Closed
- % Done changed from 0 to 100
Applied in changeset github|3fed8b4a8db46af4e4e23e72f63663361639dd75.