Sono oltre 4 mesi che non vi ho tediato con le mie chiacchiere… in realtà siamo stati abbastanza attivi… il nostro obiettivo in questi mesi lo possiamo sintetizzare in una parola: stabilizzazione….

Come più volte abiamo ricordato l’obiettivo principale della nostra attività è  quella di rendere disponibile una “piattaforma HW/SW” su cui poter effettuare agevolmente della sperimentazione della tecnologia LoRa in ambito radioamatoriale… e va da se che solo facendo della sperimentazione si può capire se e come la nostra piattaforma in realtà sia utile o si comporti come ci si aspetterebbe !

Orbene in questi ultimi mesi abbiamo finalmente implementato una serie di piccoli/grandi cambi sia a livello di HW che di SW individuando svariate cose da sistemare ed ottimizzare; il risultato  ad oggi è che finalmente penso possiamo dire di essere arrivati ad un primo risultato che si sta concretando con un buon numero di dispositivi in funzione basati sia su HW Sarimesh originale che su HW cinese , su cui sta girando il nostro SW con un buon livello di stabilità e di performance.

In questo articolo vorrei cercare di illustrare quello che abbiamo imparato e quello a cui siamo arrivati;  in articoli successivi poi cercheremo di illustrare più in dettaglio quello che ad oggi abbiamo in mano sia come HW che come SW in modo da orientare semmai meglio il tipo di sperimentazione da implementare.

In questi mesi svariati OM oltre al sottoscritto hanno attivamente collaborato ad una serie di prove e di confronti da cui sono emersi interessanti affinamenti della nostra soluzione.

Un primo grosso elemento che abbiamo imparato è come affrontare il tema dell’HW… infatti se è vero che per far arrivare degli spots su aprs.fi è più che sufficiente uno schedino cinese , non è altrettanto agevole riuscire a mettere in grado, chi è desideroso di andare oltre i limiti di questi schedini , di raggiungere l’obiettivo di usare  il nostro HW…. il motivo banale è che fare qualcosa di più ambizioso richiede necessariamente oggi di usare delle metodiche di prototipazione che purtroppo non possono passare per dei “breadboards filati”… non perchè sia impossibile, ma perchè l’affidabilità di un prototipo filato è molto scarsa a causa banalmente di falsi contatti o di errori di collegamento banali che rendono l’attività di sperimentazione molto complessa per fattori in realtà slegati dall’obiettivo della sperimentazione…

Quindi il problema era quello di mettere insieme un “palinsesto”  più che uno schema elettrico da implementare con le moderne tecniche di realizzazione dei circuiti stampati e su cui si potessero implementare con semplici plug-in/plug-out diverse configurazioni di test con la sicurezza che fossero ridotte al minimo le possibilità di errori di cablaggio …..

Un successivo elemento importante era quello del tipo di “processore”  da utilizzare…  oggi esistono svariati dispositivi che sposano diverse architetture e che promettono ottimizzazioni in svariate direzioni…  abbiamo cercato di fare un poco di schouting e la considerazione a cui siamo arrivati per una serie di considerazioni sia HW che soprattutto SW è che l’architettura del famoso ESP32 è ancora certamente la scelta più interessante …. principalmente ed innanzitutto per un problema di costi estremamente competitivi.

Fatte queste considerazioni ci siamo guardati intorno ed è stato evidente che pur mantenendosi sulla scelta ESP32 era possibile spaziare agevolmente in termini di scalabilità HW/SW in modo da poter cogliere diversi obiettivi principalmente in termini di rapporti costi/prestazioni…  abbiamo quindi deciso di puntare su tre diversi target: la versione ESP32-S3 per massimizzare le prestazioni, la versione ESP32-C3 per massimizzare la riduzione dei consumi e la minimizzazione dei costi, e la versione ESP32 tradizionale per le applicazioni intermedie.

Ne sono scaturite tre diverse “schede o PCB”  basate ognuna su uno dei tre processori  indicati e caratterizzate per poter fare della sperimentazione a 360° ….

1. La scheda Maxi_V2024 che rappresenta l’evoluzione della classica scheda Maxi pensata oramai quasi 5 anni orsono destinata a sperimentazione avanzata e pensata per una applicazione “fissa” . E’ basata sul processore ESP32-S3
2. La scheda Mini_V2 che consente la realizzazione di sperimentazione di soluzioni mobili pensate però con un target di uso in “auto” ovvero con alimentazione NON autonoma, e comunque dotata di una notevole modularità. E’ basata sul processore ESP32
3. La scheda “OffGrid” pensata per la realizzazione di soluzioni NON modulari a bassissimo costo e basso consumo energetico per un uso portatile e/o remoto. E’ basata sul processore ESP32-C3.

 

La figura mostra le tre schede a confronto….

Una lezione interessante che abbiamo imparato è stata poi quella di come consentire ad un aspirante sperimentatore di realizzare dei prototipi…  su questo fronte la conclusione è che l’unica concreta possibilità è quella di rendere disponibili al prezzo di costo delle schede completamente assemblate almeno per la parte a montaggio superficiale (SMD) , o ancora meglio delle schede completamente testate e collaudate pronte per ricevere i moduli ad incastro necessari per mettere su una certa versione di sperimentazione.

Sembra un fatto evidente … ma purtroppo non lo è per un motivo semplice: fare qualcosa oggi  che non si limiti a collegare pochi fili richiede di utilizzare delle tecniche di montaggio avanzate tipo l’uso di componentistica SMD e l’uso di un pitch delle tracce estremamente piccolo… e tutto questo implica che lo sperimentatore medio ha molte difficoltà sia nel montaggio che nell’approviggionamento dei componenti necessari e soprattutto la probabilità concreta di successo è estremamente bassa anche se ci sta tanta volontà di cimentarsi…

In dettaglio la principale difficoltà è che lavorare con componenti molto piccoli richiede una attrezzatura abbastanza delicata quale ad es. un microscopio, una stazione saldante all’altezza, una calma ed una pazienza non banale…

A questo si aggiunge il problema di acquisto dei componenti sui portali tipo Aliexpress che purtroppo spesso induce in errori quali ad es. l’acquisto di un “colore” (come lo chiamano …) diverso per un certo componente all’interno di una singola pagina di acquisto; un altro problema sono i costi di spedizione e le quantità minime convenienti…

Tutto questo aggiunto ovviamente ai tempi per ottenere un nuovo campione se per caso si scopre di aver fatto un errore di acquisto …

Nella nostra esperienza maturata nel corso della sperimentazione fin qui fatta emerge che è assolutamente perdente  lo sperare che più di  uno o due sperimentatori  ( dico 1 o 2 in numero…)  riescano ad applicarsi... ed il tutto è più che comprensibile in verità!!!

Realizzare oggi delle schede SMD assemblate in fabbrica è abbastanza fattibile ma si scontra con il discorso costi per vari motivi:

1. costi di spedizione dalla cina significativi
2. costi di produzione in Europa assolutamente fuori portata
3. oneri doganali per l’importazione  in Italia e per lo sdoganamento  significativi e che non consentono in pratica per piccoli quantitativi di recuperare l’iva del 22%
4. costi di attrezzatura per la realizzazione delle schede montate che aumentano notevolmente il costo unitario per piccoli lotti.
5. rischio notevole di dover gettare dei lotti a causa di errori presenti nello schema o nella definizione degli esemplari di componenti da montare.
6. problemi di normative in caso di vendita di assiemi che concretizzano un “prodotto” e non un KIT….

 

Tutti questi elementi implicano che a livello hobbistico è abbastanza complicato riuscire a mettere su qualcosa che consenta di realizzare delle schede premontate con costi contenuti… l’unica concreta possibilità probabilmente è quella di scambiarsi dei prototipi a livello privato sfruttando i classici portali tipo e-bay e in maniera assolutamente occasionale ovvero non professionale….

E’ questa la conclusione a cui saremmo arrivati e che pensiamo di testare… anche questa è una sperimentazione…. !

A livello SW con la release 6.0.x del SW LoRa Sarimesh  abbiamo finalmente iniziato a rendere disponibilii alcune features quali l’utilizzo del MagicTag e la doppia velocità di connessione a livello radio 300/5300 bit/sec con commutazione automatica.

Grazie poi alla offerta di campioni dei mesi scorsi sono anche aumentati il numero di iGates e di dispositivi tracker in uso che usano il nostro HW/SW; la figura seguente riporta uno snapshotb del portale di raccolta degli spots inviati dai vari iGates in funzione, ad oggi.

 

Cominciamo anche a vedere qualche esempio di funzionamento del sistema DualMode , ovvero la commutazione automatica della velocità di comunicazione tra SF=12  (spots color arancio) ed SF=7 (spots color verde) ovvero da 300 bit/sec a 5300 bit/sec a seconda della copertura radio…

 

Allo stato riteniamo che non ci siano troppi bug latenti nel SW per cui si può pensare di introdurre prossimamente altre nuove features.

Tra le nuove features stiamo  pensando al supporto della nuova banda 2.4GHz che aprirebbe la porta a nuove applicazioni del trasporto LoRa grazie alle velocità di trasmisisone notevolmente superiori che si renderebbero disponibili anche se su aree meno estese che non con la banda 433MHz.

Nel prosieguo mi propongo di fare dei post monografici sulle varie schede HW di cui ho accennato per poi passare a rivisitare alcuni aspetti SW che si sono rivelati, nella recente fase di sperimentazione su larga scala, abbastanza poco noti .

… eventualmente vi capita date semmai uno sguardo pure ad e-Bay ogni tanto per qualche novità…. just in case….