MeshCore vs Meshtastic: le differenze tecniche, senza tifo

In MeshCore gli advert e i messaggi di canale viaggiano sempre in flood: un repeater li ritrasmette a chiunque sia in ascolto, con un annuncio periodico predefinito ogni 12 ore (regolabile con set flood.advert.interval <ore>). I messaggi privati, invece, usano un meccanismo diverso: il primo invio raggiunge il destinatario in flood, ma la conferma di consegna che torna al mittente porta con sé l'elenco dei repeater attraversati. Da quel momento il mittente incorpora quel percorso nei pacchetti successivi, e solo i repeater che corrispondono al percorso lo ritrasmettono — è un routing diretto, non più un flood. Il limite interno del firmware è di 64 hop per pacchetto. Un punto centrale del disegno: i client MeshCore (companion) non ripetono mai il traffico altrui, solo repeater e room server lo fanno.

Meshtastic risolve il problema dei pacchetti duplicati con un meccanismo che il progetto stesso chiama "managed flooding": ogni nodo che riceve un pacchetto con un HopLimit diverso da zero prova a ritrasmetterlo, ma prima ascolta per un breve intervallo per verificare se un altro nodo lo ha già fatto — in tal caso non ritrasmette. L'intervallo di attesa dipende dal rapporto segnale/rumore (SNR) del pacchetto ricevuto: i nodi più lontani, con SNR più basso, tendono a ritrasmettere per primi, in modo che il messaggio si propaghi più lontano possibile con meno duplicati. Dalla versione 2.6, anche Meshtastic ha introdotto un meccanismo simile al routing diretto per i messaggi non broadcast: il flood iniziale stabilisce un nodo di inoltro successivo (next-hop) che i messaggi seguenti possono riutilizzare, con ritorno automatico al flood se quel percorso smette di rispondere. Il campo HopLimit nell'header dei pacchetti Meshtastic è codificato su soli 3 bit, quindi il suo valore massimo possibile è 7.

Le conseguenze pratiche seguono direttamente da qui. In MeshCore, una volta stabilito un percorso diretto, i messaggi tra due nodi che si scrivono spesso occupano meno airtime: solo i repeater sul percorso ritrasmettono, non l'intera rete. In Meshtastic, il backoff basato sull'SNR del "managed flooding" riduce le ritrasmissioni duplicate sui broadcast, e dalla v2.6 il next-hop routing evita di rifare un flood completo per ogni messaggio diretto una volta che un percorso è stabilito. In entrambi i casi l'obiettivo è lo stesso — ridurre la congestione e l'occupazione dello spettro condiviso — perseguito con architetture diverse: MeshCore separa nettamente client e infrastruttura di ripetizione, Meshtastic lascia che qualunque nodo partecipi al flooding gestito.

Sul piano dell'hardware, i due ecosistemi si sovrappongono molto: entrambi girano su board LoRa economiche e diffuse come Heltec V3, RAK4631/WisBlock o LilyGO T-Beam. Questo non significa che le reti siano compatibili tra loro: un nodo va flashato con il firmware dell'uno o dell'altro progetto, non con entrambi contemporaneamente, e le due mesh non si sentono anche sulla stessa frequenza — protocolli, formati dei pacchetti e chiavi di cifratura sono incompatibili. Puoi però tenere board diverse per reti diverse, ad esempio una Heltec V3 su MeshCore e un'altra board separata su Meshtastic, senza alcun conflitto tra le due installazioni.

Chi arriva da MeshCore e vuole approfondire i primi passi pratici può partire dalla guida a MeshCore passo passo, mentre chi ha già un nodo configurato ma non riesce a farlo comunicare con il resto della mesh italiana dovrebbe controllare il preset radio condiviso per l'Italia. Le domande più comuni su costi, portata e sicurezza sono raccolte nella pagina FAQ MeshCore.