Grid Square logging

[G4POP]

Firstly I would ask you all to upgrade to the very latest Beta release of Log4OM https://www.log4om.com/download/

It is completely stable and includes many enhancements, there is no benefit in sticking with outdated releases.

I have written a document that explains how things work including information about the next beta release additions which you should all read, it is included in the latest user guide Page 53>>>>, entitled 'How Lookup Works'

[k1io]

1) Is JTDX or WSJT-X (I assume they look the same; I use them interchangeably with the same ADI file) the "external source"?

Have you updated your user guide?

External source is the on line lookup service like QRZ, HamQTH etc

2) If I put "external source" on top of the list for both real-time and historic logging, does that mean it will log what JTDX or WSJT-X provides, and only fill in a gap when a grid square is not provided, like on SSB or CW?

Please read the explanation in latest user guide "The information obtained is DISPLAYED in the input screen and in the event of manual or cluster spot lookups will be saved with the QSO."

and

"PLEASE NOTE
When a QSO is in progress in an external program like WSJT etc the Log4OM lookup is only displayed it is not what is saved when the QSO is completed by the WSJT software sending the QSO via UDP
UNLESS the user elects to update the data received in the QSO sent from the external program in the Program Configuration menu"

3) Is there a way to correct incorrect lookups in the past, so that the ADI file overrides the values that Log4OM incorrectly inserted (like on that D2UY example)? Can this be done automatically (batch) on my 4000 or so contacts in the log?

Of course use the QSO manager to bulk edit

4) Did this change in 2.26 or can I leave 2.25 in place for now?

NO! in the first line of my last post I state "Firstly I would ask you all to upgrade to the very latest Beta release of Log4OM https://www.log4om.com/download/"

BETA VERSION 2.26.0.03 is the one you should use and when we release the next Beta update that also.

Before you ask

1. Always backup before updating
2. You dont need to uninstall the original version
3. You should not lose your settings unless you do something wrong, but as above we always reccommend that you BACKUP first

[IW3HMH]

We suggest to use latest beta.
About receiving QSO from "jt world":
if you receive QSO from JT through message 12 (enabled in the relative application section in Log4OM (but will be moved to connection screen) Log4Om will "know" the data is coming from JT application and work accordingly preserving the data in the payload.
If you receive QSO from another application via ADIF message, there will be soon an option to decide what to do with the gridsquare for the specific inbound port, so you can define your own behaviour.

[k1io]

When did this change, or what enables it to keep the grid square data that comes from JTDX intact? Is it the setting I just referred to or did you change something in 2.26 or in a beta?

Grid square, of course, is different from CQ and ITU zone data, as those are not transmitted in the exchange and should be looked up. But one user may operate from more than one grid square, under the same call sign, depending on which QTH he is at, so even if the lookup is usually correct (which is NEVER the case with D2UY, for instance), it can still be wrong. The transmitted square should always be logged.

I don't know if LoTW rejects QSOs with a mismatched grid square but if it does (which would be a reasonable thing to do) this behavior would cause some DXCC contacts and other award entries to be lost!

[k1io]

Here's a screen shot I just took. I will see if upgrading to newer version changes it. He is, of course, identifying his square as JI64.

Log4OMWrongSquare.png (96.37 KiB) Viewed 1866 times

Plus the info providers setting. External source is now first.

Log4OMInfoConfig.png (49.53 KiB) Viewed 1866 times

[k1io]

And after installing the beta, same thing:

Log4OMWrongSquare2-26-3-beta.png (97.59 KiB) Viewed 1865 times

Obviously this is unacceptable for FT8/4 operation and if this can't be rectified, I will have to find a new logging program, which would not make me happy.

[KI5IO]

Fred,

Try flipping CTY and Clublog Priorities. See my arrangement below.

I've also looked up D2UY and get a different grid that you have noted. This is just a manual entry of the OM's call into the Main UI.

[k1io]

Does flipping it simply use a different external database (CTY) rather than Clublog? I am not being picky about the data source used to give D2UY his square; I want WHATEVER square is in the JTDX log to be the one in Log4OM, even if it's out in the middle of the ocean (like he's /MM or something, or simply on vacation not at his listed grid square).

[G4POP]

Going to leave you to it Nolan

[KI5IO]

Does flipping it simply use a different external database (CTY) rather than Clublog? I am not being picky about the data source used to give D2UY his square; I want WHATEVER square is in the JTDX log to be the one in Log4OM, even if it's out in the middle of the ocean (like he's /MM or something, or simply on vacation not at his listed grid square).

Fred,

Just flip to the order I have in my JPG and give it a try.

Why you can't try the suggestions we have given and/or looked in the User Guide for additional explanation is now getting beyond my understanding.