WSJT-X Logging

18 posts / 0 new
Last post
n2yqt
WSJT-X Logging

What is the trick to getting QCRLOG to do a call lookup when it logs from WSJT-X in remote mode? All the info shows up in the New QSO window but when it actually logs it the name and everything else goes away.

oh1kh
WSJT-X Logging

HI !

For me it does. But it is because I'm running my own 1.9.0 version.
I do not know how Petr did add this wsjt-x addition to his code, so it depends on that.

If call lookup is done in normal use it should work also with wsjt-x,
If it doesn't, source code has difference and the trick is to fix code and recompile.

--
Saku
OH1KH

--
Saku
OH1KH

n2yqt
Thats the weird part. Some

Thats the weird part. Some times it will do a lookup and sometimes it will not. I'm sure it's something simple. I'll check it over when I get home later. I had made my own to log WSJT-X in to N2FJP that worked really well. 

w6jhb
Same problem here

I just installed CQRlog 2.0.4 and have the same problem. All fields are visible in New QSO panel, but at the no of a QSO in WSJT-X, the name and QTH fields do not get populated into the QSO database. This, to me, is a bug and needs addressing.

Jim / W6JHB
Folsom, CA

oh1mrr
Noticed also this, now, when

Noticed also this, now, when started make some JT qsos...

<p>Jarmo</p>

oh1kh
code is still there

HI!
Checked latest cqrlog code at github and wsjt-x remote code is still there unchanged.
fNewQSO.pas
//----------------------------------------------------
if TXEna and TXOn then
begin
edtCall.Text := '';//clean grid like double ESC does
old_ccall := '';
old_cfreq := '';
old_cmode := '';
if dmUtils.GetBandFromFreq(mhz) <> '' then //then add new values from status msg
cmbFreq.Text := mhz;
cmbMode.Text := TXmode;
edtCall.Text := call;
edtCallExit(nil)
end;
//----------------------------------------------------
if new then
begin
edtCall.Text := '';//clean grid like double ESC does
old_ccall := '';
old_cfreq := '';
old_cmode := '';
//frmMonWsjtx.NewBandMode(WsjtxBand,WsjtxMode)
end
end; //Status

These 2 parts should "simulate" new call typing to new qso-form's call-field.

First "if TXEna"-case is the "normal" case.
Call should appear to new qso's call field when wsjt-x transmit is ON and next status packet is receved by cqrlog. Should read as "Wsjt-x remote #1" on top of callsign field of newQSO form.

Second "if new"-case should wipe callsign away from newQSO's call field when band is changed from wjtx-x and next status packet is receved by cqrlog after that (does not require TX on). Should read as "Wsjt-x remote #1"

Those are the cases.

I do not know if there are changes elsewhere at newQSO.pas (1.9.0 --> 2.0.4) that may "wipe" callsign away for some reason.

Saku
OH1KH

--
Saku
OH1KH

oh1mrr
Call comes ok into log, but

Call comes ok into log, but like name taken from qrz.com
does not appear in log after saving qso..

<p>Jarmo</p>

oh1kh
name disappear

Might be differences between 1.9.0 and 2.0.4.
At the moment when you answer (fire wsjt-x TX period) does call AND NAME appear in to newQSO window ?

It should if "Enable auto search..." is set from Preferences -> new qso. Just like it appears when call is manually typed in.
It indicates that info fetch is done.
After that, if the name is there, but does not go into log it really is difference between versions and Petr should know why.

If name does not appear to newQSO window at same time (or internet delay later) as call does it is also something that Petr has changed.
If I remember right calling edtCallExit(nil) subroutine should execute info search, if it is set from preferences in version 1.9.0

For me, with my 1.9.0.mod.vers. it appears from first wsjt-x TX period and goes to log, too.

--
Saku
OH1KH

oh1mrr
Action is same... In first TX

Action is same... In first TX, comes info visible, where name shows ok.
But after you confirm WSJT qso ok, name does not go into log.
When I type name into WSJT confirmation window, it goes into log.

<p>Jarmo</p>

w6jhb
Not only the name....

For me, it is not only the name - the QTH information that is present in the New QSO screen is also missing when the contact is logged into the CQRlog database. I am on version 2.0.4.

Jim / W6JHB
Folsom, CA

oh1kh
Not in log

If everything show ok at newQSO-form, but does not go into log database confirms that something has changed from 1.9.0 to 2.0.4 and Petr should check the change that prevents logging.

Just to be sure I'll ask one more thing:

Do you log qso via wsjt-x logging or try just "save qso" from newQSO form?

I have never used way to press "Save QSO" from new QSO window. I suspect it does not work that way as wsjtx-remote is activated.
Right way is make logging with wsjt-x's logging form. Even if you really do not need that log.

At wsjt-x settings you can select to activate logging when "free text" message includes "73". Otherwise you have to press wsjt-x's "log qso" button and then insert power/comment if you want and finally press "OK".

This causes type 5 message "Wsjt-x remote #5" that saves qso to cqrlog. And as said, for me it takes also fetch information along from newQSO form.

If you do it that way and still name etc. that shows on newQSO form does not go into log as Petr why,

Saku
OH1KH

--
Saku
OH1KH

oh1mrr
I do it via wsjt-x logging.

I do it via wsjt-x logging. Ie via window, which open after I sen last 73

<p>Jarmo</p>

oh1kh
Oops

You may be fooled....
I may be fooled....

Who remembers untouched code after 2 years?

It seems that coding of remote message #5 has something that clears more than wanted.

At newQSO.pas:

5 : begin
ParStr := StFBuf(index);
if dmData.DebugLevel>=1 then Writeln('Qso Logged Id:', ParStr);
//----------------------------------------------------
ClearAll;
cbOffline.Checked := True;
call := '';
time1 := '';
time2 := '';
sname := '';
qth := '';
loc := '';
mhz := '';
mode := '';
rstS := '';
rstR := '';
state := '';
note := '';
pwr := '';

date := dmUtils.GetDateTime(0);
edtDate.Clear;

Try to remove these lines:

ClearAll;

qth := '';

state := '';

Save and recompile and try new binary. It seems that removing only "ClearAll" might be enough.

I can not do that as I have not taken latest complete code from GitHub. And doing that would need some
swapping if I want keep my old 1.9.0 branch still working. And GitHub is......at least when you use it seldom.

I have not been interested anything else than name from fetch information and that has exeption little below:

if sname <>'' then //if user does not give name edtName stays what qrz.com may have found
edtName.Text := sname;
edtNameExit(nil);

So I tought all goes ok to database. Seems that is fool.

But anyhow fetched name should go to database anyhow. That's for sure.

--
Saku
OH1KH

oh1kh
How ever it works

After some other duties I did now little testing how my 1.9.0 really works.

First. If I use QRZ.com info fetch gives just NAME, ITU, WAZ, DXCC ref. Nothing else to newQSO form.
So it is no wonder I say all is ok, as I got just name and it goes to cqrlog DB when qso is logged via wsjt-x's logging.
All is ok.

Then I changed to hamqth.com that I have never used before for info fetch.
From there, with some calls, I got more data. Qth name, full locator, county etc. depending what is typed by the owner of call.
If I log this kind of qso with more data on newQSO-form using wsjt-x's logging ALL data goes to cqrlog.
When I open QSOlist and edit qso all information is back. And it also shows up on QSOlist, too.
Of course if (and because) wsjt-x logging gets 4letter locator from qso it overrides bossible 6letter locator from info fetch.

So all that I previously suspected with removing "ClearAll" from newQSO.pas, wsjt-x decode subroutine #5 seems to be unnecessary. You may try it, but at least 1.9.0 works with it.

Logging problem that I once a while have with 1.9.0 is that program stops to error message of corrupted data and asks "cancel" to stop program or "ok" to continue with possible data loss.
This happens fully randomly.
Mostly when is DXcluster is connected and bandmap is in use (and maybe rbn is connected, too).
Seems to be some kind of buffer overflow that I have not succeeded to find. Or it can be too slow response from internet
as I do have little poor WiFi at hamshack.
If it happens just after pressed OK at wsjt-x logging it prevents qso to go in to cqrlog, but then it means whole qso. Not just fetch data.

When it happens, I have just say OK to error message and then close wsjt-x remote and open it again and relog qso.
Fortunately it happens quite seldom and I have used to live with that.

But that is another subject.

So I raise my hands up what comes to this one in discussion !

Saku
OH1KH

--
Saku
OH1KH

oh1mrr
<p>When I change callsign

<p>When I change callsign lookup into HamQth, I get Tag "&lt;session_id&gt;" not found! In info window. What to do?</p>

<p>Jarmo</p>

oh1mrr
Foud solution. I had some

Foud solution. I had some special chars in my passwd. Changed plain letter/number
now HamQth works in cqrlog..

<p>Jarmo</p>

oh1kh
wsjt-x logging

Hi!

I have spend few days for moving some additions I made for 1.9.0 to 2.0.4.
Including "wsjt-x CQ monitor","Worked locators map","Propagation from dk0wcy" and "PgUp/PgDN" buttons to cwkeys.

Now I'm able to use this version 2.0.4 and already noticed that information from NewQso does not go to log when wsjt-x logging is done.

I will check out why for my next next job.
Be patient...

If someone having x86_64 kernel (for compliled binary. I'll put source to GitHub later) and being active wsjt-x user wants to be a beta tester, mainly for those additions that I have moved , please drop me PM .

Saku

oh1kh
AT
sral.fi

--
Saku
OH1KH

oh1kh
wsjt-x logging

I think I have found reason why QRZ data gets deleted during wsjt-x logging.
Now I have to test it more during weekend.

Curious ones may peek github.com/oh1kh/cqrlog

--
Saku

--
Saku
OH1KH