Does the DHT22 'cache' the readings?

[CyberFerret]

Hey all,

Got an odd issue with a project that uses the DHT22 Temp and Humidity sensor.

I am using Bluetooth to query and read results from the sensor. I also have a button on my breadboard which can be used to read and instantly transmit the readings via bluetooth.

Very simple code. Upon button press or a sequence of characters from the Bluetooth Rx buffer, I execute

Code: Select all

float v1 = dht.readTemperature();
float v2 = dht.readHumidity();

The problem is, whenever I call the above, the results in v1 and v2 seem to either exactly the same, or very close to the last set of results received. If I then immediately call the above again, then the results returned are very different.

Code: Select all

05/10/2014 03:15pm  ~tempC: 32.10 tempF: 89.78 humidity: 58.00
06/10/2014 09:45am  ~tempC: 32.10 tempF: 89.78 humidity: 57.90
06/10/2014 09:46am  ~tempC: 29.70 tempF: 85.46 humidity: 64.40

In the above, you can see I queried the DHT22 for a reading yesterday afternoon. Then I did so again this morning, and got pretty much the same reading as yesterday. Then I immediately re-queried the DHT22 and got new results which were closer to what was expected.

Should I be placing a delay() in between the reading to prevent some sort of buffer overrun on the DHT22 ??

Thanks,
Devan

[andrew]

There isn't a buffer as such.
Could you please post your sketch so we can see what might be causing the condition?

[CyberFerret]

Thanks for the reply. Here is my sketch below. I have stripped it back to bare bones. The sketch also drives a MicroView display with gauges showing the values, but I have stripped that code out for simplicity. The MicroView was only kicked on by the button press, not the Bluetooth trigger anyhow, so the code was essentially separate from the start.

Code: Select all

#include <SoftwareSerial.h>      // Bluetooth comms library
#include <DHT.h>                // Temperature and humidity sensor

#define DHTPIN A0
#define DHTTYPE DHT22

#define rxPin 2
#define txPin 3

DHT dht(DHTPIN, DHTTYPE);

SoftwareSerial BTserial(rxPin, txPin);

int buttonPin = A1;              // Press button
int buttonState = 0;
int inByte;

float temperatureC, temperatureF, humidityP;


void setup() {
  dht.begin();
  // prepare button
  pinMode(buttonPin, INPUT);
  digitalWrite(buttonPin, HIGH);
  // prepare Bluetooth
  BTserial.begin(9600);
}

void loop() {
  // check for button press
  buttonState = digitalRead(buttonPin);

  if (buttonState != HIGH) {
    getReadings();
    transmitDataBT();
  }
    
  // check for Bluetooth instigated query
  if (BTserial.available() > 0) {      
    inByte = BTserial.read();
    delay(10);
    BTserial.write(inByte); // write it back
    if (inByte == 126) { // 126="~" character, which is what we want
      getReadings();
      transmitDataBT();
    }
  }
}

void getReadings() {
  // Calculate values
  humidityP = dht.readHumidity();
  temperatureC = dht.readTemperature();
  temperatureF = dht.convertCtoF(temperatureC);
}


void transmitDataBT() {
  // Send log to Bluetooth listener
  BTserial.print("tempC: ");
  BTserial.print(temperatureC);
  BTserial.print(" tempF: ");
  BTserial.print(temperatureF);
  BTserial.print(" humidity: ");
  BTserial.println(humidityP);
}

[andrew]

The DHT22 can only be sampled once every two seconds, put a delay(2000) at the start of void getReadings() and see what happens.

[csconsulting]

I also have this odd feeling that the "Read" process actually starts the internal processing of the sensor readings ready for the next read. So you are always getting the results of the last actual reading, not the current reading.

[Liradon]

I also have this odd feeling that the "Read" process actually starts the internal processing of the sensor readings ready for the next read. So you are always getting the results of the last actual reading, not the current reading.

I can confirm you odd feeling. I have the exact same issue.
I stumbled upon this issue because I want to take readings every 5 minutes, not every 2 seconds like (I think) every hobby project this sensor is used for.
I noticed that when I breathed on the sensor to increase the humidity, the next reading I took would still be around 40% - 50% (normal humidity levels). The reading I took after that, the humidity level spiked towards 99%.
The same goes the other way around. When I increased the humidity and took a readin, then taking another reading after 5 minutes, the sensor would return a humidity level of 99%. Taking a reading 2 seconds after that returns a normal humidity level, around 40% - 50%.

I've been looking for an explanation for a very long time, but it seems nobody (except you two) stumbled upon this issue before.

I solved this by "flushing" the sensor's cache before actually taking the reading of the values I want. I do this by reading the sensor's values (which returns the cached values, but triggers the mechanism to read the current values), waiting 2 seconds and than reading the values again, returning a close-to-real-time value of the actual temperature and humidity.

I hope this still provides some value for you, even though it's 6 years after your post. Just felt I had to answer, to help anybody else with this same issue in the future.