Sono passati parecchi mesi dall’ultimo aggiornamento sulla nostra sperimentazione LoRa APRS…   sono stati mesi in cui,  grazie anche all’ingresso nel nostro gruppo di “pazzi sperimentatori” di un nuovo OM di lunga data, Giovanni IZ0CZW  che opera da quel di Monte San Biagio ( Terracina ) a ben 120 Km dalla Penisola Sorrentina dove finora abbiamo condotto le nostre prove,  abbiamo effettuato una serie di prove ed attività che hanno sostanzialmente riguardato da un lato la stabilizzazione e l’arricchimento del SW e della documentazione e dall’altro una serie di prove in campo.

Come abbiamo più volte affermato l’obiettivo della nostra sperimentazione era quello di mettere in grado dei radioamatori  non necessariamente superesperti di HW e SW  ma desiderosi di sperimentare  questa nuova tecnologia LoRa di  entrare sul tema con un approccio non semplicemente di “utilizzatori di un nuovo oggetto a scatola chiusa”   ma come “dei curiosi che vogliono vedere all’interno dell’oggetto fino al livello che più aggrada”,  con la possibilità di aggiungere eventualmente il “proprio tocco di classe” !

Il test del fuoco è stato il primo rilascio del nostro “ciarpame”  ad un OM che finora non aveva avuto nessun tipo di contatto con il gruppetto di persone che hanno pensato ed implementato il tutto:  il test ha riguardato non solo l’aspetto tecnico ma anche l’aspetto “auto-approviggionamento”  dei materiali , la  realizzazione HW di due dispositivi  e il setup e configurazione del SW.

Aspetti di setup HW / SW

L’aspetto “auto-aproviggionamento” dei materiali ha ovviamento richiesto i soliti due mesi di elapse-time per l’arrivo dei materiali dalla Cina, acquistati tramite i soliti portali e non ha avuto particolaari problemi; peraltro alla luce delle metodiche di sdoganamento in atto dall’inizio di luglio, questi tempi si stanno riducendo notevolmente per cui è presumibile che già attualmente si possano ridurre questi tempi a meno di un mese. Come risultato è ora  disponibile una lista utilizzabile per l’acquisto delle parti necessarie a realizzare dei dispositivi senza bisogno di particolari ricerche e con la quasi certezza di non sbagliare o tralasciare qualcosa. La lista è reperibile nella appendice del documento di cui al paragrafo seguente.

Un ulteriore risultato di questa fase è stato quello di aver creato uno strumento agevole per stimare il costo dei nostri dispositivi basato su elementi concreti e non solo su una stima approssimativa.

Gli unici componenti non acquistabili sui classici portali sono ovviamente i circuiti stampati necessari per i diversi oggetti; allo stato della sperimentazione,  e data la sua limitatezza, abbiamo pensato di evitare di fornire le informazioni per l’auto-approviggionamento di questi PCB direttamente a partire dalle informazioni tecniche di produzione per evitare di complicare inutilmente il processo di avvicinamento al discorso, preferendo offrire la possibilità di fornire degli esemplari finiti al puro costo di fabbricazione e spedizione.

La realizzazione dell’HW e il setup del SW e della relativa configurazione ha richiesto di creare un piccolo documento che riportasse le informazioni necessarie e sufficienti ad ottenere dei dispositivi funzionanti in breve tempo e senza richiedere  particolari informazioni aggiuntive.  Il documento è reperibile all’indirizzo seguente:  LoRa_Tracker_manual_vr1_5 

Il documento riporta nelle varie sezioni una serie di informazioni relative anche agli aspetti funzionali in modo da avvicinare l’utilizzatore alle varie funzioni disponibili cercando di lasciargli  la visibilità dei blocchi funzionali presenti nei vari dispositivi e la corrispondenza alle relative modalità di configurazione dei blocchi stessi.

Nell’appendice del documento è disponibile una lista di esempio per l’acquisto dei materiali necessari a realizzare i dispositivi.

Un interessante risultato di questa fase di sperimentazione ha riguardato anche il supporto remoto in fase di test dell’HW e del SW: sfruttando il sistema di collaborazione remoto “AnyDesk” disponibile gratuitamente su qualsiasi PC è stato possibile risolvere rapidamente la fase di test con delle  semplici sessioni di co-lavoro remoto:  questa modalità si è rivelata molto efficiente in quanto consente di fare del training-on-the job abbrevviando la “learning curve” degli strumenti di debug disponibili.

Il montaggio dei PCB non ha presentato particolari problemi essendo stata utilizzata una tecnica di tipo tradizionale “pin-in-hole” per il montaggio dei vari moduli sul PCB principale, con la presenza di un unico componente SMD peraltro facilmente saldabile essendo di dimensioni abbastanza grosse.

Per il primo caricamento del SW è stata scelta la modalità tramite collegamento USB tra  dispositivo e computer, e sfruttando il semplice strumento SW di download disponibile su internet ed ampiamente documentato;  in questo modo è possibile caricare il SW sul dispositivo target senza neanche minimamente installare sul proprio PC un qualsiasi strumento di sviluppo SW e quindi anche in questo modo abbreviando la “learning curve” necessaria ad ottenere il primo risultato di un dispositivo funzionante.

Anche questa scelta rappresenta un tentativo di evitare inizialmente inutili complicazioni solitamente legate al setup di un ambiente di sviluppo SW completo per la riproduzione di una buuld SW e per il relativo caricamento sul target;  è comunque nostra intenzione fornire prossimamente tutto il SW sorgente in modalità open-source, una volta che il progetto abbia raggiunto un minimo livello di stabilità.

La procedura di caricamento di una “immagine SW” sui vari dispositivi supportati è dettagliataente descritta nel documento citato in precedenza.

Una volta effettuato il primo caricamento del SW tramite il “download tool”  è possibile effettuare tutti gli aggiornamenti SW successivi usando la modalità OTA (Over-The-Air) disponibile tramite l’interfaccia di controllo WEB based disponibile una volta caricata la prima immagine SW sul dispositivo.  Anche questa procedura è dettagliatamente descritta nel documento citato.

Una menzione particolare va fatta per il supporto di situazioni di fault in fase di installazione della prima immagine:  è evidente che in fase di montaggio si possano fare degli errori o possano esserci dei problemi per cui tale operazione non va a buon fine;  ovviamente è necessario poter debuggare tali situazioni…  pur non disponendo di strumentazione di test e verifica HW ( ad es. un oscilloscopio…)…

Per rendere possibili tali attività si è usata una tecnica ampiamente utilizzata in ambito professionale per il debug di circuiti complessi basati su microprocessore: sono stati predisposti una serie di piccoli programmini SW , che chiamiamo “test segments”, utilizzabili in successione per verificare in maniera specifica e puntuale solo alcuni aspetti del circuito completo, consentendo quindi di effettuare l’individuazione ( ovvero il cosiddetto “pin-pointing”) dell’area affetta da fault.

Ovviamente per usare questi “test segments” diventa necessario installare un ambiente di sviluppo SW: l’ambiente supportato è l’Arduino IDE  ampiamente noto anche a sperimentatori non professionisti del SW.

I “test segments” sono concepiti e congegnati in modo da poter “girare” anche senza richiedere i sorgenti completi del SW operativo e hanno quindi solo una funzione di ausilio al debug HW, per cui sono sempre molto semplici e facilmente utilizzabili; un ulteriore beneficio di questo approccio è di consentire di acquisire una prima familiarizzazione con i vari blocchi HW presenti sulle piattaforme utilizzate, approfondendone semmai gli aspetti di utilizzabilità e modifica del SW di supporto relativo.

 

Arricchimenti funzionali

Durante le prove che abbiamo avuto modo di condurre in questi mesi è apparso evidente che era possibile introdurre qualche ulteriore piccola funzionalità a supporto della realizzazione, della comprensione e della documentazione dei risultati che si andavano ad ottenere.

Gli obiettivi delle prove erano diversi.

• prove di funzionalità a livello radio
• prove di funzionalità a livello di rete LoRa e APRS-IS
• usabilità della soluzione a livello operatore

 

Per la prima tipologia di prove è stato migliorato il sistema di raccolta e riporto dei dati di performance dei collegamenti a livello dei parametri di intensità dei segnali e  rapporto Segnale/Rumore in relazione alle condizioni operative del livello radio LoRa: è infatti evidente che la conoscenza di tali parametri è essenziale ad avere delle valutazioni oggettive delle prestazioni. E’ stato in particolare migliorato il sistema di riporto remoto ad un server ad hoc da parte degli iGate per tali dati e per la loro presentazione geolocalizzata; i dati così accumulati su questo server vengono storicizzati e sono utilizzabili per attività di documentazione o confronto nel corso della sperimentazione.

Per la seconda tipologia di funzionalità, che gira in particolare intorno alle funzioni di “digipeating” a livello APRS-LoRa ed APRS-IS, sono stati introdotti miglioramenti soprattutto nella documentazione in tempo reale di questa funzionalità ( opzionalmente attivabile) allo scopo di poter a colpo d’occhio ricostruire i passaggi che un pacchetto fa lungo la rete LoRa, ed associando ad ogni passaggio il riporto dei parametri di performance di cui sopra.

Si è reso inoltre necessario approfondire e trattare una serie di situazioni di utilizzo pratico relative alla politica di gestione del traffico da e verso la rete APRS-IS e tra la rete APRS-IS e la rete LoRa allo scopo di evitare e gestire situazioni di congestione e/o di malfunzionamenti legati alle tipologie di traffico gestite.  In questa fase abbiamo generato delle nostre “linee guida” relativamente alle regole di “accettazione del traffico” proveniente da internet tramite APRS-IS , nonchè delle regole di “tagging” di tali traffici allo scopo di seguirne i percorsi in rete LoRa.

Per la terza tipologia di funzionalità si è cercato di ampliare alcune pagine dell’interfaccia WEB grafica arricchendole di una serie di informazioni relative alle performances e al tracciamento dei percorsi dei pacchetti ricevuti, sia a livello di iGate che di tracker.

Le figure seguenti riportano degli esempi di schermate relative a queste funzioni.

Questa schermata riporta sinteticamente la situazione dell’ultimo pacchetto LoRa ricevuto sia a livello di iGate che di tracker e dello stato di funzionamento del nodo;  alcuni parametri interessantI:

• Last_RX_Pkt_Report:  riporta i dati del nodo che ha ricevuto il pacchetto con i valori di rssi e snr del segnale
• Last_RX_Pkt_payload: riporta il payload completo ricevuto dalla rete LoRa
• Last_RX_Path: riporta alcuni dati di percorso del pacchetto sulla rete LoRa; in particolare il primo nodo da cui il pacchetto è stato originato e la sua tipologia ( es. Beacon o FromInternet),  il primo nodo su cui il pacchetto è transitato ed i relativi parametri di performance, l’ultimo nodo che ha ricevuto lo spot ed i relativi pametri di performance.
• LoRa_lost_packets: pacchetti finora scartati in trasmissione da parte del nodo a causa di congestione sulla rete LoRa
• LoRa_CRC_errored_packets: pacchetti ricevuti dal nodo a livello LoRa e con errori di CRC ( verosimilmente dovuti a rumore, interferenze o collisioni a livello LoRa e non corretti dai sistemi di protezione LoRa )
• AprsIS_dropped_packets: pacchetti destinati ad APRS-IS e scartati a causa di congestione verso internet.
• LoRa_OnAirTime(msec): tempo medio di trasmissione richiesto dai pacchetti trasmessi dal nodo a livello LoRa.

 

Tutti questi dati servono a quantificare eventuali situazioni di anomalia a livello LoRa e possono essere utilizzati nel corso delle prove per ottimizzare eventualmente i parametri a livello LoRa o APRS.

Esempio di informazioni reperibli sul sito di raccolta statistiche relativamente ad un pacchetto LoRa: si nota nell’esempio un pacchetto originato dal nodo IQ8SO-10 e relativo ad uno spot  proveniente da una tratta di 120Km , generato da un nodo che usa la nostra tecnologia “iGate-LoRa” trasmesso con parametri LoRa larghezza di banda 31.25Khz ed  SF 7 ,  transitato inizialmente sul nodo I8FUC-10 che lo ha ricevuto con valori di rssi=-68dbm ed snr=11,75 db, successivamente ricevuto come ultimo nodo da IZ0CZW con un valore di rssi=-106,50 dbm  ed snr=-8,50db

 

Esempio di riporto su aprs.fi di uno spot LoRa:  si nota che sono recuperabili sostanzialmente gli stessi dati reperibili sul server delle statistiche anche se in formato sintetico.

 

Una prima sintesi delle prove effettuate

Con l’attivazione del nodo iGate IZ0CZW ne pressi di Terracina, grazie a Giovanni, ad inizio luglio è stato possibile realizzare una serie di prove non solo in ambito locale ma anche un primo accenno di rete LoRa in ambito geografico, intendendo con tale locuzione quello che tipicamente si intende in ambito APRS classico, ovvero una rete in cui le informazioni APRS transitano tra più nodi APRS anche abbastanza distanti in modo da estendere la rete APRS a livello radio oltre l’ambito di un singolo nodo APRS , sfruttando le funzioni di digipeating allo scopo di transitare su più nodi APRS: nel nostro caso tutti i nodi di cui si parla utilizzano esclusivamente la tecnologia LoRa a 433 Mhz  al posto della tradizionale tecnologia APRS  ( per es. a 144,800 Mhz  ).

I parametri radio utilizzati, per nostra scelta,  sono stati  i seguent:  larghezza di banda 31,25 Khz, spreading factor 7 e coding rate 7, con uso di un singolo canale in modalità ad accesso condiviso, ed utilizzando le funzionalità CAD ( Channel Activity Detection) fornite dai chips LoRa utilizzati. 

La componentistica LoRa utilizzata è stato un modulo LoRa di seconda generazione basata sul chipset Semtech SX1268 e con frequenza stabilizzata a TCXO, con potenza emessa di 1 Watt ed antenne tipo mobile per i tracker e verticali per gli iGates. Tale soluzione presenta rispetto ai chip LoRa di prima generazione significativi miglioramenti sia intermini funzionali che di sensibilità e potenza emessa; ul ulteriore vantagio è la disponibilità di una funzonalità di “Channel Activity Detection”  estesa a tutto il pacchetto LoRa e non solo al preambolo come nei chips di prima generazione.

Per tutte le prove si sono utilizzati dispositivi HW basati sulla nostra tecnologia;  sono state anche effettuate un limitato numero di prove utilizzando il nostro SW  installato su una classica piattaforma cinese tipo TTGO T-Beam V1  e che utilizza un chipset LoRa di prima generazione di tipo SX127X senza stabilizzazione di frequenza a TCXO e con potenza emessa di circa 100 milliwatt.

In tutte le prove effettuate in queste condizioni si è usato come criterio di verifica delle prestazioni la correlazione tra i risultati ottenuti in termini di valori di rssi e snr e i risultati di una simulazione effettuata con il tool “Radio Mobile” ampiamente utilizzato come strumento di dimensionamento delle tratte radio anche a livello di relazione con gli enti statali di verifica e controllo del traffico radioamatoriale.

Si è in genere ottenuto un ottimo livello di correlazione tra stime di copertura e valori rilevati/misurati; valori quantitativi saranno elaborati successivamente.

Molto interessante in questa fase è stata la ricezione di spots LoRa su distanze anche di circa 130Km in situazioni di buona propagazione a lvello VHF/UHF. La figura seguente si riferisce ad uno spot ricevuto e proveniente dal iGate di Sorrento Colli su una distanza di circa 130 Km.

 

Sono state effettuate anche un primo limitato numero di test utilizzando valori di impostazione del livello LoRa di tipo “estremo” con l’obiettivo di valutare l’utilizzabilità della tecnologia LoRa come indicatore dello stato della propagazione:  in particolare sono stati impostati i dispostivi iGate per operare con condizioni LoRa fino a larghezza di banda pari a 15,6Khz e SF = 11  ottenendo la ricezione di spots con livelli di rssi fino a -141,75 dbm e valori di snr fino a -17,75 db con un teorico relativo alle impostazioni loRa di circa -144 dbm come rssi minimo detezionabile !

Una cosa interessante che abbiamo anche notato è che spesso le tratte sono asimmetriche nel senso che un segnale ricevuto da un estremo del link non trova l’equivalente dall’altro estremo se i valori di SNR e rssi sono molto bassi…  questo farebbe pensare che da un lato ci sia un livello di rumore radio decisamente più alto che dall’altro;  in particolare dalle prove fatte si evidenzia che per es. il nodo di Monte San Biagio abbia un livello di rumore circa 10 db più basso del nodo di Sorrento Colli ( dove sono in realtà colocati svariati ponti a 144 e 432 Mhz ed altre apparecchiature sia in banda VHF/UHF che in banda 5 Ghz.

 

Posieguo delle attività

Come prosieguo delle attività di sperimentazione, oltre a continuare con altre prove sulla falsariga di quelle fatte finora,  ci si è prefisso l’obiettivo di affrontare il discorso della compatibilità e della integrazione tra la nostra tecnologa LoRa basata sulla realizzazione proposta su   https://github.com/sh123/esp32_loraprs  ,   con la tecnologia che chiameremo nel seguito OE_Style in uso attualmente soprattutto in Austria e Germania e che comincia a diffondersi anche in Italia.

Il tema è particolarmente interessante data la diffusione della tecnologia OE_Style e l’ottenimento di una compatibilità consentirebbe di estendere significativamente l’ambito di sperimentazione.

Un altro tema interessante è quello della standardizzazione a livello IARU del servizio LoRa che attualmente , in una prima proposta avanzata qualche tempo fa, prevede l’uso di un doppio canale di larghezza 125 + 125 Khz che quasi sicuramente nel contesto normativo italiano potrebbe avere serie difficoltà di accettazione da parte delle autorità e organizzazioni regolatorie. L’utilizzo della nostra proposta potrebbe consentire di ottenere livelli di prestazioni identici o  addirittura migliori con un significativo abbattimento della  banda richiesta a 31,25 Khz con un singolo canale radio.

Un ulteriore tema su cui lavorare è quello dell’utilizzo di LoRa come metodo per le verifiche di aperture di propagazione, sfruttando la tecnologia per un semplice utilizzo come beacon, utilizzando condizioni radio LoRa “estreme”.