Re: improved support for the Russian District Award
I am confused by your statement:toggle quoted messageShow quoted text
". . . 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
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.
From: DXLab@groups.io [mailto:DXLab@groups.io] On Behalf Of Dave AA6YQ via
Sent: Tuesday, November 23, 2021 01:03
Subject: [DXLab] improved support for the Russian District Award
I have developed an application that downloads a list from
and creates an RDA database.
Some entries on the list simply specify the callsign's Oblast and District,
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
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