Re: [Hamlib-developer] CW sending is very broken...

[Black M. <mdb...@ya...>]

I need more logs with -vvvvv and -Z to see timing.I thought we had it thread safe but maybe tlf is doing something different.
I'll have to take a look at tlf.

Mike W9MDB

 

    On Tuesday, February 20, 2024 at 10:50:46 AM CST, George Baltz <geo...@gm...> wrote:  
 
 ...but that may just be a symptom.


Last weekend I operated a bit in the ARRL DX CW test - first CW contest 
since last February.  Setup was my TS-890S barefoot into a Buddipole and 
a 10M dipole, driven by a laptop running tlf with Hamlib 4.6-git.

Worked fine for a while, then started getting no response to keyboard, 
followed by multiple copies of text being sent.  Saw some hamlib errors 
displayed in the tlf bottom line, but they vanished too quickly to 
remember. Then changed over to running rigctld and configuring tlf to 
use hamlib_dummy(#2) as rig.  Still getting flaky response and keying.

So I added -vvv and captured the logs - some are attached.

Looking at these, then at the code, it looks to me like the problem is 
much deeper than rig_send_morse - AFAICT none of the backend code is 
thread-safe, nor is the rig protocol itself. Having the main app thread, 
morse_data_handler, and other threads all calling the rig backends at 
the same time means they are stomping all over each other, and the rig 
responses may be consumed by the wrong requestor.

In the short term, bypassing(reverting) the morse_data_handler would fix 
keying.  For the long term we need a real plan to make hamlib 
thread-safe.  This means defining the scope of the threads, what code 
needs protection, what are the effects on the application, how to do 
error recovery/logging, etc.  Making legacy code thread-safe is not easy.

Comments, please, to the list.

73

n3gb

_______________________________________________
Hamlib-developer mailing list
Ham...@li...
https://lists.sourceforge.net/lists/listinfo/hamlib-developer