Nel nostro ultimo articolo sul tema LoRa (https://www.sarimesh.net/2020/01/30/sempre-a-proposito-di-lora/)    abbiamo discusso delle due possibili alternative di sperimentazione che si possono portare avanti.

A distanza di svariati mesi è possibile fare qualche considerazione a tale proposito:

• l’alternativa b) che si basava sul tentativo di utilizzare la banda 868Mhz si è dimostrata sostanzialmente inutilizzabile in Italia per un motivo nienteaffatto tecnico:  infatti approfondendo gli aspetti regolatori è emerso chiaramente che tale banda è di fatto difficilmente usabile senza pericolo di oneri e sanzioni molto salate economicamente in quanto tale banda è ancora sotto un vincolo di utilizzo militare e questo sembra che stia portando a richieste da parte delle amministrazioni statali di pagamento di forti oneri per ogni gateway installato.  Questo di fatto rende impraticabile, per un obiettivo amatoriale, tale banda, almeno fino a quando non sia definitivamente chiaro la gratuità di utilizzo di tale banda.
• Quella che resta sicuramente aperta e gratuita è la modalità di sperimentazione che avevamo indicato come a) e che peraltro consente di avere maggiori margini di azione per quanto riguarda la sperimentazione stessa, anche se accessibile solo ai radioamatori autorizzati con licenza.

 

Sulla base di queste considerazioni abbiamo quindi ripreso con maggiore convinzione e slancio il discorso inizialmente assunto come base di sperimentazione: ovvero partire dal porting del protocollo APRS tradizionale, che usava la modulazione AFSK in banda 144.800Mhz,  sostituendo il solo livello fisico AFSK con quello LoRa in banda 433 Mhz.

Il tema principale che abbiamo affrontato è stato ovviamente quello di sfruttare sperimentazioni già note, per evitare di “reinventare la ruota”:  allo stato esistono due implementazioni di “APRS over LoRa”:

• modalità “iot4pi”  utiizzata già da qualche tempo e basata sull’uso diretto del protocollo LoRa senza passare per nessun livello intermedio tipo AX25; per dettagli consultare i seguenti links:

           -    http://www.iot4pi.com/wp-content/uploads/2018/02/LoRa_IoT_Austria.pdf
           -    iot4pi.com/en/software/lora-aprs-gateway-en/    
           -    http://www.kh-gps.de/lora.htm

• modalità basata sull’utilizzo del formato  AX25 per incapsulare le informazioni da trasportare tramite APRS; per ulteriori dettagli consultare il seguente link:

           -   github.com/sh123/esp32_loraprs 

La prima modalità è stata la prima ad essere esplorata ed è leggermente più efficiente in termini di overhead come lunghezza di pacchetto, ma non è direttamente interfacciabile alla rete APRS/IS ovvero per es. ai portali tipo   http://aprs.fi    o  http://aprsdirect.com

La seconda modalità è molto più recente e mantiene il formato tradizionale dei pacchetti APRS per cui è direttamente interfacciabile a tutti i portali APRS/IS attualmente operativi.

Una ulteriore considerazione a vantaggio della soluzione 2 è la disponibilità di una implementazione completamente opensource e free, mentre per la prima soluzione le iniziali implementazioni erano di fatto closed source e disponibili solo su piattaforma Raspberry, mentre solo recentemente sono comparse alcune implementazioni open e su piattaforme anche meno costose del Raspeberry.

A vantaggio invece della soluzione 1) è il fatto che in alcuni paesi ( Austria e Germania) esiste già una certa base installata di nodi;  questo vantaggio in realtà è molto relativo in quanto LoRa è una tecnica di accesso per cui per es. in Italia solo un OM di passaggio  austriaco o tedesco  potrebbe godere di tale vantaggio….  e viceversa.

Un ultimo decisivo punto a vantaggio della soluzione 2) è che l’applicazione è molto ben strutturata dal punto di vista dell’ingegneria SW (e quindi agevolmente adattabile a nuove esienze) e consente con uno stesso codice di implementare con semplici settaggi ben tre funzionalità: end-node ( es. tracker) , iGate/Digipeater e APRS KISS client  bluetooth  compatibile con tutti i SW in grado di interfacciarsi con tale protocollo.

Alla luce di queste considerazioni la nostra scelta è caduta sulla soluzione 2) anche considerando il fatto che essa usa come piataforma HW di riferimento sia per la parte tracker che per la parte iGate/Digipeater il microcontrollore ESP32 da noi già scelto in precedenza per altre nostre sperimentazioni e caratterizzato da un costo irrisorio ( 3€ ) e da un insieme di funzionalità decisamente di primo piano.

Quindi la piattaforma HW di riferimento scelta  per la sperimentazione è stata appunto il microcontrollore ESP32 :   questa scelta appare ottimale anche per un altro aspetto: esistono già sul mercato una serie di schedine basate su tale processore e che integrano già on board una radio LoRa e addirittura un GPS. Il costo di questi schedini oscilla dai 10 € ai 30 € a seconda delle funzionalità incluse.

Nel nostro caso, essendo nostro obiettivo sperimentare e non semplicemente utilizzare qualcosa di già esistente abbiamo deciso di creare una nostra piattaforma HW su cui inserire tutta una serie di opzioni di sperimentazione, in primis la possibilità di sostituire la parte radio LoRa, la possibilità di usare chipset GPS diversi e di inserire dispositivi opzionali quali display, RTC (Real Time Clock) , interfacce di rete non solo WiFi ma anche Ethernet,  e sensori aggiuntivi.

La soluzione HW scelta è stata quella del “circuito stampato (PCB) carrier” su cui montare una serie di modulini opzionali; la soluzione si è dimostrata decisamente funzionale in quanto molto economica e, rispetto a implementazioni basate sull’uso di breadboard, decisamente più stabile ed affidabile ed usabile anche per prove concrete in campo.

Una prima versione del circuito stampato (PCB) realizzato e testato è illustrato nella figura seguente: le dimensioni totali del PCB sono 10×10 cm ed è alimentato a 12V DC.

Esso contiene oltre alla parte LoRa anche la possibilità di ospitare un completo ricetrasmettitore a 144.800Mhz con potenza di 1Watt in modo da poter implementare oltre alla modalità LoRa anche un tradizionale protocollo APRS/AFSK. Il PCB include inoltre la possibilità di  essere utilizzato come trasmettitore WSPR su bande decametriche.

Utilizzando questo PCB è stato possibile realizzare una prima serie di prove sia utilizzando APRS/AFSK che APRS/LoRa.

Sulle base dei primi positivi risultati abbiamo quindi deciso di avviare una seconda fase della piattaforma HW di test allo scopo di incorporare una serie di nuove opzioni che si sono rese disponibili recentemente soprattutto in tema di Chipset LoRa e di nuove metodologie di comunicazione quale il protocollo NPR (New Packet Radio).

Riguardo ai ChipSet LoRa, come già detto in altri articoli, il protocollo LoRa è basato su una specifica brevettata  della societa Semtech che ha implementato fin dall’inizio tale specifica in una serie di ChipSet ad elevata scala di integrazione (VLSI); tali chip sono resi disponibili a chiunque altro vendor voglia produrre dispositivi basati su tale tecnologia.

Una prima generazione è nota come SX127x  ed è quella oggi universalmente impiegata da quasi tutti i vendor di moduli LoRa e risale oramai a svariati anni fa come introduzione sul mercato. 

Recentemente ( due anni fa) Semtech ha creato una seconda generazione di chip LoRa che hanno incorporato una serie di miglioramenti  sia in termini funzionali che di qualità dell’implementazione; come risultato sono nati i chipset della serie SX126x per le frequenze sotto al Gigahertz e la serie SX128x per la banda dei 2.4 Ghz.

Questi nuovi chipset in particolare consentono di elevare ulteriormente il “link budget” ovvero la massima attenuazione di percorso radio consentito, grazie ad un aumento della potenza di trasmissione  ed un miglioramento della sensibilità del ricevitore grazie all’introduzione onchip di un amplificatore lineare del segnale ricevuto.

I nuovi chip includono inoltre una funzionalità CAD ( Channel Activity Detection) che consente di migliorare la coesistenza di una molteplicità di nodi in una stessa area e la possibilità di funzionare in modalità quarzata TCXO.

I chip di queste nuove generazioni non sono ancora utilizzati nei moduli complessi di cui si parlava prima ( es. quelli che integrano ESP32 + Lora ) ma sono solo disponibili come moduli ad hoc da integrare in dei circuiti ad hoc.

E’ questo il motivo per cui nella nostra sperimentazione abbiamo scelto la soluzione Carrier-PCB su cui poter montare tramite dei semplicissimi sub-carrier a piedinatura standard una varietà di diversi moduli radio.

il supporto di questi chip di seconda generazione ha anche avuto un impatto significativo sugli aspetti SW delle applicazioni LoRa based: infatti dal punto di vista del controllo i nuovi chipset hanno introdotto una nuova tipologia di interfaccia HW/SW che è completamente incompatibile con l’interfaccia di prima generazione; questo ha implicato che molti dei SW sviluppati per i chip di prima generazione sulle varie piattafrme, non possono agevolmente essere portati sulle piattaforme che utilizzanno chip di seconda generazione.

Quindi uno dei punti base della nostra sperimentazione di seconda fase è stato quello di scegliere/trovare una soluzione che consentisse di utilizzare simultaneamente chip di prima e seconda generazione senza dover apportare significative modifiche ai SW applicativi.

Come al solito prima di “reinventare la ruota” ci siamo guardati intorno ed abbiamo trovato una soluzione che definirei ottimale: si tratta della libreria “RadioLib”: questo modulo SW consente di pilotare in maniera sostanzialmente trasparente sia radio LoRa di prima che di seconda geneazione, oltre a fornire tutta una serie di ulteriori funzioni , mancanti in altre librerie similari,che possono tornare utili in fase sperimentale. Per un approfondimento sulla libreria Radiolib potete consultare il seguente link: http://github.com/jgromes/RadioLib  

Come curiosità mi piace ricordare che questa libreria, come pure la tecnologia LoRa, è stata scelta per implementare la parte di comunicazione  del progetto FOSSASAT di cui forse alcuni di voi hanno già sentito parlare: http://fossa.systems

Purtroppo le applicazioni che avevamo creato per la sperimentazone di prima fase erano basate su un diverso tipo di libreria ( LoRa Lib by Sandeep )  per cui si è posto, come prima cosa, il problema di “migrare” le nostre applicazioni su questa nuova libreria.

Questo lavoro è stato completato nel corso del mese di agosto, per cui oggi possiamo dire di avere già un primo livello di SW basato sulla libreria radiolib e che gira sulla piattaforma HW-PCB di fase 1 e che è in grado di girare immediatamente senza cambi sulla piattaforma PCB di fase 2 non appena sarà disponibile nel corso del mese di settembre.

La piattaforma HW di fase due  sarà esclusivamente in grado di supportare radio LoRa ed in particolare potrà montare due radio LoRa simultaneamente in modo da poter sperimentare funzionalità quali ad es. la connessione di un nodo remoto LoRa ad un backhaule ad es. Sarimesh utilizzando per es. un protocollo di tipo NPR ( New Packet Radio).

Riguardo alle applicazioni SW attualmente disponibili possiamo citare le seguenti:

• Implementazione trasmettitore APRS/AFSK basato su RTX integrato SA828 con 1watt di uscita a 144.800 Mhz
• Implementazione tracker  APRS/LoRa  basato su libreria RadioLib ( associato a chipset SX127x )
• implementazione iGate APRS/LoRa basato su libreria RadioLib in grado di operare come digipeater e come iGate verso APRS/IS
• implementazione sensore  IoT basato su libreria radioLib in grado di interfacciarsi con il protocollo MQTT verso piattaforme IoT cloud
• implementazione gateway IoT basato su libreria RadioLib  in grado di collegare sensori LoRa/MQTT verso piattaforma cloud ADAFRUIT-IO ( io.adafruit.com  )

 

Tutte le applicazioni su indicate sfruttano una base SW identica che consente di controllare i dispositivi tramite una semplice interfaccia WEB su Wifi  oltre a potersi interfacciare via USB ad un computer per controllo e caricamento del SW.

 

Per quanto riguarda qualche primo risultato in termini di copertura e funzionalità abbiamo innazitutto affrontato il tema della occupazione di banda a livello radio e della sensibilità, ovvero della possibilità di sfruttare il guadagno di processo intrinseco nel protocollo LoRa per avere una equivalente aumento del minimo segnale radio detezionabile.

I due parametri per come è strutturato il protocollo LoRa, sono strettamente relazionati; la tabella seguente riporta in forma tabellare tale relazione:

Le varie colonne si riferiscono ad un certo valore di larghezza di banda in Hz, mentre le varie righe sono relative al parametro SF Spreading Factor che fornisce una indicazione dell’effetto di sparpagliamento dello spettro radio che è responsabile del guadagno di processo del protocollo LoRa.

I valori riportati in ogni casella sono rispettivamente i valori di sensibilità ( ovvero minimo livello di segnale detezionabile in dbm equivalenti) e il bit rate equivalente di trasmissione in bit/sec.

Come noto in Italia ed in banda 433Mhz i massimi valori di banda trasmessa devono essere  inferiori ai 15-20Khz;  inoltre dalla tabella emerge che per avere un elevato valore di sensibilità è opportuno tenere bassa la banda occupata.

Ovviamente valori di larghezza di banda bassi e SF elevati producono un abbassamento significativo del bit rate e pongono problemi di stabilità di frequenza dei nodi che vogliono comunicare.

Nelle prove che abbiamo portato avanti abbiamo avuto modo di evidenziare che usando chipset LoRa di prima generazione (quindi senza TCXO) si riesce a realizzare un collegamento stabile in un range di temperature ambientali tipo circuito posto sulle bocchette dell’aria condizionata dell’auto a 20 °C / circuito sul cruscotto dell’auto a 40 °C, usando una banda di 15.6Khz sostanzialmente quindi alla stregua di una trasmissione in MBFM.

Con questi valori di banda e usando uno SF=9 abbiamo  realizzato una serie di prove di copertura nella nostra zona ( penisola sorrentina): a scopo di confronto tra valori ottenuti nel corso delle prove e valori prevedibli, abbiamo realizzato una simulazione con il tool RadioMobile impostato con i valori appropriati.

Di seguito riportiamo alcuni dati ottenuti.

La figura seguente è la simulazione della copertura radio ottenibile con una coppia di radio LoRa di prima generazione con frequenza 433Mhz, potenza emessa =100milliWatt, banda=15.6Khz, SpreadingFactor=9, antenna verticale bibanda 144/433 Mhz con 5db di guadagno lato iGate e verticale bibanda con 2-3 db di guadagno lato mobile.

Le figure seguenti, ottenute tramite registrazione dei pacchetti emessi a ritmo 30 sec dal tracker e raccolti sul portale APRS.FI tramite un iGate posto a casa dello scrivente,  sono relativi ad un esempio di “percorsi” effettuati in auto cercando di esplorare le zone marginali della copertura evidenziata dalla simulazione:

Nelle immagini sono stati evidenziati alcuni punti caratterizzati da valori misurati di segnale (RSSI) inferiori a -140dbm proprio in zone che sulla simulazioni appaiono marginali.  Dai risultati ottenuti appare una buona coerenza tra valori di intensità di segnale misurati e valori previsti in base al calcolo di copertura effettuato con Radio Mobile.

Inoltre i valori minimi misurati sono in ottimo accordo con quanto prevedibile dalla tabella sopra presentata in base ai valori di banda e di Spreading Factor usati.

La figura seguente, ottenuta con i due nodi tracker e iGate in casa a distanza di 4 metri, riporta i segnali come ricevuti tramite un ricevitore SDR:

Si può notare la larghezza di banda occupata e l’allineamento di frequenza tra le due tracce relative rispettivamente ad un pacchetto emesso da tracker e lo stesso pacchetto ripetuto dal iGate che opera come Digipeater.

Va osservato che la potenza emessa non è stata misurata, ma è molto probabile che sia inferiore ai 100 milliWatt teorici che i moduli possono generare.

Una ulteriore nota che è possibile fare è che la maggior parte delle prove fatte è consistita nello spostarsi negli abitati della zona e quindi tra palazzoni di 4-6 piani; quello che si è potuto osservare è che anche in tali condizioni , pur con valori di segnale molto bassi, si è riuscito a mantenere il collegamento.

Come prosieguo della sperimentazione prevediamo di migrare il tutto sul nuovo PCB-carrier di fase 2; questo consentirà di passare a sperimentare alcuni chip di seconda generazione sia in banda 433 Mhz che in banda 2.4 Ghz.

Un punto importante da approfondire sarà la riduzione del “Time On Air”, ovvero il tempo impiegato per trasmettere un pacchetto,  in modo da aumentare la potenzialità in termini di nodi simultanei supportabili in una certa zona di copertura.

Per quanto riguarda la banda 2.4 Ghz sarà interessante capire come LoRa si comporta in presenza di trasmissioni radio di tipo WiFi, come pure cosa si possa ottenere in un utilizzo a banda trasmessa maggiore , grazie alla disponibilità nei chip SX128x di una nuova modalità di trasmissione a velocità maggiore del LoRa tradizionale.

Dal punto di vista delle applicazioni SW un tema che potrà essere affrontato è quello del collegamento di più nodi LoRa in modalità MESH;  è un tema già studiato e su sui esistono delle implementazioni anche opensource che promettono interessanti novità e possibilità di sperimentazione.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Google Translation