Although I prefer #Linux for many things, I do bump into a problem that makes it feel like MS DOS ca. 1987 sometimes.

Reboot, & my USB (both tty & audio) devices may re-shuffle.

Everything was working. #DireWolf #RigBlaster #WSJTX #WinKeyer #FTdx3000

Without changing any USB cables in any way, reboot, & Direwolf cannot start because the TTY port isn't there anymore.

Now starting documenting a new habit. Unplug all USB but one if I'm going to reboot, then plug in specific order. This is dumb.

@kelvin0mql I wonder if some startup script could update some symlinks to the actual devices. Perhaps lsusb could be used to identify the devices by type.

@kc0itq
Yeah, toying with the idea of writing a bash script that checks where the RigBlaster currently is, edits two lines of direwolf.conf if needed, and THEN starting direwolf.

The randomness is annoying, though. I mean, if nothing moved, then NOTHING SHOULD MOVE. Alas, they sometimes move. It's dumb.

@kc0itq
The smarter bits of #HamRadio software for #Linux get configured using the #ALSA descriptions of the devices, rather than specific USB ports or "card 1, card 2" crap.

So some of these work after a re-shuffle, and others do not.

@kelvin0mql @kc0itq

There should be device names that are specific to the radio or adapter. Have a look at the udev monitoring tools when you plug in a device.

I blame all of the YouTube tutorials that use the plain /dev/ttyUSB0 names.

@kelvin0mql @kc0itq If your version of Linux uses udev there may be repeatable device names somewhere in the /usr/lib subdir. These are annoyingly long.
You can write your own udev rules to put short names in the /dev filesystem.
I've provided instructions to the Portland Oregon "The Linux Users Net" on groups.io. I cobbled the info together from several other posts around the web. This group is invite only. Contact kc7mm (Russ) at kc7mm.com to get access.

@kelvin0mql @kc0itq You should be able to be granted access. Search for "Create named aliases for your USB devices"

The net meets Mondays 2000 hours Pacific time (Z-8) if you want to participate.

@Howitzer105mm @kc0itq
Nope. That ain't gonna help me, it would appear.

This really was never about whether there's a way to work very hard on something complicated to fix it.

This was about the fact that - out of the can - MacOS & Windows apps are able to point to a device ONCE & connect to it past reboots, un/re-plugs, etc...

While - out of the can - Linux apps are often written such that they cannot. I imagine it is slightly harder, but developers do not care (enough).

@Howitzer105mm @kc0itq
It's a thing I complain about WRT Developers somewhat on the regular. The one-man-shop Developers do not have Customer Care VPs pounding on them. So they don't prioritize these things.

Understandable with free software that people write simply because they want it "out there". They have chosen a hard life, & seem to expect that everyone else should suffer likewise. It's obtuse, but I get it.

This is just me pissing into the wind, frankly.

@kelvin0mql @kc0itq Is that really sufficient to know? Well behaved usb devices have a unique serial number. That number can be used to uniquely id the device between reboots which in turn let's udev place them at a repeatable location in the /dev fs

@Howitzer105mm @kc0itq
Oh, a SERIAL number?

I guess I assumed when you said "annoyingly long" you meant like how the ALSA description includes things like
BurrBrown_from_Texas_Instruments_USB_AUDIO_CODEC

Currently doing
$ find /usr/lib |more
and paging through to see if anything looks like it might be a USB device serial number.

Please stand by...

@Howitzer105mm @kc0itq
A million things under
/usr/lib/python3
so I've halted that, and am doing
$ find /usr/lib |grep -v python3|more

Please stand by...

@kelvin0mql @kc0itq If you run 'locate' on your system it will be faster to search that output for burr

@Howitzer105mm @kc0itq
Just finished paging through all that.

Nope.

There's a million pages, and I don't see annoyingly long paths/names with serial numbers that look like they could be at all related to USB tty or sound devices.

I think this Xubuntu system doesn't work like you're describing.

@kelvin0mql I'd suspect some intelligence that is artificial in nature could write your bash script. If you use symlinks, programs you don't know of yet will work with those. I'd also wonder if it's just a timing thing: which device responded first on the bus.
I wrote udev rules to create /dev/ttyIC-7300, /dev/ttyWinKeyer, etc. It's pretty easy, and I don't have to think about USB device shuffles.
@kelvin0mql @kc0itq
Mostly it's just matching the vendor and device IDs to the devices.
@kelvin0mql @kc0itq

SUBSYSTEM=="tty", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", SYMLINK+="ttyIC-7300"
SUBSYSTEM=="hidraw", ATTRS{idVendor}=="08bb", ATTRS{idProduct}=="2901", SYMLINK+="IC-7300-audio"
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", SYMLINK+="ttyCI-V"
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6015", SYMLINK+="ttyWinKey"

@kelvin0mql @kc0itq

@praxiscode @kelvin0mql @kc0itq

We've done a fair bit of this for FARPN, thanks for @n6cta for guiding me through dealing with dual (dueling?) Icom radios. One should be easier, but there are config files for two that could be made to work with one:

https://wiki.farpn.net/tutorial-packet-on-pi#pbbs_hardening

tutorial-packet-on-pi [FARPN]

Is there any way to leverage udevd for the audio portion of that setup doc?

@IrrationalMethod @kelvin0mql @kc0itq

@praxiscode
Not that I'm aware of, but I didn't look very hard for it. We ended up needing to tie it to the specific USB port so it wouldn't get mixed up with my 9700.

@kelvin0mql @kc0itq

It should be possible to match on serial number as well

@IrrationalMethod @kelvin0mql @kc0itq

@kelvin0mql

This actually sounds irritating af. See also frustrating.