klog-2.2.1 causes hamlib-4.4.2 (rigctld) with wsjtx-2.6.0-RC4 to continually reverse split VFOs every second.

[barjac]

Testing wsjtx-2.6.0-RC4 with hamlib-4.4.2 works fine, until klog-2.2.1 is running. All seems fine initially until the end of a transmit frame, when the VFO starts to cycle, reversing TX/RX modes every second (approx). This is with klog in read only mode for hamlib. Rig is Kenwood TS450S.

I will test with the previous version of wsjtx next to confirm whether this is due to a change in wsjtx

[barjac]

OK, testing with wsjtx-2.5.4 there is no sign of the problem, so despite klog 'exposing' the issue, it does appear to be a change in wsjtx-2.6.0 that is causing it. Note that in both cases wsjtx is built to use the system hamlib-4.4.2.

[mdblack98]

May I suggest you use the latest hamlib and see if that works. http://n0nb.users.sourceforge.net/

Mike W9MDB

[barjac]

Hi Mike, Thanks for following my link on wsjtx ML. That was my next thought this morning after sleeping on it. Indeed, packaging and installing hamlib-4.5-0.20220911.098d1d8d.1 this morning has fixed the issue for me. Is there likely to be a stable release of hamlib soon that I can use for our (Mageia) next distribution release? We are getting quite close to version freeze and trying to tie up loose ends. Thanks, Barry

@Jaime I will let you decide whether to close this as others may be using earlier hamlib versions. I have noticed that logging from wsjtx-2.6.0 seems a little flakey now. A restart of klog while wsjtx is running seems to fix this, so care needs to be taken about the order in which programs are started.

[barjac]

It seems there is a klog issue with hamlib 4.5. It does work, as I tested with wsjtx-2.6.0 above, however the hamlib test button in settings remains red and when pressed it locks up klog. (Without wsjtx running and using rigctld).

[mdblack98]

Please run rigctld with verbose turned on like this, duplicate the problem, and send me the log. Just add "-vvvvvv -Z" like this: rigctld -m 1027 -r /dev/ttyUSB0 -s 9600 -vvvvvv -Z >log.txt 2>&1 Send me the log.txt file MIke W9MDB

[mdblack98]

I am planning on releasing 4.5 soon.

[barjac]

OK Mike here goes. I have used the rigctld parameters as normally included in our systemd unit file.

/usr/bin/rigctld --vfo -vvvvvv -Z -m 2003 -r /dev/ttyUSB0 -t 4532 --set-conf="serial_handshake=None" >log2.txt 2>&1

The above values are normally in variables from my config file.

In the attached log2.txt I started rigctld, then klog, which is in read only mode and was communicating OK with the rig. I navigated to the settings->hamlib page. The test button was red. I clicked the button at 12:51:41 (it stayed red) and I then cancelled the settings dialogue, and then killed rigctld with CTRL/c

log2.txt

klog-2.2.1-1.mga9 lib64hamlib4-4.5-0.20220911.098d1d8d.1.mga9_bcj hamlib-utils-4.5-0.20220911.098d1d8d.1.mga9_bcj

BTW Mike any chance you could reverse the git# and date in your snapshot tarball names so they sort by date and not git#? As you can see in the package name above, without the reversal a newer snapshot could sort anywhere. :)

[mdblack98]

I don't see a set_ptt command in the log.  Does KLog use CAT ptt or another COM port for PTT (i.e. RTS/DTR keying?)Also the serial_handshake looks wrong for the TS-450S as it has hardware flow control. I did see that the 450 does not have the PS command so I've made it detect that now the 1st time it times out. Can you do a "git clone" of the master and test the latest version? Mike W9MDB

On Monday, September 12, 2022 at 07:20:13 AM CDT, Barry Jackson ***@***.***> wrote:  

OK Mike here goes. I have used the rigctld parameters as normally included in our systemd unit file.

/usr/bin/rigctld --vfo -vvvvvv -Z -m 2003 -r /dev/ttyUSB0 -t 4532 --set-conf="serial_handshake=None" >log2.txt 2>&1

The above values are normally in variables from my config file.

In the attached log2.txt I started rigctld, then klog, which is in read only mode and was communicating OK with the rig. I navigated to the settings->hamlib page. The test button was red. I clicked the button at 12:51:41 (it stayed red) and I then cancelled the settings dialogue, and then killed rigctld with CTRL/c

log2.txt

klog-2.2.1-1.mga9 lib64hamlib4-4.5-0.20220911.098d1d8d.1.mga9_bcj hamlib-utils-4.5-0.20220911.098d1d8d.1.mga9_bcj

BTW Mike any chance you could reverse the git# and date in your snapshot tarball names so they sort by date and not git#? As you can see in the package name above, without the reversal a newer snapshot could sort anywhere. :)

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

[barjac]

I will test git master later - thanks. klog is in read-only mode so is not concerned with PTT, which is controlled by wsjtx using CAT, but it was not running during the above tests. I just discovered that (with rigctld started by systemd on boot) that if wsjtx is started without klog, then it fails due to hamlib timeout. With klog started first then both programs work and display the VFO correctly. I will get a log of trying to start wsjtx first before I update to git master.

[ea4k]

It was a bug in hamlib. Thank you for working on it to both of you.

[mdblack98]

Sorry...was thinking of another issue.  I believe the VFO swapping should be fixed in the latest. Mike W9MDB

On Tuesday, September 13, 2022 at 10:55:04 AM CDT, Barry Jackson ***@***.***> wrote:  

I will test git master later - thanks. klog is in read-only mode so is not concerned with PTT, which is controlled by wsjtx using CAT, but it was not running during the above tests. I just discovered that (with rigctld started by systemd on boot) that if wsjtx is started without klog, then it fails due to hamlib timeout. With klog started first then both programs work and display the VFO correctly. I will get a log of trying to start wsjtx first before I update to git master.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>