Sie sind hier

DMR-Datenübertragung

DMR kann außer für Sprechfunk auch zur Datenübertragung zwischen Computern verwendet werden. Leider sind die Schnittstellen nicht besonders gut dokumentiert und man muss sich die Lücken selbst zusammenreimen bzw. experimentell austesten. Diese Seite dokumentiert meinen aktuellen Wissensstand zu dem Thema und wird ggf. später ergänzt/korrigiert.

Disclaimer: Alle Angaben sind ohne Gewähr und dienen der persönlichen Weiterbildung im Rahmen des Amateurfunks. Andere Geräte mit anderer Firmware können sich ggf. anders verhalten. Ein paar grundlegende Erfahrungen mit IP-Netzen sind zum Verständnis durchaus hilfreich. Bitte auch den Ham-Spirit beachten!

Anwendungs-Ideen

  • Zugang zum HAMNET für Funkamateure ohne die für WLAN-Zugänge notwendige Sichtverbindung zum Turm.
  • Kleiner kompakter Instant-Messenger.

Es ist zu beachten, dass die Datenübertragung sehr langsam ist. Ich rechne mit 4800 oder 9600 Bit/s, habe aber noch keine Messungen gemacht.

Hytera

USB-Treiber

Das DMR-Funkgerät wird als USB-Netzwerkkarte eingebunden, wahlweise über RNDIS oder NCM. Der Microsoft-RNDIS-Treiber wird zumindest von der Hytera-Dateitransfer-Software nicht erkannt, mit dem Treiber aus dem Hytera-CPS-Paket funktioniert es. Ich habe das nicht näher untersucht.

Getestete Geräte: MD-785G, PD-785G

Codeplug

Im Codeplug muss unter ConventionalGeneral SettingNetwork das gewünschte USB-Protokoll ausgewählt werden (RNDIS oder NCM-Treiber) und "Forward to PC" angehakt werden.

Ich empfehle den NCM-Modus weil der auch unter Linux funktioniert. Unter Windows ist es aber vermutlich egal.

"Radio Control Station IP" im Codeplug ist die IP-Adresse des Funkgeräts auf dem RNDIS- bzw. NCM-Interface. Das Funkgerät weist dem PC über DHCP die im CPS genannte "PC IP" zu, diese kann man nicht ändern. Man muss den virtuellen Netzwerk-Adapter somit nicht manuell konfigurieren sondern alles auf "automatisch" lassen. Dies ist das Zugangsnetz, bzw. genau genommen handelt es sich nur um einen Punkt-zu-Punkt-Verbindung.

Falls es nicht funktioniert, sollte der Digital Bearer Service unter ConventionalDigital CommonBasic auf "Compressed-IP" gestellt werden. Ich vermute, dass das Einfluss darauf nimmt, wie die Daten über die Luftschnittstelle übertragen werden. Dies hat ggf. auch Auswirkungen auf die Übertragung von Textnachrichten.

Netzwerkinterface überprüfen (Zugangsnetz)

Ich benutze im Folgenden 192.168.10.1 als "Radio Control Station IP", was eine vom CPS automatisch gewählte "PC IP" von 192.168.10.2 ergibt.

Mit "ipconfig" kann die Konfiguration angezeigt werden, der Eintrag für das DMR-Funkgerät sieht dann ungefähr so aus:

Ethernet-Adapter Ethernet 3:
Verbindungsspezifisches DNS-Suffix:
IPv4-Adresse . . . . . . . . . . : 192.168.10.2
Subnetzmaske . . . . . . . . . . : 255.255.255.0
Standardgateway . . . . . . . . . : 192.168.10.1

Wenn die Adressen nicht mit denen aus dem Codeplug übereinstimmen hilft es manchmal, das USB-Kabel zum Funkgerät mal kurz rauszuziehen und wieder reinzustecken. (Dies ist bisher nur einmal direkt nach dem Programmieren vorgekommen.)

Der IP-Stack im Funkgerät arbeitet nur rudimentär. Es werden anscheinend nur UDP- und ARP-Pakete an den Host gesendet. Ein DHCP-Renew wurde nicht beantwortet, anpingen ist ebenfalls nicht möglich.

IP-Adressen für Radionetz

Das im Codeplug konfigurierte "Subnet" (per Default 10) ist das erste Oktett der IP-Adresse. Die fehlenden drei Oktette werden aus der DMR-ID gebildet. Zur Umrechnung gibt es das Python-Programm DMRconverter von Cort Buffington, N0MJS. Das Programm geht standardmäßig von Subnet 12 aus, daher ggf. nur die hinteren 3 Oktette der berechneten IP-Adresse benutzen. Die ebenfalls berechnete "PC IP address" wird in diesem Kontext nicht benötigt!

Beispiel: DMR ID 999000 → IP 10.15.62.88
(Die ID ist absichtlich keine gültige Amateurfunk-DMR-ID - jeder muss die benötigten DMR-IDs selbst umrechnen!)

Dies ist das Radionetz.

Zugangsnetz und Radionetz haben nichts direkt miteinander zutun, daher können (müssen?) sie auch unterschiedliche IP-Bereiche haben. Vermutlich dürfen sie sich aber nicht überlappen?

Kurz zusammengefasst:

  1. Das Zugangsnetz verbindet nur PC und Funkgerät, es dringt nicht nach außen.
  2. Das Radionetz verbindet die Funkgeräte, daher müssen alle beteiligten Geräte eine zueinander passende Konfiguration haben.
  3. Der PC hat nur eine IP aus dem Zugangsnetz, sendet aber an IPs aus dem Radionetz und empfängt von dort.
  4. Das Funkgerät hat eine IP aus dem Zugangsnetzs um mit dem PC zu kommunizieren. Diese IP tritt aber nicht wirklich in Erscheinung. Außerdem hat das Funkgerät eine IP aus dem Radionetz, mit der es Pakete an andere Funkgeräte bzw. deren PCs sendet.

IP-Routing

Das Routing ist ein wenig zickig, Windows scheint teilweise eine Default-Route auf die USB-Netzwerkkarte einzurichten, so dass man nicht mehr parallel ins Internet kommt. Teilweise bleibt die Route auch auf dem normalen Ethernet-Interface, so dass die Pakete statt ans Funkgerät in Richtung Internet gesendet werden. Muss man später noch glattziehen und manuell korrekte Routen setzen.

Wenn das DMR-Funkgerät eine Zugangsnetz-IP von 192.168.10.1 (der PC hat dann dementsprechend 192.168.10.2) hat, kann mit folgendem Befehl eine Route eingetragen werden:

route add 10.0.0.0 MASK 255.0.0.0 192.168.10.1

Die Eingabeaufforderung muss als Administrator gestartet werden, sonst fehlen die nötigen Rechte. Mit dem Parameter -p übersteht der Eintrag auch Reboots.

Mit "route print -4" kann man die Windows-Routing-Tabelle ausgeben. Es muss eine Zeile wie "10.0.0.0 255.0.0.0 192.168.10.1 192.168.10.2 66" erscheinen. Die 66 ist dabei nicht so wichtig.

Für erste Tests empfiehlt es sich, alle anderen Netzwerkkarten im PC zu deaktivieren, dann gibt es nur die korrekte Route. Das vermeidet auch, dass die Daten irrtümlich andere Wege nehmen und in Wirklichkeit gar nicht über DMR übertragen werden.

Telegramme über Funk senden und empfangen

UDP-Telegramme (z.B. mit netcat gesendet) an Port 3007 (Port kann im Codeplug geändert werden) schalten das Funkgerät automatisch auf TX, senden die Daten und schalten dann zurück auf RX.

Wenn keine Gegenstation da ist, versucht das sendende Funkgerät das Paket noch mehrmals zuzustellen und gibt dann auf.

Wenn eine Gegenstation mit passender IP/ID das Paket empfängt, wird es per Funk quittiert. Dies macht das Funkgerät selbständig unabhängig davon, ob ein PC die Daten auch auswertet.

Die Paket-Telegramme sind teilweise extrem kurz und daher nicht immer auf der TX-LED zu sehen!

Das empfangende Funkgerät leitet das Paket dann an die IP-Adresse des PCs im Zugangsnetz weiter, die Ziel-IP des Paketes aus dem Radionetz wird dabei überschrieben (NAT). Die Quell-IP bleibt die Radionetz-IP des absendenden Funkgeräts, man weiß also von wem das Paket kommt und kann auf die DMR-IP rückrechnen.

Pakete dürfen nicht zu groß werden, sonst rebootet das Funkgerät.

NetCat-Beispiele

Senden: nc -u 10.15.62.88 3007

Empfangen: nc -ul 3007

Da es verschiedene Varianten von NetCat gibt, können die Parameter ggf. leicht abweichen. In diesem Fall mit "nc -h" oder "netcat -h" nachschauen.

Zugriff auf andere Ports des lokalen Funkgeräts

Man kann über die Radionetz-IP des lokalen Funkgeräts auch auf andere Ports zugreifen (z.B RCP auf 3005), vermutlich kann man damit dann ähnliche Dinge anstellen wie über das Dispatcher-Protokoll der Repeater? Also z.B. QSOs aussenden und aufzeichnen oder Textnachrichten senden. Das muss man aber nochmal gesondert erforschen. Das funktioniert nur lokal, man kann darüber nicht über DMR den Status eines entfernten Funkgeräts abfragen!

Das Lesen des Codeplugs via CPS erfolgt direkt über USB, in Wireshark sind dabei keine Datenübertragungen zu sehen.

Linux

Linux erkennt das Hytera-Funkgerät als RNDIS-Gerät und lädt Module. Es taucht aber kein neues Netzwerk-Interface auf. Irgendwas fehlt da noch.

Im NCM-Modus wird unter Debian 9 automatisch ein neues Interface erzeugt. Mit "dhclient interfacename" (interfacename entsprechend anpassen, siehe ip/ifconfig/dmesg) setzt Linux die IP-Adressen automatisch auf die im Codeplug konfigurierten Werte.

Die Ausgabe von "ip -a" enthält dann z.B. sowas:

3: enx00000xxxxxxx: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:00:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
inet 192.168.10.2/24 brd 192.168.10.255 scope global enx00000xxxxxxx
valid_lft forever preferred_lft forever

Auch unter Linux können die oben beschriebenen Routing-Probleme auftreten, so dass auch hier ggf. noch etwas Handarbeit nötig ist.

Motorola DMR

Im Motorola-CPS gibt es diverse Einstellungen, die ähnlich, aber nicht identisch zu den Hytera-Einstellungen sind. Ich könnte mir vorstellen, dass man mit etwas probieren auch damit eine Datenübertragung hinbekommt, das muss aber mal getestet werden. Auch hier spielt vermutlich das Compressed-IP-Format eine Rolle.

Tytera & Co

Zu den chinesischen Geräten habe ich aktuell keine näheren Informationen da ich mich mit diesen Geräten noch nicht näher befasst habe.