read() hangs with MkrWiFi + MkrConnector Board #67
Comments
|
Hoi Toine, 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) |
|
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;
} |
|
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>.
|
|
OK, will wait for your results tomorrow. // ik begrijp dat je ook NL spreekt, maar hou de discussies op GitHub bij voorkeur in EN. |
|
agreed, we wont more Double Dutch :-) |
|
The DHTStable library is not out of support for bugs but new ideas and features will all be in the DHTNew . Thereafter we can find out how to get DHTNEw to work on the MKr1010. |
|
cheapest and in stock so far: |
|
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) |
|
Thank you for testing, I will create a new release of it this weekend. I will to give you credits in the code for your time (If you like) |
|
no problem! 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 |
|
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. 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. |
|
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 You think speed might be the issue?! |
|
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
|
|
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 :-( |
|
FYI, I have merged the working read() into DHTSTable master. |
|
@ToineSiebelink |
|
Hi Rob, I think the MKR1010 or the connector carrier board might have built in pull up resistors I am not sure. |
|
Agree, the problem is definitely in the timing of the DHTNew lib. I ordered two MKR1010's so if time permits I can start investigating too. |
|
I just tested using a breadboard with just 1 sensor with and without 10k pull up resistor. Still the same results :-( 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.... |
|
Thanks for giving it a try, |
Good find, although I expect there is little difference as the internal PULLUP is often in the order of 50K for most noards. |
|
Got my MKR1010 Wifi boards and I have a problem with uploading a sketch.
Any clue how to get that board more stable? |
|
Sometimes after reset the ORANGE led is fading in and out (frequency ~ 1 Hz) |
|
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. Followed guidelines - https://www.arduino.cc/en/Guide/MKRWiFi1010 |
|
See this often when trying to upload. Probably I miss one or two crucial steps but the first hour with the MKR1010 Wifi is not a success. |
|
This looks like a successful upload 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 :) |
while(!Serial);adding that line seems to make the difference for the Serial monitor ... as I was able to reproduce your error. Now I must learn to do this upload etc smoothly. |
|
After running for 24+ hours with 44200 full calls 4 fails ==> that is 1 in 11050 or 0.009 % |
|
This morning after ~35 hours still only 4 TOC errors so better than 1 in 10.000 test setupBoard: MKR1010 Wifi |
After 46+ hours, still in the order of 1 in 10.000 |
after 60 hours, 100.000+ real reads => same failure rate (and all Timout C) So that timeout seems the most critical / sensitive one |
|
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>.
|
|
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. |
|
No need to apologize, good to hear it works! You might use setSuppressError(bool). to suppress error values in cases there is a timeout. |
|
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... |
|
Never used thingSpeak, how do I get to see the data - it says the channel is not public. (any URL?) 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). |
|
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? |
|
Tried this URL - https://thingspeak.com/channels/613783/charts/6?api_key= and some raw data.. |
|
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. 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 |
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 Pull up on board side |
recommend 1K I use this book as a reference - https://www.amazon.co.uk/Practical-Electronics-Inventors-Fourth-Scherz/dp/1259587541 For my commercial projects I work together with an Electric Engineer so he "fixes" my hardware schemes. |
|
thanks for the tips. I'll try that! |
|
FYI 128000 real reads 10 fails => 1 in 10K still holds. Unless there are other related questions, I think the issue can be closed? |
|
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>.
|
|
Yes, the library did not change so I only need to
so a bit more than just the readme, but no breaking stuff. |
still going well |
|
PR created - #68 stable 1 in 10.000 ==> going to adjust timing a bit to see if that reduces it |
|
PR merged. |
|
update test with slightly longer timeout C (90 micros in stead of 70 micros) 1x SNR - Sensor not Ready but no other (timeout) errors although I expected 2 or 3 so looks promising as an improvement. |
|
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>.
|
|
You can't make the time shorter than the specs otherwise you don't have a measurement.
(backgrounder) 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. 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. I will try to keep the setup running to see how much better it is . now at 41424, still no timeout, only one SNR |
|
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>.
|
|
So after 40+ hours and 74000++ reads no TOC error anymore, so time to prepare a PR. |
|
DHTNEW 0.4.10 released |
|
going towards 80 hrs...still going strong. 92 hrs. tomorrow I stop the testrun. 114 hrs, ... 162 hrs |
|
Note: found the define to set the IRQ flag in the library #ifdef ARDUINO_SAMD_MKRWIFI1010
#error found
#endifintention to include this in the library sometime. |
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
!
The text was updated successfully, but these errors were encountered: