Quando si installa un repeater MeshCore, spesso si tende a pensare che la cosa più importante sia soltanto la posizione: tetto alto, collina, traliccio, montagna o punto radio con grande visibilità. In realtà, nelle reti MeshCore più estese, l’altezza non è l’unico fattore determinante.
Un repeater molto alto, infatti, può ascoltare e raggiungere molti più nodi rispetto a un repeater locale. Questo è un grande vantaggio, ma può diventare anche un problema se il nodo ritrasmette troppo velocemente, rischiando di “parlare sopra” ad altri repeater più vicini o più bassi che non hanno ancora avuto il tempo di inoltrare correttamente il pacchetto.
MeshCore utilizza un meccanismo di propagazione controllata dei pacchetti: quando un repeater riceve un pacchetto valido, lo inoltra una sola volta, rispettando alcuni parametri temporali. Tutti i repeater coinvolti fanno la stessa cosa, generando una propagazione progressiva del messaggio all’interno della rete.
Per questo motivo, in una rete MeshCore ampia e con molti repeater, non è sempre opportuno usare gli stessi valori su tutti i nodi. Un piccolo repeater locale installato su un balcone o su un tetto può lavorare bene con tempi brevi. Un repeater regionale, collocato in posizione più favorevole, dovrebbe invece attendere leggermente di più. Un repeater dorsale, installato su una montagna o su un sito molto alto, dovrebbe essere ancora più “prudente”, lasciando prima lavorare i repeater più bassi.
Il ruolo del parametro txdelay
Il parametro più importante è txdelay. Questo valore regola la finestra casuale di attesa prima della ritrasmissione di un pacchetto flood. Lo scopo è evitare che più repeater trasmettano nello stesso istante, generando collisioni radio.
Una logica pratica può essere questa:
Tipo di repeater
Scenario Operativo
Valore Indicativo
Repeater locale
balcone, abitazione, tetto basso, copertura cittadina limitata
txdelay 0.5
Repeater regionale
palazzo alto, sito urbano elevato, copertura su più zone
txdelay 1.0
Repeater dorsale / backbone
montagna, traliccio, sito dominante, collegamento tra aree lontane
txdelay 2.0
Questi valori non devono essere considerati obbligatori, ma una base di partenza. Ogni rete va osservata sul campo, valutando ritardi, pacchetti persi, collisioni, percorsi anomali e comportamento reale dei nodi.
Il parametro rxdelay
Il parametro rxdelay introduce un ritardo di elaborazione legato alla qualità del segnale ricevuto. In pratica, i pacchetti ricevuti con segnale migliore possono essere processati prima, mentre quelli ricevuti con segnale più debole possono essere ritardati.
Questo può aiutare nelle reti dove più repeater ascoltano gli stessi pacchetti con qualità molto diverse. Anche in questo caso, non è un valore da aumentare a caso. Conviene lasciarlo a zero nelle reti semplici e provarlo solo quando ci sono molte sovrapposizioni, percorsi asimmetrici o collisioni sospette.
Rispetto del “tempo radio” af, dutycycle
Nelle versioni più recenti del firmware MeshCore, il vecchio parametro af è stato sostituito dal comando dutycycle. Questo parametro non cambia frequenza, larghezza di banda, spreading factor o coding rate, ma impone una gestione più prudente del tempo di trasmissione radio.
In area EU868 è sempre opportuno prestare attenzione al duty cycle previsto dalla normativa e dal piano radio utilizzato. Per una rete seria e stabile, tutti i repeater di una stessa area dovrebbero adottare criteri coerenti, evitando configurazioni casuali o troppo aggressive.
Il parametro flood.max
Il parametro flood.max definisce il numero massimo di hop che un messaggio flood può attraversare. In genere non è necessario modificarlo: il valore predefinito è normalmente sufficiente e protegge la rete da propagazioni incontrollate.
Ridurre troppo questo valore può limitare inutilmente la copertura. Conviene modificarlo solo in reti molto locali, sperimentali o volutamente circoscritte.
Regola generale
Un repeater MeshCore ben configurato non deve dominare la rete, ma collaborare con essa. I repeater locali devono poter ritrasmettere rapidamente i pacchetti nella propria zona. I repeater regionali devono intervenire con un leggero ritardo. I repeater dorsali, invece, devono agire con ancora più prudenza, proprio perché la loro copertura è molto più ampia.
La regola più importante è semplice: più un repeater è alto, potente e strategico, più deve essere rispettoso dei tempi della rete.
Comandi CLI consigliati
Prima di modificare i parametri, verificare sempre la configurazione attuale:
get txdelay
get direct.txdelay
get rxdelay
get dutycycle
get flood.max
get flood.max.advertProfilo 1 — Repeater locale
Adatto a balconi, tetti privati, postazioni cittadine o coperture limitate.
set txdelay 0.5
set direct.txdelay 0.2
set rxdelay 0
set flood.max 64
set flood.max.advert 8Profilo 2 — Repeater regionale
Adatto a palazzi alti, punti radio urbani o siti con copertura su più zone.
set txdelay 1.0
set direct.txdelay 0.2
set rxdelay 2
set flood.max 64
set flood.max.advert 8Profilo 3 — Repeater dorsale / backbone
Adatto a montagne, tralicci, postazioni dominanti o collegamenti tra reti distanti.
set txdelay 2.0
set direct.txdelay 0.2
set rxdelay 4
set flood.max 64
set flood.max.advert 8Duty cycle
Per firmware MeshCore recenti, indicativamente dalla versione 1.15.0 in poi, è preferibile usare:
get dutycycle
set dutycycle 10
Il valore va comunque scelto in base alla normativa, al canale radio utilizzato e al contesto operativo.
Sui firmware più vecchi, dove dutycycle non è disponibile, si può trovare ancora il parametro legacy:
get af
set af 9Nota finale
Questi valori non devono essere applicati indistintamente a tutti i nodi. La configurazione ideale dipende dalla posizione, dall’altezza, dalla copertura reale, dal numero di repeater vicini e dal comportamento osservato sul campo.
In caso di dubbi, è sempre meglio partire dai valori predefiniti, modificare un parametro alla volta e verificare gli effetti reali sulla rete.
Nota tecnica
nella documentazione MeshCore attuale, txdelay accetta valori da 0 a 2 e il default è 0.5; direct.txdelay ha default 0.2;rxdelay è indicato come sperimentale e accetta valori da 0 a 20. Inoltre af risulta deprecato dalla versione 1.15.0 in favore di dutycycle, mentre flood.max ha default 64 e flood.max.advert default 8
Perfecto
Claro y concreto
Muy útil
Gracias