MeshCom FW 4.0 – Informazioni interne

• (FW -> BLE -> APP) Tipi e struttura dei pacchetti
• (FW <- BLE <- APP) Aufforderungen an die FW via BLE

Allo stato attuale delle conoscenze, esistono fondamentalmente due diversi pacchetti BLE che vengono ricevuti tramite BLE dal firmware e che si distinguono in base al primo carattere (ASCII/byte):

• Messaggi in generale: @...
• Pacchetti di dati (JSON): D{"KEY":"value", ...}
• Ce ne sono altri?

La struttura di un pacchetto di messaggi risale agli albori dello sviluppo del firmware e sarà difficile modificarla nella versione v4.xx. È possibile che nella versione v5.xx vengano apportate modifiche alla struttura.
La struttura del protocollo di messaggistica (FW -> BLE -> APP) è un mix di ASCII + byte + byte combinati + UTF-8, il che rende più difficile la decodifica.

bb = byte
hh = combinazione binaria
aa = Percorso [ASCII]
dt = Destinazione + Tipo [ASCII] (varie varianti)
[ulteriori parametri] dipendono dalla sottotipo di un messaggio

Varianti per dt

• *: = Messaggio a tutti

• 123: = Messaggio al gruppo 123

• OE3WAS-12: = DM (messaggio diretto) a OE3WAS-12

• *:{CET} = Data e ora (viene trasmessa solo se si tratta di GW; non in caso di CL)

• *! = stringa POS

• Si ha DM quando DM == CALL proprio

• GRP-Msg serve per il confronto con i gruppi a cui si è iscritti

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

…
…
[TODO] Questa struttura dei dati e questo elenco potrebbero essere incompleti e potrebbero subire modifiche alla luce di nuove informazioni.

Poiché i pacchetti di dati sono formattati come stringhe JSON, è possibile "key":"value" Decodificare le coppie è piuttosto semplice. Sarebbe stato così facile ricevere tutti i dati BLE sotto forma di stringa. Ma a causa della struttura assurda del protocollo di messaggistica, è stato necessario, ricevere tutti i dati in byte e convertire questa sequenza di byte in UTF-8.

Per quanto riguarda i pacchetti di dati, la struttura di base prevede che nella chiave "TYP":"xx" quello "xx" (Value) può assumere valori diversi e in questo modo distingue i pacchetti.

Attualmente sono noti i seguenti tipi (Value):

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

Esistono diversi pacchetti di requisiti relativi alla FW, ovvero alla “trasmissione”.
Se non diversamente specificato, i valori sono espressi in byte esadecimali (0x..).

Innanzitutto, l'avvio iniziale della comunicazione deve avvenire tramite il cosiddetto pacchetto {HELLO}, che deve essere inviato.

Successivamente, dall'FW arrivano diversi pacchetti di dati contenenti i parametri (I, SE, SW, SN, W, G, SA).
Vengono trasmessi anche i messaggi ancora ricevuti e memorizzati nel FW (@:).
Di tanto in tanto viene inviato il pacchetto di dati con«TYP»: «MH».
La fine di questa trasmissione viene segnalata da uno speciale pacchetto di dati:

Al termine diCONFFIN, l'APP invia un pacchetto di timestamp, ad esempio:

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

Successivamente è possibile inviare comandi e messaggi personalizzati al firmware.

I messaggi e i comandi hanno fondamentalmente la stessa struttura, per cui len il numero di byte del messaggio, seguito dall'ID del messaggio e dai byte del messaggio.
ATTENZIONE: In UTF-8, alcuni caratteri occupano più di 1 byte!

len & ID sono rappresentati come byte esadecimali, mentre il messaggio e il comando sono rappresentati in formato ASCII/UTF-8. Per i comandi, la distinzione tra maiuscole e minuscole non ha alcuna rilevanza e viene qui utilizzata solo per motivi di chiarezza.

Esiste un gruppo di comandi che hanno un ID diverso, ma che sono strutturati fondamentalmente allo stesso modo. Ciascun comando, però, ha logicamente una propria sintassi.
Ormai tutti questi messaggi di configurazione sono disponibili anche come --command da inviare.

ID messaggio:

• 0x20 – Timestamp dal telefono (--settime) [4 byte]
• 0x50 – Indicativo di chiamata (--setCALL) [1 byte di lunghezza – indicativo di chiamata]
• 0x55 – SSID Wi-Fi (--setSSID) e PWD (--setPWD) [1 byte – lunghezza SSID – SSID – 1 byte lunghezza PWD – PWD]
• 0x70 – Latitudine (--setLAT) [1 byte di lunghezza + 1 byte di ID messaggio + 4 byte di latenza + 1 byte di save_flag]
• 0x80 – Longitudine (--setLON) [1 byte di lunghezza + 1 byte di ID messaggio + 4 byte di lon + 1 byte di save_flag]
• 0x90 – Altitudine (--setALT) [1 byte di lunghezza + 1 byte di ID messaggio + 4 byte di alt + 1 byte di save_flag]
• 0x95 – Simboli APRS (--symID --symCD)
• 0xF0 – Salva impostazioni nella memoria Flash (--save)
• save_flag è 0x0A per salvare e 0x0B perché non si salva (da riga 365 e segg.) https://github.com/icssw-org/MeshCom-Firmware/blob/oe1kfr_434q/src/phone_commands.cpp)

[TODO] Seguiranno ulteriori informazioni …

Con il termine “hardware esterno” si intendono vari sensori e un’espansione I/O digitale.

La versione MT-FW 4.34v supporta diversi sensori. Al momento, non tutti sono descritti in modo adeguato. Per questo motivo cercherò di fornire qui una descrizione il più possibile dettagliata, con i singoli parametri relativi ai rispettivi sensori.

I principali dati ambientali comunemente rilevati sono:temperatura[°C],umidità relativa[%rH],pressione atmosferica[hPa]
Altri parametri sono:qualità dell'aria,_CO₂[ppm] e altri.

• Indirizzoin esadecimale
• /X= identificativo nel messaggio POS (V=2 ha la priorità su V=3)
• (*)= la temperatura serve alla compensazione interna ed è quindi leggermente superiore a quella ambientale reale.
• Collegamento MCU811WAK-GND oltre a quello I²C.

Attualmente è supportato ufficialmente solo un sensoreINA226(tensione [V] - corrente [A] - potenza [W]) nella versione da 20 A con_{RS = 2} mΩ[R002].

È supportato unMCP23017a 16 pin I/O suI²Ccon indirizzo 0x20.
I 16 pin I/O sono contrassegnati con A0..A7, B0..B7. Il controllo è possibile tramiteterminale,BLEeUDP(client web).

Comandi tramite terminale e app BLE:

• --io invia un pacchetto JSON tramite BLE
• --setio clear imposta tutti gli I/O su INPUT
• --setio {A0..A7,B0..B7} {in | out} imposta la funzione dell'IO selezionato su INPUT oppure OUTPUT
• --setout {A0..A7,B0..B7} {high | low} imposta l'IO selezionato su HIGH oppure LOW

©️ 11/7/2025 di OE3WAS – Wolfgang