 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : DHT22 PicoMite 5.07.06 jumping readings
  Page 3 of 3 |
|||||
| Author | Message | ||||
| JohnS Guru  Joined: 18/11/2011 Location: United KingdomPosts: 3800 |
Even if 1 in 10000, it would be wise to code around any implausible value (not just 1000), and wiser still to cope with a stream of implausible values (in this latter case, to report broken hardware). John |
||||
panky Guru Joined: 02/10/2012 Location: AustraliaPosts: 1101 |
John, Part of the problem is that, when you detect the temp/humidity values of 1000, you have no way of knowing if it is a firmware/timing issue, faulty cables/connections/pcb layout etc! or even the actual device unless you have access to a logic analyser to catch and validate the data. Doug Edited 2023-01-31 21:12 by panky ... almost all of the Maximites, the MicromMites, the MM Extremes, the ArmMites, the PicoMite and loving it! |
||||
phil99 Guru Joined: 11/02/2018 Location: AustraliaPosts: 2135 |
In this instance perhaps one way to determine if you have a hardware issue is crank up the CPU speed. If pain persists the hardware is ill. 378MHz 16000 samples so far, no errors therefore hardware fine. . |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6783 |
I think you might notice if the temperature reached 1000 degrees or the humidity got to 1000% when using a DHT device. That's a fault in reality. :) It's probably quite safe to simply test the values as they come in and ignore any that have a value of 1000. True, you don't know if the problem is in firmware or hardware but that doesn't matter. You could flag, say, 10 consecutive 1000 values as a failed sensor, bring up an alarm and stop using it completely. No need for changing CPU speed or a logic analyser. In any case, you shouldn't really be looking at individual readings. You should be averaging them out in a FIFO array to reduce reading jitter. Values of 1000 simply don't go into the array. The number of failed readings merely changes how quickly the average changes, it doesn't affect the accuracy. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| bigfix Senior Member  Joined: 20/02/2014 Location: AustriaPosts: 128 |
I have no own experience with those Sensors, but I remember some discussions in other forums (sorry - in german...) AM2320 vs AM2302/DHT22 One recommendation was to use the AM2320 Sensor instead It is more stable in high humidity in the longterm, unlike some newer versions of the DHT22/AM2302 The AM2302 is basically a wired DHT22 Running the usual AOSONG 1 Wire Protocol The AM2320 supports by default the same protocol, but optionally runs I2C if you connect Pin 3&4 with GND So you could use I2C to read the sensor data as an alternative There seems to be no way to change the I2C Address for multiple sensors |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3800 |
If it is sporadic you can ignore it & no fix is needed. If it is beyond some threshold (e.g. always bad!), you have a fault that needs a (hardware) fix. Just keep track of how often 1000 (or any bad value) occurs in a row (*). If more than some threshold you need a fix. (*) or if it suits you, within some time period, or some other heuristic John |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6098 |
It IS important to know if the errors are hardware or firmware (Or your coding). Hardware is something you can and should fix. It usually only gets worse over time. Your coding is also your responsibility and can be addressed. Firmware is out of your control and provided you know about it, you can decide if you need to use another approach altogether or patch the code. One problem with the DHT22 etc is, they are often used in 'remote' weather stations where power is critical. Running the pico at lower speed saves a lot of power but doesn't help the DHTxx error. You can't change speed on the fly like the Microchip devices so you are stuck. A failure rate of 1 in 5 when everything is good is a bit much to accept. Now we know what causes the rogue readings, the main problem is solved. Incidentally, I stopped using these sensors when I found they got stuck at 100% humidity after a year or two and are a pain to try and recover. They are nice until then... Jim VK7JH MMedit MMBasic Help |
||||
| phil99 Guru Joined: 11/02/2018 Location: AustraliaPosts: 2135 |
"are a pain to try and recover" Yes, and long before they get stuck their accuracy declines. The recommended method to restore them is to heat them to 50C in dry air for several hours. |
||||
| phil99 Guru Joined: 11/02/2018 Location: AustraliaPosts: 2135 |
More pointless messing about with a DHT11. Recently revived one as above which reduced the error but the humidity was still more than 10% higher than indicated by a AHT10. When testing at the command prompt noticed the reading decreased if left for a while between tests. This test program shows that you need to increase the interval between reads to 30S to get a stable humidity. The first column is the time between reads (S) then Temp. and Humidity. > do :for n=0 to 60:device humid gp0,t,h,1:?n,t,h :pause 1000*n :next :loop 0 11 47 <-- last stored value from previous run 1 1000 1000 <-- interval too short to wake the DHT11 2 1000 1000 3 11 47 4 11 61 5 11 61 6 11 61 7 11 60 8 11 59 9 11 57 10 11 56 11 11 55 12 11 54 13 11 53 14 11 52 15 11 51 16 11 50 17 11 50 18 11 49 19 11 49 20 11 49 21 11 48 22 11 48 23 11 48 24 11 48 25 11 48 26 11 48 27 11 48 28 11 47 29 11 47 30 11 47 31 11 47 32 11 47 .... 55 11 47 56 11 47 57 11 47 58 11 47 59 11 47 60 11 47 0 11 47 1 1000 1000 2 1000 1000 3 11 47 4 11 61 5 11 61 6 11 61 7 11 60 8 11 59 Edited 2024-06-06 07:58 by phil99 |
||||
| phil99 Guru Joined: 11/02/2018 Location: AustraliaPosts: 2135 |
Have now tested the 30S sample interval from 6% humidity to 85%, according to a AHT10 and the DHT11 remains within 4% of it over that range. 1% low at the bottom and 4% high at the top. The DHT11 chip sleeps between reads so the 30S read interval lets it cool back to ambient between reads. This I assume is what improves the accuracy of the humidity reading. The temperature tracking is quite good too. Never** more than 0.4°C difference (Using the 2 pin method to get 0.1° resolution from the DHT11). Now to see how long before the DHT11 needs reviving again. **After the AHT10 temperature has stabilised. Internal heating due to constant power consumption of the AHT10 chip takes more than 10 min. to settle. |
||||
| Page 3 of 3 |
|||||
 Print this page |
