NewBee DHT readings. Non-linear?

[espruino-discuss3]

Posted at 2014-09-23 by user7114

I have noticed that when the temperature goes above greater than 21.6C or 71F the DHT22 humidity drops off by 20 RH%.It reads right below 71F? I haven't replaced this sensor yet but it might be the software(module)?
Note: This sensor is light sensitive and the poll rate should be > 2 seconds per Adafruit.
Note: I have tried shielding the signal/power lines. Added pull-ups to no avail.
Any ideas?

[espruino-discuss3]

Posted at 2014-09-23 by @gfwilliams

Just to check, are you using up to date firmware? And you're saying the temperature still reads right, it is just the humidity that is off?

I know there were some changes a while back that only worked with newer firmware. If you're up to date then it looks like a software issue though.

@drazzy - do you have any ideas about this?

---

Posted at 2014-09-23 by user7114

Just to check, are you using up to date firmware?

v71 - BigRam - Espruino v1.3

And you're saying the temperature still reads right, it is just the
humidity that is off?

Yes - off by 20 RH% (below expected)

---

Posted at 2014-09-23 by DrAzzy

Hm, I'm not sure how bad data could be getting through the module anymore, since (as of the extension of the event buffer) the module actually calculates it's own checksum, and compares it to the one provided by the part.

DHT22.prototype.endRead = function() {
    clearWatch(this.watch);
    var tcks = this.hout&0xFF;
    tcks+= (this.hout>>8)&0xFF;
    tcks+= (this.tout&0xFF);
    tcks+= (this.tout>>8)&0xFF;
    tcks=tcks&0xFF;
    if (tcks==this.cks && this.hout > 0 && this.tout > 0) {
        var rh=this.hout*0.1;
        var temp=this.tout*0.1;
        if (this.tout&0x8000) {
            temp=temp*-1;
        }
        if (rh < 100 ) {
            return {"temp":temp,"rh":rh};
        }
    }
    return {"temp":-1,"rh":-1};
};

Can you provide a few examples of correct and incorrect data that it's reported?

I have one that I believe is giving me accurate information while reading around 27.8C and 54.1% humidity.

---

Posted at 2014-09-23 by user7114

I have 3 humidity references near this DHT22 and they all read +-5 RH% from each other.
Like I said, when the temperature moves from the morning hours to afternoon hours from
the 60F to the higher 70F and above, the humidity drops off by 20RH% to its min. value of
20 RH%? As for values, I don't know what you want?

---

Posted at 2014-09-23 by DrAzzy

I'm sort of confused as to what you're seeing. The way I interpreted the original post, if the temperature the DHT reports is greater than 21.6, the humidity was off by 20% (implying that if you watched it go from 21.5c to 21.6c, you'd see the humidity drop - likely pointing to an issue reading the data incorrectly).
In that case, I'd like examples of the temperature and humidity (to the decimal) reported by the DHT, and for ones where the humidity is wrong, an estimate of what the humidity should be. Without examples of bad data, I can't figure out what my module is doing wrong in reading the DHT.

---

Posted at 2014-09-23 by user7114

Ok here goes...
Right now, the DHT22 temperature is 78.44F/25.8C and the DHT22 humidity is 23.5RH%. I have three other humidity devices that read 38RH%, 40RH% and my Nest is 40RH%. The temperature from my other devices read 77F/25C, 75F/23.89C, and 75F/23.89C .

---

Posted at 2014-09-23 by DrAzzy

Does it sometimes give correct values? If so, let me know the temperature/humidity when it gets it right. I'm basically looking for datapoints, so I can reconstruct the bitstreams that would have produced them, and try to see how it could have failed in this way. More examples are helpful, since I'm looking for patterns

I wager that the humidity is bitshifted to the right one (halving it)... but I'm not sure, looking at the code, how this could happen, since there's the checksum. (which is why I'd like to see more data points - to confirm or refute my theory that humidity is getting bitshifted right).

Also, I'll try it out with latest bigram tonight and see if that breaks my readings (my setup is currently on 70)

---

Posted at 2014-09-23 by user7114

Does it sometimes give correct values?

Yes indeed, as I stated above. Below ~ 70F the humidity reads OK. I will take another reading
in the morning.

---

Posted at 2014-09-24 by user7114

Today, the temp is 72.86 F and the humidity is 40.4 RH%. This matches correctly all my other references. The unknown is the exact temperature crossover point that the humidity drops?

Addition: At ~73.94F the humidity drops to 20.3 RH%. This RH% reading is bad.

---

Posted at 2014-09-24 by DrAzzy

Yeah, it's definitely getting shifted right 1 bit... hmm...

I can't see how this is happening. If I can't reproduce on latest bigram, I'll post a debug version that'll record everything.

---

Posted at 2014-09-25 by @gfwilliams

The actual code is quite small - I wonder if you could just produce a single file that could be pasted into the right hand pane that would display all the debug data?

By the way, looking at the code it might be 'nicer' to create a string of 1s and 0s. You could then use parseInt(data.substr(...),...,...) to extract the data... Might be worth a try - now ints are only 32 bit I should probably change a lot of the example code (like IR) to work a similar way.

---

Posted at 2014-09-26 by DrAzzy

var dht = require("http://drazzy.com/e/espruino/etc/dht22debug.js").connect(C11); 
dht.read(function (a) {console.log("Temp is "+a.temp.toString()+" and RH is "+a.rh.toString());});

(change the pin to whatever pin you have connected to it)

Please run that while it's at a temperature it fails at and post the results that it logs.

---

Posted at 2014-09-26 by user7114

I like to try to be clear ...
The temperature in which the humidity fails at is directly tied to the "ambient" temperature not the temperature generated by the DHT22.

The data stream from the DHT22 sends out the temperature first then the humidity RH% which is somehow corrupted even with a checksum?

BTW ... on the other hand, just maybe, the 8 bit processor in the DHT22 has its calibration curves screwed up!

---

Posted at 2014-09-26 by @gfwilliams

The data stream from the DHT22 sends out the temperature first then the humidity RH% which is somehow corrupted even with a checksum?

I think @drazzy's hunch is that the data is not corrupt, it is just being interpreted badly (such that a bit is in the wrong place).

Anyway, some data from his code above would help to narrow it down.

---

Posted at 2014-09-26 by DrAzzy

@gfwilliams that's exactly why. This is the kind of problem that happened occasionally before we were able to use the checksum (thanks to the espruino event buffer size change)

---

Posted at 2014-09-27 by DrAzzy

I would really like to see that data - if you could run that, I'd really appreciate it.

I just encountered another issue with a sensor (BMP180) outputting values that are erroneously bitshifted one bit to the right under circumstances that remain unclear.

Also, just updated the debug module so it logs even more data.

---

Posted at 2014-09-27 by user7114

I would give you the data if it fails but I think you jinz my Espruino and now it refuses to give bad data!

---

Posted at 2014-09-27 by user7114

@drazzy The data you asked for ...
The humidity reading should be 42RH%

 1v71 Copyright 2014 G.Williams
>echo(0);
=undefined
plen=0.00008201599 bit:0
plen=0.00002479553 bit:1
hout=undefined
plen=0.00002479553 bit:2
hout=undefined
plen=0.00002479553 bit:3
hout=undefined
plen=0.00002479553 bit:4
hout=undefined
plen=0.00002479553 bit:5
hout=undefined
plen=0.00002479553 bit:6
hout=undefined
plen=0.00002479553 bit:7
hout=undefined
plen=0.00002384185 bit:8
hout=undefined
plen=0.00007247924 bit:9
hout=undefined
plen=0.00007152557 bit:10
hout=undefined
plen=0.00002479553 bit:11
hout=undefined
plen=0.00006866455 bit:12
hout=undefined
plen=0.00007247924 bit:13
hout=undefined
plen=0.00007152557 bit:14
hout=undefined
plen=0.00002479553 bit:15
hout=undefined
plen=0.00007057189 bit:16
hout=undefined
plen=0.00002574920 bit:17
tout=undefined
plen=0.00002574920 bit:18
tout=undefined
plen=0.00002574920 bit:19
tout=undefined
plen=0.00002574920 bit:20
tout=undefined
plen=0.00002574920 bit:21
tout=undefined
plen=0.00002574920 bit:22
tout=undefined
plen=0.00002384185 bit:23
tout=undefined
plen=0.00007057189 bit:24
tout=undefined
plen=0.00002574920 bit:25
tout=undefined
plen=0.00002574920 bit:26
tout=undefined
plen=0.00002574920 bit:27
tout=undefined
plen=0.00002574920 bit:28
tout=undefined
plen=0.00007247924 bit:29
tout=undefined
plen=0.00002574920 bit:30
tout=undefined
plen=0.00002574920 bit:31
tout=undefined
plen=0.00007057189 bit:32
tout=undefined
plen=0.00007152557 bit:33
cks=undefined
plen=0.00007247924 bit:34
cks=undefined
plen=0.00007152557 bit:35
cks=undefined
plen=0.00002479553 bit:36
cks=undefined
plen=0.00002479553 bit:37
cks=undefined
plen=0.00007152557 bit:38
cks=undefined
plen=0.00007152557 bit:39
cks=undefined
plen=0.00007152557 bit:40
cks=undefined
11011101
100001001
11100111
Temp is 26.5 and RH is 22.1
> 

---

Posted at 2014-09-27 by DrAzzy

ARGH! I omitted a key part in the debug version, which is why it kept reporting undefined instead of a value. I've fixed it now, so resending to Espruino will give it the new version

But... I'm looking at the bit lengths it's returning... and it's really giving 8 zeros at the front of the humidity...

plen=0.00002479553 bit:1
hout=undefined
plen=0.00002479553 bit:2
hout=undefined
plen=0.00002479553 bit:3
hout=undefined
plen=0.00002479553 bit:4
hout=undefined
plen=0.00002479553 bit:5
hout=undefined
plen=0.00002479553 bit:6
hout=undefined
plen=0.00002479553 bit:7
hout=undefined
plen=0.00002384185 bit:8

---

Posted at 2014-09-27 by user7114

Again ...

 1v71 Copyright 2014 G.Williams
>echo(0);
=undefined
plen=0.00007915496 bit:0
plen=0.00002479553 bit:1
hout=0
plen=0.00002479553 bit:2
hout=0
plen=0.00002479553 bit:3
hout=0
plen=0.00002479553 bit:4
hout=0
plen=0.00002479553 bit:5
hout=0
plen=0.00002479553 bit:6
hout=0
plen=0.00002479553 bit:7
hout=0
plen=0.00002384185 bit:8
hout=0
plen=0.00007152557 bit:9
hout=1
plen=0.00007152557 bit:10
hout=3
plen=0.00002574920 bit:11
hout=6
plen=0.00002574920 bit:12
hout=12
plen=0.00007152557 bit:13
hout=25
plen=0.00002479553 bit:14
hout=50
plen=0.00007152557 bit:15
hout=101
plen=0.00007057189 bit:16
hout=203
plen=0.00002479553 bit:17
tout=0
plen=0.00002479553 bit:18
tout=0
plen=0.00002479553 bit:19
tout=0
plen=0.00002574920 bit:20
tout=0
plen=0.00002574920 bit:21
tout=0
plen=0.00002574920 bit:22
tout=0
plen=0.00002574920 bit:23
tout=0
plen=0.00007152557 bit:24
tout=1
plen=0.00002574920 bit:25
tout=2
plen=0.00002574920 bit:26
tout=4
plen=0.00002574920 bit:27
tout=8
plen=0.00002574920 bit:28
tout=16
plen=0.00002574920 bit:29
tout=32
plen=0.00007247924 bit:30
tout=65
plen=0.00007152557 bit:31
tout=131
plen=0.00002384185 bit:32
tout=262
plen=0.00007152557 bit:33
cks=1
plen=0.00007247924 bit:34
cks=3
plen=0.00002574920 bit:35
cks=6
plen=0.00007152557 bit:36
cks=13
plen=0.00002479553 bit:37
cks=26
plen=0.00002479553 bit:38
cks=52
plen=0.00007152557 bit:39
cks=105
plen=0.00002479553 bit:40
cks=210
11001011
100000110
11010010
Temp is 26.2 and RH is 20.3
> 

---

Posted at 2014-09-28 by DrAzzy

Bitstream is consistent with the results returned, ie, 0000000011001011000000010000011011010010

The checksum the device is returning is consistent with the incorrect result.

I conclude that your device is defective. Those things have temperature correction algorithms built in - I suspect that this what is bad. They may well program these things individually (in a high speed automated test device) to set the coefficients to correct for individual variation between humidity sensors - it's thus not entirely implausible. I'll bet you could find an exact temperature (let me guess - 25.6C) at which it starts failing, and correct for it (ex, function (a) {var rh=a.temp>25.6?a.rh<<1:a.rh;console.log("Temp is "+a.temp.toString()+" and RH is "+rh.toString());})

---

Posted at 2014-09-28 by user7114

BTW ... on the other hand, just maybe, the 8 bit processor in the
DHT22 has its calibration curves screwed up!

I will buy another one, from a different vendor source, and re-test it.
I sent a complaint to Aosong and I am holding my breath that they will respond.