Sperimentazione LoRa: qualche piccolo addon…
Grazie alla pandemia che ci ha costretto a privileggiare (????!!!!!) le attività casalinghe rispetto alle nostre normali abitudini di vita, questi ultimi due mesi hanno visto qualche ulteriore sviluppo sul fronte della sperimentazione LoRa che stiamo portando avanti…
Il primo punto su cui abbiamo operato è stato il “porting” del nostro SW su piattaforme HW diverse da quella da noi sviluppata come base di sperimentazione.
Il motivo principale di questa attività era di consentire di far girare il nostro SW sulle oramai tradizionali schedine tipo TTGO o Heltec disponibili su internet a prezzi contenuti e praticamente complete di quasi tutti i componenti necessari per un utilizzo “standard” della tecnologia LoRa/APRS.
L’operazione di porting ha comportato ovviamente una serie di modifiche ed adattamenti, peraltro abbastanza limitati, per poter utilizzare esattamente lo stesso SW su piattaforme HW mancanti in pratica di alcune componenti o dotate esclusivamente di alcune specifiche componenti.
In aggiunta si è dovuta introdurre una certa flessibilità per portare in conto le eventuali differenze presenti nelle diverse piattaforme HW spesso anche semplicemente di versione diversa ( a parità di nome commerciale).
Una ulteriore differenza che si è dovuta affrontare è la mancanza nella quasi totalità delle schedine commerciali di una memoria FRAM per conservare dati di configurazione o di logging: la soluzione implementata per la configurazione è di utilizzare la funzionalità di filesystem basata sulla soluzione LITTLEFS in modo da poter realizzare esattamente la stessa funzione della FRAM, sfruttando la flash presente; gli effetti di questa modifica sono abbastanza irelevanti in termini di “usura” della flash in quanto la configurazione verrà probabilmente cambiato molto raramente; un effetto secondario agiuntivo è un leggero rallentameno del tempo di reazione delle operazioni a livello di GUI.
Per le funzionalità di logging, pur essendo possibile utilizzare lo stesso tipo di soluzione, si è preferito NON implementare questa funzionalità (ovvero disabilitarla) sostanzialmente per due motivi: il primo è per evitare di introdurre un possibile meccanismo di “logoramento” della flash on board, e il secondo per evitare di ridurre ulteriormente lo spazio disponibile in flash per il SW, in modo da consentire di mantenere inalterate le funzionalità di caricamento del SW tramite la modalità OTA (Over The Air).
Sulla base di queste considerazioni è stato possibile portare esattamente lo stesso SW (come sorgenti) che gira sulla nostra piattaforma di sperimentazione anche sulle seguenti schede standard, ovviamente utilizzando “immagini” diverse e compilate per le diverse schedine.:
- TTGO T-Beam V1
- Heltec WiFi Lora 32
La figura seguente mostra due esemplari di piattaforme diverse su cui gira lo stesso SW.
Ovviamente a seconda dei casi ( per. es. schedina Heltec ) potranno mancare alcune funzioni quali ad es. il GPS. Inoltre la parte LoRa supportata sarà esclusivamente quella presente sulla schedina.
Nel portare il SW su queste nuove piattaforme ovviamente si presentano nuove opportunità legate alle specificità funzionali delle diverse piattaforme.
In particolare per le schedine TTGO esiste la possibilità di implementare un controllo molto sofisticato degli aspetti di consumo energetico, sfruttando le features disponibil nell’HW particolare.
Ovviamente nella attuale situazione del nostro SW queste funzionalità non sono supportate allo stato, essenzialmente per la loro stretta dipendenza da un HW particolare; ciò non toglie che volendo si potrebbe in futuro introdurre il loro supporto.
Una ulteriore funzione che è stata implementata allo scopo di consentire una agevole “migrazione” dell’applicazione su diverse piattaforme fisiche è stata la possibilità di “salvare” la configurazione operativa che è running su un certo esemplare e poter effettuare il “restore” oltre che sullo stesso esemplare anche su un esemplare diverso sia con la stessa piattaforma HW che con una piattaforma HW diversa.
Il formato usato per il save/restore della configurazione è di tipo testuale con codifica JSON e quindi facilmente analizzabile ed eventualmente customizzabile; questo consente di creare una configurazione “campione” da poi semmai leggermente customizzare prima di essere caricata su un certo esemplare fisico, semplificando eventuali attività di deploiment massivo.
Le figure seguenti riportano una sintesi delle shermate della interfaccia WEB relativa alle funzioni di save/restore della configurazione
Come fallout del porting del nostro SW sulle piattaforme indicate è quindi ora possibile agevolmente caricare una immagine precompilata su una di queste piattaforme senza necessità di installare tutto il SW di sviluppo arduino e senza una particolare esperienza nello sviluppo SW.
Per il primo caricamento dell’immagine SW compilata è possibile utilizzare un semplice tool disponibile sia in ambiente Windows che Linux e che consente di sfruttare la connessione USB presente.
Successivamente al primo caricamento e’ possibile aggiornare il SW del dispositivo via radio utilizzando la modalità OTA e quindi senza richiedere neanche la connessione USB ad un computer.
Il tool richiesto è reperibile su internet senza difficoltà, con numerosi tutorial che ne spiegano l’utilizzo; un esempio è reperibile al seguente URL: ESP32 Flash Download Tool
La figura seguente riporta una schermata di esempio di utilizzo di tale tool:
Allo scopo di generare una immagine appropriata ad una certa piattaforma è essenziale conoscere una serie di informazioni specifiche della versione di HW che si intende utilizzare.
Allo stato sono disponibili, per chi eventualmente ne fosse interessato, le immagini per le due piattaforme sopra indicate.
Reference:
Commenti
Sperimentazione LoRa: qualche piccolo addon… — Nessun commento