CQRlog Alpha affects WSJTx in ways it shouldn't.

3 posts / 0 new
Log in or register to post comments
Last post
Fri, 2026-01-09 01:10
#1
VK2XAX
CQRlog Alpha affects WSJTx in ways it shouldn't.

I've been using the Alpha version for a while now and I've found that if "UDP Accept" is switched on in WSJTx and "remote mode for wsjt" is switched on in CQRlog Alpha then the following things occur...

In FT4 mode RX frequency gets set to 5000 # thankfully FT4 doesn't care.

In FT8 mode RX frequency gets set to 5000 # thankfully FT8 doesn't care.

In JT4 mode RX frequency gets set to 5000 # JT4 complains that RX frequency is outside operational parameters

In Q65 mode T/R gets changed from whatever you have set to 300s And RX frequency gets set to 5000 !! # this severely affects the operation in Q65 since the T/R period is important to the current mode of operation.

In MSK mode T/R gets changed from whatever you have set to 30s And RX frequency gets set to 1600 # this also makes MSK unusable

This behavior can be see in the following versions of WSJTx, 2.7, 3..0rc1, ImprovedPlus 251212

OS is Ubuntu 24.04.3 LTS

So the question is... Why is CQlog affecting WSJTx in these ways ?

regards

Tim
de VK2XAX

Top
Fri, 2026-01-09 07:52
oh1kh
CQRlog Alpha affects WSJTx in ways it shouldn't.

HI Tim! Good question, and perhaps you have found a bug that has been there for long.
Cqrlog uses wsjtx UDP message #15 "Configure" for two cases.

1) 
            //clean wsjtx's DXCall and DXGrid and do GenStdMsg(to clean it too)
               Begin
                 frmMonWsjtx.SendConfigure('','',' ',' ',$7FFFFFFF,$7FFFFFFF,$7FFFFFFF,False,True); 

2) // New QSO From Spot
                 frmMonWsjtx.SendConfigure('','',' ',' ',$7FFFFFFF,$7FFFFFFF,$7FFFFFFF,False,True); 

Wsjtx API says:
Configure In 15 quint32
* Id (unique key) utf8
* Mode utf8
* Frequency Tolerance quint32
* Submode utf8
* Fast Mode bool
* T/R Period quint32
* Rx DF quint32
* DX Call utf8
* DX Grid utf8
* Generate Messages bool
*
* The server may send this message at any time. The message
* specifies various configuration options. For utf8 string
* fields an empty value implies no change, for the quint32 Rx DF
* and Frequency Tolerance fields the maximum quint32 value
* implies no change. Invalid or unrecognized values will be
* silently ignored. NOTE that if a mode/submode change occurs and
* the current frequency is NOT in the frequency table for that
* mode, a frequency change (to the default frequency for that band
* and mode) may occur.
 
 It seems that I have thought that quint32 is a signed integer, so maximum value would be then $7FFFFFFF
 How ever if quit32 is unsigned integer the maximum value is $FFFFFFFF
 
I have tested now with $FFFFFFFF values and it seems that at least when band changes there is no change to RXfrequency.
I will put that to CqrlogAlpha devel branch to test it for some time and later release it (if it works) in version 140.

Thanks for reporting!

--
Saku
OH1KH

Top
Fri, 2026-01-09 13:49
DO1YHJ
Nice

Glad to see you may have found a Bug and a possible solution.
Just pulled the git branch, compiled it and it looks good so far.
No more RX frequency changes on Mode or Band Change.
Tested with FT4 and FT8, did not use the other Modes.
And the Glitch with not showing snr on the first start in normal Mode in the cq-monitor seems to be solved too.

73 de Heinz-Juergen DO1YHJ

Top