Add support for ARRL DX Contest

[w7sst]

Contest information

• Contest Name: ARRL DX Contest
• Contest Rules: https://www.arrl.org/arrl-dx
• Call History file name: ARRLDXCW_USDX.txt

Unique contest behaviors

• Contest exchange: W/VE stations send a signal report and their state or province. (See the ARRL Contest Multipliers List for a list of abbreviations.) DX stations send a signal report and power as a number or abbreviation.

Additional information

• It would be nice if user could pick DX-side or US-side for this contest. Perhaps with a checkbox, or two call history files, one for DX and one for US. Or, a checkbox in a setting dialog (which we don't have yet).

Can you help?

Please let us know if you are available to help. (replace '[ ]' with '[x]' to affirm)

• Yes, I'm available to discuss questions or alternatives regarding the implementation of this contest.
• Yes, I'd like to review and provide feedback on the proposed solution.
• Yes, I'm available to help test this contest. Let me know when it is ready for early testing.

[w7sst]

In a recent email, Larry, F6FVY, added:

Please, don't stay too much US-centric, and consider other major "international" contests, like CQWW (I see it's on your todo list, great!), ARRL DX (especially DX side), IARU HF etc.

[f6fvy]

It would be nice if user could pick DX-side or US-side for this contest

Actually your own callsign should be enough to decide MR what side you're on, assuming MR can lookup what DXCC entity you're in. And if I may, MR should better rely on the AD1C CTY files (https://www.country-files.com/) which are regularly updated, rather than a new proprietary file ARRL.LIST.

[w7sst]

It would be nice if user could pick DX-side or US-side for this contest

Actually your own callsign should be enough to decide MR what side you're on, assuming MR can lookup what DXCC entity you're in. And if I may, MR should better rely on the AD1C CTY files (https://www.country-files.com/) which are regularly updated, rather than a new proprietary file ARRL.LIST.

Hi Laurent, I like this idea of using the user's callsign to determine which side of the DX they are on. Yes, our MR does that the ability to look up current entity or continent using ARRL.LIST file. I also like the idea of looking into the CTY files as an alternative.

I am hoping to work on this contest next and a release by the mid- to late-November in time for the February contest. This contest will be very usable to alot of users.

Thank you again for your input and welcome to our project. It's good to have you.

[f6fvy]

Please correct the link for the Call History file name which is https://n1mmwp.hamdocs.com/mmfile/get/file/ARRLDXCW_USDX.txt (the current link leads to the IARU HF file).

[w7sst]

Please correct the link for the Call History file name which is https://n1mmwp.hamdocs.com/mmfile/get/file/ARRLDXCW_USDX.txt (the current link leads to the IARU HF file).

Fixed. Thank you.

[w7sst]

Words of Wisdom from Larry, F6FVY (taken from an email response dated Oct 14, 2022)...

Hi Mike
Tnx for your reply and the valuable informations.

Le 14/10/2022 à 19:30, Mike Brashler a écrit :

My early thinking was that a contest has two exchange fields -- this turned out to not always be true. Thus, my thinking will have to evolve as we generalize the notions of Contests and Exchange handling. The ContestDefinition table is currently using two fields, and this is working for contests with two exchanges (which covers most contests).

It is also necessary to take into account the contests in which the exchanges are not the same according to the entrants.

For example, ARRL 10m (december):

• US (KH6 and KL7 included) + VE send States/Provinces
• /MM send IARU Region (can be considered as "fixed exchange" like US/VE)
• Others (called DX stations) send serial numbers !

And everyone can work everyone, so MR will have to handle the correct exchange !

Finally, regarding the number of exchanges fields, the ARRL sweepstates uses 4 of them : Serial number + Precedence + Check (year of licence) + ARRL/RAC section. Good luck with that ;-) And there is NO RST.

My head hurt when it has been implemented in Win-Test !

73
Larry - F6FVY

Larry is correct. My initial thinking for contest exchanges was fixed with only two exchange types, one for each exchange field. However, Larry points the error in my thinking.

Thus the rules for determining contest exchanges are determined by:

1. The contest itself - Each contest has specific exchange rules with two exchange fields (Exch1 and Exch2). (my original thinking)
2. The user's location - The user's callsign is used to determine if the user station is local-to-the-contest or considered as DX-to-the-contest. Depending on station location (relative to the contest), the exchange types can change.
3. The DX station's location - The station being worked can also qualify the exchange type. For example, ARRL 10m contest can have three different exchange types, depending on sending station's location.

ARRL 10m contest rules state:

• US (KH6 and KL7 included) + VE send States/Provinces.
• District of Columbia stations send 'DC'.
• Mexican stations send their state or province.
• /MM send IARU Region (can be considered as "fixed exchange" like US/VE)
• Others (called DX stations) send serial numbers !

So this means a contest can have a set of possible exchange types. The current table definition is fixed with one type per exchange field. Looks like I need to extend this to support multiple. Hmmm, I have to think more about this.

This also implies that there are multiple station locations relative to contest: local, remote, region1, region2. So perhaps a contest has a set of locations, and each location has a corresponding set of exchange types. So for ARRL10M, the locations include (US/CA,HI,AK,DC,Mexico,MM,DX) with corresponding exchange types (state/prov, 'HI', 'AK' 'DC', Mexican state/prov, IARU region, serial number). A user's call, including the home station, can be in any of these regions. If the home call is located in a DX region, the the serial number will increment when it is being sent. The current design of etSerialNumber will work for this.

For now, this means that the sending station (e.g. DxStation), based on it's location, determines what is being sent. Thus, the receiving exchange fields (Exch1 and Exch2) must expect and validate the entered exchange information based on what the sending station is sending. The station's location determines what it sends. So my design idea of using the base class TStation to contain the sending exchange type is still valid, even with the complexity of dynamic exchange types based on the remote DxStations location (e.g. 10m contest can have exchange types of State/Prov, DC, Mexican State/Prov, IARU region for /MM, and serial numbers for Dx stations).

@f6fvy - Thanks again for your words of wisdom in your email from two weeks ago. I finally (today) got my head around what you are saying. Btw, I have ARRL DX contest starting to run and am now finalizing the design of handling dynamic exchange types based on station location. I will include you in code review(s) as I get closer to checking in some of this code. 73, Mike.