New joint DHT11/DHT22 module

I set the timeout to 30us and it works !

quoting the datasheet:

Data-bus's free status is high voltage level. When communication between MCU and DHT22 begin, program of MCU will transform data-bus's voltage level from high to low level and this process must beyond at least 1ms to ensure DHT22 could detect MCU's signal, then MCU will wait 20-40usfor DHT22's response.

@MaBe

I set the timeout to 30us and it works !

Where did you change this?

I changed in this line the value to 30, and its working good, now it is always reads good value, no error

  },20); // time in msec (min 15 virker) 6 20 // PB

@Wilberforce

https://github.com/espruino/EspruinoDocs/blob/master/devices/DHT22.js#L45

replace 6 with 30 and test again

It is really good for me now, there is no error with this new version.

@Gordon should we add a second parameter to pass the timeout used to delay the start of decode
in module DHT22 ?

I'd just make it 30ms regardless.

I guess as usual, this is only actually a problem on ESP8266, and not any of the proper Espruino boards?

You do know the text you quoted says 20-40uS, but the timeout is 30ms so 1000 times longer?

Thanks - mixed up units ... - back for checking and testing ...

changes to module DHT22:

....
  setTimeout(function() {

    pinMode(D5,'output');digitalPulse(D5, 0, 1) // fire a 1ms  marker 

    clearWatch(ht.watch);
    delete ht.watch;
....
    }
  },6);
};
....

sample DHT22 code:

E.on("init",function(){

  dht = require("DHT22").connect(D4);

  setInterval(function(){
    dht.read(function (a) { 
      console.log("t = "+a.temp.toFixed(1).toString()
                  +", rh = "+a.rh.toFixed(1).toString()
                  //+"\nraw:"+a.raw+
                  //+"\nerr:"+a.err+
                  //+", cse:"+a.checksumError
                 );},
      1);

  },2000);
});

save();

output is -1 for both value, changing 6 to 30 I receive correct values.

plus logic analyzer screen shot "001.jpg" of on dht.read

Question: why is the marker fired so late ?

1 Attachment

You can't just replace the pinMode(ht.pin,'input_pullup'); with a digitalPulse (which it seems you've done). It'll mean the DHT22 is fighting against the Espruino board to pull the signal line low and something might get damaged.

As far as I can tell, the marker isn't fired late. It should immediately set the pin low, then set it to 'input_pullup' after 1ms. It then waits 5ms for the response.

My guess is that on ESP8266, it often messes up the timing (maybe WiFi needs to process something for a few ms) and executes the pinMode and the other timeout right after each other, so there is no time for the result to appear.

I guess you could work around this by just nesting the timeouts?

  setTimeout(function() {pinMode(ht.pin,'input_pullup');},1);
  setTimeout(function() {

to:

  setTimeout(function() {
    pinMode(ht.pin,'input_pullup');
    setTimeout(function() {
    // ...
    }, 6);
  },1);

DHT22 is on pin D4 and pulse is on D5

I'm running three DHT22. Most of the readings are erroneous, returning -1,-1 (no checksum error). My sensors are several meters away and the supply voltage is 5v. It works flawlessly with an old module I found online. I also tried some DHT11's and couldn't get them to work at all with the current module.

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.

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

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?

Now it works with the new software module - with the DHT22 connected 9 meters away!

PICO v1.88
DHT22

.....
  },6);
}
// Test with
var dht = new HT("DHT22",B3);
setInterval(function () {

dht.read(print);
},1000);

This gives:

{
  "raw": "0100000001001000010000000011011001111110111",
  "rh": 28.9, "t": -21.7 }
{ "err": true,
  "raw": "0100000001001000110000000011011010111111"
 }
{ "err": true,
  "raw": "01"
 }

Change the 6 to 50

    } else {
      if (n>1) setTimeout(function() {ht.read(cb,--n);},500);
      else cb({err:true, raw:d});
    }
  },50);
};

This works and gives:

{
  "raw": "010000000100011110000000001101100111111000",
  "rh": 28.6, "t": 21.7 }
{
  "raw": "010000000100011111000000001101101011111010",
  "rh": 28.7, "t": 21.8 }
{
  "raw": "010000000100011110000000001101100111111000",
  "rh": 28.6, "t": 21.7 }

Also works with a value of 30.

stick to 50 - it is a safe value - check the data sheet (20-40uS)

@ClearMemory041063 I updated the module to use a 50ms timeout almost 2 weeks ago now. Are you somehow using an old version of it?

The DHT22 module is not working from the modules page.
To troubleshoot:

1. copied the un-minified version DHT22.js to local projects/modules directory, tested and it works.
   
2. copied DHT22.min.js to local projects directory and I get the -1 values.
   Please check the DHT22.min.js file.
   Thanks
   

Strange... the minified version definitely uses the 50ms delay too now: http://www.espruino.com/modules/DHT22.min.js

It work now.
Thanks!

It work now.

But I didn't change anything! :) Maybe it was some cacheing problem?

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!
After a while it works again.

It would really help to know the reason and have some kind of (manually) cache clearing.