KLog wsjtx-2.6.0-RC4 problems #1114
Comments
… call to PS times out for Kenwood rigs #1114
|
Using a package from master hamlib-4.5~git-20220913.e7262e2.tar.gz (my tarball) (I did try without --set-conf="serial_handshake=None" but the rig was unresponsive (not a beep :)) I hit the klog test button at 21:51:50 in the log. The test button remained red, after which klog locked up and eventually had to be killed. Then, as a demonstration of normal operating with wsjtx and klog I had two QSOs using FT8 on 30m with logging running. Both contacts were auto-logged to klog from wsjtx and there were no issues with hamlib working split. log5.txt Big file! The problems now only seem to affect the hamlib test button in klog. Edit: I notice that a . was missing from 127.0.0.1, however I suspect that -T parameter is maybe not used now? |
|
That is not the latest hamlib....tonight's build (20220914) or the current github master version should work OK.
Your log shows hamlib from 3 days ago.
rigctld Hamlib 4.5~git Sat Sep 10 18:00:34 2022 +0000 SHA=098d1d
On Tuesday, September 13, 2022 at 04:25:29 PM CDT, Barry Jackson ***@***.***> wrote:
Using a package from master hamlib-4.5~git-20220913.e7262e2.tar.gz (my tarball)
I ran:/usr/bin/rigctld --vfo -vvvvvv -Z -m 2003 -r /dev/ttyUSB0 -T 127.0.01 -t 4532 --set-conf="serial_handshake=None" > log4.txt 2>&1
I checked on opening klog that the frequency in the program was following the VFO OK.
(I did try without --set-conf="serial_handshake=None" but the rig was unresponsive (not a beep :))
I hit the klog test button at 21:51:50 in the log. The test button remained red, after which klog locked up and eventually had to be killed.
log4.txt
Then, as a demonstration of normal operating with wsjtx and klog I had two QSOs using FT8 on 30m with logging running. Both contacts were auto-logged to klog from wsjtx and there were no issues with hamlib working split.
log5.txt Big file!
The problems now only seem to affect the hamlib test button in klog.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
|
On 13/09/2022 22:47, Michael Black wrote:
That is not the latest hamlib....tonight's build (20220914) or the current github master version should work OK.
Your log shows hamlib from 3 days ago.
rigctld Hamlib 4.5~git Sat Sep 10 18:00:34 2022 +0000 SHA=098d1d
The tree that I used was:
commit e7262e2
Author: Mike Black W9MDB ***@***.***>
Date: Tue Sep 13 11:45:58 2022 -0500
Make TS450S turn off has_ps
So what am I doing wrong?
I cloned your repository:
Edit : link here was obviously wrong - doing too many things at once!
I checked out
bugfix/541_crash_in_ri branch
Made a tarball from it which if I now decompress has the above last
commit in it.
commit e7262e2 (HEAD -> master,
origin/master, origin/HEAD)
Author: Mike Black W9MDB ***@***.***>
Date: Tue Sep 13 11:45:58 2022 -0500
Make TS450S turn off has_ps
#1114
I see you added one more commit which I will test, but first I need to
know what is going wrong.
Barry
…
On Tuesday, September 13, 2022 at 04:25:29 PM CDT, Barry Jackson ***@***.***> wrote:
Using a package from master hamlib-4.5~git-20220913.e7262e2.tar.gz (my tarball)
I ran:/usr/bin/rigctld --vfo -vvvvvv -Z -m 2003 -r /dev/ttyUSB0 -T 127.0.01 -t 4532 --set-conf="serial_handshake=None" > log4.txt 2>&1
I checked on opening klog that the frequency in the program was following the VFO OK.
(I did try without --set-conf="serial_handshake=None" but the rig was unresponsive (not a beep :))
I hit the klog test button at 21:51:50 in the log. The test button remained red, after which klog locked up and eventually had to be killed.
log4.txt
Then, as a demonstration of normal operating with wsjtx and klog I had two QSOs using FT8 on 30m with logging running. Both contacts were auto-logged to klog from wsjtx and there were no issues with hamlib working split.
log5.txt Big file!
The problems now only seem to affect the hamlib test button in klog.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
|
Wrong repository -- that's a fork....
https://github.com/Hamlib/
Mike
On Tuesday, September 13, 2022 at 05:22:27 PM CDT, Barry Jackson ***@***.***> wrote:
On 13/09/2022 22:47, Michael Black wrote:
That is not the latest hamlib....tonight's build (20220914) or the current github master version should work OK.
Your log shows hamlib from 3 days ago.
rigctld Hamlib 4.5~git Sat Sep 10 18:00:34 2022 +0000 SHA=098d1d
The tree that I used was:
commit e7262e2
Author: Mike Black W9MDB ***@***.***>
Date: Tue Sep 13 11:45:58 2022 -0500
Make TS450S turn off has_ps
So what am I doing wrong?
I cloned your repository:
https://github.com/zarath/nanovna-saver
I checked out
bugfix/541_crash_in_ri branch
Made a tarball from it which if I now decompress has the above last
commit in it.
commit e7262e2 (HEAD -> master,
origin/master, origin/HEAD)
Author: Mike Black W9MDB ***@***.***>
Date: Tue Sep 13 11:45:58 2022 -0500
Make TS450S turn off has_ps
#1114
I see you added one more commit which I will test, but first I need to
know what is going wrong.
Barry
On Tuesday, September 13, 2022 at 04:25:29 PM CDT, Barry Jackson ***@***.***> wrote:
Using a package from master hamlib-4.5~git-20220913.e7262e2.tar.gz (my tarball)
I ran:/usr/bin/rigctld --vfo -vvvvvv -Z -m 2003 -r /dev/ttyUSB0 -T 127.0.01 -t 4532 --set-conf="serial_handshake=None" > log4.txt 2>&1
I checked on opening klog that the frequency in the program was following the VFO OK.
(I did try without --set-conf="serial_handshake=None" but the rig was unresponsive (not a beep :))
I hit the klog test button at 21:51:50 in the log. The test button remained red, after which klog locked up and eventually had to be killed.
log4.txt
Then, as a demonstration of normal operating with wsjtx and klog I had two QSOs using FT8 on 30m with logging running. Both contacts were auto-logged to klog from wsjtx and there were no issues with hamlib working split.
log5.txt Big file!
The problems now only seem to affect the hamlib test button in klog.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: ***@***.***>
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
|
OK I now have results from main master repository. I'm certain that you pointed me at your fork, as I had the branch name. Doing the same as before with just rigctld and klog, the VFO tracks ok, but the hamlib test in klog fails which crashes klog. As before I then used klog and wsjtx for a contact which went smoothly. Sorry for the mix-up |
|
On 13/09/2022 23:25, Michael Black wrote:
Wrong repository -- that's a fork....
https://github.com/Hamlib/
Mike
I realize that I got two bugs and two different projects totally mixed
up in my mind today.
My apologies for the confusion.
Barry
|
|
Try again...put another patch in.
Mike W9MDB
On Tuesday, September 13, 2022 at 06:17:49 PM CDT, Barry Jackson ***@***.***> wrote:
OK I now have results from main master repository. I'm certain that you pointed me at your fork, as I had the branch name.
Anyway now I have a package installed built from #8c4c906
Doing the same as before with just rigctld and klog, the VFO tracks ok, but the hamlib test in klog fails which crashes klog.
log7.txt
As before I then used klog and wsjtx for a contact which went smoothly.
log8.txt
Sorry for the mix-up
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
|
Using build from 7db23d5 Success! Red to Green :) Klog did not crash and OK-ing the hamlib settings dialogue did not cause a crash. After about a minute (a known bug in klog) klog became responsive again and continued working normally. Closing and restarting either klog or wsjtx does not now cause any issues during a session, tested also with rigctld started by systemd. Nice job Mike! Oops forgot to attach the log :) |
|
Can you send me another hamlib log to be sure it's not hamlib causing the klog problem?
On Wednesday, September 14, 2022 at 07:10:03 AM CDT, Barry Jackson ***@***.***> wrote:
Using build from 7db23d5
Hit the test button at 12:39:10
Success! Red to Green :)
Klog did not crash and OK-ing the hamlib settings dialogue did not cause a crash. After about a minute (a known bug in klog) klog became responsive again and continued working normally.
Closing and restarting either klog or wsjtx does not now cause any issues during a session, tested also with rigctld started by systemd.
Nice job Mike!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
|
I'm fairly sure it's not hamlib causing the problem, as it happens every time the 'settings' dialogue is OKed irrespective of whether the hamlib tab has been used. |
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.
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.
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).
The text was updated successfully, but these errors were encountered: