Michael (DL2YMR) hat auf seinem YouTube-Kanal veröffentlicht indem er zeigt wie das Baofeng UV-5R mit Chirp programmiert wird. Bei dem Gerät handelt es sich um eines der meistverkauften Handfunkgeräte überhaupt. Die Bedienung des Geräts wird deutlich komfortabler, wenn man es personalisiert und nach eigenen Vorlieben programmiert. Michael erklärt was dazu benötigt wird und zeigt wie es funktioniert.
Beim Vernetzen von Computern via Funk kann sich die Anzahl und Auswahl der direkt erreichbaren Gegenstellen im Verlaufe der Zeit ändern: Neue Knoten können hinzukommen, bestehende entfallen oder vorübergehend unerreichbar sein. Zeitgemäße Netzwerk-Protokolle, z.B. das Internet-Protokoll (IP), in Verbindung mit geeigneten Routing-Protokollen, z.B. Babel, können die Erreichbarkeit aller Knotenpunkte eines vermaschten Funknetzes (und ggf. weiterer angeschlossener Teilnetze) ermöglichen.
Insbesondere für uns Funkamateure ist ein solcher Ansatz deshalb interessant, weil einige Stationen nicht dauerhaft zur Verfügung stehen (z.B. weil sie nur besetzt betrieben werden), sich die Anzahl von Knotenpunkten jederzeit ändern kann und Überreichweiten oder experimentelle Aufbauten bestimmte Teilnetze verbinden könnten, die ansonsten isoliert voneinander sind.
In diesem Artikel möchte ich einen Lösungsansatz zur IP-Adressvergabe und Vernetzung via IP-Routing vorstellen, der
die Eigenarten des Mediums „Funk“ berücksichtigt und
einfach einzurichten ist.
Die das Netz aufspannenden Stationen sind hierbei in einem vermaschten Netzwerk (Mesh-Netz) miteinander verbunden. Wie die dazu notwendigen Direktverbindungen aufgebaut werden können, soll nicht Teil dieses Artikels sein, wird jedoch z.B. von DL1PZ in einem anderen Beitrag behandelt. Stattdessen beschäftige ich mich hier mit der Einrichtung des Routings, so dass eine Funkstation A, die Kontakt mit einer Funkstation B hat, auch die Funkstation C erreichen kann, falls die Stationen B und C eine Verbindung haben. Auch eine Weiterleitung über mehr als eine Zwischenstation (genannt: „Hop“) ist so möglich.
Dezentrale IP-Adressvergabe
In einem IP-Netzwerk werden die Teilnehmer mittels sogenannter IP-Adressen angesprochen. Im Falle von IPv4, der älteren Version des Internet-Protokolls, sind dies vier Zahlen von 0 bis 255 getrennt durch Punkte, also z.B. „10.169.145.125“. Bei IPv6 kommen längere Adressen zum Einsatz, die in hexadezimaler Schreibweise notiert werden, z.B. „fdb7:5c3c:1e90:e4c1:0000:0000:00d5:85ed“. Die Punkte bzw. Doppelpunkte dienen nur der Lesbarkeit bei Darstellung in Textform und werden bei einer binären Übertragung nicht mitgesendet. Zur Vereinfachung besteht bei IPv6 die Möglichkeit, mittels eines doppelten Doppelpunktes „::“ die Auslassung mehrerer 0000-Blöcke zu kennzeichnen. Außerdem ist es möglich, führende Nullen innerhalb eines Vier-Zeichen-Blockes wegzulassen, so dass vorstehende Adresse auch verkürzt als „fdb7:5c3c:1e90:e4c1::d5:85ed“ geschrieben werden könnte.
Um eine zentrale Adressvergabe zu vermeiden, aber gleichzeitig jedem Teilnetz (einschließlich vorübergehend isolierter Netze) permanente Adressen zuweisen zu können, die dennoch mit hoher Wahrscheinlichkeit im Rahmen des Einsatzzweckes eindeutig sind, wird IPv6 genutzt. IPv6 ermöglicht es aufgrund der vergleichsweise langen Adressen, einfach einen zufälligen Adressbereich zu wählen, der dann mit großer Wahrscheinlichkeit eindeutig ist. Genau dies ist bei IPv6 im Rahmen der sogenannten „Unique Local Addresses“ (ULA) auch vorgesehen: Jede Person oder Organisation, die einen Adressbereich benötigt, erzeugt einfach eine 40 Bit lange Zufallsfolge. Wird dieser noch die Bitfolge 11111101 (hexadezimal „fd“) vorangestellt, ergeben sich 48 Bit, die den sogenannten „Präfix“ für den Adressbereich bilden. Die Person bzw. Organisation, die sich diesen Adressbereich zufällig ausgesucht hat, kann nun alle damit beginnenden Adressen beliebig verwenden, ohne große Gefahr zu laufen, mit den Adressen zu kollidieren, die andere Personen oder Organisationen verwenden. Ein solcher Präfix wird z.B. als fd4a:eeb2:7cea::/48 notiert, wobei 48 die Präfixlänge in Bits in dezimaler Schreibweise darstellt.
Die Wahrscheinlichkeit einer Kollision, d.h. die Wahrscheinlichkeit, dass in einem Netzwerk der gleiche Präfix zweimal vergeben wird, steigt zwar vergleichsweise schnell mit der Anzahl der vergebenen Präfixe (vgl. Geburtstagsparadoxon), allerdings beträgt z.B. bei 10.000 solcher miteinander vernetzten Präfixe die Kollisionswahrscheinlichkeit aufgrund der vielen Möglichkeiten (2 hoch 40 = 1.099.511.627.776) immer noch weniger als 0,05 Promille, also etwa 1:20.000. Verglichen mit anderen potentiellen Störungsursachen scheint dies vernachlässigbar klein zu sein. Die Berechnungsformeln für die Kollisionswahrscheinlichkeit sind identisch mit denen der sogenannten Geburtstagsangriffe, wobei wir hier vom wohlwollenden Verhalten aller Teilnehmer ausgehen.
Sobald ein 48-Bit langer IPv6-Adress-Präfix per Zufall ermittelt wurde, können, wie zuvor erwähnt, aus dem sich ergebenden Bereich beliebige IP-Adressen gewählt werden, z.B. die Adresse
fd4a:eeb2:7cea:0000:0000:0000:0000:0001
welche in verkürzter Schreibweise als fd4a:eeb2:7cea::1 geschrieben werden kann. Auch ist es möglich ganze Netzbereiche unterzuverteilen.
Unter Linux lässt sich dann beispielsweise diese Adresse einem Funk-Interface (hier im Beispiel tun0) wie folgt zuweisen:
ip -6 addr add fd4a:eeb2:7cea::1/128 dev tun0
Die 128 steht hierbei für eine Präfixlänge von 128 Bit, d.h. wir teilen dem Betriebssystem mit, dass zunächst keine andere Adresse via Funk erreichbar ist. Welche anderen Adressen wir tatsächlich erreichen können, wird dem Betriebssystem vom Routing-Dienst mitgeteilt, der im Folgenden beschrieben werden soll.
Der Routing-Dienst „babeld“
Sofern die Installation von „babeld“ in aktueller Version nicht durch das Paketmanagement des Betriebssystems erfolgen kann, finden sich Hinweise zum Download der Software auf der Homepage des Babel-Projektes.
Die folgenden Beschreibungen beziehen sich auf die zum Zeitpunkt der Veröffentlichung dieses Artikels aktuelle Version 1.9.2 der Software. Es gibt auch andere Routing-Software, z.B. BIRD, die das Babel-Protokoll ebenfalls umsetzen kann. Diese sollte ebenso eingesetzt werden können, ist aber anders zu konfigurieren.
Die Einrichtung von „babeld“ gestaltet sich sehr einfach. Wir legen dazu die Konfigurationsdatei /etc/babeld.conf an. Für den Fall, dass wir unseren Präfix wie im vorhergehenden Abschnitt als fd4a:eeb2:7cea::/48 festgelegt hätten (in der Praxis muss dies natürlich ein eigener, zufälliger Präfix sein), sähe die Datei wie folgt aus:
in ip fd00::/8 allow
in deny
out ip fd00::/8 allow
out deny
redistribute ip fd4a:eeb2:7cea::/48 local
redistribute ip fd4a:eeb2:7cea::/48 metric 256
redistribute local deny
redistribute deny
Den Routing-Dienst können wir dann z.B. mit folgendem Kommando starten:
babeld -c /etc/babeld.conf wl3sp0
Hierbei wäre wl3sp0 das Funk-Interface, mit dem die Vernetzung erfolgt. (Mit „ip link show“ lassen sich alle verfügbaren Interfaces anzeigen.) Wird, wie in diesem Beispiel, ein WLAN-Interface (wl3sp0) verwendet, kann babeld anhand der Hardwarekonfiguration selbst erkennen, dass eine Funkverbindung vorliegt. Wird stattdessen eine Vernetzung mittels einer schmalbandigen Verbindung über ein herkömmliches Funkgerät vorgenommen, kommt oft ein generischer TUN-Gerätetreiber zum Einsatz, bei dem die automatische Erkennung nicht möglich ist. Hier sollten wir nachhelfen, z.B. mit:
So sagen wir dem Routing-Dienst, dass es sich bei der verwendeten Netzwerkschnittstelle um eine Funkverbindung handelt („type wireless“), die sich ggf. mit anderen Funkverbindungen einen Kanal teilt („channel interfering“) und das Kommunikationsintervall für eine schonendere Bandbelegung reduziert wird („hello-interval 60“). Anstelle der Option „-C“ lässt sich der auf diese Option folgende Text („interface tun0 […]“) auch als eigene Zeile in die Konfigurationsdatei schreiben. (Details hierzu in der Anleitung von babeld.)
Falls wir Pakete für andere Funkknoten weiterleiten wollen (was ja Sinn und Zweck eines Mesh-Netzes ist), müssen wir unserem Betriebssystem noch mitteilen, dass Packet-Forwarding (also Routing) aktiviert werden soll. Dies lässt sich z.B. für IPv6 unter Linux bis zum nächsten Neustart mit folgendem Kommando einschalten:
sysctl -w net.ipv6.conf.all.forwarding=1
Soll Packet-Forwarding dauerhaft aktiviert bleiben, so ist die Datei /etc/sysctl.conf entsprechend zu bearbeiten.
Sicherheitsbedenken
Sobald wir Routing auf unserem Computer aktivieren, wird dieser beliebige Pakete weiterleiten. Es wäre dann also auch möglich, via Amateurfunk auf ein ebenfalls angeschlossenes privates Heim- oder Firmennetz (oder das Internet) zuzugreifen, was in der Regel nicht erwünscht sein wird. In einem solchen Fall ist also unbedingt eine Firewall einzurichten, deren Konfiguration hier nicht weiter behandelt werden soll und vom konkreten Szenario abhängt.
Ebenso sollte verhindert werden, dass der Routing-Dienst über Funk Einträge für unser privates Netz akzeptiert. Liegt unser privates Netz außerhalb des ULA-Adressbereiches (beginnt also nicht mit hexadezimal „fd“), dann sorgt die oben vorgestellte Konfiguration bereits automatisch dafür, dass entsprechende Routing-Informationen abgelehnt werden. Verwenden wir bei unserem privaten Heim- oder Firmennetz jedoch ebenfalls ULAs, dann müssen wir dem Routing-Dienst noch mitteilen, dass für diese Adressen keine Informationen aus dem Funknetz angenommen werden sollen. Dies lässt sich, z.B. wenn fdf2:c215:20a4::/48 unser privates Netz sei, mit der Zeile
in ip fdf2:c215:20a4::/48 deny
an oberster Stelle in der /etc/babeld.conf erreichen.
Einen zusätzlichen Filter für die ausgehende Richtung benötigen wir nicht. Wir haben bereits vermerkt, für welche Netzwerke wir Routing-Informationen einspeisen wollen („redistribute ip fd4a:eeb2:7cea::/48 […]“). Für alle anderen Netzwerke haben wir festgelegt, dass diese von babeld nicht eingespeist werden („redistribute local deny“ und „redistribute deny“).
Anbindung von weiteren angeschlossenen Geräten über den selben Funkknoten
Der Zugriff auf bestimmte lokale IP-Adressbereiche kann aber durchaus auch erwünscht sein, denn vielleicht möchten wir nicht nur ein einzelnes Gerät an das Funknetz anbinden, sondern ein ganzes Netzwerk. Die bereits erwähnte Konfigurationszeile „redistribute ip […] metric 256“ (ohne die Option „local“) ermöglicht die Einspeisung von IP-Adressen, die nicht dem eigenen Endgerät, sondern anderen Endgeräten zugehörig sind.
Die Zahl 256 gibt hier die sogenannte Metrik an, die ein Maß für die Güte der Anbindung eines Netzwerks ist. Dieser Wert ist dann von Bedeutung, wenn ein Netzwerk auf verschiedenen Wegen erreichbar ist, z.B. weil es mit mehreren Funkknoten direkt verbunden wird. Dann kann bei jedem dieser Funkknoten ein unterschiedlicher Wert für dieses Netzwerk festgelegt werden, wobei ein niedrigerer Wert für eine höhere Güte der Anbindung steht. In einfachen Fällen, also bei Netzwerken ohne Mehrfachanbindung, können wir einfach 256 festlegen.
Für die lokale Vernetzung können wir nun einen Unterbereich des Adressraumes ausweisen, z.B. fd4a:eeb2:7cea:5555::/64. Unserem eigenen Netzwerk-Interface (also z.B. unserer Netzwerkkarte) weisen wir eine IP aus diesem Unteradressraum zu und geben mit der Präfixlänge /64 an, dass weitere Adressen aus dem gleichen Unteradressraum (beginnend mit den 64 Bits fd4a:eeb2:7cea:5555) direkt zu erreichen sind. Heißt unser Netzwerk-Interface für kabelgebundenes Ethernet z.B. „enp0s25“, so wäre das Kommando hierfür:
ip -6 addr add fd4a:eeb2:7cea:5555::1/64 dev enp0s25
Andere Geräte am gleichen Ethernet-Segment können dann z.B. die Adressen mit der 2, 3, 4 usw. am Ende zugewiesen bekommen, also z.B. die fd4a:eeb2:7cea:5555::4, und sind dann aus dem Funk-Mesh-Netz erreichbar. Diesen Geräten muss jetzt nur noch mitgeteilt werden, dass Pakete an fd00::/8 (also Adressen beginnend mit „fd“) über unseren Funkknoten mit der IP fd4a:eeb2:7cea:5555::1 geroutet werden müssen, sofern für diese keine andere Route existiert. Hierzu ist das Routing der Geräte entsprechend einzustellen oder ggf. eine Default-Route zu setzen. Wie dies funktioniert, hängt vom Betriebssystem des jeweiligen Endgerätes ab. Auch ließe sich ein DHCPv6-Server verwenden, dessen Konfiguration jedoch den Rahmen dieses Artikels sprengen würde.
IPv6 und die Paketgröße (MTU)
Leider sieht IPv6 vor, dass auf jeder Verbindung mindestens Pakete der Größe 1280 Byte übertragen werden können. Dies ist die minimal mögliche Einstellung der sogenannten „Maximum Transmission Unit“ (MTU). Eine Fragmentierung, d.h. Aufteilung in kleinere Pakete, ist durch Router auf dem Transportweg bei IPv6 im Gegensatz zu IPv4 nicht vorgesehen (siehe RFC 8200, Sektion 5). Das kann zu Schwierigkeiten z.B. bei bestimmten Hardware-TNCs führen, die Pakete dieser Größe nicht handhaben können. Umgehen ließe sich dieses Problem mit einer zusätzlichen Fragmentierungsschicht, die aus Sicht von IPv6 unsichtbar sein müsste. Die von DL1PZ vorgestellten Programme ermöglichen keine zusätzliche Fragmentierung, jedoch sind die dort vorgestellten Software-TNCs Dire Wolf und pktfec-tnc ohne Probleme in der Lage, größere Pakete auf’s Band zu senden.
Skalierbarkeit
Da jeder Knoten in regelmäßigen Abständen Informationen zu allen erreichbaren Adressbereichen mit allen direkten Nachbarknoten austauschen muss, skaliert das hier vorgestellte Verfahren nicht beliebig. Mit wachsender Knotenanzahl wird die Menge an zu übertragenden Informationen ebenfalls wachsen. Bei langsamen Packet-Radio-Verbindungen dürften bereits bei einer zweistelligen Anzahl von Netzknoten Probleme auftreten. Weniger problematisch wäre dies bei einer Vernetzung mit schnellerer Technik.
Um dieses Problem zu lösen bzw. zu umgehen, sehe ich verschiedene Alternativen:
Mesh-Netze bleiben lokal begrenzt und werden mit anderen Mesh-Netzen ausschließlich manuell verbunden. Routing-Informationen zu anderen Mesh-Netzen werden nur für das gesamte jeweils andere Mesh-Netz in das eigene Mesh-Netz eingespeist, so dass jedes andere Mesh-Netz nur mit einem einzigen Präfix in den Routing-Tabellen auftaucht, was die Routing-Tabellen kleiner hält. Damit dies funktioniert, müssten die einzelnen lokalen Mesh-Netze jedoch jeweils einen gemeinsamen Präfix verwenden und sich dann auf eine Vergabemethode von IP-Adressen innerhalb ihres jeweiligen Präfixes einigen.
Mesh-Netze bleiben lokal begrenzt und werden untereinander über sogenannte Border-Router und ein Backbone verbunden. Routing-Informationen zu anderen Mesh-Netzen werden gar nicht im eigenen Mesh-Netz verbreitet. Stattdessen werden die Border-Router als zuständig für den Bereich fd00::/8 angegeben.
Das Routing-Protokoll wird erweitert (bei Babel grundsätzlich vorgesehen), oder ein anderes, zukünftiges Routing-Protokoll wird benutzt, das solche Szenarien noch besser abbilden kann.
Fazit und Ausblick
Es macht Spaß, mit Ad-hoc-Vernetzung zu experimentieren. IPv6 ermöglicht es, ohne zentrale Koordinierung feste IP-Adressen zu verwenden. Mit dem Routing-Protokoll Babel bzw. der Software „babeld“ und IP-Packet-Forwarding können wir eine automatische Vernetzung vornehmen lassen. Inwieweit sich diese Verfahren im größeren Maßstab in der Praxis, insbesondere bei langsamen Packet-Radio-Verbindungen, einsetzen lassen, bleibt zu erforschen.
Wenn im Zusammenhang mit dem Amateurfunk von IP-Vernetzung die Rede ist, werden viele sicherlich zuerst an das HAMNET denken, ein Hochgeschwindigkeitsnetzwerk auf IP-Basis. Doch darum soll es in diesem Artikel gar nicht gehen. Denn obwohl die Möglichkeiten des HAMNET, insbesondere die verfügbaren Datenraten, überzeugend sind, gibt es doch einige praktische Einschränkungen. Die vermutlich größte Hürde in das HAMNET einzusteigen sind die Ausbreitungseigenschaften des hierfür verwendeten 2,4 GHz-Bandes. Ohne direkten Sichtkontakt geht da nicht viel. Das heißt in der Praxis: Eine flächendeckende Versorgung mit HAMNET steht in ländlichen genauso wie städtischen Gebieten noch in den Sternen, obwohl bereits ein erheblicher Aufwand getrieben wurde, um sogenannte Benutzereinstiege bereitzustellen. Auch der neuerdings zusätzlich verfolgte Ansatz mit Breitbanddatenübertragungen auf dem 70cm-Band mittels NPR70 findet seine Grenzen in dem knappen zur Verfügung stehenden Frequenzspektrum, das sich viele Anwendungen teilen müssen.
Deshalb haben Silvio DM9KS, Jan DL9JBE und Björn DL1PZ in den letzten zwei Jahren diverse Versuche zur IP-Vernetzung unternommen und dabei “normale” Funkkanäle verwendet. Es wurden FM-Verbindungen mit 7 bzw. 12,5 kHz Kanalbreite auf dem 10m-, dem 2m- und dem 70cm-Band genutzt. Die dort erreichbaren Datenraten kommen natürlich nicht an die Geschwindigkeiten des HAMNET heran. Dafür sind aber IP-Verbindungen auch unter wesentlich widrigeren Funkbedingungen überhaupt herstellbar. In diesem Artikel sollen die verschiedenen Hard- und Softwarekomponenten bzw. Protokolle vorgestellt werden, die im Rahmen der Versuche erprobt wurden.
Schematischer Versuchsaufbau
Versuchsaufbau
Der grundsätzliche technische Aufbau folgte stets dem gleichen Schema. Eine oder mehrere IP-fähige Anwendungen (z. B. IRC-Chatprogramme, Telnet, Schachprogramme, usw.) erzeugen IP-Datenpakete. Diese werden durch einen Einpacker um ein Rufzeichen und Protokollinformationen ergänzt an einen Terminal Node Controller (TNC) weitergegeben, der die Datenpakete für die Übertragung auf dem Band vorbereitet und dann über eine Audioschnittstelle an einen Transceiver übergibt. Empfangene Übertragungen werden andersherum durch den Transceiver über die Audioschnittstelle an den TNC zur Dekodierung übergeben. Dann werden Rufzeichen und Protokollinformationen durch den Auspacker entfernt und die empfangenen Nutzdaten als IP-Paket (über das Betriebssystem) an die IP-Anwendung weitergegeben.
In dem immer gleichen Schema war – neben der Verwendung von IP – die Konstante bei allen Versuchen das sogenannte KISS-Protokoll, auf das später noch eingegangen wird. Alle anderen Komponenten wurden in den Versuchen durch wechselnde Hard- bzw. Software implementiert.
AX.25
Der älteste Vertreter der Lösungen zur IP-Vernetzung über den Amateurfunk ist das AX.25-Protokoll. Dieses ursprünglich für Packet-Radio geschaffene Protokoll bringt auch die Möglichkeit des Transports von IP-Paketen mit. AX.25 ist ein umfassendes Netzwerkprotokoll, das selber auch ganz ohne IP-Netzwerk in der Lage ist, Computer und angebotene Dienste (wie Mailboxen) zu verbinden. Bis zum Ende des letzten Jahrtausends wurde es bei Funkamateuren rege genutzt und es bestand praktisch flächendeckender Zugang zum Packet-Radio-Netzwerk über Funk.
Das Protokoll enthält eine Vielzahl an Funktionen, z. B. zu Multiplexing, Flusskontrolle oder Routing, die für die IP-Vernetzung jedoch keine Rolle spielen. Diese Aspekte werden bereits von IP (bzw. genau genommen TCP/IP) selber gelöst. Daher beschränkt sich dieser Artikel auf die für den Anwendungsfall relevanten Teile von AX.25.
Im Folgenden wird nur der Sendeweg beschrieben. Der Empfangsweg verhält sich entsprechend genau andersherum. Das heißt die sendeseitig hinzugefügten Informationen werden in umgekehrter Reihenfolge wieder entfernt bzw. die vor der Aussendung vorgenommene Modulation wird entsprechend demoduliert.
AX.25 definiert gleich zwei der im schematischen Aufbau dargestellten Komponenten: Den Ein- und Auspacker für IP-Pakete sowie den TNC (aber nicht das Modem). Im AX.25-Protokoll ist diese Aufgabentrennung zwar überhaupt nicht vorgesehen, doch in der Praxis ist sie weit verbreitet. Auch das KISS-Protokoll ist nicht Teil von AX.25, doch dazu – wie schon versprochen – später mehr.
Bei den ersten Versuchen wurde die in Linux eingebaute AX.25-Unterstützung verwendet, um IP-Pakete ein- bzw. wieder auszupacken. Praktisch passiert dabei folgendes: Zu jedem IP-Paket, das auf die Funkschnittstelle gesendet werden soll, werden zunächst zusätzliche Informationen hinzugefügt, bevor das Paket an den TNC übergeben wird. Hierzu werden zwei der durch AX.25 spezifizierten Funktionalitäten genutzt, nämlich die Adressierung und die Protokollidentifikation.
Rufzeichen und Protokollidentifikation
AX.25 verwendet Amateurfunkrufzeichen, um den Absender und den oder die Empfänger einer Übertragung anzugeben. Zur Unterscheidung mehrerer Stationen des gleichen Rufzeicheninhabers ist es vorgesehen, optional eine Zahl von 1 bis 15 als sogenannten „Secondary Station Identifier“ („SSID”) anzuhängen, z. B. DL1PZ-14. Die Kodierung des Rufzeichens erfolgt als 7-Bit-ASCII-Zeichenkette, wobei das jeweils freibleibende 8. Bit anderweitig genutzt wird. Die Erzeugung und Verarbeitung gestaltet sich daher etwas komplizierter, zudem die sieben ASCII-Bits auch noch um ein Bit zur Seite verschoben werden. AX.25 beschränkt die Länge der Rufzeichen strikt auf 6 Zeichen, was die Verwendung von längeren Rufzeichen (z. B. Sonderrufzeichen) leider vollkommen unmöglich macht. AX.25 sieht als Adressangabe mindestens eine Absender- und eine Zieladresse vor.
In der AX.25-Konfiguration von Linux wurde jeweils das eigene Rufzeichen hinterlegt. Dieses wird dann automatisch zu jedem Paket hinzugefügt. Da AX.25 zwingend auch eine Empfängeradresse vorschreibt, welche jedoch für die IP-Vernetzung nicht nötig ist, wird das entsprechende Feld durch Linux automatisch mit dem Text “QST” belegt. Diese Q-Gruppe steht in CW für eine Sendung an alle Stationen.
Weiterhin setzt AX.25 noch einen sogenannten “Protocol identifier” (“PID”) vor die eigentlichen Nutzdaten. Im behandelten Falle, also der Übertragung von IP-Paketen, wird hier hexadezimal 0xCC für IPv4 vermerkt. Ein PID für IPv6 ist in der letzten Version 2.2 des AX.25-Standards nicht vorgesehen. Dementsprechend kann mit diesem Ansatz auch keine Vernetzung per IPv6 sondern nur per IPv4 vorgenommen werden.
PicoAPRS – TNC und Transceiver in einem Gerät
KISS-Protokoll
Nachdem nun diese beiden Informationen hinzugefügt wurden, wird das Datenpaket an den TNC weitergegeben. Dazu wird das schon erwähnte KISS-Protokoll verwendet, meist über eine serielle Schnittstelle. Dieses ist mit dem SLIP-Protokoll verwandt, bei dem bestimmte Steuerzeichen einen seriellen Datenstrom in einzelne Pakete unterteilen. Die Abkürzung KISS bezieht sich hier auf das sogenannte KISS-Prinzip, Dinge einfach zu halten (engl. “Keep it simple, stupid!”, zu Deutsch also “Halte es einfach, Dummerchen!” oder etwas sachlicher formuliert: “Mach’ eine Sache nicht komplizierter als nötig”). Entsprechend ist das Protokoll auch überschaubar definiert. Am Anfang und am Ende der Übertragung wird jeweils ein Byte mit dem hexadezimalen Wert 0xC0 als Begrenzung eines Datenpakets angefügt. Sofern in den Daten selber der Wert 0xC0 vorkommt, wird dieser durch die Bytefolge 0xDB 0xDC ersetzt. Wenn wiederum ein 0xDB vorkommt, wird dieses durch die Folge 0xDB 0xDD ersetzt.
TNC für AX.25
Die Aufgabe des TNC ist es nun, das Datenpaket für die Übertragung auf der Funkschnittstelle vorzubereiten. Ein für AX.25 ausgelegter TNC erledigt dabei zunächst die folgenden Aufgaben:
Bitstopfen (engl. “bit stuffing”): Das Einfügen von einem oder mehreren Füll-Bits in einen Datenstrom. Im Falle von AX.25 konkret das Einfügen eines zusätzlichen 0-Bits, falls fünf 1-Bits unmittelbar aufeinander folgen.
Rahmensynchronisation: Dient dem Erkennen von Anfang und Ende eines AX.25-Datenpakets (streng genommen gemäß OSI-Schichtmodell als “Datenframe” zu bezeichnen). Konkret beginnt und endet jedes AX.25-Datenframe mit der Bit-Folge 01111110 (hexadezimal 0x7E). Daher auch das vorgenannte Bitstopfen, das sicherstellt, dass diese Sequenz niemals innerhalb der tatsächlich übertragenen Nutzdaten vorkommt, sondern nur als Rahmensynchronisation.
Fehlererkennung: Das Erkennen von Übertragungsfehlern (z. B. aufgrund von Störungen auf dem Band) durch den Empfänger. Hierzu fügt der Sender im Falle des AX.25-Protokolls vor dem Ende eines jeden Datenframes (unmittelbar vor der Rahmensynchronisation) eine Prüfsumme ein, die vom Empfänger kontrolliert werden kann.
Als letzten Schritt der Vorbereitung führt das im TNC integrierte Modem nun die Modulation durch. Dieser Schritt ist nicht mehr Teil der AX.25-Spezifikation. Aus der langjährigen Praxis des Betriebs von Packet-Radio haben sich jedoch zwei Varianten der Modulation herauskristallisiert: Einerseits AFSK mit 1200 Baud entsprechend des Half-Duplex-Modus der Bell-202-Modem-Spezifikation und andererseits FSK mit 9600 Baud nach G3RUH. Praktisch alle Hardware-TNCs unterstützen eines dieser beiden Verfahren. Software-Lösungen bieten hingegen neben diesen beiden Verfahren auch noch eine Reihe weiterer Modulationsarten.
Anschluss an das Funkgerät
Für die Verbindung zwischen dem TNC und dem Funkgerät wird eine herkömmliche analoge Audioverbindung genutzt. Fast jedes Funkgerät verfügt über einen Anschluss für Mikrofon und externen Lautsprecher, welche mit dem TNC verbunden werden können. Im Falle von Software-TNCs ist entsprechend die Soundkarte des Computers mit dem Funkgerät zu koppeln.
Manche hochwertigere Funkgeräte verfügen auch über einen sogenannten 9600-Port. Dieser bietet einen Ein- und Ausgang für Audiosignale, bei denen das Signal jedoch an den üblichen NF-Filtern (Bandpass) vorbeigeführt wird und somit ein größeres Frequenzspektrum durchgelassen werden kann. Der Verzicht auf Filter vermeidet außerdem ein nichtlineares Verhalten hinsichtlich des Phasenganges und stellt damit eine einheitliche Verzögerung des gesamten Signals unabhängig von den übertragenen NF-Frequenzen sicher. Mit einem 9600-Port ist es einfacher, hohe Datenübertragungsraten zu erreichen. Dieser Anschluss ist die Voraussetzung für die Verwendung eines 9600-Baud-Modems nach G3RUH.
Ein Baofeng UV-5R mit Audio-Datenkabel
Audiopegel
Grundsätzlich gilt: Der Audioausgang des TNCs oder – im Falle eines Software-TNCs – des Computers ist mit dem Audioeingang des Funkgeräts und andersherum der Audioausgang des Funkgeräts wiederum mit dem Audioeingang von TNC bzw. Computer zu verbinden.
In der Praxis hat es sich als sehr wichtig herausgestellt, die Audio-Lautstärke in beide Richtungen korrekt einzupegeln. Sendeseitig sollte die in das Funkgerät eingegebene Audiolautstärke so gewählt sein, dass sie so laut wie möglich ist ohne das es zu Verzerrungen des Signals kommt. Bei Geräten mit eingebautem Audio Level Controller (ALC) kann dies leicht erreicht werden, indem die Lautstärke soweit angehoben wird, dass die ALC-Anzeige gerade so nicht ausschlägt. Empfangsseitig sollte die Lautstärke so eingestellt werden, dass die empfangenen Signale keinesfalls übersteuern.
Verbesserungspotential von AX.25-TNCs
Bei den Versuchen wurden unterschiedliche AX.25-TNCs verwendet. Eine Besonderheit war dabei der PicoAPRS, der TNC und Transceiver zu einem winzigen Gerät vereint. Als reine Software-Lösung kam immer wieder Dire Wolf zum Einsatz.
Leider sieht AX.25 für die Fehlererkennung lediglich eine 2 Byte lange CRC-Prüfsumme vor. Diese erlaubt es mit relativ hoher Wahrscheinlichkeit, eine fehlerhafte Übertragung als solche zu erkennen. Die Möglichkeit einer Fehlerkorrektur, weil z. B. der Kanal kurz gestört war, erlaubt dies aber nur sehr eingeschränkt. Der technische Stand dazu hat sich seit der Spezifikation von AX.25 aber deutlich weiterentwickelt.
So unterstützt der Software-TNC Dire Wolf schon seit einiger Zeit eine Fehlerkorrektur mittels Reed-Solomon-Codes. Diese Fehlerkorrektur kommt in einem zu AX.25 rückwärtskompatiblen Kodierungsverfahren mit der Bezeichnung FX.25 zum Einsatz. Dem aktuellen Stand der Technik entspricht dies jedoch auch noch nicht.
Ein heute übliches Verfahren zur Fehlererkennung und auch -korrektur sind sogenannte Low-Density-Parity-Check-Codes (LDPC), die z. B. bei DVB-S2 oder FT8 verwendet werden. Jan DL9JBE hat sich mit diesem Verfahren näher beschäftigt und dabei die experimentelle Software pktfec-tnc entwickelt. Das ist ein Software-TNC, der dieses Verfahren zur Fehlerkorrektur einsetzt. Da pktfec-tnc ebenfalls die KISS-Schnittstelle verwendet, kann es einfach anstelle eines AX.25-TNC verwendet werden. Als Modulation zur Übergabe per Audiokanal an das Funkgerät wird Quadraturamplitudenmodulation (QAM) verwendet, welche hinsichtlich Symbolrate (Baudrate) und Symbolanzahl (Bits je Symbol) relativ frei konfiguriert und somit an die Kanaleigenschaften angepasst werden kann. Die genauen technischen Hintergründe hat Jan im Artikel Schnellere Datenübertragung ohne Data-Port beschrieben. Praktisch gibt es also mehrere Methoden wie sich das AX.25-typische Ein- und Auspacken von IP-Paketen mit einem modernen TNC verbinden lässt.
Einschränkungen von AX.25
Aber auch bei der Verwendung von AX.25 für das Ein- und Auspacken von IP-Paketen stellten sich einige praktische aber auch theoretische Probleme. Wie bereits erwähnt unterstützt AX.25 ausschließlich IPv4 und ist nicht auf IPv6 vorbereitet. Das ist auch nicht verwundernswert, da das letzte Update des AX.25-Standards aus dem Jahre 1998 stammt, dem gleichen Jahr in dem IPv6 erstmals spezifiziert wurde. Leider scheint AX.25 IP-Datenpakete praktisch auch auf eine maximale Länge von 255 Bytes zu beschränken. Dies würde die Ergänzung einer IPv6-Unterstützung erschweren. Denn IPv6 verlangt, dass jeder Übertragungsweg darauf vorbereitet ist, Pakete mit 1280 Byte Länge zu unterstützen. Es wäre also nötig, einen neuen Mechanismus zur Aufteilung größerer Datenpakete in mehrere Teilpakete zu implementieren.
Bei der Adressierung ist AX.25 für den vorgesehenen Anwendungsfall nur eingeschränkt geeignet bzw. ineffizient. Eigentlich wird nur eine Angabe das Rufzeichens der Sendestation benötigt. AX.25 verlangt jedoch zusätzlich auch zwingend die Angabe eines Zielrufzeichens. Neben der erwähnten unpraktischen um ein Bit verschobenen Kodierung kommt erschwerend noch hinzu, dass AX.25 für das Absender- wie Empfängerrufzeichen jeweils eine feste Breite von 6 Zeichen zuzüglich SSID vorsieht und dafür jeweils 7 Byte benötigt. Das führt einerseits dazu, dass auch bei kurzen Rufzeichen stets 14 Byte für die Adressierung verbraucht werden. Anderseits macht es die Nutzung von Sonderrufzeichen unmöglich, die länger als 6 Zeichen sind.
Abschließend sei noch erwähnt, dass keine Umsetzung von AX.25-IP-Vernetzung für andere Betriebssysteme als Linux gefunden werden konnte. Damit war dann z. B. das von DL9JBE benutzte FreeBSD außen vor. Eine Portierung erschien aufgrund der Mängel hinsichtlich IPv6 und der Adressierung sowie der Gesamtkomplexität des Standards nicht vielversprechend.
Debugging von IP-Verbindungen mit dem Netzwerkanalyse-Werkzeug Wireshark
Alternativen zum Verpacken von IP-Paketen
Eine weitere Möglichkeit zum Ein- und Auspacken der IP-Pakete ist tncattach, welches auf einfache Art und Weise die beiden Aufgaben der Rufzeichennennung und Protokollidentifikation übernimmt und die Daten per KISS-Protokoll an einen TNC weiterreicht. Um IPv4 bzw. IPv6-Pakete zu kennzeichnen, stellt tncattach die zwei Byte lange Markierung gemäß dem Ethernet-Standard IEEE 802.3 vor jedes Paket, also hexadezimal 0x08 0x00 für ein IPv4- und 0x86 0xDD für ein IPv6-Paket. Es werden vorab noch 2 weitere Bytes hinzugefügt, die Linux-spezifisch definiert sind, deren genauer Zweck sich im Rahmen der Versuche nicht erschlossen hat. Die Rufzeichennennung erfolgt bei tncattach nicht in jedem Paket. Stattdessen werden von Zeit zu Zeit separate Datenpakete erzeugt, die nur das Rufzeichen erhalten. Das bietet den Vorteil, dass bei jeder Übertragung einige Byte eingespart werden können.
Die Software tncattach ist für die reine IP-Vernetzung gegenüber AX.25 als Fortschritt anzusehen. Die Funktionalität beschränkt sich weitgehend auf die IP-Vernetzung (zusätzlich ist auch die Vernetzung auf Ethernet-Ebene möglich) und IPv6 wird unterstützt. Rufzeichen werden ohne Bitverschiebung kodiert, also im Klartext. Es ist nur das Rufzeichen der Sendestation anzugeben und lange Sonderrufzeichen stellen auch kein Problem dar.
Nicht so gut gefallen hat, dass das Rufzeichen nicht in jedes Paket einkodiert wird. Rein formal wird das die Verpflichtung zur Rufzeichennennung im Amateurfunk möglicherweise erfüllen. Zumindest praktisch ist es so aber nicht ohne weiteres möglich, jede Sendung klar zuzuordnen. Es ist nicht erkennbar, welches IP-Datenpaket zu welchem Rufzeichen-Paket gehört. Eine Zuordnung wie im Sprechfunk anhand der Stimme ist ja nicht möglich.
Als größter Nachteil wurde allerdings festgestellt, dass tncattach ausschließlich für Linux entwickelt wird. Nach einer kurzen Betrachtung des Quellcodes ist der Eindruck entstanden, dass eine Portierung auf andere Betriebssysteme bisher leider nicht vorgesehen ist.
hamtunnel
Eine weitere Alternative zum Verpacken von IP-Paketen hat Jan DL9JBE als Ergänzung zu pktfec-tnc implementiert und dabei folgende Design-Kriterien zugrunde gelegt:
Unterstützung für Linux und FreeBSD
Kompatibilität zum KISS-Protokoll, um bestehende TNCs nutzen zu können
Einfaches Protokoll, das leicht für den Menschen lesbar ist
Rufzeichennennung in jedem Paket im Klartext
Unterstützung beliebig langer Rufzeichen (auch z. B. Rufzeichen aus dem CB-Funk oder anderen Funkdiensten)
Die Software heißt hamtunnel und ist kann zusammen mit pktfec-tnc heruntergeladen werden. Genauso wie AX.25 und tncattach übernimmt hamtunnel die Anreicherung von IP-Paketen um eine Protokollinformation und das Rufzeichen. Dazu wird vor jedes Datenpaket als erstes das Rufzeichen in beliebiger Länge im ASCII-Klartext vorangestellt und mit einem Null-Byte (also hexadezimal 0x00) abgeschlossen. Es folgt dann die Markierung des IP-Protokolls im Klartext. Konkret wird die Zeichenfolge “IP4” bzw “IP6” verwendet, die sich von selber erklären dürften. Auch diese Sequenz wird mit einem Null-Byte abgeschlossen. Im Anschluss folgt unverändert das eigentliche IP-Paket.
Lesbarkeit von Daten für den Menschen
Die Lesbarkeit von Daten für den Menschen ist dabei ein interessanter Punkt, der hier noch etwas weiter ausgeführt werden soll. Viele Datenformate machen es leider schwer, Rohdaten ohne Spezialsoftware zu betrachten und zu verstehen. Das soll hier an einem Vergleich üblicher Datenpakete von AX.25 und hamtunnel dargestellt werden. Dazu wird jeweils der Anfang eines typischen Datenpaket wiedergegeben, wie es von einem TNC empfangen wurde. Es handelt sich dabei jeweils um ein IPv4-Paket, gesendet von der Station DL1PZ. Dabei werden druckbare ASCII-Zeichen als Text dargestellt und nicht-druckbare Zeichen als Hexadezimalzahl nach dem Muster <00>. In Fettschrift wird das Rufzeichen und die Protokollinformation hervorgehoben.
Im Falle von AX.25 ist praktisch überhaupt nicht zu erkennen, was für Daten vorliegen. Die Sequenz <88><98>b<a0><b4> ist übrigens DL1PZ in ASCII-Kodierung um ein Bit nach links verschoben und das Byte <cc> steht für IPv4. Die Kodierung von hamtunnel hingegen lässt das Rufzeichen leicht erkennen und gibt mit “IP4” einen klaren Hinweis darauf, welche Art von Daten anschließend zu erwarten sind. Zumindest für alle mit Programmiererfahrung ist das Null-Byte <00> leicht als Trennzeichen zu identifizieren. Die anschließend folgenden IPv4-Daten sind (genauso wie IPv6) leider nicht für den Menschen lesbar, da bei IP die Kopfdaten stets binär kodiert werden.
Die Früchte der Arbeit: IP-basierter IRC-Chat auf 144,850 MHz im Channel #2m-talk
Fazit
Viele Wege führen zum Ziel. Zum Vorbehandeln der IP-Pakete mit Rufzeichen und Protokollinformationen können AX.25, tncattach oder hamtunnel genutzt werden. TNCs gibt es in Hardware, wie der PicoAPRS, und in Software, wie Dire Wolf oder pktfec-tnc, teils mit klassischer AX.25-Kodierung, teils mit moderneren Verfahren. Bei der Modulation ermöglichen die TNCs neben Klassikern wie 1200-Baud-AFSK gemäß Bell-202 oder 9600-Baud nach G3RUH viele weitere Verfahren. Dank KISS-Protokoll lassen sich die Komponenten beliebig kombinieren.
Eines darf dabei aber nicht vergessen werden: Nur wenn alle beteiligten Stationen exakt die selbe Art verwenden um IP-Pakete einzupacken, für die Übertragung vorzubereiten und zu modulieren ist ein erfolgreicher Datenaustausch möglich. Denn die Verfahren sind nicht untereinander kompatibel. Das ist leider ein Dilemma. Denn entweder verwenden wir möglichst etablierte (“gut abgehangene”) Verfahren wie AX.25 mit 1200-Baud-AFSK-Übertragung und bleiben auch mit alten Hardware-TNCs kompatibel – oder wir verzichten auf die Abwärtskompatibilität und setzen auf neuere Verfahren mit eleganteren Protokollen und moderner Fehlerkorrektur.
Michael Phelps (NA7Q) hat die Initiative ergriffen und möchte ein aktuelles APRS-Wiki erschaffen. Dabei soll ein Nachschlagewerk für Hardware-Setups und auch Empfehlungen für den richtigen Betrieb entstehen.
Viele Informationen, die sich im Internet finden lassen, sind veraltet, missverständlich oder schlicht falsch. Daher hat NA7Q das Wiki aprs.wiki ins Leben gerufen und sucht nun Autoren und Übersetzer, die das Wiki mit den aktuellsten Informationen befüllen.
Jedes Jahr zu Weihnachten, zum Alexanderson-Day und zu besonderen Anlässen wie beispielsweise Veranstaltungen der Vereinten Nationen geht der Längstwellensenders Grimeton mit dem Rufzeichen SAQ wieder auf Sendung. Die Grundvoraussetzung für guten Empfang ist allerdings eine leistungsstarke Antenne. in den vergangene Jahren habe ich einige Antennen dafür gebaut und auch wieder verworfen. Meine Versuche mit Ferritstabantennen waren nicht von Erfolg gekrönt. Auch mit der MiniWhip bin ich nicht warm geworden. Die MiniWhip ist nicht schlecht, aber ich mochte die erforderliche zusätzliche 12V Stromversorgung nicht.
Ich habe in diesem Jahr also eine neue Antenne für den Empfang der Sondersendungen aus Grimeton gebaut.
Alles was man dazu benötigt ist eine 28 Zoll Fahrradfelge, 41 m Kupferlackdraht 0,8 mm², ein kleines Gehäuse, eine PL-Buchse und ein bisschen Kleinmaterial.
Reparaturwerkstätten für Fahrräder haben eigentlich immer Felgen, die zur Entsorgung vorgesehen sind, herumliegen. Für die Werkstatt ist es Schrott, für den Funkamateur allerdings eine Rahmenantenne. Ich habe bisher alle Felgen kostenlos überlassen bekommen. Die Werkstatt freut sich über weniger Entsorgungskosten.
Zuerst müssen die Speichen mit dem Seitenschneider entfernt. Im Anschluss sollte die Felge gründlich gereinigt werden. Nachdem ich die Felge gesäubert hatte, habe ich ein ungefähr 5 cm langes Stück aus der Felge herausgesägt. Das freigewordene Stück habe ich mit einer Gehäuseschale überbrückt, die später die PL Buchse aufnehmen wird. Zum Schutz des Kupferlackdraht habe ich mit Isolierband in das Laufrad eingeklebt. Manchmal befindet sich das alte Felgenband noch auf der Felge. Wenn man es schön sauber bekommt, dann ist es optimal als Schutz für den Wickeldraht geeignet.
Zunächst habe ich 50 Windungen Kupferlackdraht aufgewickelt und die beiden Enden des Drahtes mit der PL-Buchse verbunden. Die Felge habe ich nicht mit der Buchse verbunden. Die Felge hat einen Wickeldurchmesser von ca. 62 cm – Daraus ergibt sich eine Windungslänge von ca. 2 m je Windung.
Ich musste ernüchternd feststellen, dass mit 50 Windungen der Empfang fast bei Null lag. Nun habe ich nach und nach immer mehr Windungen entfernt und den Empfang immer wieder überprüft. Mit dem empirisch ermittelten Ergebnis von 20 Windungen, hatte ich den besten Empfang. Ich konnte am Sonntag Vormittag, den 09.12.2018, den Zeitzeichensender MSF aus Nordengland auf 60 kHz hören. Und das trotz Tagesdämpfung.
Etliche Langwellen Radiosender waren mit kräftigen Signalen sehr gut hörbar. Auch der Zeitzeichensender DCF77 aus Mainflingen (bei Frankfurt am Main), auf 77,5 kHz, war mit einem Signal über S9 zu empfangen.
Also Deckel drauf und fertig. Nun hängt die Antenne neben meinem ersten Prototypen, der nicht ganz so erfolgreich war. Eventuell lag das am dünneren draht, denn beim Prototypen hatte ich 0,2 mm² Kupferlackdraht genommen. Ich überlege die beiden Antennen 90 Grad zueinander auszurichten und beide anzuschließen.
Ich freue mich auf die nächste SAQ Aussendung und bin mal gespannt, ob ich sie damit hören kann.
In der Zwischenzeit kann man aber auch noch andere Dinge im VLF-Bereich hören. Da sind zum Beispiel die Sferics oder die “Schumann Resonanz” bei 7.83, 14.1 und 20.3 kHz und einige Zeitsignalsender, wie schon weiter oben genannt. Der begehrte SAQ ist bei 17.2 kHz aktiv, wenn er sendet. Bei ca. 100 kHz ist das Long Range Navigation System LORAN zu hören. Auf 147 kHz ist fast rund um die Uhr der Deutsche Wetterdienst aus Pinneberg in RTTY hörbar. Eine Liste von Längstwellensendern gibt es übrigens in der Wikipedia. Ab ca. 160 kHz beginnt das Langwellen Radioband. Hier tummeln sich überraschend viele Radiostationen. Das Funkfeuer unseres Flughafens (BRU) kann ich bei 426 kHz in CW hören. Wer Interesse daran hat, der kann einfach mal in langen Winternächten über das “Band” drehen.
VLF-Konverter von DL8UF
Für den Empfang benötigt man natürlich einen geeigneten Empfänger. Wer keinen VLF Empfänger hat, der kann sich mit einem VLF Konverter behelfen. Die sind ultraleicht aus wenig Teilen zusammen zu bauen. Im Netz gibt es sehr viel dazu. Ich habe den VLF-Konverter von DL8UF nachgebaut. Wer ihn aus einer USB Quelle speist, der kann den ganzen oberen Teil im Schaltbild auch weglassen. Er dient nur der Stromversorgung. Man kann auch gleich mit der USB Spannung an VCC gehen! Ich kann die letzte Station mit diesem Konverter bei 655 kHz empfangen. Und nun viel Freude beim nachbauen.
Dieser Artikel erschien zuerst im Dezember 2018 in der gedruckten Ausgabe unseres Magazins.
Im Jahr 2020 findet zu Weihnachten leider keine Sendung aus Grimeton statt.
Der in Berlin lebende Funkamateur Jörg Scholtz DK2AI hat ein Buch über seine Reise nach Sibirien geschrieben und nun veröffentlicht. Gemeinsam mit einem russischen Kollegen reiste er bis an die chinesische Grenze. Das Ziel dabei war „von dort aus zu funken, wo nie zuvor ein Mensch gefunkt hat.“
Das Vorwort des Buches macht schonmal neugierig und wirbt ebenfalls für den Amateurfunk. Dieser Reisebericht könnte auch für Menschen interessant sein, die noch keine Funkamateure sind.
Buchtitel „Meine Funkexpedition ins ferne Sibirien“
„Amateurfunk (englisch: „ham radio“) ist kein abgehobenes Hobby für verschrobene Bastelfreaks, sondern eine wunderbare Möglichkeit, über alle Grenzen hinweg mit der Welt in Kontakt zu treten. Selbst im heutigen Kommunikationszeitalter mit Internet und sozialen Medien gibt es für den Amateurfunk durchaus eine Daseinsberechtigung, denn nicht alle Gebiete und Regionen der Welt sind online erreichbar, außerdem gibt es in vielen Ländern aus politischen Gründen Zugangsbeschränkungen und Restriktionen. …
Dieses Buch erzählt von meiner abenteuerlichen Reise durch Russland bis ins ferne Sibirien, meinen FunkErfolgen und nicht zuletzt von wunderbaren Begegnungen und russischer Gastfreundschaft.
Es soll auch andere Funkamateure dazu ermutigen, sich in unbekanntes Terrain zu begeben und sich an Orte zu wagen, von denen aus bisher selten oder gar nicht gefunkt wurde.
Und nicht zuletzt ist mein Buch auch ein Aufruf dazu, die eigene Bequemlichkeit aufzugeben und die heimische Umgebung zu verlassen, um neue Horizonte zu entdecken -und das meine ich ganz wörtlich, während ich voller Ehrfurcht an stille und eindrucksvolle Momente in den unendlichen Weiten Sibiriens denke, die mir ewig im Gedächtnis bleiben werden.“
ATTENTION! NOW YOU CAN MAKE DIGITAL VOICE TALK WITH YOUR PICOAPRS! Thanks to sh123! Install codec2_talkie apk from GitHub https://t.co/PLy0x4yO1z set your PicoAPRS to TNC mode and connect with your smartphone via USB cable. That's it Both have to set the same baudrate in the app pic.twitter.com/xG5EZ1ZeJB
Dabei handelt es sich um eine minimalistische Android-App mit der man mittels AX.25 digitalen Sprechfunk betreiben kann. Die App verbindet sich via Bluetooth oder USB mit einem KISS-TNC. Über das am TNC angeschlossene Funkgerät können dann Codec2-Audioframes, welche in KISS-Frames eingekapselt sind, versendet werden.
Die App bzw. Codec2 ändert nichts an Modulation oder sonstigen Parametern. Es hängt alles vom verwendeten Funkgerät ab.
Laut Entwickler sollen sich AFSK1200, GMSK 9600, LoRa, FSK, FreeDV und weitere Modulationen verwenden lassen. Einzige Bedingung ist, dass verwendete Funkgerät muss via KISS ansprechbar gemacht werden.
Laut dem GitHub-Repository funktioniert es mit dem PicoAPRS und mit den kleinen LoRA ESP32 Modulen, die Bluetooth integriert haben.
Das Projekt befindet sich in einem recht jungen Stadium sieht, aber vielversprechend aus.
Ich werde das in den kommenden Tagen mal mit unterschiedlichen TNCs und LoRa-Modems durchtesten. Über die Resultate berichte ich dann hier im Blog.
Weitere Infos zu dem Projekt gibt es bei GitHub und im Forum unsigned.io
Das Bildmaterial in diesem Artikel wurde mir von Taner Schenker, DB1NTO zur Verfügung gestellt.
Login
