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

Chapter 14 - a suggestion to improve debouncing #9

Closed
mikebern opened this issue Oct 30, 2018 · 2 comments
Closed

Chapter 14 - a suggestion to improve debouncing #9

mikebern opened this issue Oct 30, 2018 · 2 comments

Comments

@mikebern
Copy link

I was looking at the C version of the Relay and Motor code and noticed that if I increase captureTime to 1 sec (long captureTime = 1000), then it becomes impossible to turn off the motor. It's happening because when the motor is running, it is almost impossible for the button to stay in the LOW state for a few hundred milliseconds even if it's being firmly pressed down all the time. It can be easily seen by printing a debug line when reading == HIGH. The schematic diagram and the code are the latest as of Oct 29, 2018.

The problem seems to be similar to one in issue #7 . There is an easy fix though, just adding a capacitor 0.1 uF aka "104" between "+" and "-" of the power supply makes spurious state transitions much less frequent.

So to summarize, the code works as it is now, but adding a capacitor (which is included in the set) makes the system more robust. Just wanted to share this observation.

@SuhaylZhao
Copy link
Member

Hi,

Yes, you are right. Adding a 0.1uF capacitance can really make the circuit more robust.

However, the circuit and code has no problem here, and after our tests, even the captureTime is set to 10 seconds, the project still work properly (set captureTime = 10000).

Because releasing the button also requires debouncing. You need waits the same amount of time(captureTime) from releasing to pressing again.

The code running result prompts whether the key is pressed or released, and only when released state is prompted, the key can be pressed again.

In addition, you can try shorting R2, and the test results will be better.

R2 is used to avoid that GPIO output too large current and the IO port is burned when the button is pressed. In this circuit, GPIO18 is input mode, so there is no need for using R2.

Thank you.

@mikebern
Copy link
Author

I think you are right. I was actually aware that LOW -> HIGH transition is also debounced, and I have to wait until it comes back to HIGH before pressing the button again. But I forgot to mention about the elephant in the room - I am not running the power source from 9v battery, but from AC/DC wall adaptor, which outputs 9v. I guess it's much noisier than the battery and that makes the critical difference.

So, it looks like I solved the issue that I've created for myself :) Thank you for your prompt follow up and clear explanations! I am closing this issue as it's not a real problem with the circuit.

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

No branches or pull requests

2 participants