I have 6 DHT22 sensor connected to a WifiMkr1010 Board (sensors connected via a MKR Co

<a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/us

cheapest and in stock so far: <a href="https://www.reichelt.nl/nl/nl/arduino-mkr10

read() hangs with MkrWiFi + MkrConnector Board,about robtillaart/dhtnew

Comments (66)

ToineSiebelink commented on June 21, 2024 1

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 <#67 (comment)>, 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>.

from dhtnew.

RobTillaart commented on June 21, 2024

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)

from dhtnew.

RobTillaart commented on June 21, 2024

@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;
}

from dhtnew.

ToineSiebelink commented on June 21, 2024

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 <#67 (comment)>, 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>.

from dhtnew.

RobTillaart commented on June 21, 2024

OK, will wait for your results tomorrow.

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

from dhtnew.

ToineSiebelink commented on June 21, 2024

agreed, we wont more Double Dutch :-)

from dhtnew.

RobTillaart commented on June 21, 2024

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

from dhtnew.

RobTillaart commented on June 21, 2024

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

from dhtnew.

ToineSiebelink commented on June 21, 2024

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)

from dhtnew.

RobTillaart commented on June 21, 2024

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)

from dhtnew.

RobTillaart commented on June 21, 2024

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

from dhtnew.

ToineSiebelink commented on June 21, 2024

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

from dhtnew.

RobTillaart commented on June 21, 2024

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.

from dhtnew.

ToineSiebelink commented on June 21, 2024

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?!

from dhtnew.

RobTillaart commented on June 21, 2024

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.

from dhtnew.

ToineSiebelink commented on June 21, 2024

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 :-(

from dhtnew.

RobTillaart commented on June 21, 2024

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

from dhtnew.

RobTillaart commented on June 21, 2024

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

from dhtnew.

ToineSiebelink commented on June 21, 2024

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....

from dhtnew.

RobTillaart commented on June 21, 2024

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.

from dhtnew.

ToineSiebelink commented on June 21, 2024

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 [email protected])

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....

from dhtnew.

RobTillaart commented on June 21, 2024

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.

from dhtnew.

RobTillaart commented on June 21, 2024

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.

from dhtnew.

RobTillaart commented on June 21, 2024

@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?

from dhtnew.

RobTillaart commented on June 21, 2024

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

from dhtnew.

RobTillaart commented on June 21, 2024

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

from dhtnew.

RobTillaart commented on June 21, 2024

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.

from dhtnew.

RobTillaart commented on June 21, 2024

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 :)

from dhtnew.

RobTillaart commented on June 21, 2024

  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.

from dhtnew.

RobTillaart commented on June 21, 2024

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 ...

from dhtnew.

RobTillaart commented on June 21, 2024

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.

from dhtnew.

RobTillaart commented on June 21, 2024

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...

from dhtnew.

RobTillaart commented on June 21, 2024

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

from dhtnew.

RobTillaart commented on June 21, 2024

@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)

from dhtnew.

RobTillaart commented on June 21, 2024

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)

from dhtnew.

RobTillaart commented on June 21, 2024

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.

from dhtnew.

ToineSiebelink commented on June 21, 2024

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 <#67 (comment)>, 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>.

from dhtnew.

RobTillaart commented on June 21, 2024

Have a great weekend!

from dhtnew.

RobTillaart commented on June 21, 2024

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

from dhtnew.

RobTillaart commented on June 21, 2024

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

from dhtnew.

RobTillaart commented on June 21, 2024

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

from dhtnew.

RobTillaart commented on June 21, 2024

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

from dhtnew.

ToineSiebelink commented on June 21, 2024

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.

from dhtnew.

RobTillaart commented on June 21, 2024

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 :)

from dhtnew.

ToineSiebelink commented on June 21, 2024

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...

from dhtnew.

RobTillaart commented on June 21, 2024

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.

from dhtnew.

RobTillaart commented on June 21, 2024

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 :)

from dhtnew.

RobTillaart commented on June 21, 2024

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=

from dhtnew.

ToineSiebelink commented on June 21, 2024

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

from dhtnew.

RobTillaart commented on June 21, 2024

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.

from dhtnew.

RobTillaart commented on June 21, 2024

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.

from dhtnew.

ToineSiebelink commented on June 21, 2024

thanks for the tips. I'll try that!

from dhtnew.

RobTillaart commented on June 21, 2024

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?

from dhtnew.

ToineSiebelink commented on June 21, 2024

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 <#67 (comment)>, 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>.

from dhtnew.

RobTillaart commented on June 21, 2024

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 ;)

from dhtnew.

RobTillaart commented on June 21, 2024

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

still going well

from dhtnew.

RobTillaart commented on June 21, 2024

PR created - #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

from dhtnew.

RobTillaart commented on June 21, 2024

PR merged.

from dhtnew.

RobTillaart commented on June 21, 2024

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.

from dhtnew.

ToineSiebelink commented on June 21, 2024

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 <#67 (comment)>, 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>.

from dhtnew.

RobTillaart commented on June 21, 2024

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

from dhtnew.

ToineSiebelink commented on June 21, 2024

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 <#67 (comment)>, 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>.

from dhtnew.

RobTillaart commented on June 21, 2024

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

from dhtnew.

RobTillaart commented on June 21, 2024

DHTNEW 0.4.10 released

from dhtnew.

RobTillaart commented on June 21, 2024

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

from dhtnew.

RobTillaart commented on June 21, 2024

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.

from dhtnew.

read() hangs with MkrWiFi + MkrConnector Board about dhtnew HOT 66 CLOSED

Comments (66)

Debugging started

test setup

Related Issues (20)

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent