I am using an EL817S optocoupler to interface a 12 V push-button signal to an ESP32 GPIO.

After pressing the button once, the ESP32 GPIO sometimes detects multiple HIGH/LOW transitions. The GPIO is configured with GPIO_INTR_ANYEDGE, so each transition can generate an event.

The signal path is:

12 V push button → EL817S → header connector → separate MCU PCB → ESP32 GPIO

I would like to determine whether the multiple transitions are caused by mechanical switch bounce, optocoupler behavior, noise on the inter-PCB connection, or the input circuit.

Questions:

1. Can the EL817S output produce multiple transitions due to input bounce/noise?
2. Should I add an RC filter/capacitor at the optocoupler output?
3. What R/C values would be suitable for this ESP32 GPIO input?
4. Could the capacitor cause slow rise/fall times or affect GPIO detection?
5. Is hardware filtering + ~50 ms firmware debounce recommended?

The MCU input currently has a pull-down and uses GPIO_INTR_ANYEDGE. I have attached the EL817S schematic and component values for reference.

I would appreciate suggestions on the appropriate hardware filtering and debounce approach.

 

For starters, change the GPIO setting to GPIO_INTR_POSEDGE.
This will give half as many interrupts but will not solve the problem.

I would add hardware debounce on the push-button.
Also, you don’t need two resistors R15 and R16. One resistor will do.

 

Try this. You can change R15 to 2K7 but it would not make much difference. The LED current would decrease from about 4 mA to about 3 mA.
As an alternative solution to try, use your original circuit but change C6 to 1 μF.
And you don’t need GPIO pulldown since R17 is already your pulldown resistor.

 

Why not just use a software debounce by adding a 100ms delay before it can accept/respond to another interrupt signal, no hardware debounce needed?
Or is that not practical with the ESP32?

 

To provide a positive state change for the input, have the pushbutton deliver a "SET" to an "RS" FF, and then use the "Q" out to set the "GPIO41-D2 The processor module can "ack" with a pulse to that ff's "R" , and "Q" will return to LO. That is a classic method.

 

Why not just use a software debounce by adding a 100ms delay before it can accept/respond to another interrupt signal, no hardware debounce needed?
Or is that not practical with the ESP32?

I seldom am able to modify the software that I must attach hardware to, as I do hardware not software. Thus a FF debounce is simpler, not needing to mount components. Other methods are certainly valid, but less convenient for my use. So far.
OPTO-Couplers do have a fast response time and so hey waill not help with "de-bouncing" the mechanical switch signal.

 

I seldom am able to modify the software that I must attach hardware to, as I do hardware not software. Thus a FF debounce is simpler, not needing to mount components. Other methods are certainly valid, but less convenient for my use. So far.

My question obviously was directed towards the TS, who I assume, it also dealing with the software.