MMDVM: Aktuelle Entwicklungen und Ausblick für 2025

Erfahrt alles über die neuesten Entwicklungen bei MMDVM und was uns in Zukunft erwartet.

Im globalen Brandmeister-Netzwerk sind im Oktober 2024 fast 18.500 Hotspots und rund 6.600 Relaisfunkstellen aktiv. Besonders auffällig: Gut 82 % dieser Systeme basieren auf MMDVM – ein Anstieg von etwa 2 % im Vergleich zum Vorjahr. MMDVM, kurz für „Multi-Mode Digital Voice Modem“, wurde von Jonathan G4KLX entwickelt. Diese vielseitige Firmware und Software ermöglicht es, verschiedene digitale Kommunikationsmodi zu nutzen. Dazu gehören aktuell D-Star, DMR, C4FM, P25, NXDN, M17, Analog FM, AX.25 und POCSAG.

Den entscheidenden Durchbruch erzielte MMDVM mit der Verbreitung kostengünstiger Hotspots und dem von Andy MW0MWZ entwickelten Pi-Star Image. Dieses ermöglicht eine einfache Konfiguration über ein benutzerfreundliches Dashboard, ohne dass tiefgehende Linux-Kenntnisse erforderlich sind. Inzwischen sind weitere Pi-Star-Derivate wie WPSD, entwickelt von Chip W0CHO, erhältlich. Diese bieten einen noch größeren Funktionsumfang und erweitern die Einsatzmöglichkeiten für Nutzer deutlich. Übrigens: Wer die Entwicklung von WPSD gerne verfolgen oder Fragen dazu stellen möchte, findet hilfreiche Infos und Unterstützung in der deutschsprachigen Telegram-Gruppe.

Wie auch im vergangenen Jahr gab es auf der diesjährigen Pacificon ein Update zum Fortschritt der MMDVM-Entwicklung, das wir euch an dieser Stelle nicht vorenthalten möchten. Für diejenigen, die unseren vorherigen Beitrag dazu noch einmal lesen möchten, steht er hier zur Verfügung:

MMDVM-TNC

Es dient der Datenübertragung über Funk und erinnert stark an das klassische Packet Radio, bei dem Informationen in Paketen gesendet und empfangen werden. Die Kommunikation zwischen dem Host und dem TNC erfolgt über KISS-Kommandos, die eine unkomplizierte Steuerung ermöglichen. Es unterstützt vier verschiedene Betriebsmodi: Im Modus 1 werden Daten mit 1k2 Baud und AFSK-Modulation über das AX.25-Protokoll übertragen, der bereits in MMDVM implementiert ist. Für die höheren Datenraten von 9k6 Baud, 19k2 Baud und 38k4 Baud in den Modi 2 bis 4 wird hingegen C4FSK als Modulationsart verwendet – ähnlich wie bei DMR, jedoch nicht kompatibel. Hier kommt ein modernes IL2P-Protokoll zum Einsatz, eine Weiterentwicklung von AX.25, das zusätzlich eine Fehlerkorrektur (FEC) integriert. Diese „aufgebohrte“ Version von AX.25 ermöglicht einen höheren Datendurchsatz und ist besonders geeignet für 9k6 Baud-fähige Funkgeräte mit Diskriminator-Anschluss (ungefiltertes Audio) an der Datenbuchse. Die Modi 2 und 3 werden zudem vom TARPN NinoTNC unterstützt.

NinoTNC N9600A, Quelle: https://tarpn.net/t/nino-tnc/n9600a/n9600a_info.html

MQTT und Anzeigetreiber

MQTT ist ein Protokoll, das speziell für die Übertragung von Nachrichten in Netzwerken mit geringer Bandbreite entwickelt wurde. Dabei sendet eine Datenquelle, wie beispielsweise ein Temperatursensor, seine Informationen an einen zentralen Verteiler, ohne dabei zu wissen, wer die Empfänger dieser Daten sind. Die Empfänger, etwa eine Anzeigeeinheit, abonnieren die für sie relevanten Daten bei diesem Verteiler und stellen sie entsprechend dar.

Auch im MMDVM-System soll das MQTT-Verfahren künftig eingesetzt werden, unter anderem zur Bereitstellung von Log-Daten. Ereignisdaten, wie etwa das Empfangen einer Station, könnten so für Dashboards und Displays wie NEXTION und OLED im JSON-Format zur Verfügung gestellt werden. Dies erfordert zwar eine Anpassung der Anzeigetreiber, bietet jedoch den großen Vorteil, dass zur Unterstützung zusätzlicher Displays keine Änderungen am Quellcode des Hosts mehr nötig sind.

Zukünftig soll MQTT auch zur Fernsteuerung von Hotspots und Relais genutzt werden, um eine einfachere Bedienung zu ermöglichen. Zudem könnten empfangene APRS-Daten über MQTT an das entsprechende Gateway weitergeleitet werden. Für die direkte Kommunikation zwischen dem Host und den Gateways ist der Einsatz von MQTT allerdings nicht vorgesehen.

AllStar Anbindung

AllStar ist eine moderne Variante von EchoLink und ermöglicht die Vernetzung von analogen FM Amateurfunk-Relaisstationen sowie -Benutzern. Dabei wird die Sprache über das Internet oder das Hamnet übertragen.

In einer zukünftigen Version des FM Gateways soll die Anbindung an AllStar-Netzwerke ermöglicht werden. Dies würde auch der analogen Seite eines Multimode-Relais neue Vernetzungsmöglichkeiten bieten, die bislang vor allem den digitalen Betriebsarten vorbehalten waren.

Analoger FM-Hotspot SHARI mit AllStar-Anbindung

Neuer Digitalmodus: dPMR

Der Digitalmodus dPMR wird voraussichtlich das letzte digitale Verfahren sein, das von der aktuellen Generation der MMDVM-Hardware unterstützt wird, bevor die Entwicklung der nächsten Generation beginnt (siehe letzter Abschnitt). dPMR basiert, wie auch NXDN, auf C4FSK und ist diesem sehr ähnlich. Aufgrund der begrenzten Speicherkapazitäten für weiteren Quellcode bei existierenden Duplex-MMDVM-Hotspots wird dPMR wahrscheinlich nur auf Simplex-Hotspots verfügbar sein.

dPMR wird von vielen günstigen Funkgeräten aus Fernost unterstützt. Da diese jedoch oft keinen standardisierten AMBE-Vocoder verwenden, sind sie untereinander häufig nicht kompatibel. Die Implementierung von dPMR in MMDVM wird daher nur mit professionellen dPMR-Geräten, wie denen von ICOM, kompatibel sein.

dPMR kompatible Mobilfunktransceiver von ICOM, Quelle: https://dpmrassociation.org/dpmr-icom.html

Cross Mode und MMDVM Transcoder

Die MMDVM_CM Suite (CM steht für CrossMode) ermöglicht es Hotspots, HF-seitig in einem anderen Modus zu arbeiten als netzwerkseitig. So könnt ihr beispielsweise mit eurem DMR-Handfunkgerät in YSF-Netzen aktiv sein oder umgekehrt. In Zukunft soll die MMDVM_CM Suite vollständig durch eine neue Lösung ersetzt werden: die Transkodierung des Audiosignals wird dann über einen speziell entwickelten MMDVM-Transcoder erfolgen.

Dieser Transcoder wird in Form eines USB-Sticks ausgeführt und soll die Transkodierung zwischen verschiedenen digitalen Verfahren übernehmen. Während die Transkodierung für IMBE (P25 Phase 1) und Codec2 (M17) auf einem STM-Prozessor (STM32H723) erfolgt, wird die Transkodierung von D-Star zu DMR, C4FM und NXDN von einem AMBE3003-Vocoder durchgeführt.

Durch diese Kombination aus neuer Software und Hardware wird es möglich sein, nahezu jeden Digitalmodus in einen anderen zu konvertieren. Die Konfiguration des Audio-Routings erfolgt über eine umfangreiche Konfigurationsdatei. Es ist jedoch zu beachten, dass immer nur ein Modus HF-seitig in einen anderen netzwerkseitig konvertiert werden kann – Mehrfachkonvertierungen gleichzeitig sind nicht möglich.

Prototyp der MMDVM Transcoder Hardware mit einem AMBE3000R auf einem Nucleo-H723, Quelle: https://github.com/ZUM-Radio/MMDVM_transcoder_hw?tab=readme-ov-file

MMDVM v2: Die nächste Generation

Die nächste Generation von MMDVM wird anstelle der bisher verwendeten Modems auf einen I/Q-basierten Transceiver setzen. Diese arbeiten mit sogenannten In-Phase (I) und Quadratur (Q) Signalen, um Informationen über Funk zu übertragen. Im Gegensatz zu herkömmlichen Modems ermöglichen sie eine flexiblere Signalverarbeitung und unterstützen dadurch eine Vielzahl von Betriebsarten. Das Signal wird direkt als I/Q-Daten verarbeitet und ermöglicht dadurch eine effizientere Modulation und Demodulation.

Dies eröffnet Hotspots die Möglichkeit, nicht nur alle digitalen Sprachmodi zu unterstützen, sondern auch den Betrieb in FM, was bisher nur mit Modems möglich war. Derzeit befindet sich das Entwicklerteam auf der Suche nach passenden und kostengünstigen ICs, um Hotspots auf dieser Basis zu realisieren. Ob diese Technologie auch für Relaisfunkstellen geeignet sein wird, bleibt abzuwarten.

Jonathan und das Entwicklerteam möchten zunächst sicherstellen, dass die gesamte Funktionalität der aktuellen MMDVM-Version in der neuen Generation vollständig integriert ist, bevor sie weitere digitale Betriebsarten wie TETRA oder P25 Phase 2 implementieren. Die Software wird außerdem so flexibel gestaltet, dass unterschiedliche I/Q-Transceiver verwendet werden können.

Frühe Experimente mit einem CMX991 I/Q-Radio Chip von KD2BMH

Wer den Vortrag von Jim KI6ZUM und Jonathan G4KLX/W4KLX in englischer Sprache ansehen möchte, findet ihn hier:

Weitere Informationen zu MMDVM findet ihr außerdem auf der MMDVM Groups.io Seite:

Screenshot von groups.io

MMDVM@groups.io

Als Team DL-Nordwest finden wir die Entwicklungen rund um MMDVM äußerst spannend. Die stetige Erweiterung der Funktionen und die neuen Technologien, die sowohl digitale als auch analoge Modi vereinen, bieten zahlreiche Möglichkeiten für die Zukunft des Amateurfunks. Wir werden die weitere Entwicklung aufmerksam verfolgen und freuen uns darauf, die neuen Fortschritte und Innovationen mit euch zu teilen.

Welche Funktionen oder Neuerungen findet ihr am spannendsten? Schreibt es uns gerne in die Kommentare unter diesem Beitrag oder diskutiert es mit uns in unserer Telegram- und oder WhatsApp-Gruppe.

Team DL-Nordwest, Stephan 9V1LH/(9M2/)DG1BGS


Möchtest du das DL-Nordwest Projekt unterstützen? Dann freuen wir uns über deinen Gastbeitrag, das Teilen unserer Inhalte oder eine (kleine) Spende 🤑 Vielen Dank für deine Unterstützung! 😘

APRS-IS Wetterstation mit der LaCrosse WS2300

In diesem Beitrag beschreibe ich, wie die Wetterdaten einer LaCrosse WS2300 Wetterstation zusätzlich an das APRS-IS Netzwerk gesendet werden können.

Das Wetter in Ostfriesland ist oft wechselhaft und meist windig, geprägt von milden Sommern, kühlen Wintern und häufigen Regenschauern. Die Nähe zur Nordseeküste sorgt generell für ein maritimes Klima. Als Technik-affiner Funkamateur finde ich es sehr spannend, die Wetterdaten selbst zu erfassen. Damals kaufte ich mir dazu eine gebrauchte LaCrosse WS2300 Wetterstation, da diese in der APRS-Gemeinschaft oft verwendet wurde. Dieses lag nicht zuletzt daran, dass zahlreiche APRS-Hardware den direkten Anschluss und somit die Übertragung der Wetterdaten ins APRS-Netzwerk ermöglichten.

So betrieb ich die Wetterstation einige Jahre an meinem ehemaligen QTH am Bodensee, bevor sie nach dem Umzug in einem Karton verschwand.

Otmar DJ1OF bei der Installation der Wetterstation am alten QTH JN47MR in 2016

Da die Wetteranlage meines Vaters DL9BGG dem rauen Ostfriesischen Wetter auf Dauer nicht gewachsen war entschlossen wir uns im Mai diesen Jahres kurzerhand, meine alte Wetterstation zu testen und an seinem QTH zu installieren.

Ein erster Test im Innenraum wurde erfolgreich bestanden und so Stand einer Installation auf dem Hausdach nichts mehr im Wege.

Da mein Vater keinen APRS-Sender betreibt, ich die Daten aber gerne ins APRS-Netzwerk spielen wollte, um mir auch in Singapur ein Bild über das aktuelle Wetter in Singapur machen zu können, suchte ich nun nach einem Weg, die Daten direkt ins APRS-IS Netzwerk zu senden.

Da ich das Rad, auch aus Zeitgründen, nicht komplett neu erfinden wollte und ich mir sicher war, dass dieses in etlichen Projekten bereits realisiert wurde, recherchierte ich im Internet nach geeigneten Lösungen. Nach nur kurzer Zeit wurde ich im Internet fündig und musste mir die einzelnen Bausteine nur gemäß meiner Konfiguration zusammensetzen.

Der slowenische OM Andrej S55MA beschreibt in seinem HAM Blog in dem Beitrag „La Crosse WS2300, WS2307 series APRS with Xastir“ ein vom ihm geschriebenes Script, welches das Programm Fetch2300 nutzt und die Daten der Wetterstation zunächst in eine temporäre Textdatei schreibt. Fetch2300 kommt als Teil des open2300 Projektes von dem Dänen Kenneth Lavrsen, welches nicht mehr weiterentwickelt wird. Das Script von Andrej S55MA öffnet dann diese Textdatei um sie zu lesen, wertet die Daten dann aus und schreibt sie in einen Textstring, der von der Linux APRS-Software Xastir gelesen werden kann. Sein Script stellt außerdem einen Webserver bereit, mit dem sich Xastir dann verbinden kann, um sich die Textzeile mit den Wetterdaten zu holen. In seinem Blog beschreibt er außerdem detailliert die dazu erforderlichen Installationsschritte.

Xastir erfordert jedoch die Verwendung einer grafischen Oberfläche (Gui). Da ich das Ganze auf einem Raspberry Pi nebenher laufen lassen wollte, auf dem bereits ein OpenWebRX+ ohne grafische Oberfläche läuft und ich die anderen Funktionalitäten einer vollen APRS-Software in meinem Fall nicht benötige, suchte ich nach einer anderen Möglichkeit. OpenWebRX+ verwendet DireWolf von WB2OSZ, um die mit dem SDR empfangenen APRS-Pakete zu decodieren und ins APRS-IS Netzwerk weiterzuleiten. Was lag also näher, eine entsprechende Bake für die Wetterdaten zu konfigurieren?

Leider führte mich auch das in eine Sackgasse. Zwar konnte ich die Wetterdaten als Bake aussenden, jedoch nicht in dem Bakenformat, um sie als Wetterstation zu erkennen. Eine neue Lösung musste also her. Ich entschied mich kurzerhand, das Script von Andrej S55MA so umzuschreiben, dass es statt der Bereitstellung eines Webservers, über den die Daten abgerufen werden, die Daten gleich selbst ans APRS-IS Netzwerk sendet. Glücklicherweise fand sich unter dem Titel Send APRS objects or telemetry via Bash auch für diese Aufgabe eine passende Anleitung in Andrej’s Blog. Ich musste also nur seine beiden Blog Einträge kombinieren und schon hatte ich Erfolg.

Wetterdaten von DL9BGG-13 auf aprs.fi

Screenshot von aprs.fi

DL9BGG-13 auf aprs.fi

Die Anpassung meines Scriptes basiert auf Version 1.6 seines Scriptes. Im Eingangsbereich des Scriptes konfigurieren wir zunächst unser Rufzeichen, die zu verwendende SSID, den dazugehörigen Passcode, den Längen- und Breitengrad der Wetterstation im DDM-Format (Dezimal-Minuten), sowie optional einen statischen Kommentar (z.B., welche Wetterstation verwendet wird). Außerdem definieren wir noch, an welchen APRS-IS Server gesendet werden soll, dessen Port und das Intervall in Sekunden, indem gesendet werden soll. Schließlich benötigt das Script noch den vollständigen Pfad zur open2300 Konfigurationsdatei. Abweichend zu Andrej’s Anleitung habe ich diese in dem Verzeichnis „/usr/local/etc/“ liegen.

#DEFINE VARIABLES
callsign="xxxxxx"
aprsssid="13"
passcode="xxxxx"
lat="0000.00N"
long="00000.00E"
comment="LaCrosse WS2300"
server="euro.aprs2.net"
port="14580"
interval="60"
ws2300config="/usr/local/etc/open2300.conf"

Das Auswerten und schreiben der einzelnen Werte ist identisch zu Andrej’s Script mit dem Unterschied, dass ich zusätzlich noch die Tendenz und die Vorhersage auswerte und später mit in den Kommentar schreibe.

tendency=$(cat "$fetch_path" | grep -oP 'Tendency\s+\K\S+')
forecast=$(cat "$fetch_path" | grep -oP 'Forecast\s+\K\S+')

Interessanter wird es jetzt beim Zusammenbau des Bakenstrings. Der zusammengebaute Bakentext mit den Werten sieht dann beispielhaft so aus:

DL9BGG-13>APN000,TCPIP*,qAC,T2PRT:@025940z5336.60N/00709.97E_157/009g...t068r000p000P...h71b10544LaCrosse WS2300, Tendency: Falling, Forecast: Rainy

Schließlich starte ich das Script einfach durch einen cronjob, wenn der Raspberry Pi hochfährt. Führt dazu den Befehl sudo crontab -e aus und ergänzt in einer neuen Zeile:

@reboot bash /usr/local/sbin/wxdata.sh &

Interessierte können mein modifiziertes Script hier herunterladen.

Linux-Script: WS2300 Wetterdaten an APRS-IS Senden

#This script reads weather data via fetch program which is part of Open2300 suite written by Kenneth Lavrsen (http://www.
#lavrsen.dk/foswiki/bin/view/Open2300/WebHome).
#It outputs the right data needed to feed Xastir for APRS weather reports. The scripts utilizes Ncat utility as server to
#serve the fetched output to Xastir.
#Fetched Data is pushed to Ncat server and then to Xastir. (Fetched data -> Ncat server -> Xastir)
#Ncat is part of Nmap, get it by installing Nmap.
#This script should work for LaCrosse weather stations, WS23xx series. Testing was done with WS2307.
#Written by S55MA and S56IUL, May 2016
#Origin Source: https://s55ma.radioamater.si/2016/05/03/la-crosse-ws2300-ws2307-series-aprs-with-xastir/

# Modified by DG1BGS/9V1LH, 23rd June 2024
# Removed the web server. APRS data is now sent directly to the APRS-IS network using ncat.
# Please update the variables in the section below.
# For more information, visit dl-nordwest.com

Größe: 12 kB
Version: 2024-07-23

Tipp: Vergabe von eindeutigen Com-Port Namen unter Linux

Um sicherzustellen, dass einem externen Gerät unter Linux immer der gleiche Com-Port zugewiesen wird, kann man externen Geräten eindeutige Namen zuweisen. In meinem Fall habe ich in dem Verzeichnis /etc/udev/rules.d eine Datei mit dem Namen 99-usb-serial.rules angelegt und die folgenden Zeilen eingefügt:

#Weather station open2300
#ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port / Mobile Phone Data Cable
SUBSYSTEM=="tty", ATTRS{idVendor}=="067b", ATTRS{idProduct}=="2303", SYMLINK+="ttyWX"

Die Vendor- und Product-ID eures externen Gerätes erhaltet ihr nach Eingabe des Befehls lsusb. In meinem Fall erhalte ich nach Eingabe des Befehls u.a. die folgende Ausgabe:

Bus 003 Device 002: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port / Mobile Phone Data Cable

Ab dem nächsten Neustart des Rechners wird der Wetterstation in diesem Beispiel jetzt immer der Com-Port /dev/ttyWX zugeordnet, den ich auch in der open2300.conf gesetzt habe.

Fazit

Das Projekt war kurzweilig und hat viel Spaß gemacht, da sich nach nur kurzer Zeit ein Erfolg eingestellt hat. Durch die gute Programmierarbeit und Dokumentation von Andrej S55MA war es sehr einfach, das Gewünschte entsprechend der eigenen Umgebung zu implementieren. An dieser Stelle meinen herzlichen Dank an alle, die ihre Projekte für andere zur Verfügung stellen und dokumentieren.

Durch das übermitteln der Wetterdaten an das APRS-IS Netzwerk sind diese jetzt nicht nur lokal verfügbar, sondern auch von jedermann weltweit abrufbar. Und obendrein erhält man auf aprs.fi noch eine statistische Darstellung der Wetterdaten.

Ich habe auch schon Ideen für künftige Erweiterungen: Die Wetterdaten könnten zusätzlich an einen MQTT-Broker gesendet werden, um sie auch an andere Stelle auszuwerten und darzustellen. Ggf. wäre das auch ein tolles Projekt für ein Wetterdisplay mit ePaper-Display. Außerdem könnte man die APRS-Baken zusätzlich durch den Einsatz eines kleinen Funkmoduls auch über VHF lokal abstrahlen und oder oder sie für eine LoRa-Telemetriebake nutzen.

Betriebt ihr auch eine eigene Wetterstation und nutzt die Daten nicht nur für euch selber? Wenn ja, berichtet gerne in den Kommentare unter diesem Beitrag über euer Projekt oder diskutiert es mit uns in unserer Telegram- und oder WhatsApp-Gruppe. Eventuell habt ihr ja auch Lust, euer eigenes Projekt hier mal vorzustellen.

Team DL-Nordwest, Stephan 9V1LH/(9M2/)DG1BGS


Möchtest du das DL-Nordwest Projekt unterstützen? Dann freuen wir uns über deinen Gastbeitrag, das Teilen unserer Inhalte oder eine (kleine) Spende 🤑 Vielen Dank für deine Unterstützung! 😘

Neuigkeiten zum MMDVM-Projekt und MMDVM-TNC

MMDVM steht für „Multi-Mode Digital Voice Modem“ und wurde von Jonathan Taylor G4KLX entwickelt. Es handelt sich dabei um eine Firmware und Software, die verschiedene digitale Kommunikationsmodi wie DMR, D-STAR, C4FM, NXDN, P25, POCSAG und weitere aber seit kurzem auch APRS (AX.25) und sogar analoges FM ermöglicht. Laut Brandmeister basieren heute mehr als 80% aller eingeloggten System (Repeater und Hotspots) auf MMDVM. Durch Pi-Star wurde dessen Verwendung sehr vereinfacht und blieb damit nicht nur Linux-Spezialisten vorbehalten.

Auch wenn MMDVM bereits auf gut 18.000 Systemen (Stand November 2023) betrieben wird, gibt es jedoch noch einige bekannte Probleme im Quellcode, die korrigiert oder optimiert werden sollten. Jonathan G4KLX war jedoch nicht dazu bereit, noch mehr seiner Freizeit kostenlos für das Projekt zu opfern. Vor allem, da sehr viele Einzelpersonen aber auch Unternehmen sehr viel Geld mit dem Verkauf von MMDVM-Hardware verdienen, die seine kostenlose Firm- und Software verwenden.

Seit kurzem tut sich jedoch wieder etwas auf seiner Github-Seite. Laut mmdvm.com hat das MMDVM Projektteam vom ARDC* eine Förderung erhalten die es ermöglicht, Jonathan als Programmierer in Vollzeit zu beschäftigen. Folgendes soll umgesetzt werden:

  • Beseitigung von bekannten Fehlern
  • Verbesserung des Kernmoduls der MMDVMHost-Software für alle digitalen Modi und der Schnittstelle zu externen Anzeigen
  • Unterstützung von Message Queuing Telemetry Transport (MQTT) um die Kommunikation zwischen verschiedenen Instanzen (Programme, Webseiten, Anzeigentreiber, APRS) zu Optimieren (s. auch nächster Punkt)
  • Webbasierte Konfiguration und Überwachung eines MMDVM-Systems (via MQTT)
  • Benutzerschnittstelle für portable Endgeräte
  • Hinzufügen von KISS/AX.25 Packet Unterstützung sowie höhere Datenraten für bestehende MMDVM-Systeme (bereits implementiert)
  • Portierung der Firmware zur Unterstützung modernerer Mikroprozessor-Architekturen
  • Unterstützung weiterer digitaler Kommunikationsmodi (M17 bereits implementiert)

Die Änderungen und Neuerungen dürften nach einiger Zeit auch in Pi-Star Einzug erhalten, so dass ihr diese nach einem Update ebenfalls nutzen könnt .Es sollen aber nicht nur bekannte Probleme behoben und bereits bestehende Funktionen erweitert werden, es wird auch an der Implementierung eines Datenmodus, dem s.g. MMDVM-TNC, gearbeitet.

MMDVM-TNC soll die digitale Modulation von DMR bzw. C4FM verwenden und eine Übertragung mit 9600 bps bei einer Bandbreite von 12,5 kHz ermöglichen. Es soll außerdem über eine für Daten optimierte ILSP FEC (Improved Layer 2 Protokoll Forward Error Correction) verfügen, die den Datentransfer robuster macht. Später sollen auch höhere Datenraten (19k2 bzw. 38k4 bps. bei 20 bzw. 25 kHz Bandbreite möglich sein.

Wir werden euch hier auf dl-nordwest.com über die Entwicklungen weiterhin auf dem Laufenden halten.

*Die ARDC (Amateur Radio Digital Communications) ist eine Organisation, die Geldmittel aus dem Verkauf des IP-Adressblocks 44.192.0.0/10 an den Onlinehandel-Riesen Amazon erhalten hat. Mit diesen Mitteln fördert die ARDC Projekte und Initiativen, die die Amateurfunk-Community, digitale Kommunikation und zugehörige Technologien unterstützen und weiterentwickeln. Bei den „ARDC Grants“ handelt es sich um finanzielle Zuschüsse, die an Einzelpersonen, Gruppen oder Organisationen vergeben werden, um entsprechende Projekte oder Forschungen in diesen Bereichen zu fördern.

Team DL-Nordwest, Stephan 9V1LH/(9M2/)DG1BGS