5 ms·

As soon as he mentioned buttons registering 15 times, I knew that some debouncing article of Jack Ganssle's would be shown.

lesuorac 3y ago
I really don't get why debouncing is such an issue in this situation. Like it only occurs when somebody has hit the button no? So if somebody hits "Accept Challenge" and then because of bounce it triggers "Accept Challenge" multiple times why does it matter? Afaik, either you can (1) trivially lock them into their first choice, (2) send the extra bounce choices (which will be a noop on the server), (3) prevent changing choices in <50ms. Any of which don't require spending 12h.
- gabereiser 3y ago
  so you can solve this one of two ways. 1) implement what they did and solve the hardware signal issue of bound (the right way). 2) implement an irq in your software reading it to poll every few ms and hope you don't read in the trough. Registering extra button clicks should not be the problem of the implementor. It's a hardware failure. However, in this case, he also is the firmware implementor so the firmware needs to be able to fire "onClick" once when the button is pressed once, regardless of bounce.
  - ilyt 3y ago
    Solving issue in hardware costs money. Most MCUs dont' have schmitt inputs so you'd need at least extra chip, diode, resistor and a cap per input
- rowanG077 3y ago
  (3) is the usual way debouncing is handled, just ignore inputs for a set time after a trigger has been detected. And this is about the second lecture in an embedded software course. So from that I got that the guys aren't really domain experts. Which honestly makes it more impressive to me that the managed to pull it off.
  - jstanley 3y ago
    My least favourite implementation of that is requiring some delay with no changes before the input is considered triggered. I have at least 2 kitchen appliances where the delay is too high, and the user experience is that you have to press and hold the button in order to trigger it, because tapping it too fast doesn't count. So frustrating, when the right way to do it is so easy.
    - bombcar 3y ago
      I would love for an “old man murray” style reviews for things like kitchen equipment and workshop tools that focused entirely on the device UI. Maybe I just need a microwave with Cherry MX keycaps.
    - geerlingguy 3y ago
      There's a ton of nuance to something as simple as debounce, and that's why the Ganssle article is so great; unlike the simple comments ("just add a 100ms sleep to your code!"), it explores the end to end experience with each given solution, both in hardware and in pseudo code. Too many people find a solution that fits the bare minimum requirement and move on, leading to years of frustration from the end users. Spend a little more time using the thing like an end user would, and you can solve that issue much better, usually.
      - guepe 3y ago
        De bouncing is solved in hw with right-sized capacitor. That's it....
        ilyt 3y ago
        You need schmitt trigger input to do it properly and most microcontrollers don't have it.
        rowanG077 3y ago
        I really, really hate HW solution for something so easily solved in Software.
- geerlingguy 3y ago
  The 12 hours were spent after everything was done, it just fit the narrative better to include the high speed footage in that segment. I had to solve the debounce more efficiently, because there were actually a few other challenge ideas which would've used the buttons and relied on more precise timing behavior. The idea was every press would be registered correctly not matter how fast someone hit one, two, or three buttons. So simpler debounce algos were out. In the end, I recommended against timing-based challenges because with those buttons and the Le Potatoes' strange behavior if you held down a button for more than 50-100ms, I couldn't guarantee every button down/button up would be registered, depending on the dexterity of the individual doing the pressing. So in an odd turnaround, one of those games might artificially boost certain age groups' ability! Also check out my blog post [1] for the exact debounce code I wound up using. [1] https://www.jeffgeerling.com/blog/2023/100-sbcs-python-flask-and-two-nucs-mrbeast https://www.jeffgeerling.com/blog/2023/100-sbcs-python-flask...
  - ilyt 3y ago
    > The idea was every press would be registered correctly not matter how fast someone hit one, two, or three buttons. So simpler debounce algos were out. ...no ? Only if you care about both on and OFF timing you'd need to get creative. You can just * trigger on interrupt * ignore that input for say 50ms (or how long you want your debounce period), whether by disabling interrupt or any other way. That way you will always catch it, on the first bounce, the fastest possible way. And as you are "NANANA NOT LISTENING" on the pin, doesn't matter whether it bounces or not. Same with holding, as long as previous registered state was ON and you get OFF, you just send the OFF higher up the stack, start the timer, and ignore any further input for that duration. I think that's what your code is mostly trying to do
  - rcarmo 3y ago
    The instant I saw that part of the video I was reminded of how I had to hack an MQTT debouncer for my doorbell sensor (which is a repurposed ZigBee door sensor with a magnetic reed switch placed near the coil). Every time the doorbell rang I got 10-20 “sensor open/close” events, which was fun. (Ended up using just one Node-RED trigger node with a suitable interval, since I already had that in the loop)
- ilyt 3y ago
  There are libraries doing exactly this. Even simple "disable interrupts for next 50ms" is good enough. Hell, resistor and a capacitor on the input would probably be enough. Or just poll every 50ms

lesuorac 3y ago

I really don't get why debouncing is such an issue in this situation. Like it only occurs when somebody has hit the button no? So if somebody hits "Accept Challenge" and then because of bounce it triggers "Accept Challenge" multiple times why does it matter? Afaik, either you can (1) trivially lock them into their first choice, (2) send the extra bounce choices (which will be a noop on the server), (3) prevent changing choices in <50ms. Any of which don't require spending 12h.

gabereiser 3y ago
so you can solve this one of two ways. 1) implement what they did and solve the hardware signal issue of bound (the right way). 2) implement an irq in your software reading it to poll every few ms and hope you don't read in the trough. Registering extra button clicks should not be the problem of the implementor. It's a hardware failure. However, in this case, he also is the firmware implementor so the firmware needs to be able to fire "onClick" once when the button is pressed once, regardless of bounce.
- ilyt 3y ago
  Solving issue in hardware costs money. Most MCUs dont' have schmitt inputs so you'd need at least extra chip, diode, resistor and a cap per input
rowanG077 3y ago
(3) is the usual way debouncing is handled, just ignore inputs for a set time after a trigger has been detected. And this is about the second lecture in an embedded software course. So from that I got that the guys aren't really domain experts. Which honestly makes it more impressive to me that the managed to pull it off.
- jstanley 3y ago
  My least favourite implementation of that is requiring some delay with no changes before the input is considered triggered. I have at least 2 kitchen appliances where the delay is too high, and the user experience is that you have to press and hold the button in order to trigger it, because tapping it too fast doesn't count. So frustrating, when the right way to do it is so easy.
  - bombcar 3y ago
    I would love for an “old man murray” style reviews for things like kitchen equipment and workshop tools that focused entirely on the device UI. Maybe I just need a microwave with Cherry MX keycaps.
  - geerlingguy 3y ago
    There's a ton of nuance to something as simple as debounce, and that's why the Ganssle article is so great; unlike the simple comments ("just add a 100ms sleep to your code!"), it explores the end to end experience with each given solution, both in hardware and in pseudo code. Too many people find a solution that fits the bare minimum requirement and move on, leading to years of frustration from the end users. Spend a little more time using the thing like an end user would, and you can solve that issue much better, usually.
    - guepe 3y ago
      De bouncing is solved in hw with right-sized capacitor. That's it....
      - ilyt 3y ago
        You need schmitt trigger input to do it properly and most microcontrollers don't have it.
      - rowanG077 3y ago
        I really, really hate HW solution for something so easily solved in Software.
geerlingguy 3y ago
The 12 hours were spent after everything was done, it just fit the narrative better to include the high speed footage in that segment. I had to solve the debounce more efficiently, because there were actually a few other challenge ideas which would've used the buttons and relied on more precise timing behavior. The idea was every press would be registered correctly not matter how fast someone hit one, two, or three buttons. So simpler debounce algos were out. In the end, I recommended against timing-based challenges because with those buttons and the Le Potatoes' strange behavior if you held down a button for more than 50-100ms, I couldn't guarantee every button down/button up would be registered, depending on the dexterity of the individual doing the pressing. So in an odd turnaround, one of those games might artificially boost certain age groups' ability! Also check out my blog post [1] for the exact debounce code I wound up using. [1] https://www.jeffgeerling.com/blog/2023/100-sbcs-python-flask-and-two-nucs-mrbeast https://www.jeffgeerling.com/blog/2023/100-sbcs-python-flask...
- ilyt 3y ago
  > The idea was every press would be registered correctly not matter how fast someone hit one, two, or three buttons. So simpler debounce algos were out. ...no ? Only if you care about both on and OFF timing you'd need to get creative. You can just * trigger on interrupt * ignore that input for say 50ms (or how long you want your debounce period), whether by disabling interrupt or any other way. That way you will always catch it, on the first bounce, the fastest possible way. And as you are "NANANA NOT LISTENING" on the pin, doesn't matter whether it bounces or not. Same with holding, as long as previous registered state was ON and you get OFF, you just send the OFF higher up the stack, start the timer, and ignore any further input for that duration. I think that's what your code is mostly trying to do
- rcarmo 3y ago
  The instant I saw that part of the video I was reminded of how I had to hack an MQTT debouncer for my doorbell sensor (which is a repurposed ZigBee door sensor with a magnetic reed switch placed near the coil). Every time the doorbell rang I got 10-20 “sensor open/close” events, which was fun. (Ended up using just one Node-RED trigger node with a suitable interval, since I already had that in the loop)
ilyt 3y ago
There are libraries doing exactly this. Even simple "disable interrupts for next 50ms" is good enough. Hell, resistor and a capacitor on the input would probably be enough. Or just poll every 50ms