Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Start listening to the sensor right after releasing the start signal … #70

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

khjoen
Copy link

@khjoen khjoen commented Jan 6, 2017

Hi all,

Here is my pull request for the changes I have done relate to how the library sends the start signal to the sensor and the hope is it will solve and that it will have the effect of a closed #48. It also relates to PR #51 and PR #58.

  • Firstly, there is an unnecessary wait of 250ms before the start signal. This is the reason I started to look at fixing the init sequence. I remember reading that it could be needed by those not using a pull up, in 85a02c7. ( If that were the case, the pin is set HIGH in begin(), it could be set again before exiting the read method. The pin state should stay HIGH as no other read can be made in the following two seconds, so more than enough time to cover that 250ms that I would like to have removed. We would also need to make sure the first read is done after proper period if sensor needs time to wake up upon start. )

  • Second, from what I conclude after a read of the datasheet and from what I have read on several forums, the MCU should only pull the line LOW for a period of time and then leave the line to the sensor. There is a possible variable amount of time before the sensor will signal its LOW and HIGH for ~80us each while preparing the data. This part
    was changed for a busy-wait loop to ensure the library gets it at a correct time and not have the guess the wait period for all possible sensors. This has made the delayMicroseconds() calls redundant. That should also satisfy the change that was originally suggested by Wolfgang and referenced in 5ed9818.

The changes' goal is to ensure the MCU and sensor do not talk at the same time. A few comments were also added to support the code changes.

Thank you,

Pascal

DHT.cpp Outdated
// set the pin LOW within 20 to 40 microseconds.
// The (F_CPU / 16000000) is a ratio to keep the timeout to approximately
// the same period if processor used has different frequency.
unsigned long timesup = (F_CPU / 16000000) * 700;

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Your code is broken for any MCU with F_CPU < 16000000. timesup will be 0 because, for example, (15000000 / 16000000) == 0. I would recommend lowering the denominator to 1000000 (or lower, depending on the minimum supported F_CPU) and increasing the multiplier.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Excellent comment! Thanks @ianhattendorf. I will try to fix this in a near future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

DHT init sequence wrong
2 participants