Dopo una lunga gestazione siamo arrivati a mettere insieme una nuova versione del SW LoRa Sarimesh  che è ora disponibile per le persone interessate a testarla…

Questa versione è sostanzialmente non tanto diretta a chi è interessato a nuovissime funzionalità nella nicchia delle funzioni sperimentali, quali ad es. le funzioni DualRadio o SplitMode,  ma è diretta principalmente a chi, avendo testato le precedenti versioni, ha avuto modo di NON ritenere il nostro SW adeguato a essere usato, in quanto carente sul fronte delle tradizionali funzioni che altri SW ben noti e molto diffusi offrivano e che sono, verosimilmente, considerate funzioni indispensabili e prerequisito,  per poter poi semmai provare funzioni realmente nuove….

Una altra connotazione della nuova versione rispetto alle versioni precedenti è che sono state rimosse ( o meglio rese non visibili o utilizzabili da GUI ) alcune funzionalità precedentemente rese usabili anche da persone non interessate ad aspetti di sperimentazione HW/SW  e che si è scoperto essere fonte di cattive interpretazioni o uso improprio , se non addirittura considerate/percepite o definite come dei veri e propri fault del SW stesso.

L’introduzione di tutte queste nuove funzioni, associata alla volontà di non modificare la caratteristica base del nostro SW di essere una unica soluzione per tutti gli usi classici ( anzicchè versioni diverse per es.  per tracker e iGate), ha richiesto una serie di ottimizzazioni a livello di architettura del SW per consentire di usare la nuova versione anche sulle  schede che montano processori un poco oramai antiquati, quali ad es. il classico ESP32 o versioni minimal quali l’ESP32-C3.

A seguire presento innanzitutto una sintetica descrizione delle principali novità, per poi fornire il necessario per poter testare il nuovo SW sulle piattaforme standard e sui dispositivi Sarimesh customizzati.

 

Principali novità funzionali

La prima grossa novità è che la nuova versione di SW supporta senza bisogno di cambiare immagine SW sia l’interfacciamento esterno via WiFi, che via Ethernet;  precedentemente per poter utilizzare una scheda che montava SW per l’uso di Ethernet , anzicchè con interfacciamento Eth, con interfacciamento WiFi, era richiesto di caricare una nuova immagine SW… ora non è più necessario in quanto l’immagine SW contiene simultaneamente sia i moduli per l’uso come WiFi che i moduli per l’uso come Ethernet; in pratica è sufficiente modificare un semplice flag per passare dall’una all’altra modalità di utilizzo.

Questa funzione ovviamente ha senso solo per schede tipo la Maxi Sarimesh che siano in grado di supportare l’interfaccia fisica Ethernet.

Una seconda grossa modifica riguarda l’interfacciamento di rete WiFi:  è ora possibile definire un insieme di “profili di rete WiFi” caratterizzati da propri valori di SSID e password relativa, a cui si aggiungono una priorità ed un valore minimo di intensità di segnale per l’aggancio.

Con questa nuova organizzazione del sottositema WiFi diventa possibile predefinire un insieme di reti che un dispositivo conosce e che prenderà in considerazione come possibili “upstream” verso internet: in pratica il SW cercherà di agganciarsi, tra le reti wifi che scopre esistenti in una certa zona, esclusivamente ad una delle reti definite in un profilo, selezionando in caso di più reti note quella a priorità maggiore ed il cui livello di intensità di segnale sia superiore alla soglia indicata nel profilo per quella rete. E’ anche supportato l’uso di reti WiFi Hidden, per le quali viene data la possibilità di comunque associare alla rete hidden una identità oltre che una password ed una coppia priorità/segnale minimo come per le reti visibili. Quest aspetto è particolarmente delicato se associato all’uso di profili e non sempre supportato da altri SW.

In questo modo diventa possibile evitare di modificare il setup della parte WiFi quando per es. si migra da una stanza all’altra in casa o da un contesto ambientale ad un altro, riuscendo comunque a ristabilire una condizione di operatività dell’upstream WiFi; un esempio classico è quando si porta un tracker in tasca e si esce di casa per entrare in macchina… il tracker opererà adeguandosi all’ambiente… in particolare è possibile specificare, con un opportuno settaggio, come il dispositivo si debba comportare in caso di impossibilità di collegarsi ad una rete nota: è la famosa situazione di “standalone” che in passato ha dato dei problemi di interpretazione ad alcuni utilizzatori… ora è possibile settare come si vuole che il dispositivo si comporti in caso non riesca a trovare nessuna rete nota a cui agganciarsi; è possibile specificare se attivare un accesspoint locale del tipo ESP_32xxxx, e per quanto tempo,  se NON attivare mai l’accesspoint locale o se operare in maniera “automatica” ovvero accendere l’accesspoint per un certo tempo predefinito e poi spegnerlo.

 

E’ stata introdotta la funzione di “Messaging standard APRS”:  è reso disponibile un nuovo pannello sulla interfaccia GUI tramite cui è possibile ricevere e/o inviare messaggi standard aprs; viene supportato sia l’invio verso RF e verso APRS-IS che la ricezione sia dal lato RF che dal Lato APRS-IS; in quest’ultimo caso un nodo iGate in particolare opererà come gateway intelligente ripetendo verso la parte RF esclusivamente quei messagi entranti che arrivino quando l’utente destinatario è stato visto recentemente lato RF e usando la modalità di connessione LoRa da lui utilizzata recentemente .

A questo scopo il nodo iGate implementa una logica di tenuta di una tabella di “nodi visti” lato RF che viene aggiornata con i dati rilevanti in  modo da rimuovere dalla tabella nodi visti oltre un certo tempo nel passato; per ogni nodo visto vengono registrati il numero di pachetti visti e l’ultimo Modo LoRa con cui quel nodo è stato visto; questa funzione è essenziale per poter operare in una situazione di tipo MultiMode LoRa in quanto un utente potrebbe usare modi diversi nel tempo; quest funzionalità consente di inviare i messaggi entranti al destinatatrio usando il Modo LoRa più recentemente usato da quell’utente.

Viene supportata anche la funzione di “Acknoledge” per i messaggi trattati, cosa in genere non sempre implementata da altri SW LoRa.

La tavola dei “nodi visti”  ( seen Nodes) riporta, per come è pensata, non solo i nodi ricevuti “direttamente”  a livello radio ma anche quelli ricevuti a livello radio ma dopo aver attraversato altri iGate:   da questa evidenza è derivata l’implementazione di una una ulteriore funzione che sfrutta la medesima infrastruttura SW del messaging , ma per mostrare esclusivamente i nodi LoRa “Ricevuti direttamente via RF”; è questa una nuova tavola della GUI, che  chiamiamo DX Table,  e che riporta, ordinate per distanza descrescente, le stazioni più “lontane” ascoltate da un iGate nelle ultime 24 ore.

Grazie alla disponibilità aggiornata in tempo reale dei dati di DX, viene introdotta una ulteriore funzione per gli iGates, che è l’invio, come parte dei suoi  beacons di un dato di “DX massimo nelle ultime 24 ore” ricevuto dal nodo; tale messaggio viene inviato con una cadenza oraria modificabile da SW. Il dato di DX viene accessoriato con i dati di RSSI , SNR , drift di freq. e modo LoRa usati per la ricezione.

Le figure a fianco servono a dare una idea di questa funzionalità e delle features addizionali che ha consentito di introdurre.

 

Una altra nuova funzionalità introdotta è il supporto di due funzioni di “mitigazione” del traffico aprs e di protezione da attività fraudolente di tipo sicurezza: sono le funzioni di “black-list” che consente di marcare una stazione o un gruppo di stazioni  come da non trattare a livello di instradamento o ripetizione dei propri messaggi, e la funzione di “Blackout-areas”.

Questa ultima funzione è particolarmente orientata ad inibire l’emissione di beacons da parte di un tracker qualora la posizione attuale sia compresa in un insieme di aree circolari specificate tramite centro e raggio; questo consente di NON essere tracciati per es. in particolari zone a scopo di evitare congestione o per motivi di privacy.

Una ulteriore area ampiamente modificata riguarda la gestione di tutto il sottosisterma GPS: è stato profondamente rivista ed ampliata la modalità di gestione del dispositivo fisico GPS equipaggiato allo scopo di utilizzare simultaneamente più costellazioni di satelliti, integrandone le funzionalità; in particolare vengono tenute delle tabelle accessibili via GUI che mostrano in maniera sintetica lo stato del sottositema GNSS in termini di costellazioni ricevute, satelliti visti ed utilizzati e relativi parametri statistici che servono a dare una concreta visione del reale livello di qualità dei fix del sistema e dei valori di HDOP e densità spettrale che servono a capire concretamente come il sistema GNSS si sta comportando, evitando di doversi solo affidare al “naso” o alla simpatia per esprimere un giudizio relativamente a questa funzionalità, come purtroppo troppo spesso succede.

Vengono anche raccolti dati analitici di qualità attualmente non utilizzati, ma usabili in futuro per ulteriori approfondimenti di questa funzione.

Sempre in tema di GPS viene resa disponibile una ampia funzionalità di testing che consente di monitorare in console o tramite telnet i dettagli del processo di acquisizione dei fix; è anche resa disponibile una funzione di “GPS TestMode” tramite la quale è possibile collegare un dispositivo ad un PC su cui far girare uno dei tanti programmi di settaggio e gestione dei chips GPS disponibili dai produttori : attivando questa funzione viene deviata la seriale/USB del dispositivo sulla seriale del chip GPS consentendo quindi di accedere trasparentemente al chipset GPS presente sul dispositivo.

Nell’area del sottosistema LoRa è stata rivisitata completamente la  pagina di settaggio dello stesso e la concettualità di presentazione, allo scopo di rendere più chiara la tematica multimodo LoRa che si intende utilizzare: purtroppo questa è una area in cui molti inciampano con interpretazioni spesso fantasiose o inconsistenti;  in pratica  il sottosistema LoRa che il nostro SW  intende supportare si cala su una realtà fisica dell’HW che può essere abbastanza diversa per i diversi casi possibili.  In particolare nel caso di schede a singola radio o a doppia radio è abbastanza diverso il modo di mappare i Modi LoRa che si vogliono utilizzare sulle radio LoRa fisicamente presenti sulla scheda.

 

Abbiamo allora pensato di schematizzare in maniera chiara innanzitutto la parte HW: in pratica su tutte le schede esisterà una ed una sola radio che potrà trasmettere  indipendentemente dal modo LoRa utilizzato; questa radio viene indicata dome Device 0; per le schede a doppia radio esisterà un secondo modulo LoRa che indicheremo con il nome Device 1 e che opererà esclusivamente in ricezione indipendentemente dal device 0 che verrà usato sia in ricezione che in trasmissione.

 

A questo schema HW viene vovrapposto un secondo schema che indichiamo come “Modi LoRa” e che limitiamo, allo stato, a soli due  profili: questi due profili definiranno analiticamente per i due Modi LoRa quali valori di frequenza, BW, SF, preambol-length da utilizzare. I due modi vengono individuati come LS (Low Speed) e HS (HighSpeed) per distinguere il bitrate disponibile per i due modi; i valori di default di SF per questi due Modi sono  12 per il LS e 7 per il HS, il tutto customizzabile liberamente tramite la schermata LoRa.

 

Fatta questa schematizzazione diventa agevole definire dei “Modi di operazione”  per il sottosistema LoRa, indipendentemente dal numero di radio LoRa presente; in particolare:

* modo Legacy : si utilizza esclusivamente una singola radio in ogni caso, operando in modo LS sia in RX che in TX

* modo HighSpeed : si utilizzza ancora una singola radio in ogni caso, operando però nel modo HS sia in RX che in TX

* SplitMode : si riferisce all’uso di una singola radio in modalità “agile” ovvero potendo utilizzare in RX/TX entrambi i modi a seconda del voluto

* DualRadio: è il caso di una scheda a doppia radio LoRa in cui si utilizza il dev 0 in modo “agile” RX/TX in modo LS/HS come voluto, mentre il Dev 1 viene usato sempre e comunque in sola ricezione nel modo LS.

Sulla base di questa schematizzazione dovrebbe essere più agevole intuire anche ad un primo livello di analisi come sia possibile usare i due modi e le due radio con diverse strategie: questo è il tema centrale della nostra sperimentazione come qualcuno tra voi ricorderà.

E’ importante osservare che esclusivamente nel Mode DualRadio un dispositivo opera ascoltanso simultaneamente i due modi, mentre in tutti gli altri modi un dispositivo eascolterò sull’uno o sull’altro modo in ogni istante, per cui diventa essenziale definire una “politica” di utilizzo dei due modi di operazione.

Come conseguenza di questa nuova schematizzazione la schermata di setup della parte LoRa si semplifica notevolmente e si riduce semplicemente all’elencazione in dettaglio dei parametri precisi che definiscono i due modi LS e HS in uso; mentre il selettore alla sommità della pagina specifica il tipo di Modo Operativo da usare per le radio presenti ( 1 o 2 )

Per quanto riguarda la strategia di utilizzo dei due modi LoRa disponibili è infine presente nella pagina GUI delle “APRS FEATURES” una ulteriore area dedicata a specificarla.

L’utilizzo di queste modalità operative sarà oggetto di sperimentazione allo scopo di definire opportune varianti e scenari di utilizzo.

Per il sottosistema APRS , a parte l’aggiunta della maxi funzione di messaging già descritta, ci sono solo piccole modifche nell’area delle modalità di “Beaconing Agile” con l’aggiunta della possibilità di specificare per ogni modalità di beaconing tracker un doppio simbolo ed una soglia di velocità all’attraversamento della quale si usa l’uno o l’altro simbolo ( “Agile Symbol”).

Anche questa funzionalità sarà oggetto di ulteriore approfondimento per spiegare il senso delle varie opzioni offerte è identificare le situazioni in cui eventualmente usarle.

Un’area sottoposta a pesante reworking è stata anche quella della strategia di recovery e di setup iniziale della piattaforma HW/SW: l’obiettivo è stato una pesante riduzione del tempo di startup di  una scheda che da oltre un minuto/due minuti ora è ridotto a circa 18-20 secondi per avere un nodo operativo; per ottenere questo obiettivo sono state modificate in particolare le modalità di recovery di una scheda “bricked”, ovvero la modalità di implementazione della  procedura di “factory default”: in passato questa rendeva disponibile una finestra temporale allo startup entro cui si poteva operare per fare un “factory default” e questo portava al famoso minuto o due di tempo di startup: nella nuova versione questo meccanismo viene sostituito da una pressione “lunga di oltre 30 secondi” sul tastino funzione presente sulle schede ovvero da un comando di console da fornire sulla seriale USB.  Resta ancora possibile comandare il “factory default anche da GUI come in passato.

E’ stata anche completamente modificata la gestione della modalità di recovery nota come “Admin mode”, che in passato era automatica, ma che ora viene relegata ad un uso solo tramite console per gestire situazioni realmente di debug HW.

Una ulteriore area di particolare reworking è stata quella della console seriale/telnet: questa funzione è stata sempre presente  ma in questa versione del SW è stata espansa notevolmente implementando una serie di funzioni aggiuntive allo scopo di rimuovere dalla GUI una serie di funzioni prettamente sperimentali spostandone la gestione su una modalità operativa meno “accessibile”…  questo consente di semplificare notevolmente la mole di informazioni da conoscere per usare il dispositivo in maniera “conforme” agli standard senza necessariamente dover costringere l’utilizzatore a lunghe spiegazioni di funzioni non essenziali  per la normale utilizzazione di un dispositivo.

Dal punto di vista della possibiltà di caricamento di una immgine SW e di tenuta delle configurazioni , è stato fatto un significativo lavoro di ottimizzazione delle modalità di mantenimento delle configurazioni e di dimensione massima delle immagini SW supportabili; in particolare utilizzando processori tipo ESP32-S3 è ora possibile superare il classico limite dei circa due Megabytes per l’immagine arrivando a 4 o anche 8 Mbytes a seconda del tipo di processore S3 utilizzato; è stato anche introdotto estensivamente l’utilizzo della PSRAM per aumentare l’area RAM utilizzabile in caso appunto di processori tipo ESP32-S3.

Per quanto riguarda la tenuta dei dati di configurazione in passato esistevano due modalità diverse di cui una sfruttava la presenza sulla scheda di una FRAM ( ovvero una memoria a lettura/scrittura non volatile) pensata per la tenuta dei  “Post Mortem Data”, anche per i dati di configurazione e l’altra, necessaria per le schede tipo cinese prive di questa funzione, che sfruttava invece la flash del processore.

Questa doppia modalità creava problemi soprattutto per il supporto delle schede “cinesi” e faceva aumentare la dimensione dell’immagine SW; nella nuova versione del SW viene unificata la tenuta dei dati di configurazione in una unica modalità che sfrutta la memoria flash del processore ma con una modalità che garantisce la consistenza dei dati e la tenuta anche a ripetute riconfigurazioni senza danneggiare  la memoria flash ( “Wear levelling”).

Resta per le schede customizzate Sarimesh il supporto per i “Post Mortem Data” utilissimi per il monitoraggio di situazioni di fault sporadici in campo; tale funzione non è supportabile concretamente su schede “cinesi” per la mancanza di una memoria FRAM o di componenti HW equivalenti, che evitino di distruggere in breve tempo la flash del processore.

Novità anche per quanto riguarda il tema del caricamento del SW sia come primo caricamento su un HW vergine o già utilizzato con altri SW, che come aggiornamento del SW in campo.

Per il caricamento del SW in campo, ovvero via OTA (Over-The-Air) nessuna grossa novità essendo già ampiamente supportato da sempre tramite una modaliutà di tipo GUI, indipendente dalla GUI principale dei dispositivi; il limite del caricamento via OTA è l’impossibilità di caricare delle immagini SW di tipo “full” ovvero che oltre a modificare la parte “codice SW”, contenga anche informazioni relative al partitioning della memoria flash del processore quali le zone definizione delle partizioni,  di bootstrap, o delle zone destinate a contenere i dati di configurazione.

Per questo motivo qualunque dispositivo richiede per “il primo caricamento” del SW di dover accedere fisicamente al dispositivo tramite una interfaccia USB/Seriale: questa necessità deriva dalla struttura di base del BSP (Board Support Package) reso disponibile dal costruttore Espressif per i suoi chips e che consente di caricare tali dati esclusivamente tramite via seriale.

Il tool base per questa operazione è un applicativo sviluppato da Espressif noto come “SW Download tool” ; in passato questo tool era disponibile come un applicativo da scaricare sul PC windows o linux, e che esso fosse  da eseguire quindi localmente collegando il dispositivo da programmare al PC tramite un cavetto seriale/USB, installando eventualmente i necessari “drivers SW” , il che spesso complicava le operazioni di caricamento.

Ultimamente sempre Espressif ha reso disponibile come liberamente usabile un tool SW chiamato “WebFlasher” il quale realizza il porting del precedente tool in un ambito di tipo “browser web” sfruttando le funzionalità di gestione ed accesso alle intrfacce seriali di un PC presenti nel browser Chrome: il risultato è una modalità di caricamento che viene definita di tipo WEB ma che comunque richiede il collegamento fisico locale del dispositivo ad un PC, ma che evita il grosso delle incombenze di installazione dei drivers della seriale/usb.

Con questa versione del SW Sarimesh abbiamo creato un sito web Sarimesh WebSerial Tools che raccoglie in una unica pagina una serie di tools utili  per il primo settaggio o anche per la gestione iniziale o anche routinaria di un dispositivo LoRa:  la pagina web consente di accedere oltre che ad una serie di informazioni di tipo documentazione, a due funzioni principali:

* una funzione “Program” che è basata sul “web flasher espressif” e consene di caricare una immagine full in maniera molto semplificata

*  una funzione console che sfrutta le estensioni web seriali di chrome per consentire una accesso in “console seriale” al dispositivo in  modo da osservare in maniera completa il processo di boot allo scopo di evidenziare eventuali problemi  o semplicemente per inizializzare l’interfaccia WiFi senza ricorrere ad altri strumenti.

Nella stessa pagina sono presenti altri links alla documentazione e ai portali tipici su cui osservare il posionamento dei dispositivi.

Il Tool richiede di usare un browser della famiglia chrome in quanto è l’unica che supporta le estensioni seriali.

Nelle figure a seguire vengono riportate alcune schermate della console durante la fase di startup per dare una idea delle info che vengono rese accessibile a chi piace entrare nei particolari…

 

“Last but not least” è stato rivisto completamente il sistema di documentazione del progetto LoRa Sarimesh rinunciando  a rendere disponibile un corposo manuale (come fatto in passato) , preso atto che l’OM medio oggi non ha tempo per leggere, ma piuttosto preferisce cose semplici ed immediate:  il risultato è l’introduzione in tutte le schermate GUI di un ampio numero di links che presentano tramite pop-outs dei rapidi cenni sul significato e l’utilizzo della maggioranza dei  parametri offerti.

Resta come aggiunta l’esigenza di documentare in maniera più ampia e tradizionale alcune funzioni nel loro insieme: a tale scopo abbiamo creato un sito web dedicato accessibile all’URL https://wiki.sarimesh.net   in cui stiamo raccogliendo in maniera ordinata tutta una serie di documenti, articoli ed  informazioni che sono già reperibili sul nostro sito https://sarimesh.net  ma che essendo dispersi in circa 8-9 anni ovviamente sono reperibili in maniera non troppo ordinata e con una certa difficoltà.

Il sito WiKi consentirà di rendere accessibile in maniera sperabilmente più agevole anche altri articoli che andremo a scrivere con il progredire della sperimentazione.

 

 

Disponibilità del SW

Come sopra chiarito il target principale di questa release è costituito da dispositivi HW non necessariamente customizzati Sarimesh, per cui a seguire verranno forniti i puntatori web da cui scaricare delle immagini full per due delle piattaforme più diffuse ovvero per le schede T-Beam vr. 1.2 con chipset LoRa SX1278, e la scheda Heltech Tracker vr. 1.1 con chipset LoRa SX1262.

L’immagine fornita consiste in un unico file con estensione .bin caricabile tramite il tool di caricamento sopra descritto impostando l’indirizzo di caricamento al valore 0x000000 ; tutte le altre voci della schermata del loader possono essere lasciate con i defaults; per caricare l’immagine voluta usare la finestrella “carica file”  per puntare al file .bin scaricato dai puntatori forniti.

Alla fine del caricamento che può essere seguito tramite la filestra posta nella parte inferiore della pagina, il  programma chiederà di effettuare il reset del target.

Una accortezza per chi si appresta ad usare per caricare l’immagine questo SW è la seguente: con gli schedini tipo T-Beam vr. 1.2 è necessario  porre attenzione ad effettuare PRIMA del caricamento , le seguenti operazioni:

1) scollegare l’eventuale batteria dello schedino.

2) effettuare l’operazione di “flash erase” tramite il tool di programmazione.

3) solo dopo il completamento del “flash erase” caricare la nuova immagine.

A valle del caricamento di  una nuova immagine full la scheda risalirà in condizioni di “factory default”; sarà quindi necessario impostare, per accedere alla GUI Web del dispositivo una rete WiFi esterna a cui attaccarsi per il completamento delle operazioni di setup.

Il modo più agevole per operare è il seguente:

a) attivare l’interfaccaia webserial presente sul tool web di cui sopra e premere sulla tastiera il tasto invio fino a vedere un prompt dei comandi.

b) digitare il seguente comando di console:

ops wifiset <WiFi_SSID>  <WiFi_password>    seguito dal tasto invio, ad es.

ops wifiset miaretewifi miapassword

c) eseguire il comando seguente per vedere l’indirizzo IP acquisito dalla scheda:

sta

WIFI IP=192.168.1.110 GW=192.168.1.1 DNS=192.168.4.1 MAC=F8:B5:B7:20:DE:8C ssid:miaretewifi rssi:-54 dBm

 

d) accedere tramite il browser web alla pagina di indirizzo assegnato utilizzando le seguenti credenziali di default:

userid:  admin

password: admin123

e) procedere accedendo alla pagina di “Quick setup” inserendo TUTTI i pochi parametri richiesti ( incluso in particolare una posizione GEO di default)

f) verificare che nella schermata Network Configuration sia stato popolato il profilo di rete immesso da console in precedenza e cancellare eventuali profili non voluti o introdurne di nuovi.

g) alla fine del popolamento di ogni schermata premere il tasto “SAVE” presente alla fine della pagina.

h) una volta verificati e popolati in maniera eventualemente diversa i dati presenti e frutto del factory default, spostarsi sulla pagina di “Operation configuration”  verificandone le impostazioni ed adattandole ai propri gusti.

i) eseguire il SAVE della schermata di “Operation” e fare attenzione che non vengano riportati errori e che alla fine del save la schermata sia completamente popolata.

l) ticcare la casella “Commit” presente sulla parte inferiore della schermata  e premere di nuovo il tasto SAVE in modo da rendere permanenti l’insiemi dei cambi effettuati… verificare che non vengano riportati errori sulla pagina web…

m) effettuare il reboot della scheda da GUI o premendo il tasto reset sul dispositivo.

La scheda dovrebbe risalire con i parametri impostati… ad ogni buon conto conviene dopo il reboot verificare se tutto torna come voluto per evitare che qualcosa sia sfuggito…

Durante la compilazione o la review delle varie schermate sfruttare i link di help per avere info sui vari campi …

Per i possessori di HW Sarimesh ( allo stato un numero molto limitato ) valgono esattamente le stesse istruzioni di caricamento con l’unica differenza che NON vengono forniti i puntatori alle immagini da scaricare, stante la significativa varietà di schede in circolazione che richiede di conoscere l’esatto livello della scheda da upgradare; è sufficiente contattare lo scrivente fornendo le foto delle parti superiore ed inferiore della scheda da aggiornare in modo da capire esattamente che versione di scheda è.

Attualmente la versione SW 7.x è caricabile su tutte le schede HW Sarimesh messe in circolazione nel corso dell’anno 2025 e 2026.

A seguire i puntatori da cui scaricare le immagini SW 7.0.7z adatte ad essere caricate sulle piattaforme standard supportate.

* Heltec_Tracker_1_1 full image

* T-Beam Vr. 1.2 full image

Buon divertimento e… ai prossimi articoli per una serie di approfondimenti e qualche simpatica nonità che è rimasta nella manica….  per chi fosse interessato!