Progetto ZEUS - sensore di fulmini

Motivazioni

In questi ultimi anni il fenomeno delle tempeste di fulmini si è intensificato, sia in frequenza sia, soprattutto, in violenza. Il numero di fulmini che viene generato da alcune tempeste magnetiche particolarmente violente è impressionante, nell'ordine di svariate migliaia. Al di là della mera curiosità, ci sono ragioni di sicurezza che motivano uno strumento in grado di avvisare per tempo dell'approssimarsi del fenomeno e di fornire anche un indice di 'pericolosità'.
Il Progetto Zeus vuole essere questo strumento.

Introduzione

Basta una veloce ricerca in Internet per capire che la rivelazione dei fulmini si può realizzare solo in 2 modi: con una ricevente autocostruita a bassa-media frequenza, nel range da 250KHz a 700KHz, con un'antenna scomoda in dimensioni e di difficile realizzazione meccanica, oppure con il chip AS3595 di AMS - Austria Micro Systems, l'unico disponibile sul mercato per mia conoscenza.
La prima alternativa è scartata perchè sono incompetente sulla RF e, soprattutto, il circuito potrebbe solo identificare la scarica di un fulmine senza però fornire indicazioni su potenza e distanza.
La seconda comporta l'uso di una breakout board in quanto saldare il chip LGA e trovare una micro antenna adeguata sarebbero entrambe missioni impossibili.

Il cuore del progetto

Per fortuna ci sono 2 o 3 soluzioni sul mercato; io ho scelto il modulo MOD-1016 di Embedded Adventures dopo un'investigazione sul WEB.
Il prodotto non è proprio economico (viaggia intorno a Euro 30.00 incluse le spese di spedizione da UK), però è una soluzione 'fatta-e-finita', funzionante, pulita e pratica.
Per informazioni dettagliate sul modulo e per i documenti tecnici relativi rimando al sito di Embedded Adventures (EA)
Il modulo offre la possibilità di interfacciarsi alla CPU in I2C o in SPI; ho scelto quest'ultmima soluzione per semplicità del SW, per la velocità e perchè si integra facilmente con l'esistente progetto Meteo.

Considerazioni e scelte

AMS dichiara che la sensibilità del proprio chip permette la rilevazioni di eventi fino a circa 40km. Il chip fornisce due indicazioni per ciascun evento: la distanza stimata e la energia del fenomeno; questo valore non ha corrispondenza con alcuna grandezza fisica, ma è utile ai fini di comparazione tra gli eventi (in altre parole, i 'piccoli botti', 'i botti' e 'i grandi botti').
Durante i temporali violenti, i fulmini possono susseguirsi in brevissimo tempo e anche sovrapporsi; la registrazione dell'evento deve quindi essere molto veloce per permettere di discernere eventi quasi simultanei, fatto salvo l'arco utile di rilevazione del sensore di circa 2ms.
E' ovvio che il rivelatore non deve funzionare H24 per 365 giorni l'anno. D'altronde, quando è previsto che si possa scatenare un temporale, il dispositivo deve essere pronto a svolgere il suo lavoro per ore, anche in momenti scomdodi e di notte soprattutto, senza richiedere la presenza umana.
Per la successiva analisi dei fenomeni, il dispositivo deve registrare per ogni evento queste informazioni:

• Distanza stimata del fulmine
• Energia dell'evento
• Data e ora precisa (con precisa si intende la migliore risoluzione)

Da queste considerazioni sono scaturite le scelte di progettazione:

• 1. Serve l'alimentazione a batteria; di conseguenza, il consumo deve essere minimizzato
• 2. Serve poter alimentare il circuito con tensioni diverse e variabili
• 3. Serve un RTC ('Real Time Clock') con risoluzione di 10ms (centesimo di secondo)
• 4. Serve una memoria veloce (molto) e grande (molto), non volatile
• 5. Serve una batteria tampone per alimentare l'RTC quando il modulo è spento
• 6. Serve un canale di comunicazione con l'esterno per scaricare i dati accumulati e interagire col dispositivo

Punto 1

Richiede una CPU a basso consumo con possibilità di Sleep; anche tutti gli altri componenti, passivi inclusi, devono essere selezionati in base anche all'assorbimento; l'obiettivo è di ottenere una durata di mesi delle batterie, idealmente per tutta la stagione dei fulmini. In questa fase è stato scelto il modello PIC18F26K22 di Microchip, con dotazioni esuberanti per questa applicazione.
Datasheet

Punto 2

Prevede l'uso del 'Buck/Boost Converter' LTC1514 di Linear Technology (ora Analog); questo converter accetta tensioni di ingresso da 2V a 8V per cui mantiene l'uscita a 3.3V anche quando l'ingresso è inferiore o superiore. La corrente massima fornita è di 50mA, più che sufficenti per questa applicazione. Dispone di un utile pin che segnala lo stato di Battery low impostabile con 2 resistenze.
Datasheet

Punto 3

Prevede lo RTC modello MCP795W20 di Microchip; non è nuovissimo, ma ha carettistiche interessanti: consumo ridotto con possibilità di backup con batteria tampone; 1/100 di secondo di risoluzione; un WDT ('Watch-Dog Timer') interno con tempi lunghi (fino a 64s) utile per le funzioni di controllo ripetitive non urgenti.
Datasheet

Punto 4

E' indubbiamente il più arduo. Le soluzioni tecnologiche nel campo delle memorie sono parecchie, ciascuna coi propri pro e contro. Ottenere una elevata velocità di scrittura, con una capacità sufficiente a memorizzare anche migliaia di eventi e il tutto con consumi ridotti si può soddisfare solo con l'uso delle FRAM ('Ferroelectric RAM').
Questi componenti sono veramente 'speciali': hanno tempi di accesso praticamente nulli, limitati solo dalla velocità di comunizione SPI, che può arrivare fino a 40MHz, consumi ridotti che scendono a pochi uA in stato di riposo, sono non volatili senza richiedere batterie tampone, cicli di riscrittura che consentono tanti anni di uso. Hanno un unico neo: sono costose! Sono disponibili in diversi tagli di capacità, con prezzi che variano da circa 5 Euro fino ai 30 Euro. Nel mio prototipo ho utilizzato il modello massimo disponibile al momento (lo FM25H20), richiesto come 'sample' a Ramtron (ora Cypress).
Il chip ha una capacità di 2Mb (262,144 byte) che, con un record di 8 byte, consentono di registrare fino a 32,768 eventi.
Si possono però utilizzare modelli con minore capacità in quanto la piedinatura è identica; serve solo modificare una riga di programma che determina la dimensione in byte.
Datasheet

Punto 5 e 6

Il punto 5 è stato risolto con una batteria piccola (odio sprecare spazio) del tipo CR1210, inserita in un porta batteria con connessioni a saldare SMT. La tensione nominale fornita è di 3V; considerando che l'RTC richiede una tensione minima di 1.8V con corrente di mantenimento inferiore a 1uA, la durata della batteria è di anni.

Il punto 6 rappresenta un'altra criticità. La porta di comunicazione è USB, realizzata con un classico modulo convertitore seriale-USB: nulla di speciale qui. Il problema nasce invece dall'esigenza di separare galvanicamente le masse del circuito da quella del PC; questo è richiesto dal modulo AS3935 che deve operare 'floating' senza alcuna connessione a terra. Da qui l'obbligo di inserire un chip di separazione sui segnali di comunicazione TX e RX.
Inizialmente ho usato un optoisolatore a led; il consumo però era elevato e la qualità dei segnali non era il massimo.
Ho quindi virato su un accoppiatore attivo ad alta frequenza, il chip ISO7321C di Texas, semplice da usare, velocissimo e parco nei consumi.
Datasheet

Addendum

In realtà nell'elenco delle scelte dovrebbe esserci un ulteriore punto: "Display e comandi".
L'idea iniziale era di disporre di un display a caratteri (quello del Nokia 5100, per dimensioni e consumi) per visualizzare lo stato del dispositivo e la programmazione dei parametri, e di 2 bottoni per selezionare le voci di comando in vari menù.
Queste scelte iniziali si sono poi dimostrate nella pratica di difficile utilizzo e di scarso interesse; è preferibile gestire il modulo dall'interfaccia verso il PC o anche un semplice terminale di testo.
La versione attuale qui presentate, la 1.3, prevede ancora nello schema e sullo stampato le connessioni per questi elementi che però non sono inseriti sul PCB e non vengono gestiti dal SW.

Fase 1 - Settembre 2016

In questa fase è stato previsto il test HW e SW del modulo.
L'Hardware è stato assemblato su una prima versione del PCB, con qualche errore, come spesso succede, risolto con un paio di tagli di piste e fili volanti.
Il SW è scritto in C con XC8 in ambiente MPLABX di Microchip.
Idealmente il programma è suddiviso in 3 aree:

• driver delle comunicazioni e di lettura/scrittura registri delle periferiche
• funzioni per l'interfaccia utente e per la comunicazione seriale
• funzioni 'core' di gestione degli eventi

Stato del progetto

N.B: quello che segue è antecedente alle scelte finali sopra descritte

Bene, il SW di prova è completo: posso dialogare con il sensore e comandare tutte le funzioni, con i riscontri inviati al terminale. Tutto a posto...peccato che non rivela nulla !!!
Il brutto di questo progetto è che per capire se e come funziona servono i fulmini!.
In tanti hanno provato svariate soluzioni 'fai-da-te', dagli accendini piezo agli spinterogeni di auto, senza successo. AMS vende un simulatore, ma il prezzo superiore ai 250 Euro non invoglia certo all'acquisto.
Ovviamente, da quando è stato pronta la base per sperimentare, di fulmini non se ne sono più visti.
Solo un pomeriggio, per circa 1 ora alcuni ZAP hanno fatto capolino, non proprio vicini. Il sensore però non mi dato alcuna segnalazione.
Al momento non mi spavento più di tanto: ho indagato parecchio sul WEB e ho scoperto che è un fatto abbastanza comune. I motivi vanno dalla programmazione dei (6) parametri di base del funzionamento, alla nutrita serie di discussioni sul collegamento a terra del circuito.
L'opinione più diffusa è che il modulo debba essere totalmente isolato da terra, altrimenti diventa 'sordo'.
Questo comporta scelte HW impegnative: l'alimentazione a batteria (era già prevista) e, fondamentale, il collegamento isolato verso il PC, quindi con l'uso di foto accoppiatori sulla linea seriale (realizzato ora con una basetta a sè).

Fatto questo, mi mancano però ancora i fulmini e le previsioni a medio termine non me ne danno; la stagione si avvia verso il periodo di calma magnetica per cui temo di dover aspettare la prossima primavera.