You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: