read() hangs with MkrWiFi + MkrConnector Board

[ToineSiebelink]

I have 6 DHT22 sensor connected to a WifiMkr1010 Board (sensors connected via a MKR Connector Carrier board on D0-D5) Until recently I used DHTStable library (1.0.1) which worked fine but I ran onto a bug when outdoor temp dropped below 0c.

So I changed over to DHTNew (0.4.9) but unfortunaly it doesn't seem to work in combination with this board. I have another set of sensors on an ESP8266 (wemos Mini) board and they word firn with the DHTNew library.

On the MKR1010 it seems to hang on the read() method. if I precede .read() with .setType(22) it does continue but reports unknown error -5 on the first attempt followed by unknown error -8 on subsequent attempts.

I have attached my sourcecode at the top you'll see do defined statement to enable DHTNEW and a basic debug option...

Any idea what could be wrong any suggestion to troubleshoot?

Thanks main.zip !

[RobTillaart]

So what resistor size would you recommend? I got 220, 1k, 10k and 100k

recommend 1K
220 ohm would give a constant current of ~25 mA (not much but not needed) 10 K and 100 K would be slower to raise the voltage.

I use this book as a reference - https://www.amazon.co.uk/Practical-Electronics-Inventors-Fourth-Scherz/dp/1259587541 There is quite some math in it, but most can be skipped.

For my commercial projects I work together with an Electric Engineer so he "fixes" my hardware schemes.

[ToineSiebelink]

thanks for the tips. I'll try that!

[RobTillaart]

FYI

OK  CRC     TOA     TOB     TOC     TOD     SNR     BS  WFR     UNK
128665  0   0   0   10  0   0   0   128674  0   

128000 real reads 10 fails => 1 in 10K still holds.

Unless there are other related questions, I think the issue can be closed?

[ToineSiebelink]

absolutely, the issue can be closed ( I presume you will only do a small readme update?) Thanks for the quick resolution and other helpful tips!

kind regards,

Toine

On Mon, 15 Nov 2021 at 21:03, Rob Tillaart @.***> wrote:

FYI

OK CRC TOA TOB TOC TOD SNR BS WFR UNK 128665 0 0 0 10 0 0 0 128674 0

128000 real reads 10 fails => 1 in 10K still holds.

Unless there are other questions, I think the issue can be closed?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/RobTillaart/DHTNew/issues/67#issuecomment-969318328, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEBXXAC6UBDDK2JEOLGPY43UMFYSTANCNFSM5HL4NNFQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[RobTillaart]

Yes, the library did not change so I only need to

• mention that the mkr1010 needs the extra line
• add some comments in the endless sketch I used to do the long test.
• add the While(!Serial) in the demo sketches
• add some commented debugging code in the .cpp file

so a bit more than just the readme, but no breaking stuff.
Tomorrow, it is too late to start a new PR now ;)

[RobTillaart]

OK  CRC     TOA     TOB     TOC     TOD     SNR     BS  WFR     UNK
146840  0   0   0   10  0   0   0   146849  0   

still going well

[RobTillaart]

PR created - https://github.com/RobTillaart/DHTNew/pull/68

OK  CRC     TOA     TOB     TOC     TOD     SNR     BS  WFR     UNK
158037  0   0   0   13  0   0   0   158049  0

stable 1 in 10.000 ==> going to adjust timing a bit to see if that reduces it

[RobTillaart]

PR merged.

[RobTillaart]

update test with slightly longer timeout C (90 micros in stead of 70 micros)

OK  CRC     TOA     TOB     TOC     TOD     SNR     BS  WFR     UNK
34549   0   0   0   0   0   1   0   34549   0   

1x SNR - Sensor not Ready but no other (timeout) errors although I expected 2 or 3 (based upon the previous run which had 1 in 10K-15K )

so looks promising as an improvement.

[ToineSiebelink]

yea sounds good, you could also consider to make it configurable if time-critical applications want to keep it shorter (and don't mind to have a retry or ignore option as required in the client app). Just a suggestion, might not be with the (coding) overhead either...

On Wed, 17 Nov 2021 at 09:05, Rob Tillaart @.***> wrote:

update test with slightly longer timeout C (90 micros in stead of 70 micros)

OK CRC TOA TOB TOC TOD SNR BS WFR UNK 34549 0 0 0 0 0 1 0 34549 0

1x SNR - Sensor not Ready but no other (timeout) errors although I expected 2 or 3 (based upon the previous run which had 1 in 10K-15K )

so looks promising as an improvement.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/RobTillaart/DHTNew/issues/67#issuecomment-971375647, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEBXXAF45YAAKPHIUDVSNXLUMNV43ANCNFSM5HL4NNFQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[RobTillaart]

You can't make the time shorter than the specs otherwise you don't have a measurement.

• that is where the original 70us is based upon.

(backgrounder) As far as we know there is a small processor in the sensor. Probably the clock of the sensor is 1MHz (assumption) but it is not very precise (±5% ?) . That assumption is based on the minimum pulse lengths mentioned in the protocol. The smallest common divider of the mentioned lengths is ~10us. To achieve that at least a 1MHz processor is needed. A DHT22 probably has a faster core than a DHT11 as it is able to "wake up" much faster and is able to add decimal precision.

The varying of pulse length is a robust protocol as a difference between a 0 and a 1 are given in an large enough time frame. 50 + 27us = 0 50 + 70us = 1. Technically speaking the protocol could be 5-10x faster and still be workable for a 16 MHz UNO. (end)

That said, if the internal processor is ~5% slower the 50+70 us of the spec become 70 + 5% = 75 us (approx) so to be able to handle this you need a sufficient large timeout, otherwise you will get too much failed readings - which is a serious waste of clock cycles in a RT system. BTW a faster processor would not need the max timeout so they will work as intended.

so, no I think it will make no sense to make the timeout configurable from the API. And people who like to hack are welcome to clone and patch the library.

I will try to keep the setup running to see how much better it is . now at 41424, still no timeout, only one SNR

[ToineSiebelink]

I see you point and yes if they aren't happy with the increase to 90us they can alway manipulate (hack) their own copy of the library

On Wed, 17 Nov 2021 at 12:50, Rob Tillaart @.***> wrote:

You can't make the time shorter than the specs otherwise you don't have a measurement.

• that is where the original 70us is based upon.

(backgrounder) As far as we know there is a small processor in the sensor. Probably the clock of the sensor is 1MHz (assumption) but it is not very precise (±5% ?) . That assumption is based on the minimum pulse lengths mentioned in the protocol. The smallest common divider of the mentioned lengths is ~10us. To achieve that at least a 1MHz processor is needed. A DHT22 probably has a faster core than a DHT11 as it is able to "wake up" much faster and is able to add decimal precision.

The varying of pulse length is a robust protocol as a difference between a 0 and a 1 are given in an large enough time frame. 50 + 27us = 0 50 + 70us = 1. Technically speaking the protocol could be 5-10x faster and still be workable for a 16 MHz UNO. (end)

That said, if the internal processor is ~5% slower the 50+70 us of the spec become 70 + 5% = 75 us (approx) so to be able to handle this you need a sufficient large timeout, otherwise you will get too much failed readings

• which is a serious waste of clock cycles in a RT system. BTW a faster processor would not need the max timeout so they will work as intended.

so, no I think it will make no sense to make the timeout configurable from the API. And people who like to hack are welcome to clone and patch the library.

I will try to keep the setup running to see how much better it is . now at 41424, still no timeout, only one SNR

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/RobTillaart/DHTNew/issues/67#issuecomment-971549065, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEBXXAE7J6WSGXRHUPPRJHDUMOQKPANCNFSM5HL4NNFQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[RobTillaart]

So after 40+ hours and 74000++ reads no TOC error anymore, so time to prepare a PR. at a rate of 1 in 10-15K somewhere between 5 and 7 TOC's were expected. No statistical argumentation calculated (too early)

OK  CRC     TOA     TOB     TOC     TOD     SNR     BS  WFR     UNK
74024   0   0   0   0   0   1   0   74024   0

[RobTillaart]

DHTNEW 0.4.10 released

[RobTillaart]

going towards 80 hrs...still going strong.

OK  CRC     TOA     TOB     TOC     TOD     SNR     BS  WFR     UNK
142799  0   0   0   0   0   1   0   142799  0

---

92 hrs. tomorrow I stop the testrun.

OK  CRC     TOA     TOB     TOC     TOD     SNR     BS  WFR     UNK
165724  0   0   0   0   0   1   0   165724  0

---

114 hrs, ...

OK  CRC     TOA     TOB     TOC     TOD     SNR     BS  WFR     UNK
206399  0   0   0   0   0   1   0   206399  0

---

162 hrs

OK  CRC     TOA     TOB     TOC     TOD     SNR     BS  WFR     UNK
293274  0   0   0   0   0   1   0   293274  0

[RobTillaart]

Note: found the define to set the IRQ flag in the library

  #ifdef ARDUINO_SAMD_MKRWIFI1010
  #error found
  #endif

intention to include this in the library sometime.