31-12-2023, 06:26
(This post was last modified: 31-12-2023, 06:32 by Palmyweather.)
This evening I started to play with the routine within the WeatherDuino software which manages the DHT22 readings, with results I feel are interesting when the multiplier is adjusted.
Original code:
If I change the "*10;" to "*2;", each time the data is displayed, the numbers are doubled: 5.06, 10.12, 20.24, 40.48...
If the "*10;" is changed to "*100;", there is no clear pattern to the number outputs.
When analysing the serial output data when the routine multiplier is set to the default of "*10;", I note that the decimal point shift in a similar pattern to how it is being multiplied and the numbers doubled when I set the multiplier to 2.
In my tests, I note that once the humidity value exceeds 100, it will always return a 0.00 or a 99.90 result on the serial output.
Could the answer be within this test done within the routine file for these random numbers to be coming from the sensor? It is almost like a variable remembering/retaining the last value and not replacing it before it is processed again.
Original code:
Code:
#if (TH_SENSOR1 == 1)
// ----- Read temperature from DHT22 (in celsius) -------
void read_DHT22()
{
dht.reading(T_ExtS1, H_ExtS1);
T_ExtS1 = T_ExtS1 * 10;
H_ExtS1 = H_ExtS1 * 10;
}
#endifIf I change the "*10;" to "*2;", each time the data is displayed, the numbers are doubled: 5.06, 10.12, 20.24, 40.48...
If the "*10;" is changed to "*100;", there is no clear pattern to the number outputs.
When analysing the serial output data when the routine multiplier is set to the default of "*10;", I note that the decimal point shift in a similar pattern to how it is being multiplied and the numbers doubled when I set the multiplier to 2.
Code:
Sending ID0...
Sensor 0 - Temp: 0.00 Hum: 0.00
Sensor 1 - Temp: 27.40 Hum: 59.20
Sending ID0...
Sensor 0 - Temp: 0.00 Hum: 0.00
Sensor 1 - Temp: 274.00 Hum: 0.00In my tests, I note that once the humidity value exceeds 100, it will always return a 0.00 or a 99.90 result on the serial output.
Could the answer be within this test done within the routine file for these random numbers to be coming from the sensor? It is almost like a variable remembering/retaining the last value and not replacing it before it is processed again.