Lotw and JT65A vs JT65

[PB4FUN]

If I have logs in log4om in JT65A, uploaded them to lotw (not by log4om) they are stored as just JT65 in lotw (without the A)
If I do a request in log4om for importing QSL from lotw there is no match. If I alter the qso in log4om to JT65 and try again there is a match.
How can I use some kind of alias where log4om recognises its JT65A as being the same as lotw's JT65 ?

[DF5WW]

Hi "nameless" ....

think there´s no problem with Log4OM. Maybe the problem that your JT65 Software logging "wrong" .... correct is JT65 for ARRL .....

Not shure about this but i mean in the latest configuration file for TQSL the LotW has changed this. So try the latest configuration from the LotW website. If the problem is not resolved with the latest config use the massive bulk editor in L4O, search all "JT65A" and change them to "JT65" that you got correct match from the LotW.

By the way, my JT65A are all logged as "JT65" from WSJT-X ... so this Software use the correct standard.

[PB4FUN]

I already did an update query.
But how am I able to see the difference between the JT65A, JT65B, JT65M and whatever other flavours there are ?

[IW3HMH]

your uploaded log contained JT65A or JT65? because if you uploaded JT65A and LOTW stored JT65 this is a BIG BIG BIG issue (and a stupid choice) that will create a lot of troubles by LOTW system...

and, sincerely, i won't be surprised...

73
Daniele

[PB4FUN]

I uploaded an .adi that contained the mode as JT65A to lotw and it was stored there as JT65 and confirmed because their system found the matching QSO.
The only issue I got with it is log4om does not see the match.

[DF5WW]

Theire system found the matches while it´s confirmed as JT65 but your JT65 Software stored in L4O JT65A/B/C or any other JT65. It is not a problem of L4O it is only a problem of your JT65xxx Software. This 3rd party software send the mode to L4O and not L4O makes the mistake. Use WSJT-X for JT65 and JT-9 with JT-Alert from VK3AMA and you have correct logs and correct matches ...

B.t.w. I always miss a Name in your postings or in a signature .... Not nice to write to a "nameless" guy ...

[IW3HMH]

It's not good that LOTW changes the information we send...
It will impossible to make a match.

Adif 2.x has JT65A, B, C on it: http://www.adif.org/adif227.htm

If LOTW stores his data in JT65 only and replies the same way this means they have changed to ADIF 3.x format without allowing "old" software to be compatible with and, in my knowledge, without announcing that.

This is a really BAD practice, made by the well known guy that is forging ADIF protocol and now LOTW to HIS SOFTWARE NEEDS.

I think there is space for a strong complaint against ARRL for this behaviour. I will open some contacts with other developers to inform ARRL that they are permitting to a single guy to completely put out-of-market a big range of software.

And i think it's time to do, before Dave Bernstein completely divert ADIF from his original destination to an appendix of his software. I'm working on software to deal with this bullshit.

[G4POP]

Don't waste your time Daniel you will just get involved in a lengthy debate with a man that will never admit he is wrong and you will just get screwed up about it.

Many of us have tried over the last ten years on the ADIF group but now we don't waste anymore time and effort on a guy that's on his own self opinionated ego trip.

[PB4FUN]

When I work in JT65A I log JT65A (manual, because CAT makes SSB from it and I am still using 2 logging programs because of the trx power being an integer).
When I export an Adif and sign it with TQSL and upload it to Lotw it is stored there as JT65 (without A)
Uploading the same adif to QRZ.com is stored as JT65A there.
Uploading it to eQSL.cc is stored as JT65.

Lotw sees the match, eQSL does, but QRZ.com and log4OM do not see it as being the same mode.

So how does the procedure go in log4om when fetching data from lotw ?
Are all QSO's being sent as parameter to return a Boolean from lotw or is an adif xml resultset compared on the client ?
If it is compared on the client it might be better to compare the mode with an array of string instead of just one string where the array contains any possible aliases.
If there is no match at all it will also not turn into a match using an alias.

[IW3HMH]

JT65A is a valid value in ADIF 2.x version
Now, with ADIF 3.x the JT65A is not valid anymore. There will be a JT65 MODE and JT65A SUBMODE.
Lotw seems that stores the data in the new 3.x format, and answer with the same logic (without announcing anything anywhere)

I'm now changing the import logic from LOTW (and EQSL, it seems) to upgrade the import from the actual 2.x to 3.x

The thing that made me upset is that the change was NOT ANNOUNCED to anyone. They just switched... this will automatically broke the LOTW import of every software, with evident troubles for users that have older versions... I wonder what happens in HRD 5.x free...