Dopo quasi 5 anni dalla nascita (nel 2018…) della nostra attività di sperimentazione su LoRa ci siamo interrogati negli ultimi mesi sul punto a cui l’applicazione LoRa ed in particolare LoRa-APRS per usi radiomatoriali oggi si trova….

Ovviamente ci sono due aspetti da considerare:  il primo è lo stato nell’ambito esteso della comunità radiantistica, il secondo aspetto è lo stato della nostra attività di sperimentazione….

 

–  Stato dell’utilizzo di LoRa in ambito comunità radiantistica

Riguardo al primo aspetto quello che si può dire è che in questi 5 anni non è cambiato molto da un punto di vista tecnologico e per quanto riguarda il grosso dei radiomatori coinvolti…

L’uso di LoRa è sostanzialmente stato relegato a quello di fratello (.. o sorella..) minore di APRS che non è riuscito sostanzialmente nemmeno lontanamente a raggiungere i fasti del fratello maggiore… probabilmente i motivi sono svariati e non è questa la sede in cui cercare di analizzarli… a parte il fare alcune evidenti considerazioni…

In pratica il grosso delle implementazioni di nodi LoRa , basato sul classico HW cinese tipo TTGO T-Beam e similari,  ha utilizzato ancora chipset LoRa di prima generazione con parametri operativi conseguentemente congelati sui classici BW=125 Khz e frequenza di utilizzo simplex a 433.775 Khz….  la scarsità di banda trasmissiva che questo contesto fornisce ha di fatto nella quasi totalità dei casi costretto ad usare gli iGates installati, in modalità solo ricezione ( quindi senza usare la funzione di digipeater…)   e conseguentemente costringendo ad avere tutti gli iGates costantemente collegati ad internet …

Queste scelte ovviamente hanno costretto ad installare quasi sempre gli iGates presso le abitazioni degli OM e quindi in postazioni non sempre ottimali dal punto di vista della copertura radio, e con la necessità di avere a disposizione un collegamento  internet permanente.

Un altro effetto negativo di queste scelte, sempre legato alla scarsità di banda disponibile, è che i dispositivi tracker non sono stati in grado di aumentare le proprie prestazioni inserendo per es. nuove funzionalità quali ad es. supporto di sensoristica o funzionalità avanzate di tipo messaging testuale o vocale, se non in applicazioni molto particolari ( ad. es. vedi il progetto MESHASTIC…) e con un ambito di copertura fisica molto limitato se confrontato con le teoriche prestazioni offerte dal protocollo LoRa…

Con questa situazione de-facto è ovviamente anche venuto meno uno degli attributi base del protocollo APRS originario, ovvero quello di offrire un servizio di “awarness” ai radioamatori in grado di funzionare anche in condizioni di estrema emergenza, per es. in assenza di collegamenti di rete funzionanti o in situazioni di completa assenza di coperture di rete ( es. in zone montagnose, in situazioni di emergenza ambientale, etc.).

In effetti con le attuali limitazioni per poter usare LoRa come un sostituto di APRS e’ necessario avere a disposizione un altro terminale ( es. uno smartphone) collegato ad internet ed accedere ad uno dei classici portali tipo aprs.fi o similari: questo ovviamente implica che ci sia copertura di rete per es. di tipo cellulare 4G o similare… e che la rete cellulare funzioni correttamente…

Un ultimo punto che è poi da osservare,  è che il costo aggiuntivo richiesto per avere dei dispositivi LoRa da usare è andato progressivamente aumentando passando da valori di 20-25€ di qualche anno fa,  a valori che spesso sfiorano i 50-80€ per dispositivi di più recente introduzione sul mercato… e che puntano più che altro a prestazioni aggiuntive di tipo “estetico” piuttosto che di tipo “funzionale”…

Allo stato attuale è da osservare che esistono alcuni paesi ( Germania, Austria, Rep. Ceca) in cui il servizio LoRa come sopra delineato è stato abbastanza sviluppato , mentre per il resto dei paesi sia europei che extra-europei non si è evidenziata quasi nessuna diffusione…  verosmilmente quindi esiste anche un problema di “massa critica”:  infatti con gli attuali limiti prima accennati per trarre benefici dal servizio LoRa è necessario che ci sia una diffusa presenza di nodi iGate,  e che i terminali per osservare la propria posizione o lo stato delle stazioni in una certa zona siano collegati ad internet ed accedano ad un portale tipo aprs.fi o similare…

Esiste infine, in alcuni paesi, un problema “normativo”  che riguarda o la tipologia della tecnologia LoRa in quanto protocollo proprietario, o gli attributi tecnici del protocollo LoRa utilizzati ( ad. es. la larghezza di banda 125 Khz, o la frequenza scelta di 433.775 Mhz).

Riguardo al primo aspetto è opinione diffusa che, dopo gli ultimi sviluppi in ambito comunità OpenSource di una implementazione free del protocollo LoRa quasi completo ( usando il framework GNU Radio) , l’aspetto “proprietario” del protocollo non sia ormai più un concreto problema per l’uso da parte dei radiomatori.

Riguardo al secondo aspetto ovviamente molto dipende dai diversi paesi… allo stato, anche grazie forse alla limitata diffusione del servizio, non sono emerse contestazioni, a parte l’utilizzo con i satelliti radiomatoriali dove è stato evidenziato il problema; resta il fatto che in molti paesi la larghezza di banda 125 Khz pone LoRa in una situazione di evidente “stranezza”; in Italia per es. a parte l’uso TV ( sostanzialmente inutilizzato da tempo) la massima larghezza di banda che viene  citata per i servizi radiantistici si  attesta intorno ai 20 Khz.

 

–  Stato della nostra sperimentazione LoRa

La nostra iniziativa di sperimentazione LoRa nacque circa 5 anni orsono sulla base di un preciso obiettivo e su una precisa evidenza consequenziale:   era nata la seconda generazione di chipset LoRa che prometteva svariati miglioramenti rispetto alla prima generazione di chipset e che non esistevano circuiti acquistabili sul mercato a prezzi contenuti e  che consentissero di implementare economicamente dei dispositivi LoRa-APRS in grado di usare questi nuovi chips.

Ci proponemmo quindi di realizzare  una piattaforma HW modulare e una piattaforma SW anch’essa sufficientemente modulare e flessibile che ci permettessero di testare agevolmente e con  minima spesa diverse soluzioni sia di utilizzo di chips fisici, che di sviluppo di servizi o approdondimento di particolari aspetti funzionali del protocollo LoRa.

NON ci proponemmo quindi un obiettivo commerciale o di creazione di qualcosa di “competitivo” con i dispositivi esistenti….

Ad oggi siamo abbastanza soddisfatti delle scelte a suo tempo tempo fatte e pensiamo che abbia ancora senso proseguire nell’attività di sperimentazione soprattutto alla luce delle considerazioni e dello stato evidenziati nel paragrafo precedente.

Ovviamente proprio alla luce della situazione sopra evidenziata, ci siamo posti il problema, qualche mese fa, di come eventualmente ri-orientare la nostra sperimentazione per cercare semmai si valutare possibili nuove opzioni di utilizzo di LoRa per cercare di migliorare il quadro sopra delineato.

Ci siamo ovviamente  basati su quello che, timidamente, nel recente passato è emerso come possibili affinamenti della tecnica di utilizzo di LoRa come protocollo per implementare il servizo APRS, quali ad es. il tentativo di introdurre tecniche di compressione del payload APRS, o tecniche di utilizzo di diversi parametri di servizio per LoRa… come pure ovviamente sui risulati da noi direttamente collezionati nella nostra sperimentazione LoRa.

Quello che è emerso inesorabilmente è l’inadeguatezza delle attuali scelte di utilizzo di LoRa come sopra delineati…

Ovviamente standoci uno stato di fatto che vede comunque come mainstream queste scelte, è evidente che la principale sfida oggi è pensare a come consentire un percorso di migrazione verso altre modalità di utilizzo che preservi la base installata e che consenta una graduale migrazione senza “offendere” nessun utilizzatore o sviluppatore degli attuali dispositivi e sistemi LoRa radioamatoriali.

E’ evidente che per utilizzare nuove modalità quasi sicuramente ci si scontrerà con l’inadeguatezza HW di dispostivi  esistenti, in quanto  quasi al 100% basati su chipset LoRa di prima generazione privi di sufficienti attributi tecnici per supportare valori di larghezza di banda più contenuti ( principale motivazione storicamente parlando per scegliere quei valori..)…  quindi diventa mandatorio consentire comunque di utilizzare tali dispositivi almeno per l’utilizzo come “tracker”,  cercando quindi di concentrare l’attenzione soprattutto sul caso di utilizzo come iGate: questo peraltro è un discorso abbastanza concreto in quanto è evidenza che il rapporto numerico tra traker installati e iGates installati  vede certamente meno numerosi questi ultimi.

Sulla scorta di queste considerazioni abbiamo, da inizio della estate oramai trascorsa,  creato una nuova versione della nostra piattaforma HW e della piattaforma SW consequenziale, che stiamo ora iniziando a testare e che di seguito andiamo brevemente a delineare.

La chiave di tutto si basa sul concetto di “DualMode”:  uno degli attributi principali del protocollo LoRa è la possibilità di essere configurato in  modo tale da operare in numerose diverse modalità di trasmissione/ricezione che si distinguono per i parametri di larghezza di banda e di “Spreading Factor” e che consentono di utilizzare uno stesso canale radio in maniera concorrente da parte di diversi utilizzatori e senza che si evidenzino particolari “interferenze” grazie alla cosiddetta “ortogonalità” delle condizioni di uso del canale radio…

L’attributo di “ortogonalità”  vale se si scelgono opportunamente i parametri di utilizzo LoRa… per gli interessati mi piace rimandare ad un riferimento che approfondisce questo tema e che è disponibile su internet all’indirizzo http://www.sghoslya.com/p/lora_6.html

Questo attributo viene ampiamente utilizzato oramai da anni per es. nelle applicazioni IoT di LoRa per realizzare un servizio che sia in grado per es. di supportare sullo stesso canale anche 8 diversi utilizzatori che usino parametri diversi; sono anche stati sviluppati dei circuiti integrati ad hoc che però hanno in genere la limitazione di supportare solo LoRa associato ad un livello di rete di tipo LoRaWAN che non è usabile per le nostre applicazioni ( a causa principalmente dell’utilizzo della crittografia ).

Sfruttando quindi questa funzionalità è possibile che su un certo canale radio siano per esempio attivi indipendentemente sia utilizzatori che usando il modo tradizionale con BW=125 Khz , sia utilizzatori che utilizzino un altro modo LoRa ( che sia però ortogonale con il 125Khz)… il tutto senza che ci siano reciproche interferenze…

Cosa significhi questo è presto detto:

– per un tracker è abbastanza agevole implementare per es. una modalità operativa ( con soli cambi di tipo SW se l’HW è congruente)  in cui il dispositivo per es. trasmetta con BW=125Khz e riceva invece con una BW e/o uno SpredingFactor (SF) diversi… sfruttando il meccanismo di misurazione del drift di frequenza presente anche nei chips di prima generazione è facile “agganciare” la frequenza di ricezione al segnale del trasmettitore LoRa che si sta ricevendo diventando in questo modo possibile operare in ricezione anche con larghezze di banda inferiore ai classici 125Khz (che è uno dei grossi obiettivi ancora da raggiungere….).

– per un iGate tradizionale è analogamente agevole modificare o solo settare il SW esistente per consentirgli in operare in “split mode” ovvero ricevere per es.  con BW=125 Khz e trasmnettere con un diverso modo, per es. BW=31.25 Khz o SF più basso… il grosso vantaggio che questa semplice modifica consente di ottenere è che l’iGate può tranquillamente operare in modalità digipeater con il che viene riguadagnata la “awarness” del sistema… ovvero consentire ai potenziali ricevitori presenti nella zona di copertura di ricevere i segnali anche di altri dispositivi presenti in zona grazie alla funzione dell’igate…  Inoltre la presenza del segnale ritrasmessa dall’iGate consente ai potenziali trackers di “agganciarsi” alla frequenza dell’iGate riuscendo anche ad operare con larghezze di banda minori del 125Khz.

– una nuova possibilità che si propone è quella di realizzare ed utilizzare un iGate di tipo “Dual Mode”: con questa locuzione intendiamo riferirici ad un dispositivo in grado di ricevere simultaneamente su due modi diversi… ovviamente si possono pensare diverse modalità per realizzare questa funzione… per es. utilizzare una singola radio con una modalità di tipo “agile” ovvero in grado di ascoltare il canale per intervalli di tempo diversi usando modi diversi…  ma il sistema oltre che complesso da un punto di vista SW, presenta il grosso svantaggio che in realtà i due modi utilizzati sono ovviamente usati per frazioni di tempo ognuna inferiore di parecchio al 100% del tempo del canale…

– una ulteriore possibilità che si propone è quella di realizzare un dispositivo che sia equipaggiato con due diverse radio LoRa collegate o a due diverse antenne o ad una singola antenna tramite un opportuno splitter…

Questa ultima possibilità è quella che da una prima analisi sembrerebbe la soluzione migliore da approfondire con una fase di sperimentazione in campo…

L’utilizzo di due diversi moduli LoRa controllati da uno stesso processore è fattibile anche se richiede lo sviluppo di un HW ad hoc…

L’uso di due radio diverse in ricezione consente di ascoltare il canale radio usando simultaneamente due diverse modalità di lavoro LoRa in maniera completamente indipendente… ovviamente fintanto che le antenne sono collegate alle due radio…  questo implica che se una delle radio va in trasmissione necessariamente bisogna operare in modo da far sì che la radio che resterebbe in ricezione non venga distrutta dal segnale a radiofrequenza della radio attiva in trasmissione….

Sulla base della circuitistica disponibile per i chips LoRa di sola SECONDA GENERAZIONE  è possibile implementare una modalità operativa che consenta di evitare la distruzione della radio che non trasmette, ma a costo di interrompere il collegamento tra tale radio e l’antenna per la durata della trasmissione dell’altra radio….

Questa situazione quindi equivale a dire che la radio che opera anche in trasmissione avrà virtualmente una disponibilità del collegamento con l’antenna per il 100% del tempo di lavoro, mentre la radio che opera esclusivamente in ricezione si dovrà accontentare di “vedere” l’antenna per un tempo inferiore al 100%… e con lì’inconveniente che il segnale proveniente dall’antenna possa avere dei “buchi” a causa delle fasi di tarsmissione della radio principale….

Cosa possa significare questa situazione non è una cosa agevolmente stimabile senza approfondire le condizioni di utilizzo del canale radio… a seguire facciamo però alcune ipotesi con delle conseguenti considerazioni….

Assumiamo innanzitutto che la radio principale ( quella che opera sia in RX che in TX)  sia quella che opera con uno “Spreading factor” inferiore ( ad es. 5 o 6) e che la seconda radio , quella che opera solo in ricezione e che chiameremo secondaria nel seguito,  operi invece con uno “Spreading factor” più alto ( ad. es. 11 o 12)…. questo indipendentemente dalla BW utilizzata : questo significa che se per es. un pacchetto emesso da un tracker abbia un  “tempo on-air” di 2 secondi,  lo stesso pacchetto ripetuto dal iGate duretà una fazione di tempo molto più bassa a causa dell’uso di uno SF decisamente più basso…  questo significa che il ricevitore secondario avrà delle interruzioni del segnale di antenna per una frazione di tempo molto più bassa dei due secondi che è la durata di un pacchetto a 125Khz di BW….

Cosa succede al ricevitore secondario in questo caso ?   orbene ci aiuta il protocollo Lora… un attributo molto interessante del protocollo LoRa è l’uso del meccanismo di codifica del segnale radio con introduzione di ridondanza ( il cosiddetto “coding rate” ) e la presenza di un meccanismo di FCS ( ossia di controllo di parità sui segnali trasmessi trasmessi e ricevuti)  che insieme consentono in pratica di “tollerare” brevi interruzioni del segnale radio senza perdere contenuto informativo o nel caso peggiore scoprire che si è perso qualcosa senza comunque produrre ricezione di pacchetti errati. Ovviamente la probabilità di queste interruzioni dipendenrà dall’affollamento del canale radio ma è verosimile, grazie al fatto che usando BW 125 Khz  il canale radio che opera in modalità 125Khz ad alto SF  vada in sovraccarico molto rapidamente, per cui i pacchetti ritrasmessi dall’igate in modalità digipeater saranno comunque poco numerosi per cui le interruzioni del segnale sopra citato restano un frazione abbastanza limitata del tempo totale di canale.

Ovviamente avere la possibilità di operare la radio principale in modalità sia TX che RX su una certa modalità consente in implementare una connessione bidirezione ( di tipo esattamente simile a quello che avviene per il classico APRS)  tra la comunità degli iGates DM (DualMode) operanti in una certa zona consentendo quindi di propagare i pachetti APRS tra i diversi iGate presenti estendendo quindi la copertura radio anche in presenza di ostacoli quali ad es. case o montagne…

Inoltre non sarà più necessario che tutti gli iGate siano collegati ad internet in quanto basterà che uno solo degli iGates che si “vedono” in una certa zona sia collegato ad internet facendo da ripetitore per gli altri iGates presenti

Per completezza del discorso va ovviamente osservato che l’obiettivo di queste azioni è quello di spingere verso l’utilizzo di valori di BW il più bassi possibili   ( per cercare di rientare nei limiti normativi presenti in alcuni paesi)  e valori di SF  il più basso possibile ( per aumentare la banda disponibile e cercare di bilanciare la diminuzione prodotta dalla diminuzione della banda utilizzata)… ovviamente i valori ottimali saranno certamente un compromesso tra le varie esigenze…

Va inoltre per sottinteso che la scelta di nuovi valori di BW e SF comporterà anche la modifica del minimo valore di segnale discernibile  … e quindi della “sensibilità” del sistema: a tale proposito va osservato un fattore che spesso viene completamente tralasciato e che la nostra sperimentazione degli scorsi anni ha consentito di approfndire…. il reale valore del minimo segnale discernibile purtroppo non dipende solo dai parametri di setup del modo di lavoro LoRa, ma soprattutto dal livello di rumore radio locale nel punto di ricezione: in altri termini i valori forniti dai datasheet Semtech relativi ai chips forniscono valori teorici in assenza di rumore ambientale ( ovvero in presenza del solo fattore di rumore dello stadio di ingresso del ricevitore)…

Alla luce di questi argomenti ha quindi poca importanza cercare di usare valori che dal calcolatore Semtech forniscono valori eccellenti del minimo segnale discernibile, se poi si va ad installare il nodo in un punto in cui il rumore elettromagnetico locale è enorme….

Un ulteriore elemento da considerare è l’orografia ambientale: spesso è questo l’elemento limitante della copertura radio, indipendentemente dalla sensibilità del ricevitore…  basta farsi un giro in una zona appenninica o alpina per capire cosa intendo dire…

 

–  Modalità operativa Dual Mode

In pratica il modo di operazione di un nodo iGate DM sarà il seguente:

– il nodo ascolta sempre sia il canale principale che il canale secondario ( ad es. BW=125 Khz / SF=12 )

– il nodo effettua la ritrasmissione ( digipeater ) di tutti i pacchetti ricevuti con eventuali limitazioni di percorso ( stile APRS ) esclusivamente sul canale principale

– il nodo effettua la trasmissione verso APRS-IS ( se abilitata ) secondo le modalità classiche di APRS-IS applicando eventuali filtri in trasmissione; analogamente in ricezione.

– per l’interconnessione degli iGates si utilizza quindi solo il canale principale con modalità APRS tradizionale

Un nodo tracker riceverà sempre sul canale principale e potrà trasmettere o sul canale secondario ( modalità tradizionale) o sul canale principale.

Con questa modalità di operazione in pratica un tracker legacy che usa quindi le classiche impostazioni attuali funzionerà correttamente con i nodi iGate DM anche senza alcuna modifica .

Volendo migrare un tracker legacy per usare le nuove funzionalità basterà impostare sia la ricezione che la trasmissione  sui parametri del canale principale di LoRa DM.

Volendo migrare completamente un tracker legacy ad usare il canale principale bisognerà che sia supportata la funzione di agganciamento della frequenza di trasmissione al segnale LoRa ricevuto.

Come si può intuire l’introduzione di nodi LoRa DM  vuole essere un tentativo per stimolare gli utilizzatori a lasciare le classiche impostazioni di LoRa 125KHz in favore della migrazione a parametri LoRa meno invasivi da un punto di vista elettromagnetico ovvero meno fuori dai limiti normativi che almeno in Italia sono, lo ricordiamo, massimo 20Khz di larghezza di banda.

 

–  Conclusioni

Sulla base di queste considerazioni abbiamo quindi deciso di reindirizzare la nostra sperimentazione nella direzione ora delineata, allo scopo ovviamente di valutare in campo le performancies ottenibili in quanto come spiegato esistono svariati aspetti che vanno considerati e che solo una fase di sperimentazione in campo può aiutare a valutare.

Allo stato è già disponibile ed in fase di test un nuovo PCB che sarà in grado di operare in questa nuova modalità e che può montare moduli LoRa di diverso tipo allo scopo di fare valutazioni usando diversi tipi di moduli radio…

E’ stata anche creata una nuova versione di SW ( Vr. 5.x) che consente di supportare questa nuova modalità operativa sia per l’uso come iGate che come Tracker ; la nuova versione SW sarà in grado di operare sia sul nuovo HW Sarimesh DualMode, che sui vecchi dispositivi HW Sarimesh ( dotati ovviamente di singola radio).

Ovviamente l’intenzione sarebbe quella di poter fare una sperimentazione ampia… per cui si porrà il tema di avere quanti più partecipanti possibile alla sperimentazione… sarà quindi benvenuta la partecipazione di altri OM interessati a valutare questa modalità operativa…

E’ nostra intenzione rendere disponibile su Github tutte le informazioni, non appena disponibili in maniera stabile, per poter realizzare l’HW e per poter installare e  utilizzare il SW necessario.