tempo ciclo lettura sensore DHT22

Qualcuno ha già provato a misurare quanto impiega un ciclo interessato dalla lettura di umidità e temperatura di un sensore DHT22?

Sto monitorando la cosa e pare che per leggere, calcolare e buttar fuori su seriale il valore ci vogliano circa 273ms.
E' un valore congruo oppure c'è qualcosa che non quadra?

Lo chiedo perché per il DS18B20 c'è parecchia documentazione e una lettura a 10bit impiega 750ms (tempo per la conversione). Tale stop è però eliminabile (chiedo la temperatura, arduino continua a lavorare mentre viene eseguita la conversione e poi mi prendo il dato).
Per i DHT non ho trovato nulla, solo il fatto di aspettare almeno 2 secondi tra una misura e l'altra.
La cosa non è bloccante per me, era solo per capire se si può ottimizzare la lettura DHT22.

Grazie

Secondo me è un valore congruo tenendo conto che c'è un ciclo di lettura umidità e temperatura, una conversione in digitale ed una trasmissione.

Qui puoi vedere il DATA SHEET con la spiegazione.

Ciao, grazie per la risposta.
Ieri, ho spulciato in rete ed avevo effettivamente trovato un datasheet (non completo come quello da te messo in link) dove appunto erano rappresentati i tempi di trasmissione/calcolo... ed i miei tempi corrispondevano appunto a quanto scritto.

Ora vedo se la libreria permette la richiesta dei dati e la prosecuzione del codice come per i sensori DS18B20 (waitforconversion = false) in modo da rallentare il meno possibile il loop.

Grazie ancora!

Ho dato un occhio al datasheet e i tempi sono espressi in micro secondi, non in millisecondi, ho letto male?
Quindi una lettura dovrebbe metterci:

1mS start signal
80+80uS sensor response signal
50+70uS per bit (x 40) considerando tutti 1 che richiede più tempo.
Totale massimo circa 6mS

Durante lo start signal il sensore prepara i dati da trasmettere.
Non dovrebbero esserci altri tempi nel mezzo.
Ho letto male?

Infatti il problema in realtà NON è nel tempo che si impiega a leggere, la lettura è piuttosto veloce ed i tempi chiaramente indicati in fig.6 di pag.6, ma che tra una lettura e la successiva DEVONO passare almeno due secondi (punto 4. in fondo a pag.3) altrimenti i dati non sono validi.

Guglielmo

Si’ concordo
però la libreria ha gia’ una sorta di gestione di questo
se due letture consecutive sono distanti meno di 2 secondi la libreria restituisce subito il valore “vecchio”
semmai il problema è che se due letture consecutive sono distanti piu’ di due secondi la lettura (vera, non l’eco della vecchia) ha un dei ritardi significativi, tra i quali un bel delay(250), che da solo fa un qurto di secondo…
bisogna vedere se allo OP questo sta bene
altrimenti la vedo dura, mi sa che servirebbe implementare una macchina a stati finiti dentro alla libreria

questa non l'ho capita.
Se mi preoccupo io di attendere i 2 secondi richiesti che problema c'è?
La libreria aggiunge comunque il delay?
Non ho guardato la libreria ma sarebbe un po' assurdo.
Il sensore è veloce ma la libreria è veloce solo se non rispetti le tempistiche del sensore?
Cioè il dato buono te lo da lento quello non aggiornato te lo da subito?
Ho capito bene?
Mi sfugge il motivo di questa scelta e della necessità della macchina a stati finiti che hai ipotizzato.

maubarzi:
La libreria aggiunge comunque il delay?

Cioè il dato buono te lo da lento quello non aggiornato te lo da subito?
Ho capito bene?
Mi sfugge il motivo di questa scelta e della necessità della macchina a stati finiti che hai ipotizzato.

esatto, bravo....
Il dato non aggiornato te lo da subito perche non deve andare a leggerlo sul sensore
Dopo 2 secondi considera quel dato vecchio, e quindi andrà a leggerne uno nuovo, con una funzione farcita di delay
Se riesci a riscrivere la libreria gestendo i tempi di attesa senza essere bloccante e senza usare una macchina a stato finiti mostramelo, che imparo qualcosa (e non sto scherzando)

… ma di che libreria e di che versione state parlando? la DHT.cpp (versione 1.3.2 di Adafruit) contiene alcuni deleyMicroseconds() e un delay da 20 msec (solo per DHT11) … non vedo nulla di più ::slight_smile:

Guglielmo

DHT.cpp (9.11 KB)

Domani da casa controllo che versione
Sicuro una usata da qualche utente qui sul forum, che cercava aiuto, io non uso quei sensori, quindi ho installato la libreria che usava qualcuno, per aiutarlo

Eccomi, sono io che ho chiesto consigli/aiuto.
Non ho visto la libreria, ma posso affermare che lo sketch con miei 270ms circa per il loop con DHT22 viene compilato con libreria DHT sensor library by Adafruit versione 1.2.3
Utilizzando librerie più recenti (ad esempio l'ultima 1.3.2) viene richiesta una libreria supplementare (se non erro la Adafruit Unified Sensor Library).

Proverò questa ultima versione per verificare se il tutto gira più velocemente.

Standardoil:
Se riesci a riscrivere la libreria gestendo i tempi di attesa senza essere bloccante e senza usare una macchina a stato finiti mostramelo, che imparo qualcosa (e non sto scherzando)

Senza riscrivere librerie alla prima folata di vento, basta adeguare eventuali delay al timing del sensore che al massimo arriva a 6mS come calcolato prima, sempre se non ho interpretato male il datasheet.
Quindi i 250mS proprio non li capisco.

Ora 6mS di attesa è decisamente più tollerabile di 250mS o addirittura 750mS che ho sentito da qualche parte.

750 sono per il ds18b20
Che ha comunque il modo asincrono...

maubarzi:
Ora 6mS di attesa è decisamente più tollerabile di 250mS o addirittura 750mS che ho sentito da qualche parte.

... basta usare le librerie aggiornate :smiley:

I 750msec che hai letto, sono per un altro sensore in cui, in fumzione della risoluzione che vuoi, aumenta il tempo di conversione, sino ad arrivare, per una risoluzione a 12 bit, a 750 msec. Ma se lo usi a risoluzioni inferiori il tempo scende drasticamente :wink:

Guglielmo

Si, appunto, non dovrebbe mai essere un problema.
Il sensore può metterci il tempo che vuole a fare le sue letture, ma quando interrogato deve poter rispondermi istantaneamente, cioè nel solo tempo di comunicazione al massimo.
Poi che abbia altre modalità più lente non è un problema basta che ci sia quella rapida, cioè la modalità asincrona ad es.
Se non è così c'è un problema da qualche parte, magari semplicemente di libreria non ottmizzata.

Rieccomi nuovamente.
Premetto che mi scuso se ho tirato fuori questo casino e grazie a tutti coloro che hanno dato il contributo.
Come dice il buon gpb01 "... basta usare le librerie aggiornate :D"

Ho ricompilato lo sketch con l'ultima versione della libreria (1.3.2) ed ovviamente aggiungendo quella ulteriore richiesta (Adafruit Unified Sensor Library) e "magicamente" il loop ora gira sui 5ms (considerate che vengono effettiate altre operazioni, prima ero a 273ms):

Temperatura Esterna: 6.50
Umidita Esterna: 66.20
Durata del ciclo loop board1: 4628us

Ancora grazie!