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.
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
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)
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
[edit]
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 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...
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?
[edit]
Reading the RPi.GPIO docs - I think it strongly implies that it is using interrupts
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?
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
