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:
