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.
Thu, 2017-01-12 01:26
#1
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
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.
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
Noticed also this, now, when started make some JT qsos...
<p>Jarmo</p>
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
Call comes ok into log, but like name taken from qrz.com
does not appear in log after saving qso..
<p>Jarmo</p>
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
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>
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
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
I do it via wsjt-x logging. Ie via window, which open after I sen last 73
<p>Jarmo</p>
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
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
<p>When I change callsign lookup into HamQth, I get Tag "<session_id>" not found! In info window. What to do?</p>
<p>Jarmo</p>
Foud solution. I had some special chars in my passwd. Changed plain letter/number
now HamQth works in cqrlog..
<p>Jarmo</p>
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
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
The problem is intermittent here. About half qrz info appears in cqrlog and about half is missing.
Is there not a definate solution, or should we use a different log database cuz of the qrz issues....
Thanks to all who helped me get my ft101d connected.
ki4yy
Blair
I see this is a very stale topic. 7 years old. Am i to infer the problems was solved on a different threat or we just dropped it, which would be sad for me as a new but enthusiastic user.
Blair