Effect of Wifi on temperature and humidity sensor

Last week pgtest opened an issue for the SHT2x library describing the effect of WIFI on the working of the sensor. In short when in short range (3 cm ~ 1 inch) there was an increase of temperature and a decrease of relative humidity.

So far we understand two effects:

  • (1) Wifi (2.4GHz) cooks the water and thus the temperature of the air rises. This causes the maximum absolute humidity to rise and thus the relative humidity to drop (under the assumption of equal amount of water).

  • (2) water evaporates so the amount of water drops so the relative humidity drops.

For details, please read - SHT 21 , HTU21 ... etc susceptible to EMC, gives wrong readings · Issue #42 · RobTillaart/SHT2x · GitHub

Effect (1) can be confirmed by calculating the absolute humidity from T and %RH.

//  from Temperature Library
float absoluteHumidity(float Celsius, float relHumidity)
{
  float TC = Celsius;
  float AH = (2.1674 * 6.112) * relHumidity;
  AH *= exp((17.67 * TC)/(243.5 + TC));
  AH /= (273.15 + TC);
  return AH;
}

Q1: Is this effect seen with other temperature and/or humidity sensors?

Q2: Is this effect seen with other 2.4 GHz sources?

Q3: Are there known formulas to compensate this effect?

Hi Rob.

I don’t know exactly when I´ll have time to do it, but I can try to repeat the experiment with a DHT11 and a BME280 with their regular libraries.

The requisites are: ESP32 with wi-fi on/off, sensors on the vertical, ~3cm from the ESP32 antenna. Is that correct?

Would be perfect.
Other boards with wifi are OK too.

How will you prove that it is not the RF signal itself inducing a voltage into the circuitry that is causing the changes in temperature and humidity readings?

How quick are the changes?

As far as I (now) know that or any other scenario cannot be excluded.

If the RF is inducing the effect in another way, there will (still) be the advice / conclusion to stay away from the WIFI modules if possible to avoid this systematic (?) error.
Other possible cause is that the WIFI module just gets hot, could lead to same effect.
So first step is to collect observations from different sensors, as it can of course be an effect only in one type of sensor.

The only argument I have so far is that the increase in T an decrease in RH lead to the same absolute Humidity in one measurement. As the inside of sensors are black boxes it is indeed possible that other effects are active.

If the RF effect would be only on the voltage in circuitry, we may assume that there is no temperature increase, or maybe less. So a second different temperature sensor could be used to verify the temperature increase.

There is a sequence in this Github post

The 114000 numbers are the measurement durations, approximate polling rate 1 measurement per second.

Keeping strong RF fields away from sensitive electronic circuits is just about mandatory in most designs. Why are you putting these sensors to within 3cm of an WiFi antenna anyway? Was it done on purpose or just part of a bad design.

Isn't this a kind of "doctor it hurts when I do this" problem

Thanks for your questions,

  1. I did not, It was reported as an interesting observation / issue on GitHub with one of my libraries. As I could not explain it for sure, I decided to ask if this effect has been seen with other sensors here on the forum to possibly get a better understanding.

  2. I don’t know if the positioning was done on purpose or not. Some tests thereafter were for sure. I assume it is not bad design but a consequence of making a device as compact as possible, or to investigate what distance is feasible.

I am aware of possible bad design, however for my question it is irrelevant why the sensor was close to the WIFI. In the datasheet of several sensors it was not mentioned, My goal is to understand why the heat up / humidity decrease happens and for that I hope to get observations of other sensors that confirm (or not) the observations made.

FYI, I have prepared a section for the library with the advice not to place the sensor near the WIFI unit, especially because the datasheet does not mention such requirement/constraint.

Perhaps distinguishing between the two possibilities could be done by considering the time it takes for the effect to occur when the WiFi is turned on, and how quickly the readings return to normal when it is turned off. Keep the test set up unchanged while turning the WiFi on and off and note the rate of change of the readings. I suggest that if heating is the cause the readings will change slowly, if RF interference is the cause then the readings will change almost immediately when the WiFi is switched on and off.

While I have done no calculations, indeed I'm not sure if I know how to do the calculations, the high specific heat capacity of water would take quite a bit of energy to cause the indicated temperature rise. I am sceptical that WiFi would deliver the required energy into the water. Perhaps someone can suggest how this might be calculated.

Thanks Perry,
The only thing I know is that the effect is seen close to the WIFI module (3 cm) where a distance of 15 cm shows no or minimal effect. As EM radiation follows inverse square root laws the energy at 15 cm is 25 times as low as at 3 cm.

I like your idea to test how fast the effect comes up, and I will forward it to the issue owner.

The heat capacity of water is of course important, and as water in the air water is mostly a gas, I assume there is no latent heat of evaporation involved, so absorbed energy will directly increase temperature. But I am not a physicist by profession.

Further thought is that if the water is heating and cooling the changes will be exponential, if caused by RF interference the changes will be abrupt.

Agree, there is always the option it is a bit of both :slight_smile:

I have asked the issue owner if he has time to do such a “reaction test”.
If there are results I will share them.

Me too.
Well I curious to see the outcome of all of this.

Some info from - SHT 21 , HTU21 ... etc susceptible to EMC, gives wrong readings · Issue #42 · RobTillaart/SHT2x · GitHub

Background:

Reason for the placement: Replicating a "commercial" Hygrometer with WiFi that ALWAYS gave wrong reading (i.e. bunch of useless Chinese cheap hygrometers) . Wanted to find out whether it was the heat from the CPU, bad ventilation, or RF which caused the consistently bad readings between different units of same type.
Personally I was looking for a design that would be minimal in size but stable and correct in measurement with WiFi enabled. A special case...

An interesting argument

The sensors are extremely small and thus contain minuscule amount of water vapor in the sensors... so even minimal power can cause deviations.


And posted earlier in the GitHub issue some data that shows there is at least an heating effect
(trimmed for readability)

Managed to grab the start of a run ... Note: ambient 23.6 C, 3 cm from antenna and WiFi ON.

src/main.cpp
SHT2x_LIB_VERSION:      0.5.4

...
114555
Temp = 23.3
Hum = 30.3

114565
Temp = 23.3
Hum = 30.3

114580
Temp = 23.3
Hum = 30.2

114577
Temp = 23.3
Hum = 30.0

114566
Temp = 23.3
Hum = 29.8

and after 10 min

113979
Temp = 26.4
Hum = 21.9

and after 20 minutes

113980
Temp = 28.4
Hum = 18.6

and after 30 minutes

113980
Temp = 29.1
Hum = 17.4


Temperature grows slowly 3 degrees in first 10 minutes, 2 degrees in next 10 minute and 1 degree in last 10 minute => not a sudden change, looks more logarithmic/exponential.
At the same time the humidity drops.

looking at the absolute humidity, 3rd column below == indication for amount of water.
As the AH drops we can assume that water is leaving the sensor.

Start
23.30	30.30	6.34
23.30	30.30	6.34
23.30	30.20	6.31
23.30	30.00	6.27
23.30	29.80	6.23
10 min
26.40	21.90	5.45
20 min
28.40	18.60	5.17
30 min
29.10	17.40	5.03

Well, despite the further discussion after post #3, I tried the first experiment:

  • ESP32 C3 supermini + BME280, 3cm far from the ESP antenna.
  • wi-fi transmitting a small data pack 10 times/second for 5 minutes, quiet for 5 minutes, then transmitting another 5 minutes.
  • Push-button to turn data transmission on/off. Green led to “see” transmission.

Result: no changes due to wi-fi were observed…

Thanks for doing the experiment, great!

First order conclusion is that this sensor is not affected at all. Food for thought.

Q: does it have a metal housing? If so, it could work as a faraday cage (assumption)

Again, thanks for testing!

Hi, @robtillaart

Was the effect instant, that is WiFi ON, effect, WiFi OFF, no effect?
Or WiFi ON, effect slowly develops, WiFi OFF, effect slowly subsides?

Tom.... :smiley: :+1: :coffee: :australia:

Wi-Fi close to a temp/humidity sensor can mess with readings, but it’s usually not because “2.4 GHz cooks water.” At normal Wi-Fi power, heating of air/water is tiny. What often happens is EMI (electrical noise) getting into the sensor or its wiring, plus local self-heating from nearby electronics or the Wi-Fi module itself, and sometimes airflow changes when the device is close to a warm board. When temperature rises near the sensor, relative humidity drops even if the water in the air stays the same, because warm air can hold more moisture.

Q1: Yes, similar issues can show up with other humidity/temperature sensors, especially digital ones on I2C (SHT2x, HTU21, some BME/DHT types). The sensor may be fine, but the readings shift when RF noise or board heat is near it.

Q2: Yes. Any strong 2.4 GHz source close by can trigger it (Wi-Fi, Bluetooth, some cordless devices), but also non-RF sources can cause the same symptoms: switching regulators, motors, relay coils, bad grounding, long I2C wires, and poor decoupling.

Q3: A simple “formula fix” usually won’t work, because the error is not constant. It changes with distance, orientation, shielding, power level, wiring, and board layout. Better fixes are hardware and placement: move the sensor away from the Wi-Fi antenna/module, use shorter I2C lines, add proper decoupling caps, lower pull-up values if needed, add shielding/ground plane, separate the sensor on a short cable, and take readings when Wi-Fi is idle. If compensation must be done, first measure an offset vs distance/power in your exact build and apply a calibration curve, but it will only match that setup.

I see the sensor module is powered from the same regulator as the WiFi radio.
Any volt drop (millivolts) on that 3.3volt pin could also play a role.

I would at least use a sensor with it's own 3V3 regulator, powered from the 5volt pin of the ESP, to eliminate unstable results due to sensor power flucuations.
Leo..