3 ms·

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 debou

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

> 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)