Log4OM

Hi all,

I'm new in the forum, but using Log4OM for more than a year now.

Recently, I started to have problems with bogus grid squares automatically entered into my log. I'm not sure if I changed the settings, or if it is something related to the new version (I only noticed after updating to 2.22.0.0). Here's the problem: Log4OM is adding the wrong grid square to my contacts. I thought the problem could be with info sources (qrz.com, hamqth.com, etc.) but I noticed that even if I delete the grid square from the main panel and leave it blank, a bogus grid square is still added to the log when I save the QSO. Same happens with digital modes: if I didn't get the grid square of a station in a digital QSO (e.g. FT8), the client does not send a grid square to Log4OM, but a bogus grid square ends up appearing in my log.

How can I prevent that? I'd rather have an empty grid square than a wrong one!

I looked into the documentation, and I've read that a center-of-the-country grid square is loaded to the main panel in case the info sources are unable to provide a valid one. That's fine, but I'm not sure that's related to the problem I'm having, as the grid squares are added directly to the log, even when there's nothing in the grid square textbox in the main panel.

Thanks and 73
G5LSI

This isn't new. It also happens with CQ and ITU zones. Like you, I would much prefer to have a blank entry rather than an incorrect one.

73,

Jim N6VH

Leandro & Jim,

D/L and install the current release V 2.22.0.2

If y'all are using V 2.22.0.0 then this would be a couple updates since your current version in use.

The (do some tests) ... Turn OFF using of Clublog and CTY d/b's. Use only an external source of either QRZ.com or HamQTH (or both).

See if that makes any difference.

Be mindful of the sort order (Info Providers/Configuration) when you do have Clublog and CTY d/b's enabled.

I've focused my tests on the "Real Time Logging" and have used either or both QRZ & HamQTH only and found that often the CQ & ITU zones are much more accurate. Understand that there is not "any" perfect d/b so there is that to deal with.

Also many OM's do not fill out the CQ/ITU zone information in their QRZ profiles, etc.. so there will be blanks there as well.

I've been pushing this issue on the Alpha Team support channel for a long time and Lele has made some changes and have appeared to help a bit.

Mind you that inbound data from WSJTx, JTAlert, etc.. is not changed by Log4OM. Whatever is passed from those APPs is what gets stored in that saved QSO.

My testing has focused on simple manual entry of a callsign in the Main UI and/or from a double click on a cluster spot and only in the CW realm.

Give those options/suggestions a try and let us know your results.

Jim, thanks for the solidarity
Nolan, thanks for the suggestions.

I have done a few more tests with v. 2.22.0.0, and then upgraded to 2.22.0.2 as suggested. As far as my tests could go, both behaved the same way with regards to grid squares (I didn't go as far as checking CQ and ITU zones).

>Mind you that inbound data from WSJTx, JTAlert, etc.. is not changed
>by Log4OM. Whatever is passed from those APPs is what gets stored
>in that saved QSO.

This is one of the things I tested. I tried WSJTx and JTDX, one at a time, connected to Log4OM via UDP. And the outcome of the test was the same for both: when logging QSOs without a grid square, a bogus grid square appeared in my log. Here are some examples: I also tested the simple entry of QSOs via main panel, with no input from any external programs, and the same happens. Here is what happens: (1) I type a call sign into the main panel; (2) a grid square is loaded from an info source; (3) I delete the grid square and leave that textbox blank; (4) I save the QSO; (5) the QSO appears in my log with the bogus grid square listed in the second column above.

I don't really understand where the grid squares are coming from, or why. As you can see, they sometimes match the QRZ.com data, but sometimes don't. But the key issue for me is: if there are no grid squares to be added, Log4OM should not be adding them (which is the correct behaviour, as Nolan stated). So I don't really understand what is going on here.

If anyone has any ideas, I'd be glad to hear. Thanks.

Leandro,

Tnx very much for your testing and input. Synchs up with what some of us on the Alpha Team have been noting. However with no Info Providers being selected/enabled you should not be seeing any grid or CQ/ITU data.

I also did some refresh tests with QRZ & HamQTH "disabled". I also made sure that Clublog and CTY d/b's were not enabled.

I then entered a callsign in the Main UI and absolutely no data showed up.

I also then saved that callsign and there was not any data (grid, CQ or ITU) saved with the call.

I had no active connections from any FTxx APPs.

My settings for this test are in images below.

Further testing with my configuration noted above ...

Shows that the 'middle of the region/country' grid square shows up with using the CTY d/b for the Historic lookups when I have QRZ and HamQTH disabled.

When using CTY in the Real Time lookup no data appears.

One additional question: Is your access to QRZ.com a "paid for" (at least) XML access?

Thanks for this, Nolan. Indeed, it was the CTY db that was generating the bogus grid squares. Once I unticked that box, I was able to store QSOs with a blank grid.

Nolan,
I unchecked both the Clublog and cty boxes. Now, no grid is entered, However, incorrect CQ and ITU zones are still being entered, I entered a non-existent USA call, and it put the station in CQ zone 5 and ITU zone 6. Those two are mutually exclusive. I didn't test lookups, because I don't want to use them. There is always the chance of incorrect or missing data there, as well. My point is that if Log4OM doesn't know the correct data, it shouldn't enter any thing. It should leave the box blank. This should be the case whether I am entering the QSO manually from the keyboard, or if it is coming form anther source such as WSJT-X/JTAlert, N1mm, etc. In the recent VHF contest, I was using N1MM, and it was sending the data directly to Log4OM. The grids were being logged correctly, since they were coming from N1MM. However, Log4OM was putting incorrect zones in the log, since they weren't being sent by N1MM. Also, I have noticed that when data is downloaded from LOTW, if no zone is in the other station's LOTW data, Log4OM inputs an arbitrary. zone, even though the correct zone was already there. I downloaded 2.22.02, with the same results.

73,

Jim N6VH

Nolan and others,

I came across this thread because recently I discovered an issue with incorrect grids. I think things may go wrong when the contact does not enter a grid.

So, not sure I am understanding everything I am including two snips of my info providers and info configuration to see if my settings make me susceptible to bogus grids as posted in this thread.

I would appreciate your feedback!

Charlie
W4EBB

Where no grid is available from external sources or software Log4om uses a grid for the centre of the country it's not a bogus grid and is by design and has been so since the inception of Log4om

It's up to the user if they want to turn off use of the CTY file