Strange readings - Githubissues

Mr-HaleYa commented 4 years ago

I am using esp32 ttgo sim 800l (https://rb.gy/ogywnq) Dfrobot dht22 (https://www.dfrobot.com/product-1102.html)

my code

DHTNEW DHT(18); DHT.setWaitForReading(true);

float DHTtempBuffer[7];
float DHThumidityBuffer[7];
int DHTReadings = 7;             // number of DHT readings before choosing a median

void getDHT(){
  for (int i = 0 ; i < DHTReadings; i++) {
    DHT.read();                                     // Gets a reading from the DHT sensor
    DHThumidityBuffer[i] = DHT.getHumidity();
    DHTtempBuffer[i] = DHT.getTemperature();
  }
  sortData(DHThumidityBuffer, DHTReadings);                     //sorts array low to high
  DHThumidity = DHThumidityBuffer[(DHTReadings - 1) / 2];       //gets median of the array
  sortData(DHTtempBuffer, DHTReadings);                         //sorts array low to high
  DHTtemperature = DHTtempBuffer[(DHTReadings - 1) / 2];        //gets median of the array
}

So my problem is that even tho I use a filtering algorithm to get rid of highs and lows by taking 7 readings then choosing a median I will occasionally get some massive dips in temperature (and spikes in humidity as a result). my temperature in my room stays about 24°C and the dips are -12 and 12 °C so half the temp and half * -1. I have no clue why it is doing this... It runs every ~2 mins and when the bad readings start it does it consistently for a few runs before correcting itself.

Nothing moves nothing is touched nothing changes... It just goes wack... Could it be a library error? I don't see how it could be but you're a smart man @RobTillaart so you may see something I'm missing. I have also thought of the potential that its a dud sensor. I hope not bc i ordered 20 more before testing the one I'm using. I had the thought that maybe adding more reading (like 15 instead of 7) so there is more to data to filter but it looks like all the readings it's taking in those fault zones are bad...

Would appreciate any suggestion - Regards Hale

RobTillaart commented 4 years ago

I need more coffee in the morning, sorry. Fixed. (now I only need to fix a coffee)

RobTillaart commented 4 years ago

pushed 0.3.0 alpha in test_timing, will be used for 12 hour test run to verify it does not fail after 10 hours.

Current test runs now 22:30 so that is 10:00 + 12:25 hrs so normally second burst would be about now. Good to see zero fails so far.

RobTillaart commented 4 years ago

Zero failures in 23:30; so starting test now with 0.3.0 alpha.

update: 9300+ reads OK

RobTillaart commented 4 years ago

0.3.0 alpha - ran for 13:00 hrs 23366 reads OK - so no 10 hr failure (capture missed first 3 reads)

17:38:45.476 -> 4   3   22  0   48.40   25.90   
...
06:39:22.886 -> 23370   14  22  0   56.30   24.70

next steps

review code delta with 0.2.2
verify & update example sketches
performance per read
push 0.3.0

Mr-HaleYa commented 4 years ago

So you think you figured it out then? 😃

RobTillaart commented 4 years ago

Not understood in all details, but I think I'm closing in. This is my current hypothesis.

Observations

The DHT22 has its own processor.
Its clock is not super accurate (few percent).
Timing of the protocol is implemented quite strict
During the crashes the sensor did not wake up

Hypothesis The DHT22 sensor does not recognize the wake up signal as the DHTNEW library is "on the edge" of the specification in its timing.

Solution 0.3.0

Extending the wake up signal by 10% This is a lot, optionally test lower percentage in the future.
Extending the wait time for the sensor to react A polling loop that gives more time if needed. It can also be faster in some cases.

Mr-HaleYa commented 4 years ago

so basically it does what it wants when it wants lol. sometimes quick readings and replies other times its to slow and doesn't fully respond before the read req is over

RobTillaart commented 4 years ago

Yes it is alive :)

RobTillaart commented 4 years ago

Issue closed as issue is fixed. The cause seemed to be related to a too strict timing during wake up of the sensor. However it is still unclear where the 10:00 and 12:25 intervals came from.

Please reopen if these burst of failed reads occur again.

Mr-HaleYa commented 4 years ago

@RobTillaart Wow, amazing work! I really don't know what I will do with my mornings now that this is closed 😭 I really enjoyed reading your in-depth explanations lol 😄 Well I hope the issue never arises again as that was (at the least) inconvenient, It is good that it was fixed tho. I wish you the best of luck on all your other projects and thank you again for the amazing work you have done here. -Regards Hale

RobTillaart commented 4 years ago

@Mr-HaleYa You're welcome, I like these kind of analysis, for me it is (mostly) fun especially the moments of new insights, the moments of real learning. The only thing that took real patience were the test runs, they took serious time, but that was also time to think about what happened under the hood.

Are you going back to the DHT22 now in your project? Or do you keep the DHT11.

Mr-HaleYa commented 4 years ago

Well if you say it works then I see no reason not to use the DHT22 🙂 I have 5 so I will switch out some of the DHT11's in my projects and see if I get any errors 😆

RobTillaart commented 4 years ago

In my tests it looks stable so please give it a try,

But you know that the fact that you see no bug is no proof there is none 😊

Success!

RobTillaart / DHTNew

Strange readings #11