Sono passati parecchi mesi dall’ultimo aggiornamento sulla nostra sperimentazione… mesi che sono andati a coincidere con un lungo … periodo di segregazione in casa gazie al virus con cui oramai stiamo imparando a convivere…

In questi mesi è continuata la sperimentazione di cui abbiamo parlato negli articoli precedenti,  seguendo le linee guida che ci eravamo date.

L’obiettivo è stato implementare una serie di nuove funzionalità SW nel campo della utilizzabilità dei dispositivi basati sul nostro progetto di base e sullo sviluppo di nuove versioni HW, sempre sulla falsariga gia utilizzata in precedenza, con l’obiettivo di rendere disponibili degli oggetti agevolmente costruibili anche da parte di persone inesperte , allo scopo di rendere agevole l’utilizzo della tecnologia LoRa-APRS ad una potenzialmente ampia platea di utilizzatori, in modo da poter realizzare una sperimentazione di più ampio respiro.

Nel seguito proveremo a descrivere il tutto in modo da evidenziare le potenzialità e stimolare la sperimentazione in campo da parte di OM interessati al tema.

 

A proposito di sperimentazione…

Vale la pena di fare innanzitutto una digressione su che cosa intendiamo per sperimentazione e perchè questo, a nostro avviso, passa per il rendere disponibile qualcosa di facilmente utilizzabile.

La tecnologia LoRa di cui ci vorremmo interessare è nata per scopi non certo di natura radioamatoriale e si sta imponendo nel campo dell’IoT come uno dei principali paletti tecnologici.

L’interesse verso questa tecnologia da parte dei radioamatori è derivata soprattutto dalle sue peculiarità che consentono di realizzare potenzialmente delle applicazioni innovative o in maniera innovativa.

Ne deriva che, diversamente dall’uso di LoRa in applicazioni IoT dove si mira soprattutto a servizi di interesse economico, per cui tutti i livelli inferiori a quelli alti ovvero dal 4-5 in su del modello OSI,  sono sostanzialmente da utilizzare a “scatola chiusa”, il radiomatore verosimilmente si interessa principalmente ai  livelli bassi dello schema OSI, ovvero quelli che gli altri usano a scatola chiusa…

Questo implica che il radiomatore verosimilmente vorrà “ravanare” dove gli altri non mettono neanche il naso: questo implica che perchè il radioamatore possa “giocare” a scoprire qualcosa è necessario che abbia a disposizione una “scatola aperta”:   è questo quello che cerca di realizzare la nostra sperimentazione: una scatola completamente aperta nella quale poter mettere le mani per eventualmente scoprire qualcosa!

E’ però evidente che nessuno pensa di re-inventare la ruota…. non avrebbe senso riscoprire cose già ben note… allora ha senso fare qualcosa in cui si possa raccogliere quanto già noto rendendolo disponibile per introdurre il proprio “tocco di classe” ...   è come rendere disponibile un meccano fatto di tanti blocchetti HW e SW dal cui assemblaggio poter generare agevolmente varianti interessanti.. in questo modo diventa possibile “aggiungere” qualcosa anzicchè semplicemente riscoprie la ruota….

Ovviamente data l’articolazione del discorso non è però detto che ognuno debba necessariamente conoscere tutti i dettagli di ogni blocchetto…  l’importante è avere la possibilità anche di aprire uno solo dei blocchetti…  o anche semplicemente vedere come usare un assemblaggio di blocchetti preconfezionato per farci cose nuove…

Tradotto in pratica questo è quello che noi abbiamo inteso fare: realizzare un ambiente HW/SW nel quale poter agevolmente mettere le mani per  introdurre solo le varianti che interessano…  per aggiungere qualcosa anzicchè riscoprire cose già ampiamente note…

Quindi abbiamo cercato di creare innanzitutto  una struttura HW modulare su cui poter introdurre agevolmente varianti,  associandola ad una struttura SW altrettanto modulare.

Come ambiente SW abbiamo scelto Arduino grazie alla sua notorietà principalmente come ambiente per “non professionisti del SW”, associando tale ambiente ad una architettuta HW basata sul processore ESP32 che rappresenta un eccezionale mix di potenza, economicità e flessibilità grazie soprattutto al fatto che il suo utlizzo si associa ad una architettura del SW di base basata sul sistema operativo FreeRTOS che presenta ottime caratteristiche di supporto per funzioni anche di tipo “real time”.

Quello che esce fuori da queste scelte è , a nostro parere, un insieme estremamente flessibile, aperto ed economico a disposizione di chi voglia “smanettare con LoRa”.

Come esempio di cosa intendiamo vale la pena di confrontare il nostro mini-tracker con il dispositivo TTGO T-Beam  che forse oggi rappresenta il circuito più diffuso tra chi vuole giocare con LoRa…  senza entrare in dettagli basta pensare che configurando il mini-tracker in modo che presenti le stesse features del T-Beam, il risultato è un dispositivo che costa meno…  forse incredibile ma vero!

La differenza non è però solo economica:  se nel T-Beam volessimo cambiare qualcosa di HW… purtroppo non è possibile, mentre nel caso del mini-tracker basta cambiare un modulino…

Queste ultime considerazioni sono state qualche mese fa il motivo per cui abbiamo pensato ad iniziare questo progetto ….  riuscire a sperimentare nuove cose senza dover aspettare che qualcun altro ci faccia trovare un nuovo oggetto già confezionato da comprare…. ovvero lo spirito del radiomatore che si diverte a costruire la radiolina con i transistori sciolti anzicchè comprarsi la radiolina giapponese già bella e fatta !

La differenza è che mentre 50 anni fa si giocava con i transistori per fare il ricevitore per le onde medie, oggi giochiamo con i circuiti VLSI e le funzioni SW per fare oggetti tecnologiamente anni luce dal ricevitore ad onde medie.

 

Aspetti di natura HW.

L’obiettivo è stato quello di creare due varianti HW del progetto di base con le seguenti applicazioni in mente:

• variante mini-Tracker
• variante Nodo Fisso DeskTop o da esterni

 

Le due varianti differiscono esclusivamente per l’aspetto HW fisico e per il tipo di moduli accessori equipaggiabili, mentre restano disponibili in entrambe le varianti tutte le possibilità di equipaggiamento in termini di tipologia di moduli radio, tipologia di moduli GPS e sensori.

Dal punto di vista SW analogamente le due varianti differiscono esclusivamente per le funzionalità SW legate ai moduli HW  equipaggiabili.

Il motivo per cui abbiamo deciso di creare due varianti è per consentire un agevole utilizzo mobile senza richiedere nulla di più di un piccolo contenitore di pochi cm3 di volume, alla stregua dei classici dispositivi LoRa  TTGO ampiamente utilizzati per varie applicazioni.

La versione completa (Nodo Fisso) è stata a sua volta ri-ingegnerizzata dal punto di vista meccanico per poterla ospitare agevolmente sia in un piccolo contenitore desktop che in un contenitore di tipo stagno per montaggio in esterno.

La seconda variante è quindi pensata per realizzare in maniera agevole un nodo LoRa da utilizzare in maniera fissa o addirittura da montare su di un palo in modo da ottimizzare le perdite di potenza sul cavo di antenna o per associarlo ad altri impianti quali ad es. un nodo della rete SARIMESH allo scopo di rendere disponibile un nodo di accesso Lora o un insieme di sensori ambientali.

Come varianti HW di equipaggiamento abbiamo la possibilità di montare: con (*) le funzioni equipaggiabli solo nella versione fissa :

• diversi tipi di moduli radio LoRa sia di prima che di seconda generazione a 433 Mhz e 2.4Ghz
• diversi tipi di moduli GPS (u-blox Neo 6 / 7 / 8 e ATMG332/6)
• supporto antenna GPS attiva esterna
• diversi tipi di display ( monocromatico 0.96″ o colori 1.14″ ) anche simultanei
• fino a tre sensori di temperatura, pressione, umidità e qualità dell’aria.
• memoria FRAM non volatile (storage configurazione e dati utilizzo)
• buzzer per segnalazioni acustiche + n. 2 LED programmabili
• pulsantino multifunzionale
• interfaccia di rete LAN 10/100Mbps (*)
• interfaccia seriale RS232 ( utilizzo come TNC KISS ) (*)
• supporto RTC (RealTimeClock)  (*)
• supporto OnBoardController Linux (*)
• alimentazione 5V o 12 V (*)
• case di plastica o per montaggio in scatola da esterni (*)

 

Il motivo per cui abbiamo introdotto il supporto di sensori è per consentire la realizzazione di nodi destinati a funzioni di monitoraggio ambientale e per poter sperimentare in futuro applicazioni anche di tipo più tradizionalmente IoT (Internet of Things).

Il supporto dell’interfacia seriale invece è stato previsto per poter utilizzazre il dispositivo esattamente come un tradizionale TNC interfacciabile ad un qualsiasi computer tramite interfaccia HW/SW di tipo KISS su RS232 in modo da poter sperimentare la tecnologia Lora ( in particolare in banda 2.4Ghz) per realizzare collegamenti punto-punto o punto-multipunto fino a circa 1Megabit/sec.

Il supporto di un On Board Controller Linux è stato previsto per poter realizzare all’interno dello stesso dispositivo fisico anche applicazioni di tipo standard come addon funzionali evitando di avere un ulteriore scatolo da equipaggiare in  un nodo.

Le figure seguenti riportano una serie di informazioni relative agli schematici e ai PCB realizzati:

Un’aspetto ulteriore che abbiamo curato è stato quello del contenitore in cui ospitare i dispositivi; si è scelto di utilizzare dei contenitori di plastica progettati ad hoc e realizzati tramite un processo di stampa 3D in modo da poter ospitare il tutto in maniera compatta e rendere agevolmente replicabile il tutto.

 

Aspetti di natura SW.

Sul fronte delle funzionalità SW è rimasta sostanzialmente inalterata tutta la parte di funzionalità descritte negli articoli precedenti, mentre sono state aggiunte numerose funzionalità tendenti a rendere agevolmente utilizzabili i dispositivi anche senza richiedere l’installazione di un ambiente di sviluppo SW, e quindi consentire a chi non è interessato agli aspetti di sviluppo SW di abbassare sensibilmente la soglia di ingresso per l’utilizzo della tecnologia LoRa.

Una particolare cura è stata dedicata alla possibilità di gestione completamente remota dei dispositivi in modo da consentirne una agevole remotizzazione ( es. associazione ad un nodo SARIMESH o in una postazione remota); in particolare è stata implementata la modalità di caricamento e aggiornamento SW OTA ( Over The Air) che consente eventualmente di sostituire il SW da remoto, e la modalità sia di gestione che di accesso in consolle per scopi di debug tramite interfaccia WEB o collegamento di rete internet.

Con le modalità di gestione implementate è possibile customizzare la quasi totalità dei parametri di funzionamento sia della parte radio LoRa  che della parte APRS e sensoristica (IoT); questo consente di sperimentare agevolmente  nuovi setup o funzionalità senza dover necessariamente disporre dell’ambiente di sviluppo SW per i processori presenti nei dispositivi (  ESP32 Arduino o Cortex-A7 Linux).

E’ stata introdotta on board per tutti i dispositivi una memoria FRAM dedicata a contenere sia i dati di configurazione estesa che dei dati di utilzzo in modo da poter implementare una funzionalità di tipo più squisitamente Tracker, ovvero poter raccogliere sul dispositivo dei dati di diversa natura da conservare localmente e poter successivamente scaricare offline (via WiFi): la funzione risulta molto utile per collezionare dati di copertura radio LoRa oppure per conservare localmente dati di tipo ambientale (es. misure dei sensori). La memoria FRAM è una memoria non volatile ( quindi mantiene i dati anche in assenza di alimentazione) caratterizzata da una durata operativa ( cicli di scrittura ) praticamente illimitata contrariamente alle tradizionali memorie flash o EEPROM.

 

Uno sguardo alle diverse versioni HW

La foto seguente rappresenta la versione minitracker priva del contenitore di plastica. Si può notare come sia stato organizzato allo scopo di realizzare la flessibilità desiderata.

Esiste un piccolo PCB base di circa 3.7×9.8 cm sul quale sono previsti gli alloggiamenti per il processore ESP32, per i due diplay ( simultanei o alternativi) montati verticalmente in modo da affacciarsi sul frontalino dello scatolino di plastica che contiene il tutto.

Sulla parte destra si nota un ulteriori piccolo PCB inserito sullo stampato principale e destinato a montare i diversi tipi di moduli LoRa equipaggiabili; sotto a questo stampato sono presenti gli zoccoletti su cui montare GPS e sensori.

 

La figura successiva mostra affiancati il mini-Tacker LoRa ed un classico modulo TTGO T-Beam LoRa acquistabile per circa 30€ su internet… come si può notare le dimensioni sono allincirca comparabili.

La foto successiva mostra lo stampato della versione fissa sottoequipaggiata; si può notare come sia realizzata con la stessa tecnica della versione mini e sia in grado di ospitare i medesimi modulini compresi i carrier che montano i moduli radio.

Per quanto riguarda i contenitori  sono stati progettati tramite un tool di progettazione 3D e i prototipi sono stati realizzati tramite stampa 3D in materiale plastico, per cui sono agevolmente riproducibili in maniera esatta e a costo molto contenuto.

 

Uno sguardo alle interfaccie di gestione.

Esistono diverse modalità di interazione con i dispositivi che abbiamo realizzato.

a) Display + pulsante + 2 LEDs sul frontalino del contenitore + buzzer

Servono sostanzialmente per l’utilizzo normale del dispositivo e mostrano alcuni dati significativi quali ad es. la posizione GPS, i dati di qualità del segnale LoRa ricevuto e i dati contenuti nei pacchetti Lora ricevuti.

Tramite il pulsantino è possibile inviare un pacchetto di beacon manualmente ( in aggiunta a quelli inviati periodicamente ), come pure è possibile riavviare il dispositivo.

Altre funzioni sono implementabili da SW come pure il significato dei due leds ( di default uno indica la regolarità di funzionamento e il secondo l’invio del beaccon ).

Il buzzer è programmato per emettere un bip quando viene ricevuto un pacchetto LoRa.

 

b) Interfaccia grafica di gestione tramite computer o smartphone, via WIFi

I dispositivi possiedono due modalità di connessione di rete WiFi:  tramite un Access Point integrato o tramite una connessione ad un proprio router WiFi disponibile nelle vicinanze.

Sfruttando la connessione WiFi è possibile con un computer o uno smartphone accedere ad una serie di schermate WEB che consentono di configurare le varie funzioni e modalità operative.

Le schermate disponibili, di cui di seguito vengono mostrati alcuni esempi, consentono per es. di impostare le modalità operative dei dispositivi, i parametri della parte radio, i parametri della parte APRS e delle interfacce IoT .

Il layout delle schermate è ottimizzato per l’uso con uno smartphone ma si adatta perfettamente anche all’uso con un PC. E’ possibile utilizzare un qualsiasi browser, anche se viene suggerito l’utilizzo di un derivato di firefox o chrome.

c) Interfaccia grafica per l’aggiornamento SW

E’ possibile effettuare l’aggiornamento SW dei dispositivi tramite connessione di rete via WiFi sia localmente che da remoto utilizzando una semplice interfaccia che consente di scegliere e caricare un “Load Module” contenente il SW del dispositivo.

Tutto il SW consiste in un singolo file con estensione .bin che viene rilasciato ad ogni aggiornamento e che può essere ricevuto tramite un qualsiasi sistema di trasmissione ( es. tramite whatsup o e-mail).

Una volta ricevuto il file e scaricato per es. sul proprio PC, si accede alla interfaccia di caricamento del SW, si seleziona il file da caricare e si avvia il caricamento; una barra mobile fornisce il progresso del caricamento. In pochi secondi il SW viene riprogrammato sul dispositivo ed attivato.

I dati di configurazione, conservati su una memoria FRAM, vengono preservati a cavallo di un aggiornamento SW.

d) Interfaccia di consolle per debug remoto tramite emulazione di terminale.

Sempre sfruttando la connessione WiFi offerta dal dispositivo è possibile accedere tramite un opportuno  programma di emulazione di terminale alla console interna dei dispositivi, in modo da accedere in tempo reale ad una serie di funzioni di verifica del funzionamento e di debug di eventuali situazioni di anomalia.

L’interfaccia utilizza il protocollo telnet per la connessione e rende disponibili una serie di comandi ad hoc per le attività di debug.

e) Interfaccia di  debug remoto tramite WEB App.

Esiste una apposita App scaricabile da internet sul proprio computer, tramite la quale è possibile accedere tramite un qualsiasi browser firefox o chrome based alla interfaccia di debug di cui al punto precedente in modo da poter controllare tale interfaccia tramite una finestra WEB; le funzionalità disponibili sono all’incirca le stesse della modalità di cui al punto d).

Grazie alle interfacce descritte è possibile accedere a tutta una serie di dati e informazioni anche di natura interna che consentono di implementare eventuali funzioni ad hoc in fase di sperimentazione.

 

A proposito dei tools utilizzati….

Un tema collaterale ma non trascurabile a nostro avviso è quello dei tools utilizzati.

In passato si parlava di matita, gomma e normografo per la progettazione,  saldatore e pinze per la costruzione e tester o oscilloscopio per il testing….

Oggi è abbastanza diverso…  purtroppo… ma fortunatamente…  volendo lavorare con la componentistica di oggi a poco servirebbero i tools di una volta 🙂

Una delle cose che abbiamo voluto “sperimentare”  con questo progettino è stata anche una completa catena di progettazione HW, sviluppo SW , progettazione e sviluppo meccanico e realizzazione completamente basata su tools opensource e liberamente recuperabili su internet a costo zero.

Analogamente per la costruzione dei prototipi abbiamo voluto utilizzare servizi e risorse disponibili su internet a costi bassissimi e alla portata di qualsiasi sperimentatore: volendo fare un classico paragone potremmo dire che il costo di una prototipazione equivale al costo di giusto qualche pacchetto di sigarette 🙂  …  con il vantaggio che ne guadagnano la salute e l’ambiente!

L‘obiettivo era dimostrare , se ce ne fosse stato bisogno, che chiunque può, avendone l’interesse e lo stimolo, avvicinarsi a questo tipo di realizzazioni praticamente senza alcuno sforzo economico, riuscendo comunque a ottenere risultati per nulla indecenti se paragonati a tools commerciali costosi e di difficile utilizzabilità.