Restauro e analisi dei sensori: ma funzionano o no?

Verifica del funzionamento

La fase di restauro dei sensori descritti negli articoli precedenti non sarebbe completa senza la verifica del loro corretto funzionamento. Purtroppo, la totale assenza di documentazione (non disponibile neanche presso la casa madre) ha reso questo passaggio complesso, anche se non impossibile. Fondamentale è stato l’utilizzo di un oscilloscopio digitale a memoria con decodifica di protocollo integrata.

_{Figura 1: Analisi di protocollo tramite il Rigol DHO812 con analizzatore di stati logici.}

Analisi del bus di comunicazione

Le analisi hanno permesso di comprendere che i sensori comunicano con la centrale DCP secondo una logica di interrogazione: la centrale interroga singolarmente ogni sensore e ciascun dispositivo risponde a turno sullo stesso bus, evitando collisioni.

Il bus è composto da quattro conduttori:

• +12 V (alimentazione) (ROSSO)
• GND (VERDE)
• RX (GIALLO)
• TX (BIANCO)

_{Figura 2: Morsettiera esterna alla DCP (notare connettori con legenda serigrafata). Chissà perchè sono state impiegate due morsettiere per la connessione di un bus...(???)}

Va precisato che i segnali RX e TX non sono differenziali, bensì con logica TTL a +5 V inversa, una sorta di RS232 “atipica” (con livelli logici 0 e +5 V), diversa dai più comuni adattatori seriali TTL-USB.

_{Fig.3 Scatola di derivazione posta a valle della DCP per la diramazione dei sensori dopo essere stata ripulita (si notino i cavi tagliati quando è stata dismessa), scaricatori e diodi di protezione per le scariche elettrostatiche.}

Un’ulteriore difficoltà è data dal fatto che i sensori rispondono solo se interrogati: in assenza di una corretta richiesta dalla centrale, essi non forniscono alcun segnale. Questo comportamento, sebbene corretto dal punto di vista progettuale (poiché previene collisioni sul bus), rende più complessa la fase di test e diagnostica. In pratica non è altro che una rete master-multislave, dove i sensori svolgono la funzione di slave e la dcp di master. L'interrogazione avviene in polling temporale.

Modalità di test e parametri inusuali

Atipica risulta anche la velocità di comunicazione: 1200 baud, 7 bit, parità pari, una configurazione davvero rara. È importante sottolineare che questa modalità di comunicazione non corrisponde a quella usata dalla centrale DCP durante il normale funzionamento dei sensori. Con ogni probabilità si tratta di una modalità di test o di servizio utilizzata in fase di collaudo e non è detto che tutti i sensori rispondano in maniera analoga, in funzione della relase software o modifiche hardware. Possiamo dire che QUESTI sensori rispondono in questo modo, e si è molto lontani da aver compreso tutte le funzionalità e sfaccettature del protocollo impiegato, nè era questo l'obbiettivo che ci si era posti. Ci interessava semplicemente sapere se questi sensori avessero ancora una scintilla di vita dopo anni di servizio e anni di riposo in un armadio dell' Osservatorio.
Invitiamo, come sempre, chi fosse a conoscenza di ulteriori dettagli o documentazione a contattare la mail dell’Osservatorio.

I primi tentativi di comunicazione

Nonostante le difficoltà, si è proceduto con una serie di tentativi, sviluppando nell’ordine:

• una semplice interfaccia hardware per l’adattamento dei livelli di RX e TX.

_{Fig.4 Interfaccia seriale usb con adattatore di livello per il dialogo con i sensori. Notare i cavi di uscita nero(GND), verde(RX) e giallo(TX). L'alimentazione +12 del sensore proviene da un alimentatore da banco.}

• un programma in Python capace di dialogare tramite porta seriale

_{Fig.5 Scrip in Python per il controllo della seriale e l'invio dei pacchetti sul bus.}

Dopo numerose prove, finalmente il sensore ha fornito una risposta: un passo decisivo. Fortunatamente, la risposta era in chiaro, ovvero in caratteri ASCII direttamente leggibili. È proprio questo l’aspetto che differenzia tale modalità dal protocollo di comunicazione usato normalmente dalla DCP.

_{Fig.6  La prima risposta del sensore di temperatura allo scrip in una calda sera di agosto}

Test pratici e script dedicati

Il processo è stato tutt’altro che lineare: in pratica si è dovuto procedere per tentativi anche sulla struttura del protocollo, realizzando uno script dedicato che generava sequenze di interrogazioni in maniera sistematica – quasi come provare le combinazioni di una cassaforte – e attendeva circa due secondi in attesa di una risposta. La problematica principale è stato determinare il valore del CRC (checksum) che non è quello che ci si aspetterebbe ma traslato di un offset, chissà perchè..
La pazienza ha infine dato i suoi frutti: il sensore ha risposto correttamente e si è potuto confermare che la strada intrapresa era quella giusta.

Implementazione con Arduino Nano

Per la fase di test definitiva è stata utilizzata una schedina Arduino Nano, programmata per interrogare il bus di comunicazione. Va sottolineato che:

- l’unica seriale hardware disponibile è stata sfruttata per la comunicazione, poiché l’attuale libreria SoftwareSerial non supporta configurazioni a 7 bit con parità odd;

- per gestire l’inversione della logica del segnale (non supportata nemmeno dalla seriale hardware), è stato necessario inserire un driver esterno con trigger di Schmitt, che garantisce sia la corretta inversione sia una maggiore stabilità del segnale;

- sebbene i sensori abbiano un consumo molto ridotto, non possono essere alimentati tramite la porta USB dell’Arduino: richiedono infatti 12 V, forniti da un alimentatore esterno dedicato.

_{Fig.7 Il tester Siap montato molto frettolosamente, il connettore in basso a destra è quello del bus}

_{Fig.8 Un'altra immagine più in dettaglio}

Grazie a questa configurazione, l’Arduino è stato in grado di inviare le interrogazioni ai sensori e riceverne le risposte in maniera affidabile, mostrando i dati direttamente su un display alfanumerico.

Risultati dei sensori

I sensori di umidità e temperatura hanno risposto correttamente alle interrogazioni, fornendo valori coerenti con le condizioni ambientali rilevate al momento del test.

_{Fig.9 Collegamento al sensore di Umidità in una umida sera di agosto (era anche calda)}

_{Fig.10 Valori di temperatura e umidità (finalmente) sul display}

_{Fig.11 Il tester collegato alla scatola di derivazione (o diramazione?) Si notino i cavi dei sensori in parallelo perchè, come già detto, il bus è comune.}

Va però precisato che la loro precisione assoluta è un’altra questione: l’ultima calibrazione risale probabilmente a circa 25 anni fa, e quindi eventuali derive nel tempo non possono essere escluse (un modo elegante di dire che i valori che forniscono sono certamente sballati).

Il sensore di temperatura PT100 è probabilmente poco soggetto a derive significative, mentre gli ADC e i riferimenti di tensione presenti sulla scheda di conversione possono influenzare maggiormente la precisione dei valori registrati.

Considerazioni finali

Forse il lavoro svolto non è valso del tutto lo sforzo impiegato: i numerosi tentativi hanno causato la rottura di diversi Arduino e schede annesse (cosa che capita quando si fanno esperimenti), e il tempo richiesto è stato notevole.
Probabilmente il gioco non valeva la candela… ma allo stesso tempo era importante capire se i sensori  fossero ancora funzionanti (anche se non utilizzabili praticamente perchè non tarati e calibrati) o dei voluminosi soprammobili/fermacarte. E questo obiettivo, alla fine, è stato raggiunto.

Al di là del risultato pratico, questo esperimento rappresenta anche un piccolo contributo alla memoria storica della strumentazione meteorologica: sensori che, all’epoca, erano costosi e di grande precisione, e che ancora oggi, per un elettronico, possono esercitare un certo interesse. Tuttavia, a differenza delle moderne stazioni e sensori, oggi facilmente intercambiabili grazie a protocolli noti e aperti, questi dispositivi utilizzavano un protocollo proprietario, ormai perso nel tempo, che ne impedisce l'utilizzo con sistemi di acquisizione diversi. Cosa che avrebbe semplificato non poco il lavoro.

Oggi, riportarli in vita, anche solo per una decina di minuti per una finalità storica e museale, significa non solo verificarne ancora l’efficienza, ma anche rendere omaggio a una tecnologia che ha aperto la strada agli strumenti moderni, in un’epoca in cui l’elettronica cominciava a sostituire i tradizionali sistemi di acquisizione più o meno manuali, trasferendo la cura con cui si costruivano parti meccaniche in complessi e raffinati circuiti elettronici, talvolta tradendo però alcune ingenuità che solo oggi, con il senno di poi, possiamo rilevare.