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…

PH and DIG

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

3 thoughts on “ADIF Mode Missing PH and DIG

  1. Someone could just manually edit the ADIF file and do a simple find/replace.

    Something like:

    SSB to PH

    FM to PH

    RTTY to DIG (or whatever it should be)

    PSK31 to DIG

    And besides the ADIF standard handling it, all the logging programs would need to change to output the appropriate mode based on the contest.

  2. Eh – last post ate my "code". No preview either so I don't know what will happen with this one.

    Should be like…

    <mode:3>SSB to <mode:2>PH

    <mode:2>FM to <mode:2>PH

    <mode:4>RTTY to <mode:3>DIG (or whatever it should be)

    <mode:5>PSK31 to <mode:3>DIG

  3. David,

    Thank you for posting a comment on HHD.

    Indeed editing ADIF files is reasonably easy to do and your point is valid. However, the point of the article is not if ADIF files can be edited to make PH and DIG Field Day compliant mode values. The point is the ADIF specification does not support PH and DIG as valid modes. Thus, ADIF cannot capture Field Day QSO data properly. Also eQSL, if eQSL is ADIF compliant, is not compatible with Field Day data.

    As for the second comment about logging programs needing to change to output the appropriate mode based on the contest… yes they should and probably already do despite this breaking the ADIF rules.

    For example, N3FJP Field Day software will generate an ADIF file with SSB (if you accept the option it pops up), CW and DIG in the mode field. The DIG mode does not exist in ADIF. However, Field Day only knows DIG in its rules therefore so does N3FJP Field Day logging software. Since the Field Day rules only require the mode to be Phone, CW or Digital, and since Field Day, like most contests, have set these rules long before computers came on the scene, it is the computer and its related attempts at standardization that have the task to accommodate the contest specifics… not the other way around.

    This small problem of Field Day exchange data incompatibility would be eliminated if ADIF added PH and DIG to the modes.

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.