CQ zone set incorrectly if QSO time/date is locked

[KJ7EHA]

I tried with the call sign you recommended and several other west coast US call signs and am seeing the same behavior.
I do not have any rig control configured or control software installed.

I start up Log4OM and if I do not lock the time/date fields the CQ zone is set correctly.
If I lock the time/date fields and do not edit them at all, the CQ zone is set correctly.
If I edit the times/dates to be some time in the past, the lookup of the west coast call sign is set to 5.
I am attaching the screen shots of the sequence below. The work around for me is that after I save the QSO I then manually edit the QSO and update the CQ field.

[KJ7EHA]

About the comment regarding "locked" and "unlocked" state.

I am calling "locked" the state in which the automated sequencing of time does not occur in the date/time field. I use this state to stop the timer so that I can to manually set a date/time in the past. I notice that this behavior occurs when the background lock icon is set to the color red. Is there something wrong there?

[KI5IO]

About the comment regarding "locked" and "unlocked" state.

I am calling "locked" the state in which the automated sequencing of time does not occur in the date/time field. I use this state to stop the timer so that I can to manually set a date/time in the past. I notice that this behavior occurs when the background lock icon is set to the color red. Is there something wrong there?

Greg,

When the padlock has a "red" background it is UNLOCKED. That is not the default state. That is a warning indicator advising the user that the padlock is UNLOCKED.

[G4POP]

Locked = Locked to computer date and time

Unlocked = Not locked to computer date and time so available for manual input

[KJ7EHA]

QSL! I will change my wording of locked vs. unlocked.

What about the main point tho? That when the date/time is manually updated in the UNLOCKED date/time field, that I am seeing it remain at CQ zone 5 when it should be 3.
But, if I leave the date/time fields locked, or if I unlock them but don't edit any of the values, it works as expected. hmm.

[G4POP]

What about the main point tho? That when the date/time is manually updated in the UNLOCKED date/time field, that I am seeing it remain at CQ zone 5 when it should be 3.
But, if I leave the date/time fields locked, or if I unlock them but don't edit any of the values, it works as expected. hmm.

Non of our team can replicate this so I suggest that you send in a support request so that they can check what is happening to you locally.

Send it by email to the log4om email address please

[KJ7EHA]

I created a video screen capture of the issue I am seeing. I posted at: https://youtu.be/qoMGPshdLYQ (3mins)
I also created a support package .zip which is on my PC, but I don't know what email address to send it to? What is "the log4om email address" I should use?

[IW3HMH]

Hi, that's not an issue of Log4OM.

Log4OM has 2 different approaches to the external sources as data sources.
This is basically because some sources works in realtime, so those works only for "current" QSO, while other sources are able to recover data in the past.

About the callsign you reported, the default REALTIME LOGGING priority for CQ and ITU is:

CTY file
Clublog
ExternalSource (qrz/hamqth/etc)

That means if the CTY has a valid CQ/ITU zone for the callsign, this will win. But CTY file is made to be used for contesting and, generically, for a realtime usage.
That means if your callsign "moved" in the past, the CTY file will provide only data for CURRENT DAY.
This is why, in Log4OM, we have 2 different approaches for "realtime" and "historic" QSO (where historic is all QSO with QSO date different than TODAY)

In the info provider section you can see we give priority to Clublog internal files for HISTORIC qso, then External Sources (QRZ/HAMQTH) and at the very end if nothing is found before, to CTY file. This is mainly because you may have a QSO 10 years old to register and CTY file is not guaranteed for historical QSO's...

Configuration.png (22.82 KiB) Viewed 4844 times

The priority order for sources is up to you. If you raise priority of the CTY source in the HISTORIC qso section, it will be used also for QSO registered in the past over clublog default data.
That is a good solution if you're registering recent QSO's, where CTY file is probably exact (like in your situation). This can create some troubles if you're registering a 10 years old QSO from a DXspedition (if the DXSpedition is not registered into clublog callsign/cq exceptions), but this can be easily changed when you have that needs.

Please note we have a fixed priority on CQ and Callsign exception data from clublog (but those data are rarely available for normal contacts)

Please note "Use CTY database as source for historic ITU and CQ zones" flags must be checked to allow Log4Om work with CTY for Historic QSO on the order you selected.

[NN7D]

We are checking on this. I am able to replicate.

Thanks for reporting.

Doug - W7DRM