Meshtastic Moduleinstellungen

Serial Modul

Das Modul Serial dient der Kommunikation mit einer Node über eine serielle Schnittstelle (USB oder UART). Der WebClient und das Meshtastic Python CLI nutzen diese Schnittstelle zur Konfiguration und zum Austausch von Daten.

Konfiguration der seriellen Schnittstelle

Zur Konfiguration dieser seriellen Schnittstelle gibt es die folgenden Optionen:

Konfiguration	Schalter	Funktion
Serial enabled	ON	Die serielle Schnittstelle wird aktiviert.
Echo enabled	OFF	Wenn ON, dann werden alle gesendeten Daten zum Geräte zurückgesendeet (Echo)
Mode	SIMPLE	SIMPLE arbeitet wie ein einfacher UART-Tunnel. Was reingeht, kommt auch wieder raus. Dafür ist ein Kanal namens "serial" erforderlich. SIMPLE ist Default.
	PROTO	PROTO stellt die Protobuf-Client-API an der seriellen Schnittstelle zur Verfügung. Die API wird verwendet, um eine Verbindung von einem anderen Gerät herzustellen, siehe die Arduino-Client-Bibliothek und die API-Referenz.
	TEXTMSG	Mit TEXTMSG kann eine Zeichenfolge über die serielle Schnittstelle an das Gerät gesendet werden, die dann als Textnachricht auf dem Standardkanal gesendet wird. Jede Textnachricht, die vom Netz empfangen wird, wird wie folgt an den seriellen Anschluss gesendet: <Short Name>: <Text>.
	NMEA	NMEA gibt einen NMEA 0183-Datenstrom aus, der interne GPS-Daten oder eine feste Position und andere Knotenpunkte als Wegpunkte (WPL) enthält.
	CALTOPO	CALTOPO gibt alle 10 Sekunden NMEA 0183 Wegpunkte (WPL) für alle gültigen Knotenpunkte aus, die von CalTopo / SARTopo verwendet werden können. *)
	WS85	WS85 analysiert und berechnet die Windgeschwindigkeitsdaten, die über die serielle Schnittstelle vom Ecowitt WS85 empfangen werden. Die erfassten Messwerte werden alle 5 Minuten per Telemetrie-Paket übertragen. Eine Modifikation des WS85-Wettersensors ist erforderlich. Wenn die Option in der App nicht verfügbar ist, kann sie mit dem CLI-Befehl "meshtastic --set serial.mode 6" aktiviert werden.
Receive GPIO Pin	Pin #	Pin für den Empfang serielle Daten - RxD.
Transmit GPIO Pin	Pin #	Pin für das Versenden serieller Daten - TxD.
Baud Rate	BAUD_9600	Die Baudrate des seriellen Interfaces.
Timeout	Millisekunden	Die Wartezeit, nach der ein empfangenes Paket als "komplett" betrachtet wird.
Override Console Serial Port	OFF	Wenn ON, kann das serielle Interface den seriellen USB-Bus für die Ausgabe verwenden. Dies ist nur für die Modi NMEA und CALTOPO nützlich und kann sich in anderen Modi seltsam verhalten oder überhaupt nicht funktionieren. Die Einstellung der TX/RX-Pins in der Konfiguration des seriellen Moduls führt dazu, dass diese Einstellung ignoriert wird.

*) CalTopo und SARTopo sind leistungsstarke Mapping-Plattformen, die Ihnen modern digitale Kartierungswerkzeuge an die Hand geben. Detaillierte Informationen finden Sie unter https://training.caltopo.com/all_users/getting-started und https://sartopo.com/help.

Anwendungsbeispiele

((in Bearbeitung))

Store & Forward Modul

Mit dem Modul Store & Forward (S&F) konfiguriert man eine Node dazu Nachrichten, die innerhalb eines privaten Kanals ausgetauscht werden, für einen späteren Abruf zu speichern. Damit haben Anwender die Möglichkeit Nachrichten zeitlich versetzt abzurufen. Selbst wenn man sich zeitweilig außerhalb der Reichweite eines Meshes befindet oder seine Node zum Zeitpunkt einer Nachricht nicht eingeschaltet hatte gehen Nachrichten nicht verloren, weil man sie innerhalb eines definierten Zeitfensters jederzeit wieder abrufen kann.

Als S&F-Server können sowohl Nodes mit der Rolle ROUTER als auch CLIENT eingesetzt werden. Die Konfiguration dieser beiden Rollen unterscheidet sich nur in einem einzigen Punkt: ein CLIENT muss explizit als Server deklariert sein. Eine Einschränkung der Funktionalität findet nicht statt. Sowohl CLIENT als auch ROUTER funktionieren weiterhin wie gewohnt, sie haben nur eine zusätzliche Aufgabe.

Hardware Voraussetzungen

Das Modul S&F lässt sich nur auf einer ESP32-Hardware mit PSRAM aktivieren. PSRAM steht für “pseudo static RAM”, also ein Speicher der nur während der Laufzeit einer Node zur Verfügung steht. Nach dem Restart einer Node ist dieser Speicher wieder gelöscht.

PSRAM

Leider ist es fast unmöglich aus den Angaben der Hersteller darauf zu schließen ob der verbaute ESP32 PSRAM besitzt und falls dies der Fall sein sollte, ob Meshtastic bei dem jeweiligen Modell die Funktion S&F unterstützt. Allein von dem oft verwendeten Modell

ESP32-S3 gibt es 29 Variationen teils mit, teils ohne PSRAM.

Eindeutig bestätigt von Meshtastic sind bisher nur die Modelle

- T3-S3 Prozessor: ESP32-S3 FH4R2

- T-Beam Prozessor: ESP32

- T-Beam Supreme Prozessor: ESP32-S3 FN8

Diese Modelle besitzen alle 8MB PSRAM.

Dagegen bietet z.B. der Heltec Wireless Tracker, obwohl er einen ESP32-S3 FN8 Prozessor verbaut hat, keinen PSRAM. Letztendliche Gewissheit ob die zur Verfügung stehende Hardware S&F unterstützt lässt sich nur durch einen konkreten Test ermitteln, zumal Die Geräteeinstellung z.Zt. keinerlei Plausibilitätsprüfung der eingesetzten Hardware durchführt.

Konfiguration der Node “Test S&F” als S&F-Server

Vorweg: S&F lässt sich nur für private Kanäle einrichten. Alle abweichenden Versuche werden mit der folgenden Fehlermeldung quittiert: S&F not permitted on the public Channel (siehe Galerie Bild 1)

Mit der Beschränkung auf private Kanäle wird eine unnötige Überlastung des öffentlichen Netzes durch “SF”-Anfragen verhindert.

Die Funktion des Servers wird mit einer Lilygo T3-S3 node als CLIENT besetzt. Als primärer Kanal wird “Babenhausen” eingerichtet. Up- und Download sind aktiviert. Der sekundäre Kanal ist der Standard-Kanal mit dem default Schlüssel “AQ==” (siehe Galerie Bild 2)

Einstellungen des Moduls “Store & Forward”

Store & Forward enabled = ON

Da wir einen CLIENT für den Test benutzen ist diese Einstellung erforderlich.

Heartbeat = ON

Diese Einstellung sendet in Intervallen von 15 Minuten ein Signal welches das Node im Mesh als S&F-Server bekannt macht. Um unnötigen Netzwerk Traffic zu vermeiden sollte diese Option nicht dauerhaft aktiviert sein. Es sollte völlig ausreichen wenn das Nodes des privaten Kanals einmal den “S&F”-Server identifiziert haben. Leider wird unter Android der Server als solches nicht gekennzeichnet. Es empfiehlt sich also ihn über die Namensgebung mit einem Zusatz “S&F” kenntlich zu machen.

Number of records

Anzahl der Sätze die max. Im PSRAM gespeichert werden. Beim Defaultwert 0 werden 2/3 des Speichers für S&F reserviert was einer Anzahl von ca. 11.000 Sätzen entspricht.

History return max

Die max. Anzahl an Sätzen die an eine Node nach einer Abfrage zurückgesendet wird.

History return window

Anzahl Minuten die eine Nachricht auf dem Server zum Abruf vorgehalten wird.

Server = ON

Auf einer Node vom Typ CLIENT muss diese Option aktiviert sein.

(siehe Galerie Bild 3)

Anwendungsbeispiel

Eine Dorfgemeinschaft hat sich entschlossen ihre sozialen Interessen auch mit Meshtastic zu unterstützen. Es wird ein zentraler Client mit dem Namen “Babenhausen” installiert. Als primärer Kanal wird “Babenhausen” und als sekundärer Kanal LongFast mit dem Default PSK “AQ==”. Alle Beteiligten wählen ebenso “Babenhausen” als primären Kanal und die sekundären Kanäle nach eigenem Interesse. Es stellt sich schnell heraus, dass es Teilnehmer gibt die tagsüber arbeitsbedingt sich außerhalb des Meshes aufhalten. Andere wiederum beklagen sich über die zu geringe Akkulaufzeit ihrer node und vergessen den Akku rechtzeitig aufzuladen. Als Lösung wird nun die zentrale node “Babenhausen ” zusätzlich als S&F-Server konfiguriert und damit gewährleistet, dass jeder Teilnehmer Nachrichten auch zeitversetzt abrufen kann. Zu beachten ist, dass die Nachrichten immer an den Kanal und nicht an die einzelne Node geschickt werden müssen. Der “S&F”-Server speichert die Nachrichten für jede einzelne Node die zum Kanal gehört. Dies sollte auch bei der Einrichtung im Feld “Number of records” berücksichtigt werden.

Testszenario

Es werden 3 Nodes verwendet. Alle haben den privaten Kanal Babenhausen als Primary und LongFast als Secondary konfiguriert und die FW 2.6 installiert.

1. RH Home (RH), Heltec V3, CLIENT_MUTE, Kanäle privat, privat, LongFast

2. RH Mobil (Rm), RAK4631, CLIENT

3. Test S&F (TS), Tlora T3-S3, CLIENT

Testablauf

1. Nachrichten von “RH” an gemeinsamen Kanal Babenhausen. Auf dem Display des S&F-Servers (TS) wird nichts angezeigt, da er die Nachricht nur speichern soll. Alle Teilnehmer die im Netz aktiv eingebunden sind erhalten diese Nachricht direkt übermittelt. (siehe Galerie Bild 4)

2. Da die Node “Rm” nicht angemeldet oder außerhalb der Reichweite war sendet sie, sobald sie wieder “Zugriff” auf den S&F-Server (TS) hat die Message “SF”. Der Server meldet das er eine neue Nachricht hat:

Total messages: 1

History Window: 480min

Last Request: 1

(siehe Galerie Bild 5)

Unmittelbar darauf wird die Nachricht an den Node “Rm” übermittelt (siehe Galerie Bild 6)

Der Server übermittelt die Nachricht die von “RH” gesendet wurde mit der Uhrzeit der Absendung. Bei einer erneuten “SF” Nachricht an den S&F-Server kommt die Meldung “Total messages: 0”, d.h. die Nachricht wurde auf dem Server für die Node gelöscht da sie bereits abgefragt wurde. Für alle anderen Nodes bleibt sie innerhalb des voreingestellten Zeitfensters noch hinterlegt. (siehe Galerie Bild 7)

Ausblick

Da Nodes mit dem Nordic nRF52840 Modul wegen fehlendem PSRAM das “S&F” feature nicht unterstützen wurde ein sogenannter pull request erstellt um z.B. das SD-Modul RAK15002 von RAKWireless zu unterstützen:

Use SD card as store&forward memory #5083

https://github.com/meshtastic/firmware/pull/5083

Ob und wann diese Anforderung realisiert wird kann zum jetzigen Zeitpunkt nicht gesagt werden.

• 
  Galerie Bild 1
• 
  Galerie Bild 2
• 
  Galerie Bild 3
• 
  Galerie Bild 4
• 
  Galerie Bild 5
• 
  Galerie Bild 6
• 
  Galerie Bild 7

Verfasser/Autor: Möchte nicht genannt werden

Besten Dank für diesen Gastbeitrag/Artikel