ADIF has revolutionized the way our QSO data can be transferred between different applications.

One problem came up on the N3FJP Software Users forum concerning the export of Field Day QSOs from the N3FJP Field Day software to eQSL. During the discussion it became apparent the ADIF format “mode” variable does not offer values compatible with the Field Day QSO requirements.

As almost anyone knows, Field Day rules only care about Phone, CW and Digital QSOs in their scoring model.

ADIF 1.0 offers these values for the mode variable…

AM, ATV, CLO=CLOVER, CW, FM, PAC=PACTOR, PKT, RTTY, SSB, SSTV, TOR=AMTOR

…and ADIF 2.2.3 offers still more…

AM, AMTORFEC, ASCI, ATV, CHIP128, CHIP64, CLO, CONTESTI, CW, DOMINO, DOMINOF, DSTAR, FAX, FM, FMHELL, FSK31, FSK441, GTOR, HELL, HELL80, HFSK, JT44, JT65, JT65A, JT6M, MFSK16, MFSK8, MT63, OLIVIA, PAC, PAC2, PAC3, PAX, PAX2, PCW, PKT, PSK10, PSK125, PSK31, PSK63, PSK63F, PSKAM10, PSKAM31, PSKAM50, PSKFEC31, PSKHELL, Q15, QPSK125, QPSK31, QPSK63, RTTY, RTTYM, SSB, SSTV, THOR, THRB, THRBX, TOR, VOI

Field Day is a supported contest type in the ADIF 2.2.3 standard.

So the question is if Field Day folds all phone QSOs into the mode ‘PH’ to include SSB, FM, AM why doesn’t the ADIF standard provide a PH mode attribute. N3FJP gets around this issue by offering to change all PH QSOs to SSB during the ADIF export, but this forces FM communications to a mode that it was not.

CW QSOs are supported quite nicely by ADIF.

Then there are the digital contacts. Field Day has no notion of PSK31, RTTY, Olivia, etc. It rolls them all into one mode called digital and dupe checks accordingly.

So, for all practical purposes, a properly stored Field Day exchange only has three values for mode: PH, CW and DIG. Only CW is a valid ADIF mode.

So, ADIF does not support the ARRL Field Day as their contest id attributes suggest.

It is obvious the various contest logging programs are taking liberties with their ADIF outputs and just define the attributes based on the contest’s parameters. Indeed, some programs try very hard to identify and store the actual mode used to make more accurate ADIF outputs even though doing so goes beyond the requirements of Field Day’s PH, CW and DIG modes.

One commenter on the N3FJP forum implied events, like Field Day, should modify their requirements if they don’t comply with standards, like ADIF.

If the standard came first, this would be true.

However, it is the contest that came first in most every case. Certainly Field Day and other ARRL contests define what is the proper information for the exchange, not the other way around.

What we have here is putting the ADIF standard on a high horse when it is, in fact, sub-subservient to the very contests it is meant to support.

The ADIF standard is quite remarkable. It really has solved our interchange issues quite well with just a few remaining nits to iron out.

If the ADIF volunteers will simply add…

…to their list of valid modes, they will finally support Field Day and, perhaps, many other contests that also do not record the specific mode type.

A program is fully compliant with a contest if it fulfills the exchange requirements of that particular contest. No third-party standard should force any additional information be it specific mode, RST, etc. despite how nice it would be to have this information.