Re: [Hamlib-developer] K3 SWR > 2.5 at the end of every transmission.

[Uwe, D. <dg...@gm...>]

Hi Nate,

Thanks for your prompt reply. Okay, 
I'llwaittoreleasemynewWSJT-XImproved3.1.0untilHamlib4.7.1hasbeenreleased. 
ThatleadsmetoconcludethatApril18isapossiblereleasedate for 
WSJT-XImproved3.1.0 (260418).

73 de DG2YCB,
Uwe
________________________________________
German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg...@gm...
Info: www.qrz.com/db/DG2YCB


Am 08.04.2026 um 12:44 schrieb Nate Bargmann:
> * On 2026 07 Apr 19:16 -0500, w2yf wrote:
>> When using 4.7.1 with WSJT-X-improved and turning on the Rig data options
>> of Pwr/SWR along with the stop transmit if SWR is > 2.5, every single
>> transmit ends with an SWR over 2.5 (reports a 20.9:1 !!!).
> That would probably be seen with every prior version of Hamlib as well.
> I've also seen the glitch and it appears on my P3 with Wattmeter
> accessory as well at times and with WSJT-X 3.1.0 improved PLUS as
> packaged by Debian running with Hamlib 4.7.1~rc.
>
>> Second question, is it worth addressing?
> Given that the issue is internal to the radio, I'm not sure just how we
> could address it properly.  One thought I had was to store and average
> the last N readings but then if/when SWR really does change dramatically
> during TX (water contamination, etc.), that won't be reflected properly
> (pun intended).
>
> I suspect that the firmware is doing so many things at the point of
> ending TX that the reported SWR value gets corrupted.  Regardless, until
> about a decade ago when remote operation became very popular and near
> real-time radio control became an expectation, radios simply weren't
> designed with that amount of information flow in mind.  As you note, the
> K4 doesn't have the issue as it exists in the current era where near
> real-time control of all aspects is expected.  Also, it has an Ethernet
> port.  There is only so much data to be pushed through a serial port,
> even at 38400 bps.
>
> I appreciate your work on learning about this issue and where the
> problem lies.  I may be wrong but I just see this a part of the changing
> tech landscape where new expectations are pressed onto old(er) tech
> that's not really worth trying to paper over.  Of course, I'll merge any
> patches that do address this in a way that is helpful.
>
> 73, Nate
>
>
>
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer