DHT22 not giving correct results
Shawn Lowe
Posts: 635
in Propeller 1
Hello all-
I'm using Jonnymac's jm_dht11_demo spin file with a dht22( I believe I read on a thread that his spin file will read both sensors) and am getting the results in the attached picture. I have a 10K resistor between power and signal. Does anyone have any ideas I can try?
Thanks
Shawn
I'm using Jonnymac's jm_dht11_demo spin file with a dht22( I believe I read on a thread that his spin file will read both sensors) and am getting the results in the attached picture. I have a 10K resistor between power and signal. Does anyone have any ideas I can try?
Thanks
Shawn
Comments
Edit- I modified his original program in the OBEX to suit my set up. Program attached.
That is weird I have 12 instead of 22 and its working. I changed it to 22 with the same results though.
{HELP DHT@ ( pin -- rh temp | -1 )
Read the relative humidity and temperature from the DHT22
Return with rh and temp in Celsius
If an error occurred in the checksum then return last valid reading
If the sensor is polled more than once every 2 seconds then use last valid readings
Typical acquisition time ~6ms
}
So if you are using pin 15 then just type "15 DHT<cr>" and when you print the first result returned then that's the temperature in Celius*10 and the second item is the humidty *10.
I just connected up a DHT22 to one of my boards on P16 and this is all I did to test it
So the first time through I read 269 which is 26.9'C and 401 which is 40.1% RH. Finally after huffing on the sensor I get a reading of 26.6'C and 47.6% RH.
Not just happy with that I do a quick one-liner and place a cube of ice over the sensor resting on tissue paper: This is what it showed, the temperature dropping and the humidity rising, as it should.
After a couple of minutes:
closely based in @Peter's DHT2 code.
Other than 20ms instead of 1ms reset pulse there isn't any real difference except you are only using 8-bits. I've checked the datasheet for the DHT11 and it seems that the data format is the same so I've just allowed for a longer reset pulse for a DHT11 as it doesn't make much sense to have a different driver just for this one small detail.
DHT11
5. Communication Process: Serial Interface (Single-Wire Two-Way) Single-bus data format is used for communication and synchronization between MCU and DHT11 sensor. One communication process is about 4ms. Data consists of decimal and integral parts. A complete data transmission is 40bit, and the sensor sends higher data bit first. Data format: 8bit integral RH data + 8bit decimal RH data + 8bit integral T data + 8bit decimal T data + 8bit check sum. If the data transmission is right, the check-sum should be the last 8bit of "8bit integral RH data + 8bit decimal RH data + 8bit integral T data + 8bit decimal T data".
DHT22
DHT22 send out higher data bit firstly! DATA=8 bit integral RH data+8 bit decimal RH data+8 bit integral T data+8 bit decimal T data+8 bit check-sum If the data transmission is right, check-sum should be the last 8 bit of "8 bit integral RH data+8 bit decimal RH data+8 bit integral T data+8 bit decimal T data".
Edit: I'm using the latest tachyon and extend builds: tachyon 300_160804 and the extend in the dropbox.
24 DHT . SPACE . 229 474 ok
Try another I/O pin or DHT22 and always make sure you use a current limit resistor if running from 5V. I notice that many diagrams show a pullup but the one wire that the DHT22 uses is not the same as the "1-wire" bus.
Testing the DHT22 it shows that internally it has a 4k7 pullup to supply which means that the pullup they show in the datasheet is redundant. The DHT22 works directly from 3.3V so no current limit or pullup resistors are necessary.
Hint: If you need to post terminal output just copy and paste as code rather than screenshots unless it is something fancy.
btw, here's a simple routine to sample and display the results: and running it
Just had a look at how they do it Arduino style and the code is a little more than one line plus it needs floats:
Check the extra notes I previously added to my last post.
The data format is the same. But the DHT11 always reports the decimal bytes as zeroes (less accurate).
Peter- Just downloaded extend, then verified communication by hitting enter a couple times and getting "ok". Then hit reset on my PPDB, bang, no more communication with prop.
BTW, It is quite possible too with V3 JUNO that it may not work with older 32k EEPROM systems as it assumes all systems would have 64k which is the standard these days.
(I could put a test in there for this to prevent it trying to save ROMs to upper EEPROM if there is only 32k). (DONE)
BTW, It is quite possible too with V3 JUNO that it may not work with older 32k EEPROM systems as it assumes all systems would have 64k which is the standard these days.
(I could put a test in there for this to prevent it trying to save ROMs to upper EEPROM if there is only 32k). (DONE)[/quote]
Okay! The PPDB board I'm using only comes with 32K even new!! So I need to get a 64K DIP chip before I continue! Thanks Peter, it never would have occurred!
Okay! The PPDB board I'm using only comes with 32K even new!! So I need to get a 64K DIP chip before I continue! Thanks Peter, it never would have occurred!
[/quote]
But if you try again with the newer version of EXTEND it will detect the 32k EEPROM and not try to backup the ROMS which you aren't using anyway.
The one I modified immediately after mentioning this problem and then appending a (DONE). Mind you though I haven't checked it on a 32k system as I would have to dig one up plus I'm pretty sure it will work because one of the things that happens when EXTEND is loading is that it does a quick check to see if you have 32k or more so that it can optimize the page size for writing blocks of EEPROM and all I added to SAVEROMS was "ep 128 => 0EXIT" which effectively does an early exit if the page size is smaller as in the case of 32k EEPROMs.
this code says
ep 128 =
means 64k
so your line above would also 0EXIT for 64k EEPROMs ...
Testing this plus confirm my 64k EEPROM has an ep of 128.
sorry - the 0EXIT trap again ... :-(
0EXIT === NOT IF EXIT THEN
btw. I like the
" ROMS" U@
trick :-)
... now everybody else than you can find out, what this trick is ;-) and maybe learn s.th.
EDIT: wrong link replaced
aliexpress.com/item/Free-Shipping-10PCS-24C512-Encapsulation-DIP-2-wire-Serial-EEPROM/32450744005.html?spm=2114.30010308.3.76.4H5Oe4&ws_ab_test=searchweb201556_7,searchweb201602_2_10057_10056_10037_10055_10049_10044_10043_10059_10033_10058_10032_10017_10041_10060_10042_10061_10062_10064,searchweb201603_1&btsid=1134ca8f-7062-4b16-9418-a604028f143d
for this price you can take 5 or 10 or 20 ;-)
upgrade the PPDB and have lot's of spares ...
Mouser. Drop in replacement:
http://www.mouser.com/ProductDetail/Microchip-Technology/24LC512-I-PG/?qs=sGAEpiMZZMuVhdAcoizlRSvfTHyGQYYpbLAyXVdZPQc=
Okay peter solved my problems with communications after reset - thank you! Now everytime I reset or hit ctrl-b I get
But when I enter the pub .DHT and tachyon says okay, I enter 14 .DHT (I moved the data line to 14 from 15) I get no response and the propeller hangs. I have this hooked o 3.3V so I have no 1k resistor.
Sweet! Thanks for the link
Don't use that part, it is 64 k bit EEPROM, not 64 k BYTE. Normally k bits are written as kb and k bytes as kB (or KB) but beware the typos accidental or not. The link though that Publison gave is correct although there are many others too. A 64KB part will normally have a 512 as part of its part number to indicate 512k bits or 64k x8 whereas the old standard 32kB was a 24LC256 or 256 k bit EEPROM.
But as I said before you don't need 64kB normally, it is only if you going to be using those "ROMS" or extend Tachyon to the point with FAT32 and perhaps Ethernet that you need the upper 32kB for the dictionary.
btw, the problem with the DHT22 could be a faulty DHT and the code hangs waiting for a response. Do a "14 DHT? PRINT" to check the DHT22 which will return with a -1 for yes and a 0 for no. (I favor using the PRINT alias in place of the dot symbol since the dot gets lost or may be interpreted as a full stop etc). Default radix should be decimal but just in case force it with a # prefix like this: #14 or #P14
If it looks faulty then just post a photo of the the way the sensor is connected up.
1 VDD
2 DATA
3
4 GND
Ahem, I uh found the problem with my setup. During playing I removed the wire from the 3.3v to the breadboard *ahem*
Here is the ouput now:
Thanks Peter for all the patience!! lol so as a learning experiment how would I convert the Celsius to Fahrenheit in the one liner example?
BTW, its good to know my sensor is good! Which was the original point of this thread.
Take 100'C and convert to F interactively So you see if you multiply by 9 divide by 5 and then add 32 you have F. Make this a function.
Playing this is what I'm getting:
Does tachyon have graphing capabilities? This is pretty cool!