ESP8266 (ES 03) debouncing question

Hey all,

My ESP 8266s finally arrived (alot earlier than expected) and had a chance to be able to knock together a little script using information from the documentation/various bits of info all over the net

The problem I am getting is this

!hello|18-FE-34-9B-ED-89
!event|18-FE-34-9B-ED-89|button1|1
!event|18-FE-34-9B-ED-89|button1|0
!event|18-FE-34-9B-ED-89|button1|1
!event|18-FE-34-9B-ED-89|button1|0
!event|18-FE-34-9B-ED-89|button1|0
!event|18-FE-34-9B-ED-89|button1|1
!event|18-FE-34-9B-ED-89|button1|0
!event|18-FE-34-9B-ED-89|button1|0
!event|18-FE-34-9B-ED-89|button1|1
!event|18-FE-34-9B-ED-89|button1|0
!event|18-FE-34-9B-ED-89|button1|0
!hello|18-FE-34-9B-ED-89
!event|18-FE-34-9B-ED-89|button1|1
!event|18-FE-34-9B-ED-89|button1|0
!event|18-FE-34-9B-ED-89|button1|0
!event|18-FE-34-9B-ED-89|button1|0
!event|18-FE-34-9B-ED-89|button1|1
!event|18-FE-34-9B-ED-89|button1|0
!event|18-FE-34-9B-ED-89|button1|1
!event|18-FE-34-9B-ED-89|button1|1
!event|18-FE-34-9B-ED-89|button1|0
!event|18-FE-34-9B-ED-89|button1|0

The !hello’s are triggered when the device is restarted, I did two runs, one with the timer based debouncer and the other one without

As can be seen it reliably triggers than chucks a fit and starts missing (first !hello was with my timer based debouncer code, second is with said code disabled)

It then falls over because I sent too many messages at once. (this I can fix by simply creating a message queue so that the script does not attempt to call more than one function on the mqtt client at once)

I am serriously considering just hardware debouncing it and forgetting using interupts because it seems like they are rather unreliable.

Any thoughts anyone?

Cheers,
Max

Here is an example of a better debounce method — use the interrupt to trigger a poll of the button GPIO. Every time you poll the button, increment a “button is pressed” counter if the button is pressed, decrement the counter if the button is open. If you hit the target (in the example, 5 polling cycles), consider the button pressed.

Back to your code though: how did it display the behaviour of being “unreliable at detecting a rising edge”? Note that what you are publishing in line 61 is the current value of the GPIO at the time the m:publish line is executed. This could be anything at all, since the switch might still be bouncing. So you’re going to the effort of attempting to debounce the switch, but then just taking whatever value the switch displays afterwards.

To extend your example along the lines of the debouncing example, I would declare the (anonymous?) function that increments or decrements the bAntiBounce counter based on the GPIO, then pass that function into six sequential 2ms timers. This means you have 7 samples taken at approximately 2ms intervals. If your bAntiBounce is greater than the starting value, your switch is on, otherwise it’s off.

Something along the lines of:

bAntiBounce=5
bounce_count = function()
    // is the switch more on-ish or off-ish?
    bAntiBounce += (gpio.read(targetGpIO))? 1 : -1;
end
tmr.alarm(2, bounceTimeout, 0, bounce_count)
tmr.alarm(2, bounceTimeout, 0, bounce_count)
tmr.alarm(2, bounceTimeout, 0, bounce_count)
tmr.alarm(2, bounceTimeout, 0, bounce_count)
tmr.alarm(2, bounceTimeout, 0, bounce_count)
button_state = (bAntiBounce > 5) ? 1 : 0

More debounce suggestions:

Note that the “digital input” ports on an AVR have schmidt triggers built into them, so you can feed the output of a RC network directly into the AVR (Arduino) chip without most of the fancy wiring described in “Lab Book Pages”. I don’t know how the ESP8266 works, but check the schematics for a little triangle with a hysteresis symbol in it.

Also note that electrical engineers seem to have the worst web design skills. It’s like working with electronics gives you Geocities Syndrome.

I checked the behaviour of two buttons and a switch here in my collection. The little green breadboard-friendly buttons have a bit of bouncing for several hundreds of microseconds, the black PCB mount-but-kind-of-breadboard-friendly button seems to have a very clean transition (but maybe I wasn’t looking carefully enough) while the toggle switch has bouncing happening for tens of milliseconds.

The “poll and count” debounce method would work, as would the RC+schmidt trigger method, since even with the noisy switch the bouncing acts like a pulsed signal with reducing pluse frequency and duration.

Now if only I could figure out how to capture the traces from the DSO Quad and open them on my computer so I could share them with you :frowning:

Could always do a uni-student and use a point and shoot camera to take a photo of the screen :stuck_out_tongue:

On my DSO I have a screen cap function but it can be a bit tricky to fire so I have in the past setup my webcam to capture the screen :stuck_out_tongue_closed_eyes:

I am simply using just some wire to emulate a switch though not sure what kind of buttons I will use in the “final product”

http://www.ganssle.com/debouncing.htm