开云体育

Hi Robin

The short answer is that (the current) linux already has the driver provided within the kernel, so nothing extra needs to be done. Windows on the other hand requires a manual install. For Icom's that is an exe download from their site.

I don't know the 7100 in detail, but the 9100 & 7300 have an external USB hub, UART and PCM device. If you look at the kernel log (sudo dmesg) before and after hot plugging the rig you will see these module load. The serial/UART looks something like "usb 1-1.3.1: cp210x converter now attached to ttyUSB0" and the ALSA base sound device "Burr-Brown from TI USB Audio CODEC"

If you don't see this detail something strange is going on.

Cheers Bob VK2YQA

--
Don Poaps
VA7DGP: data
VA7QU:? ?voice

No sudo needed, just open a terminal window, and enter...

dmesg -WH? (On Debian/Ubuntu/Mint based systems at least.)

Nothing will happen, until you connect, or disconnect something, then it'll show you what it is, or was etc.

Chances are the ICOM's use something generic for the USB/Serial part of things, that does not have any unique identifier (other than the I/O "path" to it) that you could use to create a udev rule, so you could have "reliable" /dev/ttyIC9100main and /dev/ttyIC9100sub virtual serial devices each and every time.

So long as, the device hardware path to it, is fixed.

I've just given up with such Prolific, SiLab and other generic chipset based things, as on many modern PC's (some laptops especially) even the "hardware numerical path" to external devices varies each time the system is powered up, or in one case when warm rebooted!? Probably due to the use of nested internal USB Hubs, inside the PC, and the way they are enumerated too.

At least FTDI based devices (the "Genuine" ones at least) all have a unique serial number that you can use for UDEV rules.

Resulting in (for example) a nice 100% reliable each and every time /dev/ttyICR9000 device to tell the software about.

Regardless of what host computer USB orifice I plug it's lead into, be that direct on the back of the PC, or via any combination of hubs.

The rule (in /lib/udev/rulesd/99shack.rules) for that device is:-

#IC-R900
SUBSYSTEM=="tty", ATTRS{serial}=="A10NDGR5", SYMLINK+="ttyICR9K"

That serial number "A10NDGR5" is unique to that particular USB<>C-IV lead, in fact, that particular embedded USB/Serial bridge chip used in the lead assembly!

I also have, among others...

#FT-736r
SUBSYSTEM=="tty", ATTRS{serial}=="A50285BI", SYMLINK+="ttyFT736"
(Based on the embedded serial number of a FTDI based USB to TTL serial adapter board, commonly used for working with Arduino's that don't have their own USB port.)

#TM-V71
SUBSYSTEM=="tty", ATTRS{serial}=="AK06ML2R", SYMLINK+="ttyTMV71"
(Based on the embedded serial number of a commercial FTDI based cable)

All result in the same /dev/tty device each and every time, so no confusion, even after a RFI event, they come back just the same after the system re-enumerates things.

(The system default assigned /dev/ttyUSB0 or 1 etc, are still present.? If you have application software that can't, or wont accept custom port names, you can often launch such programs from a script, in which you can "readlink /dev/ttyFT736" for example, and put the resulting normal "ttyUSB4" assignment for example, into a system variable from where you can hopefully specify that on the command line that launches the program, or feed it in some other way.? I've even grep'd and replaced a config file "port value" before invoking the program in the past.)

FTDI might be more expensive than others, but you get what you pay for, and an easier life too!
In the UK, "Technofix.uk" sell such cables for sensible costs, and they always work.? (Even on windows, the update service will find the correct driver, if not already installed.)

Google "writing linux udev rules" for some background, but be aware the learning curve is steep at first, but stick with it, they really do work very well.? SO LONG AS there is something "unique" about each such USB device.

Sadly, most equipment makers take the cheap generic route.?? Even though many of those such devices can also be connected to an external EEROM, where such unique info can be stored, and will override the chip's own default when a host system enumerates it on connection / re-connection.

Many common audio codec chips (Cmedia for example) can also do that, but again most device makers don't want the expense of extra parts and the process of creating and assigning such unique ID codes.

It could be possible to "dead bug" such an additional chip, if the codec/bridge chip's needed pins are not connected to anything else. And one has the eyes of a hawk plus microsurgery soldering tools!

One day, all this might be easy, but I'm not holding my breath!

Seasons Greetings...

Dave G0WBX.

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

开云体育

Hi Tim.

But, does the "Serialization" information set by Icom, appear in the strings returned to the system when they are enumerated on connection?

dmesg -WH should show it on finding the device, if it does.? eg:-? For a FTDI based device ...

dave@DellXPS:~$ dmesg -WH
[Dec31 10:45] usb 3-2.2: new full-speed USB device number 78 using xhci_hcd
[  +0.118563] usb 3-2.2: New USB device found, idVendor=0403, idProduct=6001, bcdDevice= 6.00
[  +0.000021] usb 3-2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  +0.000007] usb 3-2.2: Product: FT232R USB UART
[  +0.000005] usb 3-2.2: Manufacturer: FTDI
[  +0.000005] usb 3-2.2: SerialNumber: AK06ML2R
[  +0.007436] ftdi_sio 3-2.2:1.0: FTDI USB Serial Device converter detected
[  +0.000066] usb 3-2.2: Detected FT232R
[  +0.002631] usb 3-2.2: FTDI USB Serial Device converter now attached to ttyUSB5

(My emphasis.)


What does that show for your Icom when it is connected?


The above will NOT show any udev created devices, but:-

dave@DellXPS:~$ ls /dev/tty*
/dev/tty    /dev/tty16  /dev/tty24  /dev/tty32  /dev/tty40  /dev/tty49  /dev/tty57  /dev/tty8      /dev/ttyS3
/dev/tty0   /dev/tty17  /dev/tty25  /dev/tty33  /dev/tty41  /dev/tty5   /dev/tty58  /dev/tty9      /dev/ttyTMV71
/dev/tty1   /dev/tty18  /dev/tty26  /dev/tty34  /dev/tty42  /dev/tty50  /dev/tty59  /dev/ttyACM0   /dev/ttyUSB0
/dev/tty10  /dev/tty19  /dev/tty27  /dev/tty35  /dev/tty43  /dev/tty51  /dev/tty6   /dev/ttyACM1   /dev/ttyUSB1
/dev/tty11  /dev/tty2   /dev/tty28  /dev/tty36  /dev/tty44  /dev/tty52  /dev/tty60  /dev/ttyACM2   /dev/ttyUSB2
/dev/tty12  /dev/tty20  /dev/tty29  /dev/tty37  /dev/tty45  /dev/tty53  /dev/tty61  /dev/ttyICR9K  /dev/ttyUSB3
/dev/tty13  /dev/tty21  /dev/tty3   /dev/tty38  /dev/tty46  /dev/tty54  /dev/tty62  /dev/ttyS0     /dev/ttyUSB4
/dev/tty14  /dev/tty22  /dev/tty30  /dev/tty39  /dev/tty47  /dev/tty55  /dev/tty63  /dev/ttyS1     /dev/ttyUSB5
/dev/tty15  /dev/tty23  /dev/tty31  /dev/tty4   /dev/tty48  /dev/tty56  /dev/tty7   /dev/ttyS2

Does.? The two in Blue in this case.

As a check...

dave@DellXPS:~$ readlink /dev/ttyTMV71 /dev/ttyICR9K
ttyUSB5
ttyUSB4

Reveals who's what, etc...?? Should some old-school software need the default format.


Flrig these days shows everything the system presents, when you go to configure a rig.
(Assuming the thing is connected before starting Flrig.? Else, use the "Update" button to the left of the port field in Config/Setup/Tranceiver.

Older versions will also accept things like /dev/ttyICR9K in the appropriate field of the radio specific .prefs file Flrig uses.
But, if something changes the setting in the settings UI, that will be reset.

Using a bash script to copy a fixed version of the .prefs file to the .flrig folder, before launching Flrig, can nail it down, so that if anyone does fiddle, exiting and restarting (via the script) will restore normal service.? (Possibly of use under EMCOM conditions, with less skilled operators perhaps.)


73.
Dave G0WBX.

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

Thanks for all your responses to this question. You've opened a door with the various tips.


73, Robin KK7MSN

Well done Tim.

73 and happy new year.

Dave G0WBX.

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

开云体育

Hi Lonney.

Yes, those links work too, but the problem is, not that one or other style of link works or not, is that the default links/symlinks created by the OS, can change whenever it is kicked into re-enumerating USB devices at Boot, or restart time, or whenever the USB subsystem changes, as devices are added or removed.

That is in effect what happens when RF gets into a USB lead and messes with things...? They often get assigned in a different order than they did the first time!?? So, even the serial/by-id values can change, and ruin your day.

It causes real chaos, in cases (such as here) where I have multiple serial devices (not just radio's, but a GPSDO and other USB/Serial connected devices in the shack.? (As well as two or three USB audio devices!)

If you just have one such USB serial device, and one only external sound I/O, you likely will never experience the chaos that can happen.


Using udev rules, based on some unique feature of a device (typically a serial number, if that exists, or some other unique info, take care, the VID/PID values are generally not unique) NOT based on what the OS did, will always work the same each and every time.

Consider the not uncommon event of RF in the shack, that can cause a USB device to "drop out", the OS then "forgets" it, but when the RF has gone, the device "re appears" and everything is re-enumerated.?? THAT is when the mayhem can happen, not just with Linux, but Windows and other OS's that support USB devices in the same way, as is the standard way these days..

Using:-
udevadm info -a -n /dev/ttyUSBn

(where n is 0, 1, 2 etc) does list a lot of good info, but in the case of my two main PC's (the currently sick HP and this Dell) that internally have at least two "layers" of dynamic hardware such as PCI and USB subsystems, each boot usually results in a different I/O "path" to an externally connected device, even if is physically connected to the same physical USB "port".

The Dell XPS laptop I'm using at the moment, has two internal PCI bus's, each of them has a collection of internal USB Hub's, that as well as supporting the external devices, also support the keyboad, mouse pad, internal sound system, some aspects of the video system (default LCD screen, and an external HDMI device if connected (and that too it seems can "carry" USB traffic between PC and "Monitor") as well a several other internal sensor type devices, battery state monitoring and temperature sensors etc.

Quite how exactly the combination of it's BIOS, UEFI and OS manage to bring all that up into a usable and generally stable system is quite amazing!

"Udev rules" when configured well, work reliably and consistently in every case, but ONLY where there is something unique about any particular "device" that is not assigned dynamically on a cold or warm start...

The obvious value to look at would be the "serial number", as that ideally (I know...)? "Could" be unique amongst a particular class of devices at least.? But the device makers are somewhat lax in that respect.? It seems Icom, and possibly other Ham rig makers may do the right thing, as does FTDI, but 99.999% of the low cost genuine (as well as the fake/counterfeit) devices do not.

Some, have the ability to use custom information held in an external ROM of some sort, using a microwire bus to communicate with it.? If present, the custom information in it will be provided to the OS when enumerated, instead of the hard coded info in the peripheral chip itself.

See the CM108 sound codec data sheet for example...


Scroll down to the "Reference Application Schematic"? (Page 27 of 28 in the file.)
U3 a 93C46 is a small EEPROM for such needs, connected to pins 2, 3, 4 and 5.

(Page 14 has the format of the needed data for that external EEPROM too.)

Therefore, it could be possible (eyesight and tooling permitting) to retrofit such an EEPROM "dead bug" on top of the codec chip perhaps.

(There is ISTR one Ham USB Audio interface device, that has lands for such a chip provided on the underside of the board, but I forget which one.)? Of course, you first need to program the EEPROM with the correct data in the correct format.

The combination of a "Genuine" FTDI USB serial bridge device (that already has a unique on the planet serial number) and with a CM108 + (programmed) EEPROM would with an example udev rule, solve the issue once and for all, perhaps.

But why would mass market developers do that, Ham Radio is a tiny & trivial marked compared to the general throw-away gadget market these days.

You pay your money, and take your choice.

73.

Dave G0WBX
(Who's eyesight is not good enough for such electronic microsurgery these days, even if I had the tooling to hand!)

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

Lonney, the issue is only a problem when one has multiple same make of USB<>Serial products showing the exact same information to the PC when enumerated.

The exception being FTDI based devices (and it seems later ICOM radios) as they have unique serial numbers that are convenient to use with udev rules, giving 100% predictable device names.

If you only have one USB<>Serial device, or if more than one, they have different chipsets (Prolific, Silicon Labs etc) you'll likely never experience the confusion of seemingly random /dev/TTYUSB* assignments!

The problem has got worse with the newer kernels too (from observation & experience) on the same fixed hardware on two PC's.? (Dell and HP.)

Imagine if you have a remote base with such issues, and it reboots for some reason...

"Have Fun"!? :-)

Dave G0WBX.

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

开云体育

Phil.

If your system reliably uses the same "device path" to reach the codec chips, then you can use that to steer things in the right direction with a couple of udev rules.

I'm (currently, but that may change...) using LMDE 6 as my OS, but that (on the same previous hardware) seems to create more mayhem by enumerating things differently each time it boots, or is awoken from a sleep or hibernation.

I now have the new FTDI based serial adapters, and that port assignment mayhem at least, has now been eliminated.

Pavucontrol (in conjunction with the new pipewire audio server) even with the helper file referenced in boot config file tweaks, absolutely will not allow the renaming audio devices, that worked solidly with LMDE 5 in the past (as previously, on the exact same hardware.)

From what I can gather (online information is still varied and sketchy about pipewire) it may not even be possible to rename them at all at present.

Someone tell me different if it is possible, with a link to a site describing all that is needed please.? Not just hints that it can be done with no specifics!? ;-)


At least building Fldigi/Flrig etc, works successfully as normal.


73 and happy new year.

Dave G0WBX.


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