With an ICOM IC-7300 and IC-9700 on the same computer you will definitely run into the issue to be able to distinguish the device names for the serial devices. Now that I added an IC-705 there is two more serial devices that are needed for PTT and CAT control. In contrast to the 7300 / 9700 the serial devices of the IC-705 appear as cdc_acm driver interfaces named /dev/ttyACMx instead. The 7300 / 9700 use the cp210x driver and are using /dev/ttyUSBx device names. So the rules could obviously not be used for the 705. So I had an experiment to develop new rules to achieve the goal of having fixed named symlinks for the serial ports of the IC-705.
IC-7300/IC-9700
For the sake of completeness I list the rules for IC-7300 and IC-9700 here. The rules are simply added by using a file /etc/udev/rules.d/65-hamradio.rules and storing them within that file. The content is:
# IC-9700 Serial Devices
ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60" , ATTRS{serial}=="IC-9700 12345679 A", SYMLINK+="ic-9700a"
ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60" , ATTRS{serial}=="IC-9700 12345679 B", SYMLINK+="ic-9700b"
# IC-7300 Serial Device
ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60" , ATTRS{serial}=="IC-7300 12345679", SYMLINK+="ic-7300"As you can see there are two rules for the IC-9700 as it has two serial interfaces. Luckily those can be distiguished by their description in the serial attribute. It contains an A for the first and
a B for the second port. In my case I use this property to generate two symlinks named /dev/ic-9700a and /dev/ic-9700b.
The rule for the IC-7300 is even simpler because the TRX has only one serial port. But in order to not hassle with different device numbers depending on when and where the device is plugged I also use a symlink /dev/ic-7300 for the serial device. This way all applications just use the symlink name and I do not need to take care about whether it is /dev/ttyUSB1 or /dev/ttyUSB5 in fact.
IC-705
Now it comnes to the IC-705 and it turns out that things are a bit more complicated here. The 705 also has two serial interfaces but in this case Linux uses the cdc_acm driver and thus generates devices names /dev/ttyACMx. But there is more: These devices do neither have a serial number in a device string nor an appendix showing whether it is the first or the second interface. Banging my head around this I found an attribute that enables to distinguish. There is an udev property named bInterfaceNumber which in my case had the value 00 for the first interface (/dev/ttyACM1 if no other ACM interface is present) and 02 for the second interface.
But it was not that easy to use this property because it belongs to the parent udev device and not directly to the ttyACMx device. The way out here is to combine two attributes of the parent devices. First udev looks if the property product is “IC-705” and if so stores that into an environment variable. We need to do this because otherwise udev would also handle other devices using the cdc_acm driver and create such symlinks. But we only want it to do that for the IC-705. So udev stores the product property and executes the following two rules only for the IC-705. The udev rules are:
KERNEL=="ttyACM[0-9]*", SUBSYSTEM=="tty", ATTRS{product}=="IC-705", ENV{PROD}="IC-705"
ENV{PROD}=="IC-705", SUBSYSTEMS=="usb", ATTRS{bInterfaceNumber}=="00", SYMLINK+="ic-705a"
ENV{PROD}=="IC-705", SUBSYSTEMS=="usb", ATTRS{bInterfaceNumber}=="02", SYMLINK+="ic-705b"This way the system creates two symlinks named /dev/ic-705a and /dev/ic-705b for the two ports. These names can for example be used in WSJT-X to configure CAT and PTT control as shown in the following screenshot.
