Manpages

NAME

hfkernel −Kurzwellen- Amateurfunk- Protokollimplementation für Soundkarte

AUFRUF

hfkernel [−2] [−3] [−a <audio-Gerät>] [−c <comm socket>] [−f] [−h] [−i] [−k] [−l] [−M <Mixer>] [−m <cpu MHz>] [−n] [−p <Ptt-Port>] [−R] [−r <Socket-Zugriffsrechte] [-s <soundcard clock correction>] [-t <gettimeofday correction>] [−s <Soundkarten-Samplerate-Korrektur>] [−t <gettimeofday Korrektur>]

BESCHREIBUNG

hfkernel implementiert die Funkprotokolle Pactor 1, AMTOR (SITOR), GTOR und RTTY. Es benützt eine normale Soundkarte als Modem. Der Geschwindigkeitswechsel bei Pactor (von 100 auf 200 baud) geschieht automatisch nach einer automatischen Abschätzung der Signalqualität. Ein PTT (push to talk) -Signal kann über die RTS-Leitung einer seriellen Schnittstelle ausgegeben werden. hfkernel hat keine eigene Benutzeroberfläche. Dafür stellt es ein UNIX domain socket (Software-Schnittstelle) zur Verfügung. Dies wurde dafür ausgelegt, um auch den Austausch mit einem Internet domain socket zu ermöglichen. Das Terminalprogramm und Mailboxinterface hfterm verbindt sich mit diesem Socket. hfkernel muß mit root-Rechten ausgeführt werden, weil es im Echtzeit-Modus läuft. Es wird aber mit dem suid-Bit installiert, und das Startskript hf vereinfacht den kombinierten Start mit hfterm.

OPTIONEN

ECHTZEIT - PROBLEME

Kurzwellenprotokolle sind normalerweise synchron. Sie benötigen eine exakte Zeitquelle, um auch bei längeren Unterbrechungen der Übertragung bitsynchron zu bleiben. Z.B. fordert das SITOR-Protokoll (ähnlich AMTOR), daß die Referenzzeitquelle nicht mehr als 20 ppm vom Idealwert abweichen darf. Es ist schwierig, eine so exakte Zeitquelle zu finden. Deshalb erfordern alle Optionen, die in dieser Implementation gewählt werden können, eine manuelle Einstellung.

Wenn die Soundkarte voll-duplex-fähig ist, wird die Referenzzeit von der Sample-Uhr der Soundkarte abgeleitet. Um unzutreffende Informationen des OSS-Treibers über die Sample-Rate zu korrigieren, kann die Option -s benützt werden. Die Soundkarte sollte echte Quarze statt billiger keramischer Resonatoren enthalten.

Wenn die Soundkarte nicht voll-duplex-fähig ist, kann die o.g. Methode nicht angewandt werden. Auf Intel-Architekturen testet das Programm die Prozessorinstruktion RDTSC (read time stamp counters, lese Zeitmarkenzähler), um zu sehen ob sie verfügbar ist und arbeitet (auf Pentium-Computern und neueren sollte dies der Fall sein). Diese Zähler inkrementieren im Takt der CPU-Clock, deshalb muß dem Programm die auf khz exakte Frequenz der CPU-Uhr bekannt sein (Option -m). Laß Dich nicht von Werbegags irreführen, z.B. läuft ein AMD K5 PR133 auf 100MHz.

Auf Nicht-Intel-Systemen, oder wenn die RDTSC-Instruktion nicht verfügbar ist oder nicht arbeitet, verwenden wir gettimeofday - in der Hoffnung daß das tv_usec -Feld genau genug ist. Systematische Frequenzabweichungen könnten mit der Option -t korrigiert werden.

UHR-KALIBRIERUNG

Wenn Du den deutschen Zeitnormal- und Referenzfrequenzsender DCF77 empfangen kannst, kann das dcf77 - Programm benutzt werden, um die Kalibrierfaktoren zu messen. Stelle Deinen Empfänger auf 78.5kHz LSB (oder 76.5kHz USB) und starte dcf77 (vorzugsweise als root). Nach 1-2 Minuten (unter störungs- freien Bedingungen) sollte das Programm die DCF77-Zeit ermittelt haben. Von da an warte etwa 15 Minuten und schreibe die Messungen auf.

Der Schweizer Zeitnormalsender HBG bei 75kHz könnte vermutlich auch verwendet werden, aber ich kenne das genaue Format seiner Übertragung nicht (es scheint dem des DCF77 sehr ähnlich zu sein).

Wenn Du weder DCF77 noch HBG empfangen kannst, benütze refclock und eine bekannte exakte Zeitquelle im Bereich von 200Hz-20kHz. Eine in den meisten Haushalten bereitstehende und normalerweise sehr genaue Quelle ist die Zeilenfrequenz-Synchronisation eines gewöhnlichen Fernsehempfängers. So weit ich weiß, wird die Zeilenfrequenz des ZDF auch von Behörden als Zeitnormal benutzt. Stelle Deinen Fernseher (mit Video-Grundfrequenzausgang) auf einen Kanal ein und leite den Videoausgang an die Soundkarte. Starte reffreq −f 15625 als root. Nach einigen Sekunden sollte das Programm die Korrekturparameter ermittelt haben. (Die oben angegebene Kommando- zeile setzt das PAL-format mit seiner Zeilenfrequenz von 15625 Hz voraus. Für andere Formate verwende die entsprechende Frequenz.)

SOUNDKARTE

Die Soundkarte muß vom OSS-Treiber unterstützt werden. Sie muß 16-Bit-Sampling in der Byteordnung der CPU, 8kHz Sampling-Rate, memory mapping der DMA-Puffers and triggering unterstützen. Eine Voll-Duplex-Soundkarte ist vorzuziehen.

Halb-Duplex-Soundkarten müssen umgeschaltet werden, wenn das Protokoll vom Empfangen zum Senden und umgekehrt übergeht. Das dauert recht lang, zwischen 5 und 35 ms. Das Program mißt die durchschnittliche Zeit beim Start. Es versucht, diese Latenz in der PTT-Auftastverzögerung (TXDelay) zu verstecken, also stelle das txdelay auf einen größeren Wert ein! Und hoffe, daß die Summe aus Ausbreitungszeit zu Deinem Funkpartner und dessen txdelay auch länger ist.

Die Audio-Level und -Parameter können mit den üblichen Mixer- Programmen eingestellt werden. Das eingebaute AGC sollte ausgeschaltet sein.

UNTERSTÜTZTE PROTOKOLLE

Derzeit werden RTTY, Amtor, GTOR und Pactor 1 unterstützt. Landesspezifische Zeichensätze werden wegen mangelnder Dokumentation nur begrenzt unterstützt.

BEGRENZUNGEN

Alle implementierten Protokolle sind von Natur aus nicht sehr robust und nicht perfekt. Memory ARQ, das Ausmitteln von Fehlern durch Durchschnittsbildung wiederholter Pakete bei Pactor, ist implementiert, aber das Grundkonzept ist fehlerhaft. Seine Erfinder gingen davon aus, daß Signal-Rausch-Abstände bei Wiederholung eines Paketes gleich bleiben, was gewöhnlich nicht zutrifft. Bessere Korrekturalgorithmen sollten Testbits verwenden, die dem Empfänger bekannt sind und ihn befähigen, die Übertragungsqualität einzuschätzen und wiederholte Sendungen entsprechend zu gewichten. Die Synchronisierung reagiert evtl. zu schnell.

Das Programm reagiert empfindlich auf andere laufende Prozesse. Der Grund dafür ist, daß Prozesse - auch im Echtzeitmodus - nur laufen, nachdem alle Interruptroutinen und ’bottom halfs’ des Betriebssystems fertig sind. In Abhängigkeit von Computertaktrate und Treibern kann das lang dauern, mehr als 100ms. Mehr als 10ms stört diese Anwendung schon sehr. Deswegen sollte L1 (FSK-Modem) am besten in die Kernel-Ebene verlagert werden. Jedoch gefällt mir im Moment die Idee nicht, noch einmel einen Soundkartentreiber zu entwickeln....

SIEHE AUCH...

Die Dokumentation des Pactor 1 -Protokolls (z.B. /usr/local/info/pactor.txt), die CCIR-Dokuumente zur Definition von SITOR (AMTOR), die OSS- und ALSA-Dokumentation. Die ausführlichere Dokumentation zur aktuellen Version des hf-Paketes ist in /usr/share/doc/packages/hf oder über das Hilfemenü von hfterm zu finden! man dcf77rx, man dcf77gen, man hfkernel, man hf und auch diese manpage sind nur kurze Einführungen und können nicht regelmäßig aktualisiert werden!

BUGS

oder Ecken werden sicher zu finden sein...

AUTOR

Thomas M. Sailer, HB9JNX/AE4WA, sailer [AT] ife.ch übersetzt und ergänzt 30.07.2004 von Günther Montag dl4mge [AT] darc.de