Hacker News Reader

Comment by modeless | Hacker News Reader

I understand keys take time to travel, but you can press them faster if you want. On the other hand I've never understood debounce as a justification for button latency. Surely a properly designed debounce circuit would add zero latency.

View on HN

> but you can press them faster if you want

I mean, yes but not really? There's very real speed limits to the human finger, after all.

But the times given above are also quite far off - the actual keyboard numbers seem to be more in the 5-15ms range, not 30+ms. At least, my mechanical gaming keyboard is hitting 8ms on this test: http://blog.seethis.link/scan-rate-estimator/

Surely a properly designed debounce circuit would add zero latency.

If you only have to worry about false deactivation and there's no line noise, and your keys always stay down long enough to be caught by your scan interval (or they trigger an interrupt), then probably yes. If you have to worry about false activation, then probably no.

What’s a properly designed denounce circuit look like that adds 0 latency? Also, for anything that’s a gesture (eg double-click on a mouse) you need time to disambiguate. I wouldn’t be surprised if there’s something similar for the laser in terms of translating the analog signal to digital and then processing it and converting it into HID events the OS can understand.

You send the key event and THEN start the debounce timer. I think most people tasked with writing a debounce function wait for the key state to change, then start a timer for how long they think the switch will bounce for, check the state after the timer expires, and then send the key event. Obviously, that adds latency. But what you can do instead is send the key event immediately and then completely ignore events during the debounce interval.

Simple, you just ignore further input for x milliseconds after the first state change, where x is slightly less than the fastest supported double-click interval.

You certainly don't want to low-pass filter the whole thing, or otherwise wait for the contact to settle before reporting the keystroke or mouse click.

I'm thinking that a debouncer might give rise to some latency when you let go of a button, or at the very least limit the shortest possible keypress. As in the first rising edge is definitely a keypress, but the falling edge is not necessarily a release.

By definition a bounce takes time to detect. And you will get multiple bounces over a time period, so there is a tradeoff between latency and false positives and false negatives. As such, there must be a measurable latency in all debouncing mitigations. But depending on the switch this latency might be measured in microseconds, so you’re sort of right that debouncing doesn’t have to add significant latency for good switches and a good contoller. For a bad switch, and a slow controller, you might start to get into the ms range to ensure a switch is pulled high/low reliably.

Denouncing is there to prevent multiple detection where there is only one.

In general, you can make a denouncer with zero latency: the receiver still triggers on the first logic change for idle to active, but then gates any further changes for a while.

(At least, that’s how I design all my debouncers.)

There may be aspects that are specific to a matrix keyboard configuration that prevent this...

Reply on news.ycombinator.com