Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why delays cannot be used with DHT_nonblocking #10

Open
toranlo opened this issue Mar 1, 2022 · 0 comments
Open

Why delays cannot be used with DHT_nonblocking #10

toranlo opened this issue Mar 1, 2022 · 0 comments

Comments

@toranlo
Copy link

toranlo commented Mar 1, 2022

Hi,
I have been taking a look at the DHT_nonblocking code and in particular I have
made some tests with the state machine and it seems to me that it should work
with any delay in the external loop() function, the state machine does not need
to be called continuously, may be periods of delay between a call and another
one. The problem why it is not working is due to the sensor not to the state machine.
I have used a DHT11 and to start the reading of the sensor it is needed to pull
down the line (LOW level) for, according to the AOSONG data sheet, a minimum of
18mS, but it does not specify a maximum time.
In the state machine this time is set to 20mS and is done in the code:
case DHT_DO_READING: /* Wait for 20 ms. */ if( millis( ) - dht_timestamp > 20 ) { dht_timestamp = millis( ); dht_state = DHT_COOLDOWN; status = read_data( ); // if( status != true ) // { // Serial.println( "Reading failed" ); // } } break;
If the state machine is called continuously it guarantees that the pulldown
time, that I called Tstart, is 20ms, but if there is any delay in the loop()
function this time is increased, due to the design of the state machine, and
the function dht_sensor.measure() fails.
I have made some tests changing the value 20, in the previous code, to others
different than 20. Increasing it up to 30mS the sensor responds correctly
(analyzing it with an oscilloscope), if the number is set to 31 the sensor
responds sometimes and sometimes does not, and if change it to 32 or upper the
sensor does not respond at all. The sensor is not working according to the
specs because in the data sheet does no specifies a maximum value for the
Tstart.
So when some delay is added in the loop() function it is added to the 20mS of
the state machine and when the effective Tstart is greater than 32 ms the
sensor does not respond. With a delay in the main loop() of 10mS the function
works well, with a delay of 20ms or greater the function does not work anymore.
Therefore after this research I think that the problem of the delay in the
loop() function is not due to the state machine itself, that is well designed
and works even when it is not called continuously, but it is caused by a bad
working of the sensor that is not satisfying the specs in the data sheet.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant