Cherry MX2A The good, the bad, and thhhe uggggly.So after building Nyan Keys
https://geekhack.org/index.php?topic=122016.0 an FPGA based keyboard designed for low latency, I decided to pair it up with Some of the new Cherry MX2A switches that said that they typically have less than 1 ms of latency! This would pair perfectly and give my board the ultimate apparent scan rate of >1000hz. If they worked...
TL;DR Cherry MX2A switches don't reliably perform under 1ms debouncing as advertised, but it won't matter anyways if you implement your debounce logic properly.
Lets start off with this snippet from Cherry's website.
"Precision Meets Longevity Through a meticulous 2-point welding process, our contacts are attached and integrated with robust resilience. This precision ensures a breathtakingly rapid debounce time of typically less than 1 ms and a lifespan exceeding 100 million clicks for select switch types."
Src.
https://www.cherrymx.de/en/mx2a.htmlSo I order 95x Cherry MX2A Browns from Keychron and wait... Fast forward to today, a knock on my door and 95x Cherry MX2A Browns are sitting in a jar just waiting for me to solder up and enjoy their glorious "debounce time of typically less than 1 ms" unbinding Nyan Key from the Kailh 5ms debounce time.
Some time later ... A fresh Cherry MX2A Nyan Keys is born.
I have a FPGA bitstream that creates a 1ms debounce timer length and write that to Nyan OS. Everything feels initially good! The switches are now allowed to change state just 1ms after an impulse (press or release) and there aren't any multiple presses.
After typing just 15 words I end up with my first "ooo" This was initially chalked up to just the way I was typing. After another few words a "vv" and then a "iii" appeared. These switches were certainly bouncing for more than 1ms. To add to the problem it wasn't a single switch it was multiple meaning this wasn't a one off outlier switch that just seemingly had a manufacturing defect. It was inherent to these switches.
Now I had to confirm my suspicions, I break out the ole' HP Infinium scope and start measuring and .... within 4 triggers.
A bounce period of nearly 2.0ms shows up. I repeat this again and again on various MX2A browns and they all are yes better at having a lower debounce time than Box Jades for example but the reality is the typically 1ms number is a far cry from the reality you will see with these switches. With all instances being lower than 3ms but bouncing longer than 1ms occoured far more often to warrant Cherry stating "typically" under 1ms.
At the end of the day I wouldn't recommend buying MX2A switches for their debounce properties because they will not live up to the marketing.
Here is why it doesn't matter!
If you send the state of the key at the impulse, then arm the debounce timer that prevents the state from changing. The key state is still sent right away, the state just can't change until the debounce timer has counted to the target. These timers can be set to a very conservative value such as 5ms and have no effect because we as humans can't press and release a key in 5ms! So by the time you release the key, the debounce timer has already completed and the release is also sent instantly!
Here is an example from Razer's website showing how a debounce works in their keyboard with a standard mechanical switch! Notice they wait the debounce delay before sending the signal? They could instead just send the signal instantly if they used my method! This would reduce their products latency!
src:
https://www.razer.com/razer-optical-switchAlso razer could improve their product latency quite a bit if they switch to sending the signal on impulse then just lock the state for the duration of the debounce.
