locked "Any Digital Mode" and Wanted Zone


Joe Subich, W4TV
 

Laurie,

I think there is an error in "Any Digital Mode" in Wanted Zones.

It appears that "Any Digital Mode" includes RTTY. However, the
rules for CQ WAZ *exclude* RTTY from "Digital" (there is a separate
award for RTTY).

I noticed DXLab/SpotCollector calling out FT8 spots from my own
JTAlert feed on 30 meters but no alerts from JTAlert. I tracked
it down (apparently) to a RTTY confirmation on that band.

73,

... Joe, W4TV


HamApps Support (VK3AMA)
 

On 14/03/2021 1:57 pm, Joe Subich, W4TV wrote:
I think there is an error in "Any Digital Mode" in Wanted Zones.

It appears that "Any Digital Mode" includes RTTY.  However, the
rules for CQ WAZ *exclude* RTTY from "Digital" (there is a separate
award for RTTY).

I noticed DXLab/SpotCollector calling out FT8 spots from my own
JTAlert feed on 30 meters but no alerts from JTAlert.  I tracked
it down (apparently) to a RTTY confirmation on that band.

73,

   ... Joe, W4TV

Joe,

The "Any Digital Mode" tracking does exclude RTTY if the required checkbox is enabled for the CQ Zone Alert under the "Rebuild Alert Database" section of the Settings window.

   

This has been in place for many years now. If I recall correctly this was first suggested by yourself.

I just now ran some tests. and cannot fault the behavior.
  • With an empty log, I ran the rebuild and all CQ zones were correctly set as needed.
  • A single RTTY QSO was added to the log and the rebuild rerun (without the ignore checkbox ticked). The zone was correctly flagged as no longer need under the "Any Mode" & "Any Digital Mode" sections of the CQ Alert.
  • The JTAlert setting for ignoring RTTY was enabled and the rebuild rerun. The "Any Digital Mode" section correctly changed accounting for the changed setting with the zone being flagged as needed.

My only thoughts as to why JTAlert is not Alerting on a CQ zone that DXLab is is that JTAlert is looking at a different filtered view of your Log compared to what DXLab is using. While the Log file may be the same, if you have multiple myQTH ID available in DXKeeper, you need to ensure that JTAlert is set to use myQTH IDs similar to DXLab. If you have no myQTH IDs set in JTAlert than the entire log is used for the rebuild.

Assuming you have the "Ignore RTTY" checkbox ticked, a search your log will likely uncover a digital mode QSO (not RTTY) for the Band that JTAlert did not alert on.

de Laurie VK3AMA


Joe Subich, W4TV
 

Laurie,

The "Any Digital Mode" tracking does exclude RTTY if the required
checkbox is enabled for the CQ Zone Alert under the "Rebuild Alert
Database" section of the Settings window.
The required checkbox is checked.

My only thoughts as to why JTAlert is not Alerting on a CQ zone that DXLab is is that JTAlert is looking at a different filtered view of
your Log compared to what DXLab is using.
DXKeeper does not filter the log for CQ WAZ - all QTHs count as long
as they are in the same DXCC country. All of my QTHs have been in the
same DXCC country.

Well ... I filtered my DXKeeper log for 30 meters and zone 12 then
examined each digital QSO. Seems DXKeeper missed an eQSL confirmation.
I need to bounce this one back to Dave <G>.

73,

... Joe, W4TV


On 2021-03-15 6:27 PM, HamApps Support (VK3AMA) wrote:
On 14/03/2021 1:57 pm, Joe Subich, W4TV wrote:
I think there is an error in "Any Digital Mode" in Wanted Zones.

It appears that "Any Digital Mode" includes RTTY.  However, the
rules for CQ WAZ *exclude* RTTY from "Digital" (there is a separate
award for RTTY).

I noticed DXLab/SpotCollector calling out FT8 spots from my own
JTAlert feed on 30 meters but no alerts from JTAlert.  I tracked
it down (apparently) to a RTTY confirmation on that band.

73,

   ... Joe, W4TV
Joe,
The "Any Digital Mode" tracking does exclude RTTY if the required checkbox is enabled for the CQ Zone Alert under the "Rebuild Alert Database" section of the Settings window.
This has been in place for many years now. If I recall correctly this was first suggested by yourself.
I just now ran some tests. and cannot fault the behavior.
 * With an empty log, I ran the rebuild and all CQ zones were correctly
   set as needed.
 * A single RTTY QSO was added to the log and the rebuild rerun
   (without the ignore checkbox ticked). The zone was correctly flagged
   as no longer need under the "Any Mode" & "Any Digital Mode" sections
   of the CQ Alert.
 * The JTAlert setting for ignoring RTTY was enabled and the rebuild
   rerun. The "Any Digital Mode" section correctly changed accounting
   for the changed setting with the zone being flagged as needed.
My only thoughts as to why JTAlert is not Alerting on a CQ zone that DXLab is is that JTAlert is looking at a different filtered view of your Log compared to what DXLab is using. While the Log file may be the same, if you have multiple myQTH ID available in DXKeeper, you need to ensure that JTAlert is set to use myQTH IDs similar to DXLab. If you have no myQTH IDs set in JTAlert than the entire log is used for the rebuild.
Assuming you have the "Ignore RTTY" checkbox ticked, a search your log will likely uncover a digital mode QSO (not RTTY) for the Band that JTAlert did not alert on.
de Laurie VK3AMA


Joe Subich, W4TV
 

Laurie,

Well ... I filtered my DXKeeper log for 30 meters and zone 12 then examined each digital QSO. Seems DXKeeper missed an eQSL
confirmation. I need to bounce this one back to Dave <G>.
On second look ... DXKeeper is correct. The eQSL confirmation is
by a station that it *NOT AG*. This it doesn't count for CQ WAZ.

Are you checking the "eQSL.cc member" field in DXKeeper for "A"
(AG status)?

73,

... Joe, W4TV

On 2021-03-15 7:00 PM, Joe Subich, W4TV wrote:
Laurie,

The "Any Digital Mode" tracking does exclude RTTY if the required
checkbox is enabled for the CQ Zone Alert under the "Rebuild Alert
Database" section of the Settings window.
The required checkbox is checked.

My only thoughts as to why JTAlert is not Alerting on a CQ zone that DXLab is is that JTAlert is looking at a different filtered view of
your Log compared to what DXLab is using.
DXKeeper does not filter the log for CQ WAZ  - all QTHs count as long
as they are in the same DXCC country.  All of my QTHs have been in the
same DXCC country.
Well ... I filtered my DXKeeper log for 30 meters and zone 12 then
examined each digital QSO.  Seems DXKeeper missed an eQSL confirmation.
I need to bounce this one back to Dave <G>.
73,
   ... Joe, W4TV
On 2021-03-15 6:27 PM, HamApps Support (VK3AMA) wrote:
On 14/03/2021 1:57 pm, Joe Subich, W4TV wrote:
I think there is an error in "Any Digital Mode" in Wanted Zones.

It appears that "Any Digital Mode" includes RTTY.  However, the
rules for CQ WAZ *exclude* RTTY from "Digital" (there is a separate
award for RTTY).

I noticed DXLab/SpotCollector calling out FT8 spots from my own
JTAlert feed on 30 meters but no alerts from JTAlert.  I tracked
it down (apparently) to a RTTY confirmation on that band.

73,

   ... Joe, W4TV
Joe,

The "Any Digital Mode" tracking does exclude RTTY if the required checkbox is enabled for the CQ Zone Alert under the "Rebuild Alert Database" section of the Settings window.



This has been in place for many years now. If I recall correctly this was first suggested by yourself.

I just now ran some tests. and cannot fault the behavior.

  * With an empty log, I ran the rebuild and all CQ zones were correctly
    set as needed.
  * A single RTTY QSO was added to the log and the rebuild rerun
    (without the ignore checkbox ticked). The zone was correctly flagged
    as no longer need under the "Any Mode" & "Any Digital Mode" sections
    of the CQ Alert.
  * The JTAlert setting for ignoring RTTY was enabled and the rebuild
    rerun. The "Any Digital Mode" section correctly changed accounting
    for the changed setting with the zone being flagged as needed.

My only thoughts as to why JTAlert is not Alerting on a CQ zone that DXLab is is that JTAlert is looking at a different filtered view of your Log compared to what DXLab is using. While the Log file may be the same, if you have multiple myQTH ID available in DXKeeper, you need to ensure that JTAlert is set to use myQTH IDs similar to DXLab. If you have no myQTH IDs set in JTAlert than the entire log is used for the rebuild.

Assuming you have the "Ignore RTTY" checkbox ticked, a search your log will likely uncover a digital mode QSO (not RTTY) for the Band that JTAlert did not alert on.

de Laurie VK3AMA


HamApps Support (VK3AMA)
 

On 16/03/2021 10:07 am, Joe Subich, W4TV wrote:
On second look ... DXKeeper is correct.  The eQSL confirmation is
by a station that it *NOT AG*.  This it doesn't count for CQ WAZ.

Are you checking the "eQSL.cc member" field in DXKeeper for "A"
(AG status)?

73,

   ... Joe, W4TV

No.

The presence or non-presence of a "eQSL (AG)" field in any of the supported loggers is not checked. A station can be eQSL(AG) but not have confirmed the QSO. JTAlert looks for an eQSL specific confirmation field in the log. In the case od DXKeeper, it is the "APP_DXKeeper_EQSL_QSL_RCVD" field.

What does the QSO in question show? Is the
"APP_DXKeeper_EQSL_QSL_RCVD" set but the "AG" field does not indicate they are AG (I don't know its exact name without looking)? If they are not "AG" surely EQSL_QSL_RCVD should not be set. Or does DXKeeper now flag non-AG QSL as EQSL_QSL_RCVD?

de Laurie VK3AMA


Joe Subich, W4TV
 

What does the QSO in question show? Is the
"APP_DXKeeper_EQSL_QSL_RCVD" set but the "AG" field does not indicate
they are AG (I don't know its exact name without looking)? If they are
not "AG" surely EQSL_QSL_RCVD should not be set. Or does DXKeeper now
flag non-AG QSL as EQSL_QSL_RCVD?
<App_DXKeeper_EQSL_RCVD> is 'Y' because the QSO has been confirmed in
eQSL.

<APP_DXKeeper_EQSL_MEMBER> is "Y" because the station is an eQSL member
but has not supplied the necessary documentation for AG status. If the
station would supply the documentation, <APP_DXKeeper_EQSL_MEMBER>
would be "A".

The problem is the eQSL confirmation is not valid for WAZ because the
station is not AG.

DXKeeper has always identified *all* eQSL confirmations as EQSL_QSL_RCVD
= 'Y' consistent with ADIF. DXKeeper only *counts* eQSL confirmations
if EQSL_MEMBER = 'A'.

73,

... Joe, W4TV


On 2021-03-16 11:31 PM, HamApps Support (VK3AMA) wrote:
On 16/03/2021 10:07 am, Joe Subich, W4TV wrote:
On second look ... DXKeeper is correct.  The eQSL confirmation is
by a station that it *NOT AG*. This it doesn't count for CQ WAZ.

Are you checking the "eQSL.cc member" field in DXKeeper for "A"
(AG status)?

73,

   ... Joe, W4TV
No.
The presence or non-presence of a "eQSL (AG)" field in any of the supported loggers is not checked. A station can be eQSL(AG) but not have confirmed the QSO. JTAlert looks for an eQSL specific confirmation field in the log. In the case od DXKeeper, it is the "APP_DXKeeper_EQSL_QSL_RCVD" field.
What does the QSO in question show? Is the "APP_DXKeeper_EQSL_QSL_RCVD" set but the "AG" field does not indicate they are AG(I don't know its exact name without looking)? If they are not "AG" surely EQSL_QSL_RCVD should not be set. Or does DXKeeper now flag non-AG QSL as EQSL_QSL_RCVD?
de Laurie VK3AMA


Laurie, VK3AMA
 

On 18/03/2021 12:06 am, Joe Subich, W4TV wrote:
<App_DXKeeper_EQSL_RCVD> is 'Y' because the QSO has been confirmed in
eQSL.

<APP_DXKeeper_EQSL_MEMBER> is "Y" because the station is an eQSL member
but has not supplied the necessary documentation for AG status. If the
station would supply the documentation, <APP_DXKeeper_EQSL_MEMBER>
would be "A".

The problem is the eQSL confirmation is not valid for WAZ because the
station is not AG.

DXKeeper has always identified *all* eQSL confirmations as EQSL_QSL_RCVD
= 'Y' consistent with ADIF.  DXKeeper only *counts* eQSL confirmations
if EQSL_MEMBER = 'A'.

73,

   ... Joe, W4TV
OK Jo9e.

I was unaware that DXKeeper flagged non-AG QSLs as confirmed.

I will need to extend JTAlert to account for that.

de Laurie VK3AMA