Navigation
Suche
Anmeldung
Als Zugangsdaten verwenden Sie bitte die Daten aus dem DCD. Sollten Sie noch keine Zugangsdaten haben oder Ihre Daten vergessen haben klicken Sie bitte hier.
Eine Erklärung, wie Sie sich anmelden finden Sie hier.
Sollten Sie Probleme mit dem Sicherheitszertifikat haben, schauen Sie bitte hier.
The "STuetzerbach Format" - STF
Definition of the DARC Contest Data Exchange Format STF
Version 1.0
Date: May 1, 2004
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 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:
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 |
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) |
Keyword | Contents |
|---|---|
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:
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:
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@dxhf.darc.de