Provided by: hf_0.8-8.1_i386
 

NAME

        hfkernel  -Kurzwellen-  Amateurfunk- Protokollimplementation für Sound‐
        karte
 

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 <gettime‐
        ofday  correction>]  [-s  <Soundkarten-Samplerate-Korrektur>] [-t <get‐
        timeofday 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  Termi‐
        nalprogramm  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

        -2     Im Standby-Modus 200 Baud nicht decodieren
 
        -3     Im Standby-Modus 300 Baud nicht decodieren
 
        -a     Pfad zum Audio-Gerät (Default für OSS: /dev/dsp) (für den  ALSA-
               Treiber versuche -a plughw:0,0)
 
        -c     Pfad zur Software-Schnittstelle (Default: /var/run/hfapp)
 
        -f     Im Standby-Modus keine Frequenznachstellung (frequency tracking)
 
        -h     Halbduplex erzwingen (läuft mit manchen Soundkarten besser) (nur
               für OSS)
 
        -i     invertiert PTT-Impuls
 
        -k     Hfkernel beenden (wird im Startskript hf verwendet)
 
        -l     Einträge in Logdatei (Default: keine)
 
        -M     Pfad zum Mixergerät
 
        -m     CPU-Uhr in MHz (auf khz genau)
 
        -n     Verzicht  auf  ’mmap()’  (kein direkter Zugriff auf Soundkarten‐
               puffer).  Experimentell! Für manche Soundkarten, die (oder deren
               Treiber) mmap nicht richtig unterstützen. (nur für OSS)
 
        -p     Pfad  zur  seriellen Schnittstelle für die PTT-Ausgabe (Default:
               keiner)
 
        -R     deaktiviert den Gebrauch der RDTSC-Instruction (nur  bei  Intel-
               Systemen).   Die  Verwendung der RDTSC-Instruktion kann bei Lap‐
               tops und/oder bei aktiviertem APM  (Advanced  Power  Management)
               Probleme verursachen.
 
        -r     Zugangsrechte  zur Software-Schnittstelle (Default: 0777 = rwxr‐
               wxrwx)
 
        -s     Korrektur der soundcard sampling rate
 
        -t     gettimeofday - Korrekturfaktor (Zeitbestimmung  über  Prozessor‐
               taktrate)
        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  Informatio‐
        nen  des  OSS-Treibers  über  die  Sample-Rate zu korrigieren, kann die
        Option -s benützt werden. Die Soundkarte sollte echte Quarze statt bil‐
        liger 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  Zeit‐
        markenzähler), um zu sehen ob sie  verfügbar ist und arbeitet (auf Pen‐
        tium-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 Frequen‐
        zabweichungen könnten mit der Option -t korrigiert werden.
 

UHR-KALIBRIERUNG

        Wenn Du den deutschen Zeitnormal- und Referenzfrequenzsender DCF77 emp‐
        fangen  kannst, kann das dcf77 - Programm benutzt werden, um die Kalib‐
        rierfaktoren 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 Mes‐
        sungen 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 Videoaus‐
        gang 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-Sound‐
        karte 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 (TXDe‐
        lay) zu verstecken, also stelle das txdelay  auf  einen  größeren  Wert
        ein!  Und hoffe, daß die Summe aus Ausbreitungszeit zu Deinem Funkpart‐
        ner und dessen txdelay auch länger ist.
 
        Die Audio-Level und -Parameter können mit den üblichen Mixer-  Program‐
        men eingestellt werden. Das eingebaute AGC sollte ausgeschaltet sein.
        Derzeit werden RTTY, Amtor, GTOR und Pactor 1 unterstützt.  Landesspez‐
        ifische 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  Durch‐
        schnittsbildung 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....
        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 aktual‐
        isiert werden!
 

BUGS

        oder Ecken werden sicher zu finden sein...
 

AUTOR

        Thomas M. Sailer,  HB9JNX/AE4WA,  sailer@ife.ee.ethz.ch  übersetzt  und
        ergänzt 30.07.2004 von Günther Montag dl4mge@darc.de
 
                                    02/15/07                        HFKERNEL(1)