von Ich hatte ja schon über meine Projekte berichtet, wo ich den kleinen SoC auf ESP32-Basis zum Einsatz gebracht hatte. Einerseits hier im Home-QTH die Überwachung meiner XPA125B-PA in Sachen Leistung, SWR und Bandwahl und das gerade fertiggestellte Projekt RX200 SWR-Meter für meinen zweiten SDR Hermes-Lite 2, der sich in der Klubstation DF0BAU als Remote-Station befindet.
Falls die Frage aufkommt: „Gibts auch Ton, also was zu hören ?“ – nein, das gibts nicht und wird es nicht geben. Dafür ist der kleine ESP32-SoC leider nicht ausgestattet und auch nicht in der Lage, eine Art Audiostreaming machen zu können. Es gibt also nur was zu „sehen“.
Ziel dieses Projekts ist nicht, eine Art WebSDR bereitzustellen, es soll nur der technische Status meines SDR-Transceivers auf meinem Blog abgebildet werden, um mehr oder weniger live meine Funkaktivitäten verfolgen zu können.
IoT – was ist das nun wieder ?
Ganz einfach, es heißt „Internet of Things“, zu dt. „Internet der Dinge“. Dabei geht es nicht um PC, Tablets, Notebooks oder Smartphones, sondern um viel kleinere, meist Minirechner oder auch SoC („System-on-a-Chip“) genannt. Vorteil dieser kleinen Systeme – alles ist meistens auf nur einem einzigen Chip untergebracht, der noch dazu meist sehr winzig ist. Ausgestattet meist mit WiFi und/oder Bluetooth und allem, was man so benötigt. Als Beispiel sind hier die bereits von mir verwendeten ESP32-SoC zu nennen. Diese kleinen SoC haben viele Anschlüsse, mit denen man im Grunde verschiedene Messaufgaben erledigen kann, man kann mittels Temperatursensor die Temperatur messen, den Luftdruck, die Spannung – also der ganze Bereich der Sensorik. Weiterhin kann man mit digitalen Input und Output-Anschlüssen Schaltaufgaben, entweder manuell oder automatisch gesteuert, erledigen – wo wir dann im Bereich der Automation angekommen sind. Viele haben ja sowas schon als „Home-Automation“ im Einsatz. Meistens sind es jedoch fertige Geräte oder besser ganze Systeme, die sich mittels Apps dann per Smartphone oder Browser steuern lassen. Sowas geht natürlich auch im Bereich DIY – also Selbstbau. Das habe ich ja bereits mit den zwei genannten Projekten speziell für die Anwendung im Amateurfunk gezeigt. Gut, die erforderliche Software musste ich natürlich selber entwickeln, das gehört ebenfalls zum DIY dazu.
Um nun die ganzen anfallenden Daten an einer zentralen Stelle zu bündeln, haben clevere Entwickler eine Software namens MQTT („Message Queuing Telemetry Transport“) entwickelt, das die Übertragung von Telemetriedaten in Form von Nachrichten zwischen Geräten ermöglicht, trotz hoher Verzögerungen oder beschränkter, langsamer oder auch nur teilweise sich im Online-Betrieb befindlicher Netzwerke – in erster Linie für M2M („Machine-to-Machine“)-Kommunikation. So einen MQTT-Server, auch MQTT-Broker genannt, habe ich bereits längere Zeit auf meinem gemieteten Server in einem Rechenzentrum in Betrieb. Eben dort, wo auch dieses Blog hier technisch betrieben wird.
Meine Idee – Ihr seht den technischen Zustand meines SDR-Tranceivers
Eine Idee, die mir schon länger im Kopf rumgeistert und wieder ans Licht kam im Zusammenhang mit einer Frage unseres Klubstationsleiters Fred/DL1VFR von DF0BAU, wo ich ja seit Kurzem einen SDR-Transceiver als Remote-Station aufgebaut habe: „Wie sehe ich, ob Aktivität – da ja quasi unbemannt – an der Remotestation stattfindet ?“. Natürlich ist das für den Leiter der Klubstation und damit auch dem Verantwortlichen für die Technik und alle Räumlichkeiten, nicht ganz uninteressant. Grundlegende Kenntnis, wer wann wo wie was da tut, ist schon wichtig. Schließlich haben wir ja auch ein Anwesenheitsbuch, wo sich die Nutzer der Klubstation eintragen, wenn sie dort tätig werden. Unbemannt bei Remotebetrieb ist das schon etwas schwieriger. Ich habe mir also diese Frage durch den Kopf gehen lassen und mal eine Art PoC („Proof-of-concept“), also eine Machbarkeitsstudie, umgesetzt. Eben mit dem, was bereits vorhanden war oder ist. Grade die Möglichkeiten von MQTT sind dafür eigentlich sehr gut geeignet. Da MQTT auch mit den Entwicklertools der ESP32 zur Verfügung steht, lag es nahe, das in diese Richtung umzusetzen.
Funktionsprinzip des gesamten MQTT-Netzwerkes
Technische Umsetzung
Datenerfassung
Zuerst erfassen wir die Spannungen des Richtkopplers (SWR-Messbrücke) des RX200 und führen diese zur Messung zwei ADC-Inputs des ESP32-SoC zu. Die ADC habe ich kalibriert, so daß die Messergebnisse mit denen des Zeigerinstruments übereinstimmen. Weiterhin erzeugt der Hermes-Lite 2 intern eine Bandspannung, die ich ebenfalls einem weiteren ADC-Input zuführe und damit das gewählte Band entsprechend der Höhe der Spannung bestimmen kann. Zu Hause erzeuge ich zusätzlich per DAC wieder eine Ausgangsspannung für die automatische Bandumschaltung der XPA125B. Diese folgt aber anderen Spannungswerten wie der Hermes-Lite 2, also nutze ich den ESP32-SoC gleich als eine Art Konverter, um die Bandspannung anzupassen (für die PA). Das PTT-Signal (Low Active) führe ich einem digitalen Input zu und habe damit den Zustand RX oder TX des Hermes-Lite 2 ebenfalls verfügbar. Damit habe ich den Bereich Sensorik bereits abgeschlossen.
Softwareentwicklung für den ESP32-SoC
Ich entwickle mit der Arduino-IDE und den von Espressif bereitgestellten SDK für die ESP32. Das erfolgt in der Sprache C++. Zusätzlich benutze ich Erweiterungsbibliotheken wie
- ESPAsyncWebserver (kleiner, aber feiner Webserver für IoT-Systeme)
- AsyncTCP (enthält u.a. Websockets)
Mittels des Webservers kann ich per Internetbrowser auf den ESP32-SoC zugreifen und damit meine Messungen optisch darstellen. Das geht wohl im lokalen Netzwerk als auch per remote, solange ich per Netzwerk den ESP32 erreichbar machen kann (remote per VPN). Damit die Messwerte in Echtzeit im Browser angezeigt werden können, benutze ich die sog. Websocket-Technik (basiert auf JavaScript). Damit lassen sich in einer einmal geladenen HTML-Seite anzeigte Werte quasi live aktualisieren, ohne die ganze Seite neu laden zu müssen. Das ist also eine Art Echtzeitdarstellung mit sehr geringem Ressourcenbedarf. Da es eine Art Kommunikationskanal gibt, der nicht nur in eine Richtung arbeitet, könnte man ebenfalls Interaktionen im Browser, z.B. das Klicken eines Buttons wiederrum zur einer Schaltaktion eines digitalen Outputs des ESP32 verwenden.
Bis hierhin stellt das alles eine mehr oder wenige lokale Lösung innerhalb der eigenen lokalen Netzwerke dar. Remotezugriff ist möglich, wenn das andere Netzwerk erreicht werden kann, was u.a. per gesicherter VPN-Verbindung gehen würde. Also bis hier ist nichts für „außen“ gebaut oder gedacht, nur für „interne Nutzung“.
Jetzt schicken wir Daten nach außen ins Internet
Ich habe also die bereits laufende Applikation erweitert, und zwar um einen MQTT-Clienten. Den benötige ich, um meinen ESP32-SoC mit meinem MQTT-Broker/-Server auf meinem Server, der sich im Rechenzentrum befindet, kommunizieren zu lassen. Das MQTT-Protokoll ist eine Art SMS für Sensoren und kurze Statusinformationen. Also eher für Zustände wie EIN oder AUS oder einen Messwert, speziell zwischen Systemen – also M2M, Maschine-zu-Maschine. Da gehe ich jetzt nicht genauer darauf ein, wen das interessiert – das Internet ist voll von Beschreibungen bezüglich MQTT.
Hier eine vom ESP32 gesendete und vom MQTT-Broker verarbeitete Message.
Das verwendete Format ist JSON, ein flexibles Formate um Daten unterschiedlicher Art strukturiert verarbeiten zu können.
Ich sende also, getriggert von Ereignissen wie PTT AN oder PTT AUS oder Bandwechsel diese Statusinformationen an den MQTT-Broker. Diese werden dort gespeichert oder an aktuell verbundene weitere Systeme sofort weitergeleitet, wie Nachrichten behandelt werden, lässt sich ebenfalls genau steuern. Es gibt also eine Art Priorisierung und ebenfalls Kategorisierung dieser MQTT-Messages.
Wie landen diese Daten jetzt auf der Homepage meines Blogs ?
Wir sind also bereits soweit, das wir Daten auf dem MQTT-Broker geschickt bekommen. Diese müssen wir jetzt weiterverarbeiten und auf der Homepage sichtbar machen. Dazu bedienen wir uns bereits fertiger Scripte in JavaScript, da JavaScript von unseren Internetbrowsern ausgeführt werden kann. Der Browser lädt also ein kleines Stück Software, um sich die Daten vom MQTT-Broker schicken lassen zu können. Auch hier bedienen wir uns wieder der Websocket-Technik, nur in einer leicht anderen Form.
Als MQTT-Scripttool kommt Paho-MQTT in der JavaScript-Version zum Einsatz. Paho-MQTT gibt es auch für andere Anwendungszwecke wie PHP, C++, Python und andere Programmiersprachen. Ich habe wi schon beim ESP32-SoC eine kleine HTML-Seite gebaut, die dann im Blog als Widget mittels iFrame-Technik eingebunden wird.
Hier ist der Abschnitt auf meinem Blog zu sehen, wo dann der Status meines SDR anzeigt wird:
- aktuell gewähltes Band am Hermes-Lite 2
- aktueller Zustand RX oder TX
- Zeitpunkt der letzten Statusänderung, also wann die letzte MQTT-Message empfangen wurde
Wenn ich natürlich nicht QRV bin, ändert sich auch der Status nicht. Es ist ein eventgesteuertes System, d.h. nur bei Änderungen werden diese Daten erneuert oder verändert.
Probiert es gerne aus, wichtig ist, JavaScript darf an Eurem Browser nicht deaktiviert sein, dann würde es nicht funktionieren. Die Verbindung zum Webserver als auch zum MQTT-Broker erfolgt verschlüsselt und ist per SSL abgesichert. Euer Internetrouter darf ebenfalls nicht den Port 8884 ausgehend blockieren, dann erreicht das Script nicht den MQTT-Broker.
Eine Erweiterung für den zweiten SDR-Transceiver an der Klubstation in Wilthen wird noch umgesetzt, jedoch muss ich da auch nocht die Applikation für MQTT umbauen bzw. erweitern. Eine Bandanzeige wird es allerdings dort nicht geben, das ist aus technischen Gründen dort nicht vorgesehen, da es da keine Notwendigkeit gab, Bandspannung zu verarbeiten. Dor dort eingesetzte PA erkennt selbst die Sendefrequenz und schaltet das Bandfilter automatisch um. Deswegen habe ich diesen Teil da nicht implementiert und plane es (vorerst) auch nicht.
