Log4OM

I'm not sure if Log4OM inserted the incorrect data or if it came from WSJTX/JTAlertX. The callsign was entered correctly as was data specific to the QSO. The operator data on the other hand had the address of an amatuer radio club in Ottawa, Canada. A little odd for a guy living in Utah. I have corrected the log entry, so I can't send you an ADIF record that would shed any light. That said, can you shed any light? FWIW I do use QRZ with a paid up account, and the best I can tell this is the only glitch.

Sometimes helps to tell what the call sign was! The correct one and the one JTalert sent to Log4om

The correct one was sent to JTAlert and logged in Log4OM. The associated name and address was wrong. The call sign is N7JCO.

Where are you doing the lookup, in JTAlert or WSJT?

I think initially JTAlert. If WSJT-X does a look up it's using their own sources, as I have not provided any to them. JTAlert has the capability of using my credentials to access QRZ. Log4OM has that same ability. I have been using JTAlert-X longer than Log4OM and they have never screwed up a lookup. Similarly Log4OM hasn't either, but I have a longer history with JTAlert-X. Whoever entered the wrong data, I am confident this is just a one off, and I'm hoping to discover what went wrong. I have no interest in assigning blame.

Hi Dan,

Hamapps has a fcc_lotw_eqsl.sqlite file in the Hamapps folder. I checked
that there is N7JCO with the state of UT and another entry for N7JCO/VE5.
Could it be possible that you worked the /VE5 call ?? If yes it could be
possible that you have logged the wrong call if you do another click on a decode
in the QSO. The /VE5 you will see only in first decode in each other the call
will be used without /VE5 and if you do another click you will overwrite the
correct call. So the station will be logged without /VE5 but with the Canadian
adress.

Only an idea. But this is not a Log4OM problem, it´s a JTalert-X problem.



Log4OM grabs only from hamqth or qrz.com or using some data from clublog
and the Lotw Database but the adress of N7JCO are correct on all those
services. So Log4OM will receive only the correct data when it looks for the
call.

Nope. I didn't work the /VE5. I looked at WSJT-X's all.txt, and found the QSO. The only call mentioned in the text was N7JCO. Thanks. I'll bump this to Laurie.

I took a look at JTAlerts fcc_lotw_eqsl.sqlite file and found the N7JCO in Utah, but no N7JCO/VE5. So the data didn't come from there. I am using the latest (July 3rd, 2017) version of the database.

I think the problem really came with WSJT-X. I am using their Beta software, and there are some bugs. I had one this morning that logged the wrong QSO instead of the one I just worked. At this point, I will let the Beta process play out, and chalk this up the hazards of using Beta SW. My data has been corrected and I just need to keep an eye on it. Thanks for your help.

Hi Dan,

my mistake. I have checked the database again and there is no N7JCO/VE5. There is only another N7J../VE5.
But in fact the wrong adress don´t comes from a Log4OM lookup, there must be a bug in WSJT-X or in JTAlert-X.

B.t.w. i´m using the latest WSJT-X beta too to check out the new FT8 mode. I don´t have had trouble with wrong
logging but i don´t do a lookup from WSJT-X and or JTalert. I only let JTalert log to Log4OM and later i open the
contacts without names and/or adresses and hit the update button in the Edit window. So i got missed Data by
Log4OM lookups at HamQTH.

In my case the error was caused by WSJT-X and recognized as their problem.
73 - Dan