LoRa è potente proprio perché è limitata. Quando forzi quei limiti, diventa la scelta sbagliata.

NON usare LoRa quando serve tempo reale

  • Audio
  • Voce
  • Streaming
  • Chat “tipo WhatsApp”

Motivo tecnico: latenza + duty cycle.
LoRa è pensata per eventi, non per conversazioni.

NON usare LoRa quando servono molti dati

  • Log continui
  • Telemetria ad alta frequenza
  • Immagini
  • Video
  • File

Motivo tecnico: payload minimo + airtime lungo.
Più parli → più rompi la rete.

NON usare LoRa se i nodi sono in movimento continuo

  • Veicoli in città
  • Tracking in tempo reale
  • Oggetti che cambiano spesso gateway

Motivo tecnico: handover assente o rudimentale.
LoRa non è nata per la mobilità rapida.

NON usare LoRa se vuoi affidabilità garantita al 100%

  • Sistemi safety-critical
  • Comandi che devono arrivare
  • Attuatori immediati

Motivo tecnico: best effort.
LoRa privilegia l’autonomia, non la certezza.

NON usare LoRa se sei dipendente da Internet/IP

  • API continue
  • Backend cloud obbligatorio
  • Architetture microservizi

Motivo tecnico: LoRa non è IP nativa.
Ogni bridge aggiunge fragilità.

NON usare LoRa se puoi usare radio classica

  • Squadre sul campo
  • Emergenze operative
  • Coordinamento umano

Motivo tecnico:
per le persone → voce
per le macchine → LoRa

Confondere i due è un errore concettuale.

NON usare LoRa se stai inseguendo la moda

  • “È IoT quindi va bene”
  • “Così è più moderno”
  • “Lo usano tutti”

Motivo reale:
LoRa non perdona i progetti mal pensati.

La regola d’oro

Usa LoRa solo se:

  • il messaggio è breve
  • l’evento è raro
  • il nodo deve durare anni
  • la rete deve esistere anche senza Internet
  • puoi accettare che qualche pacchetto vada perso

Se anche una sola di queste condizioni non è vera → guarda altrove.

Sintesi brutale

LoRa non è:

  • una rete dati
  • una rete voce
  • una rete veloce
  • una rete “always on”

LoRa è:

una rete che resta in piedi quando tutto il resto cade

Ed è per questo che va usata solo quando serve davvero.

Nel Prepping Cittadino il concetto di infrastruttura minima non nasce dal desiderio di semplificare per ideologia, ma dalla necessità di ridurre l’esposizione al fallimento sistemico. Un’infrastruttura minima è ciò che resta quando tutto il superfluo viene rimosso e la funzione deve continuare a esistere anche in condizioni degradate. Non è una versione povera di un sistema complesso, ma un sistema progettato fin dall’inizio per funzionare con poco, per dipendere da pochi fattori e per essere compreso da chi lo usa.

La società contemporanea si regge su infrastrutture massime. Reti estese, altamente integrate, efficientissime in condizioni normali ma fragili quando una singola componente critica viene meno. Energia, connettività, logistica, servizi digitali: tutto è interdipendente. Il Prepping Cittadino non rifiuta questa realtà, ma la osserva con lucidità. Sa che più un sistema è performante, più è vulnerabile a cascata. L’infrastruttura minima nasce come risposta a questa vulnerabilità strutturale.

Un’infrastruttura minima ha tre caratteristiche fondamentali. È autonoma, nel senso che può funzionare senza coordinamento centrale. È leggibile, perché chi la utilizza può capire cosa sta succedendo e intervenire. Ed è degradabile, cioè non collassa di colpo ma perde progressivamente prestazioni restando comunque utilizzabile. Queste tre qualità la rendono adatta a contesti in cui lo stress, l’incertezza e l’errore umano sono la norma, non l’eccezione.

Nel Prepping Cittadino l’infrastruttura minima non serve solo “in emergenza”. Serve soprattutto prima e dopo. Prima, perché costringe a sviluppare competenze reali, non delegate a sistemi automatici. Dopo, perché permette di ripristinare una forma di coordinamento anche quando il ripristino completo delle infrastrutture maggiori è lento o parziale. È un ponte operativo tra il funzionamento ordinario e il collasso temporaneo.

La comunicazione è uno degli ambiti in cui questo concetto diventa più evidente. Le infrastrutture moderne di comunicazione sono potenti ma opache. L’utente non sa dove passa il messaggio, chi lo gestisce, quali priorità vengono applicate. L’infrastruttura minima, al contrario, rende visibile il processo. Sai quando trasmetti, sai quando ricevi, sai quando non funziona. Questa trasparenza non è un dettaglio tecnico, è una forma di controllo cognitivo che riduce il panico e migliora la qualità delle decisioni.

La CB si inserisce perfettamente in questo modello. Non perché sia l’unico strumento possibile, ma perché incarna il principio di infrastruttura minima in modo quasi didattico. Pochi elementi, nessuna mediazione invisibile, funzionamento comprensibile anche a chi non è un tecnico. Non garantisce risultati, ma garantisce un processo. Ed è il processo, nel Prepping Cittadino, a fare la differenza tra reazione istintiva e risposta consapevole.

Parlare di infrastruttura minima significa quindi spostare il focus dalla prestazione alla continuità. Non chiedersi “quanto è potente”, ma “quanto è indipendente”. Non “quanto è veloce”, ma “quanto è prevedibile”. In un mondo costruito sull’ottimizzazione estrema, il Prepping Cittadino recupera un principio antico e spesso dimenticato: quando tutto è instabile, ciò che conta davvero è ciò che resta in piedi.