Archivi tag: keysight

Esp8266 – Low Power (parte 2)

Come promesso nel precedente articolo, ho fatto qualche (decina) di prove per cercare di ottimizzare il funzionamento del sistema ed essere sempre più parco nelle richieste energetiche.
Lo sketch di partenza è quello che ha funzionato nei precedenti tests, molto “quick and dirty” con notevoli margini di ottimizzazione.
I parametri principali rilevati sono stati:
– Corrente media: 53,3 mA
– Corrente massima: 272,1 mA
– Energia 177 uA/h

Sketch versione 1

Il primo passo di ottimizzazione ha previsto una ridefinizione del delay imposto prima della attivazione del sensore DHT. Ho fatto diverse prove ed ho trovato che 1,7s consente una ottima ripetibilità delle misure. Inoltre ho epurato alcune funzioni che erano “eccessive”. Il risultato è stato molto incoraggiante:
I parametri principali rilevati sono stati:
– Corrente media: 39,6 mA
– Corrente massima: 242,1 mA
– Energia 132 uA/h
Non male!

Sketch versione 2

Per l’ultimo test ho rimosso anche tutti i “serialprint” che avevo inserito per monitorare il funzionamento del sistema. Vero che non sono molto “costosi” in termini energetici, ma richiedono tempo per essere eseguiti. Ed il tempo è energia, soprattutto se sono usati durante il periodo di connessione di ESP.
I parametri principali rilevati sono stati:
– Corrente media: 39,5 mA
– Corrente massima: 248,4 mA
– Energia 131,8 uA/h
Visti i risultati li avrei potuti anche lasciare!

Sketch versione 3 – Minimale

Rimangono da risolvere due interrogativi:
– cosa succede inserendo il codice per la gestione di MQTT;
– quanto incide la presenza di una sensore di luminosità.

L’introduzione del codice relativo ad MQTT non ha effetti apprezzabili sul funzionamento del sistema. In fondo si tratta di un paio di funzioni che non hanno altro effetto se non quello di trasmettere qualche frame aggiuntivo alla fine dello sketch. Se la comunicazione si mantiene a rate elevato, l’impatto “energetico” è davvero modesto.

Aggiunta del codice MQTT

Con queste figure, faccio un rapido conto (nella speranza che sia giusto, altrimenti, accetto critiche e correzioni che siano sensate): 0.130 uA/h sono l’energia di un singolo processo di acquisizione e notifica. Ne vorrei eseguire 6 in un’ora, con un assorbimento di 7.8mA/h. Se ipotizzo una batteria da 1500mA, vengono fuori circa 8 giorni di funzionamento (sono ben 11520 cicli di acquisizione). Non ci siamo.

NB: ho chiesto di commentare ma i commenti sono disabilitati. Non sono impazzito, basta mandarmi una mail o un WA. Non ne posso più di pubblicità di farmaci e di cancellare spam dal mio blog.

Esp8266 – LowPower

Da qualche tempo mi sono fissato per rispondere ad una sfida: realizzare un sensore di umidità, temperatura che sia alimentato a batteria, Wifi e che mi garantisca una grande durata dell’accumulatore.
Lavorare in “low-power” è interessante in quanto impone di rinunciare a “tutto il possibile”, per potere contenere il consumo di energia del sistema. Inoltre impone di lavorare con dispositivi che supportino una modalità di “deep-sleep” e che non richiedano il bacio di un principe per essere risvegliati.
Visto che tutti i miei progetti sono basati su ESP8266 e che ne ho ancora “diversi” nel cassetto, ho voluto provare con questo micro. Le informazioni di partenza per questa avventura le ho prese da questo sito, davvero chiaro.

Il prototipo lo ho costruito attorno al sistema di sviluppo basato su “breadboard” che avevo realizzato (troppi) ani fa. Qualche falso contatto da ripristinare, qualche integrato da rimuovere ma alla fine ha funzionato tutto. Ho iniziato con qualche sketch base, per riprendere mano e per fare dei test con i singoli componenti poi mi sono concentrato su alcuni aspetti specifici:
– quanto influisce il metodo di assegnazione dell’IP sul consumo?
– quanto influisce la presenza di un sensore di temperatura sul consumo?

Assegnazione degli IP e consumo.
Il processo di assegnazione di un IP ad un dispositivo IoT può avvenire in due modi: statico o tramite DHCP. Nel primo caso è necessario interagire e configurare ogni dispositivo a mano, possibilmente tenendo traccia degli indirizzi usati.
Nel secondo caso ci pensa un protocollo a configurare l’indirizzo IP, sfruttando un paradigma client server e lo scambio di 4 messaggi.
Per fare questa valutazione mi sono avvalso di un “DC Power Analyzer”, Keysight N6705B, equipaggiato con un cassetto N6762A (opzione 2uA) e N6752A. In pratica è un alimentatore da banco regolabile, estremamente preciso e controllabile da remoto, con funzioni integrate di oscilloscopio e data logger. Un bel giocattolo.
Ho compilato due sketch, uno con assegnazione statica ed uno con assegnazione dinamica dell’IP ed ho effettuato un test della durata di pochi minuti, a parità di condizioni di connessione e parametri di alimentazione.

Test con assegnazione STATICA
Lo sketch prevede la connessione all’AP, una operazione di controllo della validità della connessione, la lettura dell’ADC ed il deep sleep per 10 secondi.
Test eseguito su 5 minuti e 30 secondi, avviando il data logger e partendo dalla condizione di “sensore spento”. Il funzionamento del dispositivo è monitorato attraverso la porta seriale (file datalogdata22.edlg).

Esp8266 – No DHCP Verticale: 50mA div

La figura mostra un blocco di esecuzione del codice. Connessione, lettura del valore e spegnimento in deep-sleep del dipositivo. La maggiore parte del consumo è imputabile alla trasmissione WiFi che, anche se in modo impulsivo, richiede parecchia corrente. Le operazioni di connessione sono evidenziate dalla figura seguente, uno zoom della immagine precedente.

ESP8266 – No DHCP

Lasciando al programma della Keysight la “briga” di analizzare 5 minuti di segnale acquisito, si ottengono i seguenti parametri:
– corrente media 26,5 mA
– corrente massima 271 mA
– Energia: 2,2 mA/h
Un singolo “blocco” di esecuzione (6 secondi) richiede 98,131 uA/h per l’esecuzione.

Test con assegnazione tramite DHCP.
In questa serie di test è stato compilato uno sketch che ha le medesime funzioni del precedente ma che non prevede assegnazione statica degli indirizzi IP. Il sistema è stato analizzato in modo analogo al caso precedente (file datalogdata24.edlg). La forma d’onda del singolo trasferimento è del tutto analoga a quella vista nel caso di assegnazione manuale dell’indirizzo IP.

ESP8266 – DHCP

Lo stesso si può dire per lo zoom delle fasi iniziali della connessione, come mostrato nella figura successiva.

ESP8266 – Connessione

Analizzando il solito “blocco” di 5 minuti si ottengono i seguenti valori:
– corrente media 7,2 mA (dipende da quanti run sono stati catturati)
– corrente massima 286 mA
– Energia: 598 uA/h
Un singolo “blocco” di esecuzione (6 secondi) richiede 98,602 uA/h per l’esecuzione.

Il DHCP non ha effetto? Beh, il suo effetto non è evidente. Lo scambio di messaggi previsto dal protocollo DHCP è molto rapido, in quanto l’AP che sto usando è “scarico” (solo 5 client connessi), è molto vicino e consente al dispositivo di connettersi con un rate elevato, cosa che minimizza l’impatto dello scambio di frames dedicati al DHCP. Inoltre il traffico del DHCP è caratterizzato dal trasferimento di pochi dati, visto che è un protocollo “lightweight”, pertanto il suo effetto è pressoché trascurabile. Questo risultato è un vero sollievo in quanto nelle applicazioni IoT, potere contare sul DHCP è una vera “manna dal cielo”.

Il sensore DHT22
Uno dei sensori più usati in ambito hobbistico. Semplice da collegare, non presenta tutte le idiosincrasie di altri che usano I2C ed è solo moderatamente “energivoro”. Ha un tempo minimo di campionamento di 2 secondi e assorbe massimo 2mA in fase di misura.
Per poterne apprezzare l’impatto sul mio sistema, ho sviluppato un nuovo sketch che preveda l’uso di DHCP e che esegua le seguenti funzioni:
– controllo di connessione WiFi;
– accensione del DHT22 tramite pin del micro ESP8266;
– lettura del valore di ADC;
– lettura dei valori di temperatura ed umidità;
– spegnimento in deepsleep (10 secondi);
(file datalogdata25.edlg ).

ESP8266 con sensore DHT22.

Analizzando il solito “blocco” di 5 minuti si ottengono i seguenti valori:
– corrente media 34,1 mA (dipende da quanti run sono stati catturati)
– corrente massima 295 mA
– Energia: 2,8 mA/h
Un singolo “blocco” di esecuzione (6 secondi) richiede 98,602 uA/h per l’esecuzione.

Sketch “verosimile”
Acquisire dei dati di temperatura ed umidità con tale frequenza è davvero eccessivo. Ho aumentato la durata del deep-sleep a 60 secondi, in modo da campionare ogni minuto.

ESP8266 – Campionamento ogni minuto

Analizziamo l’intera “ora” di acquisizione (file datalogdata27.edlg): quanto costa in termini energetici?
– corrente media 9,8 mA (dipende da quanti run sono stati catturati)
– corrente massima 295 mA
– Energia: 9,8 mA/h
Con una batteria da 1500mA/h, possiamo fare circa 6 giorni, al netto della autoscarica.
Pochissimo! Occorre ottimizzare:
– ridurre il tempo di esecuzione dello sketch, “limando” al minimo i delay per l’attivazione del sensore DHT;
– ridurre la potenza di trasmissione del modulo WiFi, tanto siamo in ambiente domestico;
Non ritengo molto conveniente cambiare il sensore che “pesa” 1.5mA, a fronte del costo della trasmissione del messaggio. Nella seconda parte del post, ulteriori misure dopo avere fatto qualche esperimento di temporizzazione

KeySight

Puntuale come l’affito anche quest’anno è arrivata la possibilità di partecipare ad un seminario della KeySight  (altro non è che la divisione strumenti, misura ed elettronica della buona vecchia Agilent). Stavolta il seminario si è tenuto al Museo Della Scienza e Tecnologia a Milano con argomento riguardante i sistemi di misura ad RF e microonde.

I contenuti del seminario sono sempre di altissimo livello, quest’anno impreziositi dalla presenza di un intervento dal taglio accademico del Dott. Mario Caironi (IIT) e relativo alle possibilità offerte dai materiali organici per la realizzazione di circuiti stampati e componenti elettronici (CMOS). Si trova qualche informazione qui e qui.

Dal punto di vista della strumentazione sono rimasto molto colpito dal nuovo analizzatore di spettro della serie UXA, con uno schermo grosso come un televisore e touch. Magnifico davvero, soprattutto per le innovazioni che introduce: nuovo funzionamento del sistema di sweep, che adesso compensa automaticamente la distorsione introdotta dal filtro RBW in modo da minimizzare sempre il tempo di scansione. Nuovi anche i mixer esterni, adesso USB-powered e con un solo cavo di collegamento allo strumento. Nuove le funzioni di low noise, con baypass di alcuni stadi per ottimizzare il rumore alla ricerca dei segnali con più basso S/N. Soprattutto nuovo l’oscillatore: tutto in tecnologia DDS funzionante a più di 14 bit su un range vastissimo (7.4GS). Interessante la possibilità di lavorare con la FFT a blocchi di 510MHz.

IMG_20150505_162831 IMG_20150505_162825

IMG_20150505_162845

Impressionante è anche la parata di apparati che è stata messa in opera per dimostrare le potenzialità di generazione di segnali arbitrari. Alla base di tutto c’è il M9505A mainframe con cassetto M8190A. Si tratta di una unità in grado di generare un segnale in banda base con 12.5 GS/s asservito ad un calcolatore sul quale gira MatLab Il segnale viene dato in pasto ad un generatore modulabile (Vectro Signal Generator – E8267D)  che agisce da Upconverter fino a 44GHz. Il segnale modulato viene ricevuto da un analizzatore di spettro della famiglia PXA, il modello N9030A. Il segnale viene prelevato dalla IF ed inviato ad un Oscilloscopio della serie Infiinium (MSO-S 804A) che lo demodula in tempo reale in modo vettoriale. Impressionante vedere sullo schermo dell’oscilloscopio 6 sottosezioni in cui erano mostrati lo spettro in banda base, i simboli, il MER e tante altre informazioni. Ipnotico.

IMG_20150505_093701 IMG_20150505_093715

IMG_20150505_093728

Nel vedere il FieldFox mi si è slogata la mascella. Si tratta di un analizzatore portatile molto compatto e dal peso di 2kg. L’oggetto funziona come VNA (si… vettoriale) a due porte, TDR, Analizzatore di spettro con tracking generator e voltmentro selettivo. Il tutto fino a 26.5GHz in scioltezza. Il prezzo è di quelli che “fanno male” ma pensare che in uno strumento solo ci sia così tanta possibilità di misura è davvero imbarazzante. In pratica si potrebbe comperare solo quello per avere un mostriciattolo in grado di rimpiazzare la maggiore parte degli strumenti del laboratorio. Purtroppo no foto. L’emozione era troppa.

Appena entrato in sala faceva bella mostra di se un oscilloscopio digitale di quelli “TOP”, che visualizzava un segnale con una risoluzione temporale nell’ordine di 1ns (era un modello con 25GHz di banda). Il sistema era in demo per mostrare come sia possibile, attraverso opportuni algoritmi, compensare il comportamento dei cavi e dei connettori sia in ampiezza che in fase in modo da minizzare gli errori di misura e l’incertezza nella misura della ISI e del Jitter. In pratica i furbastri hanno integrato nell’oscilloscopio un generatore in grado di emettere un gradino estremamente ripido (<13ps) che eccita quindi uno spettro molto alto. Questo segnale viene immesso nel cavo da caratterizzare e consente di ricavare la funzione di trasferimento del sistema che verrà poi compensata attraverso FPGA. Non fa i miracoli, per caratterizzare a pieno una linea è sempre il VNA lo strumento vincente, ma in tutte quelle situazioni in cui il VNA non c’è o non è possibile usarlo… è possibile metterci una pezza molto efficace.

IMG_20150505_092441

Ultimo, ma non per importanza, il sistema di analisi della potenza per sistemi in corrente continua modello N6705B. Si tratta di un dispositivo modulare che può lavorare come source o sink di tensione e corrente continua ed è in grado di caratterizzare a pieno un dispositivo misurandone il consumo in potenza o in energia nel tempo. La cosa molto interessante di questo sistema è nella possibilita, attraveso un opportuno software, di potere effettuare il calcolo dell’energia fornita al sistema utilizzando una comoda piattaforma grafica. Costa un patrimonio, ma sarebbe davvero utile per i progetti che stiamo portando avanti.

IMG_20150505_111702

E’ tutto. Per questa volta.