ESP8266 – Collegare più sensori analogici

Usando ormai da svariato tempo schede basate su ESP8266-12 ho imparato a convivere con i due limiti operativi di questi controller, ovvero il non indifferente consumo di corrente, il che ne rende problematica l’alimentazione con batterie e la presenza di una sola entrata analogica.

Il primo problema è in qualche modo aggirabile ricorrendo alla gestione in Deep Sleep di un nodo, quando però non è richiesto che il nodo debba essere sempre “sveglio” e vigile, in attesa di eventi estemporanei. Nel secondo caso invece è invece necessario ricorrere a chip esterni, tipo l’MCP3008 o MCP3208, che mettono a disposizione un certo numero di entrate analogiche da gestire ad esempio sul bus SPI. D’altronde è lo stesso problema che hanno i Raspberry, che di entrate analogiche non ne hanno proprio.

Esistono comunque in giro degli schemi semplificati che permettono agli ESP8266 di lavorare con più sensori analogici contemporaneamente effettuando una sorta di multiplexing via software. Ho realizzato un circuito di test composto da un controller Wemos D1 mini (ma anche una qualsiasi altra scheda basata sull’8266 va benissimo) e tre fotoresistori GL5539, a rappresentare genericamente 3 sensori analogici.

a0_multipli

Nella parte superiore della breadboard ci sono i soliti rail di alimentazione, 3.3V in questo caso, tensione che costituisce anche la Vref per i sensori. Questo perché nonostante il datasheet di Espressif citi come voltaggio di riferimento per l’entrata analogica A0 i valori da 0 a 1V, nelle schede commerciali in genere un partitore di tensione interno riporta il Vref ai più comodi valori compresi tra 0 e 3.3V.

Ogni sensore ha la sua resistenza di pull-down di 10K, che può variare a seconda di cosa stiamo usando e, cosa molto importante, ogni singolo circuito relativo ad un sensore analogico è isolato dagli altri tramite un comune diodo. In questo modo i sensori non si influenzeranno tra loro quando attiveremo di volta in volta i rispettivi pin digitali a cui sono connessi. Senza i diodi avremo comunque letture scombinate, provare per credere.

a0_multipli_2

In basso ho creato un common rail per convogliare i segnali analogici provenienti dai sensori e indirizzati all’entrata A0 del controller. Sarà quindi lo sketch, prima di effettuare la lettura sul singolo sensore, a portare a livello alto il relativo pin digitale e a portare a 0V gli altri 2.

Ecco lo sketch di esempio:

La cosa sembra funzionare. Dov’è il problema? I diodi, naturalmente. Questi provocano per loro natura una certa caduta di tensione nel circuito. Nel mio caso è esattamente di 0.5V, il che significa che il voltaggio di riferimento viene abbassato da 3.3V a 2.8V e avremo letture raw che non vanno da 0 a 1023, ma da 0 a 870 sballando tra l’altro la formula che uso per il GL5539 che dovrebbe diventare:

Insomma, se vogliamo convivere con questa situazione, una volta dedotto il valore massimo che otteniamo dopo la caduta di tensione (es. 870) possiamo rimappare le nostre entrate analogiche “virtuali” con una istruzione del tipo:

val = map(val,0,870,0,1023);

tenendo conto però che stiamo perdendo risoluzione sulle letture analogiche, e quindi qualità sul valore ritornato. Se tutto questo è per noi accettabile va bene, altrimenti è decisamente meglio passare a veri multiplexer, quindi chip esterni del tipo MCP3008 che sono comunque gestibili molto facilmente e che occupano sempre e comunque 4 pin digitali. In questo caso i valori letti saranno accurati al 100% (10 bit).

Una scheda che però mi intriga ancora di più e che ho intenzione di provare è la ADS1015 di Adafruit, che mette a disposizione 4 entrate analogiche ad alta risoluzione (12 bit, ovvero non più 1024 valori ma 4096) a guadagno variabile, anche se al costo di circa 10$. Il massimo della flessibilità insomma visto che veicola i dati sul bus I2C, impegnando solo 2 pin per i segnali.

 

Sensore Adafruit BMP280

In genere quando si ha bisogno di un sensore barometrico, capace cioè di misurare la pressione atmosferica, si ricorre al classico BMP180, reperibile presso alcuni fornitori cinesi intorno ai 3 euro. Ci sono però in commercio versioni più precise e flessibili, come ad esempio il BMP280 messo in commercio da Adafruit, a circa 10 dollari. Se poi vogliamo anche che il modulo misuri l’umidità relativa sia Adafruit che Sparkfun hanno in catalogo il BME280, in entrambi i casi quotato sui 20 dollari. Quello Adafruit può essere alimentato sia a 5 che a 3.3V mentre lo Sparkfun solo a 3.3V. Personalmente non spenderei 20$ per avere anche la misura di umidità, ma a questo punto userei un BMP280 affiancato da un DHT22 (3-4€) risparmiando un pò ed ottenendo anche un’altra lettura di temperatura per controllo.

Comunque: cos’ha in più il BMP280 rispetto al suo predecessore BMP180? Innanzitutto è più preciso, specialmente nella lettura barometrica. Nel datasheet Bosch del BMP280, reperibile QUI, c’è anche una breve comparativa dei valori tra i due sensori, e poi nel caso del BMP280 possiamo usare sia l’interfaccia I2C che SPI.

bmp280-1

Come si nota in figura la scheda Adafruit espone ben 6 pin così indirizzati:

Volendo quindi utilizzare il BMP con il bus I2C è sufficiente collegare i pin SCK e SDI oltre all’alimentazione, mentre in SPI servono 4 connessioni più l’alimentazione. Quindi direi proprio nessun problema di convivenza anche con molti sensori di vario tipo sullo stesso controller.

E mettiamoci poi alla fine anche la qualità costruttiva e l’affidabilità dei prodotti assemblati da Adafruit.

Passiamo alla libreria di gestione: ovviamente Adafruit mette a disposizione sul suo sito una LIBRERIA per questo sensore che va utilizzata oltre a quella generica comune a tutti i sensori Adafruit.

Sugli articoli di qualche mese fa riguardanti il BMP180 avevo fatto uso della libreria Sparkfun, perché ritengo abbastanza inutile avere una funzione per l’altimetro se non si ha la possibilità di prendere una misura di pressione a 0 mt. sul livello del mare. L’altezza precisa del punto di misura (sempre fissa se costruiamo una Stazione Meteo) la possiamo ricavare meglio dal GPS di un cellulare ed usarla poi per ricavare la pressione S.L.D.M. che è direttamente confrontabile con i dati meteo pubblicati dalle fonti ufficiali. Quindi stavolta va bene la libreria di Adafruit e quest’ultima quantità ce la calcoliamo da soli.

bmp280-2

Ecco un breve sketch di esempio per Arduino utilizzabile, con le opportune modifiche di collegamenti ai pin,  anche su schede ESP8266:

Nella funzione utente leggi_BMP280() ho quindi ignorato la readAltitude() messa a disposizione dalla libreria a favore del calcolo della pressione SLDM. E’ possibile usare l’altimetro ma ricordiamoci che il parametro di input 1013.25 mBar è un valore assolutamente teorico e non garantisce precisione nel calcolo dell’altitudine. Sarebbe necessaria contemporaneamente e nello stesso luogo un’altra lettura di pressione sul livello del mare con cui “entrare” nella funzione readAltitude().

Un’ultima cosa: mi raccomando di non dimenticare la bmp.begin() dentro la funzione setup. Il sensore è calibrato in fabbrica e questa funzione ne chiama un’altra interna alla libreria, readCoefficients(), che acquisisce i dati di calibrazione inseriti dal produttore e memorizzati in alcuni registri interni del chip Bosch.

 

 

ESP826612-e e sensori analogici. Risolto.

Ci ho messo un po’ a capire, ma credo di aver risolto. Dopo aver provato ad installare il supporto per le schede ESP versione 2.0.1-rc2 e non aver notato progressi sono andato a rovistare nel codice in cerca di qualche ispirazione. In effetti la gestione della analogRead() è rimasta la stessa:

se si usa un Mac come nel mio caso, cercando in

 un file chiamato core_esp8266_wiring_analog.c  non ho trovato particolari indizi

se non quello che nella chiamata di questa funzione è vietato distrarsi e immettere come parametro di input ‘0’ invece di ‘A0′. 🙂

L’illuminazione mi è venuta guardando il codice di debug che io metto come testata nei miei sketch ESP e che ha avuto un effetto stabilizzante nei runtime dei moduli. Ecco qui il colpevole:

Anzi, il colpevole era questa maledetta riga:

che ha il compito evidentemente di mettere in output il pin ADC per leggere il Vref e che inibisce l’uso dello stesso pin come porta analogica….

Dopo aver dato qualche testata contro il muro per non averci fatto caso prima, ho tolto solo questa riga lasciando il resto, ho ricaricato lo sketch e il mio fotoresistore GL5539 ha miracolosamente preso a misurare correttamente fotoni, facendo il suo sporco lavoro.

Due cose soltanto mi lasciano un po’ perplesso: il pin ADC lasciato “a vuoto” non ritorna  0 ma un valore flottante compreso tra 10 e 15. Vabbè, ci posso anche stare. Ma la cosa più strana è che, multimetro alla mano, ho misurato che la porta satura (ovvero ritorna valore 1023) non a 1V come dichiarato, ma a 3.3V, il voltaggio di alimentazione. Tanto è vero che al di là della resistenza di pull-down (10Kohm) che ho lasciato, non c’è stato alcun motivo di usare nel circuito un classico partitore di tensione.

Verificherò questa cosa anche sulle altre schede in mio possesso, se così fosse sarebbe anche meglio, non perderei risoluzione sui sensori analogici. E’ strano, ma le misure dicono che è così…..

 

ESP8266-12e e sensori analogici

esp8266-12e

Finora i miei tentativi di dare un senso a quella benedetta “porta analogica” AD0 presente nei miei ESP8266-12e sono stati piuttosto frustranti. Almeno nella versione che ho io, quella con il chip CH340, la analogRead() ritorna invariabilmente un valore 1023 sia con la porta “a vuoto” che con un qualsiasi voltaggio nel range 0-1V applicato. La cosa assurda è che a vuoto il pin risulta elettricamente a 0V verso massa, ma la lettura è sempre e comunque 1023.

Ho cercato ovviamente su Internet di trovare informazioni ed effettivamente ho trovato diversi articoli che parlano di “valori random” su questa porta tra cui il mio 1023, imputabili probabilmente alla libreria che interfaccia la IDE di Arduino. D’altronde io sto utilizzando la versione “certificata”, la 1.6.5, e la trovo estremamente comoda visto che non ho il tempo di provare a programmare questa scheda con altre interfacce.

Spero che sia solo un problema dell’attuale interfaccia che sta alla versione 2.0.0, e che comunque ha più di 300 issues aperti. Ho visto che la prossima versione in fase di sviluppo è alla Release Candidate 2, quindi prossima all’uscita, e  mi auguro che questo fastidioso problema venga risolto.

Arduino e fotoresistori GL55XX

fotoresistenza

In precedenza ho illustrato come utilizzare il sensore TLS2561 per misure di luce in Lux di buona qualità, ma nella maggior parte dei casi possono essere utilizzati i più comuni fotoresistori della famiglia GL55 che, a fronte di una più bassa qualità costruttiva offrono tuttavia un “lavoro” più che decente oltre a costare enormemente di meno. Si tratta comunque di componenti passivi (a differenza dei fototransistor) che possono presentare variazioni dei valori caratteristici da esemplare a esemplare anche abbastanza importanti, ma se non abbiamo in mente di costruire un luxmetro di precisione ci possiamo anche accontentare. Per ottimizzare il codice che presento in seguito sarà bene tenere sott’occhio il datasheet di tutta la serie, che si può scaricare QUI, da cui andranno prelevati i valori della Dark Resistance e Light Resistance, tipici del modello. Nel mio caso, essendomi procurato dei GL5539, avrò rispettivamente come valori 5Mohm e 50Kohm.

Nel circuito ho utilizzato una resistenza di Pull-Down (o stabilizzatrice verso massa, come vogliamo chiamarla) di 10Kohm, che mi sembra un buon compromesso nel caso di una scheda Arduino generica che abbia come voltaggio di riferimento 5V. Ecco lo schema di collegamento su breadboard:

gl5539

Nello sketch andranno quindi valorizzati correttamente nella funzione di calcolo in Lux della lettura sensore i valori RD e RIF, deducendoli dal datasheet. La formula utilizzata per la conversione in Lux è decisamente migliore di quella che ho utilizzato in passato per il Keyes KY018 e ritorna un valore -1 in caso di saturazione del sensore, il che accadrà solo in presenza di forte luce solare diretta sul GL55XX. Al confronto con un Luxmetro vero le letture mi sono apparse sempre decenti, a conferma della bontà dell’algoritmo.

Ecco qui lo sketch di test. Ho utilizzato per l’output oltre l’uscita seriale anche uno dei miei LCD di cui ho parlato in precedenza, ma si può bypassare il codice sostituendo all’inizio la definizione #define LCD false a quella esistente.

SKETCH DI TEST:

 

Stazione Meteo 3.0 su ESP8266-12e

meteo3

Era prevedibile che portassi il nodo relativo alla Stazione Meteo da Arduino a ESP8266. La possibilità che offre questo modulo di entrare direttamente nella LAN casalinga fa sì che possa andare a scrivere direttamente i dati in un server MySql senza ricorrere ad intermediari. L’unico particolare è che non avendo ancora disponibile (per ora e per quanto ne sappia) una libreria che dallo sketch sia in grado di effettuare direttamente le INSERT nel database (cosa che per gli Arduino esiste da tempo) necessita di spedire i dati con il protocollo  HTTP ad un web server attrezzato con un interprete PHP, che potrebbe risiedere ad esempio nello stesso Raspberry dove gira MySql. Niente di complicato insomma, specialmente per chi già ha almeno conoscenze di base di questi ambienti.

Devo dire che il mercato di queste piccole schede è molto agguerrito e in continua evoluzione: già sono in commercio cloni di Arduino Uno dotati di moduli wi-fi ESP, che mantenendo lo schema di connessioni tipico di Arduino (comprese le molte porte analogiche che mancano agli ESP) abbassano notevolmente il costo della connessione wi-fi da svariate decine di euro a 5-6 euro. Un chiaro messaggio a chi riteneva che si dovessero spendere 70 euro per mettere un singolo Arduino in rete via wi-fi, francamente un’esagerazione.

Risolti i problemi di stabilità di cui ho parlato in precedenza (ora i moduli sono stabilissimi) rimaneva il problema del consumo di corrente, che è notevolmente maggiore di un Arduino Nano e che mi creava molti problemi ad alimentare la stazione con un battery pack a celle solari di quelli che si usano per ricaricare i cellulari. Il modulo può essere facilmente messo in “sleep-mode” e riportato in vita solamente per effettuare le letture diciamo ogni 5 minuti, il che abbassa drasticamente il consumo di corrente che altrimenti si manterrebbe su diverse decine di mA. Colpa ovviamente del modulo wi-fi che per collegarsi alla LAN e per rimanerci collegato, specialmente in caso di segnale basso, consuma molta energia.

Un’altra cosa interessante da sottolineare è il buon comportamento di questo modulo nei confronti del segnale wi-fi. Per la cronaca quelli che sto utilizzando ora sono i 12e venduti da BangGood a circa 6 euro, interfacciati verso la porta USB da un chip CH340 (altri produttori usano l’FTDI). Nonostante l’antenna “stampata” sulla scheda stessa non possa dare le stesse prestazioni di una esterna in termini di sensibilità devo dire che anche con un segnale di -94 o -96 dB raramente il modulo perde la connessione, e se accade si riaggancia al primo colpo al mio router. Tutto questo è documentato dal mio logger dove registro in tempo reale anche questo tipo di attività.

Lo sketch che pubblico di seguito invia i suoi dati via HTTP ad uno script PHP situato nella DocumentRoot di un server Apache che una volta letti i dati si occuperà di inviarli ad un server MySql installato, nel mio caso, sulla stessa macchina, un Raspberry Pi2.

Ecco lo script:

Esiste quindi un database con dbname = domotica e una tabella dove vengono depositati, ogni 5 minuti, i dati inviati dalla Stazione.

La tabella MySql avrà questa struttura:

Ho preferito mantenere il timestamp di ricezione dei dati in UTC, ovvero un orario di riferimento con fuso orario 0 con ottima approssimazione assimilabile al Tempo Medio di Greenwich perché non genererà date ambigue nel momento in cui si passa dall’ora solare a quella estiva, MySql permette poi in fase di interrogazione di riferirsi al fuso locale italiano (definito CET, e poi CEST quando in vigore l’ora estiva) con una query del tipo:

Qui devo fare una annotazione di tipo sistemistico: la funzione CONVERT_TZ() richiede che siano popolate alcune tabelle di sistema che generalmente sia in MySql che in MariaDB NON sono inizializzate. Per evitare che la lettura delle date ritorni dei valori NULL bisogna, da shell Linux, lanciare una utility che prelevi le informazioni relative alle timezone (tipicamente in /usr/share/zoneinfo) e le depositi nelle tabelle in questione. Il comando è:

Di seguito verrà chiesta la password dell’utente root del database. A esecuzione avvenuta si potrà andare nello schema denominato “mysql” e controllare che le tabelle [timezone_*], credo siano 4 se non ricordo male, siano popolate.

In poche parole la tabella nella sua forma originale si presenta in questo modo:

Schermata 2016-01-22 alle 21.56.33

E letta dalla query che ho indicato con le conversioni delle date in quest’altro modo:

Schermata 2016-01-22 alle 21.56.48

Ma passiamo ai collegamenti fisici: ho sostituito il “vecchio” lettore di luce KY018 con un più preciso e flessibile TSL2561 di Adafruit, digitale, che mi ha permesso di non scontrarmi con la poca flessibilità delle schede ESP con i sensori analogici.

“Solita” resistenza di pull-up sul sensore DHT22 (4.7Kohm o 10Kohm) e, cosa fondamentale un “ponte” possibilmente interrompibile tra il pin GPIO16 (D0) e il pin RST per far sì che funzioni il codice di Deep-Sleep del modulo. Questo circuito va chiuso durante l’esecuzione dello sketch e va aperto quando c’è da fare l’upload di uno sketch modificato. Mi raccomando, poiché con i due PIN cortocircuitati l’upload del codice dà errore e non funziona. Il Deep-Sleep fa risparmiare molta corrente, l’ESP quando è “dormiente” consuma pochi micro ampère  e quando viene risvegliato riesegue da capo lo sketch comprensivo della funzione setup(). Il che significa ovviamente che si riconnetterà di nuovo al wi-fi dopo esserne uscito per “addormentarsi”.

La mia Stazione è ormai da circa 24 ore in questa condizione di funzionamento e non ho rilevato comportamenti anomali o scorretti da parte del modulo.

Per quanto riguarda le librerie esterne, sono le stesse che ho già indicato in post precedenti relative agli stessi sensori. Adafruit per quanto riguarda i sensori DHT22 e TSL2561 e la SFE_BMP180 per il sensore barometrico.

Ecco quindi lo sketch che pilota il tutto:

Sostituire i valori della propria LAN nelle rispettive righe:

const char* ssid = “**********************”;
const char* password = “******************”;

nonché l’indirizzo IP del server HTTP:

String url = “http://192.168.3.100/insert_meteo.php?”;

e il nome del file php che si occupa della ricezione, che io ho chiamato “inserti_meteo.php”

La gestione del modo Deep-Sleep avviene in pratica sostituendo la classica delay() con questo codice:

uint32_t sleepTimeSec = 300;  // 300 secondi, ovvero 5 minuti
uint32_t sleep = (sleepTimeSec * 1000000);

ESP.deepSleep(sleep, RF_DEFAULT);

Trascorso il tempo indicato il modulo effettuerà un wake-up, in pratica un SOFT RESET, che NON rimetterà in esecuzione il codice dal punto in cui lo abbiamo lasciato, ma procederà ad una riesecuzione da capo della funzione setup() e poi loop().

Sensore Adafruit TSL2561 – Letture di luce direttamente in Lux

tsl2561_1

Stimolato dal fatto che alle schede ESP8266 non stanno proprio simpatici i sensori di luce analogici ho ricercato qualcosa di digitale in grado di svolgere lo stesso compito, magari dotato di una libreria in grado di fornire i valori di uscita già calibrati in Lux senza dover giocherellare con formule variabili da modello a modello di fotoresistore. Ho trovato quindi questo TSL2561, prodotto dalla NewYorkese Adafruit, che ovviamente offre come valore aggiunto rispetto ad un fotoresistore del tipo GL5539 (di cui comunque ne ho una bustina piena) la lettura direttamente in Lux sulla banda del visibile, sull’infrarosso e su una banda più estesa definita “broadband”. Secondo fonte Adafruit inoltre la precisione dovrebbe essere migliore di un sensore fotografico CdS. In poche parole potremmo costruirci attorno un buon luxmetro o eventualmente un esposimetro.

Stiamo parlando di un sensore del costo di circa 6-7$; è chiaro che con la stessa cifra si possono acquistare non meno di una sessantina di GL5539, ma se vogliamo la qualità Adafruit e questo tipo di accuratezza nelle letture mi pare che siamo ancora a cifre accettabili. Poi ovviamente si può scegliere di usare uno o l’altro in base al contesto che ci interessa.

Informazioni molto dettagliate sull’impiego di questo sensore posso essere trovate sul sito Adafruit a questi indirizzi:

https://learn.adafruit.com/tsl2561/overview

https://www.adafruit.com/datasheets/TSL2561.pdf

Le librerie da scaricare sono due: una generica in comune ai sensori Adafruit ed una specifica per il TSL2561. Ho provato lo sketch di esempio anche su ESP8266 (con le dovute modifiche) e ha funzionato correttamente. Vengono prodotti dei warnings in compilazione la prima volta ma poi spariscono del tutto nelle compilazioni successive. Ricordarsi di definire nella Wire.begin i due pin associati al colloquio I2C, a differenza degli Arduino. Questo sensore è dotato poi di un pin “address” che permette di definire 3 indirizzi I2C (scollegato, a massa, a +Vcc) quindi può convivere tranquillamente con altri sensori che sfruttano lo stesso bus.

Per comodità riporto lo sketch di test Adafruit per Arduino leggermente modificato così da mostrare tutte e 3 le letture insieme e con un refuso corretto riguardante il metodo getLuminosity che nell’originale non funziona. Come si può vedere c’è una funzione configureSensor() che permette di regolare la sensibilità e la precisione del sensore, altra cosa che può rivelarsi utile.

 

SKETCH DI TEST:

Arduino – KY037 Trigger Sonoro

KY037

Identificato dal codice Keyes KY037 questo sensore ibrido (dotato di uscita sia analogica che digitale) dovrebbe attivarsi in presenza di un transiente sonoro, ovvero un battito secco delle mani, o un qualsiasi rumore improvviso nelle vicinanze del piccolo microfono a condensatore di cui è dotato. Come non pensare di usarlo per accendere e spegnere ad esempio la luce di una stanza battendo semplicemente le mani o emettendo un do di petto alla Pavarotti per stupire le persone che ci sono venute a trovare a casa? Mah, io non lo farei, almeno con questo tipo di sensore. Il rischio della figuraccia sta in agguato e probabilmente saremo costretti a battere le mani due o tre volte o cantare un’intera aria del Rigoletto. Insomma, sarà la qualità non eccelsa del microfono, sarà che regolare correttamente la soglia è un’operazione molto delicata, ho notato che svariate volte “fa cilecca”.

Innanzitutto bisogna dire che va calibrato: il led di sinistra, così come si vede in figura, è il led che segnala l’attivazione sonora del sensore (Trigger Led) e appena collegato e alimentato deve risultare spento. Il mio ad esempio mi è arrivato con questo led perennemente acceso, il che significa che bisogna girare la piccola vite del potenziometro di colore blu in senso antiorario, fino a che il led non si spegne. In questo momento siamo giunti nel punto di massima sensibilità del sensore. Girando ulteriormente la vite verso sinistra abbassiamo la sensibilità di intervento. Conviene fare questa calibrazione mentre è in esecuzione lo sketch di prova che indico sotto.

Io devo dire che mi sono fermato più o meno nella zona di calibrazione al confine tra led spento – led acceso. Fatto questo ho fatto le prove sonore del caso battendo le mani, usando la voce e via dicendo. Beh, che cosa devo dire? Chi vuole faccia questa prova e giudichi se è il caso di considerare affidabile questo piccolo sensore o no…..

I collegamenti: conviene per queste prove collegare sia l’uscita digitale che analogica, per rendersi conto di come funzionano entrambe le uscite.

 

SKETCH DI PROVA:

AGGIORNAMENTO

Ho fatto delle ulteriori prove anche con il KY038, sensore molto simile a questo ma dotato di un microfono più piccolo.

Schermata 2015-10-23 alle 02.23.04

Viene definito meno sensibile del KY037 ma ammesso che sia vero mi sembra che la differenza tra i due sensori non sia eclatante. Dopo aver provveduto anche in questo caso a regolare il trimmer nel punto limite di spegnimento del Trimmer Led in presenza di silenzio ed essendomi venuto un dubbio, ho provveduto a togliere tutto il superfluo dalla routine di lettura presente nella funzione loop() e ho notato un certo aumento di sensibilità, direi quasi accettabile se si considera comunque che per accendere ad esempio con un battito di mani le luci di una stanza bisogna avvicinarsi al sensore, diciamo entro un metro. La conclusione è quindi che il sensore ha bisogno di un codice velocissimo, capace di intercettare il transiente sonoro nell’attimo infinitesimale in cui il pin del segnale “sale” a livello logico 1. Basta qualche istruzione in più, una analogRead() o anche un paio di Serial.print di troppo e possiamo perdere l’attimo fuggente. Qui sotto una versione della funzione loop() molto più reattiva, nella quale però va messo dopo l’attivazione del sensore un delay per annullare dei rimbalzi di segnale che ogni tanto ci sono.

Arduino – Sensore HC SR501

pir01

Eccolo qua. Non si può pensare di progettare un sistema antifurto con Arduino senza avere a che fare con uno di questi sensori cosiddetti PIR (Passive Infra-Red). Funziona ad infrarossi, e intercetta qualsiasi movimento, grazie alla lente di Fresnel plastica che si vede in figura, con un raggio di circa 120 gradi rispetto l’asse frontale. Ha un range di distanza massima che va dai 3 ai 7 metri, regolabile. Dato l’alto segnale di uscita sembra si possa anche posizionare ad una certa distanza da Arduino, se le esigenze di collocamento lo richiedono (ad esempio sul soffitto, lontano da prese di corrente, ecc.).

Digitale, alimentabile a 5V. Non indispensabile, ma io consiglio di utilizzarla per stabilizzare il segnale, una resistenza di pull-down (cioè tra pin di uscita e massa) di 10Kohm.

pir02

La circuiteria come si vede dal retro della basetta è più complessa del solito per un sensore di questa classe e sono presenti due trimmer di regolazione. Guardando la figura il primo a sinistra regola l’isteresi della lettura, ovvero il tempo in cui il pin del segnale rimarrà nello stato HIGH. In genere viene posizionato sul minimo (circa 3 secondi) e se ruotato alla posizione opposta si ottiene un delay di circa 300 secondi. Il trimmer di destra invece regola la distanza massima di intervento del sensore, che va da circa 3 metri a 7 metri.

Pilotarlo è semplicissimo e non necessita di alcuna libreria esterna. Ecco uno sketch di esempio:

Arduino – Sensore barometrico BMP180

20150918_102833

Eccolo qui, il classico sensore di pressione atmosferica. Me ne sono arrivati una coppia, di cui purtroppo uno non funzionante. Generalmente vengono venduti con la strip dei contatti non ancora saldata al sensore, quindi bisogna provvedere da sé alle saldature. Era l’anello mancante alla Stazione Meteo che sto realizzando e di cui parlerò in seguito; effettua una lettura della pressione barometrica e della temperatura e poi calcola in libreria anche la stima dell’altezza sul livello del mare.

Utilizza i pin seriali analogici I2C, quindi richiede la libreria Wire di Arduino (già disponibile nella IDE ufficiale) e una ulteriore libreria esterna specifica del sensore. Ne esistono diverse, ed io andando in giro ne ho scaricata una all’indirizzo http://www.adrirobot.it/sensori/sensore_pressione_BMP180/bmp180.zip, ottimo sito tra l’altro. Volendo si possono utilizzare anche quelle Adafruit o Sparkfun, insomma chi più ne ha più ne metta.

Riguardo l’alimentazione del sensore bisogna stare molto attenti: il datasheet Bosch dice chiaramente che si tratta di un sensore da alimentare a 3.3V. La versione in mio possesso sembra avere un regolatore di tensione per alimentarlo a 5V, ma non mi sono fidato comunque ed ho perciò utilizzato per alimentarlo il pin marcato come 3.3 collegandolo appunto ai 3.3 Volts di Arduino. Forse sono stato eccessivamente prudente, ma dal momento che già uno dei due mi è arrivato non funzionante non volevo rischiare nemmeno lontanamente di mettere fuori uso quello buono.

Ecco i collegamenti ad Arduino ( i colori sono una mia convenzione):

I pin SCL e SDA sono le 2 connessioni I2C. Le due entrate analogiche utilizzate non vengono definite all’interno dello sketch come in altri casi quindi vanno utilizzate necessariamente quelle (A4 e A5). Devo dire che il sensore è stabilissimo (con Arduino, sui Raspberry non ho verificato) e non ha mai fallito letture anche dopo parecchio tempo di utilizzo continuo. Inoltre mi pare vada a regime in tempi molto brevi, qualche minuto al massimo.

Ho cercato di impostare lo sketch come funzione separata di lettura, questo facilita l’inserimento del codice in ambiti multisensore.

SKETCH DI ESEMPIO: