¿ªÔÆÌåÓý
Have fun, indeed.
The same is true for USB Audio Codecs. Although my two Icom radios have serial numbers implanted in the USB Serial chips, their audio codecs are indistinguishable from USB point of view. On Linux I can configure the likes of wsjt-x to connect to what I think
is the correct audio. If ever I need to reboot then the audio codecs may be named the same or they may not. It depends on the combination of radios powered on when I reboot and then the order I power them on.
It should be possible to analyse then USB connections and identify which audio codec and serial chip are on the same USB hub and keep them associated in some way, but so far it's been easier to suck it and see. If I press the tune button on wsjt-x and the target
radio generates RF then the audio is connected correctly: if not, then swap the audio connections around.
73 and HNY 2025.
Phil GM3ZZA
From: [email protected] <[email protected]> on behalf of Dave, G?WBX via groups.io <g8kbvdave@...>
Sent: 03 January 2025 9:26 AM To: [email protected] <[email protected]> Subject: Re: [linuxham] Icom IC-7100 USB Driver ?
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: |