Amateur Data Interchange Format 1.0

(ADIF)

Specifications

Ever since software has become a part of amateur radio, there have been as many data formats as there have been ham radio software programmers. Hams have struggled with converting data among various formats. Several hams have been discussing such a standard via an Internet discussion. In early 1996 KK7A promoted the idea of a standard for exchange of ham data. An internet reflector was set up for discussing such a standard. WF1B and WN4AZY, as publishers of commercial ham radio software, have taken the best suggestions from this discussion and formed a proposal. Ray introduced it at the 1996 Dayton hamvention. Within a year, this proposal has adapted adopted by most software publishers. We wish to thank everyone who has contributed to this effort.

ADIF is infinitely extensible--it will never be outgrown. It can handle binary as well as text data. New data elements may be added to this specification without "breaking" older implementations. It may be easily programmed in any language. The data itself is easily read by eye, and may implemented so as to be transferred via Internet without any encoding.

 

Purpose:

Provide a standard interchange independent of operating system or programming language for amateur data that will permit easy and direct transfer of data conforming to the standard between various amateur programs as well awards and contest sponsors.

 

Data to be Interchanged:

The ADIF standard must not be limited to log data. It should incorporate other categories such as awards multiplier lists, packet spot data, contest rules, etc., and must be expandable to incorporate any new type of data that may appear in the future as the hobby grows and changes. However, as of version 1.0, only specifications for log data have been implemented. Anyone wishing to interchange other types of data will still find these specifications helpful. All that is necessary to transfer other types of data is to apply to ADIF a definition of fields and records to be transferred.

 

ADIF components:

ADIF consists of three components:

1. Physical specifications--a specification of how fields and records are stored.

2. Field type definitions--Specification of how a particular type of data is stored. For instance, DATE should be stored with ASCII characters in the format YYYYMMDD. Examples of other possible data types are Numeric, Windows .BMP picture, binary data containing unspecified non-textual data, or freeform text containing multiple lines.

3. Field definitions--a list of data elements (Call, QSO Date, DXCC country, etc.), and a description of valid values. Each field has a name that is from one to ten characters long. The field name may include the characters A-Z, 0-9, and _, but must begin with a letter. (This is for easy transfer with xBase and other popular existing data formats).

4. File definitions--a description of a category of data. For instance, log data is defined as all data resulting from a QSO, including exchanged info plus any data related specifically to a QSO, such as band/mode, comments, traffic exchanged during the QSO, awards tracking info, and contest scoring info. A category will include a list of fields supported by the ADIF standard for each category. Each record in the file will contain one or more of the supported fields.

Additional fields that are not part of the ADIF specification for the file may be added by those creating ADIF files. This will permit export of user-defined fields. However, there is of course no guarantee that these undocumented fields will be imported by a program reading ADIF files, or that a chosen name may not be used for another purpose and imported into the wrong field in future ADIF specifications. Therefore, creators of ADIF files are encouraged to cooperate when adding new fields to so as to derive maximum benefit from ADIF.

 

1. Physical Specifications:

Each data field is preceded by a field name and length enclosed in angle brackets. The name and length are separated by a colon. The field name may be in upper, lower, or mixed case. Case is insignificant. For instance, CALL, Call, or call are equivalent. The length specification is ASCII text in display format, and may be of any non-negative value. The data follows the closing angle bracket. For example:

<CALL:6>WN4AZY

 

Records are made up of multiple fields and terminated with <EOR> or <eor> as an end-of-record marker. For example:

<call:6>WN4AZY<band:3>20M<mode:4>RTTY<qso_date:8>19960513<time_on:4>1305<eor>

 

An optional field type indicator may follow the field length, separated by a colon: For example:

<qso_date:8:d>19960513

 

The field type indicator may be in upper, lower, or mixed case. A field type indicator is optional. For instance, the Field Definition for QSO_DATE specifies that the field is always of type Date, so it is not necessary to repeat it here. However, when exporting user-defined fields that are not part of the ADIF specification, a type indicator will assist anyone attempting to import the data.

Any number of characters of any value except < may be added after a field’s data or <eor> and before the start of the next field. This is typically carriage returns and/or line-feeds to make the file easier to read in a text viewer. For example:

<call:6>WN4AZY<band:3>20M<mode:4>RTTY
<qso_date:8:d>19960513<time_on:4>1305<eor>

<call:5>N6MRQ<band:2>2M<mode:2>FM
<qso_date:8:d>19961231<time_on:6>235959<eor>

 

In this example, a new line is inserted in the middle of each record, and two newlines are inserted at the end of each record. This makes long records easy to read in a text editor.

Optional header information may be included before the actual data in the file. To include optional header info, the first character of the file must be something other than <. Any amount of header info of any value except <eoh> may be included. The header info must be terminated with <eoh>. Any number of characters of any value except < may follow <eoh>. The first < after <eoh> is the start of the first field of the first data record in the file. Here is an example:

this data was exported using WF1B RTTY version 9, conforming to ADIF standard specification version 9.99<eoh>

<call:4>aa1a...

If the first character of a file is <, it is presumed to be the first field of the first data record.

The ADIF version may be included in the header info as follows: <adif_ver:4>1.00 is included as part of the header specification, an importing program can easily determine the ADIF version used to create the file. Note that this must not be at the beginning of the header info, because < as the first character indicates that there is no header.

It is important for the programmer importing ADIF data to note that any number of characters of any value may follow the actual data in a field. For example, carriage return/linefeed, or just a line feed. There is nothing in the specifications to prevent an exporter from placing a comment after the actual data. Therefore, after reading a field’s data based on the length specification, the programmer should read and discard characters until the start of a new field (<) or <eor> is encountered.

There is no specification for the order in which fields appear. They may appear in any order. Unused fields may be omitted entirely. Therefore, each record will not necessarily have the same fields. The specification does not prohibit a zero-length field, so those writing import programs should allow for this.

There is no specification for field length or maximum field length in the Physical Specifications. Unless there is a length specification in the Field Definition, exporters simply export all data in their field. Importers import as much data as their program can accept.

Note that while these examples have all been of simple ASCII fields, the specification permits data of any type or length. It could be easily used to transfer pictures or text documents, for instance.

 

2. Field Type Definitions:

Type

Description

Date A date specification in YYYYMMDD format
   
Time A time specification. May be 6 characters long (HHMMSS) if seconds are included, 4 characters (HHMM) if seconds are not included. Time is in 24-hour format, from 0000 to 235959. A zero-length field or omission of the field indicates an empty time value.
   
M Multi-line text field. For xBase MEMO and similar data.
   
C (Character) So far everyone who has written an export program has not specified a type for character data. However, it is included in the specifications for consistency.

 

3. Field Definitions:

Name Type Comment
ADDRESS M As it will appear on the mailing label
AGE N  
ARRL_SECT C  
BAND C 160M, 80M, 40M, 30M, 20M, 17M, 15M, 12M, 10M, 6M, 2M, 70CM,23CM...see table below
CALL C  
CNTY C US County in the format STATE,COUNTY. For example GA,BARROW. Use CQ County list
COMMENT C Comment field for QSO
CONT C Continent: NA,SA,EU,AF,OC,AS
CONTEST_ID C Contest Indentifier -- SS, ARRLVHF, ARRLDX, etc.
CQZ N CQ Zone
DXCC N Numeric identifiers from ARRL. See table below
FREQ N in Megahertz
GRIDSQUARE C 4, 6, or 8 or however many characters
IOTA C HYPHEN MUST BE INCLUDED. Example: NA-001 IOTA PROVIDES DISK IN THIS FORMAT
ITUZ N ITU Zone
MODE C SSB,CW,RTTY,TOR,PKT,AM,FM,SSTV,ATV,PAC=PACTOR,CLO=CLOVER
NAME C  
NOTES M Long text for digital copy, third party traffic, etc.
OPERATOR C Callsign of person logging the QSO
PFX C WPX prefix
PROP_MODE C  
QSLMSG M Personal message to appear on qsl card
QSLRDATE D QSL Rcvd Date
QSLSDATE D QSL Sent Date
QSL_RCVD C Y=Yes, N=No, R=Requested, I=Ignore or Invalid
QSL_SENT C Y=Yes, N=No, R=Requested, I=Ignore or Invalid
QSL_VIA C  
QSO_DATE D YYYYMMDD in UTC
QTH C  
RST_RCVD C  
RST_SENT C  
RX_PWR N Power of other station in Watts
SAT_MODE C Satellite Mode
SAT_NAME C Name of satellite
SRX N Received serial number for a contest QSO
STATE C US state
STX N Transmitted serial number for a contest QSO
TEN_TEN N  
TIME_OFF C HHMM or HHMMSS in UTC
TIME_ON C HHMM or HHMMSS in UTC
TX_PWR N Power of this station in watts
VE_PROV C 2-letter abbreviations: AB, BC, MB, NB, NF, NS, NT, ON, PE, QC, SK, YT

Band designations:

Band Frequency
160m  
80m  
40m  
30m  
20m  
17m  
15m  
12m  
10m  
6m  
2m  
1.25m 220MHz
70cm 432
35cm 902
23cm 1300
13cm 2300
9cm 3300
6cm 5660
3cm 10000
1.25cm 24000
6mm 47 GHz
4mm 75
2.5mm 120
2mm 142
1mm 241
   

 

DXCC country codes:

Handling transfer of DXCC(tm) country info has been a common problem due to lack of an official list. The ARRL maintains everyone's DXCC status using numeric codes. We have adopted their codes for ADIF transfer of data. We wish to thank the ARRL for making this list available.

Code Country Deleted
1 CANADA  
2 ABU AIL IS Y
3 AFGHANISTAN  
4 AGALEGA & ST BRANDON  
5 ALAND IS  
6 ALASKA  
7 ALBANIA  
8 ALDABRA Y
9 AMERICAN SAMOA  
10 AMSTERDAM & ST PAUL  
11 ANDAMAN & NICOBAR IS  
12 ANGUILLA  
13 ANTARCTICA  
14 ARMENIA  
15 ASIATIC RUSSIA  
16 AUCKLAND & CAMPBELL  
17 AVES ISLAND  
18 AZERBAIJAN  
19 BAJO NUEVO Y
20 BAKER, HOWLAND IS  
21 BALEARIC IS  
22 BELAU (T8)  
23 BLENHEIM REEF Y
24 BOUVET  
25 BRITISH N. BORENO Y
26 BRITISH SOMALI Y
27 BELARUS  
28 CANAL ZONE Y
29 CANARY IS  
30 CELEBE/MOLUCCA IS Y
31 C KIRIBATI  
32 CEUTA & MELILLA  
33 CHAGOS  
34 CHATHAM IS  
35 CHRISTMAS IS  
36 CLIPPERTON IS  
37 COCOS ISLAND  
38 COCOS-KEELING IS  
39 COMOROS (FB8) Y
40 CRETE  
41 CROZET  
42 DAMAO, DUI Y
43 DESECHEO IS  
44 DESROCHES Y
45 DODECANESE  
46 EAST MALAYSIA  
47 EASTER IS  
48 EASTERN KIRIBATI  
49 EQUATORIAL GUINEA  
50 MEXICO  
51 ERITREA  
52 ESTONIA  
53 ETHIOPIA  
54 EUROPEAN RUSSIA  
55 FARQUHAR Y
56 FERNANDO DE NORONHA  
57 FRENCH EQ. AFRICA Y
58 FRENCH INDO-CHINA Y
59 FRENCH WEST AFRICA Y
60 BAHAMAS  
61 FRANZ JOSEF LAND  
62 BARBADOS  
63 FRENCH GUIANA  
64 BERMUDA  
65 BRITISH VIRGIN IS  
66 BELIZE  
67 FRENCH INDIA Y
68 SAUDI/KUWAIT N.Z. Y
69 CAYMAN ISLANDS  
70 CUBA ADIF:CM  
71 GALAPAGOS  
72 DOMINICAN REPUBLIC  
74 EL SALVADOR  
75 GEORGIA  
76 GUATEMALA  
77 GRENADA  
78 HAITI  
79 GUADELOUPE  
80 HONDURAS  
81 GERMANY Y
82 JAMAICA  
84 MARTINIQUE  
85 BONAIRE,CURACAO  
86 NICARAGUA  
88 PANAMA  
89 TURKS & CAICOS IS  
90 TRINIDAD & TOBAGO  
91 ARUBA  
93 GEYSER REEF Y
94 ANTIGUA & BARBUDA  
95 DOMINICA  
96 MONTSERRAT  
97 ST LUCIA  
98 ST VINCENT  
99 GLORIOSO IS  
100 ARGENTINA  
101 GOA Y
102 GOLD COAST/TOGOLND Y
103 GUAM  
104 BOLIVIA  
105 GUANTANAMO BAY  
106 GUERNSEY  
107 REPUBLIC OF GUINEA  
108 BRAZIL  
109 GUINEA-BISSAU  
110 HAWAII  
111 HEARD IS  
112 CHILE  
113 IFNI Y
114 ISLE OF MAN  
115 ITALIAN SOMALI Y
116 COLOMBIA  
117 ITU GENEVA  
118 JAN MAYEN  
119 JAVA Y
120 ECUADOR  
122 JERSEY  
123 JOHNSTON IS  
124 JUAN DE NOVA  
125 JUAN FERNANDEZ  
126 KALININGRAD  
127 KAMARAN IS Y
128 KARELO-FINN REP Y
129 GUYANA  
130 KAZAKHSTAN  
131 KERGUELEN  
132 PARAGUAY  
133 KERMADEC  
134 KINGMAN REEF  
135 KYRGYZSTAN  
136 PERU  
137 SOUTH KOREA  
138 KURE ISLAND  
139 KURIA MURIA IS Y
140 SURINAME  
141 FALKLAND IS  
142 LACCADIVE ISLANDS  
143 LAOS  
144 URUGUAY  
145 LATVIA  
146 LITHUANIA  
147 LORD HOWE IS  
148 VENEZUELA  
149 AZORES  
150 AUSTRALIA  
151 MALYJ VYSOTSKI IS (R1MV)  
152 MACAO  
153 MACQUARIE IS  
154 YEMEN ARAB REP Y
155 MALAYA Y
157 NAURU  
158 VANUATU  
159 MALDIVE IS  
160 TONGA  
161 MALPELO IS  
162 NEW CALEDONIA  
163 PAPUA NEW GUINEA  
164 MANCHURIA Y
165 MAURITIUS IS  
166 MARIANA IS  
167 MARKET REEF  
168 MARSHALL IS  
169 MAYOTTE  
170 NEW ZEALAND  
171 MELLISH REEF  
172 PITCAIRN IS  
173 MICRONESIA  
174 MIDWAY IS  
175 FRENCH POLYNESIA  
176 FIJI  
177 MINAMI TORISHIMA  
178 MINERVA REEF Y
179 MOLDAVIA  
180 MT ATHOS (SY)  
181 MOZAMBIQUE  
182 NAVASSA IS  
183 DUTCH BORNEO Y
184 NETHER N. GUNIEA Y
185 SOLOMON ISLANDS  
186 NEWFOUNDLAND/LAB Y
187 NIGER  
188 NIUE  
189 NORFOLK IS  
190 WESTERN SAMOA  
191 N COOK IS  
192 OGASAWARA  
193 OKINAWA Y
194 OKINO TORI-SHIMA Y
195 PAGALU (ANNOBAR IS)  
196 PALESTINE Y
197 PALMYRA & JARVIS IS  
198 PAPUA TERR Y
199 PETER I IS  
200 PORTUGUESE TIMOR Y
201 PRINCE EDWARD & MARION  
202 PUERTO RICO  
203 ANDORRA  
204 REVILLA GIGEDO  
205 ASCENSION ISLAND  
206 AUSTRIA  
207 RODRIGUEZ IS  
208 RUANDA-URUNDI Y
209 BELGIUM  
210 SAAR Y
211 SABLE ISLAND  
212 BULGARIA  
213 SAINT MARTIN (FJ)  
214 CORSICA  
215 CYPRUS  
216 SAN ANDREAS & PROVIDENCIA  
217 SAN FELIX  
218 CZECHOSLOVAKIA Y
219 SAO TOME & PRINCIPE  
220 SARAWAK Y
221 DENMARK  
222 FAROE IS  
223 ENGLAND  
224 FINLAND  
225 SARDINIA  
226 SAUDI/IRAQ N.Z. Y
227 FRANCE  
228 SERRANA BANK Y
229 GERMAN DEM. REP. Y
230 FED REP OF GERMANY  
231 SIKKIM Y
232 SOMALI  
233 GIBRALTAR  
234 S COOK IS  
235 SOUTH GEORGIA IS  
236 GREECE  
237 GREENLAND  
238 SOUTH ORKNEY IS  
239 HUNGARY  
240 SOUTH SANDWICH ISLANDS  
241 SOUTH SHETLAND ISLANDS  
242 ICELAND  
243 DEM REP OF YEMEN Y
244 SOUTHERN SUDAN  
245 IRELAND  
246 MALTA, SOVERIGN  
247 SPRATLY IS  
248 ITALY  
249 ST KITTS & NEVIS  
250 ST HELENA IS  
251 LIECHTENSTEIN  
252 ST PAUL ISLAND  
253 ST PETER & ST PAUL RKS  
254 LUXEMBOURG  
255 ST MAARTEN  
256 MADEIRA IS  
257 MALTA  
258 SUMATRA Y
259 SVALBARD IS  
260 MONACO  
261 SWAN ISLAND Y
262 TADZHIKISTAN  
263 NETHERLANDS  
264 TANGIER Y
265 NORTHERN IRELAND  
266 NORWAY  
267 TERR NEW GUINEA Y
268 TIBET Y
269 POLAND  
270 TOKELAU IS  
271 TRIESTE Y
272 PORTUGAL  
273 TRINDADE & MARTIN  
274 TRISTAN DA CUNHA  
275 ROMANIA  
276 TROMELIN  
277 ST PIERRE & MIQUELON  
278 SAN MARINO  
279 SCOTLAND  
280 TURKMENISTAN  
281 SPAIN  
282 TUVALU  
283 UK BASES ON CYPRUS  
284 SWEDEN  
285 VIRGIN IS  
286 UGANDA  
287 SWITZERLAND  
288 UKRAINE  
289 HQ UNITED NATIONS  
291 UNITED STATES  
292 UZBEKISTAN  
293 VIETNAM  
294 WALES  
295 VATICAN  
296 YUGOSLAVIA  
297 WAKE IS  
298 WALLIS & FUTUNA  
299 WEST MALAYSIA  
301 W KIRIBATI  
302 WESTERN SAHARA  
303 WILLIS IS  
304 BAHRAIN  
305 BANGLADESH  
306 BHUTAN  
307 ZANZIBAR Y
308 COSTA RICA  
309 MYANMAR  
312 KAMPUCHEA (CAMBODIA)  
315 SRI LANKA  
318 CHINA  
321 HONG KONG  
324 INDIA  
327 INDONESIA  
330 IRAN  
333 IRAQ  
336 ISRAEL  
339 JAPAN  
342 JORDAN  
345 BRUNEI  
348 KUWAIT  
354 LEBANON  
363 MONGOLIA  
369 NEPAL  
370 OMAN  
372 PAKISTAN  
375 PHILIPPINES  
376 QATAR  
378 SAUDI ARABIA  
379 SEYCHELLES  
381 SINGAPORE  
382 DJIBOUTI  
384 SYRIA  
386 TAIWAN  
387 THAILAND  
390 TURKEY  
391 UNITED ARAB EMIRATES  
400 ALGERIA  
401 ANGOLA  
402 BOTSWANA  
404 BURUNDI  
406 CAMEROON  
408 CENTRAL AFRICAN  
409 CAPE VERDE  
410 CHAD  
411 COMOROS (D6)  
412 CONGO  
414 ZAIRE  
416 BENIN  
420 GABON  
422 THE GAMBIA  
424 GHANA  
428 IVORY COAST  
430 KENYA  
432 LESOTHO  
433 NORTH KOREA (HP)  
434 LIBERIA  
436 LIBYA  
438 MADAGASCAR  
440 MALAWI  
442 MALI  
444 MAURITANIA  
446 MOROCCO  
450 NIGERIA  
452 ZIMBABWE  
453 REUNION  
454 RWANDA  
456 SENEGAL  
458 SIERRA LEONE  
460 ROTUMA IS  
462 SOUTH AFRICA  
464 NAMIBIA  
466 SUDAN  
468 SWAZILAND  
470 TANZANIA  
474 TUNISIA  
478 EGYPT  
480 BURKINA-FASO  
482 ZAMBIA  
483 TOGO  
488 WALVIS BAY Y
489 CONWAY REEF  
490 BANABA ISLAND  
492 YEMEN  
493 PENGUIN ISLANDS Y
497 CROATIA  
499 SLOVENIA  
501 BOSNIA-HERZEGOVINA  
502 MACEDONIA  
503 CZECH REPUBLIC  
504 SLOVAK REPUBLIC  
505 PRATAS IS  
506 SCARBOROUGH REEF  

 

4. File Definitions:

A log record is the data resulting from logging one QSO. ADIF does not specify a minimum required set of fields for log data. Although a record should contain at least :

Call
QSO_Date
Time_On
Band
Mode

it is permissible to export data with any of these items missing.

 

ADIF, xBase and other formats

As xBase languages and utilities are very popular (perhaps the most popular) for data handling applications, many parties to the ADIF proposal discussion favored using xBase files as the physical specification. However, this standard was not selected, since it is not easily used by those not using an xBase language, and lacks the flexibility and extensibility that ADIF features. However, a de-facto secondary xBase specification exists. Those wishing to use xBase files that will be compatible with each other may simply use ADIF field and record specifications.

We encourage development of public-domain utilities being made available that convert ADIF/xBase files as well as other popular data formats such as Lotus 123, Paradox, MS Access, etc.

 

Usage of ADIF and limitations

In order to maintain the integrity of ADIF and public confidence therein, these guidelines must be followed by anyone wishing to support ADIF.

ADIF may be freely used by any individual or organization, non-profit or commercial. Anyone claiming "ADIF compatibility" or "ADIF support", or other language with similar meaning, must be able to import and export ADIF data.

Of course data import is not necessary or desirable for all programs. For example, in the case of contesting-only packages, the user will probably want to export the contest data for use in a general logger, but not care about importing data. Authors of such packages shall state they provide "ADIF export compatibility" or "ADIF export support", or other language with similar meaning.

Writing a software package that imports ADIF but cannot export ADIF is not within keeping of the spirit and intent of ADIF. Such a package cannot truthfully claim to be ADIF compatible or to support ADIF. Authors of programs that only import must state that they support "ADIF import compatibility" or "ADIF import support", or language with similar meaning.

Packages that export and import ADIF may state that they support "ADIF import and export" or a similar phrase. However, any claims of ADIF support without any qualifiers shall mean that the program imports and exports.

Export programs shall be written in good faith so that the data will be of maximum usefulness to the user of the data. Products that export data in such a manner that its usefulness is limited, for example by exporting only a few fields or using non-standard formats or names for fields, cannot claim ADIF compatibility. Export programs should include all data in the file to be exported. If an author has fields that are not in the field list of the ADIF specification, he may export the fields by choosing the most obvious field name, and making a reasonable attempt to notify other ADIF supporters--for example via the ADIF mailing list reflector. In time there will probably be an official standards committee that will maintain the field list.

 

ADIF Mailing List Reflector and Web sites

Those with Internet email may participate in the ADIF discussion.

A number of amateurs have been discussing the difficulty in transferring QSO data between the various ham radio software packages that are available, and the desirability of having a standard format so that data can be easily transferred between any two programs. This mailing list has been set up to facilitate the formation of such a specification.

Any software developer or any ham who wishes to contribute to this discussion is welcome to participate.

You may subscribe to these mailing lists by filling out a form at the ADIF web page (http://www.hosenose.com/adif). You may also subscribe via email as described below.

To subscribe to the ADIF Mailing List, send a message to:

listserv@hosenose.com

In the SUBJECT field, enter

SUBSCRIBE ADIF

You will be sent a confirmation along with additional information within 24-48 hours of subscribing.

This web site also contains links to other publishers who support ADIF.

For any questions about this specification, contact us!

 

Ray Ortgiesen, WF1B
Wyvern Technology, Inc.
35 Colvintown Road
Coventry, RI 02816-8509

401-823-RTTY
401-822-0554 Fax
http://www.wf1b.com/
E-Mail: wf1b@wf1b.com
RTTY Contest Reflector: wf1b-rtty@wf1b.com

Publisher of the popular WF1B RTTY contesting program.

 

Dennis Hevener, WN4AZY
Personal Database Applications
1323 Center Dr.
Auburn, GA 30011-3318

770-307-1511
770-307-0760 Fax
pda@hosenose.com
http://www.hosenose.com/

Makers of LOGic ham radio software, SARTek universal antenna rotator interface, and other products for the computer in the shack.

10-Jun-1998 http://www.hosenose.com/adif/adif.html