MeshCom FW 4.0 – Interna

• (FW -> BLE -> APP) Arten und Aufbau der Pakete
• (FW <- BLE <- APP) Aufforderungen an die FW via BLE

Derzeitiger Stand der Erkenntnis ist, dass grundzätzlich 2 unterschiedliche BLE-Pakete existieren, die man über BLE von der FW empfängt und die sich im 1. Zeichen (ASCII/Byte) zu erkennen geben:

• Messages allgemein: @...
• Datenpakete (JSON): D{"KEY":"value", ...}
• gibt es noch andere?

Der Aufbau eines Message-Paketes stammt aus den allerersten Anfängen der FW-Entwicklung und es wird schwierig sein, dies in der FW v4.xx zu ändern. Ev. werden in der FW v5.xx Änderungen im Aufbau erfolgen.
Der Aufbau des Message-Protokolls (FW -> BLE -> APP) ist eine Mischung aus ASCII + Bytes + Combo-Bytes + UTF-8, was die Dekodierung schwieriger gestaltet.

bb = Byte
hh = binary combo
aa = Path [ASCII]
dt = Destination + Typ [ASCII] (verschiedene Varianten)
[weitere Parameter] sind abhängig von der Unterart einer Message

Varianten für dt

• *: = Message to all

• 123: = Message to Group 123

• OE3WAS-12: = DM (DirectMessage) to OE3WAS-12

• *:{CET} = Date & Time (wird nur übertragen, wenn GW ist; bei CL nicht)

• *! = POS-String

• DM ist dann, wenn DM == eigener CALL

• GRP-Msg dient zum Vergleich mit den abonnierten Gruppen

siehe hier: https://github.com/karamo/MeshAll42_MIT-AI2/blob/main/MeshCOM_Interna/MeshCom-ACK.md#meshcom-ack-system-dokumentation

…
…
[TODO] Diese Datenstruktur & Liste sind u.U. unvollständig und können auf Grund neuer Erkenntnisse geändert werden.

Da Datenpakete als ein JSON-String formatiert sind, lassen sich die "key":"value" Paare recht einfach dekodieren. Es wäre so einfach gewesen, alle BLE-Daten als String empfangen zu können. Aber auf Grund des unsäglichen Aufbaus des Message Protokolls war es erforderlich, alle Daten als Bytes zu empfangen und diese Byte-Folge in UTF-8 umzukonvertieren.

Bei den Datenpaketen ist der grundsätzliche Aufbau so, dass im Key "TYP":"xx" das "xx" (Value) verschiedene Werte annehmen kann und so die Pakete unterscheidet.

Folgende Typen (Value) sind derzeit bekannt:

• „I“ == --info
• „SE“ == --seset
• „SW“ == --wifiset
• „SN“ == --nodeset
• „W“ == --wx | --weather
• „G“ == --pos
• „SA“ == --aprsset
• „IO“ == --io
• „TM“ == --tel
• „AN“ == --analogset
• „MH“

Es gibt verschiedene Anforderungspakete an die FW, also das „Senden“.
Falls nicht anderes vermerkt, ist Darstellung als Hex-Bytes (0x..).

Zu aller erst muss einmal der initiale Start der Kommunikation durch das sog. {HELLO}-Paket erfolgen, welches gesendet werden muss.

In der Folge kommen von der FW mehrere Datenpakete, die die Parameter enthalten (I, SE, SW, SN, W, G, SA).
Auch die noch in der FW empfangenen und gespeicherten Nachrichten werden übertragen (@:).
Das Datenpaket mit dem „TYP“:“MH“ wird zwischendurch mal gesendet.
Das Ende dieser Übertragung wird durch ein spezielles Datenpaket signalisiert:

Anschließend an CONFFIN schickt die APP ein Timestamp-Paket, z.B.:

06 20 CF 7D DE 67 
[BLE] Timestamp from phone (sec) <UTC>: 1742634447 -> 2025.03.22 09:07:27

Daran anschließend können eigene Commands & Messages an die FW geschickt werden.

Messages und Commands sind grundsätzlich gleich aufgebaut, wobei len die Anzahl der Message-Bytes ist, gefolgt von der Msg-ID und den Message-Bytes.
ACHTUNG: In UTF-8 sind tw. mehr als 1 Byte/Zeichen!

len & ID sind als Hex-Byte dargestellt, die Message bzw. der Command sind als ASCII/UTF-8 dargestellt. Bei den Commands ist Groß-/Kleinschreibung unbedeutend und wird hier nur der Klarheit wegen unterschiedlich geschrieben.

Es gibt eine Gruppe von Commands, die einen anderen ID habe, aber grundsätzlich gleich aufgebaut sind. Der jeweilige Command hat aber logischerweise eine eigene Syntax.
Mittlerweile sind alle diese Config Messages auch als --command abzusenden.

Msg-ID:

• 0x20 – Timestamp from phone (--settime) [4Bytes]
• 0x50 – Callsign (--setCALL) [1Byte len – Callsign]
• 0x55 – Wifi SSID (--setSSID) and PWD (--setPWD) [1Byte – SSID Length – SSID – 1Byte PWD Length – PWD]
• 0x70 – Latitude (--setLAT) [1Byte length + 1Byte Msg-ID + 4Bytes lat + 1Byte save_flag]
• 0x80 – Longitude (--setLON) [1Byte length + 1Byte Msg-ID + 4Bytes lon + 1Bytes save_flag]
• 0x90 – Altitude (--setALT) [1Byte length + 1Byte Msg-ID + 4Bytes alt + 1Byte save_flag]
• 0x95 – APRS Symbols (--symID --symCD)
• 0xF0 – Save Settings to Flash (--save)
• save_flag is 0x0A for save and 0x0B for don’t save (Aus Z.365ff https://github.com/icssw-org/MeshCom-Firmware/blob/oe1kfr_434q/src/phone_commands.cpp)

[TODO] weitere Infos folgen …

Als „externe Hardware“ werden verschiedene Sensoren und eine Digital-I/O-Erweiterung beschrieben.

In der MT-FW 4.34v werden verschiedene Sensoren unterstützt. Nicht alle sind derzeit ausreichend beschrieben. Daher versuche ich hier ein möglichst detailierte Beschreibung zu erstellen, mit den einzelnen Parametern zu den jeweiligen Sensoren.

Die wichtigsten üblichen Umweltdaten sind: Temperatur [°C], rel.Feuchte [%rH], Luftdruck [hPa]
Weiter Parameter sind: Luftqualität, CO₂ [ppm] u.a.

• Addr in Hex
• /X = Kennung in POS-Msg (V=2 hat Priorität gegenüber V=3)
• (*) = die Temperatur dient zur internen Kompensation und ist daher etwas höher als reale Umwelt.
• MCU811 WAK-GND Verbindung zusätzlich zu I²C.

Derzeit wird offiziell nur ein INA226 (Spannung[V]-Strom[A]-Leistung[W] Sensor in der 20A-Ausführung mit einem R_S=2 mΩ [R002]) unterstützt.

Es wird ein MCP23017 16-Pin-I/O auf I²C Addr=0x20 unterstützt.
Die 16 IOs sind durch A0..A7, B0..B7 gekennzeichnet. Die Steuerung ist via Terminal, BLE & UDP (Web-Client) möglich.

Befehle via Terminal & BLE-APP:

• --io liefert auf BLE ein JSON-Paket
• --setio clear setzt alle IOs auf INPUT
• --setio {A0..A7,B0..B7} {in | out} setzt die Funktion des gewählten IO auf INPUT oder OUTPUT
• --setout {A0..A7,B0..B7} {high | low} setzt den gewählten IO auf HIGH oder LOW

©️ 11.7.2025 by OE3WAS – Wolfgang