Adafruit CLUE Incorrect Temperature and Humidity readings Moderators: adafruit_support_bill, adafruit

[Tom_Henry]

Just purchased Adafruit's CLUE board.

I have been running Adafruit's example program entitled: clue_display_sensor_data.py. I added some print statements and sleep, see attached file.

The temperature and humidity readings are incorrect. I compare them to using Adafruit's MS8607 sensor readings.

Clue: Temperature: 27.65 C Humidity: 36.88% MS8607: Temperature: 22.23 Humidity: 47.49%

I am guessing maybe the CLUE board heats up and changes the readings.

I am not happy about the incorrect readings. Does anyone have any information on why this is happening?

Tom Henry

[kevinjwalters]

The temperature is a common issue for the CLUE and most microcontroller development boards. As you note, the dominant error is caused by self-heating from the electronics on the board. The temperature sensors embedded in specific components are often really there to calibrate the other sensors in that components. The CLUE actually includes three temperature sensors: BMP280 (the source for clue.temperature), SHT31D and nRF52840 (CPU).

I've spent a lot of time recently looking at this on the (two) CLUEs. We tend to think of LEDs as cold due to the comparison with their very hot, incandescent cousins but bright ones do product heat and as @adafruit_support_carter has noted this is significant from the backlight on the CLUE's screen. A summary of my recent experiments is -2.5 degrees celsisus and -5.5 are reasonable correction factors for backlight off and on for room temperature. The detail is embedded in previous discssions in the forums.

• CLUE temperature off a few degrees?
• External temperature sensors vs CLUE's onboard
• Offering calibrated temperature property

One odd thing I've noticed recently is the RP2040 on the new Raspberry Pi Pico seems to reliably underread! I'd imagine this is just because the recommended standard coefficients for calculation are wrong for the temperature conversion.

I've not looked at humidity. I have a commercial sensor on my wall and I've never trusted the readings from that. The only thing I've noticed about CLUE's is it is very responsive and can pick up the transient rise and fall from breathing onto the CLUE. Unmounted thermistors are like this too, they can pick up tiny warm/cold draughts that we'd barely notice.

[liquidsquid793]

Trying to use sensors accurately directly on a compact board is rather difficult if the board consumes a decent amount of power. There will be temperature rise. Your humidity will read lower when the sensor warms up, so the two readings you are getting are consistent with a warm board.

Try turning down the backlight to an acceptable value, and turn off unnecessary peripherals to reduce consumption and that will help.

Out of curiosity would be to calculate dewpoint from both devices, as dewpoint should remain consistent between temperature and humidity (and a little bit of air pressure). Look up the formula for that.

You can compensate for the temperature rise of the board as suggested, and it should be close enough once discovered, unless airflow over the boards is different. Example would be to use the lower temperature reading from the other design, and subtract from your reading to get the offset and use that for your display. Of course, this will only be true when the board temperature "settles" after running a while. If you want to get picky, you can figure out the warming time also, and adjust the offset from 0 to the final offset over that same period once discovered, and you can have a reasonably good estimate of temperature as soon as the board turns on.

Good luck, sensing accurately and with precision is an artform.

Note that most sensors need to run through an averaging filter of some sort to calm down the noise a little. Since real-world sensing values don't change very rapidly, you need to understand values that change quickly may be meaningless information.
Try this easy method to filter readings, and then you can apply to any sensor:
(Normally declarations should be somewhere else, but put here for convenience)

Code: Select all | TOGGLE FULL SIZE

  static bool firstIn = true;
  static float humidityAveSum = 0.0f;
  const float humidityNumPts = 16.0f;
  float result;

  if (firstIn)
  {
    firstIn = false;
    //Seed the accumulator
    humidityAveSum = sht30.readHumidity() * humidityNumPts;
  }
  else
  {
    //Add new value, remove the previous average.
    humidityAveSum = humidityAveSum + sht30.readHumidity() - humidityAveSum / humidityNumPts;
  }
  //Come up with the average result
  result = humidityAveSum / humidityNumPts;

  arcada.display->print("Humid: ");
  //arcada.display->print(sht30.readHumidity());
  arcada.display->print(result);
  arcada.display->print(" %");
  arcada.display->println("         ");


The cool part of the above code is that it is a single-sample in, single result out infinite impulse response filter, and you don't have to wait for the results to go to near average by latching in the initial value. This is using a running average over 16 samples which still allows the sensor to be easily responsive with a 1Hz sample rate, but much "quieter" for noise. A real-world value in a large room or outdoors may need an average over a period of 5 minutes or more, which with a 1Hz sample rate would be 5 * 60 = 300 samples. That may be too slow for tinkering, but that single value for humidityNumPts is all you need to adjust to change it for your use case.