Dialog about data corruption appears on second QSO from WSJT-X

9 posts / 0 new
Last post
N0NB
Dialog about data corruption appears on second QSO from WSJT-X

I installed WSJT-X 2.0.0 today and am running CQlog 2.3.0.

I have to start WSJT-X separately from entering remote mode in CQRlog as I use a custom init file. I did this long ago with WSJT-X and have done so for about a year.

Anyway, when I complete the first QSO in WSJT-X after starting CQRlog and entering remote mode (Ctrl-J) it is logged normally. Completing the second QSO results in a dialog from CQRlog giving the Ok and Abort buttons and stating to select Ok and risk data corruption (if it's really that bad, why offer the option?). Selecting OK clears the dialog but CQRlog does not log that QSO nor any subsequent ones.

Having to restart CQRlog for each QSO is kind of a drag.

oh1kh
Dialog about data corruption appears on second QSO from WSJT-X

Hi!
Starting separately is ok, and I even recommend that. Sure you have wsjtx settings rig as "hamlib net rigctld" and "localhost:4532" as address, eh?

Could you start cqrlog from command line like:
cqrlog debug=1 > /tmp/debug.txt
When error occurs and you shut down add file /tmp/debug.txt to your reply before starting cqrlog again.

Note also that wsjtx v2.0 uses angle brackets in some udp messages and cqrlog 230-001 and -002 can not handle that right. How ever it should not effect to logging section.
My latest test binary -204 filters those away.

There might be something else with v2.0 too. Logging udp message is a little bit longer, but the beginning of it should be similar as in earlier versions.

So I'm waiting for your reply, and do some more qsos with v2.0 by myself too. So far I have not catch any errors. But I have worked only few qsos.

--
Saku
OH1KH

N0NB
Dialog about data corruption appears on second QSO from WSJT-X

No, I am not using rigctld, instead I have Radio 2 unconfigured in CQRlog and switch to Radio 2 in the TX RX dialog before starting WSJT-X. I have customized the Gnome launcher to start WSJT-X as "wsjtx -r k3" and no combination of quoting will cause CQRlog to start WSJT-X, hence my manual method.

I will provide a debug file later this weekend.

oh1kh
Dialog about data corruption appears on second QSO from WSJT-X

HI!
Oh, I see. You do it reverse way. Actually you are using rigctld as wsjt-x starts it anyway.
Check with console giving command :
ps ax | grep rig
while wsjt-x is running. There should be only ONE instance of rigctld running then. (one line)

Is there a special reason for doing it that way? Do you use different rig with wsjt-x than with normal qsos?

If k3 is your digital rig, and Radio 1 is some other model, I would set up Radio 2 with k3 parameters. Then change wsjt-x settings/radio to Rig: Hamlib Net rigctld and Cat control Network server localhost:4532
When first switched to Radio 2 I would then start wsjt-x without any parameters (or you can keep -r k3 if you made radio settings change with that setup)

If you have same k3 for wsjt-x and other qsos then just forget Radio 2 completely. Do changes above to wsjt-x/radio settings and just simply start wsjt-x always after cqrlog is first running. After doing wsjt-x qsos just stop it and do other qsos and start again when you want to keep wsjt-x qsos again.
No need to switch radios in cqrlog TRXControl as long as it is running first. If you close cqrlog, but keep wsjt-x running you will see that it starts to complain about rig. That reminds you to keep cqrlog running while working with wsjt-x

3rd way, if you like to work with wsjt-x alone without cqrlog is to keep your -r k3 config for that but make another wsjt-x startup icon that starts it without parameters. In that wsjt-x settings/radio you can then use those values above and so this wsjt-x needs always cqrlog running first on background. In this case it is also possible to start wsjt-x from cqrlog remote.

Se also this: http://www.saunalahti.fi/~sakny/bin/cqrlog2/setting_rigctld_for_all_prog...

How ever if you like keep everything as it is now try to set preferences/TRXContorl/Radio2:
localhost, port 4532 (these are default)
Rig: #2 Net rigctl
UNcheck "Run rigctld at program start"
Other settings as default, serial port can be empty.

and look if that makes any improvement for logging.

--
Saku
OH1KH

KB9REV
Dialog about data corruption appears on second QSO from WSJT-x

Used CQRLOG for a year with WSJT-X and fldigi without problems. I could launch WSJT from CQRLOG and have it log within WSJT - no problem. I had to upgrade to the latest WSJT-X to maintain compatibility and needed to upgrade from Linux Mint 18.3 to 19.0 and that's when the problems began.

I am now having a similar problem as N0NB except the access violation is on my first QSO. I can log directly from within CQRLOG without a problem. When I start fldigi from CQRLOG I can log from within fldigi without a problem. However, when I start WSJT-X v 2.0 from CQRLOG it gives the same error message to me as N0NB after I try to log the QSO.

I've include the debug.txt file.

Thanks for making such a great program and I hope that you can see where my problem lies.

File: 

73,

KB9REV
Larry

oh1kh
Dialog about data corruption appears on second QSO from WSJT-x

Hi!
From debug it seems that logging is done ok until end. But then happens something and there are no debug lines showing where program is running at that phase.

Are you using Cq-monitor?
Or wsjtx Map instead?
Or just simple remote without those above?

I can not make that happen with my beta test binary 2.3.0-204. You could also try that if the error is same whit that ( http://www.saunalahti.fi/~sakny/bin/cqrlog2/ ).

I have to downgrade 2.3.0-001 (or -002) to see if that matters,

--
Saku
OH1KH

KB9REV
Dialog about data corruption appears on second QSO from WSJT-x

Saku,
I have installed the 2.3.0-206 beta test binary and the logging problems have gone away. Not sure what caused them, but very happy again that it is working well.

Thank you for all your time and effort to make this such an excellent logging program!

73,

KB9REV
Larry

F5RPN
Hello, same problem for me

Hello, same problem for me (Archlinux, CQRLOG 2.3.0 (001), wsjtx 2.0.0) and same solution with the beta release of december ( CQRLOG 2.3.0 (002)).

73 Eric

pa3fqh
Same problem here (solved)

I had exactly the same problem on Ubuntu 18.04 LTS and version 2.3.0 (001). After I installed the beta of 3 december - 2.3.0 (002), the problem was gone.

73
Peter/PA3FQH