Hello.
Can you try the DHT22 component found here, please.
If it works, it will be rolled out for the Grove component as well.
DHT22 bug ?
-
- Matrix Staff
- Posts: 1913
- http://meble-kuchenne.info.pl
- Joined: Wed Dec 02, 2020 11:07 pm
- Has thanked: 619 times
- Been thanked: 644 times
-
- Matrix Staff
- Posts: 1465
- Joined: Sat Dec 05, 2020 10:32 am
- Has thanked: 204 times
- Been thanked: 347 times
Re: DHT22 bug ?
A 10MHz clock on an 8bit PIC means HEX instructions take 0.4us (or twice that for jumps). This means you only have a few instructions to deal with the waveform received from the sensor. If you need to use this chip and clock speed, then I think the best thing would be for you to create your own optimised pin reading function in assembly language.
-
- Valued Contributor
- Posts: 1528
- Joined: Thu Dec 03, 2020 10:57 am
- Has thanked: 353 times
- Been thanked: 549 times
Re: DHT22 bug ?
Hi
Following on from Steve there are a lot of posts on Arduino forums regarding the DHT22 at 8MHz and the struggle to get reliable readings. Most problems seem to disappear at 16MHz. At lower speeds even things like other interrupts caused issues.
I read in one post that the user eventually got things working by disabling every interrupt and creating a loop that did everything required sequentially. Seems a lot of work compared to the cost of a crystal
Regards
Following on from Steve there are a lot of posts on Arduino forums regarding the DHT22 at 8MHz and the struggle to get reliable readings. Most problems seem to disappear at 16MHz. At lower speeds even things like other interrupts caused issues.
I read in one post that the user eventually got things working by disabling every interrupt and creating a loop that did everything required sequentially. Seems a lot of work compared to the cost of a crystal

Regards
-
- Valued Contributor
- Posts: 1528
- Joined: Thu Dec 03, 2020 10:57 am
- Has thanked: 353 times
- Been thanked: 549 times
Re: DHT22 bug ?
Hi
I didn't say your speed was the problem, just that in other cases it has been an issue. From the posts I refer to, in some cases changing the library helped, as the new one used different timings.
I have no need (yet) to use the component so haven't really looked at it to any depth.
There is an issue related to the new version, which Matrix are clearly trying to resolve, so if I were having the problem I may consider trying solutions suggested elsewhere such as an increased clock (if doable) even just to eliminate, reporting the outcome in the forum as it may prove helpful to others.
What chip are you using? Whilst I don't have a 22' I do have an 11' which is pretty similar in terms of talking.
Regards
I didn't say your speed was the problem, just that in other cases it has been an issue. From the posts I refer to, in some cases changing the library helped, as the new one used different timings.
I have no need (yet) to use the component so haven't really looked at it to any depth.
There is an issue related to the new version, which Matrix are clearly trying to resolve, so if I were having the problem I may consider trying solutions suggested elsewhere such as an increased clock (if doable) even just to eliminate, reporting the outcome in the forum as it may prove helpful to others.
What chip are you using? Whilst I don't have a 22' I do have an 11' which is pretty similar in terms of talking.
Regards
-
- Matrix Staff
- Posts: 1465
- Joined: Sat Dec 05, 2020 10:32 am
- Has thanked: 204 times
- Been thanked: 347 times
Re: DHT22 bug ?
Which specific version of the component works in your situation? You can revert the version via library updates if you still need to work with it.
The reason for the change is it was not working for some other devices. When timing is critical like it is with this sensor, it is very difficult to create a component that works on very slow chips like yours and much faster devices like the RPI and ESP.