Statistics from 2024 CQ WW SSB and CQ WW CW logs

A huge number of analyses can be performed with the various public CQ WW logs (cq-ww-2005--2024-augmented.xz; see here for details of the augmented format) for the period from 2005 to 2024.

As in prior years, there follow a few basic analyses that interest me. There is, of course, plenty of scope to use the log files for further analyses, some of which are suggested by the figures below.

Below are some simple analyses of basic statistics from the logs. The 2024 versions of the contests showed more or less normal activity, following several years disrupted by COVID and the invasion of Ukraine by Russia. The latter, of course, is still under way, but its effect on the contest seems to be decreasing. And we 2024 may well turn out to have been the peak of sunspot cycle 25. 

Number of Logs

Until 2020, the raw number of submitted logs for SSB had been relatively flat for several years; the logs submitted for CW showed a fairly steady annual increase. In 2020, unsurprisingly, the number of logs in both modes increased to new record, probably because of the pandemic; CQ WW SSB 2021 set another record; on CW, the number of logs decreased slightly, but would still have been a record were it not for 2020. 2022 was another year of unusual circumstances: not only was the pandemic still in evidence in much of the world, but the Russian invasion of Ukraine, along with the CQ WW committee's vacillation on how to proceed in light of that invasion -- and then the protest against the committee's position as of the contest dates -- was always going to lead to a reduction in the number of submitted logs. In 2024, the numbers for both modes bounced back up somewhat: on SSB they set a new record, but on CW they still fell short of the 2020 peak.

Popularity

By definition, popularity requires some measure of people (or, in our case, the simple proxy of callsigns) -- there is no reason to believe, a priori, that the number of received logs as shown above is related in any particular way to the popularity of a contest, despite rather frequent conclusory statements to the contrary.

So we look at the number of calls in the logs as a function of time, rather than positing any kind of well-defined positively correlated relationship between log submission and popularity (actually, the posts I have seen don't even bother to posit such a relationship: they are silent on the matter, thereby simply seeming to presume that the reader will assume one). 

However, the situation isn't as simple as it might be, because of the presence of busted calls in logs. If a call appears in the logs just once (or some small number of times), it is more likely to be a bust rather an actual participant -- but the situation is complicated: some participants might a handful of contacts, and select only relatively exotic calls for those QSOs. Or perhaps they just worked their friends. Where to set a cut-off a priori in order to discriminate between busts and actual calls is therefore unclear; but we can plot the results of choosing several such values. 

First, for SSB:

Regardless of how many logs a call has to appear in before we regard it as a legitimate callsign, the popularity of CQ WW SSB during the pandemic surely increased from the doldrums of the prior few years. Complicating the picture in the past couple of years is, of course, the reduction in participation that is (presumably) due to the Russian invasion of Ukraine. Whatever the cause, the number of calls certainly seems to be well down on the number at a similar point in the last solar cycle

[I note that a plausible argument can be made that the number of uniques will be more or less proportional to the number of QSOs made (I have not tested that hypothesis; I leave it as an exercise for the interested reader to determine whether it is true), but there is no obvious reason why the same would be true for, for example, callsigns that appear in, say, ten or more logs. The interested reader might also consider basing a similar analysis on eXtended Super Check Partial files as created by the drscp program.]

Moving to CW:

On CW, we see that in 2022 the reduction due (presumably) to the Russian invasion of Ukraine led to the number of active calls being the lowest of all the years for which data are available. In 2023, and again in 2024, there was a slight correction; but the numbers of logged calls are still well short of the numbers during the high-sunspot years of the last solar cycle.

 

Geographical Participation

How has the geographical distribution of entries changed over time?

Again looking at SSB first:

The number of entrants from zone 16 continues to recover, but is still well down from historical levels. The number of logs submitted from zone 28 bucked its recent trend by declining slightly. The number of logs from zones outside EU and the US continues to be very small. This can be seen more clearly if we plot the percentage of logs received from each zone as a function of time:

For a so-called "world-wide" contest, it's not very encouraging.

On CW, most zones evidence a sustained long-term increase:

Again we see the expected drop in entries from zone 16 in the past few (invasion-affected) years, but other than that trends continue more or less as before, with the relative increase spread more or less evenly across all zones, with the percentages of logs from each zone barely changing:

It is, I think, of some interest that the change in participation in zone 28 that is obvious on SSB is only gradually making itself felt on CW. Zone 24 is very slowly becoming more common; but, really, it's hard to argue that there have been any substantive changes apart from the ones resulting from the Russian invasion of Ukraine.

Activity

Total activity in a contest depends both on the number of people who participate and on how many QSOs each of those people makes. We can use the public logs to count the total number of distinct QSOs in the logs (that is, each QSO is counted only once, even if both participants have submitted a log).

For SSB:

  

There were five years in the most recent solar cycle (cycle 24) in which more QSOs were made than in 2024. It doesn't seem likely that the next four years will all result in more QSOs than 2024, suggesting that, possibly for the first time ever, the peak number of distinct QSOs will probably decrease from one cycle to the next.

 
And for CW:

 

A very similar situation holds to that on SSB. It seems plausible that the greying of the amateur radio community is finally taking its toll. I hope not, but I can't say that these graphs bode well for the years to come.

 

Running and Calling

On SSB, the ongoing gradual shift towards stations strongly favouring either running or calling, rather than splitting their effort between the two types of operation, finally appears to have reached some kind of equilibrium. There was essentially no change between 2018 and 2019, and even a (very) slight reversal of the trend in 2020 and 2021. 2022, however, for the first time saw more than 30% of entrants making no run QSOs at all, a situation that continued in 2023. In 2023, the number of stations making fewer than 10% of their QSOs in a run exceeded 60%, a situation that continued in 2024; there is no sign of a reversal in this telling statistic.

I have not investigated the cause of the decrease in the percentage of stations strongly favouring running, although the public logs could readily be used to distinguish possibilities that spring to mind, such as more SO2R operation, more multi-operator stations, and/or a reluctance of stations to forego the perceived advantages of spots from cluster networks. In any case, it certainly seems that SSB operators seem to fall decisively into one of two camps: runners and callers (look at the quite astonishing bimodal distribution in the first of the two graphs above, with the vast majority nearly always calling other stations).

On CW, the split between callers and runners continues to be much less bimodal than on SSB (as mentioned above, on SSB, more than 30% of entrants have no run QSOs; on CW, the equivalent number is below 10%, and shows no sign of rising appreciatively). The difference in call/run behaviour on the two modes (and the difference in the way that the behaviour has changed over time) is profound, and probably worthy of further investigation. CW continues to appear to exhibit what would seem to be a much healthier split between the two operating styles:

Assisted and Unassisted

We can see how the relative popularity of the assisted and unassisted categories has changed since they were introduced:

 

On CW, there is now no longer more or less equal numbers of assisted and unassisted logs: a gap in favour of assisted operation has now definitely established itself. On SSB the unassisted logs handily exceeds the number of assisted logs. My guess, for what it is worth, is that CW assistance is more widespread partly because it (partially) absolves stations from actually being able to copy at high speed, and partly because the RBN is so effective that essentially all CQing stations are spotted.

I find it particularly interesting that the number of CWU logs has remained essentially unchanged ever since the unassisted category was created.

Looking at the number of QSOs appearing in the unassisted and assisted logs:

(The lines are for the median number of logs; the vertical bars run from 10% to 90%, 20% to 80%, 30% to 70%, 40% to 60%, with opacity increasing in that order.)

A long-term downward trend in the numbers of QSOs in the assisted logs ceased in 2016, and since then the median number of QSOs in the assisted logs has remained essentially unchanged. A more or less constant difference of roughly one hundred QSOs between the median CW and SSB logs (in favour of CW) continues.

Inter-Zone QSOs

We can show the number of inter-zone QSOs, both band-by-band and in total. In these plots, the number of QSOs is accumulated every ten minutes, so there are six points per hour.

The new cycle seems to be near or at its peak. Unfortunately, the CW event suffers by occurring a month later in the year than the SSB event. [I do not understand why the CQ WW committee do not alternate the weekends of the SSB and CW modes; but then, I don't understand a lot of what they do or don't do.]

 

Like the two prior years, 2024 saw fairly ordinary 15m participation on SSB, probably because of signs of activity on 10m. CW saw more activity, presumably because, the CW event being later in the year, 10m did not cooperate to the same extent as it did on SSB.

Much less activity on 20m, in both modes.

As always, CW dominates on 40m; and, within that mode, intra-EU QSOs further dominate. After the first few hours of the contest, very little DX was worked in either of the past couple of years.

80m is always dominated by CW; but 2024 evidenced what appears to be a record low level of activity.

160m paints a similar story to 80m, although the raw QSO counts are about half those on the higher band. Like 80m, 160m activity appears to have sunk to a record low -- certainly much lower than at the equivalent point of the last cycle.

The overall picture shows the arrival of Cycle 25; but it seems clear that the ramp-up appears considerably slower in this cycle, perhaps due to the ongoing dampening effects from the invasion of Ukraine.

Unofficial graphical station reports for the CQ WW SSB and CW contests, 2005 to 2024

Graphical versions of unofficial station reports for entrants in the CQ WW SSB and CW contests for the period 2005 to 2024 have been placed in this directory. Note that, unlike the text-only versions, these files are PDFs that are quite sizeable.

Cleaned and Augmented Logs (including RBN data) for CQ WW CW and SSB Contests, 2005 to 2024

Cleaned and augmented versions of the logs for the CQ WW CW and SSB contests are now available for the period 2005 to 2024.

Links to the cleaned and augmented logs may be found in this directory (look for "clean" or "augmented" in the filenames).

The cleaned logs are the result of processing the QSO: lines from the entrants' submitted Cabrillo files to ensure that all fields contain valid values and all the data match the format required in the rules. Any line containing illegal data in a field (for example, a zone number greater than 40, or a date/time stamp that is outside the contest period) has simply been removed. Also, only the QSO: lines are retained, so that each line in the file can be processed easily. All zones are rendered with two digits, so as to further simplify processing by scripts or programs.

The augmented logs contain the same information as the cleaned logs, but with the addition of some useful (derived) information on each line. In addition to the actual logs, two additional sources of information are used when appropriate:

1. AD1C has made accessible historical cty.dat and associated files. These allow us to use callsign-based multiplier lists as they would have existed at the time of each contest.
   
   
2. From 2009 onwards, the Reverse Beacon Network (RBN) has been available for the CW contests. This allows us to include the time since a station was last posted by the RBN (see below for details).

The information added to each line of the augmented logs comprises:

1. A sequence of four characters that are the same for each entry in a particular log:
•  a. letter "A" or "U" indicating "assisted" or "unassisted"
•  b. letter "Q", "L", "H" or "U", indicating respectively QRP, low power, high power or unknown power level
•  c. letter "S", "M", "C" or "U", indicating respectively a single-operator, multi-operator, checklog or unknown operator category [ the contest organisers have stated that checklogs are not made public, but in fact at least some of them from the early years have been, hence the need for the "C" category ]
•  d. character "1", "2", "+" or "U", indicating respectively that the number of transmitters is one, two, unlimited or unknown
2. A four-digit number representing the time if the contact in minutes measured from the start of the contest. (I realise that this can be calculated from the other information on the line, but it saves subsequent script-based processors of the file considerable time to have the number readily available in the file without having to calculate it for each QSO.)
3. Band
4. A set of fourteen flags, each -- apart from column k and column n -- encoded as T/F: 
   • a. QSO is confirmed by a log from the second party 
   • b. QSO is a reverse bust (i.e., the second party appears to have bust the call of the first party) 
   • c. QSO is an ordinary bust (i.e., the first party appears to have bust the call of the second party) 
   • d. the call of the second party is unique 
   • e. QSO appears to be a NIL 
   • f. QSO is with a station that did not send in a log, but who did make 20 or more QSOs in the contest 
   • g. QSO appears to be a country mult 
   • h. QSO appears to be a zone mult 
   • i. QSO is a zone bust (i.e., the received zone appears to be a bust)
   • j. QSO is a reverse zone bust (i.e. the second party appears to have bust the zone of the first party)
   • k. This entry has three possible values rather than just T/F:
     • T: QSO appears to be made during a run by the first party
     • F: QSO appears not to be made during a run by the first party
     • U: the run status is unknown because insufficient frequency information is available in the first party's log
   • l. QSO is a dupe
   • m. QSO is a dupe in the second party's log
   • n. RBN information (see below)
5. If the QSO is a reverse bust, the call logged by the second party; otherwise, the placeholder "-"
6. If the QSO is an ordinary bust, the correct call that should have been logged by the first party; otherwise, the placeholder "-"
7. If the QSO is a reverse zone bust, the zone logged by the second party; otherwise, the placeholder "-"
8.  If the QSO is an ordinary zone bust, the correct zone that should have been logged by the first party; otherwise, the placeholder "-" 

RBN Information

In the CW contests from 2009 onwards, the RBN was active, automatically spotting the frequency at which any station calling CQ was transmitting. To reflect possible use of RBN information, the augmented files now include a fourteenth flag. For the sake of uniformity, this column is present in all the augmented files, regardless of whether the RBN actually contributed useful information to a particular contest.

Each QSO has one of several characters in the fourteenth column of flags. These characters should be interpreted as follows:

'-'
  No useful RBN-derived information is available for this QSO.

'0'
  The worked station (i.e., the second call on the log line) appears to have begun to CQ on this frequency within (roughly) 60 seconds prior to the QSO.

'A' to 'Z'
  For the nth letter of the alphabet: the worked station appears to have been CQing on this frequency for (roughly) n minutes prior to the QSO.

'+'
  The worked station appears to have been CQing for more than 26 minutes on this frequency.

'<'
  Because the the RBN is distributed, and because each contest entrant station has its own clock, there is generally a skew between the reading of the clock of the station making the QSO and the timestamp from the RBN at which it believes a posting was made (indeed, it's unclear from the RBN's [lack of] documentation exactly how the timestamp on an individual RBN posting is to be interpreted). If the character '<' appears in the the RBN column, it indicates that the raw values of the clocks suggest that the QSO took place up to two minutes before the RBN reported the worked station commencing to CQ at this frequency. When this occurs, the most likely interpretation is that there is non-negligible skew between the two clocks, and the station was actually worked almost as soon as a CQ was posted by the RBN. This character also appears if the RBN erroneously posts the worked station as CQing at this frequency shortly after the QSO. But it might also mean that the entrant was simply lucky and found the CQing station just as it fired up on a new frequency.

Notes:

• The encoding of some of the flags requires subjective decisions to be made as to whether the flag should be true or false; consequently, and because CQ has yet to understand the importance of making their scoring code public, the value of a flag for a specific QSO line in some circumstances might not match the value that CQ would assign. (Also, CQ has more data available in the form of check logs, which are generally not made public.)
• I made no attempt to deduce or infer the run status of a QSO in the second party's log (if such exists), regardless of the status in the first party's log. This allows one cleanly to perform correct statistical analyses anent the number of QSOs made by running stations merely by excluding QSOs marked with a U in column k.
• No attempt is made to detect the case in which both participants of a QSO bust the other station's call. This is a problematic situation because of the relatively high probability of a false positive unless both stations accurately log the frequency as opposed to merely the band. (Also, on bands on which split-frequency QSOs are common, the absence of both transmit and receive frequency is a problem; I confess that I have never understood why Cabrillo was not designed to report both transmit and receive frequencies -- or even to define clearly which frequency is to be reported. I digress.) Because of the likelihood of false positives, it seems better, given the presumed rarity of double-bust QSOs, that no attempt be made to mark them.
• The entries for the zones in the case of zone or reverse zone busts are normalised to two-digit values.

Most-Logged Stations in CQ WW CW and SSB Contests: 2024, and the decade from 2015 to 2024

The public CQ WW CW and SSB logs allow us easily to tabulate the stations that appear in the largest number of entrants' logs. For 2024, the ten stations with the largest number of appearances in CQ WW SSB logs were:

Callsign	Appearances	% logs
CN3A	15,857	72
D4C	12,973	63
LZ9W	12,391	60
M6T	12,335	61
P33W	12,206	62
CR3A	12,079	63
9A1A	11,911	59
YT5A	11,585	57
DF0HQ	11,439	58
V26B	11,327	56

The first column in the table is the callsign. The second column is the total number of times that the call appears in logs. That is, for example, if a station worked DF0HQ on six bands, that will increment the value in the second column of the DF0HQ row by six. The third column is the percentage of logs that contain the callsign at least once.

Similarly, the ten stations with the largest number of appearances in CQ WW CW 2024 were:

Callsign	Appearances	% logs
CN3A	15,208	76
CR3A	13,192	73
M6T	13,079	69
CR3W	12,842	70
9A1A	12,546	69
PJ4K	12,238	66
LN8W	11,414	64
YT5A	11,193	63
PJ2T	11,118	60
K1LZ	10,872	58

I find it interesting to see which stations have had the most long-term activity on the contests. For the ten years from 2015 to 2024 on SSB we find:

Callsign	Appearances	% logs
LZ9W	96,329	55
CN3A	93,558	51
DF0HQ	85,830	53
YT5A	82,583	50
M6T	81,170	50
PJ2T	74,644	41
P33W	70,548	44
K3LR	68,256	45
V26B	65,879	39
CR6K	62,368	40

And for the same years on CW: 

Callsign	Appearances	% logs
LZ9W	105,845	66
CR3W	103,850	60
YT5A	99,323	64
PJ2T	93,857	52
9A1A	88,887	54
M6T	86,850	54
TK0C	83,045	49
DF0HQ	78,680	53
RM9A	74,095	48
LN8W	71,662	47

Similar tables from last year may be found here.

Clublog OQRS non-respondents to direct QSL requests

Clublog offers a service, known as OQRS (for "online QSL request service"), whereby one can send a direct request for a QSL to those stations that are willing to accept such requests. As part of the process of sending the request, Clublog automatically connects to Paypal so that the requester can pay the fee that the recipient of the request demands. This can be very useful: it makes requesting, and paying for, direct requests relatively quick and easy.

However, a very few people offering direct QSLs appear to take advantage of the system to collect the money from Paypal without sending the requested QSL.

Generally speaking, when someone whose QSL I desire does not respond to such a request within six months, I will send a polite follow-up e-mail, giving details of the QSO(s), the amount paid and the transaction ID of the Paypal transaction that transferred the money. If I hear nothing after a further three months, I repeat this exercise, but send this last e-mail from a different account, in case the account from which the first e-mail was sent is, for some reason, blocked by the recipient or some intermediate party.

After all this, there is a handful of stations who, in my direct experience, have neither sent the requested (and paid-for) QSL, nor responded to any of the e-mails.

These are the stations that, by my direct experience, have failed to fulfil the obligation to send a responsive QSL (with dates of the request up to the end of 2023):

Year of request          Call

2020                     D3AM
2021                     7X3IOTA
2021                     HC90IARU
2021                     PY0F/PP1CZ*
2021                     5X8C**
2021                     PY0FW
2022                     OH0T
2022                     TI9/3Z9DX***
2023                     CT3MD

* The Paypal payment was reversed by the recipient a couple of months after payment was made. No explanation was forthcoming from the recipient of the money (despite my questioning him via e-mail), and no QSL was ever received.

** A discussion did take place via e-mail, and it was agreed that the QSOs in question had indeed taken place, but there was some doubt as to who was responsible for sending out the requested card. Despite assurances that the issue would be dealt with, no card was ever received.

*** I did receive a responsive e-mail to this request, stating that the QSL would be sent at some future date; as of late January, 2025, however, it has not yet been received. Were it to arrive, I should gladly remove the relevant call from the above list.

I wish to emphasise that the great majority of stations faithfully respond to direct Clublog OQRS requests in a timely manner, and I thank such stations for offering this easy way to obtain their QSLs. This post is made merely so that those experiencing the disappointment of requests that have gone unanswered may see the stations that have likewise disappointed me.

Unofficial station reports for the 2024 CQ WW SSB and CW contests

Unofficial station reports for entrants in the 2024 CQ WW SSB and CW contests have been added to this directory.

A Saga of WAE and DCL

At some point in the last few years, the application procedure for the Worked All Europe award  has been changed, profoundly. In the past, the process was more or less the ordinary one used by many awards: make a list of the cards needed to qualify; have it checked by a couple of local amateurs; submit it to the relevant DARC award manager, along with the fee. This took a bit of time, but was easy and essentially stress-free once the needed cards were in hand.

Recently, I decided that, as I now had the requisite cards, I would apply for the WAE-TOP plaque as described on the WAE page. (I note in passing that, from my location in Colorado, WAE-TOP is considerably more difficult than is 5BDXCC, as if the latter weren't hard enough.) The plaque, I thought, would look good on my shack wall, and would celebrate a feat that is rather difficult from here. So I started out the application process with some enthusiasm; you can imagine as you read what follows how that keenness waned with each roadblock that I encountered.

On the WAE page I discovered that one is now expected to submit one's application "in the Darc (sic) Community Logbook (DCL)". There is a statement that "A traditional application form may be requested in exceptional cases from DF8AA", but, even though it doesn't suggest what might qualify as "exceptional", there was nothing obviously different about my application that would suggest that it would meet whatever those criteria might be. So, "OK", I thought, "if that's what I have to do, that's what I'll do".

Obviously, the first thing to do is to register for DCL. Hmmm... the page is in German (hardly surprising), which I don't read. But there is a Union flag, so I clicked that. Well, a bit of the page is now in English, but most of it remains in German -- although in an oddly inconsistent way.

There is a "Register new account" link, but before doing that, I thought it a good idea to see roughly how the process of submitting a WAE application would work. There's a "Help" tab, and that brings up two sub-items: "Help" (again) and "Logbook Quick Start Guide". The latter sounds promising, so I click on it. Ah! That brings up a complicated sheet written in German -- even though I had clicked the Union flag. OK, click the "Help" instead... and this page appears. Even though the URL (https://confluence.darc.de/display/DX/DCL+-+DARC+Community+Logbook) is in English, the actual page that is displayed is in German. So DCL seems to have forgotten that I had clicked the Union flag... and on the German Help page, there is no flag to click.

Could I have bumbled my way forward? Yes, of course I could. But if such simple functions weren't working in a sensible manner, this did not bode for the more complex interactions that would doubtless be necessary later. So I thought I would communicate with the DCL administrator (Martina, DO8MKR) and see what she had to say.

(Throughout what follows, there were several interactions with DO8MKR. She was unfailingly polite and, clearly, doing her best to help in what are perhaps invidious circumstances. Unfortunately, it quite soon transpired that she was in the position of being forced to defend some very sloppy programming that, in my opinion, should have undergone considerably more testing before being made available, at least to non-German-speaking users. In what follows I omit some details of our interactions because they would not be useful.)

Responding to my suggestion that, even though the Union flag had been clicked, much of what was presented to a user was still in German, she said, "I could not discover any fundamental problems with the British flag", which I interpreted to mean that my expectation that information would be presented in English after clicking the flag did not match the intent of those who created the DCL website.

I then registered on the site, on 25 September. Martina then sent me an e-mail to say that "Your registration was done on 2024-08-17". This made (and still makes) no sense, so I just but put it down to a bug and ignored it, not bothering to raise it as an issue.

I created an ADIF file containing 341 records, corresponding to the QSL cards I had available in support of my application for the WAE-TOP plaque. (I note in passing that, apart from contests, I log on paper; so it took a while for me to create this file.)

In the DCL, one uploads an ADIF file by clicking "Logbook" and then clicking "ADIF-Import"; one then follows the prompts. I did this, but was confused by the result. The lack of useful feedback (in any language), as I later discovered, is endemic in DCL. I had received no indication of an error, and yet when I tried to examine the logbook by clicking on "Search/Manage Log", the logbook seemed to have no QSOs. Unlabelled columns only added to my feeling of hopeless confusion. 

So I wrote to Martina:

I'm unsure what to do next. The attached screenshot shows the "List of Import 
Jobs". It has a red "X" in the rightmost column. I don't know if that matters. 
The column has no header, so I can't tell what is the purpose of that column.

If I go to the "Logbook" page, I don't see any of the uploaded QSOs, so I'm 
not sure whether the upload worked, or, if it failed, what the reason was for 
the failure.

The response (but also see below):

When testing with an adi-Checker, I receive the following error message:
Consistency error on line 1299: Frequency '18' is out of range for band 
'17M'

Therefore no QSOs are uploaded to DCL

 The referenced QSO was (with line numbers added):

  1299    <BAND:3>17m
  1300    <CALL:5>G4AMT
  1301    <FREQ:2>18
  1302    <MODE:2>CW
  1303    <QSL_RCVD:1>Y
  1304    <QSO_DATE:8>20110114
  1305    <RST_RCVD:3>559
  1306    <RST_SENT:3>559
  1307    <STATION_CALLSIGN:4>N7DR
  1308    <TIME_ON:6>163400
  1309    <EOR>

• The "consistency error" (to the extent that there is one) is not on line 1299. That is the first line of the QSO, so there is nothing against which to compare it for consistency.
• The "error" seems to be that line 1301, which defines the frequency to be 18MHz, is deemed incompatible with the band, 17m.

OK, so, technically, 18MHz is not inside the 17m band in any part of the world. But, really... an error? I log on paper, and always log the WARC bands as simply a number of MHz (completely eliding here the issue that the 12m band is a lot closer to 25MHz than 24 MHz). Other systems that accept ADIF files (for example, Clublog and QDURE) , happily accept the QSO, and almost all QSLs I receive for QSOs on WARC bands similarly record the frequency simply as an integral number of MHz -- that is, technically, outside the band. Ultimately, there is no requirement in the specification (that I can see) one way or the other about the consistency of the BAND and FREQ fields, so it's certainly permitted that DCL can impose a constraint that the frequency must be inside the pertinent band. But it certainly doesn't seem very sensible that they do so.

• Even if one holds that the QSO should be rejected, that seems no reason to reject all the other QSOs in the file: "[t]herefore no QSOs are uploaded" (emphasis added).

The "fix", regardless of whether it should be necessary, was easy: move all the frequencies so that they are inside the band. So I shifted 10MHz to 10.1MHz, 18 MHz to 18.1MHz and 24MHz to 24.9MHz. Roughly, and ignoring error processing, one trivial way of doing this would be:

 adif3_field& field { _elements["FREQ"s] };

 if (field.value() == "10"s)
    field.value("10.1"s);

 if (field.value() == "18"s)
    field.value("18.1"s);

 if (field.value() == "24"s)
   field.value("24.9"s);

Uploading the revised ADIF file... still failed. And still without providing any kind of reason.

This time. Martina responded:

After checking again, I have discovered that it was not necessarily due 
to the frequency. I only suspected this... 

It is unfortunate when user-facing support simply guesses as to the reason for a failure; especially when the said support does not hint that the response is only "suspected".

She continued:

However, with your new adi I was still able to add the QSO for you after 
updating the top line. You nead a header line in the adi-file.
Please add <EOH> therefore in the first line.

So we have new advice; the trouble with it is that this produces a file that does not conform to the ADIF specification. (I am the first to admit that the ADIF specification falls far short of the precision that one expects in a professional document; nevertheless, on this point it seems unambiguous.)

Referring to the specification, we see:

IV.A.2. ADI File Structure

An ADI file begins with an optional Header followed by one or more Records:

Header
Record
Record
...
Record

and:

IV.A.3. ADI Header

A Header begins with any character other than < and terminates with a case-insensitive End-Of-Header tag:

<EOH>

If the first character in an ADI file is <, it contains no Header....

It follows directly from these requirements that a file that begins with "<EOH>" is not a compliant ADIF file (1: it begins with "<" and hence contains no header; 2: the "<EOH"> string is an End-of-Header tag, which is within, and marks the end of, a Header... which, by definition, the file does not contain). The example in the specification makes it clear that an "<EOH>" tag is part of the header and, as the text says, "terminates" it.

Nevertheless, having been advised to do so, I recreated the original file (without the altered frequency fields), but inserted the string "<EOH>" as a line at the start of the file (and added a blank line afterwards). The file now began (with line numbers added):

     1    <EOH>
     2    
     3    <BAND:3>20m
     4    <CALL:5>RZ3FW
     5    <FREQ:2>14
     6    <MODE:2>CW
     7    <QSL_RCVD:1>Y
     8    <QSO_DATE:8>20100718
     9    <RST_RCVD:3>449
    10    <RST_SENT:3>559
    11    <STATION_CALLSIGN:4>N7DR
    12    <TIME_ON:6>013800
    13    <EOR>

And, yes! it worked, despite the file's failure to conform to the ADIF requirements.

But some of the QSO data were incomplete on DCL: several of the QSOs were accompanied by an error message:

 "ignored, as tag's value too long (max. 5 characters allowed in DCL)"

It transpired that there is an undocumented limit of 5 characters to the RST_SENT and RST_RCVD ADIF tags imposed by DCL (the ADIF specification imposes no limit). So any entry such as "559/579" or "59 plus 20dB", or anything of that ilk is rejected by DCL.

So I created another non-compliant ADIF file, but with all the RST values limited to strings that DCL would find acceptable, with the intention that this file would represent my application.

In passing, I note that I raised these as issues with Martina, and she promptly responded:

we are currently in the process of reprogramming the DCL. As part of 
this, we will certainly also fix the problems mentioned.
However, this change will certainly take some time.

That at least gave me some comfort that others would not be subjected to the kind of mess that I was dealing with. However, later (see below), she also said:

there will be no more changes to the current DCL (e.g. function for 
deleting QSOs).

So either there will be changes, or there won't. Take your pick.

Going back to the increasingly-wearing application process: at this point now I naturally wanted to delete the QSOs currently in the DCL system, prior to uploading the actual QSOs to be used for the application. There was no obvious indication in DCL as to how to go about deleting data, so I asked Martina (by this time I was, understandably, I think,  beginning to get pretty annoyed at the programming underlying DCL and the lack of user-facing documentation -- at least, English documentation -- for the system). She replied:

... the [delete] function can be found in "im- and export" in the job
list. There is a red X at the right end of each line, which you can use
to delete the corresponding upload.

I had actually already tried that already, but I did it again, in case I had made some error earlier. But no, clicking the (undocumented) red X did not remove any QSOs from the logbook.

Back to Martina again, and this time I received the response:

of course you are right and the variant described does absolutely not 
work in your case. 

She continued:

The red X only deletes the QSOs that are not in confirmed status. As you 
have marked them all as T-QSL, no connections will be deleted. This only 
works for QSOs in status "x", but yours have the status "w" for worked

I'm sorry I didn't think of that at the time.

In this case, I also have no way of deleting the QSOs in our database. 
The only possibility would be to delete all QSOs manually in the logbook.

At this point, I wondered if I was going quietly insane... a logbook system that allows you to add hundreds or thousands of QSOs at a time, but requires you to delete QSOs one at a time? (In fact, it occurred to me that the simplest way to delete a non-trivial number of QSOs might be simply to delete the account, and then create a new one; but, given the experience so far, I guessed that the system might well not allow that, and I was -- at this point -- still sufficiently interested in completing the application process that I didn't want to run that risk.) So I soldiered on and sat in front of the computer for a while, tediously deleting all the QSOs that I had uploaded, seriatim. That at least worked. I then uploaded a clean file (I was going to write "ADIF file", but of course that would be wrong, since it didn't conform to the ADIF specification.) DCL accepted the file (hooray!). But then what do I do?

On the DCL site, I clicked various buttons in an attempt to find something that would tell me what to do next in order to get the system to understand that I wanted to apply for WAE-TOP. I must have done something right, although I didn't see anything that told me that an application had been created, because when I broke down and asked Martina what I needed to do next, she said:

You already have the WAE under "Award Request" - "All Requests".
If you click on the pencil to the right of the request, you will be 
taken to your award request.

 and:

At the top of the page in the blue area, the option "submit application" 
is no longer grayed out.
You can apply for the diploma and contact the diploma manager in the 
Notes section to check your T-QSL.

I didn't really understand that last part, but I found the "submit application" button and pressed it. It was nuclear what that actually did, but at that point I assumed that my application had been entered into the system. (I admit that I still don't understand why the application was present, as Martina pointed out, under "Award Request - All Requests", which, to a native speaker of English means that a request is present in the system, when another step was required. As best as I can tell, the system treats "request" and "application" as two different things, which a lawyer would be tempted to regard as a "distinction without a difference", at least in English.)

Working on the assumption that I had now created a valid request for WAE-TOP, I waited for something or someone to tell me what happens next.

What happened next was that four days later I received an e-mail from DF8AA (Wolfgang), the WAE award manager. So that was good. What was less good was what it said, which was:

I have received your WAE application.
The points are sufficient for the WAE TOP, but many QSOs still need to 
be checked, red in the application.
I see that you are a user of Clublog. It is possible to import confirmed 
QSOs into the DCL. This can make the verification procedure easier.

In the DCL, go to >Logbook > Club log import
follow the further instructions.

We will then see what further steps are necessary.

My first thought was along the lines of, "well, the old system was about as easy as possible; why was that abandoned?" ; and my second thought was, "And if I hadn't ever used Clublog, what happens?" Indeed, I have many physical QSLs for QSOs that are not on Clublog; what if I had needed to use some of those for this application? And that concluding sentence in the e-mail was a bit ominous: I mean, is this process not well-defined, even if it's undocumented? Further, it wasn't at all clear to me how much help Clublog data would be anyway; Clublog doesn't seem, as far as I can tell, to provide a simple way to test whether a collection of QSOs have been confirmed by the other parties, so I couldn't test this thesis, but a priori it seems unlikely that a collection of ~380 QSOs with Europe will have an overwhelming number of confirmations within Clublog.

Of course, I didn't raise any of these issues. Instead, I went to the DCL site and clicked as instructed in the e-mail.

This brought up a DCL page that, among other things, requested my Clublog password! Notice what I said there: this was a DCL request for me to enter a password for a service run by a different entity -- the request did not come from Clublog. There was a word in common use in the 1990s: gobsmacked. That pretty much sums up my reaction to this: do the programmers of DCL seriously expect people to provide them with their passwords for other services? Apparently, they do. (And just as mind-boggling, one can reasonably assume merely from the existence of the request that a non-trivial fraction of people are actually willing to do this. Is it any wonder that computer fraud is a vast, thriving business?) [The question also crossed my mind whether, given the EU's strict data laws, it is even legal for an entity in the EU to require me to surrender a password to another entity in order to use a service of the first entity. I don't know.]

Not being a complete idiot (although I freely admit that sometimes I do a reasonable impersonation of one; but I do try not to make it a lifestyle), I did not "follow the further instructions", per DF8AA's e-mail. Instead, I responded that I would not disclose a password to access my account on another service, and if that was actually a requirement for continuing the application, then I would just give up.

You can tell that by this time I had pretty much reached my breaking point ... how ridiculous is it to replace a process that worked fine for decades with something that is, by any measure, and according to my experience, at least several times as much effort... and following which, even after all this work, I still hadn't reached the point where the application was approved and I could legitimately expect a plaque for my shack wall? Surely, part of sponsoring an award is to make it as easy as possible for applicants, is it not? (Which doesn't necessarily mean mean that every applicant has to use the same process; but it does mean that, having achieved the necessary QSOs and received confirmation of those QSOs, in whatever form, the barrier to submitting the confirmations should be as low as possible.)

I admit that what I hoped for at this point was a statement that I could always just use the old application system, and, indeed, the next e-mail from Wolfgang said:

I also accept a confirmed GCR list.
Nevertheless, it is much quicker to import 210 confirmed QSOs from
Clublog into the DCL than to check each card individually. But anyway,
it's not my time.
Please send the confirmed GCR list as PDF to me.

I can't say that I understood the second sentence, but no matter: at last I was given permission to submit confirmations in the old way. I printed out a list and had a couple of local hams check it and sign the application, and e-mailed it to DF8AA.

And, a month or so later, I received in the mail:

So, in the end it's a happy story. At least, mostly happy. But the experience has certainly soured me on DARC awards. For several years I have been applying for, and receiving, DLD at various levels on 20m, 15m and 10m, all done the old-fashioned way. As long as that is acceptable, I'll continue to do so -- although it's getting harder and harder to find DOKs that I haven't already confirmed -- but I am fearful that at some point DLD may become DCL-only, in which case that will be the end of my fun of working DLs and collecting DOKs and DL QSLs. But for now at least, I can continue to enjoy the chase, and savour every new DOK.