Closed Jurand2020 closed 4 years ago
line 213 even change it to 50
if i reduce timeout value in line 213 I get the DHTLIB_ERROR_SENSOR_NOT_READY too
Q: what length is your wire currently?
still no-go: Sensor not ready, -999.0, -999.0, 21081, 0
line about 1m
line 266 count = 3; change to 1 ==> so after one detection of state it returns...
You get problems if you would do while (micros() < (start + timeout))
Yes, you are right.
line 266 count = 3; change to 1
no change
checked my breadboard I have my sensor powered with the 5V pin. changed it to 3V3 and going to do some test runs.
3V3 still works with short lines I need to find a 1m wire to recreate your config
2 mtr cable does work here ... (edit: flat wires no utp/stp)
DHT_endless.ino
LIBRARY VERSION: 0.3.3
35 1 OK, 55.5, 26.6, 4926, 22
1040 2 OK, 55.5, 26.6, 2, 22
2040 3 OK, 55.4, 26.6, 4954, 22
3045 4 OK, 55.4, 26.6, 2, 22
4045 5 OK, 55.8, 26.7, 5000, 22
5050 6 OK, 55.8, 26.7, 2, 22
6050 7 OK, 55.5, 26.7, 4999, 22
7055 8 OK, 55.5, 26.7, 2, 22
8055 9 OK, 55.4, 26.7, 4902, 22
TIM CNT STAT HUMI TEMP TIME TYPE
9060 10 OK, 55.4, 26.7, 2, 22
10060 11 OK, 55.3, 26.7, 5003, 22
11065 12 OK, 55.3, 26.7, 2, 22
12065 13 OK, 55.1, 26.8, 4952, 22
13070 14 OK, 55.1, 26.8, 2, 22
14070 15 OK, 54.8, 26.8, 4852, 22
15075 16 OK, 54.8, 26.8, 2, 22
16075 17 OK, 55.1, 26.8, 4954, 22
17080 18 OK, 55.1, 26.8, 2, 22
18080 19 OK, 55.2, 26.8, 4897, 22
TIM CNT STAT HUMI TEMP TIME TYPE
19085 20 OK, 55.2, 26.8, 2, 22
20085 21 OK, 55.2, 26.8, 4903, 22
21090 22 OK, 55.2, 26.8, 2, 22
22090 23 OK, 55.2, 26.8, 4899, 22
23095 24 OK, 55.2, 26.8, 2, 22
24095 25 OK, 55.0, 26.8, 4900, 22
25100 26 OK, 55.0, 26.8, 2, 22
26100 27 OK, 54.8, 26.8, 4846, 22
27105 28 OK, 54.8, 26.8, 2, 22
28105 29 OK, 54.6, 26.8, 4804, 22
TIM CNT STAT HUMI TEMP TIME TYPE
29110 30 OK, 54.6, 26.8, 2, 22
are you using ESP?
Yes ESP32 (tried to upload photo but that crashed ...)
there is sth about my sensor. I've got it all soldered and it is hard to replace the esp.
fact is I'm using thin wires inside (0,24mm kynar), but it has no more than 3cm each
there is sth about my sensor. I've got it all soldered and it is hard to replace the esp.
mmmm, can you check the soldering?
funny is that it works with the previous method. can it be that communication ovelaps somehow?
connections checked with multimeter. It is still running with grove libs
I tried 3 mtr cable - on bread board and it still works
note the failures in the log below was when reconnecting cables (runtime)
848036 847 SNR, -999.0, -999.0, 1175, 22
849037 848 OK, -999.0, -999.0, 2, 22
850037 849 SNR, -999.0, -999.0, 1175, 22
OK CRC TOA TOAB TOC TOD SNR BS UNK
815 0 0 0 0 0 34 0 0
TIM CNT STAT HUMI TEMP TIME TYPE
851039 850 OK, -999.0, -999.0, 2, 22
852039 851 SNR, -999.0, -999.0, 1174, 22
853040 852 OK, -999.0, -999.0, 2, 22
854040 853 SNR, -999.0, -999.0, 1175, 22
855041 854 OK, -999.0, -999.0, 2, 22
856041 855 SNR, -999.0, -999.0, 1174, 22
857042 856 OK, -999.0, -999.0, 2, 22
858042 857 SNR, -999.0, -999.0, 1174, 22
859043 858 OK, -999.0, -999.0, 2, 22
860043 859 OK, 66.6, 26.0, 4850, 22
TIM CNT STAT HUMI TEMP TIME TYPE
861049 860 OK, 66.6, 26.0, 2, 22
862048 861 OK, 67.4, 26.0, 4850, 22
863053 862 OK, 67.4, 26.0, 2, 22
864053 863 OK, 69.0, 26.0, 4956, 22
865058 864 OK, 69.0, 26.0, 2, 22
866058 865 OK, 67.3, 26.0, 4800, 22
867063 866 OK, 67.3, 26.0, 2, 22
868063 867 OK, 65.0, 26.1, 4850, 22
869068 868 OK, 65.0, 26.1, 2, 22
870068 869 OK, 63.0, 26.1, 5105, 22
connections checked with multimeter. It is still running with grove libs
OK, that means the hardware is OK
Propose to go back to what worked for you:
You stated that version 0.3.2 worked if you added just one line (digitalWrite(datapin HIGH) around line 204.
So I am going to try that here with my 3 mtr cable.
Version 0.3.2 with 3 mtr cable fails here with BITSHIFT error. so problem situation recreated.
wow. I'm not the only one ;) btw, If I set the type before read(), then the results are:
dhtnew_test.ino LIBRARY VERSION: 0.3.3
Type detection test, first run might take longer to determine type STAT HUMI TEMP TIME TYPE OK, 0.0, 0.0, 20, 22 OK, 0.0, 0.0, 2, 22 OK, 0.0, 0.0, 2, 22 OK, 0.0, 0.0, 2, 22
Humidity offset test STAT HUMI TEMP TIME TYPE Sensor not ready, -999.0, -999.0, 94, 22 OK, -999.0, -999.0, 3, 22 OK, -999.0, -999.0, 2, 22 OK, -999.0, -999.0, 2, 22
no error nor correct values
Adding the one liner digitalWrite(datapin HIGH) makes it work with 3 mtr cable.
This is the simplest fix for the problem. As we now understand how/where the problem is started I propose to use this minimal fix to update the library. As we understand it is a timing problem I propose to add an explicit delayMicroseconds() too
// REQUEST SAMPLE - SEND WAKEUP TO SENSOR
pinMode(_dataPin, OUTPUT);
digitalWrite(_dataPin, LOW);
// add 10% extra for timing inaccuracies in sensor.
delayMicroseconds(_wakeupDelay * 1100UL);
// HOST GIVES CONTROL TO SENSOR
digitalWrite(_dataPin, HIGH); // <<<<<<<<<<<<<<
delayMicroseconds(2); // <<<<<<<<<<<
pinMode(_dataPin, INPUT_PULLUP);
// DISABLE INTERRUPTS when clock in the bits
noInterrupts();
If that works for you that will be the fix.
The earlier rewrite with waitFor() will get additional testing from my side as this would replace the "hard to tune" timeout loops
wow. I'm not the only one ;) btw, If I set the type before read(), then the results are:
setting the type manually will not force the sensor to cooperate, (nevertheless a good experiment!) it only forces the wake-up time of the sensor to be set
If that works for you that will be the fix.
Yes, this works here.
OK then I will make a new version of the lib containing those two line. Thank you very much for helping with this investigation, it has learned me some new things about fast reading digital signals and slow rising wires :)
expect the new version in< 5 minutes.
Master upgraded to 0.3.3 with the fix. I will remove the test_29 branches as these did not solve the problem (have a local copy here to investigate further)
testrun with 3 mtr cable starts OK - will get a night run
TIM CNT STAT HUMI TEMP TIME TYPE
2545332 2540 OK, 59.2, 26.1, 4846, 22
2546337 2541 OK, 59.2, 26.1, 2, 22
2547337 2542 OK, 59.0, 26.2, 5051, 22
2548342 2543 OK, 59.0, 26.2, 2, 22
2549342 2544 OK, 59.0, 26.2, 2, 22
2550342 2545 OK, 58.9, 26.2, 4995, 22
2551347 2546 OK, 58.9, 26.2, 2, 22
2552347 2547 OK, 58.7, 26.1, 4996, 22
2553352 2548 OK, 58.7, 26.1, 2, 22
2554352 2549 OK, 58.5, 26.2, 4894, 22
OK CRC TOA TOAB TOC TOD SNR BS UNK
2549 0 0 0 0 0 0 0 0 <<<< not bad stats to get started :)
TIM CNT STAT HUMI TEMP TIME TYPE
2555358 2550 OK, 58.5, 26.2, 2, 22
2556358 2551 OK, 58.5, 26.1, 4895, 22
2557363 2552 OK, 58.5, 26.1, 2, 22
2558363 2553 OK, 58.4, 26.1, 4801, 22
2559368 2554 OK, 58.4, 26.1, 2, 22
Nightly run was OK sofar, > 40.000 calls with 3 meter (10 feet) cable, zero fails no guarantee but it gives some confidence
40997916 40897 OK, 62.6, 22.7, 5146, 22
40998921 40898 OK, 62.6, 22.7, 2, 22
40999921 40899 OK, 62.6, 22.7, 5147, 22
OK CRC TOA TOAB TOC TOD SNR BS UNK
40899 0 0 0 0 0 0 0 0
TIM CNT STAT HUMI TEMP TIME TYPE
41000926 40900 OK, 62.6, 22.7, 3, 22
41001927 40901 OK, 62.6, 22.7, 5143, 22
Looks good on my setup too.
When using longer wire for am2302 (like 1-5m) there is always error on read. Checked with oscilloscope - the signal looks fine. Grove_Temperature_And_Humidity_Sensor library had no problem with the same hardware setup. I've used ESP32 DevKit V1.