Arduino – Controllare la tensione di funzionamento

Mi sono imbattuto in un articolo molto interessante, scritto circa 3 anni fa, dove si parlava della possibilità di leggere su Arduino via software la tensione di riferimento della scheda (teoricamente 5.0V) in modo tale da controllare la bontà del regolatore di tensione interno o dell’alimentatore esterno su porta USB e, cosa non meno utile, il calare della tensione applicata da una batteria esterna, in modo tale da prevedere la ricarica. Il link dell’articolo originale è riportato nello sketch qui sotto.

Io tra l’altro ho un Arduino Nano di fabbricazione cinese che a differenza degli altri non riusciva a mantenere eccitato un relè perché evidentemente difettoso e infatti sia il tester che questo sketch mi hanno confermato che un Vcc di 4.48 Volts è decisamente troppo basso per permettere il funzionamento corretto della scheda. Per cui questo è diventato praticamente il primo test a cui sottopongo ogni scheda appena comprata, soprattutto i piccoli Nano.

 

Stazione Meteo – Il Data Collector

Ecco l’ultimo anello della catena, il server UDP che raccoglie i dati inviati dalla Stazione Ricevente e li scrive su un database Mysql, residente, ma non necessariamente, sulla stessa macchina. In questo caso non sto parlando di un hardware specifico, potrebbe trattarsi di un qualsiasi Pc, Mac, o Server Linux dove sia installato l’interprete Python 2 e un Server MySql o MariaDB. Certo, deve rimanere acceso H24 ed è conveniente che sia una scheda a basso consumo come un Raspberry se vogliamo ospitarla a casa nostra.

Non voglio entrare nei particolari di gestione di un server MySql, perché richiederebbe un tutorial apposito piuttosto lungo ed articolato, per cui darò per scontato che chi si appresta a completare un progetto simile sia già a conoscenza delle procedure necessarie a gestirlo. Comunque per ricevere i dati che la Stazione Ricevente sta attualmente inviando ho provveduto a creare un database chiamato meteodb, un utente meteo, dotato di password e accessibile dal localhost in questo caso e un paio di tabelle di cui la prima, dati_meteo per la ricezione dei dati veri e propri, e la seconda, stazioni, per gestire un eventuale elenco di stazioni di trasmissione, ognuna associata ad un codice.

Script delle tabelle:

Codice Python del Server Udp:

Questo codice va salvato in un file chiamato ad esempio data_logger.py a cui vanno dati i permessi di esecuzione (chmod +x).

Infine può essere lanciato in backgound con un comando del tipo nohup python data_logger.py > dlg_stdout.log 2>dlg_error.log &

in modo tale che anche chiudendo il terminale da cui si è lanciata l’esecuzione il processo rimanga attivo in background.

Ecco un esempio di scrittura di alcune righe di dati sul database:

Schermata 2015-10-29 alle 20.32.23

Questi sono dati scritti ogni minuto, ma agendo sullo sketch del trasmettitore si può scegliere la cadenza di lettura in base alle proprie esigenze.

Arduino – Ethernet Shield e Dissipatore

shield01

Come ho già avuto modo di segnalare in precedenza, il chip principale dello shield ethernet per Arduino (W5100) scalda in maniera abbastanza considerevole, e se tenuto acceso H24 può

shield04

risultare conveniente aiutarlo a smaltire il calore in eccesso e quindi diminuire la probabilità di guasti tramite un piccolo radiatore passivo, di quelli che si usano per la cpu del Raspberry. Ho scelto lo stesso dissipatore in rame di cui ho parlato qualche post fa, e che pur essendo leggermente più grande del chip W5100 si adatta piuttosto bene ad essere utilizzato.

shield02

E’ dotato di una pasta termica ed adesiva per cui aderisce perfettamente alla superficie del chip.

20151027_025831

Stazione Meteo – L’unità ricevente

20151024_200515

L’unità ricevente della Stazione Meteo è costituita da un Arduino Uno R3 con montato uno shield Ethernet collegato alla lan domestica attraverso uno switch. Il  suo scopo è ricevere via radio i valori letti dalla Stazione Trasmittente per ritrasmetterli poi, via UDP ad un server MySql che li inserirà nel database. In aggiunta a questo all’Arduino Uno è collegato localmente un sensore DHT11 per rilevare temperatura e umidità nella stanza in cui si trova la scheda stessa.

20151024_223655

Una piccola complicazione è nata dal fatto che lo shield Ethernet e il ricevitore NRF24L01 utilizzano entrambi l’interfaccia SPI per comunicare con Arduino. Andando infatti a leggere la documentazione ufficiale su questo shield leggeremo che i pin 10,11,12 e 13 (50,51 e 52 nel caso di un Mega) sono usati per il colloquio tra shield ed Arduino, il che impedisce a questi pin di essere usati per l’I/O e causa possibili conflitti con altri moduli che utilizzano la SPI. In un primo momento, infatti, mantenendo sull’UNO gli stessi collegamenti usati dall’NRF24 nell’Arduino Nano, questo non funzionava. Per fortuna ho dovuto spostare solo il pin CSN dal 10 all’8 per far funzionare il modulo ricevente.

Un’altra considerazione riguarda la scelta di usare il colloquio tramite protocollo UDP nella LAN domestica. Il protocollo UDP è molto semplice da utilizzare: il client spedisce i suoi pacchetti sulla rete indirizzandoli al server che se è in ascolto li riceve, se per qualche motivo non ha avuto occasione di farlo la trasmissione va persa, senza alcun tipo di controllo. Oltre a questo va detto che a differenza del protocollo TCP, non esiste alcuna garanzia che i pacchetti arrivino nell’ordine giusto. Non spaventiamoci, tutto questo succede molto raramente, ma può succedere. Inoltre lo shield ethernet di Arduino prevede solamente il colloquio di tipo Unicast, ovvero il client può inviare pacchetti solamente ad un destinatario per volta, di cui conosce l’indirizzo IP e non permette l’invio di pacchetti a più destinatari contemporaneamente, ovvero in modalità Multicast.

Detto questo non escludo che in un prossimo futuro farò in modo che il server che ospita MySql sia in ascolto da un socket server TCP, sicuramente più affidabile. Dalle prove sul campo per ora il colloquio UDP non mi ha dato particolari problemi, per cui considero questo passaggio come una miglioria del software per la futura versione 2.0.

Sia l’Ethernet Shield che il server MySql ovviamente devono avere un indirizzo IP nell’ambito della nostra rete domestica, che verrà definito di tipo Statico. Nel mio caso allo Shield ho assegnato un IP 192.168.3.120 mentre la scheda Banana Pro dove risiede MySql ha indirizzo IP 192.168.3.102. Una particolarità dell’Ethernet Shield è che il produttore non ha provveduto a “marcarlo” con un MAC address univoco, come di solito si fa con gli apparati di rete, per cui all’interno dello shield ne inseriremo noi uno di comodo, in quanto comunque ogni scheda di rete deve presentarsi su un network con un MAC address, oltretutto univoco.

Una considerazione sullo shield ethernet: dovendolo tenere acceso H24 per questo progetto mi sono accorto che il chip principale della

20151025_100705

scheda scalda molto. Poggiandoci con cautela il dito sopra scotta talmente che non si resiste per più di un paio di secondi. Secondo la misura del mio “ditometro” direi quindi che raggiunge una temperatura di non meno di 50-55 gradi durante il suo funzionamento. Ho previsto quindi di applicare sopra al chip uno di quei piccoli dissipatori passivi che in genere si acquistano per i Raspberry, al fine di allungare la vita operativa dello shield.

 

I collegamenti:

Stazione Ricevente

 

Per quanto riguarda lo sketch, questo oltre a provvedere ai vari settaggi di rete, riceve il payload dalla Stazione Trasmittente, legge i dati del sensore DHT11, li aggiunge al payload ricevuto e invia il tutto al server UDP in ascolto.

 

SKETCH :

 

 

 

 

 

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.

Stazione Meteo – L’unità trasmittente

20150920_095055

L’unità incaricata di ospitare i sensori è attualmente funzionante anche se ancora ospitata su breadboard in attesa, alla fine del collaudo, di passare su scheda millefori. Ho scelto come scheda controller dei sensori l’Arduino Nano, piccolo, poco costoso (5-6 euro), dai bassi consumi e dotato di buone caratteristiche di connettività.

20151009_172728

La Stazione Trasmittente dovrà essere collocata all’aperto, e per quanto riguarda l’alimentazione a 5V del Nano sto testando con un certo successo alcuni Power Pack a ricarica solare generalmente dedicati ai telefoni cellulari e prodotti in Cina che, se tenuti costantemente alla luce solare durante il giorno, riescono a ricaricare ciò che il Nano e i sensori consumano in termini di corrente nell’arco delle 24 ore.

20151020_191748

Non sono richieste grosse capacità della batteria interna, anche una da 5000mA va più che bene, purché l’esposizione alla luce diurna della cella solare (in genere sono celle da 1.5W) riesca sempre a recuperare l’energia assorbita dalla Stazione Trasmittente.

Per la trasmissione dei dati letti dai sensori ho scelto un modulo molto economico ma piuttosto affidabile, l’NRF24L01. Si tratta di una trasmittente / ricevente a 2.4 GHz, funzionante tramite interfaccia SPI, capace di operare fino ad una velocità di 2 Mbps con un consumo estremamente basso. Il costo si aggira intorno ai 2 euro.

Schermata 2015-10-21 alle 15.00.45

Si trova in varie versioni, principalmente distinte dal fatto che abbia un antenna cablata sul circuito come pista di rame (vedi figura) o dotata di un’antenna esterna. Io ho utilizzato la prima versione e per distanze di svariati metri (anche con ostacoli del tipo pareti) non mi sta dando alcun problema. Qualora l’NRF24L01 desse qualche problema durante la trasmissione è consigliabile inserire un condensatore elettrolitico di capacità pari a 4.7 o 10 microfarad saldato tra i 2 pin di alimentazione del modulo, allo scopo di stabilizzare la linea dei 3.3 V dell’Arduino Nano che può presentare eccessivi residui di alternata (ripple) se alimentato con un alimentatore a 5V. Nel mio caso, usando un battery pack il problema non sussiste.

I componenti usati al momento quindi sono:

E questo è lo schema di collegamento:

Schermata 2015-09-20 alle 18.28.31

Come già accennato nel Post precedente, sto preventivando di aggiungere quantomeno un rilevatore di pioggia ai sensori esistenti, ma in futuro sarà possibile anche registrare dati su velocità e direzione del vento tramite un unità anemometrica esterna, collegata a questa o ad un’altra stazione trasmittente. La libreria standard del modulo NRF24L01 prevede fino a 6 trasmettitori su altrettanti canali diversi.

Infine lo sketch che si occupa di leggere i sensori e trasmettere il “payload” con il contenuto delle letture al ricevitore Arduino Uno. Utilizzo uno schema di trasmissione semplificato, senza controlli sull’avvenuta ricezione in quanto questi moduli NRF24L01 si sono dimostrati molto affidabili, ma è possibile gestire la trasmissione in maniera più sofisticata, se necessario.

Per il funzionamento dello sketch sono necessarie alcune librerie esterne da aggiungere alla IDE di Arduino.

 

Stazione Meteo – Il progetto

Stazione Meteo Finale.001

Ecco il mio progetto di Stazione Meteo nella sua prima attuale versione in corso di collaudo. E’ sostanzialmente costituita da un modulo trasmittente (ma possono essere più di uno, fino a sei) collocato all’aperto e utilizzante un Arduino Nano collegato ad una serie di sensori e ad una piccola scheda radio di tipo NRL24L01 in grado di trasmettere tutti i dati letti ad un Arduino Uno, dotato dello stesso modulo per la ricezione e con in più uno shield ethernet in grado di colloquiare con la rete domestica. Lo stesso Arduino è dotato di un altro sensore di temperatura e umidità che effettua una lettura dentro casa. Tutti questi dati vengono raccolti da un client UDP che li invia al corrispondente  server UDP che può essere collocato su un Raspberry (o altra macchina Linux) che provvederà a scrivere in tempo reale queste grandezze su di un database MySQL installato localmente.

Attualmente la stazione trasmittente legge informazioni all’esterno relative a Temperatura, Umidità, Pressione Atmosferica, Illuminazione. E’ possibile comunque aggiungere altri sensori per rilevare ad esempio la presenza di pioggia o neve, dati su velocità e direzione del vento ed eventualmente un pluviometro per la misurazione quantitativa della pioggia caduta. I margini di ampliamento sono piuttosto ampi (come prima aggiunta sto aspettando un sensore di pioggia) e il resto della catena andrà adeguata solamente in termini di software.

Senza contare che tutti i dati incamerati nel database presente all’interno del Raspberry possono a loro volta essere utilizzati da un sito web locale (realizzato in PHP ad esempio) o inviati ad un documento remoto del tipo Google Docs. Questa fase è ancora in corso di progettazione.

20150920_094948

Questo è il prototipo funzionante della Stazione Trasmittente, ancora su breadboard, che ho poi posto all’esterno (ben protetta) a raccogliere dati. Per l’alimentazione a 5V del circuito sto sperimentando uno di quei Power Pack a ricarica solare che si utilizzano per i telefoni cellulari (costo: 15 –  20 euro) che mi sembra ideale per questo tipo di situazione dal momento che sarà esposta alla luce del sole per tutta la giornata. Non appena terminata la fase di collaudo passerò tutti i componenti su di una scheda millefiori con cablaggi a saldare.

 

20150917_230641

Questo è il modulo ricevente interno costituito da un Arduino Uno + Ethernet Shield (entrambi SunFounder) che oltre ad occuparsi della ricezione dei segnali dalla Stazione Esterna ( o anche da più stazioni) mette a disposizione questi dati sulla rete domestica. Infine sulla scheda Raspberry o Banana Pro, come nel mio caso, dove sarà collocato il Server UDP in ascolto, gira il codice Python che si occupa anche della scrittura su database MySQL. Questa ultima macchina, se opportunamente configurata attraverso il router che accede all’esterno, potrebbe in teoria ricevere dati da altri collector dello stesso tipo situati geograficamente in qualsiasi locazione.

 

Schermata 2015-10-18 alle 14.23.06

Ed ecco come si presentano attualmente i dati su MySQL, letti in questa fase di collaudo ogni minuto per evidenziare qualsiasi tipo di problematica. Da sinistra verso destra ci sono il timestamp di deposito sul DB, temperatura e umidità interni, poi i dati esterni letti dal DHT22, dal BM180 e dal KY018.

Di seguito pubblicherò altri post con la descrizione dettagliata, schemi di collegamento e il codice per i vari moduli.

OS X El Capitan e la IDE di Arduino

Schermata 2015-10-06 alle 22.10.22

Avendo partecipato al Public Beta Test Program di Apple già sapevo che con l’avvento di OS X El Capitan la IDE di Arduino avrebbe smesso di funzionare, almeno per quello che riguarda i driver di emulazione USB-Seriale che servono per far comunicare il Pc con la scheda. Causa di tutto ciò è il nuovo meccanismo di System Integrity Protection implementato da Apple, che crea nuove restrizioni verso alcune zone del sistema (le directory /System, /sbin e /usr, tranne la /usr/local) anche ad utente elevato con privilegi da sudoer, come di solito si fa in OS X. Lo scopo di tutto questo è senz’altro nobile e condivisibile, aumenta la sicurezza del sistema in generale contro accessi indesiderati e possibili intrusioni di malware ma impedisce comunque il corretto funzionamento di alcune applicazioni realizzate in precedenza che andrebbero “reingegnerizzate” per funzionare con El Capitan.

Una delle vittime è proprio la IDE di Arduino per Mac: i driver FTDI e CHT che servivano per creare delle porte seriali virtuali dal bus USB dei Mac non funzionano più. Al momento attuale la soluzione consiste nel disabilitare questo meccanismo di protezione e adesso vedremo come, anche se io sarei contrario a fare una cosa del genere, non fosse altro perché abbassa il livello di sicurezza di OS X in generale. La mia soluzione temporanea comunque è stata quella di installare una macchina virtuale Linux Mint 17 sotto VMware 8 e usare e programmare da lì le mie schede Arduino. Tra l’altro sotto Linux non c’è bisogno di utilizzare driver aggiuntivi e l’unica accortezza è di aggiungere l’utente che utilizziamo abitualmente al gruppo secondario < dialout > per far sì che possa usare i device seriali-usb creati da Linux. Funziona perfettamente e per adesso preferisco lavorare in questa maniera.

Ad ogni modo per disabilitare la System Integrity Protection bisogna riavviare il Mac tenendo premuti i tasti Command + R finché non si sentirà il suono di avvio.  Saremo entrati quindi in Recovery Mode. Apriamo dal menu Utilities il  terminale e digitiamo:

e poi facciamo ripartire il sistema.

Dando il comando csrutil status avremo come messaggio:

Per ritornare eventualmente sui propri passi è sufficiente ripetere la procedura descritta e dare un comando

per ripristinare la situazione.

 

Per coloro che (come me) avessero gli Arduino Nano cinesi che necessitano dei driver CHT340 segnalo che ho dovuto reinstallarli e solo dopo un reboot del Mac mi sono trovato la seriale accessibile (l’ultima in basso nell’elenco).

Schermata 2015-10-11 alle 17.12.27

 

Ripeto: io preferisco, sperando che sia una situazione comunque temporanea, utilizzare una VM Linux che può essere creata anche scaricando gratuitamente VirtualBox, solo perché in ogni caso (o per deformazione professionale) dò priorità assoluta alla sicurezza del sistema.

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:

Spostamento server

Ho dovuto di nuovo spostare il sito su un altro server cambiando sistema operativo. Sono rimasto piuttosto perplesso nei confronti delle instabilità mostrate dalla Raspbian Wheezy sul Raspberry: prima ha cominciato a funzionare male la ZenCache poi addirittura a fronte dell’aggiornamento del Kernel alla versione 4.1 dopo poche ore il sito diventava irraggiungibile e addirittura il Raspberry non era più accessibile via SSH. Unica soluzione il reboot. La cosa brutta è che a differenza del primo caso i log di sistema non mi hanno permesso di ricostruire la natura del problema. Insomma, ora il blog gira su un Banana Pro dotato della stabilissima Bananian (kernel 3.4.108) e mi sembra che sia migliorato come velocità di accesso non fosse altro perché ora il server ha a disposizione una ethernet Gigabit ( e non fast-ethernet) e un “vero” hard disk collegato alla porta SATA. Ho provato un po’ di tutto su queste schede ma devo dire che l’accoppiata Banana Pi/Pro e Bananian 15.08 headless per questo tipo di attività non si batte.