Come accennavo nei miei ultimi posts su questo sito, negli ultimi tempi mi è capitato di interagire direttamente con numerosi OM che si stanno avvicinando alla nostra sperimentazione.... uno dei punti che mi ha maggiormente colpito è stato il notevole interesse che ho scoperto esistere sulla nostra iniziativa ma che però rappresentava per la maggioranza delle persone una grossa anche se piacevole sorpresa….

In effetti  la quasi totalità di chi  si avvicina attualmente a LoRa lo fa più che altro per la curiosità di un qualcosa di cui tutti parlano… ma che poi si riduce quasi sempre ad un fuoco di paglia difronte alla evidenza che più che far arrivare i propri spots su aprs.fi o scambiarsi qualche acrobatico messaggino con una tastiera microscopica anzicchè usare un comodo cellulare,  non si riesce a fare… LoRa in questo contesto non è , nè più nè meno,  che qualcosa che fa peggio,  quello che da anni l’APRS tradizionale fa  meglio…

In questo articolo vorrei allora cercare di approfondire qualcuno degli argomenti che mi è capitato di trattare con parecchie persone singolarmente e che ho scoperto suscitare un significativo interesse.

La prima domanda che di fatto ci si pone è: per quale motivo inventarsi, per usare LoRa, qualcosa di diverso da quello che si riesce agevolmente già a reperire sui classici portali cinesi come HW o i classici SW che vanno oggi per la maggiore…. visto che sono più che sufficienti per fare tutto il fattibile ???

La domanda è ovviamente legittima… ma penso che i più attenti tra voi, che sono reduci dalla lettura del “ripassino su cosa sia LoRa“, avranno subito trovato delle risposte per cui forse le mie considerazioni a seguire saranno pleonastiche….

Anche noi, nel nostro “gruppetto Sarimesh”  ci ponemmo questa domanda e le risposte che ne scaturirono ci hanno portato a quello che oggi ci ritroviamo: LoRa era una tecnologia esplosiva in continua evoluzione, ma la percezione che di LoRa si aveva a livello dei radioamatori, diversamente che a livello degli addetti ai lavori dell’IoT, era che ci si trovasse di fronte ad una replica abbruttita del classico APRS... sintomatico di questo stato delle cose è la famosa posizione IARU che venne formulata relativamente all’uso di LoRa per applicazioni radioamatoriali e che sentenziava quello che ancora oggi si fa nel 99,99% delle applicazioni radioamatoriali, salvo ad aver semplificato pesantemente l’aspetto implementativo… parlo della definizione degli attuali parametri di utilizzazione del protocollo LoRa e delle modalità di utilizzo dello stesso che tutti ben conoscete.

Nelle considerazioni che facemmo ci stava la spinta ad una esplorazione a 360 ° del protocollo LoRa indipendentemente da quella posizione,  soprattutto alla luce delle enormi potenzialità che loRa presentava e alla enorme problematicità e precarietà della soluzione di utilizzo a cui si riduce l’utilizzo di LoRa attualmente ….

L’obiettivo che ci ponemmo fu allora quello di cercare una soluzione che potesse consentire di “sperimentare” le reali potenzialità di LoRa in più direzioni: la prima direzione era l’utilizzo dei nuovi chips LoRa di seconda generazione che stavano già uscendo sul mercato ma che non erano disponibili su nessuno “schedino cinese”.

Una seconda direzione fu l’approfondimento delle caratteristiche di LoRa al variare dei parametri che caratterizzano il protocollo allo scopo di cercare delle modalità che consentissero di aumentare le prestazioni dal punto di vista della banda trasmissiva utile e dell’utilizzo efficiente dei canali radio sfruttando le proprietà di ortogonalità del protocollo LoRa.

Una terza direzione fu quella della “riduzione” dell’occupazione di banda di un canale LoRa: i famosi 125 KHz di banda ( in campo sub-Gigahertz)  erano e sono se ci pensiamo un unicum nella pratica radioamatoriale ( a parte  il discorso della TV…) e per i più accorti sono sempre stati una spada di damocle in termini di “tollerabilità” da parte degli enti regolatori.

Una ulteriore direzione era quella degli aspetti di servizio:  un sistema tipo il LoRa appariva una soluzione ideale per tutte quelle applicazioni in ambito emergenziali che richiedono soluzioni completamente “OffGrid”  ovvero che offrano la possibilità di operare in completa assenza di sistemi di comunicazione “normali”… lo schema che vedeva LoRa usabile sostanzialmente sempre o quasi sempre come un sistema “bisognoso” di connettività internet per arrivare anche pochi Km di distanza contrastava vistosamente con le proprietà e le potenzialità del protocollo LoRa...

Da queste osservazioni scaturì la evidenza che era necessario, alla luce delle soluzioni HW/SW che esistevano ,  “inventarsi” qualcosa che, in accordo allo spirito radiomatoriale, consentisse anche di “andare fuori dal seminato”... e sia in direzione dell’HW che del SW…

Ovviamente lavorare con dispositivi ad elevatissima complessità e con grosse esigenze di innovazione rendeva ottimale un approccio a “building blocks”  che consentisse di evitare di riscoprire la ruota e consentisse esclusivamente di fare quello che mancava rispetto all’esistente…. in pratica creare la possibilità di mettere insieme una piattaforma HW su cui “inserire” flessibilmente dei moduli reperibili sul mercato in modo da poterli agevolmente integrare in diversi modi con minimo sforzo di sviluppo, minimi costi di realizzazione e soprattutto massima riutilizzabilità delle spese che si sarebbero andate a fare….

Su questa base nacque l’idea della scheda Maxi che in pratica è andata evolvendo tra svariate versioni per far fronte alle nuove idee ed opportunità,  che si evidenziavano, di sperimentazione, consentendo di riciclare in maniera quasi totale la componentistica “addon” utilizzata spesso fin dall’inizio delle prime sperimentazioni….

Allo stato attuale, se diamo un  rapido sguardo allo schema elettrico della ultima versione della scheda,  noterete immediatamente la presenza di svariati componenti o “posizioni” apparentemente inutilizzate o prive di significato…  il motivo di queste posizioni è in realtà legato a diverse idee di addons per poter realizzare particolari setup sperimentali che al momento sono stati semmai solo abbozzati a livello di “proof of concept” ma che potranno essere poi sviluppate in seguito…

Ai più attenti non sfuggirà che questo approccio è molto utilizzato anche in prodotti commerciali… la natura SW based di tutte le moderne applicazioni è tale che nel fare dell’HW si pensi a cose anche non immediatamente supportate in SW, ma che si pensa di supportare nel futuro… e si vuole essere preparati a NON richiedere nuovo HW o cambio dell’HW per poter implementare con soli addons SW tali funzioni…..

Capite allora che per supportare un tale approccio era indispensabile scegliere anche una “piattaforma SW”  sufficientemente flessibile per poter agevolmente realizzare applicazioni in grado di sfruttare in maniera appropriata le funzionalità HW che si pensava di rendere disponibili….

Ovviamente il primo passo fu… quello di evitare o tentare di evitare di riscoprire la ruota 🙂

Ricordo ancora le ricerche a 360° che facemmo allo scopo di trovare qualcosa che ci consentisse, almeno a prima vista, di avere qualcosa di appropriato…  ricordo ancora che ci colpì ( parlo di circa cinque anni orsono…) in particolare il SW “Meshastic” che sicuramente tutti conoscete … ma non ci limitammo ai SW radioamatoriali in quanto ( purtroppo forse …) qualcuno di noi veniva da esperienze lavorative su sistemi embedded per usi non proprio ludici ed era conscio della difficoltà di realizzare sistemi che andassero un poco oltre i classici programmi “Arduino based” anche se elegantemente vestite delle ultime metodiche di sviluppo SW….

Orbene il punto di approdo fu quello di implementare qualcosa di originale che consentisse di implementare, anche se su un processore di non enormi caratteristiche funzionali, qualcosa in grado di operare sia in modo tradizionale che in modo “real time”… la scelta fu quella di utilizzare l’architettura della famiglia ESP32  e del sistema operativo FreeRTOS che faceva da base per i SW forniti di corredo con questo processore ( quello che in gergo viene definito BSP ovvero Board Support Package).

I motivi di questa scelta li illustrai a più riprese nei primissimi articoli che scrivemmo riguardo alla nostra piattaforma e si  possono sintetizzare in pochi punti:  l’ESP32 rappresentava e ancor oggi rappresenta una delle piattaforme più performanti in una fascia di prezzo  “bassissima”, era supportata dall’onnipresente ambiente di sviluppo Arduino ed era ben supportato da una serie di librerie SW attinenti al tipo di componentistica che si pensava di andare ad utilizzare.

Per circa due-tre anni su questa base abbiamo realizzato varie versioni della nostra piattaforma SW ( che ora chiamiamo Sarimesh Core vr. x.y)  sempre utilizzando Arduino come ambiente di riferimento, nella speranza, purtroppo non rivelatasi particolarmente concreta, che altri OM trovassero interessante “mettere il naso” nel nostro SW sfruttando il fatto che fosse basato appunto su Arduino che appariva come un ambiente amichevole e superdiffuso….

Ad un certo punto, preso atto che questa speranza era sostanzialmente rimasta solo tale, decidemmo di migrare completamente dall’ambiente Arduino all’ambiente PlatfotmIO che nel farttempo si stava affermando come un ambiente di riferimento per tantissime applicazioni embedded… il salto si è rivelato una ottima decisione soprattutto alla luce del supporto di un insieme di schede HW che andavano aumentando dalla singola Maxi con cui eravamo partiti…. e PlatformIO si prestava egregiamente a supportare diverse piattaforme HW con il minimo sforzo di adattamento…

Uno dei motivi di questa migrazione fu anche il fatto che cominciò ad essere evidente che , standoci molta difficoltà da parte degli sperimentatori ad “auto-costruire” dei prototipi, per poter cercare di aumentare l’interesse verso il nostro SW poteva essere utile “portare” il nostro SW anche sui classici schedini cinesi… con il che si andava ad umentare esponenzialmente il numero di diverse varianti di schede HW da supportare e su cui adattare il nostro SW.

Nello stesso tempo avevamo cominciato a creare degli “spin-off” ovvero delle derivaziopni che pur sposando la stessa logica e la stessa architettura della scheda Maxi, cercavano di ottimizzare alcuni aspetti…. erano nate in pratica parecchie schede HW diverse che per esempio consentivano di diminuire le dimensioni fisiche ( ad esempio la scheda Mini) , oppure consentivano di realizzare delle soluzioni ottimizzate per una certa specifica applicazione… quale ad esempio la schedina Supermini pensata per i droni e la recente OffGrid pensata appunto per un utilizzo indipendente da fonti di energia tradizionali.

E qui siamo ad oggi… attualmente con la versione SW Sarimesh Core vr. 6.x siamo in grado di supportare un certo insieme di funzionalità con un unico paccheto SW su tutte le piattaforme supportate e che viene configurato con un unico sistema di uso e gestione indipendentemente dal tipo di HW, ma ovviamente con i soli limiti che i diversi HW hanno in termini di funzioni presenti e caratteristiche di potenza di calcolo richieste.

Nel seguito di questo articolo vorrei provare ad analizzare la sola scheda Maxi che comprende al suo interno un poco tutte le caratteristiche dei vari HW disponibili e che si presenta come una specie di “summa” delle features ( ovvero delle caratteristiche) funzionali sfruttabili ed implementabili; molte di queste funzionalità sono già ad oggi supportate anche dal SW, altre non lo sono ma lo potranno essere nel futuro se risulteranno di reale interesse pratico.

Analogamente in una successiva chiacchierata proverò ad illustrare alcune macrofunzionalità del SW che sono presenti nel pacchetto Sarimesh e che possono tornare utili  in particolari situazioni sperimentali.

 

La scheda Maxi in dettaglio

La figura a seguire è lo schema elettrico della scheda Maxi ultima versione; lo schema è volutamente eseguito evidenziando le filature allo scopo di rendere evidente a colpo d’occhio anche a persone non esperte di lettura dei moderni schemi elettrici le varie parti presenti e il modo in cui si integrano tra loro. Una versione pdf dello schema è scaricabile dal seguente URL: LoRa_Beacon_2024_DM_Vr3   ; la figura a seguire è una immagine 3D della scheda vista dal lato superiore, mentre le successive mostrano indettaglio una scheda montata completamente ed una scheda “nuda”, come viene assemblata infabbrica con le sole componenti a montaggio supeficiale (SMD).

 

Volendo osservare in dettaglio il circutio stampato è possibile scaricare i relativi files Gerber dal seguente URL: LoRa_Beacon_2024_DM_Vr3_GERBER_PCS1

A seguire vorrei soffermarmi sulle caratteristiche principali della scheda: al centro dello schema si nota il processore ESP32-S3 che è il cuore della scheda e a cui si collegano la maggioranza degli altri dispositivi presenti nello schema; il processore presenta due connettori USB-C di cui solo uno è utilizzato per scopi di caricamento iniziale del SW o per diagnostica locale collegandolo tramite un cavetto USB-C ad una porta di un PC in modo da apparire al PC come un collegamento seriale.

Il processore, come pure tutti i moduli addon, è montato utilizzando degli zoccoli con passo 2.54 mm in modo da rendere agevole l’eventuale sostituzione o il recupero agevole per essere impiegati in altre realizzazioni future.

Nella parte in basso a destra troviamo due posizioni destinate a montare delle piccole carte figlie su cui vanno montati i moduli LoRa che si intendono utilizzare sulla scheda; questa soluzione di montaggio è stata pensata per consentire di tenere isolata la parte delle due radio rendendo agevolmente sostuibili tali carte a scopo di test e/o di confronto eventualmente tra diverse soluzioni.

Le carte figlie hanno l’esatta dimensione dei moduli Ebyte E22-400M30S e E22-400M33S rispettivamente da 1 wat e 2 watt di potenza, caratterizzati dall’avere una pinnatura con spaziatura di 2.54 mm; sono però pensate per poter montare anche moduli diversi adattando la relativa pinnatura al formato 2.54 mm previsto sulle nostre PCB. Esistono diversi tipi di carte figlie attualmente disponibili per montare chips LoRa quali ad es. l’RA-01S basato come gli eByte prima citati sul chip LoRa SX1268 di seconda generazione, o un chip LoRa a 2.4 GHz.

Le due radio sono pilotate tramite un bus SPI e sono gestite in maniera tale da coesistere ; uno dei moduli LoRa viene usato in modalità  RX/TX mentre l’altro viene usato esclusivamente in modalità RX. In questo modo è possibile operare simultaneamente le due radio per ricevere due modi LoRa diversi ed implementare così la funzionalità DualMode . Le due radio sono terminate con due connessioni di antenna separate in modo da poter essere collegate a due antenne diverse ovvero ad uno splitter a RF per combinare le due radio su una singola antenna.

Tutti i moduli LoRa sono oggi resi disponibili ( a parte il caso di schedini cinesi supercompatti) racchiusi in dei contenitori metallici che forniscono la necessaria schermatura in modo da essere sufficientemente agevoli da montare anche su schede digitali; i connettori di antenna presenti sui moduli sono di tipo IPEX, mentre le terminazione dei cavetti di rilegamento di antenna sono in formato SMA.

Sempre a destra del processore , verso il basso sul PCB,  troviamo il modulo GPS ATGM336H ; si tratta di un modulo di recentissima uscita che supporta praticamente tutte le varie costellazioni satellitari attualmente disponibili con ottime carattristiche funzionali. Il modulo è dotato di una piccola batteria onboard ed è pilotato via seriale utilizzando una porta seriale asincrona del processore; è presente il pin di PPS (Pulse per second) che viene attestato sul processore per consentire un asservimento del tempo reale della scheda al GPS se montato ovviamente; il modulo GPS tipicamente NON viene montato nell’uso come iGate in quanto ovviamente in genere un iGate è fisso; volendo, può comunque essere installato per un uso per es. in mobilità o per avere un asservimento del tempo al GPS stesso.

Sempre in tema di base dei tempi è presente un modulo DS3231 RTC (Realk Time Clock) pilotato tramite il bus I2C,   in grado di mantenere una base dei tempi quarzata e con batteria tampone di buona precisione asservita al GPS o al protocollo NTP (Network Time Protocol) anche in assenza temporanea di un segnale GPS o NTP di sincronizzazione. La presenza di questo modulo è richiesta per avere la possibilità di tenere una base dei tempi sufficientemente accurata per un funzionamento  in un uso di tipo pseudo-sincrono della scheda, ovvero per implementare eventualmente delle modalità di lavoro della parte radio che richieda un allineamento della base dei tempi tra trasmettitopre e ricevitore molto stretto.

Anche questo modulo RTC è opzionale, ma se ne consiglia in genere sempre l’equipaggiamento  per consentire una tenuta accurata della base dei tempi e della data onde poter taggare gli eventi radio in maniera confrontabile e storicizzabile.

Alla sinistra del processore verso il basso sul PCB è presente un modulo Ethernet W5500 che viene utilizzato per fornire la connetività di connessione tramite cavo ethernet come alternativa alla modalità WiFi resa disponibile nativamente dal processore ESP32-S3. Il modulo Ethernet è pilotato tramite un secondo bus SPI dedicato, attestato sempre sul processore ESP32-S3. La connessione tramite cavo LAN è consigliata ovviamente in tutte quelle situazioni in cui la scheda è utilizzata per es. colocata sotto l’antenna su un palo o un traliccio e quindi ad una certa distanza da un eventuale accesspoint WiFi con cui allacciarsi alla connesisone di rete internet presente nel sito di installazione; spesso la precarietà della connessione WiFi è una causa di nstabilità operativa, mentre con la connessione Ethernet associata eventualmente anche alla telealimentazione tramite PoE (Power over Ethernet) rappresenta un modo decisamente più affidabile di collegamento.

Sulla parte frontale del PCB troviamo la predisposizione per il montaggio di due display di cui uno a colori pilotato tramite bus SPI ed il secondo monocromatico di tipo OLED pilotato tramite il BUS I2C;  i due display sono gestibili separatamente da SW anche se attualmente a livello SW non è supporta la modalità Split-Display.

Il display a colori è in grado di montare diversi tipi di display ; il tipo di display suggerito di default è un 1.14″ con risoluzione 135×240 pxl. Il display a colori è previsto disabilitabile da SW per ridurre eventualmente leggermente i consumi se non utilizzato.

Accanto ai display sono presenti due led (rosso e verde) ed un tastino funzione; lo scopo è quello di implementare delle semplici funzioni di monitoraggio del funzionamento e di gestione emergenziale della scheda in caso di indisponibilità della interfaccia grafica di controllo della scheda e per  implementare la funzione di factory defaults in caso di emergenza.

E’ anche presente un buzzer allo scopo di generare dei segnali sonori per indicare eventuali eventi quali ad esempio la ricezione di un pacchetto o altri eventi significativi.

Come si può notare dallo snapshot dello schema elettrico relativo a questa ultima parte è presente un circuito di bus extender allo scopo di aumentare il numero di pin di I/O del processore per consentire l’implementazione di alcune funzioni ausiliari che ora si andranno a descrivere.

Una funzione essenziale a garantire la continuità di servizio di  un dispositivo remoto basato su di un processore è la presenza di un meccanismo di Watchdog-timer HW; a questo scopo è presente un chip MAX6371 che implementa tale funzione: il chip deve essere stimolato da SW  periodicamente allo scopo di tenere attivo il meccanismo di watchdog… se il processore, per qualsiasi motivo, non è in grado di attivare questo stimolo per un certo tempo, il chip provvede autonomamente  ad attivare un segnale HW che resetta fisicamente il processore facendolo quindi ripartire, ed evitando che la scheda resti bloccata semmai per sempre. Il meccanismo può essere disabilitato tramite un ponticello ad hoc per scopi di test .

Sempre in tema di reset è presente,  un meccanismo HW che consente di resettare il processore da SW utilizzando un opportuno pin di controllo: questo meccanismo è presente allo scopo di consentire di resettare a comando il processore in modo sicuro anche in caso di malfunzionamento che impedisca il classico Soft Reset SW del processore.

Sempre in tema di disponibilità e di supporto al testing e alla diagnostica è presente una memoria FRAM ovvero una RAM di tipo ferromagnetico destinata a mantenere in maniera NON volatile una serie di dati relativi al funzionamento della scheda .

E’ questa una funzione estremamente utile per monitorare, fissare e diagnosticare una serie di situazioni anomale che si possono verificare in un uso non sorvegliato ( remoto) del dispositivo e che possono condurre ad una situazione di perdita di controllo della scheda.

Attualmente viene utilizzata per mantenere una serie di variabili di stato relative alle risorse disponibili del processore (es. memoria RAM) ,  allo stato dei semafori che monitorano l’accesso alle risorse HW ( bus I2C ed SPI)  condivise a livello SW dai diversi thread SW che sono attivi sul processore, nonchè degli indicatori di eventuali reboot allo scopo di individuare e fissare situazioni di reboot ripetuti causati per es. da situazioni di inconsistenza dei dati di configurazione:  si parla per questi dati di “Post Mortem Data” e rappresentano dei dati spesso molto significativi per diagnosticare situazioni di malfunzionamenti sporadici non altrimenti diagnosticabili.

Una ulteriore tipologia di dati tenuti nella FRAM sono dei messaggi di “evento” quali ad es. azioni di manutenzione, di caricamento del SW, di reboot manule, etc. Questi dati tipicamente sono tenuti in RAM e scompaiono a cavallo di un restart del processore; grazie all’uso di una FRAM è possibile rendere questi dati non volatili in modo da arricchire la base di informazioni diagnostiche disponibili in caso di anomalie.

Va osservato che tutti questi dati potrebbero essere tenuti in una flash o una EEPROM ma è una pratica estremamente dannosa in quanto, essendo questi dati aggiornati in tempo reale ed in continuazione, oltre a rallentare l’operation del sistema produrrebbero la distruzione di quelle memorie in brevissimo tempo; la FRAM per la sua tecnologia è completamente immune da questi fenomeni di usura.

Abbiamo poi la parte di alimentazione ed una serie di funzioni ausiliari che ora andiamo  ad illustrare.

La scheda Maxi NON è progettata per un uso di tipo intermittente, per cui non si sfruttano assolutamente le funzionalità di sleeping del processore; esistono però delle possibilità di abilitare o disabilitare alcune funzioni tramite comando SW.

La parte di alimentazione è pensata per essere alimentata  in diverse modalità

La modalità di default prevede di essere alimentata a 12 Volt tramite un alimentatore esterno o tramite un iniettore PoE con uscita sempre a 12V. Da questa tensione viene ricavata tramite un modulo DC/DC stepdown una tensione a 5 volt che alimenta il processore ed i moduli radio che richiedono tale tensione, mentre un ulteriore LDO produce una tensione a 3.3 V per alimentare tutti i i circuiti ausiliari quali ad es. i display, il GPS, etc.

Esiste poi una seconda modalità di alimentazione che è prevista per l‘integrazione con una schedina esterna ausiliaria destinata a svolgere funzioni di servizio: la prima funzione di servizio è supportare una modalità di alimentazione tramite pannello solare e UPS associata ad una batteria LiPo di grossa capacità; una seconda funzione è quella di ospitare un controllore di tipo Raspberry allo scopo di implementare funzioni SW di livello gestionale; questo processore è pilotabile come alimentazione dal processore ESP32 tramite un opportuno comando SW.

Allo scopo di misurare  e monitorare gli aspetti di alimentazione è presente un chip INA219 che è in grado di misurare la tensione e la corrente assorbita a valle del DC/DC stepdown allo scopo di evidenziare eventuali problemi di instabilità dell’alimentazione della scheda.

Essendo la scheda prevista per essere installata eventualmente anche in una scatola stagna in esterni, è presente la possibilità di pilotare una ventola di circolazione dell’aria anche essa pilotabile dal processore via SW.

Esiste poi la predisposizione per installare e pilotare da SW alcuni sensori attestati sul bus I2C: attualmente sono previsti due diversi zoccoletti: uno  in grado di collegare direttamente dei sensori tipo BME680, BME280 e BMP280  (ovvero sensori di pressione, temperatura, umidità e qualità dell’aria) e un altro previsto per collegare un sensore di polveri sottili SPS30. Tutti questi sensori sono già supportati a livello SW; essendo in realtà questi sensori tutti attestati sul bus I2C è idealmente possibile adattare anche ulteriori sensori pilotabili tramite I2C, con opportune aggiunte a livello SW.

Tutte le funzioni finora descritte sono utilizzabili in quanto supportate anche a livello SW ; esistono poi ulteriori predisposizioni a livello di HW per realizzare ulteriori funzioni non ancora supportate a livello SW.  Queste funzioni pur essendo state oggetto di un test veloce non sono ancora definite utilizzabili in quanto non è stato ancora integrato nell’attuale pacchetto SW un loro supporto organico; in particolare il testing di queste funzioni è stato limitato a degli opportuni test-segments SW.

Una funzione già prevista in HW è il supporto per una scheda di memoria compact flash allo scopo di implementare una memoria di massa locale allo scopo di accumulare dati quali ad esempio dati di trafifco o dati rilevati dai sensori.

Una seconda opzione prevista è quella di montare una coppia di adattatori seriali resi accessibili uno tramite collegamento RSS232 e il secondo tramite collegamente seriale su USB; lo scopo di queste due interfacce seriali è quello di consentire l’utilizzo della scheda in modalita KISS TNC seriale o per interfacciare dispositivi di tipo seriale quali ad es. sensori o dispositivi esterni non meglio identificati allo stato.

Per utilizzare queste funzioni saranno richiesti dei piccoli modulini già identificati e di cui è stato previsto già il montaggio sul PCB del Maxi.

 

Come penso sia chiaro la scheda Maxi è pensata per un uso  sperimentale per cui è sottinteso che rappresenta uno strumento di prototipazione e di studio ; in particolare l’utilizzo di zoccoletti per connettere i vari moduli pur risultando molto pratico in fase di sperimentazione ovviamente non è una soluzione utilizzabile per un uso “serio” in un ambiente semmai anche ostile.

E’ comunque una base utilizzabile anche in situazioni classiche semplicemente optando per un montaggio tramite saldatura di tutti i moduli evitando i contatti. Quindi, a richiesta, è possibile realizzare delle schede completamente saldate che certamente avranno una maggiore resistenza ambientale.

Attualmente per chi fosse interessato siamo in grado di fornire sia delle schede montate con la sola componentistica SMD in fabbrica, sia delle schede completamente montate anche con la modulistica non SMD e pronte all’uso; per entrambe le soluzioni il nostro orientamento è di NON operare a fini di lucro, per cui tutte le parti saranno fornite come semplici Kit al puro prezzo di costo senza ricarichi.

E’ anche sottinteso che queste schede sono utilizzabili esclusivamente da radioamatri forniti di licenza radio in quanto operano con bande di frequenza e con  parametri di potenza non consentiti per un uso tipo ISM (uso libero). 

Per ogni ulteriore informazione potrete contattarci all’indirizzo di e-mail: info@sarimesh.net