21–30 of 30 posts
Earlier quoted context omitted.
They can, and article is just bad, as it completely ignores that and the fact you can use diodes to remove ghosting.
I've been typing for a long time, and I think I type pretty quickly. I've never felt that my keyboard is slower than my typing. At least not since ZX-81 days.
I don't get the multiplexer vs matrix argument. Wouldn't multiplexers add their own problems? You need to wait for the output to become stable when you change the input select. I'm guessing as part of the scanning, they are changing the SEL of the muxes and then waiting? The article seems to gloss over that completely. I would have thought they'd be super cheap anyway, if you're looking at $200 keyboards, spending a…
The settling time of the switch is the same, regardless of the scanning technique used.
But with a multiplexer, the output of one switch has no impact on the output of another – you can independently actuate each key. They are all essentially isolated switches with individual pull-up resistors.
The multiplexing can be done in a number of different ways, none of which need to be particularly clever. The simplest scheme is simply to connect each key directly to a GPIO on a large-pinout microcontroller, like a TQFP-144. The fewer the keys, the less GPIO you need.
This is the best way to build a keyboard, since input can be done at the clock speed of the MCU, and debouncing can happen on all pins in parallel simultaneously.
Slightly more complex would be to use a smaller MCU with a multiplexer on each input, like a 4051 or 4067. The switching time is like 20-50ns on these parts, so while it's not quite as fast as a GPIO register read, it's still pretty quick, more than fast enough for keyboards.
If you really wanted to get crazy, you could read each switch with a high speed ADC and use an ML model to debounce the keys. But at that point, you're better off just using optical switches which don't really need debouncing.
I don't get the multiplexer vs matrix argument. Wouldn't multiplexers add their own problems? You need to wait for the output to become stable when you change the input select. I'm guessing as part of the scanning, they are changing the SEL of the muxes and then waiting? The article seems to gloss over that completely. I would have thought they'd be super cheap anyway, if you're looking at $200 keyboards, spending a…
Multiplexers are only better for N-key rollover. The settling time of the switch is the same, regardless of the scanning technique used. But with a multiplexer, the output of one switch has no impact on the output of another – you can independently actuate each key. They are all essentially isolated switches with individual pull-up resistors. The multiplexing can be done in a number of different ways, none of which n…
I don't get the multiplexer vs matrix argument. Wouldn't multiplexers add their own problems? You need to wait for the output to become stable when you change the input select. I'm guessing as part of the scanning, they are changing the SEL of the muxes and then waiting? The article seems to gloss over that completely. I would have thought they'd be super cheap anyway, if you're looking at $200 keyboards, spending a…
Multiplexers are only better for N-key rollover. The settling time of the switch is the same, regardless of the scanning technique used. But with a multiplexer, the output of one switch has no impact on the output of another – you can independently actuate each key. They are all essentially isolated switches with individual pull-up resistors. The multiplexing can be done in a number of different ways, none of which n…
> The switching time is like 20-50ns on these parts, so while it's not quite as fast as a GPIO register read, it's still pretty quick, more than fast enough for keyboards.
I guess my point was that if you change which input you're reading from the mux and then immediately sample with the MCU, you'll get unstable data. 50ns is 20MHz, I can easily see an MCU used in a keyboard being fast enough to hit this.
It's obviously easy to work around, but so is ghosting.
Earlier quoted context omitted.
Multiplexers are only better for N-key rollover. The settling time of the switch is the same, regardless of the scanning technique used. But with a multiplexer, the output of one switch has no impact on the output of another – you can independently actuate each key. They are all essentially isolated switches with individual pull-up resistors. The multiplexing can be done in a number of different ways, none of which n…
This keyboard actually uses optical switches and reads them using an ADC. It does do debouncing but with orders of magnitude shorter delay.
> Depending on the quality of the switch, the bouncing time will vary. The most popular Cherry MX switches have a bouncing time of up to 5ms. This means the software delay should at least be 5ms or higher. That is incorrect. You can register and send "key held" input on the first bounce, immediately, then just ignore the key for the debouncing interval. Probably still want some capacitance on the input to not get tri…
Rhythm games have knobs to offset the music, most even have sync wizards (tapping to the beat). If you have 200ms input delay, just have the game offset the music by -200ms. It's really not a problem
The best optical linear switches in 2022 have a response time of 0.2 ms. I think we hit the point of rapidly diminishing returns long ago.
People claiming rhythm games require low latency is a pet peeve of mine. Rhythm games have knobs to offset the music, most even have sync wizards (tapping to the beat). If you have 200ms input delay, just have the game offset the music by -200ms. It's really not a problem
People claiming rhythm games require low latency is a pet peeve of mine. Rhythm games have knobs to offset the music, most even have sync wizards (tapping to the beat). If you have 200ms input delay, just have the game offset the music by -200ms. It's really not a problem
I got a cabinet for one of my favorite arcade rhythm games, Pop'n Music, a couple of years ago. It's older Firebeat hardware so it's a non-general purpose system specifically built for arcade music games not running a general purpose OS. I was surprised by how much better it felt than the newer versions of the game which run on Windows XP with inherent extra latency in its audio playback. (Other games by the same developer have taken advantage of lower latency audio apis in newer versions of Windows but iirc Pop'n hasn't gotten off XP yet.)