Re: [Hamlib-developer] Question...rigctl timed out on receive, cannot see data from 746PRO

[Dave B <g8k...@go...>]

Don't forget to also kill off the infamous "Modem Manager", that has 
caused stupidity in the past too.


If you have a FTDI based device that shows a serial number like this in 
dmesg....
(Even a fake one!)


[Apr 7 15:04] usb 1-1.6.5.2: new full-speed USB device number 15 using 
ehci-pci
[  +0.115074] usb 1-1.6.5.2: New USB device found, idVendor=0403, 
idProduct=6001, bcdDevice= 6.00
[  +0.000006] usb 1-1.6.5.2: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3
[  +0.000002] usb 1-1.6.5.2: Product: FT232R USB UART
[  +0.000002] usb 1-1.6.5.2: Manufacturer: FTDI
*[  +0.000001] usb 1-1.6.5.2: SerialNumber: AK06ML2R*
[  +0.002918] ftdi_sio 1-1.6.5.2:1.0: FTDI USB Serial Device converter 
detected
[  +0.000036] usb 1-1.6.5.2: Detected FT232RL
[  +0.001054] usb 1-1.6.5.2: FTDI USB Serial Device converter now 
attached to ttyUSB5

(The above, is seen by watching dmesg output, when connecting a FTDI 
equipped serial bridge device.)

It is fairly easy to use a udev rule based on the Serial Number, to 
assign it to a static'ly numbered /dev/ttyUSBx device (x is your choice) 
or even give it a name you'll remember /dev/ttyFTDIcable-a   or   
/dev/ttyIC746  (etc.)

Then it'll appear always with that designation in the device list, 
regardless of what /dev/ttyUSBx it gets assigned from the kernel (that 
will also be valid, but can change if something forces a re-enumeration.)

Hamlib will accept such names, as will a lot of other software (Flrig 
etc) just fine I've found.

Sadly, even genuine Prolific, CMedia or SiLabs chips usually do not have 
anything "unique" about them to do that with, but you can in a 
statically wired shack, use the "Path" to it, to give it a name. But if 
you change the physical port it's plugged into, or add/remove a hub, all 
bets are off!

Some other chips (serial and sound I/O) can use data in an attached 
eeprom, where you can put a unique ID into, that will be used in place 
of it's default details when it is enumerated.  Not a trivial thing to 
achieve though.

The above based on my own personal hands-on experience.

73.
     Dave G0WBX.
(Currently using LMDE 5, no brltty, but ModemManager is in there... Not 
causing issues at present.)



On 07/04/2023 13:29, Brian Morrison wrote:
> On Thu, 6 Apr 2023 17:34:08 -0400
> jeff millar<wa...@gm...>  wrote:
>
>> Some progress on connecting CI-V USB dongle to IC-746Pro remote port
>>
>>     - Tested FTDI CI-V adapter with another radio, IC-9700, same
>> problem,
>>        - unable to receive responses from radio
>>        - oscope show response from radio
>>        - So the problem is the USB converter or Linux
>>     - Tested with real FTDI, real Prolific 2303 and fake Prolific 2302
>> Ci-V converters, none work
>>     - Test with QinHeng CH341, success!
>>        - initially failed to create ttyUSB0
>>        - Internet search said remove braille device package "brltty",
>> due to udev rule issue
>>        - Now creates ttyUSB0
>>        - Works well with both 746PRO and IC-9700
>>
>> All these USB to CI-V serial adapters were purchased from Amazon and
>> had various Chinese company names.  I looked back through order
>> history and can't figure out which of the three ordered is the CH341.
>>
>> Any other ideas about why this should be so fragile?
> A lot of it is down to clones of the originals, the manufacturers
> modified the 'real' devices to try and make them incompatible with the
> older drivers and force the fakes out of the market. It led to much
> confusion and headache. I don't know how much of that got into other
> OSs but it certainly caused trouble for Windows users.
>
> brltty is also a pain, it's hanging around in systems where it will
> never be used presumably to make it easier for those that needed
> braille displays/keyboards.
>
> Glad you found a fix.
>

-- 
Created on and sent from a Unix like PC running and using free and open source software: