ADIF Mode Missing PH and DIG

The ADIF mode problem

Most everyone knows about the Amateur Data Interchange Format otherwise known as ADIF.

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.

ADIF really doesn’t support ARRL Field Day

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

It’s 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.

ADIF playing god

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 might 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.

The solution is so simple

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.

Revisions

UPDATE 2010:
A long drawn out conversation on the ADIF email reflector yielded no progress on this issue. The points made include requiring logging applications to properly store the particular mode used for phone or digital QSOs (SSB, AM, Olivia, PSK31, etc.). Many do this quite nicely including N1MM and MixW. The fact remains, however, this is the tail wagging the dog. ADIF is in no position to require a QSO be recorded with detail beyond that defined in the rules of the particular event. Continuing the Field Day example, Phone, CW and Digital are perfectly valid QSO mode identifiers… because the event rules say so. ADIF has no support for this so is not fully compatible with legitimate Field Day QSO data. This causes problems when trying to upload to places like LOTW and eQSL since they have also adopted the tail wagging the dog approach. [update 2012 see below] This is unfortunate as ADIF is the only game in town when it comes to QSO data interchange.

UPDATE 2012:
A quick look at the LOTW page suggests Logbook of the World does indeed circumvent the limitations of the ADIF standard and do accept phone and digital contacts with the words PHONE and DATA. It’s not exactly the same as PH and DIG proposed above, but precisely matches the intent. LOTW’s support of Phone and Data as valid ADIF mode values highlights ADIF’s inability to support Field Day and other contests’ QSO mode definitions. Kudos to the ARRL LOTW team for working around the specification limitation by simply ignoring it.