I haven't used the udev rules to give specific device file names, but
that looks slick.
The /dev/serial/by-id/whatevertheidis method I learned about a number
of years ago. I was surprised I hadn't learned about it sooner.
Definitely a nice method. I have thought about using that and
something like ln -s /dev/serial/by-id/longname $HOME/.dev/keyer to
map from device ID to application name. (Kindof like the example
earlier in the thread with udev rules.)
Windows is a tougher nut to crack. However, there is some hope. USB
CDC (USB to serial) devices that have uniqe VID:PID and/or unique
serial numbers will show up, CROSS PLATFORM, with python -m
serial.tools.list_ports --verbose. (3rd party python library
pyserial. Bundled with debian via python3-serial package.) These
days, I write my python software to autodetect using VID:PID and/or
unique serial for USB CDC devices, so I'm no longer fooling around
with the serial port enumeration problem. Sometimes I'll supplement
this with a map if I have several devices of the same kind hooked up
at once attached to different things. Then specifying the thing, the
map yields the USB serial number, and the serial library is used to
find the device file to open. Works on unix or windows. In theory
should be able to do in C applications as well.
It would be easy to write a python program to check for configuration
changes or to update a $HOME/.dev/whatever link. Ping me off list if
any interest in such.
+1 for avoiding avoidable problems. +1 for having a computer setup
that can be setup before a contest, validated before a contest, and
doesn't change during a contest.
Good luck! Let us know if you don't get the problem squared away.
Drew
n7da
On Wed, Oct 16, 2024 at 8:56 PM Christoph Berg <c...@df7cb.de> wrote:
>
> Re: K1VP
> > I have used this technique with great success, but I have also used UDEV
> > rules with great success as well. I usually have two USB to serial
> > converters active at all times so keeping them straight is essential.
> > Using the assigned names was a best an exercise in frustration until I
> > wrote UDEV rules or used the id method.
>
> For an example how that looks like:
>
> /etc/udev/rules.d/shack.rules:
>
> # 10c4:ea60 Silicon Labs CP210x UART Bridge (IC-7610)
> SUBSYSTEM=="tty", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60",
> ATTRS{serial}=="IC-7610 * A", SYMLINK+="ic7610",
> ENV{SYSTEMD_USER_WANTS}+="ic7610.service"
> SUBSYSTEM=="tty", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60",
> ATTRS{serial}=="IC-7610 * B", SYMLINK+="ic7610b",
> ENV{SYSTEMD_USER_WANTS}+="ic7610.service"
>
> (More in https://github.com/df7cb/df7cb-shack/blob/master/udev/shack.rules)
>
> That creates symlinks when the TRX is connected:
>
> lrwxrwxrwx 1 root root 7 16. Okt 20:49 /dev/ic7610 -> ttyUSB0
> lrwxrwxrwx 1 root root 7 16. Okt 20:49 /dev/ic7610b -> ttyUSB1
>
> It also automatically starts a rigctld if you have the matching
>
> ~/.config/systemd/user/ic7610.service file:
>
> [Unit]
> Description=TCP radio control daemon (IC-7610)
> StopWhenUnneeded=true
>
> [Service]
> ExecStart=/usr/bin/rigctld -m 3078 -r /dev/ic7610
>
> [Install]
> WantedBy=default.target
>
> Christoph
>
