DHT22 in a NanoPi M1

[nico]

Hi! I just bought a NanoPi M1 board and It is running with Armbian without problem. Now I want to add a DHT22 temp & hum sensor but searching in the web I cant find any script to get it work. I saw that the RPi script doesn't work on the NanoPi M1 because the chip is differnt. In the Friendlyarm page there is a C script to work with the DHT11, but nothing with the DHT22. So, anyone have been experimenting whit it in this context? There are a Wiring Pi equivalent to NanoPi M1? Thanks

[tkaiser]

Please report back if post #9 here helps. The dht11 binary in the archive is tested with both DHT11 and DHT22 but on A20 (I don't think the SoC is important but the board and GPIO settings/cabling)

[nico]

Tkaiser, thanks you for your soon answer. I read the post you mentioned and follow the LeMaker's steps (https://github.com/LeMaker/WiringBP) but it doesn't work for the NanoPi. Then I found this blog WiringPi in a Orange Pi with which I have more hope since Orange Pi PC has the same AllWinnwer H3 processor, but it doesn't work either, I do not have many clues why.

Finally, I found in the FriendlyARM Wiki the procedure to install a DHT11 sensor in a NanoPi M1 with a Debian OS, which consists in the installation of only one library. I tested it in Armbian and it doesn't work. As last test, I booted the NanoPi with Debian image and tested the FriendlyARM library and it works! but only with a DHT11 sensor, not the case with the DHT22. So, I'm a little confused by all this, especially since it should have worked with the Orange Pi procedure. Any tips?

[nico]

Its Works! Like Yudanta referenced is his blog, Pete was experimenting with the NanoPi and after I read his article, I realiced that I was looking the wrong PIN. I got the DHT22 working using this WiringPi but with some errors each 5 or 6 readings. I used the Yudanta referened driver and the Tkaiser driver but with both I have random reading errors. I'll investigate in deep later. Thank you very much!

[vlad59]

You can try this project for DHT22 : https://github.com/technion/lol_dht22

I made some modifications here : https://github.com/seblucas/lol_dht22and I've been using it for a year and a half on my Banana Pi doing a reading every 15 minutes. So far I loose on average 1 reading per day.

 

You can see here that the program has to wait for specific amount of time. So if you want to use your DHT22 with a lot of reliability, you'll have to keep the CPU load low and maybe tweak your cpufreq settings to set a minimal freq at around 600MHz this should help lowering the errors you see.

[nico]

vlad59: thanks for the tips! i will test lol_dht22 driver.

To learn, why lowering the frequency the reliability is better?

[vlad59]

I've advised to change the minimal frequency to an higher value (not lower) : 600MHz instead of 480MHz

 

That's mainly because delayMicroseconds is a busy loop so having an higher frequency will make it more precise. Linux is not a realtime OS so you don't have much choice.

 

Of course if you need 100% reliability, your best choice is to connect your DHT22 to an Arduino and connect your Arduino to your Orange Pi with an UART.

[tkaiser]

Of course if you need 100% reliability, your best choice is to connect your DHT22 to an Arduino and connect your Arduino to your Orange Pi with an UART.

 

Since the normal use case for DHT11/DHT22 is monitoring minor changes over time (both temperature and humidity only slightly change) one can also simply use a software approach. Simply drop readouts with wrong checksum and use the last value known.

 

This is a Lamobo R1 (also A20) allowed to clock between 144 and 912 MHz. The only busy times are throughout the day when 5 RPi acting as surveillance cameras stream to the Lamobo (then cpufreq is between 720 and 912 MHz, all the other times at 144 MHz). Also I saved the 4k7 resistor so I get really often readout fails but it doesn't really matter at all since all I wanted to know is whether the 3 already available temperature sensors inside the enclosure (A20, AXP209 and Samsung SATA disk queried through SMART) work correctly -- obviously they do: