Blog
Ne avevamo parlato di passaggio, come il firmware che supporta già i chip LoRa nuovi. Questa volta guardiamo dentro: come gira, cosa fa diversamente dal firmware ufficiale e quando ha senso provarlo.
Nell'articolo sull'hardware mesh abbiamo citato ZephCore due volte: ha già i driver per i chip LoRa di nuova generazione (LR1110 e LR2021) e una build per l'nRF54L15, che il firmware ufficiale non può supportare perché gira su un core Arduino solo per nRF52. Lo abbiamo poi rimesso nel percorso tra le risorse di awesome-meshcore, fra i firmware alternativi.
Il punto però non è solo l'hardware. ZephCore cambia il modo in cui il firmware passa il tempo. Il firmware ufficiale gira in un ciclo che controlla tutto, di continuo. ZephCore invece aspetta che succeda qualcosa.
Questo articolo si basa sul codice di ZephCore 1.18.0 e sul ramo principale di MeshCore di metà ottobre 2026.
ZephCore non è un fork del protocollo. Un nodo ZephCore parla con i nodi MeshCore normali, si accoppia con le stesse app e risponde agli stessi comandi della CLI. Il formato dei pacchetti in aria è bloccato a quello ufficiale: il documento di progetto lo chiama frozen, e ogni funzione in più deve restare locale al nodo.
Cambia quello che sta sotto. Al posto di Arduino c'è
Zephyr, un sistema operativo real-time per
microcontrollori della Linux Foundation. I driver radio, il Bluetooth, la
USB e il file system sono quelli di Zephyr. Il codice della mesh
(Dispatcher, Mesh, Packet, le identità) è invece copiato da MeshCore
quasi riga per riga: ogni modifica è marcata con un commento
// ZEPHCORE:, così un confronto con l'originale mostra solo le differenze
volute. Quando MeshCore esce con una versione nuova, ZephCore la importa.
La 1.18.0 di ZephCore contiene le modifiche della 1.18.0 ufficiale.
| MeshCore ufficiale | ZephCore | |
|---|---|---|
| Base | Arduino (core Adafruit su nRF52, Arduino-ESP32 su ESP32) | Zephyr RTOS |
| Ciclo principale | loop() chiamato di continuo |
thread che dorme finché arriva un evento |
| Radio | RadioLib, l'interrupt alza un flag | driver Zephyr, l'interrupt mette il pacchetto in coda e sveglia il thread |
| Ritardo prima di ritrasmettere | txdelay fisso |
finestra adattiva |
| Processori | nRF52, ESP32, RP2040, STM32 | nRF52, nRF54L, ESP32, EFR32MG24, STM32WL, Linux |
| Ruoli | companion, repeater, room server, KISS modem | gli stessi più l'observer (MQTT) |
| Chi lo scrive | il progetto MeshCore | una persona che dirige, con il codice scritto al 99% da AI |
Un programma Arduino ha due funzioni: setup(), che parte una volta, e
loop(), che viene chiamata all'infinito. Il repeater ufficiale fa così. A
ogni giro loop():
the_mesh.loop(), che a sua volta chiede alla radio se ha finito
di trasmettere, se ha ricevuto un pacchetto, se c'è qualcosa da spedire;powersaving è attivo e non c'è lavoro in sospeso, mette il
processore a dormire.La radio non chiama nessuno. Quando l'SX1262 riceve un pacchetto, alza il
pin DIO1 e l'interrupt imposta un flag (STATE_INT_READY nel wrapper di
RadioLib). Sarà il giro successivo del loop ad accorgersene. È un modello
detto polling: il programma chiede di continuo «c'è qualcosa?».
Il polling è semplice da leggere e da correggere, ed è il motivo per cui
MeshCore gira su schede tanto diverse. Ha due costi. Il primo è l'energia:
se powersaving è spento, che è il default, il processore non si ferma mai.
Il secondo è che ogni pezzo di codice nel loop rallenta tutti gli altri:
se uno si blocca, si blocca tutto.
Va detto per correttezza: con powersaving on su nRF52 anche il firmware
ufficiale dorme fra un evento e l'altro, e si sveglia con qualunque
interrupt. Ma al risveglio rifà comunque tutto il giro, per scoprire cosa
è successo.
In ZephCore la mesh vive in un solo thread, il thread principale di Zephyr.
Quel thread passa quasi tutto il tempo fermo in una chiamata,
k_event_wait(), che si sblocca solo quando qualcuno alza uno dei bit di
evento: pacchetto LoRa ricevuto, trasmissione finita, comando arrivato da
USB o Bluetooth, scadenza di manutenzione, azione del GPS.
Il percorso di un pacchetto ricevuto è questo:
MESH_EVENT_LORA_RX;Dispatcher del firmware ufficiale;Nessuno chiede di continuo «c'è qualcosa?». Quando non c'è niente, il processore non ha niente da eseguire e Zephyr lo mette a dormire da solo.
Il codice ha una regola esplicita: lo stato della mesh si tocca solo dal thread principale. Bluetooth, USB, GPS e driver radio girano in contesti separati e passano i dati attraverso code ed eventi. È lo stesso principio del firmware ufficiale, un solo flusso che possiede la mesh, ma senza il giro a vuoto.
Restava un pezzo di polling. Fino alla 1.16.7 il repeater ZephCore si svegliava comunque ogni 5 secondi, per fare la manutenzione: misurare il rumore di fondo, controllare il timer degli advert, rimettere a posto una configurazione radio temporanea.
Dalla 1.16.8 il repeater è guidato dalle scadenze. Prima di addormentarsi chiede «quando è il prossimo lavoro?» e programma un'unica sveglia per quel momento. Una sveglia di sicurezza ogni 60 secondi copre il caso di una scadenza dimenticata. Il documento di progetto riporta circa 0,07 risvegli al secondo per un repeater fermo, cioè uno ogni 14 secondi circa. Oggi il room server condivide lo stesso ciclo del repeater, e quindi le stesse sveglie.
Il companion tiene il timer da 5 secondi, ed è una scelta dichiarata: deve controllare cose che non hanno una scadenza, come l'avanzamento della lista contatti verso l'app o il Bluetooth che smette di farsi vedere.
Una nota sui consumi: in un repeater la parte grossa la fa la radio, sempre in ascolto, come avevamo scritto nell'articolo sull'hardware. Un processore che dorme meglio aiuta, ma non cambia l'ordine di grandezza. ZephCore ha anche una leva sulla radio: un ciclo di ascolto in cui il chip LoRa sonnecchia fra un controllo del preambolo e l'altro. È opzionale e va valutata scheda per scheda: dormire troppo vuol dire perdere pacchetti.
Un firmware senza loop non può più scrivere «aspetta che la radio finisca» come una riga dentro un ciclo. Ogni componente che ha un'attesa deve sapere in che fase si trova e cosa la fa passare alla fase dopo. In pratica, diventa una macchina a stati esplicita. In ZephCore ce ne sono diverse:
LoRaRadio): ricezione, ascolto prima di parlare,
trasmissione, ritorno in ricezione. Ogni passaggio è innescato da un
interrupt del chip, non da un controllo periodico.La regola che le tiene insieme è scritta nel progetto: ogni attesa ha un limite e un modo di uscirne. ZephCore non usa il watchdog hardware, il timer che riavvia il processore se il programma smette di rispondere. Ogni macchina a stati ha invece il proprio ripristino. Se il canale risulta occupato per più di 4 secondi, la radio viene resettata e rimessa in ricezione invece di trasmettere alla cieca. Se un chip LR1110 resta bloccato senza interrupt per 12 secondi, un controllo separato lo riconosce e lo riavvia.
È un approccio più faticoso da scrivere, ma che si può verificare. Il nucleo della mesh gira anche sul computer, dentro una batteria di test automatici con gli strumenti che trovano gli errori di memoria (ASan e UBSan). Su un loop che controlla l'hardware a ogni giro sarebbe più difficile.
Nell'articolo sul tempo d'aria condiviso abbiamo
visto come funziona il ritardo casuale prima di ritrasmettere un flood: la
finestra è fissa, 5 × txdelay × tempo in aria, e alzare txdelay sui
repeater in collina riduce le collisioni al prezzo di più latenza.
ZephCore sostituisce quel parametro con tre meccanismi:
La conseguenza pratica è importante: su ZephCore set txdelay,
set rxdelay e set direct.txdelay vengono accettati ma ignorati. Il
consiglio del nostro articolo precedente non si applica. L'unica leva è
set backoff.multiplier (default 0,2), che regola il rinvio per doppione;
get txdelay mostra lo stato del meccanismo adattivo.
Queste scelte non cambiano niente in aria: un nodo ZephCore in mezzo a nodi ufficiali è solo un nodo che sceglie il momento in modo diverso. Non abbiamo misure sul campo che dicano se una mesh mista funzioni meglio o peggio. Se ne hai, scrivici.
set meshtimesync on).set leds off li spegne tutti; si può scegliere
cosa segnala ciascuno, per esempio un lampeggio a ogni pacchetto
ricevuto: a colpo d'occhio si vede se un repeater sente qualcosa.Per chi usa un companion, ZephCore è soprattutto un modo di avere MeshCore su schede che il firmware ufficiale non supporta. Per chi gestisce un repeater, è un esperimento interessante su due fronti: un processore che dorme davvero quando non c'è traffico e un ritardo di ritrasmissione che si adatta da solo invece di essere regolato a mano.
Il modo giusto di provarlo è su un nodo che controlli da vicino, non sul repeater in cima alla collina che serve mezza provincia. E se lo provi, raccontaci com'è andata nel gruppo: stabilità, consumi, cosa senti in più o in meno.
docs/DESIGN.md
di ZephCore.zephcore/src/server_main_common.cpp.docs/ARCHITECTURE.md.txdelay ignorato:
ADR 0007.examples/simple_repeater/main.cpp;
gestione dell'interrupt radio:
src/helpers/radiolib/RadioLibWrappers.cpp;
sonno su nRF52:
src/helpers/NRF52Board.cpp.