NewBee DHT readings. Non-linear?

Posted on
  • 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?

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

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

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

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

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

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

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

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

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

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

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

  • var dht = require("http://drazzy.com/e/espruino/et­c/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.

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

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

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

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

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

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

  • 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
    > 
    
  • 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());})

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

  • Post a reply
    • Bold
    • Italics
    • Link
    • Image
    • List
    • Quote
    • code
    • Preview
About

NewBee DHT readings. Non-linear?

Posted by Avatar for user7114 @user7114

Actions