Optional gpio input debounce

I'm dealing with an input that is pulled high and then goes low for a very small amount of time before going high again, in other words a very quick low-going pulse. The GPIO input node does not pick it up and I'm fairly certain that it is due to the debounce. I need a way to turn off the debounce feature on an input pin so that I can read very quick pulses.

One way to do this could be to have a checkbox indicating if debounce is required. If it is checked, the debounce value is used and implemented. Otherwise not.

Couple of points

Debouncing usually means ignoring any changes after the first change for a small period of time. So any debouncing shouldn't effect detection of the transition from high to low

I think setting the debounce time to 0 turns it off in any case

In my experience, debounce could be implemented in two ways. One is what you mentioned.

The other is to wait for a period of time after state change and see if the state change persists. If not, ignore.

I'm not sure how it is implemented here, but I know two things are happening :

  • No state change is detected when given a very quick pulse (< 1ms).
  • Setting debounce time to 0 causes the node to indicate "Stopped".

Sorry- your right - if debounce is set to 0 - it says stopped and ignores any changes on the input.

Which makes me now think that the debounce might not be implemented in the way I thought it was

Off to check source code to find out ...

Thanks for your effort!

If I've followed the rabbit hole correctly then the python code that handles the pin does debounce by waiting the bounce time and then reporting the pin state (the method you suggested)

Just trying to find out why a value of 0 isn't allowed

Closing in on it

My current thinking is this
node-red uses a python prog nrgpio.py to handle the Pi pins

That uses standard RPi.GPIO library

RPi.GPIO library handles debouncing internally but doesn't accept a value of 0 for bouncetime - reports an error and that error causes the node to stop

Going to see if I can make a small mod to nrgpio.py to test for 0 bouncetime

I made a mod and it worked (as in 0 bounce time doesn't stop the node from working)

I don't have a source of 1ms pulses handy (prob going to need another Pi to generate them) but maybe your able to modify the same file on your Pi and see what happens?

I'm off to bed now


1 Like

Also off to bed now. Will try in the morning and report back.

@cymplecy Happy to look at a Pull request for this mod if you want to provide one.

I rigged up a WEMOS D1 mini to produce 1ms pulses every 3 seconds and connected it to my Pi - my modified node seems to catch them reliably with bounce time set to 0

I made the changes to the code as you did above. I can confirm that a debounce time of 0 no longer causes the flow to stop.

However, it still does not catch my pulses.

I will put my pulses on a scope tomorrow and come back with more exact information of my setup.

In the meantime, a quick question. Does the GPIO node make use of the interrupt functionality of the pin? Or is it simply polling the pin on a regular basis? I can get it to work with the node-red-contrib-opi-gpio library. It uses the interrupt to trigger the change. The difference might be with how the two gpio nodes are triggered...

I don't know whether it uses interrupts or polling I'm afraid - I'll see if I can find out

What settings are you using (board type / pin number) to get this opi node to work on a Pi?

Where are you getting your pulses from BTW?

Well the code was as per above

It uses interrupts on both edges - which then call the callback code which does
ie waits for the debounce time then re-reads the pin.

What I mean is - I don't know whether the RPi.GPIO library is reacting to hardware interrupts or just doing fast polling and generating the callbacks that way - does the Pi have hardware interrupts on its GPIO pins?


Reading the RPi.GPIO docs - I think it strongly implies that it is using interrupts


Sorry for the long silence.

I have since hooked up my scope and checked the pulse width. It is a low going pulse of around 0.2ms in duration. See below (0.1ms per div):

It is generated by a diesel flow meter.

I'm using board type as "other".
I then use a stray rpi-gpio node just to enable the pullup on the pin.

I believe this is the first time you have mentioned that you are using node-red-contrib-opi-gpio node. Everyone here has (I imagine) been assuming that you are using the standard node-red gpio node. Try the standard one and see if it works ok.
In addition I dread to think what the effect of also using a standard gpio node watching the same pin is. Why are you not just using that for reading the pin, now that you can specify 0 debounce on that node?

No - they told us earlier that they got it work using it

Ah, I missed that. I take it all back.

Aah - that could possibly explain why the standard node isn't catching it - it will get triggered by the high/low transition but the pin value could have returned to it high before it state is read and sent out

I'll have a play using 0.1ms pulses and see if I can come up with method of reporting them