hm, ok. i am using WSJT-X. you are using JTDX. i attached a screenshot, too. So here it works fine.
at the moment i think, it could not be a problem due to JTDX, because the "new mode country" is something internal where cqrlog looks via sql in the database to determine the status of the callsign.
with 2.4.0 FT4 is integrated. maybe do you have leave in menu preferences > Modes > "User defined digital modes" some old entries from 2.3.0 ?
seems we have to debug this. maybe you can start cqrlog in debug mode and send us a log-file.
Hi Saku!
Possibly due to classing FT4 as mode MFSK, I notice that, per band, any previously logged FT4 stations calling CQ appear in CQ-monitor in UPPER case. Normally they should be reported in lower case, as happens in all other modes. Not really a problem, but still a bit confusing!
Robin, 9H1ZZ
Stations that appear in low case letters (FT8,FT4,JT etc). are stations that you have worked with that mode and in the current band.
Stations that are printed UPPER case are stations that you have not worked with current mode and band.
From printing color you can see have you worked them #1)never(then the font is also Bold), 2#)on other band or 3#)on this band but different mode. The 4th color shows you have worked in this band and mode (and then call is also printed in lower case).
With right clik on CQ-monitor you can define the colors.
The upper / lower case was defined for color blind persons to see worked stations more easily that way.
I agree with your definition... that is actually how it does work, except in FT4.
In FT4, everything is reported in UPPER case, even stations worked before in FT4 on the same band.
Easily demonstrated by working an FT4 station correctly and logging it to CQRLOG.
If that same station continues calling CQ, they should now be reported in lower case, not UPPER case.
In all other modes that works as you described.... but not with FT4.
You are using JTDX, are you?
Maybe then you can make that happen. I do not know if JTDX uses nonstandard UDP frame sending mode MFSK and submode FT4 because that is all I can figure out, but not test now.
I am using here cqrlog version date 2022-03-10 (version number has been so long the same that only version date counts)
and wsjt-x v2.5.4
Other possible cause:
If you compare "stone age" ADIF imported FT4 qsos to what you see now in CQ-monitor that can also be reason. "Stone age" means time where cqrlog did not yet set submode FT4 as mode in log but was saving the MFSK there. Then you have to fix all those MFSKs to FT4 with group edit and after that cqrlog finds calls worked before with FT4.
( that came in to my mind when reading the beginning of this thread)
JTDX uses ":" as one letter FT4 mode indicator in UDP frame while wsjtx uses this letter for mode QRA64
Wsjtx mode FT4 indicator is "+" while it means T10 with JTDX, I think.
This is a heck of mess. Why they can not keep any standards. In addition MSHV uses here a string "FT4" or "FT8".
This needs a bigger fix.
RemoteName derived from UDP frame should be passed to MonWsjtx unit so that it could define what mode letters are actually in use.
Hi Saku!
Thanks for your investigations and successful resolution of problem.
I do not have compilation resources (Lazarus, etc) here.
I recall that last time we had a problem (JS8-call) requiring re-compile, you were able to do it for me and sent me a compiled file, which was great!
Can you do the same for me this time too? Thanks.
I run Mint 20.3 on a Intel NUC i3.
I had to test with this. I do not know how you make it happen. It is the same procedure that handles all wsjtx decoding. So there is no difference with mode that wsjtx is using. The UDP logging frame sent to cqrlog is always in same format.
Here look at SQ8AA
Then having a qso with him.
Then qso was done.
Same with PD0WMRÂ and Wsjtx map. He was calling CQ here
And here is qso in final, sending 73 and call is already changed to lower case.
Hi,
yesterday i was working some stations in FT4 on 30m.
Here wsjt-x cq-monitor in cqrlog 2.4.0 (001) works fine.
Did you already work stations in FT4? When not, it is normal that you have "new mode country" information.
Ensure that all your old FT4 Qso's have mode FT4 (and not MFSK or DATA or something else).
maybe you can give us some more details.
Bye DL7OAP, Andreas
Hello Andreas,
I do not find anything special in my settings. attached a screenshot or appears FT4.
73 Didier F1MXE
File:
Hi Didier,
hm, ok. i am using WSJT-X. you are using JTDX. i attached a screenshot, too. So here it works fine.
at the moment i think, it could not be a problem due to JTDX, because the "new mode country" is something internal where cqrlog looks via sql in the database to determine the status of the callsign.
with 2.4.0 FT4 is integrated. maybe do you have leave in menu preferences > Modes > "User defined digital modes" some old entries from 2.3.0 ?
seems we have to debug this. maybe you can start cqrlog in debug mode and send us a log-file.
bye Andreas, DL7OAP
File:
When i am open adi files qso are log in mfsk mode submode ft4.
normal or not ?
File:
Hi!
That is OK and follows ADIF specifications
https://www.adif.org/310/ADIF_310.htm#Submode_Enumeration
--
Saku
OH1KH
Hi Saku!
Possibly due to classing FT4 as mode MFSK, I notice that, per band, any previously logged FT4 stations calling CQ appear in CQ-monitor in UPPER case. Normally they should be reported in lower case, as happens in all other modes. Not really a problem, but still a bit confusing!
Robin, 9H1ZZ
HI Robin!
Stations that appear in low case letters (FT8,FT4,JT etc). are stations that you have worked with that mode and in the current band.
Stations that are printed UPPER case are stations that you have not worked with current mode and band.
From printing color you can see have you worked them #1)never(then the font is also Bold), 2#)on other band or 3#)on this band but different mode. The 4th color shows you have worked in this band and mode (and then call is also printed in lower case).
With right clik on CQ-monitor you can define the colors.
The upper / lower case was defined for color blind persons to see worked stations more easily that way.
See "Cqrlog help/Operating/Digital modes: wsjtx".
--
Saku
OH1KH
Saku,
I agree with your definition... that is actually how it does work, except in FT4.
In FT4, everything is reported in UPPER case, even stations worked before in FT4 on the same band.
Easily demonstrated by working an FT4 station correctly and logging it to CQRLOG.
If that same station continues calling CQ, they should now be reported in lower case, not UPPER case.
In all other modes that works as you described.... but not with FT4.
Robin, 9H1ZZ
AAAHhhhh..
You are using JTDX, are you?
Maybe then you can make that happen. I do not know if JTDX uses nonstandard UDP frame sending mode MFSK and submode FT4 because that is all I can figure out, but not test now.
I am using here cqrlog version date 2022-03-10 (version number has been so long the same that only version date counts)
and wsjt-x v2.5.4
Other possible cause:
If you compare "stone age" ADIF imported FT4 qsos to what you see now in CQ-monitor that can also be reason. "Stone age" means time where cqrlog did not yet set submode FT4 as mode in log but was saving the MFSK there. Then you have to fix all those MFSKs to FT4 with group edit and after that cqrlog finds calls worked before with FT4.
( that came in to my mind when reading the beginning of this thread)
--
Saku
OH1KH
Correct. I am using JTDX(2.2.0-rc152). Thanks for testing.
I will try using wsjt-x myself to check this.
Then maybe look at UDP details of JTDX.
Robin, 9H1ZZ
Hi Robin!
Found that problem.
JTDX uses ":" as one letter FT4 mode indicator in UDP frame while wsjtx uses this letter for mode QRA64
Wsjtx mode FT4 indicator is "+" while it means T10 with JTDX, I think.
This is a heck of mess. Why they can not keep any standards. In addition MSHV uses here a string "FT4" or "FT8".
This needs a bigger fix.
RemoteName derived from UDP frame should be passed to MonWsjtx unit so that it could define what mode letters are actually in use.
--
Saku
OH1KH
Hi !
Not so big change after all. If you can compile from source please test this and give report:
https://github.com/OH1KH/cqrlog/tree/jtdx_fix
--
Saku
OH1KH
Hi Saku!
Thanks for your investigations and successful resolution of problem.
I do not have compilation resources (Lazarus, etc) here.
I recall that last time we had a problem (JS8-call) requiring re-compile, you were able to do it for me and sent me a compiled file, which was great!
Can you do the same for me this time too? Thanks.
I run Mint 20.3 on a Intel NUC i3.
Thanks,
Robin, 9H1ZZ
Hi Robin!
Sent an email to your qrz.com address.
--
Saku
OH1KH
Hi Robin!
Information for you and others interested in this topic: Fix is today added in official source code.
https://github.com/ok2cqr/cqrlog/commits/master
--
Saku
OH1KH
Hi Robin!
I had to test with this.
I do not know how you make it happen. It is the same procedure that handles all wsjtx decoding. So there is no difference with mode that wsjtx is using. The UDP logging frame sent to cqrlog is always in same format.
Here look at SQ8AA
Then having a qso with him.
Then qso was done.
Same with PD0WMRÂ and Wsjtx map.
He was calling CQ here
And here is qso in final, sending 73 and call is already changed to lower case.
I can not see any problem there.
--
Saku
OH1KH