Keyboard Tips & Tricks - Volume 1
CTRL + F to quickly skip to each tip/trick below: Tip #1 - Cheap Dust Cover (Shower Caps) Tip #2 - Upgrade Your Wire Keycap Puller to Plastic Tip #3 - Test Your PCB/QC Your Board Before Building Soldering-Specific: Tip #4 - Take Your Time. Set Yourself up for Soldering Success Tip #5 - Using the Right Size Soldering Tip Tip #6 - Soldering Loose Switches/Plateless Builds - Rubber Bands Tip #7 - Fixing Crooked Switches After Soldering Extra Tip - Test Your PCB After Soldering… BEFORE You Put Away Your Soldering Equipment Intro & Disclaimer A recent mistake. Mixed three sets of beige PBT keycap sets and spent a good while having to separate everything... “I wish I had known about this sooner…” I can’t tell you the amount of times that I’ve said those words out loud, or thought about them when it comes to the keyboard hobby. Whether it’s what someone in the community has told me, or something I found out myself, even things that may seem so simple as using...
Mar 11, 2025
> NKRO with dramatically improved latency between keyboard halves.
I never even knew the old Ergodox had a latency issue. Can someone expound upon both the initial latency issue and the solution used by the Infinity Ergodox?
400 kHz / 30 = 13 333 scans per second
13 333 / 38 keys = 350 total scans per second
So, even the generic scan rate is less than 1000 Hz. What makes matters worse is that to actually report a key change at 1000 Hz, you need to scan the entire matrix faster than 1000 total scans per second. This depends on the debounce algorithm, but usually isn't less than 5.
This means you need to scan the keyboard at 5 kHz. This is easy for even older micocontrollers running at a few hundred kHz (Teesny 2.0 runs at 16 MHz) because there is much less overhead.
tl;dr, hand-wavy explanation, but basically i2c is terribly inefficient for this sort of thing.
The infinity ergodox only sends "key state changes". This means that each side first debounces the key using the 72 MHz microcontroller, then sends only the event. The event is also asynchronous so no polling is required. Because of the debounce time, if the interconnect is running at a high enough baud rate it should be able to handle something like a 1000 Hz usb scan rate with ease.
Also, the 1000 Hz thing is mostly a bunch of marketing BS, but it can be helpful for keyboards with a crappy microcontroller design.