The "STuetzerbach Format" - STF

Definition of the DARC Contest Data Exchange Format STF

Version 1.0
Date: May 1, 2004

Contents

1. Introduction

The idea to define a standard contest data exchange format materialised after 2 years of electronic log checking with a variety of formats. Many data formats could not be processed without manual intervention. In 1998, the basic principle of the STF format was defined by DL2NBU, DL6RAI and DL3DXX, further refined by DL3DXX and used for checking the WAE-DX Contests CW and SSB for the first time in practice. Meanwhile, STF is established as a common platform to process logs in all contests sponsored by the DARC Committee DX and HF-Contesting. The Swiss USKA uses this format for their contests too.

The format is an open system. It can be extended to cover new contests with different language elements. We, as the developers of this format, cannot think of all aspects of the many different contests. Thus, the idea was to be able to add new elements in future without changing the general layout.

Implementing STF, authors of contest logging software ease the burden for users to select and compile all the data necessary for the submission of contest logs. This is especially true for the often complicated compilation of all relevant data for the WAEDC log. Because STF contains not only QSO- and QTC-data but also the complete header information, only one file has to be sent by the participant, reducing the amount of incomplete logs received by the log checkers. Furthermore, some data can directly be taken from the log header for automated post-processing.

STF is to be used as a data exchange turntable. The format can, for instance, be used as follows:

  • In contest logging software as an export format,
  • post-contest processors,
  • cross check software of the contest sponsor,
  • acquisition of participants data (address, claimed scores),
  • automatic generation of final contest results,
  • import format for different general purpose logging software,
  • QSL management software.

2. General Definition

2.1. File Format

STF files are plain ASCII files by definition. Non-ASCII characters found within STF files (outside hex 0x00 - 0x7f) should be tolerated and not cause read errors. Yet, their correct interpretation is not guaranteed.

It is recommended to use the filename extension .stf for this kind of file.

Each STF file begins with a four-character Magic containing the character sequence STF followed by the main format version number. Thus, files compliant to the STF-1 format specification always begin with STF1 in the first four bytes. A future version 2 of the format will be shown as STF2. This guarantees that STF files and their respective version can always be determined by reading the first four bytes of the file.

2.2. Keywords

The STF-format is very flexible by design. The structure of the file and the data layout is not necessarily based on row or column positions. The data structure is defined by keywords, always treated case insensitive.

2.3. Data Blocks

The STF-format splits a file into several sections, so called data blocks:

  • A file header,
  • a QSO data block,
  • optionally one or more QTC data blocks (specific to WAEDC),
  • further optional data blocks which may be defined in future.

Each of these data blocks is surrounded by two keywords, markers for begin and end of such a section.

The following data blocks and their respective keywords are currently defined:

  • Header ... EndHeader (file header)
  • QsoList ... EndQsoList (QSO data)
  • QtcSent ... EndQtcSent (data of sent QTC)
  • QtcRcvd ... EndQtcRcvd (data of received QTC)

2.4. Data Records

The contents of the data blocks is organized as a sequence of data records. Records are separated by one ore more consecutive line-end-markers. Thus, within a block, one line of text always contains one data record. Any of the three commonly known character sequences CR/LF (0x0d0a - DOS-format), LF (0x0a - Unix-format) oder CR (0x0d - Apple-format) can be used as a line-end marker.

A data record is split into various data fields, separated by one or several consecutive tabs (hex 0x09) or spaces (0x20). Tabs and spaces at the beginning or end of a record are ignored. It is recommended to use these field delimiters in such a way as to make the overall block layout look tabular, pretty and easy to read.

The maximum line length is limited to 255 characters. However, the lines should not be longer than 80 characters, which makes them easier to view in an editor.

Empty lines, containing just line-break characters, are allowed anywhere in the file. They are silently ignored.

Comment lines can be inserted anywhere in the file. They always begin with a ´#´ as first character on the line. In contrast to soapbox comments, which are contained in a separate data record, these lines are interpreted as file comments or even ignored.

An arbitrary sequence of characters following the defined sequence of data fields on a line should be ignored, not causing read errors.

In general, it is recommended to add a WEB link to this STF specification and a note specifying the software used to generate the STF file as comment line.

3. File Header

The header is always the first block in the file. It begins with the keyword Header and ends with EndHeader.

Every header line is a data record, containing one keyword followed by the content of the field.

The STF header should always contain all keywords defined for it, even if no values are on hand. Thus, the participant can fill in any perhaps in software unavailable or otherwise missing information manually.

Example of an STF header including file magic and recommended comments:

 

STF1
# BinFile "dl3td", BinVersion "CT9.xx"
# Data written "Fri Oct 16 14:15:55 1998 UTC"
# STF specs at http://www.darcdxhf.de

Header
Contest WAE-CW
MyCall DL3TD
Category SOHP
MailAddress Lothar Wilke
MailAddress Eislebener Strasse 14
MailAddress ERFURT
MailAddress D-99086
MailAddress Germany
EMail -
ClaimedQso 1477
ClaimedQtc 1768
ClaimedPts 3245
ClaimedMult 420
ClaimedScore 1362900
Club ICC
Equipment -
Power -
Soapbox WAEDC is the best, thanks for a great weekend.
Soapbox See you again next year.
QsoOrder Date Time Band Mode Call SRst Sent RRst Rcvd
QtcOrder Date Time Band Mode Call QTCn Qtim Qcal Qinf
EndHeader
...

 

 

3.1. Data Records for General Log Information

Although some of the information is currently not used by the log processing software, a standardisation of the keywords is reasonable at this time.

Keywords may, if necessary, be used multiple times. Mailing address lines, for example, should be split into several MailAddress lines to achieve a reasonable layout when printed.

Currently the following keywords are defined for records in the header block:

Keywords for Header Entries - Mandatory Fields
Keyword Contents
Contest name of the contest (perhaps including mode)
MyCall callsign of the participant, used during the contest
Category category of participation
MailAddress mailing address, possibly broken up into several lines using further MailAddress records
ClaimedQso number of claimed QSOs
ClaimedPts number of claimed QSO points (WAEDC: QSO + QTC points)
ClaimedMult number of claimed multipliers
ClaimedScore calculated claimed score of the entrant
Keywords for Header Entries - Contest Specific Fields
Keyword Contents
Specific special regional or organisational designators like DOK, CQ/WAZ zone, state etc.
ClaimedQtc number of claimed QTCs (WAEDC only)
ClaimedMult2 number of second claimed multipliers (e.g. CQWW zones)
Keywords for Header Entries - Optional Fields
Keyword Contents
EMail e-mail address
Equipment equipment list used during the contest
Power transmitter output power
Operators list of operators for multi-op
Club name of the club for the club competition
Soapbox comments for soapbox

3.2. Data Records Describing the QSO-/QTC-Layout

The two mandatory language elements (header records) QsoOrder and QtcOrder have a special meaning. They describe sequence and content of data fields in the QSO or QTC data records. This way, extensions with new data fields are easily possible.

The content of these data records is a list of keywords, where their sequence defines the availability and sequence of the data fields within the QSO- and QTC-datablocks. For a description of possible keyword values please refer to the following sections.

4. QSO-Data Block

The QSO-data block begins with the keyword QsoList and ends with EndQsoList.

One line per QSO is to be used. QSOs are to be listed in chronological order. The sequence of data fields within a record is defined in the QsoOrder record of the file header. Unknown or unused fields within a record must contain a '-' (minus) as an empty field designator. Thus, every QSO record must have the same number of fields.

Example of a QSO block (the field / column definition is still shown in the header block):

 

Header
...
...
QsoOrder Date Time Band Mode Call SRst Sent RRst Rcvd Pts Mult
EndHeader

QsoList
19980808 0032 15 CW PY3CJI 599 1 599 001 1 PY
19980808 0033 40 CW WP2Z 599 2 599 63 1 KP2
19980808 0035 20 CW PR2W 599 3 599 013 1 PY
19980808 0036 40 CW JY9QJ 599 4 599 54 1 JY
19980808 0039 40 CW KC1F 599 5 599 052 1 K
19980808 0040 40 CW KC1XX 599 6 599 91 1 -
19980808 0041 40 CW W3BGN 599 7 599 050 1 -
19980808 0041 40 CW K2NG 599 8 599 73 0 -
19980808 0042 40 CW K3WW 599 9 599 045 C -
19980808 0043 40 CW TL5A 599 10 599 77 1 TL
...
...
EndQsoList

 

4.1. QSO-Data Record

To describe QSO, the following data fields and their respective keywords are defined. Field values within a QSO record are to be separated by an arbitrary number of field delimiters. Thus, these field delimiters (tabs and spaces) can't be part of the field values themselves.

There is no mandatory sequence of data fields within a QSO record; it is defined according to the sequence of keyword values in the QsoOrder statement of the file header. All QSO records within a file have therefore the same field layout. Here the list of data fields defined for QSO records and their respective keywords, which should be recognized by compliant reader programs:

Keywords for QsoOrder Entries
Keyword Related QSO-Data Field
Date date
Time time in UTC
Band band (wavelength, not frequency)
Mode mode of operation
Call callsign of partner station
SRst RS(T) sent
Sent QSO-info sent
Sent2 second QSO-info sent (if any)
RRst RS(T) received
Rcvd QSO-info received
Rcvd2 second QSO-info received (if any)
Pts claimed QSO points
Mult multiplicator value
Mult2 second multiplicator value (if any)

Not all of these values are required in every contest. At least the fields Date, Time, Band, Mode, Call, SRst and RRst should be populated to describe a QSO completely. In case of contestlogs, the fields Sent and Rcvd should be available too. Points and multipliers are optional values, they will anyway be re-calculated during cross-examination.

4.2. QSO-Data Formats

To be able to process the data automatically, formats are specified for most of these field values.

Date:

The date has always to be entered using an eight-digit value in the sequence year + month + day and formatted as YYYYMMDD.

Time:

The timestamp has to be entered using a four-digit value in the sequence hour + minute and formatted as a 24-hour UTC value HHMM.

Band:

The band information has to be entered as wavelength using one of the following values:

 


HF VHF and above
------------- ---------------
160 = 1.8 MHz 6 = 50 MHz
80 = 3.5 MHz 4 = 70 MHz
40 = 7 MHz 2 = 144 MHz
30 = 10 MHz 70 = 432 MHz
20 = 14 MHz 23 = 1296 MHz
17 = 18 MHz 13 = 2320 MHz
15 = 21 MHz 9 = 3.4 GHz
12 = 24 MHz 5 = 5.6 GHz
10 = 28 MHz 3 = 10 GHz
1.2 = 24 GHz

 

Mode:

All operational modes currently defined are available in annex A. More modes are added from time to time meeting actual demand.

Pts:

Point score for the related QSO. A QSO deleted by the participant himself has to be marked with a non-numeric entry in this data field, where ´C´ (canceled) is recommended.

Mult, Mult2:

An alphanumeric string describing the multiplicator (e.g. zone number, prefix, state, DOK) if a new multi was worked, else a minus (´-´).

5. QTC-Data Blocks (WAEDC only)

There are two blocks defined for QTCs, one for the transmitted and one for the received QTC. The block for QTC sent begins with the keyword QtcSent and ends with EndQtcSent. Similiarily, the block for QTC received begins with the keyword QtcRcvd and ends with EndQtcRcvd.

One line per QTC must be used. QTCs are to be given in chronological order within their block. The sequence of the data fields within a record is defined by the QtcOrder record values in the file header. All records have the same amount of fields.

Example for a block of received QTC (the field / column definition is still shown in the header block):

 

Header
...
...
QtcOrder Date Time Band Mode Call QTCn Qtim Qcal Qinf Pts
EndHeader

QtcSent
19980808 0037 40 CW JY9QJ 9/10 0032 RT3A 010 1
19980808 0037 40 CW JY9QJ 9/10 0033 YT1AD 24 1
19980808 0037 40 CW JY9QJ 9/10 0034 LY2BM 19 1
19980808 0037 40 CW JY9QJ 9/10 0034 S50A 052 1
19980808 0037 40 CW JY9QJ 9/10 0034 DL0GVM 015 1
19980808 0037 40 CW JY9QJ 9/10 0035 OL6X 17 1
19980808 0037 40 CW JY9QJ 9/10 0035 OH6OS 14 1
19980808 0037 40 CW JY9QJ 9/10 0035 DL7ALM 27 1
19980808 0037 40 CW JY9QJ 9/10 0036 UY0ZG 018 1
19980808 0037 40 CW JY9QJ 9/10 0036 DA0FF 38 1
...
...
EndQtcSent

 

5.1. QTC-Data Record

To describe QTC, the following data fields and their respective keywords are defined. Field values within a QTC record are to be separated by an arbitrary number of field delimiters. Thus, these field delimiters (tabs and spaces) can't be part of the field values themselves.

There is no mandatory sequence of data fields within a QTC record; it is defined according to the sequence of keyword values in the QtcOrder statement of the file header. All QTC records within a file have therefore the same field layout. Here the list of data fields defined for QTC records and their respective keywords, which should be recognized by compliant reader programs:

Keywords for QtcOrder Entries
Keyword Related QTC-Data Field
Date date when the QTC was sent/received (YYYYMMDD)
Time time when the QTC was sent/received (HHMM)
Band band (wavelength) where the QTC was transmitted
Mode mode in which the QTC was transmitted
Call callsign of the partner station that transmitted/received the QTC
QTCn QTC serial number in the format nnn/mm
QTim time information exchanged in the QTC (HHMM)
QCal callsign information exchanged in the QTC
QInf QSO number information exchanged in the QTC
Pts claimed points for this QTC

All fields except Pts are mandatory to completely describe a valid QTC. As long as there is no need to mark QTC explicitely as canceled by the participant, the points field can be omitted in the whole block, they will anyway be re-calculated during cross-examination.

5.2. QTC-Data Formats

To be able to process the data automatically, formats are specified for most of these field values.

Date:

The date has, like in the QSO record, always to be entered using an eight-digit value in the sequence year + month + day and formatted as YYYYMMDD.

Time, QTim:

The timestamp has to be entered using a four-digit value in the sequence hour + minute and formatted as a 24-hour UTC value HHMM.

Band:

The information, on which band the QTC was exchanged, has to be entered as wavelength using one of the following values:

 


80 = 3.5 MHz
40 = 7 MHz
20 = 14 MHz
15 = 21 MHz
10 = 28 MHz

 

Mode:

All operational modes currently defined are available in annex A. Yet, in case of QTC only CW, SSB or RTTY are valid entries.

QTCn:

Number of the QTC-Series the current QTC belongs to. This number is always defined as the sequence of QTC-series-number followed by the number of QTC belonging to the series nnn/mm, where mm can only have a value between 1 and 10. Any leading zeros can be omitted.

Pts:

Point score for the related QTC (normally 1). A QSO deleted by the participant himself has to be marked with a non-numeric entry in this data field, where ´C´ (canceled) is recommended. If no Pts keyword was found in the QtcOrder header entry, the points field is omitted and all QTC will be treated as valid submission (One point per QTC).

6. Additional Blocks

In the future, several more data blocks may be defined and added to this format, e.g. a Results/EndResults block. The format of the block limiters will always be the same:

  • A certain keyword at the beginning of a block,
  • the same keyword prefixed with End at the end of a block.

Nothing else has been decided yet. STF-Reader programs should be able to skip any unknown blocks.

7. Final Comments

By publishing the DARC-STF format, software authors have the option to add this interface to their software. Not only contest software developers are asked to do so but also general purpose logging software and other QSO data processing software authors are kindly invited.

This format was specified by DL2NBU, DL3DXX, DL3TD, DL6RAI and DL8WAA.

Please direct additions and ideas to the following E-Mail address: stf(at)dxhf.darc.de

8. Annex

Annex A: Designations for Operational Modes

To top

Annex A: Designations for Operational Modes

Definition of the DARC Contest Data Exchange Format STF

Version 1.0
Date: May 1, 2004

This annex is a mandatory part of the specification and contains all valid abbreviations to be entered as values in the Mode field of QSO-/QTC-data records.

Abbreviation for Modes
Mode Abbreviation
Morse CW
Single Sideband Phone SSB
Amplitude Modulation Phone AM
Frequency Modulation Phone FM
Radio Teletyping (including MTTY) RTTY
Frequency Shift Keying (except RTTY, e.g. FSK31, MFSKxxx, HFSK) FSK
Phase Shift Keying (PSK31/63/125, QPSK) PSK
Weak Signal Comms by K1JT WSJT
Quadrature Amplitude Modulation QAM
Packet PACKET
Pactor, Pactor2 PACTOR
Amtor AMTOR
GTor GTOR
Throb THROB
ASCII ASCII
Hell HELL
Clover CLOVER
Slow-Scan Television SSTV
Amateur Television (Wideband) ATV

Annex B: Recommended Contest Names

To top

Annex B: Recommended Contest Names

Definition of the DARC Contest Data Exchange Format STF

Version 1.0
Date: May 1, 2004

This is a non-mandatory annex, a listing of recommended abbreviations for contest name values to be entered in the Contest header field. This list is not meant to be complete. For these abbreviations widely used shortcuts were selected.

Recommended Abbreviations for Contest Names
Contest Related Abbreviation
AGCW Happy New Year Contest HNY
All Asian DX Contest AA
ARI Intl. DX Contest ITALDX
ARRL 10m Contest ARRL-10
ARRL 160m Contest ARRL-160
ARRL DX Contest ARRL-DX
CQ Mir Contest CQM
CQ WW DX Contest CQ-WW
CQ WW DX Contest 160m CQ-160
CQ WW WPX Contest CQ-WPX
Croatian CW Contest CROATIA
DARC 10m Contest DARC-10
DARC-Weihnachtswettbewerb (XMAS) XMAS
DXpedition DXPDN
European HF Championship EUHF
HA DX Contest HADX
Helvetia Contest HELVETIA
HK Independence Contest HK
HSC CW Contest HSC
IARU HF World Championship IARU-HF
IARU Region 1 FieldDay (DARC Rules) FD
IARU Region 1 FieldDay (USKA Rules) FD-HB9
Japan Int. DX Contest JADX
LZ DX Contest LZDX
OK/OM DX Contest OKDX
Original QRP Contest OQRP
PACC Contest PACC
RSGB IOTA Contest IOTA
Russian DX Contest UADX
Scandinavian A. Contest SAC
SP DX Contest SPDX
TOPS 80m Activity Contest TOPS
UBA Contest UBA
Ukrainian DX Contest UKRAIN
USKA-Weihnachtswettbewerb (HB9) XMAS-HB
VK/ZL Oceania DX Contest VKZL
WAE DX Contest WAE
WAG Contest WAG
WW South America Contest WWSA
YO DX HF Contest YODX
YV Independence Contest YV

 

Annex C: Recommended Contest Categories

To top

Annex C: Recommended Contest Categories

Definition of the DARC Contest Data Exchange Format STF

Version 1.0
Date: May 1, 2004

This is a non-mandatory annex, a listing of recommended abbreviations for contest category values to be entered in the Category header field. This list is not meant to be complete. For these abbreviations widely used shortcuts were selected. A couple of contest sponsors specify their own classes, e.g. denoted explicitely by numbers or letters. The contest rules will always have priority, the current abbreviations are only recommendations. For Single Mode and Single Band entries it is recommended to extend the category specification with the respective Mode or Band values.

Recommended Abbreviations for Contest Categories
Category Related Abbreviation
Checklog CHECK
Multi Operator Multi TX MM
Multi Operator Single TX MS
Multi Operator Two TX M2
Single Operator SO
Single Operator Allband SOAB
Single Operator Allband Assisted SOAB(A)
Single Operator High Power SOHP
Single Operator Low Power SOLP
Single Operator QRP SOQRP
Shortwave Listener SWL
Mixed Mode (Add-On) MIXED

 


Annex D: Changelog

To top

Annex D: Changelog

Definition of the DARC Contest Data Exchange Format STF

Version 1.0
Date: May 1, 2004

This annex contains the summary of changes for this specification, starting with the first published version V0.9C.

Changes from version V0.9C to V1.0

  • Removed inconsistency for keywords / blocks "QtcList" and "QtcSent" / "QtcRcvd",
  • removed inconsistency for keywords / fields "Address" and "MailAddress",
  • removed problems with point scores of "-1" (deleted QSO/QTC now designated by "C" instead),
  • clarification of the formal file structure (file -> block -> record -> field),
  • clarification for the recommended treatment of various file errors by reader programs (skip, ignore),
  • extension and separation of definition for operational modes,
  • addition of annex for recommended contest categories,
  • addition of annex for recommended contest name abbreviations,
  • addition of this change log,
  • some editorial changes.

 

 

Um unsere Webseite für Sie optimal zu gestalten und fortlaufend verbessern zu können, verwenden wir Cookies. Durch die weitere Nutzung der Webseite stimmen Sie der Verwendung von Cookies zu. Weitere Informationen zu Cookies erhalten Sie unter Datenschutz. Akzeptieren.