New joint DHT11/DHT22 module #900
Replies: 76 comments
-
Posted at 2016-02-05 by DrAzzy Why wouldn't we keep separate modules, keep the API the same, and get rid of the old DHTxx modules, if this works and is faster? This would make the module take up a couple fewer jsvars too, which is an issue that you have to keep in mind since we don't have a compiler to optimize out unreachable code like we do on Arduino - this weakens the argument for "one library that does a whole bunch of devices" paradigm. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2016-02-06 by @gfwilliams Yes, I was starting to think that - the code itself is quite simple, and the duplication is probably worth it to simplify things. I guess it depends whether there are any other differences between them apart from just DHT11 and DHT22? |
Beta Was this translation helpful? Give feedback.
-
Posted at 2016-02-11 by @gfwilliams Please can someone test this on DHT22? Then both modules can be updated to use the more efficient code. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2016-02-12 by DrAzzy I'll try to test on mine this weekend. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2016-02-12 by @MaBecker I will test too over the weekend |
Beta Was this translation helpful? Give feedback.
-
Posted at 2016-02-15 by @MaBecker working fine on ESP, build version see test output comments: I prefer a fixed result format, e.g. 999.9
|
Beta Was this translation helpful? Give feedback.
-
Posted at 2016-02-15 by @gfwilliams That's good to know... @mabe have you tried |
Beta Was this translation helpful? Give feedback.
-
Posted at 2016-02-15 by @MaBecker yes, that's it - thanks.
|
Beta Was this translation helpful? Give feedback.
-
Posted at 2016-03-01 by @gfwilliams @mabe I've just committed some code specifically for DHT22 - please could you give it a test?
|
Beta Was this translation helpful? Give feedback.
-
Posted at 2016-03-01 by @MaBecker @gordon sure, will run some test on Thursday |
Beta Was this translation helpful? Give feedback.
-
Posted at 2016-03-04 by @MaBecker test results for code above on ESP8266
ESP8266 hint: require("ESP8266").setCPUFreq(80); |
Beta Was this translation helpful? Give feedback.
-
Posted at 2016-03-04 by @gfwilliams So there is something wrong? Or is it really that cold where you are? :) |
Beta Was this translation helpful? Give feedback.
-
Posted at 2016-03-04 by @MaBecker sorry, should show +22.3 and not -22.3 |
Beta Was this translation helpful? Give feedback.
-
Posted at 2016-03-04 by @gfwilliams So is it actually showing the right thing, or is it broken? |
Beta Was this translation helpful? Give feedback.
-
Posted at 2016-03-04 by @MaBecker old version shows 22.3 and new -22.3 |
Beta Was this translation helpful? Give feedback.
-
Posted at 2016-09-01 by CanyonCasa In short these devices are not really designed to be "several meters away". Bottom line, they may just not work at such distances. Some issues to consider... I would first try to talk to the devices connected directly together and not several meters apart across cabling. The outcome tells you whether this is a software or hardware problem. I suspect very likely switching times are too fast for long distances and/or the capacitive loading too large to drive. Rule of thumb: if the signal rise/fall times are less than 10ns/ft the cable will exhibit transmission line effects, meaning reflections that degrade signal integrity. For example, if several meters were say equal to 15ft, then rise/falls less than 150 ns will cause reflections, likely degrading signal integrity, where faster equates to more degradation. Second rule of thumb: most cabling will contribute ~50 pF/ft. So, a 15' cable would present a hefty 750 pF load that the DHTxx must drive. One thing that may help both cable problems would be to add a small series resistance at the device, 1-10 ohms/ft. The large capacitive load will lead to large supply spiking currents that requires local supply bypassing, meaning you need a capacitor AT THE DEVICE connected between VDD and VSS. Third rule of thumb: bypass cap >100X loading; if larger than 0.1 uF then parallel with a 0.01 uF or smaller, which improves high frequency response. What kind of cabling? Open wiring (i.e. just individual wires) will exhibit more variability and crosstalk when transmission line effects come into play. May be better off using coax. Note, all these problems apply to the Espruino end of the line as well since it must drive the initialization pulse. If you have a scope, probing the signals at each end would shed a lot of light on the situation. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2016-09-02 by Maarten Thanks for your informative reply. There sure are lots of factors worth considering. But what I ment by "old module" was the old version of the software module for Espruino. My sensors are actually 26ft/8m away and connected through common telephone cable. They work flawlessly with the old software. Why it doesn't work with the new software is beyond my competence in electronics. Regarding long distance TTL signals I also have relay modules and IR signal LEDs connected 8 meter away. It works well but sometimes the IR signals doesn't get interpreted by the receiving end. I wonder if the long distance TTL signals will harm the output pins of the board though (given the current spikes). |
Beta Was this translation helpful? Give feedback.
-
Posted at 2016-09-05 by @gfwilliams Which type of board are you using the sensors with? Also, could you try one closer in case it is something related to the distance? |
Beta Was this translation helpful? Give feedback.
-
Posted at 2016-11-20 by Maarten Now it works with the new software module - with the DHT22 connected 9 meters away! |
Beta Was this translation helpful? Give feedback.
-
Posted at 2016-11-20 by ClearMemory041063 PICO v1.88
This gives:
Change the 6 to 50
This works and gives:
|
Beta Was this translation helpful? Give feedback.
-
Posted at 2016-11-20 by ClearMemory041063 Also works with a value of 30. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2016-11-20 by @MaBecker stick to 50 - it is a safe value - check the data sheet (20-40uS) |
Beta Was this translation helpful? Give feedback.
-
Posted at 2016-11-21 by @gfwilliams @ClearMemory041063 I updated the module to use a 50ms timeout almost 2 weeks ago now. Are you somehow using an old version of it? |
Beta Was this translation helpful? Give feedback.
-
Posted at 2016-11-21 by ClearMemory041063 The DHT22 module is not working from the modules page.
|
Beta Was this translation helpful? Give feedback.
-
Posted at 2016-11-21 by @gfwilliams Strange... the minified version definitely uses the 50ms delay too now: http://www.espruino.com/modules/DHT22.min.js |
Beta Was this translation helpful? Give feedback.
-
Posted at 2016-11-21 by ClearMemory041063 It work now. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2016-11-21 by @gfwilliams
But I didn't change anything! :) Maybe it was some cacheing problem? |
Beta Was this translation helpful? Give feedback.
-
Posted at 2016-11-21 by luwar Yes, that's possible. There is indeed some kind of caching inside the WebIDE. I use a minification proxy so I can see all requests to http://www.espruino.com/modules. Normally a press to "Send to Espruino" fetches the required modules. But sometimes it doesn't. Even a restart of the WebIDE and the controller does not help in this case! It would really help to know the reason and have some kind of (manually) cache clearing. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2016-11-21 by @gfwilliams I think it might be Chrome itself... Hard to know what I can do as I've already set up the website to send anti-caching headers (you can check). |
Beta Was this translation helpful? Give feedback.
-
Posted at 2016-11-24 by CanyonCasa FYI. Good tutorial on DHT22 at http://www.nutsvolts.com/magazine/article/march2013_Henry?utm_source=Newsletter+%2368&utm_campaign=Newsletter+%2368&utm_medium=email |
Beta Was this translation helpful? Give feedback.
-
Posted at 2016-02-05 by @gfwilliams
Hi,
It's come up in another thread that the existing DHT11 & 22 modules aren't that fast or memory efficient. There's been a pull request for a multipurpose module, but it's still slower than it could be, and doesn't work in a backwards-compatible way with DHT11.
I don't have a DHT22 here so can't test, but maybe someone else could take a look at this and see if it works on all the various different module types, or whether we need a few more tweaks?
I can then put it into a
HTxx
module, and can reference that from existing DHT11/22 modules to provide a seamless upgrade for everyone already using them.Beta Was this translation helpful? Give feedback.
All reactions