LoRa Duty Cycle – Tempo massimo di trasmissione per un nodo

Ciclo di lavoro (LoRa Duty Cycle)

LoRa funziona bene perché è “parca”: invia poco, ma riesce a coprire distanze notevoli. In Europa però la banda 863–870 MHz (quella che spesso chiamiamo “868”) è condivisa da moltissimi dispositivi SRD: sensori, allarmi, telemetria, LoRaWAN e anche reti mesh. Per evitare che pochi nodi saturino lo spettro, la normativa tecnica ETSI impone limiti di occupazione dell’etere: il duty cycle, in italiano ciclo di lavoro.

In pratica il duty cycle è un “contatore” del tempo totale in trasmissione (time-on-air) in una finestra di osservazione tipica (spesso 1 ora). La cosa che conta davvero, lato utente: non è “quanti messaggi invii”, ma quanti secondi totali resti in TX.

Conversione immediata:

• 1% = 36 secondi/ora
• 0,1% = 3,6 secondi/ora
• 10% = 360 secondi/ora (6 minuti/ora)

Questo è il motivo per cui LoRa “non è Wi-Fi”: se lo usi come chat continua, non solo consumi batterie e congestioni la rete, ma rischi anche di uscire dai limiti di utilizzo.

Limiti in Europa (e quindi in Italia): non è “sempre 1%”

L’errore più comune è pensare che “in Europa è 1% e basta”. In realtà i limiti tipici dipendono dalla sotto-banda (sub-band) in cui trasmetti. Nella “EU868” esistono segmenti più restrittivi e segmenti più permissivi.

Cosa significa “in pratica”:

• se resti dentro una stessa sotto-banda, stai consumando lo stesso budget complessivo di airtime;
• “cambiare canale” è utile solo se ti sposti davvero su una sotto-banda diversa (quando il tuo dispositivo/firmware lo permette e quando è coerente con il bandplan scelto).

Esempio pratico

Supponiamo che il tuo nodo:

• invii un pacchetto LoRa ogni 10 minuti
• ogni pacchetto duri 1 secondo di time-on-air

In un’ora invia 6 pacchetti → 6 secondi/ora ✅ (ok nel 1%).

Se invece invia 1 pacchetto ogni minuto (sempre 1 secondo):

• 60 pacchetti/ora → 60 secondi/ora ❌ (fuori se sei nella sotto-banda da 1%).

La trappola del “messaggio piccolo”

Molti pensano: “tanto mando pochi byte, non consumo”. Ma se usi impostazioni lente (SF alto, BW stretta), anche un messaggio breve può “restare in aria” molto più del previsto. E il duty cycle si brucia senza accorgersene.

Time-on-Air: cosa lo aumenta davvero

Il duty cycle è fatto di secondi, quindi devi ragionare su cosa aumenta il time-on-air. Le leve principali sono queste:

Indicazione operativa: quando devi “rientrare nei limiti”, spesso la prima leva non è ridurre la frequenza dei messaggi, ma ridurre l’airtime per messaggio:

• SF più basso quando il link lo consente;
• payload più corto (anche solo togliendo testo inutile, campi ridondanti, telemetria troppo verbosa);
• meno ritrasmissioni (che in LoRa costano airtime vero, non “gratis”).

Un metodo semplice per non sbagliare

1. decidi quanto spesso vuoi inviare (es. ogni 5, 10, 15 minuti);
2. misura/stima il time-on-air con le tue impostazioni reali (SF/BW/CR/payload);
3. moltiplica e confronta col budget (36 s/ora, 3,6 s/ora, 360 s/ora a seconda della sotto-banda).

Cosa cambia con Meshtastic e MeshCore

Nelle reti mesh (Meshtastic, MeshCore) il duty cycle diventa più delicato perché un nodo può:

• trasmettere i propri messaggi;
• inoltrare (forward/relay) messaggi di altri nodi.

Quindi il consumo reale è:

TX tuoi + TX inoltrati

Questo è il motivo per cui in mesh la topologia “conta”: un nodo centrale non è solo un utente, è infrastruttura.

Perché molte reti mesh EU/Italia usano 869.525 MHz

Molte community mesh in Europa scelgono preset/frequenze attorno a 869.525 MHz perché ricadono nel segmento 869.4–869.65 MHz, comunemente associato al duty cycle più alto (10%). Tradotto: più margine di airtime = rete che “respira” meglio quando aumentano inoltri, beacon, ritrasmissioni e traffico generale.

Meshtastic, inoltre, applica un limite di attività per EU su base finestra mobile di 1 ora: quando il nodo raggiunge il limite, riduce/ferma le trasmissioni finché non rientra. In una mesh questo comporta un effetto importante: i nodi “centrali” possono diventare strozzature se consumano airtime con l’inoltro.

MeshCore e disciplina radio

In MeshCore (e in generale nelle mesh fatte bene) entra un concetto fondamentale: fairness. Se un nodo fa da ponte, deve “frenarsi” con pause e limiti proporzionati all’uso radio, altrimenti:

• si alza il tasso di collisione;
• aumentano le perdite;
• la rete diventa instabile;
• i nodi più lontani “spariscono” perché non trovano finestre libere per trasmettere.

Numeri pratici: come si brucia il budget (senza accorgersene)

I numeri dipendono da BW, CR, preambolo e payload, ma per un’idea rapida (ordine di grandezza su payload piccolo) si vedono spesso questi valori indicativi:

Esempio “nodo ponte” (mesh)

• 10 messaggi/ora tuoi
• 60 messaggi/ora inoltrati
• airtime medio ~0,19 s

Totale: 70 TX/ora → 70 × 0,19 ≈ 13,3 s/ora ✅ (dentro 1%)

Se la rete cresce e inoltri 250/ora:

• 260 × 0,19 ≈ 49,4 s/ora ❌ (fuori 1%)

Se aumenti SF, peggiori anche senza aumentare il numero di messaggi: ti basta raddoppiare l’airtime e hai raddoppiato anche il consumo di duty cycle.

Effetto “raffiche” e collisioni

In mesh succede spesso questo: evento → più nodi trasmettono quasi insieme → collisioni → ritrasmissioni → altro airtime bruciato. Per questo la gestione dei tempi (pianificazione e jitter) è parte della soluzione, non un dettaglio.

Soluzioni per gestire il limite di trasmissione

• Riduci airtime: SF più basso quando possibile, payload più corto, meno overhead, meno ritrasmissioni.
• Riduci traffico inutile: telemetria troppo frequente, beacon e ACK non necessari, messaggi “di chat” lunghi e ripetitivi.
• Compressione / riduzione messaggi: meno caratteri, meno campi, più essenziale (soprattutto in mesh).
• Routing intelligente: limiti di hop sensati, evita salti inutili, evita flooding “cieco”.
• Limiti di traffico per nodo: rate-limit per TX e per inoltro; i nodi ponte devono avere regole più strette.
• Gestione dei tempi: pianifica gli invii (telemetria a intervalli sensati) e usa ritardi randomizzati (jitter) per ridurre collisioni.
• Gateway cablato: un gateway con Ethernet/LTE può aggregare dati e ridurre l’airtime complessivo dei nodi “silenziosi” (che trasmettono poco e solo quando serve).
• Scegli bene la sotto-banda: tra 0,1% e 10% cambia tutto (quando applicabile).

LBT + AFA

In alcuni contesti SRD si incontra l’approccio LBT + AFA (Listen Before Talk + Adaptive Frequency Agility): ascolto prima di trasmettere e cambio adattivo di frequenza. È un accesso più “educato” rispetto al duty cycle fisso, ma richiede supporto reale di hardware/firmware e implementazione corretta.

Rischi dell’ignorare il duty cycle

• Conformità: rischi di operare oltre le condizioni previste per quella sotto-banda.
• Congestione: più airtime = più collisioni e pacchetti persi (specie in mesh).
• Autonomia: trasmettere spesso e “lungo” annulla il vantaggio principale di LoRa (batterie che durano mesi/anni solo se il traffico resta leggero).

Riferimenti e Fonti

Semtech / MachineQ — Sensor Design Conversion Guide (PDF): https://info.semtech.com/hubfs/machineq_Sensor-Design-Conversion-Guide.pdf (Semtech)

ETSI — EN 300 220-2: https://www.etsi.org/deliver/etsi_en/300200_300299/30022002/03.03.01_60/en_30022002v030301p.pdf (ETSI)

CEPT — ERC/REC 70-03 (pagina ufficiale documento): https://docdb.cept.org/document/845 (docdb.cept.org)

CEPT — ERC/REC 70-03 (PDF, edizione più recente in DocDB): https://docdb.cept.org/download/4831 (docdb.cept.org)

Meshtastic — Radio settings / Region settings: https://meshtastic.org/docs/overview/radio-settings/ (Meshtastic)

Meshtastic — LoRa configuration: https://meshtastic.org/docs/configuration/radio/lora/ (Meshtastic)

Sezione Mesh mhz.life