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]

Hoi Toine, Not familiar with the board, is it a 3V3 board? Did you use pullups? If so which value?

You state the DHTStable worked except for negative temperatures. I assume you mean temp Celsius.

I will check later this evening, as I have another thing to fix too (in house not sw)

[RobTillaart]

@ToineSiebelink

The DHT11/22 low level protocol is quite sensitive for timing, spent quite some time on it.

Had a quick look and the DHTStable might still have a "negative bug" as the way temperature is calculated differs from DHTNew. So I made a patch for DHTStable to have the same math as DHTNew for temperature.

Can you please test this by replacing the read() function in the DHTStable library?

int DHTStable::read(uint8_t pin)
{
    // READ VALUES
    if (_disableIRQ) noInterrupts();
    int rv = _readSensor(pin, DHTLIB_DHT_WAKEUP);
    if (_disableIRQ) interrupts();
    if (rv != DHTLIB_OK)
    {
        _humidity    = DHTLIB_INVALID_VALUE;  // NaN prefered?
        _temperature = DHTLIB_INVALID_VALUE;  // NaN prefered?
        return rv; // propagate error value
    }
    // CONVERT AND STORE
    _humidity  = word(bits[0], bits[1]) * 0.1;
    int16_t t = ((_bits[2] & 0x7F) * 256 + _bits[3]);
    if (t == 0)
    {
      _temperature = 0.0;     // prevent -0.0;
    }
    else
    {
      _temperature = t * 0.1;
      if((_bits[2] & 0x80) == 0x80 )
      {
        _temperature = -_temperature;
      }
    }
    // TEST CHECKSUM
    uint8_t sum = bits[0] + bits[1] + bits[2] + bits[3];
    if (bits[4] != sum)
    {
        return DHTLIB_ERROR_CHECKSUM;
    }
    return DHTLIB_OK;
}

[ToineSiebelink]

Hoi Rob.

Thanks for your quick response! I'll might get a chance to test that path for dhtstable tomorrow. If have to test it using the freezer 🤣 now as temp outside is above zero celcius again.

Re. The wifi mkr1010. Yes I think it wath you call a 3V3 board. See spec here https://store.arduino.cc/products/arduino-mkr-wifi-1010?selectedStore=eu

But for the I/0 it is stacked on this connector carrier board: https://store.arduino.cc/products/arduino-mkr-connector-carrier-grove-compatible?selectedStore=eu

The grove connections are a convenient way to be able to plugin and out the cables to my sensors.

My understanding was that pull up resistors are built in but I am more a software the s hardware man. So my understanding might be wrong.

I would prefer to continue using your dhtnew library as dhtstablec seemed a stopgap solution?! Thanks for this libraries btw, I was getting a lot of faulty readings with the standard libs (probably because bof cable lengths)

In the weekend I might try connecting directly to the WiFi board without the carrier but that requires some small hardware changes and it is a live system controlling my house heating.

Dankjewel, Toine

On Thu, 4 Nov 2021, 17:52 Rob Tillaart, @.***> wrote:

@ToineSiebelink https://github.com/ToineSiebelink

The DHT11/22 low level protocol is quite sensitive for timing, spent quite some time on it.

Had a quick look and the DHTStable might still have a "negative bug" as the way temperature is calculated differs from DHTNew. So I made a patch for DHTStable to have the same math as DHTNew for temperature.

Can you please test this by replacing the read() function in the DHTStable library?

int DHTStable::read(uint8_t pin) { // READ VALUES if (_disableIRQ) noInterrupts(); int rv = _readSensor(pin, DHTLIB_DHT_WAKEUP); if (_disableIRQ) interrupts(); if (rv != DHTLIB_OK) { _humidity = DHTLIB_INVALID_VALUE; // NaN prefered? _temperature = DHTLIB_INVALID_VALUE; // NaN prefered? return rv; // propagate error value } // CONVERT AND STORE _humidity = word(bits[0], bits[1]) 0.1; int16_t t = ((_bits[2] & 0x7F) 256 + _bits[3]); if (t == 0) { _temperature = 0.0; // prevent -0.0; } else { _temperature = t * 0.1; if((_bits[2] & 0x80) == 0x80 ) { _temperature = -_temperature; } } // TEST CHECKSUM uint8_t sum = bits[0] + bits[1] + bits[2] + bits[3]; if (bits[4] != sum) { return DHTLIB_ERROR_CHECKSUM; } return DHTLIB_OK; }

— 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-961282205, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEBXXAHF5KMHXCA4Q3R5VNLUKLB7TANCNFSM5HL4NNFQ . 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]

OK, will wait for your results tomorrow.

// ik begrijp dat je ook NL spreekt, maar hou de discussies op GitHub bij voorkeur in EN.

[ToineSiebelink]

agreed, we wont more Double Dutch :-)

[RobTillaart]

The DHTStable library is not out of support for bugs but new ideas and features will all be in the DHTNew . As the negative temperature is probably a bug in the code for temperature so that will be fixed if the patch works.

Thereafter we can find out how to get DHTNEw to work on the MKr1010. (do you know where to buy them for a fair price? https://www.kiwi-electronics.nl/nl/arduino-mkr-wifi-1010-3852?search=1010 is out of stock

[RobTillaart]

cheapest and in stock so far: https://www.reichelt.nl/nl/nl/arduino-mkr1010-wifi-bt-samd21-cortex-m0-32-bit-arm-ard-mkr1010-wh-p289307.html E27.15 + 7

[ToineSiebelink]

Hi Rob, I tested DHTSTable with the proposed modified read() method using my freezer and confirm it now correctly reports temperatures below 0 Celcius :-D

I had to make some small corrections as you used _bits[] instead of just bits[] on a few lines. Here is the corrected method I have running now:

int DHTStable::read(uint8_t pin)
{
    // READ VALUES
    if (_disableIRQ) noInterrupts();
    int rv = _readSensor(pin, DHTLIB_DHT_WAKEUP);
    if (_disableIRQ) interrupts();
    if (rv != DHTLIB_OK)
    {
        _humidity    = DHTLIB_INVALID_VALUE;  // NaN prefered?
        _temperature = DHTLIB_INVALID_VALUE;  // NaN prefered?
        return rv; // propagate error value
    }
    // CONVERT AND STORE
    _humidity  = word(bits[0], bits[1]) * 0.1;
    int16_t t = ((bits[2] & 0x7F) * 256 + bits[3]);
    if (t == 0)
    {
      _temperature = 0.0;     // prevent -0.0;
    }
    else
    {
      _temperature = t * 0.1;
      if((bits[2] & 0x80) == 0x80 )
      {
        _temperature = -_temperature;
      }
    }
    // TEST CHECKSUM
    uint8_t sum = bits[0] + bits[1] + bits[2] + bits[3];
    if (bits[4] != sum)
    {
        return DHTLIB_ERROR_CHECKSUM;
    }
    return DHTLIB_OK;
}

(added code tags for syntax highlighting)

[RobTillaart]

Thank you for testing, I will create a new release of it this weekend. The bits and _bits , yes a hasty copy / paste action without testing but you figured it out. well done! (I try to use _var for private and protected vars but I am not always consistent apparently :)

I will to give you credits in the code for your time (If you like)

[RobTillaart]

Created - https://github.com/RobTillaart/DHTstable/tree/develop

[ToineSiebelink]

no problem! I also went back to my main setup with Arduino MKR WiFi1010 board. I modified by code for easier and better switch between your 2 libraries and I tested on several pins, with and without MKR Connector Carrier board but to no avail. DHTNew hangs on read() while DHTStable,read22() successfully reads all 6 sensor I have attached.

If I use setType(22) I see several Timeout C and Timeout D messages but mainly 'waiting for read' until it fails.

I actually live in Ierland and order from Farnell.ie but a quick search for Dutch seller brought me here: https://www.robotshop.com/nl/nl/arduino-mkr-wifi-1010-schild.html?gclid=CjwKCAjwz5iMBhAEEiwAMEAwGLimOST3z9uRHgDC1zlAWWD3jinGGNFl1ZIXcZzM6FtUhC5hjkPDARoCjXAQAvD_BwE but I am not familiar with them...

Actually I see you found a cheaper option already

[RobTillaart]

As we "saved the project" with the improved read, we should continue with fixing the DHTNew lib for Arduino MKR WiFi1010 board. (at least the read function is OK, it is definitely lower timing)

I will order one, so I can test to see what happens. Good to know which timeouts fail. What is the clock freq of the Mkr1010?

Ireland, still on my list to visit - have seen pictures of Northern Ireland that were really beautiful (countryside) and the south west parts. The closest I came long ago was the island of Anglesey.

[ToineSiebelink]

yep, moved here 20+ years ago, never regretted it :-) Still often visit my hometown of Breda though not too far from Gemert!

A Quick search on speed: Clock Speed | 32.768 kHz (RTC), 48 MHz (see https://www.wia.io/things/arduino-mkr1010)

You think speed might be the issue?!

[RobTillaart]

Timeouts are based upon clock-speeds (it is just a bit bang protocol) and there is no uniform way to handle that in a neat way in the arduino world. E.g. there are different ways to get the clockspeed.

some places to tune: dhtnew.cpp

• line 381 uint8_t count = 2; and set it to 1
  • line 343 + 349 set the waitfor timeout parameters to resp 80 and 100 but 70 and 90 are already high.

[ToineSiebelink]

sorry Rob, tried that, no Joy, I went up to 90/110 even tried to double the original values 140/180 but stil the same response hanging on read() (with using setType()) and timeout C/D messages if I do set the type :-(

[RobTillaart]

FYI, I have merged the working read() into DHTSTable master.

[RobTillaart]

@ToineSiebelink Do you use pullup resistors? if so, which value? What is the length of the wires? approx?

[ToineSiebelink]

Hi Rob, I think the MKR1010 or the connector carrier board might have built in pull up resistors I am not sure. Regarding the length of the cables. They vary from 1m to unknown but at least 6=7meters as I am using cabling the original connected wall thermostats to a central manifold system for the heating (I remove the electronics form the original thermostats and put a DHT22 inside the housing). I hope I have time later today to take out the MRK 1010 and put it on breadboard with up to 3 sensors to take out the unknowns about cabling and I can also add pull resistors... But don't forget DHTStable still is performing fine in exactly the same setup! There must be a important software difference that makes DHTStable work and DHTNew fail. but I appreciate that hardware issues do complicate matters....

[RobTillaart]

Agree, the problem is definitely in the timing of the DHTNew lib. unclear is if it is the first bit, last bit or another bit, or even a random bit that fails.

I ordered two MKR1010's so if time permits I can start investigating too.

[ToineSiebelink]

I just tested using a breadboard with just 1 sensor with and without 10k pull up resistor. Still the same results :-( I had a look at your library code but this hardware-related stuff in C++ is beyond me unfortunaly I cannot help. I am a fully time java developer and normally work on very different stuff (lookup toine.siebelink@est.tech)

I did notice hover that in DHTNew before reading you use "pinMode(_dataPin, INPUT_PULLUP);" but in DHTStable you just use "pinMode(pin, INPUT);" I might do some more testing around this later....

[RobTillaart]

Thanks for giving it a try, Yes, C++ is different and low level embedded bit hacking is one of its extreme sides. When board comes in I make a setup and hook it up to a oscilloscope to see if there is something awkward.

[RobTillaart]

I did notice hover that in DHTNew before reading you use "pinMode(_dataPin, INPUT_PULLUP);" but in DHTStable you just use "pinMode(pin, INPUT);" I might do some more testing around this later....

Good find, although I expect there is little difference as the internal PULLUP is often in the order of 50K for most noards. Far higher than often used 4K7. But that said still worth a try.

[RobTillaart]

@ToineSiebelink

Got my MKR1010 Wifi boards and I have a problem with uploading a sketch.

• There appear two ports sometimes COM8 and COM10 but most of the time I see no port.
• Pressing RST twice to go to bootloader mode (I googled this) did not help.
• The IDE recognized the board and installed all stuff - board manager says I have latest version 1.8.10
• ON led is on (green)
• a small orange led is on

Any clue how to get that board more stable?

[RobTillaart]

Sometimes after reset the ORANGE led is fading in and out (frequency ~ 1 Hz)

[RobTillaart]

Removed and reinstalled the driver and boards stuff. It looked like it could upload once.

Pressing reset twice: The ORANGE led fading in/out => assumption: the system is in bootloader mode. Pressing reset once: The ORANGE led is dark ==> assumption: the system is in run mode.

Followed guidelines - https://www.arduino.cc/en/Guide/MKRWiFi1010 Stil cannot connect the Serial monitor to the device

[RobTillaart]

See this often when trying to upload.

java.io.IOException: jssc.SerialPortException: Port name - COM8; Method name - setEventsMask(); Exception type - Can't set mask.
    at processing.app.Serial.dispose(Serial.java:173)
    at processing.app.SerialMonitor.close(SerialMonitor.java:147)
    at processing.app.AbstractMonitor.suspend(AbstractMonitor.java:113)
    at processing.app.Editor$UploadHandler.run(Editor.java:2065)
    at java.lang.Thread.run(Thread.java:748)
Caused by: jssc.SerialPortException: Port name - COM8; Method name - setEventsMask(); Exception type - Can't set mask.
    at jssc.SerialPort.setEventsMask(SerialPort.java:279)
    at jssc.SerialPort.removeEventListener(SerialPort.java:1064)
    at jssc.SerialPort.closePort(SerialPort.java:1090)
    at processing.app.Serial.dispose(Serial.java:170)
    ... 4 more

Probably I miss one or two crucial steps but the first hour with the MKR1010 Wifi is not a success.

[RobTillaart]

This looks like a successful upload

Uploading using selected port: COM10
C:\Users\Rob\AppData\Local\Arduino15\packages\arduino\tools\bossac\1.7.0-arduino3/bossac.exe -i -d --port=COM10 -U true -i -e -w -v C:\Users\Rob\AppData\Local\Temp\arduino_build_730126/BareMinimum.ino.bin -R 
Set binary mode
readWord(addr=0)=0x20007ffc
readWord(addr=0xe000ed00)=0x410cc601
readWord(addr=0x41002018)=0x10010305
version()=v2.0 [Arduino:XYZ] Mar 19 2018 09:45:14
chipId=0x10010005
Connected at 921600 baud
readWord(addr=0)=0x20007ffc
readWord(addr=0xe000ed00)=0x410cc601
readWord(addr=0x41002018)=0x10010305
Atmel SMART device 0x10010005 found
write(addr=0x20004000,size=0x34)
writeWord(addr=0x20004030,value=0x10)
writeWord(addr=0x20004020,value=0x20008000)
Device       : ATSAMD21G18A
readWord(addr=0)=0x20007ffc
readWord(addr=0xe000ed00)=0x410cc601
readWord(addr=0x41002018)=0x10010305
Chip ID      : 10010005
version()=v2.0 [Arduino:XYZ] Mar 19 2018 09:45:14
Version      : v2.0 [Arduino:XYZ] Mar 19 2018 09:45:14
Address      : 8192
Pages        : 3968
Page Size    : 64 bytes
Total Size   : 248KB
Planes       : 1
Lock Regions : 16
Locked       : readWord(addr=0x41004020)=0xffff
readWord(addr=0x41004020)=0xffff
readWord(addr=0x41004020)=0xffff
readWord(addr=0x41004020)=0xffff
readWord(addr=0x41004020)=0xffff
readWord(addr=0x41004020)=0xffff
readWord(addr=0x41004020)=0xffff
readWord(addr=0x41004020)=0xffff
readWord(addr=0x41004020)=0xffff
readWord(addr=0x41004020)=0xffff
readWord(addr=0x41004020)=0xffff
readWord(addr=0x41004020)=0xffff
readWord(addr=0x41004020)=0xffff
readWord(addr=0x41004020)=0xffff
readWord(addr=0x41004020)=0xffff
readWord(addr=0x41004020)=0xffff
none
readWord(addr=0x41004018)=0
Security     : false
Boot Flash   : true
readWord(addr=0x40000834)=0
BOD          : false
readWord(addr=0x40000834)=0
BOR          : false
Arduino      : FAST_CHIP_ERASE
Arduino      : FAST_MULTI_PAGE_WRITE
Arduino      : CAN_CHECKSUM_MEMORY_BUFFER
Erase flash
chipErase(addr=0x2000)
done in 0.828 seconds

Write 14860 bytes to flash (233 pages)
write(addr=0x20005000,size=0x1000)
writeBuffer(scr_addr=0x20005000, dst_addr=0x2000, size=0x1000)
[========                      ] 27% (64/233 pages)write(addr=0x20005000,size=0x1000)
writeBuffer(scr_addr=0x20005000, dst_addr=0x3000, size=0x1000)
[================              ] 54% (128/233 pages)write(addr=0x20005000,size=0x1000)
writeBuffer(scr_addr=0x20005000, dst_addr=0x4000, size=0x1000)
[========================      ] 82% (192/233 pages)write(addr=0x20005000,size=0xa40)
writeBuffer(scr_addr=0x20005000, dst_addr=0x5000, size=0xa40)
[==============================] 100% (233/233 pages)
done in 0.122 seconds

Verify 14860 bytes of flash with checksum.
checksumBuffer(start_addr=0x2000, size=0x1000) = f307
checksumBuffer(start_addr=0x3000, size=0x1000) = 88a
checksumBuffer(start_addr=0x4000, size=0x1000) = 8ce8
checksumBuffer(start_addr=0x5000, size=0xa0c) = 987f
Verify successful
done in 0.014 seconds
CPU reset.
readWord(addr=0)=0x20007ffc
readWord(addr=0xe000ed00)=0x410cc601
readWord(addr=0x41002018)=0x10010305
writeWord(addr=0xe000ed0c,value=0x5fa0004)

especially the almost last line - Verify successful + status bar

But I can't connect with the Serial monitor. On the bright side, the weekend is coming :)

[RobTillaart]

  while(!Serial);

adding that line seems to make the difference for the Serial monitor ... as I was able to reproduce your error. (seldom I was so happy to see an error :)

dhtnew_test.ino
LIBRARY VERSION: 0.4.9

1. Type detection test, first run might take longer to determine type
STAT    HUMI    TEMP    TIME    TYPE
Time out C error,   -999.0, -999.0, 21688,  

Now I must learn to do this upload etc smoothly.

[RobTillaart]

OK, somehow the comport flips between 8 and 10 causing part of my problems.

Debugging started

added some print statement in the DHTNEW library when it fails with DHTLIB_ERROR_TIMEOUT_C

(line 339++)

  // READ THE OUTPUT - 40 BITS => 5 BYTES
  for (uint8_t i = 40; i != 0; i--)
  {
    // EACH BIT START WITH ~50 us LOW
    if (_waitFor(HIGH, 70)) 
    {
      Serial.print("IC: ");
      Serial.println(i);
      return DHTLIB_ERROR_TIMEOUT_C;
    }

    // DURATION OF HIGH DETERMINES 0 or 1
    // 26-28 us ==> 0
    //    70 us ==> 1
    uint32_t t = micros();
    if (_waitFor(LOW, 90))
    {
      Serial.print("ID: ");
      Serial.println(i);
      return DHTLIB_ERROR_TIMEOUT_D;
    }
    if ((micros() - t) > DHTLIB_BIT_THRESHOLD)
    {
      _bits[idx] |= mask;
    }

    // PREPARE FOR NEXT BIT
    mask >>= 1;
    if (mask == 0)   // next byte?
    {
      mask = 0x80;
      idx++;
    }
  }

Different runs gave different numbers, 27, 11, 21, 22, 31 ...

[RobTillaart]

Hi, modified the DHTNEW_pulse_diag sketch a bit just to get the timing of the bits . Used VCC to power the DHT22, used pin 5 as data pin.

times are in micros. (arbitrary run).

...
RUN:    19
IDX:    89
WAKEUP
    1155    4   84  103 3   99
HUM
    25  29  53  26  53  26  53  29  54  25  54  73  52  26  69  26
    53  74  53  26  53  73  54  29  53  26  53  74  53  73  66  26
TEMP
    55  26  53  26  53  29  53  26  53  26  53  26  57  22  69  74
    53  74  53  26  53  75  54  25  54  25  54  29  53  22  66  26
CRC
    53  29  53  74  53  26  53  26
    53  74  53  28  53  74  47  6434
BYE
    107 2

It shows nice zero's => times = 25-30 It shows nice ones => times = 53-75 But is also shows a 6434 BANG way out of range. (this time at the end)

Conclusions: (1) signals have a good HIGH and LOW level apparently (2) at some moment it does not see a LOW or HIGH for ~6400 micros. It blocks. That explains the timeout C and D.

Question is what causes the code to block? an interrupt? Further analysis needed.

[RobTillaart]

disabled the interrupts in the test sketch and SUCCESS!

dhtnew_test.ino
LIBRARY VERSION: 0.4.9

1. Type detection test, first run might take longer to determine type
STAT    HUMI    TEMP    TIME    TYPE
OK, 57.5,   20.3,   5253,   22
Waiting for read,   57.5,   20.3,   4,  22
Waiting for read,   57.5,   20.3,   3,  22
Waiting for read,   57.5,   20.3,   3,  22

2. Humidity offset test
STAT    HUMI    TEMP    TIME    TYPE
OK, 68.0,   20.3,   5304,   22
Waiting for read,   68.0,   20.3,   3,  22
Waiting for read,   68.0,   20.3,   3,  22
Waiting for read,   68.0,   20.3,   3,  22

3. Temperature offset test
STAT    HUMI    TEMP    TIME    TYPE
OK, 64.9,   21.6,   5253,   22
Waiting for read,   64.9,   21.6,   3,  22
Waiting for read,   64.9,   21.6,   3,  22
Waiting for read,   64.9,   21.6,   3,  22

4. LastRead test
64.9,   19.1
64.9,   19.1
64.9,   19.1
64.9,   19.1
actual read
64.9,   19.1
actual read
64.9,   19.1
actual read
64.9,   19.1
actual read
64.9,   19.1
actual read
64.9,   19.1
64.9,   19.1
64.9,   19.1
64.9,   19.1
actual read
64.9,   19.1
actual read
64.9,   19.1
actual read
64.9,   19.1
actual read
64.9,   19.1
actual read
64.9,   19.1
64.9,   19.1
64.9,   19.1
64.9,   19.1

Done...

[RobTillaart]

Line to add in setup()

  mySensor.setDisableIRQ(false);

Could you give this sketch a try?

//
//    FILE: dhtnew_test.ino
//  AUTHOR: Rob Tillaart
// VERSION: 0.1.6
// PURPOSE: DHTNEW library test sketch for Arduino
//     URL: https://github.com/RobTillaart/DHTNew
//
// HISTORY:
// 0.1.0    2017-07-24 initial version
// 0.1.1    2017-07-29 added begin();
// 0.1.2    2018-01-08 removed begin();
// 0.1.3    2020-04-30 replaced humidity and temperature with functions
// 0.1.4    2020-06-08 improved error handling
// 0.1.5    2020-06-15 match 0.3.0 error handling
// 0.1.6    2020-11-09 wait for read handling
//
// DHT PIN layout from left to right
// =================================
// FRONT : DESCRIPTION
// pin 1 : VCC
// pin 2 : DATA
// pin 3 : Not Connected
// pin 4 : GND

#include <dhtnew.h>

DHTNEW mySensor(5);

void setup()
{
  while(!Serial);
  Serial.begin(115200);
  Serial.println("dhtnew_test.ino");
  Serial.print("LIBRARY VERSION: ");
  Serial.println(DHTNEW_LIB_VERSION);
  Serial.println();

  mySensor.setDisableIRQ(false);

  Serial.println("\n1. Type detection test, first run might take longer to determine type");
  Serial.println("STAT\tHUMI\tTEMP\tTIME\tTYPE");
  test();
  test();
  test();
  test();

  Serial.println("\n2. Humidity offset test");
  Serial.println("STAT\tHUMI\tTEMP\tTIME\tTYPE");
  mySensor.setHumOffset(2.5);
  test();
  mySensor.setHumOffset(5.5);
  test();
  mySensor.setHumOffset(-5.5);
  test();
  mySensor.setHumOffset(0);
  test();

  Serial.println("\n3. Temperature offset test");
  Serial.println("STAT\tHUMI\tTEMP\tTIME\tTYPE");
  mySensor.setTempOffset(2.5);
  test();
  mySensor.setTempOffset(5.5);
  test();
  mySensor.setTempOffset(-5.5);
  test();
  mySensor.setTempOffset(0);
  test();

  Serial.println("\n4. LastRead test");
  mySensor.read();
  for (int i = 0; i < 20; i++)
  {
    if (millis() - mySensor.lastRead() > 1000)
    {
      mySensor.read();
      Serial.println("actual read");
    }
    Serial.print(mySensor.getHumidity(), 1);
    Serial.print(",\t");
    Serial.println(mySensor.getTemperature(), 1);
    delay(250);
  }

  Serial.println("\nDone...");
}

void loop()
{

}

void test()
{
  // READ DATA
  uint32_t start = micros();
  int chk = mySensor.read();
  uint32_t stop = micros();

  switch (chk)
  {
    case DHTLIB_OK:
      Serial.print("OK,\t");
      break;
    case DHTLIB_ERROR_CHECKSUM:
      Serial.print("Checksum error,\t");
      break;
    case DHTLIB_ERROR_TIMEOUT_A:
      Serial.print("Time out A error,\t");
      break;
    case DHTLIB_ERROR_TIMEOUT_B:
      Serial.print("Time out B error,\t");
      break;
    case DHTLIB_ERROR_TIMEOUT_C:
      Serial.print("Time out C error,\t");
      break;
    case DHTLIB_ERROR_TIMEOUT_D:
      Serial.print("Time out D error,\t");
      break;
    case DHTLIB_ERROR_SENSOR_NOT_READY:
      Serial.print("Sensor not ready,\t");
      break;
    case DHTLIB_ERROR_BIT_SHIFT:
      Serial.print("Bit shift error,\t");
      break;
    case DHTLIB_WAITING_FOR_READ:
      Serial.print("Waiting for read,\t");
      break;
    default:
      Serial.print("Unknown: ");
      Serial.print(chk);
      Serial.print(",\t");
      break;
  }

  // DISPLAY DATA
  Serial.print(mySensor.getHumidity(), 1);
  Serial.print(",\t");
  Serial.print(mySensor.getTemperature(), 1);
  Serial.print(",\t");
  uint32_t duration = stop - start;
  Serial.print(duration);
  Serial.print(",\t");
  Serial.println(mySensor.getType());
  delay(500);
}

// END OF FILE

[RobTillaart]

@ToineSiebelink Not clear yet why allowing interrupts makes this work. It might be similar to the ESP doing Wifi / BT in the background.

Think I need to rephrase this line in the readme.

If consistent problems occur with reading a sensor, one should allow interrupts DHT.setDisableIRQ(true)

[RobTillaart]

NOw more that 5700 seconds no problem

TIM CNT STAT    HUMI    TEMP    TIME    TYPE
5700337 5680    OK, 59.7,   20.1,   5067,   22
5701343 5681    WFR,    59.7,   20.1,   3,  22
5702345 5682    OK, 59.6,   20.1,   5213,   22
5703351 5683    WFR,    59.6,   20.1,   3,  22
5704352 5684    OK, 59.5,   20.1,   5207,   22
5705358 5685    WFR,    59.5,   20.1,   3,  22
5706359 5686    OK, 59.5,   20.1,   5209,   22
5707365 5687    WFR,    59.5,   20.1,   3,  22
5708366 5688    OK, 59.4,   20.1,   5159,   22
5709373 5689    WFR,    59.4,   20.1,   3,  22

WFR = Wait for Read (at least 2 seconds should be between reads)

[RobTillaart]

10 hours later

TIM CNT STAT    HUMI    TEMP    TIME    TYPE
35836300    35720   WFR,    65.0,   17.5,   4,  22
35837301    35721   OK, 64.8,   17.5,   5203,   22
35838307    35722   WFR,    64.8,   17.5,   3,  22
35839308    35723   OK, 64.7,   17.5,   5251,   22
35840314    35724   WFR,    64.7,   17.5,   3,  22
35841315    35725   OK, 64.6,   17.5,   5298,   22
35842321    35726   WFR,    64.6,   17.5,   3,  22
35843322    35727   OK, 64.5,   17.5,   5250,   22
35844328    35728   WFR,    64.5,   17.5,   3,  22
35845329    35729   OK, 64.3,   17.5,   5203,   22

Except for the tab spacing it is still going well.

[ToineSiebelink]

Hi Rob, sorry am out for a weekend at the West coast in Ireland for a bit of an adventure weekend far away from computers and Arduino boards😁 I just glanced at your mail but have to say I had no problems connect the boards like you mentioned... I had a bit of a problem reconnection sometimes after the new lib would hang. Had to press physical reset button at exactly the right time. Well done on finding the issue and many thanks for that! I'll verify your solution on Monday!

On Sat, 13 Nov 2021, 07:15 Rob Tillaart, @.***> wrote:

10 hours later

TIM CNT STAT HUMI TEMP TIME TYPE 35836300 35720 WFR, 65.0, 17.5, 4, 22 35837301 35721 OK, 64.8, 17.5, 5203, 22 35838307 35722 WFR, 64.8, 17.5, 3, 22 35839308 35723 OK, 64.7, 17.5, 5251, 22 35840314 35724 WFR, 64.7, 17.5, 3, 22 35841315 35725 OK, 64.6, 17.5, 5298, 22 35842321 35726 WFR, 64.6, 17.5, 3, 22 35843322 35727 OK, 64.5, 17.5, 5250, 22 35844328 35728 WFR, 64.5, 17.5, 3, 22 35845329 35729 OK, 64.3, 17.5, 5203, 22

Except for the tab spacing it still going well.

— 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-967796694, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEBXXADGWVZPUZP6FZGJZ5TULYGB3ANCNFSM5HL4NNFQ . 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]

Have a great weekend!

[RobTillaart]

After running for 24+ hours with 44200 full calls 4 fails ==> that is 1 in 11050 or 0.009 % Not zero but not too bad either,

OK  CRC     TOA     TOB     TOC     TOD     SNR     BS  WFR     UNK
44196   0   0   0   4   0   0   0   44199   0   

TIM CNT STAT    HUMI    TEMP    TIME    TYPE
88710300    88400   WFR,    66.4,   19.8,   3,  22
88711301    88401   OK, 66.3,   19.8,   5344,   22
88712307    88402   WFR,    66.3,   19.8,   3,  22
88713308    88403   OK, 66.3,   19.8,   5347,   22
88714315    88404   WFR,    66.3,   19.8,   4,  22
88715316    88405   OK, 66.2,   19.8,   5254,   22
88716322    88406   WFR,    66.2,   19.8,   3,  22
88717323    88407   OK, 66.2,   19.8,   5252,   22
88718330    88408   WFR,    66.2,   19.8,   3,  22
88719331    88409   OK, 66.2,   19.8,   5254,   22

[RobTillaart]

This morning

OK  CRC     TOA     TOB     TOC     TOD     SNR     BS  WFR     UNK
63996   0   0   0   4   0   0   0   63999   0   

after ~35 hours still only 4 TOC errors so better than 1 in 10.000

test setup

Board: MKR1010 Wifi Sketch: dhtnew_endless.ino Wires: ~20 cm between sensor and board, no pull-up resistor connected over breadboard (not soldered) Power sensor: 3.28 volt Power board: USB from laptop Data-pin: 5

[RobTillaart]

OK  CRC     TOA     TOB     TOC     TOD     SNR     BS  WFR     UNK
83717   0   0   0   8   0   0   0   83724   0   

After 46+ hours, still in the order of 1 in 10.000

[RobTillaart]

OK  CRC     TOA     TOB     TOC     TOD     SNR     BS  WFR     UNK
108191  0   0   0   9   0   0   0   108199  0   

after 60 hours, 100.000+ real reads => same failure rate (and all Timout C)

So that timeout seems the most critical / sensitive one

[ToineSiebelink]

Hi Rob,

That failure rate is definitely good enough for me :-D

I hope to test later today

thanks,

Toine

On Mon, 15 Nov 2021 at 09:40, Rob Tillaart @.***> wrote:

OK CRC TOA TOB TOC TOD SNR BS WFR UNK 108191 0 0 0 9 0 0 0 108199 0

after 60 hours, 100.000+ real reads => same failure rate (and all Timout C)

So that timeout seems the most critical / sensitive one

— 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-968707218, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEBXXAAGOXSFLRXLVLMTSXLUMDIRVANCNFSM5HL4NNFQ . 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.

[ToineSiebelink]

Hi Rob, apologies for the delay, I have now added the line to allow the interrupts and all my 6 sensors seem to work fine now with DHTNew library :-) well done! So this proves it works well in a real world situation with long cables etc. My system poll temperature every 90 seconds or so and reports to thinkSpeak every second iteration. I'l share my thinkspeak channel details with you later.

[RobTillaart]

No need to apologize, good to hear it works!

You might use setSuppressError(bool). to suppress error values in cases there is a timeout. Your graphs might look much nicer without spikes :)

[ToineSiebelink]

Channel #613783 Read API Key: JSGFE3HN1PPK9B3Q

I fall back on the previous value (store separately using my own code) to prevent spikes in my graphs ( I also don't want the heating to suddenly kick in/off for any good reason :-))

The first 5 fields have been pretty good since I started using DHTStable library a few months back. Just #6 (hot water) still is problematic:it starts failing after anything from 2 to 10 days. I'm pretty sure its a hardware issue, resetting the module using te reset button or even loading a new sketch doesn't fix it. But disconnecting power for a few seconds does fix it. I might try an external pull up resister 4.7K I think is what you advised earlier...

[RobTillaart]

Never used thingSpeak, how do I get to see the data - it says the channel is not public. (any URL?) A screenshot is satisfying enough for me BTW :)

Measuring Hot Water can be a problem for the sensor. I had problems in the past with humidity "freezing at 100%". I think these sensors operating at the edge of their specs for longer time is not what they are meant for.

For temperature of water I prefer the watertight DS18B20. Stable over a wide temperature range (-55°C .. 125°C). Several years ago I was involved in a project using them to measure temperatures on Antarctica. Long stick in the snow and every 20 cm or so was a sensor.
As these sensors can be connected on one bus all 10 of them only used one pin.

[RobTillaart]

How long is the wire to the hot water sensor? you might even need a lower resistor like 2K2 or even 1K (> 10 mtr)

Have you checked the voltage at the end near the sensor? If it drops below 3V3 it is out of spec and may "freeze" even near hot water :)

[RobTillaart]

Tried this URL - https://thingspeak.com/channels/613783/charts/6?api_key= Can see up to six charts (1 .. 6)

and some raw data.. https://thingspeak.com/channels/613783/fields/1?api_key=

https://thingspeak.com/channels/613783/feeds.json?api_key=

[ToineSiebelink]

good, you got Thingspeak working! (its cool actually and free up to something like 3 million data entries per year :-))

'Hot Water' is just measuring on the outside of a copper tank, so it is dry and the range is not huge; room temperature to 50c max. funny enough the hot-water is probably one of the shorter cables., about 2-3 meters. Does it make a difference what side the resistor is used ie. near the Arduino or near the sensor?

The Mkr Connector Carrier (https://store.arduino.cc/products/arduino-mkr-connector-carrier-grove-compatible) uses Grove connectors which are supplied with 5V so that is what I use for all sensors and I just check and measure 4.6 Volt at the sensor end. So what resistor size would you recommend? I got 220, 1k, 10k and 100k

[RobTillaart]

Does it make a difference what side the resistor is used ie. near the Arduino or near the sensor?

Yes, no electrical engineer by profession but this is how I think it works.

suppose the wire is long and near the board the voltage is 5V and it drops to 4V (just for the idea)

Pull up on sensor side If the sensor gives a HIGH it can only be 4V as its power is 4V and the pull up can only pull it up to 4V. As the signal drops another volt on the way back the voltage can be as low as 3V on the data Pin.

Pull up on board side If the sensor gives a HIGH it can only be 4V as its power is 4V. As the signal drops another volt on the way back the voltage can be as low as 3V on the data Pin. However there the pull up, can pull it up to the 5V again.