Those of you who are using Linux in one form or another, and need some "stability" as to how USB/Serial adapters are named/numbered each time you connect them to you computer, could do no worse than consult this site...
http://hintshop.ludvig.co.nz/show/persistent-names-usb-serial-devices/
Very good and genuinely useful info regarding "udev rules". These are text files that you can create, so that the OS can assign a consistent device ID for your use, regardless of how the OS actually discovered them...
Two things though...
a) The place to put the needed udev configuration file, can vary between Linux distro's, worse, more than one place can be used. One for "system" and one for "users".
(On this now older Mint 19.3 system, my "Shack" udev file (99-shack.rules) is located at:- /lib/udev/rules.d)
You also need to kick the OS into re-scanning the udev rules after you added new rule or made a change. $ sudo udevadm control --reload-rules && udevadm trigger (Your login password will be asked for.)|
|b) Sadly, most USB<>Serial adapters, do NOT have any unique identifying feature in the information they present to the OS when connected, or as found during the boot process. But, you can use the "path" to them (the convoluted route via all the USB hubs etc, between OS and device) if needed. Just that you then *MUST* connect things up exactly the same each time.
But.. FTDI bless them, DO HAVE a unique serial number for each and every one of their devices. ("Genuine" devices that is, there are fake FTDI chips about as well!)
It is trivial then, to use that serial number to create (for example) a rule that results in a "device" name for example of:- /dev/ttyTMV71 Whenever that programming lead is connected.
The corresponding rule itself is:-
#TM-V71 (using the FTDI based lead) SUBSYSTEM=="tty", ATTRS{serial}=="AK06ML2R", SYMLINK+="ttyTMV71"
In this case, the FTDI unique "serial number" is AK06ML2R
You can discover that in several ways. One of the easiest is to perform a
$ dmesg -wH
command in a seperate terminal window. You will see instantly what happens when you connect or disconnect things. The -w means wait, and the H means human readable output. So, it just sits there reporting stuff as it happens. Untill you use a Control+C character to quit dmesg, then allowing you to close the terminal session as you need.
The output of that contains (for example)...
[ +0.114801] usb 1-1.4.2: New USB device found, idVendor=0403, idProduct=6001 [ +0.000003] usb 1-1.4.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ +0.000002] usb 1-1.4.2: Product: FT232R USB UART [ +0.000002] usb 1-1.4.2: Manufacturer: FTDI [ +0.000002] usb 1-1.4.2: SerialNumber: *AK06ML2R* [ +0.002668] ftdi_sio 1-1.4.2:1.0: FTDI USB Serial Device converter detected [ +0.000047] usb 1-1.4.2: Detected FT232RL [ +0.000534] usb 1-1.4.2: FTDI USB Serial Device converter now attached to ttyUSB5 [ +12.717166] usb 1-1.4.2: USB disconnect, device number 17 [ +0.000237] ftdi_sio ttyUSB5: FTDI USB Serial Device converter now disconnected from ttyUSB5
Note the "usb 1-1.4.2:" common parts of each line. the "1.4.2" after the initial "1-" changes if the same device is plugged into a different port, as below...
[ +0.000002] usb 1-1.4.5.5: Manufacturer: FTDI [ +0.000001] usb 1-1.4.5.5: SerialNumber: *AK06ML2R* [ +0.002685] ftdi_sio 1-1.4.5.5:1.0: FTDI USB Serial Device converter detected [ +0.000047] usb 1-1.4.5.5: Detected FT232RL [ +0.000408] usb 1-1.4.5.5: FTDI USB Serial Device converter now attached to ttyUSB5
It now has a path of 1.4.5 You can use that information in a udev rule thus, below.
#TS-870s SUBSYSTEM=="tty", ATTRS{devpath}=="1.3.3", SYMLINK+="ttyTS870"
(In this case, for my Kenwood TS-870s, that is connected to one "leg" of a 4 port Prolific based device. The line beginning with a # Is a comment, you can for example include human readable text as a reminder...)
Example readlink outputs:
$ readlink /dev/ttyTMV71 ttyUSB5
or...
$ readlink /dev/ttyTS870 ttyUSB2
Note! Your "custom" name "ttyTMV71" for example is valid, but what it points to, the "default" device name "ttyUSB5" is also still valid. The only difference is that "ttyTM-V71" will not change, regardless of the "ttyUSBn" device it actually relates to.
So, in this instance, you would ordinarily use "/dev/ttyUSB5" in Chirp to work with the connected Kenwood TM-V71 radio. However, you CAN manually edit the port name in Chirp, to show "/dev/ttyTMV71", and it remembers it between sessions, so regardless of what ttyUSB device number is actually uses, it will work.
(Or specify "/dev/ttyTS870" in Flrig or Fldigi. You of course can use readlink in a script to set an environment variable prior to launching some software that needs a port specified in it's command line invocation. It's not difficult, and there is ton's of good instructional pages out there that will help you automate things for a stable life...)
You can also use udev rules to give consistent names to other devices, if you have multiple of the same type. Some USB sound cards for example also have a unique ID of some sort you can use.
Hope something above helps. It seems like a lot of trouble and faffing about at first, but explore it, and you'll never look back. It is also one of the more compelling reasons to buy only genuine FTDI USB/Serial products too! It just makes life easier!
Lastly. If you go this route.. DO make backups of your rules files! You will likely need them if/when you upgrade/replace your OS. Or just to remind your faded grey cell, what you did to make it work in the past.
Have Fun!
73.
Dave G8KBV (just another Linux user, "NOT" an expert by any means.)
On 03/11/2022 19:00, chirp_users-request@intrepid.danplanet.com wrote:
Message: 1 Date: Thu, 3 Nov 2022 02:26:57 -0500 From: W Paul Millsac0hy@wpmills.com Subject: Re: [chirp_users] Linux and chirp To:chirp_users@intrepid.danplanet.com Message-ID:cf28ae50-a629-50ea-542b-4d0db3ee525c@wpmills.com Content-Type: text/plain; charset=UTF-8; format=flowed
But if you plug in both, one will be ttyUSB0 and one will be ttyUSB1, etc.
On 10/29/22 01:05, Cinaed Simson wrote: