Il networking mesh basato su LoRa ha guadagnato un notevole slancio negli ultimi anni. Che tu stia costruendo un sistema di comunicazione d'emergenza, distribuendo sensori IoT in una fattoria remota o coordinando un gruppo di escursionisti lontano dalla copertura cellulare, due protocolli dominano ora la conversazione: Meshtastic e MeshCore.
Condividono la stessa tecnologia radio di base — LoRa (radio a lunga distanza) — e possono funzionare su hardware identico. Ma sotto la superficie, fanno scelte architetturali fondamentalmente diverse che producono comportamenti molto diversi nel mondo reale. Questo articolo spiega esattamente quali sono queste differenze, con sufficiente profondità tecnica per prendere una decisione informata per la tua implementazione.
Cosa sono? Una panoramica rapida
Meshtastic è una piattaforma di comunicazione mesh decentralizzata, completamente open source e off-grid. Ogni nodo è uguale — qualsiasi dispositivo può inoltrare qualsiasi messaggio. È progettato per essere plug-and-play: carica il firmware, associa il telefono e sei connesso alla mesh. Il progetto è guidato dalla comunità con decine di migliaia di utenti attivi in tutto il mondo e un ampio ecosistema di hardware supportato.
MeshCore è un protocollo mesh LoRa più recente e leggero costruito attorno a una architettura di routing ibrida. Divide i dispositivi in ruoli distinti — dispositivi client che solo inviano e ricevono, ripetitori dedicati che gestiscono il routing, e server di stanza che memorizzano la cronologia dei messaggi. Questa struttura lo rende significativamente più efficiente su larga scala ed è progettata per implementazioni professionali.
Entrambi i protocolli sono open source. Entrambi funzionano su hardware radio LoRa. Entrambi supportano il networking mesh multi-hop. La divergenza fondamentale è nel modo in cui i messaggi viaggiano attraverso la rete.
La differenza tecnica fondamentale: architettura di routing
Questo è il concetto più importante da comprendere. Ogni differenza a valle — durata della batteria, scalabilità, resistenza alla congestione — deriva direttamente da questa singola decisione architetturale.
Meshtastic: Routing Flood Gestito
Meshtastic utilizza un approccio di flooding controllato. Quando un nodo trasmette un messaggio, lo invia a tutti i nodi nel raggio radio. Ogni nodo ricevente ritrasmette ai suoi vicini. Questo si propaga fino a quando ogni nodo nella rete ha ricevuto il messaggio o il limite di hop è esaurito.
Parametri chiave:
- Limite predefinito di hop: 3 hop
- Limite massimo di hop: 7 hop
- Deduplicazione: I nodi memorizzano i pacchetti visti di recente e ignorano i duplicati per prevenire loop infiniti
- Tutti i nodi inoltrano: Ogni dispositivo partecipa per impostazione predefinita all\'inoltro del traffico
Questo approccio è elegante nella sua semplicità — nessuna tabella di routing da mantenere, nessuna fase di scoperta del percorso, nessuna pianificazione dell\'infrastruttura richiesta. È anche altamente resiliente: se un nodo va offline, i messaggi si instradano automaticamente intorno al vuoto.
Il compromesso è l\'efficienza del canale. In una rete grande e densa, il flood genera enormi quantità di traffico radio ridondante. Ogni messaggio può innescare dozzine di ritrasmissioni a livello di rete. Questo fenomeno è talvolta chiamato "tempesta di broadcast", e diventa un collo di bottiglia significativo con l\'aumentare del numero di nodi. La documentazione di Meshtastic riconosce che le prestazioni iniziano a degradare intorno ai 100 nodi su un singolo canale a causa dei limiti di memoria hardware e della saturazione del canale.
MeshCore: Routing ibrido a sorgente
MeshCore adotta un approccio fondamentalmente diverso con il suo protocollo di routing ibrido. Combina una fase iniziale di flood per la scoperta del percorso con trasmissioni unicast dirette per tutte le comunicazioni successive.
Fase 1 — Scoperta del percorso (flood):
La prima volta che il Nodo A vuole raggiungere il Nodo B, effettua un flood nella rete. Quando il Nodo B riceve il messaggio, genera un acknowledgment di consegna contenente il percorso completo seguito dal messaggio — la sequenza ordinata degli indirizzi dei ripetitori. Questo acknowledgment torna con un flood al Nodo A.
Fase 2 — Trasmissione diretta (unicast):
Il Nodo A estrae il percorso dall\'acknowledgment e lo memorizza. Tutti i messaggi successivi al Nodo B inseriscono questo percorso direttamente nell\'intestazione del pacchetto. I ripetitori verificano se il loro indirizzo corrisponde al prossimo hop designato nell\'intestazione del percorso — se sì, inoltrano; altrimenti scartano completamente il pacchetto. Nessuna ritrasmissione inutile.
Parametri chiave:
- Conteggio massimo di hop: 64 hop
- Memorizzazione del percorso: I dispositivi client memorizzano le rotte conosciute per ogni contatto nella loro rubrica
- Recupero del percorso: Se un percorso si interrompe a causa del movimento di un nodo, il mittente rileva il fallimento dopo alcuni tentativi, cancella il percorso memorizzato e rilancia il flood per scoprire una nuova rotta
Il risultato è un utilizzo del canale drasticamente ridotto dopo la stretta di mano iniziale per la scoperta del percorso. In una rete MeshCore consolidata, la maggior parte del traffico è unicast diretto punto a punto — non trasmissioni broadcast. Questa architettura si scala molto oltre ciò che i sistemi basati su flood possono supportare praticamente.
Ruoli dei nodi: dove MeshCore cambia il modello
Una delle decisioni progettuali più significative di MeshCore è la separazione esplicita dei ruoli dei dispositivi. In Meshtastic, tutti i nodi sono funzionalmente equivalenti. In MeshCore, i ruoli sono distinti, intenzionali e influenzano tutto, dal consumo della batteria alla pianificazione della topologia di rete.
Companion Radio (Client)
Questo è il dispositivo portato dagli utenti finali, connesso via Bluetooth LE a un'app per smartphone. La scelta progettuale critica: i Companion Radio non fanno relay del traffico di default. Trasmettono e ricevono i propri messaggi ma non partecipano all'inoltro dei pacchetti per altri nodi.
Impatto sulla durata della batteria: Poiché il dispositivo non monitora continuamente il canale né ritrasmette, il ciclo di lavoro radio diminuisce significativamente. Questo è un vantaggio pratico sostanziale per dispositivi portatili usati per un'intera giornata di operazioni sul campo.
Nota: Esiste una modalità "client repeat" per scenari in cui non è disponibile un'infrastruttura di ripetitori — un fallback temporaneo, non la modalità operativa prevista.
Ripetitore
I ripetitori sono la spina dorsale di una rete MeshCore. Eseguendo firmware dedicato per ripetitori, sono tipicamente installati in posizioni fisse e elevate — cime di colline, tetti di edifici, torri radio — per massimizzare l'area di copertura. A differenza del modello puramente decentralizzato di Meshtastic, i ripetitori MeshCore sono l'infrastruttura di routing.
Poiché i ripetitori inoltrano pacchetti solo quando il loro indirizzo corrisponde al prossimo hop designato nell'intestazione del percorso incorporata, il loro processamento è altamente mirato. Gestiscono il vero lavoro di routing senza partecipare a tempeste di broadcast.
Room Server
Il Room Server è una caratteristica unica senza un equivalente diretto in Meshtastic. Funziona come un BBS (Bulletin Board System) — un archivio persistente di messaggi per canali di gruppo. Gli utenti che accendono i loro dispositivi ore dopo la trasmissione dei messaggi possono recuperare l'intero backlog, simile a un'app di chat con cronologia lato server.
Questo è particolarmente prezioso per team che operano con orari asincroni: team di ricerca e soccorso, operazioni di monitoraggio agricolo o reti di infrastrutture comunitarie dove i nodi non sono sempre online.
I Room Server possono opzionalmente essere configurati per agire come ripetitori, ma la documentazione MeshCore sconsiglia di combinare i ruoli in implementazioni critiche per le prestazioni.
Confronto affiancato
| Caratteristica | Meshtastic | MeshCore |
|---|---|---|
| Protocollo di Routing | Flood Gestito (Broadcast) | Routing Ibrido a Sorgente (Flood → Unicast Diretto) |
| Architettura di Rete | Completamente decentralizzato, tutti i nodi uguali | Gerarchico: client + ripetitori + room server |
| Massimo Numero di Salti | 7 (predefinito: 3) | 64 |
| Relay Client | Sì — tutti i nodi fanno relay di default | No — i client non fanno relay di default |
| Scalabilità | ~100 nodi prima del degrado del canale | Quasi illimitata (vincolata all'infrastruttura) |
| Efficienza del Canale | Inferiore su larga scala (sovraccarico flood) | Alta (unicast diretto dopo la scoperta del percorso) |
| Durata Batteria Portatile | Moderata (ciclo di lavoro relay) | Alta (nessun relay = minore attività radio) |
| Cronologia Messaggi Offline | Nessuno (solo in tempo reale) | Sì — tramite Room Server |
| GPS / Condivisione della Posizione | Integrata, una funzione primaria | Non è una funzione primaria |
| Crittografia (Broadcast) | AES-256-CTR chiave simmetrica per canale | Comunicazioni criptate |
| Crittografia (Messaggi Diretti) | PKC end-to-end (firmware v2.5.0+) | Sicuro per progettazione |
| Complessità di Configurazione | Molto bassa — plug and play | Moderata — richiede pianificazione del ruolo nella rete |
| Dimensione della Comunità | Molto grande (decine di migliaia) | In crescita, più piccolo ma attivo |
| Open Source | Completamente open source (MIT/GPL) | Core open source; alcuni elementi commerciali |
| Interoperabilità | ❌ Non compatibili — protocolli incompatibili | |
Crittografia e Sicurezza in Profondità
Entrambi i protocolli criptano le loro comunicazioni, ma la filosofia di implementazione differisce in modi importanti per le implementazioni professionali.
Meshtastic utilizza AES-256-CTR per le trasmissioni di canale. Ogni dispositivo che condivide un canale usa la stessa chiave simmetrica — se conosci la chiave, puoi decriptare tutto il traffico del canale. Per i messaggi diretti, Meshtastic ha introdotto la crittografia end-to-end PKC (Public Key Cryptography) nel firmware v2.5.0, il che significa che solo il destinatario previsto può decriptare un DM, anche se i pacchetti vengono intercettati via etere.
Note critiche sulla sicurezza operativa per Meshtastic:
- La chiave del canale predefinita è pubblicamente nota (
"AQ==") — qualsiasi implementazione in produzione deve cambiarla immediatamente - Le intestazioni dei pacchetti sono mai criptate — gli indirizzi dei nodi e il conteggio degli hop sono sempre visibili agli osservatori
- Non esiste perfect forward secrecy (PFS) — il traffico criptato catturato potrebbe essere decriptato retroattivamente se una chiave del canale viene compromessa in seguito
- I messaggi del canale non hanno verifica di integrità, il che significa che potrebbero teoricamente essere manipolati
Per una guida completa sulle migliori pratiche di sicurezza, consulta la nostra guida: Consigli per la Configurazione di Meshtastic — Impostazione del Canale e Sicurezza.
MeshCore è progettato con la sicurezza come requisito primario e non come aggiunta, in particolare per implementazioni tattiche e professionali. La roadmap della specifica v2 del protocollo include un miglioramento dell'hashing dei percorsi e della crittografia. Il suo focus sui casi d'uso professionali significa che il rafforzamento della sicurezza ha una priorità di sviluppo più alta rispetto al codice più orientato agli hobbisti di Meshtastic.
Hardware: Stesse Radio, Firmware Differente
Questo è uno dei punti più praticamente importanti: entrambi i protocolli funzionano su hardware LoRa ampiamente simile. La maggior parte delle schede di sviluppo basate sui chip Semtech SX1262 o SX1276 sono supportate da entrambi gli ecosistemi.
Hardware comunemente supportato da entrambi:
- Heltec WiFi LoRa 32 V3 — compatto, economico, OLED integrato, punto d'ingresso popolare
- LilyGo T-Beam / T3-S3 — scheda con GPS integrato, ampiamente usata nelle applicazioni di tracciamento Meshtastic
- RAK WisBlock — piattaforma modulare ideale per implementazioni personalizzate di sensori e gateway
- Serie Seeed Studio SenseCAP — hardware di grado industriale con supporto per alimentazione solare
La implicazione chiave: non sei vincolato a nessuno dei due ecosistemi. Lo stesso dispositivo fisico può eseguire entrambi i firmware. Se inizi con Meshtastic per imparare le basi del networking mesh e poi decidi che l'architettura di MeshCore si adatta meglio alla tua implementazione, è a un flash del firmware di distanza — nessun hardware nuovo richiesto.
Per la selezione dell'antenna e l'ottimizzazione della portata (applicabile a entrambi i protocolli), vedi:
Strumenti di flashing:
- Meshtastic: flasher.meshtastic.org
- MeshCore: flasher.meshcore.co.uk
Quale protocollo dovresti scegliere?
Nessun protocollo è universalmente superiore. Sono ottimizzati per scenari di implementazione realmente diversi. La risposta onesta è che la scelta giusta dipende interamente da cosa vuoi costruire.
Scegli Meshtastic se:
- Sei nuovo nel networking mesh LoRa e vuoi il percorso più rapido per un sistema funzionante
- Il tuo caso d'uso è mobile e temporaneo — gruppi di escursionismo, pattuglie sciistiche, gare su sentieri, campeggi, coordinamento eventi
- La condivisione della posizione GPS è un requisito fondamentale
- Vuoi la comunità più grande, il maggior numero di tutorial e l'ecosistema hardware più ampio
- La tua rete rimarrà relativamente piccola (meno di ~30 nodi) dove il sovraccarico da flooding è trascurabile
- Hai bisogno che tutto sia configurato tramite una app mobile raffinata con un minimo carico tecnico
La nostra serie completa di guide Meshtastic copre ogni aspetto di configurazione e funzionamento:
- Consigli per la configurazione di Meshtastic
- Guida all'uso dell'applicazione Android
- Panoramica dell'interfaccia Meshtastic
- Guida BaseUI di Meshtastic
- Configurazione del modulo di test della portata
- Panoramica del modulo informazioni vicini
- Preferenze utente e configurazione
Scegli MeshCore se:
- Stai implementando infrastruttura permanente e fissa — reti mesh comunitarie, agricoltura intelligente, IoT industriale, sistemi di gestione delle emergenze
- La scala della rete è importante — hai bisogno di comunicazioni affidabili per decine o centinaia di utenti simultanei
- Hai bisogno di archiviazione e recupero messaggi offline (funzionalità BBS del Room Server)
- L'efficienza del canale è critica e non puoi permetterti tempeste di broadcast che saturano la tua allocazione dello spettro LoRa
- La durata della batteria del dispositivo portatile è una priorità per operazioni sul campo prolungate
- Il tuo caso d'uso è professionale o tattico, richiedendo ruoli di comunicazione definiti e una topologia di rete strutturata
- Hai bisogno di copertura oltre 7 hop — MeshCore supporta percorsi fino a 64 hop di lunghezza
Una nota sull'interoperabilità
Vale la pena affermarlo esplicitamente: i dispositivi Meshtastic e MeshCore non possono comunicare tra loro. Usano formati di pacchetto incompatibili, protocolli di routing diversi e strutture di canale differenti. Un nodo Meshtastic che opera su 915 MHz non decodificherà il traffico MeshCore sulla stessa frequenza, e viceversa.
Se stai distribuendo in un ambiente dove altri stanno già usando un protocollo, devi impegnarti nello stesso per ottenere interoperabilità. Attualmente non esiste nessun ponte o gateway tra i due ecosistemi.
Tre domande per orientare la tua decisione
-
Mobile o fisso?
Se i tuoi nodi si muovono (persone che portano dispositivi), il modello flood di Meshtastic gestisce naturalmente i cambiamenti di topologia senza configurazione. Se i tuoi nodi sono infrastruttura fissa, la memorizzazione del percorso di MeshCore diventa un grande vantaggio in termini di efficienza. -
Zero-config o disposto a costruire infrastruttura?
Meshtastic può formare una rete funzionale in minuti senza pianificazione. MeshCore richiede il posizionamento intenzionale di ripetitori e l'assegnazione dei ruoli — più lavoro iniziale, prestazioni significativamente migliori su larga scala. -
Piccolo gruppo ad-hoc o grande comunità persistente?
Per gruppi sotto i ~30 nodi in distribuzione temporanea, la semplicità di Meshtastic prevale. Per reti più grandi o permanenti, l'efficienza di routing e le capacità del Room Server di MeshCore diventano vantaggi critici.
Conclusione
Meshtastic e MeshCore sono entrambi protocolli mesh LoRa tecnicamente validi, attivamente sviluppati e realmente utili. Non sono tanto concorrenti quanto soluzioni a problemi diversi.
Meshtastic è l'opzione democratizzata: massima accessibilità, configurazione minima, la comunità più ampia e la migliore esperienza mobile. È la scelta giusta quando hai bisogno di qualcosa che funzioni immediatamente e la tua rete rimane gestibile in dimensioni.
MeshCore è l'opzione ingegnerizzata: efficienza di routing superiore, chiara separazione dei ruoli, persistenza dei messaggi offline e un percorso verso una copertura a scala cittadina o regionale. Richiede più pianificazione ma offre prestazioni significativamente migliori in implementazioni grandi o professionali.
Poiché l'hardware è compatibile con entrambi, non sei mai completamente vincolato. Il percorso pratico per la maggior parte degli utenti: iniziare con Meshtastic per apprendere i fondamenti del mesh LoRa, valutare se l'architettura di MeshCore risolve problemi reali che stai incontrando e migrare se i guadagni in efficienza giustificano l'investimento nell'installazione.
Per un'introduzione completa a Meshtastic, consulta la nostra serie completa di guide Meshtastic per iniziare. Per MeshCore, inizia da docs.meshcore.io per comprendere l'architettura del ruolo del nodo prima di acquistare l'hardware.
Buon meshing.
