Schicht 2: Seriell-Paket-Wandlung, Datensicherung
Links zu diesem Thema:
Allgemeines
Modulator/Demodulator
Dokumentation der Schnittstelle für das Anwenderprogramm
Anwenderprogramm "oscardata", Dokumentation folgt in Kürze ...
Das Modem, also die Übertragung via Soundkarte/Funk, bietet eine serielle Übertragung von einzelnen Bits mit entsprechender Geschwindigkeit (Bitrate). Natürlich ist die Übertragung fehlerbehaftet.
Um dieses Übertragungsmedium sinnvoll nutzen zu können brauchen wir: eine effektive Fehlerkorrektur, einen CRC um Fehler zu erkennen und eine Umwandlung von Datenpaketen in einen seriellen Bitstrom (und umgekehrt).
Das Programm qo100modem übernimmt diese Aufgabe und kümmert sich zusätzlich um das Datenmanagement:
* Schnittstelle zur Anwenderapplikation
* Schnittstelle zu Gnu Radio Modulator und Demodulator
* Seriell / Paket Umwandlung
* CRC16 Fehlererkennung
* FEC 255/32 Vorwärtsfehlerkorrektur
Aus Sicht des Anwenderprogramms gibt es zwei Funktionen:
1. Übertragung eines festen Datenblocks (z.B. Bild,
Textdatei, Binärdatei usw)
2. Übertragung eines kontinuierlichen Datenstroms, z.B. für Testzwecke
dabei werden auch ein paar Managementinformationen übertragen um den Datentyp (z.B: Bild oder HTML Datei usw) und den Status der Übertragung (Anfang, Ende) zu kennzeichnen.
Datenformat:
Übertragen werden Blöcke zu je 259 Byte (2072 bit), bei einer Nutzdatengröße von 219 Byte. Das Verhältnis vom Nutzdaten zu Gesamtdaten ist damit 84,5 : 100, wir brauchen also ca. 15% für FEC und Managementdaten.
Header:
Bei einem kontinuierlichen Bitstrom braucht man irgendeine Methode um den Anfang eines Datenblocks zu finden. Dieser Header besteht aus 3 Byte (24 bit). Da der Header nicht FEC gesichert sein darf, weil er im "Klartext" erkennbar sein muss, wird eine gewissen Toleranz eingebaut:
Von den 24 bit brauchen nur 21 bit korrekt sein um den Header als gültig zu erkennen. 21 bit bieten bereits eine sehr sichere Erkennung. Wenn also durch Übertragungsfehler maximal ein Viertel des Headers defekt wird, so hat das auf die Erkennung keinen Einfluß. Der Rest des Datenblocks genießt dann die Absicherung durch die FEC. Sollte trotzdem mal irrtümlich ein Header erkannt werden obwohl da keiner ist, so wird das vom CRC erkannt und führt zu keinem Fehler, lediglich einer minimal höheren CPU Last.
Im Bild ist noch ein 4 Byte Header eingezeichnet, dieser wurde aber in 3 Byte geändert, der gesamte Datensatz ist dadurch 258 Byte lang. Das hat einen wichigen Grund: in QPSK besteht ein ymbol aus 2 Bit, in 8PSK aus 3 Bit. Damit alle Symbole in volle Bytes passen (und wir nicht mit Bruchteilen von Byte rechnen müssen) muss die Gesamtanzahl an Bits durch 2 und durch 3 teilbar sein. Das ist bei diesen Längen der Fall.
Frame-Counter und Status:
Der Zähler wird bei Beginn einer Übertragung auf 0 gesetzt und dann automatisch bei jedem gesendeten Block um 1 erhöht. Bis die 10 Bit einen Überlauf bekommen können 1024 Blöcke oder ca. 224kByte Daten übertragen werden. Da größere Dateien wegen der Sendezeit sowieso nicht sinnvoll sind, sind alle Blöcke eindeutig durchnummeriert. Ein Anwenderprogramm kann diesen Zähler nutzen um lückenhafte Dateien bei wiederholter Übertragung zu vervollständigen.
Die beiden Statusbits zeigen den Beginn und das Ende einer Übertragung an. Damit kann das Anwenderprogramm seine Dateien öffnen und schließen sowie dem Nutzer den Stand der Übertragung anzeigen.
Ein 4 bit langes Typ-Feld wird benutzt um den Typ der Daten zu kennzeichnen, z.B. Bilder, Texte, Webseiten, Binärdateien usw.
FEC (Forward Error Correction):
Der FEC kommt eine entscheidende Bedeutung zu. Ohne diese Fehelrkorrektur wäre eine Übertragung unmöglich. Daher wurden viele verschiedene FEC Implementationen auf ihre Qualität untersucht. Eine weit verbreitete FEC wurde von K9AN entwickelt und findet sich in vielen Bibliotheken wie z.B. Liquid-SDR und anderen. Diese FEC ist ganz gut, musste sich aber schließlich geschlagen geben als ich die Schifra-FEC im Internet fand. Diese ist für OpenSource Projekte kostenfrei unter GPL 2.0 nutzbar.
Shifra-FEC hat mit weniger FEC Bytes eine deutlich bessere Korrekturqoute als alle anderen FEC Implementationen die ich getestet habe. Verglichen mit der K9AN FEC konnte nach Einbau der Shifra FEC der Empfangspegel um 6dB gesenkt werden (das ist ein Viertel) und die Daten wurden immer noch fehlerfrei restauriert. Ein weitere Vorteil ist, dass sie im Quellcode vorliegt und man so keine unbekannten Bibliotheken installieren muss.
Wer sich dfür interessiert findet die Webseite mit einer Suchmaschine durch Eingabe von "Schifra FEC".
CRC:
es wird ein CRC16 benutzt, also sind 2 Byte für den CRC reserviert. Es ist ein Standard-Algorithmus der in vielen Anwendungen zum Einsatz kommt. Ein 2 Byte langer CRC kann ab und zu (alle paar 100 Frames) ein false-positive, also eine irrtümliche OK-Erkennung auslösen. Sicherer wäre ein CRC32 mit 4 Bytes. In diesem Fall reichen ab 2 Byte, da durch weitere Tests, vor allem die FEC, die Datensicherheit so hoch ist, dass keine Fehler mehr festgestellt wurden.