Page 4 of 5

Re: DHT22 bug ?

Posted: Wed Feb 14, 2024 9:35 pm
by medelec35
Hello.
Can you try the DHT22 component found here, please.
If it works, it will be rolled out for the Grove component as well.

Re: DHT22 bug ?

Posted: Thu Feb 15, 2024 1:09 pm
by kaqkk007
As soon as we have time we will try

Re: DHT22 bug ?

Posted: Tue Feb 20, 2024 4:12 pm
by kaqkk007
Unfortunately 10Mhz quartz and Pic 16f628 did not produce any worthwhile data 99,9 es reads data continuously

Re: DHT22 bug ?

Posted: Tue Feb 20, 2024 4:27 pm
by Steve-Matrix
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.

Re: DHT22 bug ?

Posted: Tue Feb 20, 2024 4:49 pm
by chipfryer27
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

Re: DHT22 bug ?

Posted: Tue Feb 20, 2024 6:19 pm
by kaqkk007
It worked fine for me until the previous update with interrupts (and even called the sensor readout from an interrupt)

Re: DHT22 bug ?

Posted: Tue Feb 20, 2024 7:53 pm
by chipfryer27
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

Re: DHT22 bug ?

Posted: Wed Feb 21, 2024 9:25 am
by Steve-Matrix
kaqkk007 wrote:
Tue Feb 20, 2024 6:19 pm
It worked fine for me until the previous update with interrupts (and even called the sensor readout from an interrupt)
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.

Re: DHT22 bug ?

Posted: Wed Feb 21, 2024 11:38 am
by kaqkk007
The 16f-18f series (enough knowledge for me) Then "backward upgrade" will be the solution as long as I have those chips in my box

Re: DHT22 bug ?

Posted: Wed Feb 21, 2024 5:31 pm
by kaqkk007
Yes 20Mhz frequency is already working with interruption ! Own (array) 7segments display management in 16f648 chip groove dht 3 ver