Du möchtest M17-Signale direkt im OpenWebRX+ empfangen und dekodieren? Wir zeigen dir, wie du die fehlende Unterstützung ganz einfach selbst nachrüstest.
Hinweis:
Die folgende Anleitung bezieht sich auf ein System mit OpenWebRX+ v1.2.85, laufend auf einem Raspberry Pi 5B mit Debian 12 Bookworm (64 Bit, aarch64). Bei anderen Versionen oder Architekturen können einzelne Schritte abweichen.
OpenWebRX+ ist eine vielseitige Web-SDR-Software, die ideal geeignet ist, um Funkverkehr auch digital bequem über den Browser mitzuhören. Besonders im VHF- und UHF-Bereich lassen sich damit digitale Relais und Betriebsarten wie D-STAR, DMR, C4FM und NXDN direkt empfangen und dekodieren und das ganz ohne zusätzliche Software.
Ein Modus ist bislang allerdings nicht integriert: M17. Dabei handelt es sich um einen noch nicht so weit verbreiteten, offenen Standard für digitalen Sprachfunk, der zunehmend an Bedeutung gewinnt. Die gute Nachricht: Du kannst die Unterstützung für M17 selbst hinzufügen. Dafür sind allerdings ein paar grundlegende Linux-Kenntnisse und etwas Erfahrung mit der Konsole nötig. In dieser Anleitung zeigen wir dir, wie du Schritt für Schritt vorgehst.
Vorbereitungen
Bevor wir mit dem eigentlichen Nachrüsten des M17-Dekoders beginnen, solltest du dich zunächst per SSH auf dem Rechner einloggen, auf dem OpenWebRX+ installiert ist. Anschließend sorgen wir dafür, dass dein System auf dem aktuellen Stand ist und alle nötigen Werkzeuge zur Verfügung stehen.
Ich habe mir angewöhnt, den Sourcecode selbst zu kompilierender Programme im Verzeichnis /usr/local/src abzulegen und dort zu kompilieren. Dafür sind allerdings sudo-Rechte erforderlich. Ganz ohne sudo-Rechte kannst du die Kompilierung auch im Home-Verzeichnis deines Nutzers durchführen. Ersetze dazu im Folgenden einfach die Zeile
cd /usr/local/src
durch
cd ~
Codec2 installieren
M17 verwendet den offenen Codec2 zur effizienten Sprachcodierung und -dekodierung. Damit der M17-Dekoder richtig funktioniert, muss Codec2 auf deinem System installiert sein.
cd /usr/local/src/
sudo git clone https://github.com/drowe67/codec2.git
cd codec2/
sudo mkdir build && cd build
sudo cmake ..
sudo make -j$(nproc)
sudo make install
echo "/usr/local/lib" | sudo tee /etc/ld.so.conf.d/codec2.conf
sudo ldconfig
M17-Dekoder installieren
Wenn bis hierhin alles fehlerfrei gelaufen ist, können wir nun mit der eigentlichen Installation des M17-Dekoders beginnen.
cd /usr/local/src/
sudo git clone https://github.com/mobilinkd/m17-cxx-demod.git
cd m17-cxx-demod/
sudo mkdir build && cd build/
sudo cmake ..
sudo make -j$(nproc)
sudo make test
sudo make install
sudo ln -s /usr/local/bin/m17-demod /usr/bin/m17-demod
Test
Nach der Installation prüfen wir, ob der M17-Dekoder korrekt funktioniert und OpenWebRX+ die M17-Signale erfolgreich dekodieren kann. Dazu müssen wir den OpenWebRX+ Service zunächst neu starten.
sudo service openwebrx restart
Auf der Weboberfläche deines OpenWebRX+ solltest du jetzt im Fenster „Receiver“ unter „Modes“ eine neue Schaltfläche mit der Beschriftung M17 sehen. Aktiviere diese, um den M17-Dekoder einzuschalten.
Nach erfolgreicher Installation erscheint eine weitere Schaltfläche zur Aktivierung des M17-Dekoders
Mit etwas Vorbereitung und ein paar Kommandos in der Konsole lässt sich OpenWebRX+ um die Unterstützung für den digitalen Betriebsmodus M17 erweitern.
Die hier beschriebene Vorgehensweise sollte sich grundsätzlich auch auf OpenWebRX (ohne Plus) und andere Linux-basierte Systeme übertragen lassen, eventuell mit kleinen Anpassungen.
Viel Erfolg und Spaß beim Ausprobieren und Experimentieren mit M17!
Betreibt ihr bereits einen OpenWebRX und habt diesen erfolgreich um weitere Funktionen erweitert? Habt ihr Ergänzungen oder Hinweise, die wir in diese Anleitung aufnehmen sollten? Dann schreibt es gerne in die Kommentare unter diesem Beitrag oder diskutiert sie mit uns in unsererTelegram- oder WhatsApp-Gruppe.
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! 😘
Wie ihr in M17 mit einer Kombination aus Hardware und Software, oder sogar rein softwarebasiert, QRV werdet, zeigen wir in diesem Beitrag.
Im ersten Teil unserer Beitragsreihe über M17 haben wir euch bereits einige Möglichkeiten vorgestellt, wie ihr mit einem Funkgerät im M17-Modus QRV werden könnt. Falls ihr den Beitrag noch einmal nachlesen möchtet, findet ihr ihn hier.
Im zweiten Teil soll es nun um eine Kombination aus Hardware und Software gehen. Außerdem betrachten wir reine Softwarelösungen, mit denen ihr ebenfalls in M17 QRV werden könnt. Grundsätzlich unterscheiden wir dabei zwischen:
Ist nur M17-Empfang (RX) möglich, auch Sendebetrieb (TX) oder sogar beides (TRX)?
Wird nur Sprache im Stream Mode unterstützt, nur Daten wie Textnachrichten oder APRS im Packet Mode oder beides?
Für welches oder welche Betriebssysteme ist die Lösung geeignet?
Handelt es sich um eine Kombination aus Hardware und Software oder um eine reine Softwarelösung?
Das Mobilinkd TNC4 unterstützt das Senden und Empfangen von M17 über eine iOS- oder Android-App, die sich per Bluetooth Low Energy (BLE) mit dem TNC verbindet. Das TNC selbst wird an die Datenbuchse eines Funkgeräts angeschlossen. Wichtig ist dabei, dass diese Buchse ein direkt vom Demodulator des Empfängers stammendes Audiosignal – sogenanntes „Flat Audio“, auch als „Baseband Audio“ oder „Diskriminator-Ausgang“ bekannt – bereitstellt.
Auch für das NucleoTNC ist eine experimentelle Firmware verfügbar, die M17 unterstützt. Beide Lösungen richten sich an Funkamateure, die kompakte und portable Möglichkeiten zur digitalen Betriebsart suchen.
DroidStar (TRX, Sprache und Daten: Android, iOS, Windows, Linux und Mac)
DroidStar von Rohith VU3LVO ist eine reine Softwarelösung, die auf einer Vielzahl von Plattformen läuft. Unterstützt werden Android, iOS, Windows, Linux und macOS. Die Anwendung ermöglicht die Verbindung zu M17-Netzwerken über MREF- oder URF-Räume und unterstützt Sprachübertragung (Senden und Empfangen) und neuerdings sogar auch den Versand und Empfang von Textnachrichten über M17.
DroidStar in M17, verbunden mit URF421 Modul D
Wenn ihr Interesse an einer Installationsanleitung speziell für iOS-Geräte habt, lasst es uns gerne in den Kommentaren wissen!
Mehr Informationen und den Download findet ihr auf der offiziellen Projektseite bei GitHub: github.com/nostar/DroidStar
mvoice (TRX, Sprache: Linux)
mvoice von Thomas N7TAE ist eine grafische, rein softwarebasierte M17-Anwendung für Linux. Die Software kann sich mit M17-Reflektoren verbinden und unterstützt auch Routing. Am besten funktioniert mvoice mit einem USB-Headset mit Mikrofon, das direkt an einem Linux-Rechner wie zum Beispiel einem Raspberry Pi angeschlossen wird. Die Audio-Ein- und Ausgabe erfolgt über die Standardgeräte von Pulseaudio oder ALSA.
m17-texting ist eine grafische Anwendung zum Senden von Textnachrichten über M17 im Packet Mode. Die Software ist in C geschrieben und erzeugt M17-Basisbandsignale, die anschließend über ein geeignetes Interface wie dem Digirig Mobile in Verbindung mit einem analogen Funkgerät mit entsprechendem Datenport wie dem Yaesu FTM-6000 übertragen werden können.
m17-fme ist eine eigenständige Softwarelösung zum Kodieren und Dekodieren von M17-Sprach- und Datenpaketen. Sie eignet sich sowohl zum Erzeugen als auch zum Analysieren von M17-Signalen und kann in bestehende Anwendungen integriert oder als eigenständiges Werkzeug genutzt werden.
Beispielhafter Empfang eines M17-Sprachsignal unter m17-fme, Quelle: github.com/lwvmobile/m17-fme
Auch im Bereich der SDR-Software gibt es spannende Möglichkeiten, M17 zu empfangen, zu dekodieren oder sogar zu senden. Nachfolgend nennen wir drei Beispiele, die entweder von Haus aus oder durch Erweiterungen für M17-Sprache und -Daten geeignet sind. In künftigen Beiträgen werden wir diese Softwarelösungen noch genauer vorstellen.
SDRangel (TRX, Sprache und Daten: Windows, Linux und Mac)
SDR++ mit M17 Decoder (RX, Sprache: Windows, Linux, Mac, BSD)
SDRangel erlaubt das Senden und Empfangen von M17 Sprache und DatenSDR++ beim Empfang eines M17-Signals mit aktiviertem M17 Decoder
GNU Radio mit gr-m17 (TRX: Linux)
gr-m17 ist eine Sammlung von GNU Radio-Modulen zur Modulation und Demodulation von M17-Basisbandsignalen. Die Bausteine können direkt in GNU Radio eingebunden werden und ermöglichen so die Verarbeitung von M17-Signalen innerhalb eigener Signalflussdiagramme.
Im Repository sind auch mehrere Beispielprojekte enthalten, darunter ein einfacher „Papagei“, der empfangene Signale wiederholt. Außerdem wird gezeigt, wie sich ein RTL-SDR-Stick zum Empfang und ein PLUTO-SDR für den Sendebetrieb nutzen lassen.
Hinweis: gr-m17 wurde für GNU Radio Version 3.10 entwickelt. In neueren Versionen kann es zu Einschränkungen oder Inkompatibilitäten kommen. Zudem verwendet gr-m17 noch nicht die neue libm17-Bibliothek.
Beispiel eines M17-Papagei, Quelle: github.com/M17-Project/gr-m17
rpitx ist ein Softwareprojekt, das es ermöglicht, HF-Signale direkt über den GPIO-Pin eines Raspberry Pi zu erzeugen. Es nutzt dabei keine klassische Funkhardware, sondern wandelt digitale Daten direkt in ein HF-Signal um, das über eine einfache Drahtantenne abgestrahlt werden kann.
Tomasz SP5LOT demonstriert in einem Video, wie sich mit rpitx Texte im M17-Format aussenden lassen. Die ausgesendeten Daten werden anschließend mit einem SDR-Stick empfangen, in GNU Radio dekodiert und in der Konsole angezeigt.
Wer noch eines der legendären Nokia 3310 oder 3330 in der Schublade hat und gerne bastelt, kann es durch Austausch des Mainboards in einen M17-Daten-Sender und -Empfänger verwandeln. Die Nachrichten werden direkt über die originale Tastatur des Nokia-Handys eingegeben und mithilfe eines SA868S-Funkmoduls im 70 cm-Amateurfunkband ausgesendet. Empfangene und dekodierte Datenpakete erscheinen auf dem Display des Geräts.
Versenden einer Nachricht mit einem modifizierten Nokia 3310, Quelle: m17project.org
Wer selbst eine Anwendung für M17 programmieren möchte, findet mit libm17 eine Software-Bibliothek. Sie ist in C geschrieben und enthält alle Komponenten wie Faltungs- und Golay-Kodierer, Bit-Interleaver, Fehlerkorrektur und Rufzeichenkodierung, die im Protokoll für Stream- und Packet Modi beschrieben sind.
Ein ungewöhnliches, aber spannendes Beispiel für die Verwendung der libm17-Softwarebibliothek ist gba_m17. Dabei handelt es sich um einen M17-Datenkodierer und -dekodierer, der auf einem Game Boy Advance oder in einem entsprechenden Emulator läuft. Auch wenn der GBA längst nicht mehr hergestellt wird und der praktische Nutzen begrenzt ist, demonstriert dieses Projekt eindrucksvoll, wie vielseitig libm17 einsetzbar ist. Es soll dazu inspirieren, ältere Elektronikgeräte, die vielleicht noch in der ein oder anderen Schublade liegen, kreativ neu zu nutzen.
libm17 auf einem GameBoy Advance, Quelle: github.com/sp5wwp/gba_m17
m17-cxx-demod ist ein in C++ geschriebener Software-Modulator und Demodulator für M17-Signale. Er ermöglicht das Dekodieren von M17-Audio-Streams, beispielsweise aus einem Diskriminator-Ausgang oder einer SDR-Quelle. Die Software kann als eigenständiges Kommandozeilenwerkzeug verwendet oder in andere Anwendungen eingebunden werden und ist besonders für Embedded- und Low-Power-Systeme wie dem Mobilinkd TNC4 oder NucleoTNC interessant.
Im ersten und zweiten Beitrag haben wir euch bereits einige Möglichkeiten aufgezeigt, wie ihr in M17 QRV werden könnt – von (fast) schlüsselfertigen Lösungen bis hin zu spannenden, experimentellen Ansätzen für Bastler und Entwickler.
Uns interessiert nun, wo ihr steht: Habt ihr M17 schon ausprobiert? Nutzt ihr bereits Hardware, Software oder SDR-Lösungen? Oder beobachtet ihr die Entwicklung noch mit Interesse von außen?
Wenn ihr M17 selbst ausprobieren möchtet, findet ihr im URF421 unser speziell dafür vorgesehenes Modul T.
Seid ihr an einer der Lösungen genauer interessiert und wüsstet gerne mehr darüber? Schreibt es uns gerne in die Kommentare unter diesem Beitrag oder diskutiert mit uns in unsererTelegram- oder WhatsApp-Gruppe darüber.
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! 😘
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.
Die Wetterstation LaCrosse WS2300 im Testaufbau
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.
Wetterstation auf dem Hausdach am neuen QTH in JO33NO
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.
Wetterdaten Anzeigeeinheit der LaCrosse WS2300
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
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.
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.
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
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.
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! 😘
