MeshCom FW 4.0 - Interna

• (FW -> BLE -> APP) Types and structure of the packages
• (FW <- BLE <- APP) Aufforderungen an die FW via BLE

The current state of knowledge is that there are basically 2 different BLE packets that are received from the FW via BLE and that can be recognized by the 1st character (ASCII/byte):

• Messages in general: @...
• data packets (JSON): D{"KEY":"value", ...}
• Are there any others?

The structure of a message package dates back to the very early days of FW development and it will be difficult to change this in FW v4.xx. There may be changes to the structure in FW v5.xx.
The structure of the message protocol (FW -> BLE -> APP) is a mixture of ASCII + bytes + combo bytes + UTF-8, which makes decoding more difficult.

bb = Byte
hh = binary combo
aa = Path [ASCII]
dt = Destination + Type [ASCII] (different variants)
[Further parameters] depend on the subtype of a message

Variants for dt

• *: = Message to all

• 123: = Message to Group 123

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

• *:{CET} = Date & Time (only transmitted if GW is; not for CL)

• *! = POS string

• DM is when DM == own CALL

• GRP-Msg is used for comparison with the subscribed groups

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

...
...
[TODO] This data structure & list may be incomplete and may be subject to change based on new findings.

Since data packets are formatted as a JSON string, the "key":"value" decode pairs quite easily. It would have been so easy to receive all BLE data as a string. But due to the unspeakable structure of the message protocol, it was necessary, receive all data as bytes and convert this byte sequence to UTF-8.

The basic structure of the data packets is as follows: in the key "TYP":"xx" the "xx" (Value) can assume different values and thus differentiate the packages.

The following types (value) are currently known:

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

There are various request packets for the FW, i.e. the "send".
Unless otherwise noted, representation is as hex bytes (0x..).

First of all, the initial start of communication must take place with the so-called {HELLO} packet, which must be sent.

The FW then sends several data packets containing the parameters (I, SE, SW, SN, W, G, SA).
The messages still received and stored in the FW are also transmitted (@:).
The data packet with the "TYPE": "MH" is sent once in between.
The end of this transmission is signaled by a special data packet:

The APP then sends a timestamp packet to CONFFIN, e.g:

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

You can then send your own commands and messages to the FW.

Messages and commands are basically structured in the same way, whereby len is the number of message bytes, followed by the Msg-ID and the message bytes.
ATTENTION: In UTF-8 there are sometimes more than 1 byte/character!

len & ID are represented as hex bytes, the message or command is represented as ASCII/UTF-8. The commands are not case-sensitive and are only written differently here for the sake of clarity.

There is a group of commands that have a different ID but are basically structured in the same way. However, the respective command logically has its own syntax.
In the meantime, all these config messages are also available as --command to be sent.

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 (From Z.365ff https://github.com/icssw-org/MeshCom-Firmware/blob/oe1kfr_434q/src/phone_commands.cpp)

[TODO] more info to follow ...

Various sensors and a digital I/O extension are described as "external hardware".

Various sensors are supported in MT-FW 4.34v. Not all of them are currently sufficiently described. Therefore, I will try to create a detailed description with the individual parameters for the respective sensors.

The most important common environmental data are: Temperature [°C], relative humidity [%rH], air pressure [hPa]
Further parameters are: Air quality, _CO2 [ppm] and others.

• Addr in Hex
• /X = Identifier in POS-Msg (V=2 has priority over V=3)
• (*) = the temperature is used for internal compensation and is therefore slightly higher than the real environment.
• MCU811 WAK-GND connection in addition to I²C.

Currently, only one INA226 (voltage [V]-current [A]-power [W] sensor in the 20A version with an _RS=2 mΩ [R002]) is officially supported.

An MCP23017 16-pin I/O on I²C Addr=0x20 is supported.
The 16 IOs are identified by A0..A7, B0..B7. Control is possible via terminal, BLE & UDP (web client).

Commands via terminal & BLE APP:

• --io delivers a JSON package on BLE
• --setio clear sets all IOs to INPUT
• --setio {A0..A7,B0..B7} {in | out} sets the function of the selected IO to INPUT or OUTPUT
• --setout {A0..A7,B0..B7} {high | low} sets the selected IO to HIGH or LOW

©️ 11.7.2025 by OE3WAS - Wolfgang