Topics

locked Wanted State alert doesn't remember that West Virginia is confirmed


Chris Morrison
 

I have JTAlert setup to work with Log4OM v2. Over the past few versions of JTAlert I've noticed I get a lot of alerts for West Virginia.  I discovered that when I scan and rebuild my log it doesn't note West Virginia as a confirmed state on any band. Over the past few days I've been manually un-ticking WV on each band I've confirmed that state in the JTAlert, Wanted US State, Individual bands settings menu. But the next time I run the Rebuild Alert Database it changes West Virginia back to a wanted state.

I thought perhaps it was a problem with my log. But looking at Log4OM v2, in the Awards status window it shows that West Virginia has been validated on 80m through to 15m. So the contacts appear correctly in the log. This problem only happens with West Virginia, no other state.

Any suggestions to where to look next? 

73
Chris
MM1PTT


HamApps Support (VK3AMA)
 

On 16/10/2020 1:10 am, Chris Morrison wrote:
I have JTAlert setup to work with Log4OM v2. Over the past few versions of JTAlert I've noticed I get a lot of alerts for West Virginia.  I discovered that when I scan and rebuild my log it doesn't note West Virginia as a confirmed state on any band. Over the past few days I've been manually un-ticking WV on each band I've confirmed that state in the JTAlert, Wanted US State, Individual bands settings menu. But the next time I run the Rebuild Alert Database it changes West Virginia back to a wanted state.

I thought perhaps it was a problem with my log. But looking at Log4OM v2, in the Awards status window it shows that West Virginia has been validated on 80m through to 15m. So the contacts appear correctly in the log. This problem only happens with West Virginia, no other state.

Any suggestions to where to look next? 

73
Chris
MM1PTT

Chris,

Firstly, don't try and combine manual updates with the rebuild process. All manual changes will be lost when the rebuild is performed. It is a rebuild, not an update operation.

The cause of JTAlert continuing to Alert on WV despite it appearing in your log is due to the Alert rebuild not finding WV qsos in your log with the QSL confirmation type you have set for the State Alert rebuild scan. For example, having the Alert set for LoTW confirmations but your log not containing WV QSOs marked as LoTW confirmed.

One of the JTAlert test team had a similar experience recently, Log4OMV2 log and also with WV log entries. Despite his insistence there were many WV qsos in his log only one band was being shown as no-longer-needed after a rebuild operation. I examined his log file directly and confirmed there were indeed many WV QSOs, but only one band confirmed. All the other entries lacked any QSL confirmations. The problem was within his log, it was not being correctly updated with his confirmations.

This is a defect within Log4OMV2 with respect to WV. I am unaware of any other US States affected. It has previously been reported to the Log4OM devs.

JTAlert will rebuild the Alert database based on your log, if it is inaccurate, than the rebuild will be inaccurate.

If your certain, that your log is correct, use the "Help" -> "Contact Support" menu, on the main JTAlert window, to send me your JTAlert files for analysis, followed by a copy of your Log4OM log file in a separate direct (not to this group) email  and I will take a closer look.

de Laurie VK3AMA




Chris Morrison
 

Hi Laurie, 
I think I've found the problem in my Log4OM log. All the logged contacts with West Virginia have just "Virginia" in the State field. In the County field they all correctly start with WV.
I've filtered my log on the County and modified the State to be West Virginia. Hopefully that's it fixed. I haven't checked if the other states have a similar issue. 
The Log4OM award tracking was correctly showing the States worked so that must use the County field and the not the State field. That was throwing me off where to look for the problem. 

73
Chris
MM1PTT





HamApps Support (VK3AMA)
 

On 16/10/2020 9:09 pm, Chris Morrison wrote:
I think I've found the problem in my Log4OM log. All the logged contacts with West Virginia have just "Virginia" in the State field. In the County field they all correctly start with WV.
I've filtered my log on the County and modified the State to be West Virginia. Hopefully that's it fixed. I haven't checked if the other states have a similar issue. 
The Log4OM award tracking was correctly showing the States worked so that must use the County field and the not the State field. That was throwing me off where to look for the problem. 

73
Chris
MM1PTT

Tnx Chris.

How did  those WV QSO get into your LoG4OM Log? Was it via a previous ADIF import? The previously mentioned WV LoG4OMV2 issues experienced by one of the JTAlert Test Team members, appears to be due to an ADIF import and Log4OMV2 appearing to be broken with respect to the data import (for WV at least).

de Laurie VK3AMA


Chris Morrison
 

Hi Laurie,
They would have got into the log by being saved by JTAlert through the UDP ADIF message on port 2235. There are 14 FT8 contacts with WV, 9 callsigns are unique. Only one contact was had the state correctly set to West Virginia, the rest were Virginia. They all have WV written in the County. 

I have Log4OM set to enrich the real time logging so it could be one of the looks up that is causing the issue. This is probably the same lookup mechanism used when importing a ADIF.

My primary info provider is set to QRZ.com, the failsafe source is HAMQTH.

In the configuration settings CQ and ITU zones are calculated from the following source list:
County file-> CTY Database->Clublog->QRZ.com->Clublog CQ exception->Clublog Callsign Exception

73,
Chris
MM1PTT


Michael Black
 

FYI...I just worked a WV FT8 contact and it did get put into LogOMV2 2.9.0 correctly including the QRZ lookup.

So I think whatever the problem was it's been fixed.
I also imported an older backup ADIF log and it worked too...at least didn't change any WV's to VA.

But the counts don't agree so have to fix the data

Only show 44 QSOs with WV...
sqlite> select count(*) from log where state = 'WV';
44
But lots more counties with WV in them.  Randomly looking up some of the they are all indeed WV QSOs.
sqlite> select count(*) from log where cnty like 'WV%';
258
Only 28 of the 44 have the new CNTY format that includes the state.
sqlite> select count(*) from log where cnty like 'WV%' and state='WV';
28

Here are the older WV QSOs that have the right state but not the new CNTY format which includes the state.
sqlite> select count(*) from log where state='WV' and cnty not like 'WV%';
16

So I used this query to get the qsoid's and update the old 16;

select qsoid,callsign,band,mode,qsodate,state,cnty from log where state='WV' and cnty not like 'WV%' order by cnty
Example update: update log set cnty='WV,Ritchie' where qsoid=20200628040107653;
So now we get this count agreed
sqlite> select count(*) from log where cnty like 'WV%' and state='WV';
44
And now these will need to be corrected.
sqlite3> select count(*) from log where cnty like 'WV%' and state!='WV';
238
I just did a batch change on the ones that showed a WV county but wrong STATE column
sqlite3> update log set state='WV' where cnty like 'WV%' and state!='WV';
sqlite> select count(*) from log where cnty like 'WV%' and state!='WV';
0

All better now.


Mike W9MDB





On Saturday, October 17, 2020, 03:00:22 AM CDT, Chris Morrison <chris.mm1ptt@...> wrote:


Hi Laurie,
They would have got into the log by being saved by JTAlert through the UDP ADIF message on port 2235. There are 14 FT8 contacts with WV, 9 callsigns are unique. Only one contact was had the state correctly set to West Virginia, the rest were Virginia. They all have WV written in the County. 

I have Log4OM set to enrich the real time logging so it could be one of the looks up that is causing the issue. This is probably the same lookup mechanism used when importing a ADIF.

My primary info provider is set to QRZ.com, the failsafe source is HAMQTH.

In the configuration settings CQ and ITU zones are calculated from the following source list:
County file-> CTY Database->Clublog->QRZ.com->Clublog CQ exception->Clublog Callsign Exception

73,
Chris
MM1PTT


Laurie, VK3AMA
 

On 17/10/2020 11:18 pm, Michael Black via groups.io wrote:
Here are the older WV QSOs that have the right state but not the new CNTY format which includes the state.
JTAlert has always logged Counties per the ADIF spec, "StateCode comma CountyName", event when the County name returned from an XML lookup is not of the correct format.

Log4OMV2 has history with bad ADIF parsing. I suspect a previous version was doing some internal magic with the County parsing that screwed up the log entries. Nothing has changed in JTAlert with respect to County logging for a number of years now.

de Laurie VK3AMA