Showing 1 of 2440 conversations about:
Apr 22, 2015
Under the Specification section of the description:
> 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?
Apr 22, 2015
Input Club
Apr 23, 2015
Basically, the original ergodox used an i2c bus to scan every key on the non-usb side. This is quite inefficient, because there is a communication overhead for every scan (for 1000 Hz scanning, you need to be able to scan every key at least 1000 times per second). Assuming a usual i2c bus speed of 400 kHz (likely a bit faster, but easier calcs) and 3 commands per scan (address, command, reply) at 8 bits each, with some protocol overhead (24 bits + 6 bits overheads)
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.
Apr 23, 2015
View Full Discussion