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:
Dave, W1HKJ
John McCurdy, K7JHM