improved support for the Russian District Award


Dave AA6YQ
 

I have developed an application that downloads a list from

https://cfmrda.ru/files/callsigns_rda.cs

and creates an RDA database.

Some entries on the list simply specify the callsign's Oblast and District,

R0AA KK-08

Some entries on the list specify one or more "activation records", indicating that the callsign operated in a particular Oblast and
District during a particular time interval. Activation records prior to 1994 can specify USSR callsigns, e.g.

EK1SK <1991-01-01, 1992-01-31> VO-29

meaning that EK1SK operated from VO-29 from 1991-01-01 to 1992-01-31.

The next version of DXView provides the option to download and install the new RDA database. I will periodically make new versions
of the RDA database available, as I've been doing with the eQSL and LoTW databases, as Joe W4TV has been doing with the DXCC
database, as Tom KQ5S has been doing with the USAP database, and as Dick N3XRU has been doing with the IOTA database.

If the RDA database is present, the next versions of DXView, DXKeeper, and SpotCollector will exploit it; SpotCollector's Spot
Database, for example, includes a new Secondary field that is populated with each active Russian callsign's District code. The next
version of WinWarbler will accepts Secondary Administrative Subdivision information from DXView and SpotCollector.

Up till now, DXLab applications have always derived information from callsigns under the assumption that current prefix-to-location
rules apply. Joe W4TV's "fix scripts" automate the correction of QSOs made under different prefix-to-location rules, but must be
manually invoked. To exploit the "activation records" present in the RDA database, the next version of DXKeeper takes a QSO's "Begin
Date" into consideration when using the Main window's "Log QSOs" tab to log a QSO with a Russian or USSR callsign with "Optimize for
realtime QSO entry" disabled, deriving the DXCC entity, CQ zone, ITU zone, and IOTA tag from the callsign's Oblast and District.

Note that DXLab's "Realtime Award Tracking" has not been extended to support the Russian District Award. Identifying active stations
in needed Districts can be accomplished with a manually-maintained filter in SpotCollector.

The next versions of DXView, DXKeeper, SpotCollector, and WinWarbler have been sent to several users for testing. If you're in hot
pursuit of RDA awards and would like to help test these new versions, please let me know via

aa6yq (at) ambersoft.com

73,

Dave, AA6YQ


 

Dave, 

Thank you for your ongoing and forward thinking work around managing QSO's real time with good informaition.

Mike
KM2B


w6de
 

I am confused by your statement:
". . . To exploit the "activation records" present in the RDA database, the
next version of DXKeeper takes a QSO's "Begin Date" into consideration when
using the Main window's "Log QSOs" tab to log a QSO with a Russian or USSR
callsign with "Optimize for realtime QSO entry" disabled, deriving the DXCC
entity, CQ zone, ITU zone, and IOTA tag from the callsign's Oblast and
District."

In particular the line: . . . with "Optimize for realtime QSO entry"
disabled. This seems to conflict with
https://www.dxlabsuite.com/dxkeeper/Help/Configuration.htm where it says:
When this box is unchecked, DXKeeper's Main window is optimized for manually
entering past QSOs:

In the past I have disabled--realtime QSO entry--only when I was editing my
logbook. Does this mean that the Oblast and District optimizing will only
take place if I manually enter the QSO on the "Log QSOs" tab of DXKeeper?
What about the Capture Window?

In the past year or two, I did run W6TV's scripts on my DXKeeper log.

73
Dave, w6de

-----Original Message-----
From: DXLab@groups.io [mailto:DXLab@groups.io] On Behalf Of Dave AA6YQ via
groups.io
Sent: Tuesday, November 23, 2021 01:03
To: DXLab@groups.io
Subject: [DXLab] improved support for the Russian District Award

I have developed an application that downloads a list from

https://cfmrda.ru/files/callsigns_rda.cs

and creates an RDA database.

Some entries on the list simply specify the callsign's Oblast and District,

R0AA KK-08

Some entries on the list specify one or more "activation records",
indicating that the callsign operated in a particular Oblast and
District during a particular time interval. Activation records prior to 1994
can specify USSR callsigns, e.g.

EK1SK <1991-01-01, 1992-01-31> VO-29

meaning that EK1SK operated from VO-29 from 1991-01-01 to 1992-01-31.

The next version of DXView provides the option to download and install the
new RDA database. I will periodically make new versions
of the RDA database available, as I've been doing with the eQSL and LoTW
databases, as Joe W4TV has been doing with the DXCC
database, as Tom KQ5S has been doing with the USAP database, and as Dick
N3XRU has been doing with the IOTA database.

If the RDA database is present, the next versions of DXView, DXKeeper, and
SpotCollector will exploit it; SpotCollector's Spot
Database, for example, includes a new Secondary field that is populated with
each active Russian callsign's District code. The next
version of WinWarbler will accepts Secondary Administrative Subdivision
information from DXView and SpotCollector.

Up till now, DXLab applications have always derived information from
callsigns under the assumption that current prefix-to-location
rules apply. Joe W4TV's "fix scripts" automate the correction of QSOs made
under different prefix-to-location rules, but must be
manually invoked. To exploit the "activation records" present in the RDA
database, the next version of DXKeeper takes a QSO's "Begin
Date" into consideration when using the Main window's "Log QSOs" tab to log
a QSO with a Russian or USSR callsign with "Optimize for
realtime QSO entry" disabled, deriving the DXCC entity, CQ zone, ITU zone,
and IOTA tag from the callsign's Oblast and District.

Note that DXLab's "Realtime Award Tracking" has not been extended to support
the Russian District Award. Identifying active stations
in needed Districts can be accomplished with a manually-maintained filter in
SpotCollector.

The next versions of DXView, DXKeeper, SpotCollector, and WinWarbler have
been sent to several users for testing. If you're in hot
pursuit of RDA awards and would like to help test these new versions, please
let me know via

aa6yq (at) ambersoft.com

73,

Dave, AA6YQ


Dave AA6YQ
 

+ AA6YQ comments below
am confused by your statement:
". . . To exploit the "activation records" present in the RDA database, the
next version of DXKeeper takes a QSO's "Begin Date" into consideration when
using the Main window's "Log QSOs" tab to log a QSO with a Russian or USSR
callsign with "Optimize for realtime QSO entry" disabled, deriving the DXCC
entity, CQ zone, ITU zone, and IOTA tag from the callsign's Oblast and
District."

In particular the line: . . . with "Optimize for realtime QSO entry"
disabled. This seems to conflict with
https://www.dxlabsuite.com/dxkeeper/Help/Configuration.htm where it says:
When this box is unchecked, DXKeeper's Main window is optimized for manually
entering past QSOs:

In the past I have disabled--realtime QSO entry--only when I was editing my
logbook. Does this mean that the Oblast and District optimizing will only
take place if I manually enter the QSO on the "Log QSOs" tab of DXKeeper?
What about the Capture Window?

+ When you log a QSO with a Russian station via the Capture window, DXKeeper will query the RDA database for that station's location on the current date. 

+ When you log a QSO with a Russian station via the WinWarbler's "QSO Info" panel, DXKeeper will query the RDA database for that station's location on the current date. 

+ When you log a QSO with a Russian station via the Main window's "Log QSOs" tab with "Optimize for realtime QSO entry" enabled, DXKeeper will query the RDA database for that station's location on the current date. 

+ When you log a QSO with a Russian or USSR station via the Main window's "Log QSOs" tab with "Optimize for realtime QSO entry" disabled, DXKeeper will query the RDA database for that station's location on the QSO's "begin" date.

+ Before 1994, stations from "non-Russian" areas of the USSR -- e.g. Lithuania or Kazakhstan -- could make QSOs from Russia using their home callsigns. These QSOs are valid for RDA awards, hence the reason for querying the RDA database when logging a QSO that was made prior to 1994.

73,

      Dave, AA6YQ


w6de
 

Got it.  Since I believe I have already loaded all my Russian/USSR contacts prior to 1994.   I’ll only be manually entering/changing contacts I find still missing or I have entered in error, which nearly 30 years after those QSOs is unlikely.

 

Thank you and 73

Dave, w6de

 

From: DXLab@groups.io [mailto:DXLab@groups.io] On Behalf Of Dave AA6YQ via groups.io
Sent: Wednesday, November 24, 2021 01:03
To: DXLab@groups.io
Subject: Re: [DXLab] improved support for the Russian District Award

 

+ AA6YQ comments below

am confused by your statement:
". . . To exploit the "activation records" present in the RDA database, the
next version of DXKeeper takes a QSO's "Begin Date" into consideration when
using the Main window's "Log QSOs" tab to log a QSO with a Russian or USSR
callsign with "Optimize for realtime QSO entry" disabled, deriving the DXCC
entity, CQ zone, ITU zone, and IOTA tag from the callsign's Oblast and
District."

In particular the line: . . . with "Optimize for realtime QSO entry"
disabled. This seems to conflict with
https://www.dxlabsuite.com/dxkeeper/Help/Configuration.htm where it says:
When this box is unchecked, DXKeeper's Main window is optimized for manually
entering past QSOs:

In the past I have disabled--realtime QSO entry--only when I was editing my
logbook. Does this mean that the Oblast and District optimizing will only
take place if I manually enter the QSO on the "Log QSOs" tab of DXKeeper?
What about the Capture Window?

+ When you log a QSO with a Russian station via the Capture window, DXKeeper will query the RDA database for that station's location on the current date. 

+ When you log a QSO with a Russian station via the WinWarbler's "QSO Info" panel, DXKeeper will query the RDA database for that station's location on the current date. 

+ When you log a QSO with a Russian station via the Main window's "Log QSOs" tab with "Optimize for realtime QSO entry" enabled, DXKeeper will query the RDA database for that station's location on the current date. 

+ When you log a QSO with a Russian or USSR station via the Main window's "Log QSOs" tab with "Optimize for realtime QSO entry" disabled, DXKeeper will query the RDA database for that station's location on the QSO's "begin" date.

+ Before 1994, stations from "non-Russian" areas of the USSR -- e.g. Lithuania or Kazakhstan -- could make QSOs from Russia using their home callsigns. These QSOs are valid for RDA awards, hence the reason for querying the RDA database when logging a QSO that was made prior to 1994.

73,

      Dave, AA6YQ