* * * * *
* * * * *
Das Stützerbach-Format war ein Standard-Logformat des Deutschen Amateur-Radio-Clubs. Nachdem der DARC beschlossen hatte, das Format nicht mehr zu verwenden, wurde auch die Spezifikation im Frühjahr 2016 ersatzlos vom Server gelöscht.
Das Format hat jedoch gegenüber dem heute gebräuchlichen "Cabrillo" einige Vorteile, weswegen es außerhalb des Referats "Conteste" des DARC weiterhin verwandt wird. Die Spezifikation habe ich mithilfe des Internet Archives gesichert.
Version 1.0
Stand: 01. Mai 2004
Die Idee zur Definition eines Standard-Contest-Formats kam nach zweijährigem Mühen bei der Auswertung computerlesbarer Logs unterschiedlichster Formate. Viele Formate ließen sich nicht ohne manuelle Eingriffe verarbeiten. Das Grundprinzip des STF-Formats wurde 1998 durch DL2NBU, DL6RAI und DL3DXX aufgestellt, von DL3DXX weiterentwickelt und erstmalig 1998 bei der Auswertung der WAEDC-CW und SSB eingesetzt. Mittlerweile kommt dieses Format bei der Auswertung aller zentral vom Referat veranstalteten Conteste zum Einsatz. Auch die Schweizerische USKA nutzt dieses Format für die Contestauswertung.
Das Format ist als offenes System konzipiert, d.h. es kann auf andere Conteste mit neuen Sprachelementen erweitert werden. Dabei wird davon ausgegangen, daß die Entwickler dieses Formates nicht an alle Besonderheiten der verschiedenen Conteste denken können. Vielmehr muß es möglich sein neue Elemente aufzunehmen, ohne das Prinzip des Formates selbst zu verändern.
Contestprogrammautoren, die STF in ihre Software einbinden, nehmen dem künftigen Nutzer die Entscheidung ab, welche Dateien er an den Contestausrichter zu senden hat. STF speichert nämlich nicht nur QSO- und QTC-Daten in einer einzigen Datei, sondern auch alle notwendigen allgemeinen Informationen. Damit verringert sich die Zahl der jährlich eingehenden unvollständigen Logs, für Contestauswerter bisher ein leidiges Problem. Außerdem vereinfachen die allgemeinen Informationen im Dateikopf (Header) u.a. die Automatisierung der Logeingangskontrolle, die Ermittlung von "Claimed Scores" sowie den maschinellen Druck von Addresslabels.
STF ist als Datendrehscheibe konzipiert. Auf dem Format aufsetzen können u.a.:
STF-Dateien sind definiert als reine ASCII-Textdateien. In der Datei eventuell trotzdem vorkommende Zeichen, die nicht dem ASCII-Zeichensatz (ordinal 0x00 .. 0x7f) entsprechen, sollten jedoch beim Einlesen toleriert werden und nicht zu Lesefehlern führen (z.B. Deutsche Umlaute). Ihre korrekte Verarbeitung wird jedoch nicht garantiert.
Es wird empfohlen, den Namen von STF-Dateien auf ".stf" enden zu lassen.
Sie beginnen grundsätzlich mit einem vierstelligen Datei-Magic, einer Zeichenfolge bestehend aus STF gefolgt von der Hauptversionsnummer. Dateien, die dieser STF-1-Format-Spezifikation genügen, enthalten STF1 als erste 4 Bytes, eine zukünftig mögliche Version 2 wird dann folglich durch STF2 gekennzeichnet. Damit ist gewährleistet, daß STF-Dateien und deren Versionsnummern durch das Lesen der ersten 4 Bytes eindeutig erkannt werden können.
Das STF-Format ist sehr flexibel ausgelegt. Zur Strukturierung der Daten kommen an vielen Stellen Schlüsselworte zur Anwendung. Bei ihrer Verwendung wird grundsätzlich nicht zwischen Groß- und Kleinschreibung unterschieden.
Das STF-Format unterteilt die in der Datei enthaltenen Daten in mehrere Datenblöcke:
Jeder dieser Datenblöcke ist durch Schlüsselworte gekennzeichnet, die Anfang und Ende des Abschnitts markieren.
Folgende Datenblöcke und ihre Schlüsselworte sind derzeit definiert:
Der Inhalt der einzelnen Datenblöcke ist in Form von Datensätzen organisiert. Datensätze sind durch Zeilenendmarkierungen voneinander getrennt, d.h. pro Textzeile ist ein Datensatz enthalten. Die Zeilenendmarkierung kann dabei mittels einer der bekannten Zeichenfolgen CR/LF (0x0D0A - DOS-Format), LF (0x0A - Unix-Format) oder CR (0x0D - Apple-Format) erfolgen.
Innerhalb eines Datensatzes werden alle Datenfelder durch beliebig viele Tabulatoren (0x09) und/oder Leerzeichen (0x20) voneinander getrennt. Leerzeichen und Tabulatoren am Anfang und am Ende einer Zeile werden ignoriert. Es wird empfohlen, diese Trennzeichen so zu benutzen, daß eine für den Betrachter übersichtliche Darstellung erreicht wird.
Die maximale Zeilenlänge ist auf 255 Zeichen beschränkt, sollte aber, wenn möglich, auf Grund der besseren Lesbarkeit auf 80 Zeichen begrenzt werden.
Nur aus optionalen Trennzeichen und dem Zeilenendekennzeichen bestehende Leerzeilen sind generell an beliebiger Stelle erlaubt. Sie werden beim Einlesen übergangen.
Kommentarzeilen können an beliebiger Position in der Datei eingefügt werden und beginnen mit einem ´#´ als erstem Zeichen auf der Zeile. Im Gegensatz zu Soapbox-Kommentaren, welche in einem separaten Datensatz untergebracht sind, werden diese Zeilen als Dateikommentare interpretiert bzw. beim Einlesen ignoriert.
Beliebige Zeichen am Ende eines Datensatzes, die nicht einem in der weiter unten beschriebene Form als Datenfeld definierten Wert entsprechen, sollten von lesenden Programmen grundsätzlich als Kommentar ignoriert werden und nicht zu Lesefehlern führen.
Es wird empfohlen, einen WEB-Link auf diese STF-Spezifikation sowie einen Hinweis auf die zum Schreiben der Datei benutzte Logsoftware als Dateikommentar unterzubringen.
Der Dateikopf (Header) ist grundsätzlich der erste Block innerhalb der STF-Datei. Er beginnt mit dem Schlüsselwort Header und endet mit EndHeader.
Jede Zeile im Dateikopf entspricht einem Datensatz und beginnt mit genau einem Schlüsselwort, gefolgt von den dazugehörigen Informationen.
Es sollen immer alle definierten Schlüsselworte ausgegeben werden, damit diese ggf. durch den Teilnehmer von Hand ergänzt werden können. Datensätze mit nicht bekannten Schlüsselworten im Dateikopf muß die einlesende Software toleranterweise übergehen.
Beispiel eines STF-Dateikopfs inklusive Datei-Magic und Kommentaren:
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 ...
Obwohl einige der im Dateikopf erfaßten Informationen zur Zeit bei der Auswertung nicht unmittelbar vom Auswerteprogramm benötigt werden, ist eine Standardisierung bei der Aufnahme neuer Elemente wünschenswert.
Schlüsselworte können - wo es sinnvoll ist - auch mehrmals vorkommen. So sollte, z.B. bei Adressangaben oder Soapbox-Kommentaren, eine neue Zeile unter erneuter Verwendung des gleichen Schlüsselwortes eingefügt werden, wo ein Zeilenumbruch im Text der jeweiligen Information erfolgen soll.
Folgende Schlüsselworte sind derzeit für den Headerbereich festgelegt:
Schlüsselwort |
Feldinhalt |
---|---|
Contest |
Name des Wettbewerbs (ggf. inklusive Betriebsart) |
MyCall |
Rufzeichen, unter dem im Contest teilgenommen wurde |
Category |
Teilnahmeklasse |
MailAddress |
Versandadresse, Zeilentrennung durch weitere MailAddress Einträge |
ClaimedQso |
Anzahl der vom Teilnehmer gemeldeten QSOs |
ClaimedPts |
Anzahl der gemeldeten QSO-Punkte, (im WAEDC QSO- + QTC-Punkte) |
ClaimedMult |
Anzahl der gemeldeten Multiplikatorpunkte |
ClaimedScore |
Durch den Einsender errechnete Punktzahl |
Schlüsselwort |
Feldinhalt |
---|---|
Specific |
Spezielle Zugehörigkeit des Teilnehmers, z.B. DOK, CQ/ITU-Zone, State usw. |
ClaimedQtc |
Anzahl der gemeldeten QTCs (nur im WAEDC) |
ClaimedMult2 |
Anzahl der gemeldeten Mutliplikator2-Punkte (z.b. CQWW) |
Schlüsselwort |
Feldinhalt |
---|---|
|
EMail-Adresse, falls vorhanden |
Equipment |
Informationen zur benutzten Ausrüstung |
Power |
Sendeleistung |
Operators |
Liste der Operateure bei Multi-OP |
Club |
Name des Clubs bei Club Competition |
Soapbox |
Kommentar (für Soapbox) |
Besondere Bedeutung kommt den beiden Schlüsselworten QsoOrder und QtcOrder zu. Die so benannten Datensätze im Dateikopf definieren die Reihenfolge und den Inhalt der Datenfelder für die in den folgenden QSO- und QTC-Blöcken jeweils enthaltenen Logdatensätze. Dieser flexible Ansatz ermöglicht eine einfache Erweiterung um neue Datenfelder, z.B. für neue Contestelemente.
Der Inhalt dieser beiden Datensätze besteht aus einer Folge von Schlüsselworten, die die Reihenfolge von Datenfeldern in den QSO- und QTC-Daten charakterisieren. Die hier zu verwendenden Schlüsselworte sind in den folgenden Abschnitten dieser Spezifikation genauer definiert.
Der QSO-Datenblock beginnt mit QsoList und endet mit EndQsoList.
Pro QSO-Eintrag ist genau eine Zeile als Datensatz zu benutzen. Die QSOs sind in chronologischer Reihenfolge anzugeben. Die Reihenfolge der Datenfelder pro QSO-Datensatz wird durch die Angaben in der QsoOrder im Dateikopf definiert. Nichtbelegte Einträge sind durch einen Strich ´-´ zu kennzeichnen. Jede QSO-Zeile hat damit die gleiche Anzahl von Feldern.
Beispiel eines QSO-Datenblocks (oben ist die Spaltendefinition im Header noch eingeblendet):
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
Zur Beschreibung von QSOs sind die folgenden Datenfelder definiert, die durch eine beliebige Anzahl von Trennzeichen voneinander separiert werden. Das bedeutet zwangsläufig auch, daß die Daten selbst keine Trennzeichen beinhalten können.
Die Reihenfolge der Daten im QSO-Datensatz ist frei wählbar, jedoch für alle in der Datei enthaltenen QSO-Datensätze gleich. Sie wird mittels Schlüsselworten im QsoOrder Eintrag des Dateikopfes beschrieben. Folgende Datenfelder sind derzeit definiert und sollten von lesenden Programmen erkannt werden:
Schlüsselwort |
Dazugehöriges QSO-Datenfeld |
---|---|
Date |
Datum |
Time |
Uhrzeit in UTC |
Band |
Band (Wellenlänge) |
Mode |
Betriebsart |
Call |
Rufzeichen |
SRst |
gesendeter RS(T) |
Sent |
gesendete QSO-Info |
Sent2 |
gesendete 2.QSO-Info (falls vorgesehen) |
RRst |
empfangener RS(T) |
Rcvd |
empfangene QSO-Info |
Rcvd2 |
empfangene 2.QSO-Info (falls vorgesehen) |
Pts |
Punkte |
Mult |
Multiplikator |
Mult2 |
2.Multiplikator (falls vorgesehen) |
Nicht alle Datenfelder werden in allen Contesten benötigt. Für einen vollständigen QSO-Eintrag werden jedoch minimal die Felder Date, Time, Band, Mode, Call, SRst und RRst erwartet, im Falle von Contestlogs zumindest erweitert um die Felder Sent und Rcvd. Punkte und Multiplikatoren sind optionale Felder, diese Werte werden während einer Contestauswertung sowieso neu kalkuliert.
Für die meisten der QSO-Datenfelder sind Datenformate mit dem Ziel definiert, das Einlesen von Daten zu erleichtern.
Date:
Die Datumsangabe erfolgt grundsätzlich achtstellig in der Reihenfolge Jahr + Monat + Tag und in der Form JJJJMMTT.
Time:
Die Uhrzeit ist vierstellig in der Reihenfolge Stunde + Minute, als UTC im 24-Stunden-Format und in der Form HHMM anzugeben.
Band:
Das Band wird als Wellenlänge eingetragen und ist wie folgt definiert:
Kurzwelle:
160 = 1.8 MHz
80 = 3.5 MHz
40 = 7 MHz
30 = 10 MHz
20 = 14 MHz
17 = 18 MHz
15 = 21 MHz
12 = 24 MHz
10 = 28 MHz
UKW:
6 = 50 MHz
4 = 70 MHz
2 = 144 MHz
70 = 432 MHz
23 = 1296 MHz
13 = 2320 MHz
9 = 3.4 GHz
5 = 5.6 GHz
3 = 10 GHz
Mode:
Derzeitig definierte Betriebsarten sind dem Anhang A zu entnehmen. Weitere Betriebsarten werden bei Bedarf hinzugefügt.
Pts:
Punktzahl für das betreffende QSO. Vom Einsender selbst gestrichene QSOs sind durch einen nichtnumerischen Wert, empfohlen wird ´C´ (canceled), zu kennzeichnen.
Mult, Mult2:
Den Multiplikator beschreibende Zeichenkette (z.B. Zone, Prefix, DOK) wenn ein Multiplikator gearbeitet wurde, ansonsten Strich ´-´.
Es gibt zwei QTC Datenblöcke, je einen für gesendete und empfangene QTC. Der Datenblock für gesendete QTC beginnt mit dem Schlüsselwort QtcSent und endet mit EndQtcSent. Der für empfangene QTC beginnt dem entsprechend mit QtcRcvd und endet mit EndQtcRcvd.
Pro QTC-Eintrag ist genau eine Zeile als Datensatz zu benutzen. Die QTCs sind im jeweiligen Block in chronologischer Reihenfolge anzugeben. Die Reihenfolge der Datenfelder pro QTC-Datensatz wird durch die Angaben in der QtcOrder im Dateikopf definiert. Jede QTC-Zeile hat die gleiche Anzahl von Datenfeldern.
Beispiel eines Datenblocks für empfangene QTC (oben ist die Spaltendefinition im Header noch eingeblendet):
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
Zur Beschreibung von QTCs sind die folgenden Datenfelder definiert, die durch eine beliebige Anzahl von Trennzeichen voneinander separiert werden. Das bedeutet zwangsläufig auch, daß die Daten selbst keine Trennzeichen beinhalten können.
Die Reihenfolge der Daten im QTC-Datensatz ist frei wählbar, jedoch für alle in der Datei enthaltenen QTC-Datensätze gleich. Sie wird mittels Schlüsselworten im QtcOrder Eintrag des Dateikopfes beschrieben. Folgende Datenfelder sind definiert und sollten von lesenden Programmen erkannt werden:
Schlüsselwort |
Dazugehöriges QTC-Datenfeld |
---|---|
Date |
Datum, an dem das QTC übermittelt wurde (JJJJMMTT) |
Time |
Uhrzeit in UTC, zu der das QTC übermittelt wurde (HHMM) |
Band |
Band (Wellenlänge), auf dem das QTC übermittelt wurde |
Mode |
Betriebsart |
Call |
Rufzeichen, von dem oder an den das QTC übermittelt wurde |
QTCn |
QTC-Seriennummer in der Form nnn/mm |
QTim |
Uhrzeit des im QTC übermittelten QSOs |
QCal |
Rufzeichen des im QTC übermittelten QSOs |
QInf |
QSO-Nummer des im QTC übermittelten QSOs |
Pts |
Punkte für dieses QTC |
Bis auf Pts sind alle diese Felder Pflichtfelder zur vollständigen Angabe eines QTC. Sollte keine spezielle Markierung von nicht zu wertenden QTC durch den Einsender gewünscht sein (kenntlich zu machen durch den Eintrag von C im Pts-Feld), kann auf das Pts-Feld im gesamten Block vollständig verzichtet werden.
Für die QTC-Datenfelder sind Datenformate mit dem Ziel definiert, das Einlesen von Daten zu erleichtern.
Date:
Die Datumsangabe erfolgt, wie auch im QSO, grundsätzlich achtstellig in der Reihenfolge Jahr + Monat + Tag und in der Form JJJJMMTT.
Time, QTim:
Die Uhrzeit ist vierstellig in der Reihenfolge Stunde + Minute, als UTC im 24-Stunden-Format und in der Form HHMM anzugeben.
Band:
Das Band, auf welchem das QTC übermittelt wurde, wird als Wellenlänge eingetragen und ist wie folgt definiert:
80 = 3.5 MHz
40 = 7 MHz
20 = 14 MHz
15 = 21 MHz
10 = 28 MHz
Mode:
Derzeitig definierte Betriebsarten sind dem Anhang A zu entnehmen. Weitere Betriebsarten werden bei Bedarf hinzugefügt. Gegenwärtig kommen jedoch nur CW, SSB oder RTTY in Betracht.
QTCn:
Serien-Nummer der QTC-Serie, zu dem das jeweilige QTC gehört. Sie wird immer in der Reihenfolge QTC-Serien-Nummer + Anzahl der zur Serie gehörenden QTC im Format nnn/mm angegeben, wobei mm nur den Werteumfang von 1..10 enthalten kann. Die Angabe führender Nullen kann dabei entfallen.
Pts:
Punktzahl für das betreffende QTC. Vom Einsender selbst gestrichene QTCs sind durch den nichtnumerischen Wert C zu kennzeichnen, zu wertende QTC durch den Wert 1. Sollte dieses Feld im QtcOrder Eintrag des Dateikopfes nicht enthalten sein, d.h. auf die (optionale) Angabe von Punkten wurde verzichtet, werden alle QTC als mit der Punktzahl "1" bewertet interpretiert.
Denkbar ist für die Zukunft die Definition weiterer Datenblöcke, z.B. eines zusätzlichen Results ... EndResults Blocks, in dem durch die Auswertungssoftware ermittelte Informationen abgelegt werden können. Diese Blöcke beginnen stets mit einem einzelnen Schlüsselwort und enden mit End, unmittelbar gefolgt vom gleichen Schlüsselwort. Im Moment ist hier noch nichts festgelegt. Lesende Software sollte in der Lage sein, ihr unbekannte Datenblöcke zu überspringen.
Durch Publizierung des DARC-STF-Formats soll Software-Authoren die Möglichkeit gegeben werden, ihre Contest-Software um eine entsprechende Schnittstelle zu erweitern. Hier sind nicht nur Contest-Software-Authoren gefragt, sondern auch Logbuch- und QSL-Verwaltungssoftware-Ersteller, die über diese Schnittstelle Daten einlesen und weiterverarbeiten möchten.
Dieses Format wurde von DL2NBU, DL3DXX, DL3TD, DL6RAI und DL8WAA erstellt.
Anregungen und Ergänzungen bitte an folgende E-Mail Adresse: stf@dxhf.darc.de
Stützerbach, den 21. Januar 2000
Editor: DL8WPX |
$Revision: 1.0 $ $Date: 2004-05-11 14:58:23+00 $ |