Re: improved support for the Russian District Award
|
w6de
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 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
|
|
|