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

"Sensor not ready," meaning #31

Closed
ghost opened this issue Sep 14, 2020 · 24 comments
Closed

"Sensor not ready," meaning #31

ghost opened this issue Sep 14, 2020 · 24 comments
Assignees

Comments

@ghost
Copy link

ghost commented Sep 14, 2020

Hi, I've been trying to get readings from a DHT11 sensor using the DHTNew library and am consistently running into a problem.

When trying the sketch dhtnew_test, the 0.2.0 version returns "Timeout_error", and the version 0.3.3 returns "Sensor not ready," from what I understood this means the sensor does not return fast enough for the code to get readings. I've used a 5.1k Ohms pull-up resistor (as the datasheet recommends), as the cables are less than 20 meters long (just a few cm long in fact). I've tried using both an analog and digital pin, the results are the same. The sensor is lit red though, so I assume it is correctly powered and grounded.

I don't know what may be going wrong or how to interpret this returned error, should I try to modify the code or is the problem coming from the connections ?

@RobTillaart
Copy link
Owner

Hi,
A few questions pop up:

  • which platform are you using? UNO / ESP etc? Some DHT sensors have trouble with 3.3 volt.
  • are there other devices connected?
  • have you tried upgrading to the latest version 0.3.3 ?
  • have you tried another lib to see if the sensor is OK e.g. one from Adafruit?

@ghost
Copy link
Author

ghost commented Sep 14, 2020

Hi, thanks for the quick reply.
Here are the details:

  • Platform : UNO
  • An LCD 16x2 screen is also connected
  • I did, the dhtnew_test sketch returns "Sensor not ready,"
  • The DHT library from Adafruit returns expected sensor values

@RobTillaart
Copy link
Owner

I'm quite busy this week and will try to recreate your problem.
How is the lcd connected? I2C or parallel?

@RobTillaart
Copy link
Owner

Did some testing with an DHT22 + UNO and got same problem.
Last issues were timing related on ESP32 so it seems I did too few regression tests.

Can you comment line 212 noInterrupts(); in dhtnew.cpp and give it a try?

int DHTNEW::_readSensor()
....
  // DISABLE INTERRUPTS when clock in the bits
  // noInterrupts();      

When I commented that line it worked better - dhtnew_endless.ino sketch -
However too much errors still on UNO so I need to check the timing constraints on those errors.

@RobTillaart
Copy link
Owner

RobTillaart commented Sep 22, 2020

Testing with UNO and DHT22 works well, 15500+ reads zero fails.

TIM	CNT	STAT	HUMI	TEMP	TIME	TYPE
15606676	15540	OK,	41.5,	23.6,	4,	22
15607677	15541	OK,	41.5,	23.6,	5272,	22
15608684	15542	OK,	41.5,	23.6,	12,	22
15609686	15543	OK,	41.5,	23.6,	5264,	22
15610693	15544	OK,	41.5,	23.6,	8,	22
15611695	15545	OK,	41.5,	23.6,	5268,	22
15612701	15546	OK,	41.5,	23.6,	8,	22
15613703	15547	OK,	41.6,	23.6,	5120,	22
15614710	15548	OK,	41.6,	23.6,	4,	22
15615712	15549	OK,	41.8,	23.6,	5228,	22

OK 	CRC 	TOA 	TOB 	TOC 	TOD 	SNR 	BS 	UNK
15549	0	0	0	0	0	0	0	0	

ESP32 with DHT22 runs now 8500+ reads with zero fails

TIM	CNT	STAT	HUMI	TEMP	TIME	TYPE
8710925	8690	OK,	40.9,	24.1,	2,	22
8711925	8691	OK,	41.0,	24.1,	5002,	22
8712930	8692	OK,	41.0,	24.1,	2,	22
8713930	8693	OK,	41.0,	24.1,	4996,	22
8714935	8694	OK,	41.0,	24.1,	2,	22
8715935	8695	OK,	41.0,	24.1,	5004,	22
8716940	8696	OK,	41.0,	24.1,	2,	22
8717940	8697	OK,	41.1,	24.1,	5100,	22
8718945	8698	OK,	41.1,	24.1,	2,	22
8719945	8699	OK,	41.2,	24.1,	5049,	22

OK 	CRC 	TOA 	TOB 	TOC 	TOD 	SNR 	BS 	UNK
8699	0	0	0	0	0	0	0	0	

Will start with DHT11 a.s.a.p.

@RobTillaart
Copy link
Owner

DHT11

image

Measured the timing of a DFrobotics DHT11 and the reaction time after the wake up delay is way beyond specification. I got times between 6000-10000 us instead of the 20-40 us mentioned above.

I patched the lib and started a test that will run for a few hours to see if other problems occur.

@RobTillaart
Copy link
Owner

ESP32 + DHT22

TIM	CNT	STAT	HUMI	TEMP	TIME	TYPE
65448152	65290	OK,	54.2,	20.6,	2,	22
65449152	65291	OK,	54.2,	20.6,	2,	22
65450152	65292	OK,	54.2,	20.6,	5150,	22
65451157	65293	OK,	54.2,	20.6,	2,	22
65452157	65294	OK,	54.2,	20.6,	2,	22
65453157	65295	OK,	54.2,	20.7,	5249,	22
65454162	65296	OK,	54.2,	20.7,	2,	22
65455162	65297	OK,	54.2,	20.7,	2,	22
65456162	65298	OK,	54.3,	20.7,	5151,	22
65457167	65299	OK,	54.3,	20.7,	2,	22

OK 	CRC 	TOA 	TOB 	TOC 	TOD 	SNR 	BS 	UNK
65299	0	0	0	0	0	0	0	0	

UNO + DHT11

TIM	CNT	STAT	HUMI	TEMP	TIME	TYPE
53681651	53290	OK,	36.0,	22.0,	4,	11
53682653	53291	OK,	36.0,	22.0,	11700,	11
53683666	53292	OK,	36.0,	22.0,	4,	11
53684668	53293	OK,	36.0,	22.0,	10604,	11
53685680	53294	OK,	36.0,	22.0,	8,	11
53686681	53295	OK,	36.0,	22.0,	11696,	11
53687695	53296	OK,	36.0,	22.0,	4,	11
53688696	53297	OK,	36.0,	22.0,	10660,	11
53689709	53298	OK,	36.0,	22.0,	16,	11
53690711	53299	OK,	36.0,	22.0,	10704,	11

OK 	CRC 	TOA 	TOB 	TOC 	TOD 	SNR 	BS 	UNK
53299	0	0	0	0	0	0	0	0	

Looks pretty stable now, will publish a new release today

Problems identified

  • noInterrupts blocked too long on AVR to keep timing of micros() correctly.
  • DHT11 does not behave according to the datasheet, it wait way longer before waking up.
  • A problem with wakeupDelay, in case type was not detected and setType was used.

RobTillaart added a commit that referenced this issue Sep 23, 2020
fix #31 DHT11 on AVR + refactor more strict timing
@cklam2
Copy link

cklam2 commented Jan 3, 2021

In case you're seeing this on an ESP8266:

Tried this library on an ESP-01 (=ESP8266), also received 'Sensor not ready' every now and then. First thought it was due to timing issues. Swapped out with another DHT-22, same issue. Then tried another DHT library that claims to be optimized for ESPs, same error. It only worked after disconnecting the VCC from the sensor, rebooting the ESP and then connect the VCC.

After a search it turns out that GPIO0, GPIO2 and GPIO15 from the ESP8266 do something special during boot time which seems to confuse the DHT sensor.

Changed pin to GPIO3 and haven't seen the issue anymore.

@RobTillaart
Copy link
Owner

@cklam2
Thanks for this addition, appreciated!
It might mean that there is an additional argument for a reset() function for the DHT.
I do not recall reading such a thing in the datasheet.

I added a note in #45 so it is at least in my list of issues.

@cklam2
Copy link

cklam2 commented Jan 3, 2021

Would be nice if the DHT it has such a feature. Haven't seen anyone suggesting that though in the threads that I've seen. Here is another one from the Tasmota project, also suggesting to avoid those aforementioned GPIO pins.

@RobTillaart
Copy link
Owner

RobTillaart commented Jan 3, 2021

@cklam2

Currently the DHTNEW lib has powerUp() powerDown() which effectively only set the datapin to LOW to reduce some (minimal) power consumption. It is possible to extend this in the following way

void DHTNEW::setVCCpin(uint8_t pin)
{ 
  _vccPin = pin;
};

int  DHTNEW::getVCCpin()  // convenience 
{ 
  return _vccPin;
};

void DHTNEW::powerUp()
{
  _power = true;
  if (_vccPin >= 0) digitalWrite(_vccPin, HIGH);

  digitalWrite(_dataPin, HIGH);
  // do a dummy read to sync the sensor
  read();
};

void DHTNEW::powerDown()
{
  _power = false;
  if (_vccPin >= 0) digitalWrite(_vccPin, LOW);

  digitalWrite(_dataPin, LOW);
}

bool DHTNEW::isPowerUp()
{
  return _power == true;
}

+ some initialization in constructor

Of course this only works when the DHT sensor is powered by a digital pin and not by VCC directly.
I do not know how much current it draws from my head and I think powering directly from IO pin is
not recommended.

Opinion?

#45

@cklam2
Copy link

cklam2 commented Jan 3, 2021

First of all, it seems that the DHTs draw around 2.5mA current and ESP8266 can provide max 12mA on the pin so in theory it' is possible. But it is not recommended. Instead, use eg a transistor to control the power through a pin.

Secondly, the power on/off functionality isn't part of the DHT sensor. It's more a generic switch functionality so I don't think it should be part of your library. Would otherwise make things more confusing.

So my opinion: ppl should just avoid those GPIO pins. If there's no other option they can use the Arduino switch library to control the DHTs power.

@RobTillaart
Copy link
Owner

RobTillaart commented Jan 3, 2021

OK, I can add some notes in the readme.md file


update: added note in master. no new release made.

@cklam2
Copy link

cklam2 commented Jan 3, 2021

Great, thanks a lot!

@DaleSchultz
Copy link

I am getting only Sensor Not Ready on ESP8266 (NodeMCU) and DHT11

With VCC connected to 3V3 pin, data to D1 (GPIO 5)

22:04:21.069 -> TIM	CNT	STAT	HUMI	TEMP	TIME	TYPE
22:04:21.069 -> 233536	220	SNR,	-999.0,	-999.0,	36168,	0
22:04:22.170 -> 234608	221	SNR,	-999.0,	-999.0,	36126,	0
22:04:23.210 -> 235681	222	SNR,	-999.0,	-999.0,	36134,	0
22:04:24.280 -> 236754	223	SNR,	-999.0,	-999.0,	36117,	0
22:04:25.360 -> 237826	224	SNR,	-999.0,	-999.0,	36130,	0
22:04:26.429 -> 238899	225	SNR,	-999.0,	-999.0,	36148,	0
22:04:27.529 -> 239971	226	SNR,	-999.0,	-999.0,	36127,	0
22:04:28.569 -> 241044	227	SNR,	-999.0,	-999.0,	36036,	0
22:04:29.662 -> 242116	228	SNR,	-999.0,	-999.0,	36151,	0
22:04:30.723 -> 243189	229	SNR,	-999.0,	-999.0,	36128,	0

No change if I disconnect the data pin.

If I connect VCC to V5 (VIN) instead of 3V3, I get only DHTLIB_ERROR_TIMEOUT_A instead of SNR.

I get the same results with two different DHT11 modules.

I have tried pins:
D1 GPIO 5
D9 GPIO 3
D6 GPIO 12

I have not yet tested any other libraries. Will do that next.

@RobTillaart
Copy link
Owner

RobTillaart commented Jun 25, 2022

@DaleSchultz
Thanks for reporting the issue. It is better to create a new issue instead of reopening one that is this old.

Things you should check

  • the power supply, 3V3 is at the edge of what works according the datasheet. Better is to power the sensor with 5V.
    You should measure it with a DMM
  • a pullup resistor, typical 4K7 and depending on length of the wires you might need to use a smaller one.
    For 3V3 you might also need to use a smaller one. 3K3 or even 2K2
    You might also start with short wires.
  • if you have a scope or a logic analyzer you can check if there is communication on the data line.
    You can make a simple line sniffer with an Arduino.
  • if you have a scope you can even check the quality of the wave form.
  • you might need to check the datasheet of the 8266 which pins are bidirectional. Some might be input only.
  • you can run the dhtnew_pulse_diag.ino example. to see the timing of the sensor.
    (you need to adjust the wakeup time in the code for the DHT11)

@DaleSchultz
Copy link

thanks, does the pullup go on the data line? The ESP8266 has built-in pullups, but perhaps the code is not telling it to use the pullup.

I am using short wires (on a breadboard), pins are bidirectional.

I don't have a scope.

I'll try the diagnostic sketch.

many thanks.

@RobTillaart
Copy link
Owner

Internal pullups are much larger e.g. 50 K
The pullup should indeed between data an 3V3

@DaleSchultz
Copy link

dhtint_pulse_diag.ino crashes with, and without, a 2k resistor and, with, and without, noInterrupts();

18:21:09.862 -> dhtint_pulse_diag.ino
18:21:09.862 -> 
18:21:09.862 -> awake 
18:21:13.075 -> --------------- CUT HERE FOR EXCEPTION DECODER ---------------
18:21:13.075 -> 
18:21:13.075 -> Soft WDT reset
18:21:13.075 -> 
18:21:13.075 -> >>>stack>>>
18:21:13.075 -> 
18:21:13.075 -> ctx: cont
18:21:13.075 -> sp: 3ffffdc0 end: 3fffffc0 offset: 01a0
18:21:13.075 -> 3fffff60:  402015d0 3ffee520 3ffee518 402012eb  
18:21:13.075 -> 3fffff70:  402015d0 00000001 00000005 40100f30  
18:21:13.122 -> 3fffff80:  3fffdad0 00000000 3ffee6d4 3ffee73c  
18:21:13.122 -> 3fffff90:  3fffdad0 00000000 3ffee728 402014a1  
18:21:13.122 -> 3fffffa0:  feefeffe feefeffe 3ffee728 40201e50  
18:21:13.122 -> 3fffffb0:  feefeffe feefeffe 3ffe85dc 40100c11  
18:21:13.122 -> <<<stack<<<
18:21:13.122 -> 
18:21:13.122 -> --------------- CUT HERE FOR EXCEPTION DECODER ---------------
18:21:13.122 -> 
18:21:13.122 ->  ets Jan  8 2013,rst cause:2, boot mode:(3,6)
18:21:13.122 -> 
18:21:13.122 -> load 0x4010f000, len 3460, room 16 
18:21:13.169 -> tail 4
18:21:13.169 -> chksum 0xcc
18:21:13.169 -> load 0x3fff20b8, len 40, room 4 
18:21:13.169 -> tail 4
18:21:13.169 -> chksum 0xc9
18:21:13.169 -> csum 0xc9
18:21:13.169 -> v00042460
18:21:13.169 -> ~ld
18:21:13.216 -> dhtint_pulse_diag.ino
18:21:13.216 -> 
18:21:13.216 -> awake 
18:21:16.413 -> --------------- CUT HERE FOR EXCEPTION DECODER ---------------

I have found that I am not getting a full 5V to the VCC pin so I am going to try a better supply next.

@DaleSchultz
Copy link

I tried a different library....
3V3 supply, no resistors using SimpleDHT

18:37:20.418 -> Sample OK: 28 *C, 55 H
18:37:21.926 -> =================================
18:37:21.926 -> Sample DHT11...
18:37:21.926 -> Sample OK: 28 *C, 55 H
18:37:23.432 -> =================================
18:37:23.432 -> Sample DHT11...
18:37:23.432 -> Sample OK: 28 *C, 54 H
18:37:24.938 -> =================================
18:37:24.938 -> Sample DHT11...
18:37:24.985 -> Sample OK: 28 *C, 54 H

@RobTillaart
Copy link
Owner

@DaleSchultz
OK, does this working library solves your issue?


dhtint_pulse_diag.ino crashes with, and without, a 2k resistor and, with, and without, noInterrupts();

Very strange as it has only basic operaters like digitalWrite/Read and pinMode.
Should work on Arduino compatible platform but I have never tested it with a ESP8266 myself.

analysis crash dhtint_pulse_diag.ino

Runs at least to the line - Serial.print("awake ");

As a software watchdog kicks in It looks like it got stuck in one of the while (digitalRead(_dataPin) == HIGH); lines forever, meaning the sensor does not pull the line HIGH enough. Otherwise we would have seen Serial.print("2 ");
Possible causes

  • datapin incorrect
  • pull up incorrect
  • wiring incorrect
  • sensor failure

The latter seems unlikely as sensor works with another library. Other three cannot be eliminated as cause.

@DaleSchultz
Copy link

yes, something is timing out as it runs for more than 2 seconds after the "awake"

@DaleSchultz
Copy link

LOL, after 7 months I could get back to this project and forgot how far I was, so I started over. Found the same issues, tried all sorts of things, then googled "sensor not ready" with ESP8266 and found this thread... scrolled down to find my own posts about it!

@RobTillaart
Copy link
Owner

Very recognizable, sort of deja vu experience.

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

No branches or pull requests

3 participants