STT-Betrieb bei DB0SP


Hintergrund

Der NF-Frequenzbereich einer Sprechfunkverbindung liegt etwa zwischen 300Hz und 3,4kHz. Unterhalb des Sprachspektrums werden bei FM Subtöne zwischen 67Hz und 254,1Hz für einen einfachen Selektivruf CTCSS verwendet. Der Bereich darunter wird im Amateurfunk i.d.R. nicht genutzt. Dieser Frequenzbereich (hier mit Überlappungen rot dargestellt) dient bei DB0SP zur Übertragung von Telemetriedaten (STT = Subton-Telemetrie) für den SysOp.



Übertragungsverfahren

Zur Übertragung der Telemetrie wird ein 35,1Hz Hilfsträger mit 4-DPSK moduliert. Das Signal kann so unterpegelig übertragen werden, dass es unhörbar bleibt und zu keinen Störungen mit der Nutz-NF kommt. Dazu ist jedoch ein Sender erforderlich, der Spektralanteile bis hinab zu etwa 3Hz verzerrungsfrei übertragen kann. Nicht alle PLL-Transceiver sind dafür geeignet. Bei quarzgesteuerten Sendern ist dies i.d.R. unproblematisch. An den Empfänger werden dagegen nur geringe Anforderungen gestellt. Übliche 9K6-Ausgänge für Packet-Radio sind geeignet.

Moduliert man eine Zufallsfolge in 4-DPSK auf einen 35,1Hz-Träger, so ergibt sich die folgende spektrale Belegung im NF-Bereich (lineare Frequenzachse: 0Hz bis 200Hz):

Die Daten werden als synchroner, paktetorientierter Datenstrom mit Fehlersicherung aber ohne Rückkanal (kein ARQ, keine Empfangsbestätigung) zyklisch übertragen. Jedes Paket beginnt mit einem Kennungsbyte (Opcode), das die Funktion der restlichen Daten im Paket beschreibt. Hat das erste Datenbyte z.B. den Wert $F6 (Opcode DATA), so können danach bis zu 64 frei definierbare Nutzbytes folgen. Die Übertragung dieses maximal langen Pakets dauert etwa 7,6s. Übliche Telemetriepakete sind aber bereits schon nach 0,8s übertragen. Näheres zum Übertragungsverfahren findet man an dieser Stelle.

QST/QTC

Im Datenformat ist auch ein Opcode zur Übertragung von Telegrammen (Opcode QTC = Ich habe Telegramme für Sie) vorgesehen. Dieses spezielle Paket enthält ein Absende- und Empfangs-Call sowie einen Zeitstempel mit Sekunden-Auflösung. Zur Nutzung ist keine Registrierung erforderlich, da die Adressierung - wie bei einem TNC - lediglich über eine MyCall-Eingabe im Decoder erfolgt.

Die Textnachrichten können aus bis zu 78 ASCII-Zeichen (Gross-, Kleinbuchstaben, Ziffern und fast alle Sonderzeichen) bestehen. Die Zeichen werden mit dem RADIX37-Verfahren im Verhältsnis 6 ASCII-Bytes = 4 Paketbytes auf 66% komprimiert. Mit diesem Paket können daher auch Kurzmitteilungen (HAM-SMS) gesendet werden, wie sie im AFu-Funkruf (SAMS / POCSAG) möglich sind. Eine Programmier-Schnittstelle ist in Entwicklung und die Planung sieht ein Linux-Programm vor, das via Internet von einem Funkrufmaster private User-Messages filtert, konvertiert/begrenzt und an den Telemetriecoder weiter gibt.

Zur Zeit sendet DB0SP fest vorgegebene Testrahmen mit QUA-Opcode an verschiedene reale Calls im OV-Spandau aus. Dieser Testbetrieb dient dazu die Latenzzeit bei der Übertragung festzustellen und sinnvolle Zeit-Parameter zu ermitteln, denn im Gegensatz zu einem echten Funkrufsender wird eine HAM-SMS nur dann gesendet, wenn der Relaisträger ohnehin wegen eines FM-QSOs getastet ist. Wenn das Relais im Ruhezustand ist, können natürlich keine Daten übertragen werden und es ist auch nicht vorgesehen, dies durch eine Art Bakenbetrieb zu ermöglichen! Dazu ist der normale AFu-Funkrufdienst da.

HAM-SMS ist eine Slave-Anwendung geringerer Priorität. Sie kann und soll den Standard AFu-Funkrufdienst nicht ersetzen. Der Vorteil dieses Verfahrens liegt darin, dass die Energiebilanz am Relais-Standort durch Mehrfachausnutzung der vorhandenen Sender deutlich verbessert wird. Bei einer größeren Verbreitung dieses propagierten neuen Dienstes können - bei zu vernachlässigenden zusätzlichen Stromverbrauch des Coders - Standorte reaktiviert oder mitbenutzt werden, auf denen die Energiebilanz dies z.Z. nicht gestattet.

Dekoder

Es existiert ein kleiner Testdekoder (STD), der wie ein Modem an den 9k6-Ausgang eines FM-Funkgerätes (z.B. FT8x7) angeschlossen werden kann und die dekodierten Daten an einer DSUB9-Buchse in 19k2 ausgibt. Diese Daten können mit einem beliebigen Terminalprogramm angezeigt werden.

Da das STT-Codierungsverfahren vollständig offen gelegt ist, sollte die Programmierung eines Soundkarten-Dekoders für den PC kein Problem darstellen. Entsprechende Programme sind gerne willkommen!

STT-Shield

Dieses Modul wurde für die Nutzung mit einem Arduino uno und einem LCD-Shield entwickelt. Es wird zwischen beide Module gesteckt, hat einen Mikofoneingang und einen zu den DATA-Buchsen von FT8x7 (und ähnlichen Geräten) kompatiblem Ein-/Ausgang. An das STT-Shield kann auch ein Lautsprecher angeschlossen werden. Damit lassen sich fast alle STT-Funktionen bereits mit relativ geringen Aufwand auf Direktfrequenzen nutzen. Bei den meisten FM-Relais wird jedoch der untere NF-Bereich zwischen RX und TX ab etwa 150 Hz abgeschnitten, so dass STT dort nicht übertragen werden kann. Einige Relais-TXe können darüber hinaus auch nicht bis hinab zu einigen Hz moduliert werden. Bei DB0SP und DB0BLN werden deshalb spezielle Steuersender verwendet, die theoretisch bis hinab zu 0 Hz (Gleichspannung) modulierbar sind. Das STT-Shield bildete die Grundlage des SuSE-Projekts.

SuSE

Im SuSE-Projekt wird ein vorhandenes STT-Shield zu einem vollwertigen 2m-TRX erweitert. Die Spandauer SuSE wurde als OV-interner Bausatz mit 15 Prototypen entwickelt (Selbstkosten etwa 370€/Gerät), mit dem STT sehr bequem genutzt werden kann. Auf dem Grafikdisplay des Gerätes werden die wichtigsten Telemetriedaten für den User angezeigt. Das S-Meter ist kalibrierbar und hat eine Auflösung von 1 dB. Beim Senden wird das SWR der angeschlossenen Antenne angzeigt. An einer USB-Schnittstelle können diverse Datentypen im Rohformat oder dekodiert in ASCII ausgegeben werden. Eine SuSE für das 23cm-Band ist z.Z. in der Entwicklung.

  Bild der SuSE

© DC7GB <31.12.2016>