Phil.

If your system reliably uses the same "device path" to reach the codec chips, then you can use that to steer things in the right direction with a couple of udev rules.

I'm (currently, but that may change...) using LMDE 6 as my OS, but that (on the same previous hardware) seems to create more mayhem by enumerating things differently each time it boots, or is awoken from a sleep or hibernation.

I now have the new FTDI based serial adapters, and that port assignment mayhem at least, has now been eliminated.

Pavucontrol (in conjunction with the new pipewire audio server) even with the helper file referenced in boot config file tweaks, absolutely will not allow the renaming audio devices, that worked solidly with LMDE 5 in the past (as previously, on the exact same hardware.)

From what I can gather (online information is still varied and sketchy about pipewire) it may not even be possible to rename them at all at present.

Someone tell me different if it is possible, with a link to a site describing all that is needed please.? Not just hints that it can be done with no specifics!? ;-)


At least building Fldigi/Flrig etc, works successfully as normal.


73 and happy new year.

Dave G0WBX.


--
Created on and sent from a Unix like PC running and using open source software:

开云体育

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:

The Country (CTY) Files were updated on 02 January 2025:



For installation instructions, start at:



Hover your mouse over the word Contest in the menu, then select the
software you are using.

To install the file, follow the link to your software at the top of the page.

If you are interested in a bigger CTY.DAT for everyday logging, you can get
it here:



Note that the release notes (and Version Entity) for this larger file are
different than what is shown below. There is a separate link to them.

As a reminder, there is an RSS feed of the latest country file announcements:



Here are the release notes:

2 January 2025 (CTY-3501)
VER20250102, Version entity is Bonaire, PJ4

Added/changed Entities/Prefixes/Callsigns:

* N0VAO, W0GG, W9CTY and WD8DII are all United States, K in CQ zone 3, ITU zone 6
* N7ML is United States, K in CQ zone 4, ITU zone 6
* AI8L, K1AF, KA4RUR, KB9SCT, KF9MT, KK7TZP, KN4SLP, N2GJ, N2UR and W9BED
are all United States, K in CQ zone 4, ITU zone 7
* AE4GW, AE4M, AK4QR, K1SPD, K4CCT, KB2UQS, KD5PCK, KI5ZQZ, KN4JGH,
KO4NOL, KZ4IT, N4AER, N5DF, NT0Y, W4AUB, W4BQK, W4KAM, W4NYZ, WA6CW and WB4KUU
are all United States, K in CQ zone 4, ITU zone 8
* K5ADR, K5YDR, K7KHZ, K8VAN, KE5MHV and W7VOA are all United States, K in CQ zone 5, ITU zone 8
* N7DKL is Alaska, KL
* W4I is Puerto Rico, KP4
* R9FCS/4 and R9JAB/6/P are both European Russia, UA
* RV3DSA/0 is Asiatic Russia, UA9 in CQ zone 19, ITU zone 34

Removed Entities/Prefixes/Callsigns:

* KK4MQM/C6A in Bahamas, C6
* GB0GTS in Scotland, GM
* AA5UZ, AG2TH, AK4I, K0IE, K0NW, K0SB, K4MQM, K7UPJ, K9GS, K9OR, KA9A,
KB8KMH, KC6UCN, KH6NO, KI4BIY, KI4ZZJ, KT4DW, KU4H, N0GAF, N0MU, N7CR,
N9SZ, NH6Z, W0ZZ, W3FU, W4KD, W4PGM, W4YEM, W7HJ, W8DX, W8HOT, W8ZM, W9BS,
WA4AA, WA4USA, WB8PAF, WB9IRF and WB9PRG in United States, K
* L73HAT/H in Argentina, LU
* R100R, R100RA, R100RN, R100RP, R100RR, R100RS, R100RV and R9XD/6
in European Russia, UA
* RX9SR/2 in Kaliningrad, UA2
* R100RB, R100RE, R100RU and R7HJ/0 in Asiatic Russia, UA9

Though I am subscribed to this reflector so that I can make these
announcements, I do not see most messages posted to it. If you have
any comments or corrections to the country file, please contact me
directly.

73 - Jim AD1C

--
Jim Reisert AD1C, <jjreisert at alum.mit.edu>,

开云体育

Hi Steve

It actually broke my fldigi/hamlib alpha builds. ie 4.2.06.18 and 19 now fails with Hamlib 4.7~git 2024-12-29T16:43:39Z SHA=028d75 64-bit (and later)

rigcontrol/hamlib.cxx: In function ‘void hamlib_get_rigs()’:
rigcontrol/hamlib.cxx:612:26: error: invalid conversion from ‘int (*)(rig_caps*, void*)’ to ‘int (*)(const rig_caps*, void*)’ [-fpermissive]
? 612 |???????? rig_list_foreach(add_to_list, 0);
????? |????????????????????????? ^~~~~~~~~~~
????? |????????????????????????? |
????? |????????????????????????? int (*)(rig_caps*, void*)
In file included from ./include/rigclass.h:27,
???????????????? from ./include/main.h:36,
???????????????? from ./include/squelch_status.h:31,
???????????????? from ./include/status.h:29,
???????????????? from ./include/nanoIO.h:42,
???????????????? from ./include/confdialog.h:424,
???????????????? from rigcontrol/hamlib.cxx:34:
/usr/local/include/hamlib/rig.h:3794:18: note:?? initializing argument 1 of ‘int rig_list_foreach(int (*)(const rig_caps*, void*), void*)’
?3794 | rig_list_foreach HAMLIB_PARAMS((int (*cfunc)(const struct rig_caps *, rig_ptr_t),

Cheers Bob VK2YQA

开云体育

commit e8bec83905a081e385ecc14777bae7edbd8887fe
Author: dave-w1hkj <w1hkj@...>
Date:?? Wed Jan 1 20:39:59 2025 -0600

??? THOR-25
?? ?
????? * add new THOR modem with following characteristics
??????? . symlen = 320
??????? . samplerate = 8000
??????? . flushlength = 40
??????? . bandwidth = 460
??????? . interleave depth = 50, 2 second
??????? . IEEE coefficients for viterbi encode/decode algorithms
????????? THOR_K15? 15
????????? K15_POLY1 044735
????????? K15_POLY2 063057
??????? . objective to provide highest baud within 500 Hertz bandwidth for
????????? European amateurs
??????? . CPS test for THOR-25
????????? - text:
??????????? 0123456789
??????????? abcdefghijklmnopqrstuvwxyz
??????????? ABCDEFGHIJKLMNOPQRSTUVWXYZ
????????? - # chars:????? 65
????????? - overhead:???? 10.720000 sec
????????? - xmt time:???? 10.080000 sec
????????? - xmt samples:? 166400
????????? - sample rate:? 8000
????????? - chars/sec:??? 6.45
????? * assigned secondary RsID code 691 to THOR-25
????? * increased flush length for all THOR baud rates
????? * added configurable start and end of signal shaping to these modem types:
??????? . dominoEX
??????? . psk
??????? . mfsk
??????? . rtty
??????? . thor
??????? . selectable on configuration tab Modem/General
????? * restored selectable paths to all THOR modem types
????? * added individual tone shaping for all THOR modem types

Increased the interleave duration to 2 seconds.? Not compatible with earlier test versions.

73, David, W1HKJ

Happy New Year to you too Sir.

Let's all hope 2025 is less troublesome than 2024 was!

73.

Dave G0WBX.

--
Created on and sent from a Unix like PC running and using open source software:

开云体育

Hi Lonney.

Yes, those links work too, but the problem is, not that one or other style of link works or not, is that the default links/symlinks created by the OS, can change whenever it is kicked into re-enumerating USB devices at Boot, or restart time, or whenever the USB subsystem changes, as devices are added or removed.

That is in effect what happens when RF gets into a USB lead and messes with things...? They often get assigned in a different order than they did the first time!?? So, even the serial/by-id values can change, and ruin your day.

It causes real chaos, in cases (such as here) where I have multiple serial devices (not just radio's, but a GPSDO and other USB/Serial connected devices in the shack.? (As well as two or three USB audio devices!)

If you just have one such USB serial device, and one only external sound I/O, you likely will never experience the chaos that can happen.


Using udev rules, based on some unique feature of a device (typically a serial number, if that exists, or some other unique info, take care, the VID/PID values are generally not unique) NOT based on what the OS did, will always work the same each and every time.

Consider the not uncommon event of RF in the shack, that can cause a USB device to "drop out", the OS then "forgets" it, but when the RF has gone, the device "re appears" and everything is re-enumerated.?? THAT is when the mayhem can happen, not just with Linux, but Windows and other OS's that support USB devices in the same way, as is the standard way these days..

Using:-
udevadm info -a -n /dev/ttyUSBn

(where n is 0, 1, 2 etc) does list a lot of good info, but in the case of my two main PC's (the currently sick HP and this Dell) that internally have at least two "layers" of dynamic hardware such as PCI and USB subsystems, each boot usually results in a different I/O "path" to an externally connected device, even if is physically connected to the same physical USB "port".

The Dell XPS laptop I'm using at the moment, has two internal PCI bus's, each of them has a collection of internal USB Hub's, that as well as supporting the external devices, also support the keyboad, mouse pad, internal sound system, some aspects of the video system (default LCD screen, and an external HDMI device if connected (and that too it seems can "carry" USB traffic between PC and "Monitor") as well a several other internal sensor type devices, battery state monitoring and temperature sensors etc.

Quite how exactly the combination of it's BIOS, UEFI and OS manage to bring all that up into a usable and generally stable system is quite amazing!

"Udev rules" when configured well, work reliably and consistently in every case, but ONLY where there is something unique about any particular "device" that is not assigned dynamically on a cold or warm start...

The obvious value to look at would be the "serial number", as that ideally (I know...)? "Could" be unique amongst a particular class of devices at least.? But the device makers are somewhat lax in that respect.? It seems Icom, and possibly other Ham rig makers may do the right thing, as does FTDI, but 99.999% of the low cost genuine (as well as the fake/counterfeit) devices do not.

Some, have the ability to use custom information held in an external ROM of some sort, using a microwire bus to communicate with it.? If present, the custom information in it will be provided to the OS when enumerated, instead of the hard coded info in the peripheral chip itself.

See the CM108 sound codec data sheet for example...


Scroll down to the "Reference Application Schematic"? (Page 27 of 28 in the file.)
U3 a 93C46 is a small EEPROM for such needs, connected to pins 2, 3, 4 and 5.

(Page 14 has the format of the needed data for that external EEPROM too.)

Therefore, it could be possible (eyesight and tooling permitting) to retrofit such an EEPROM "dead bug" on top of the codec chip perhaps.

(There is ISTR one Ham USB Audio interface device, that has lands for such a chip provided on the underside of the board, but I forget which one.)? Of course, you first need to program the EEPROM with the correct data in the correct format.

The combination of a "Genuine" FTDI USB serial bridge device (that already has a unique on the planet serial number) and with a CM108 + (programmed) EEPROM would with an example udev rule, solve the issue once and for all, perhaps.

But why would mass market developers do that, Ham Radio is a tiny & trivial marked compared to the general throw-away gadget market these days.

You pay your money, and take your choice.

73.

Dave G0WBX
(Who's eyesight is not good enough for such electronic microsurgery these days, even if I had the tooling to hand!)

-- 
Created on and sent from a Unix like PC running and using open source software:

Yea, that version was released in error and has a few issues, grab 2.2.14.



Robert

Richard,

What version are you using?

Robert