3 ms·

Some folks here might be familiar with QMK. I did a bit of tinkering with an Atmel-based split keyboard with a traditional matrix design (just like almost all c

Some folks here might be familiar with QMK. I did a bit of tinkering with an Atmel-based split keyboard with a traditional matrix design (just like almost all custom mech keyboards). My findings: the scan rate is around 200-2000hz (number of times a single key is checked per second). Having a split does lower this number, so does enabling i2c for either split communication or RGB. I measured latency with an oscilloscope by checking the speed from having a key scan to a NumLock LED lighting up on the keyboard. It is variable, from 5ms all the way to 30. I hear that ARM is way better in this regard. And ZMK might be better, too.

MivLives 5y ago
Wouldn't ZMK be slower due to having to handle bluetooth? Do you have the full data for each QMK feature written out anywhere? Or is just roughly something like, more features turned = more lag. Did you get faster input when you only used one side of the split?
- the_gipsy 5y ago
  I think you can run ZMK without bluetooth.
- Scene_Cast2 5y ago
  I tried a standard config (think BFO-9000 default config). Here are some numbers. Main refers to the left half of the keyboard connected to USB. "Other" refers to the right half, connected via a TRRS cable to the left half. Serial for comms, measurement on main half, other half disconnected. 7-13ms Serial, measurement on main half, other half connected. 8-16ms Serial, measurement on other half, main connected. 9-19ms i2c, measurement on main, other not connected, 5-15ms i2c, measurement on main, other connected, 6-16ms i2c, measurement on other, 10-20ms Not sure if any of the above is stat-sig. Measurement methodology - hook up one probe to the key and trigger on having the key scan seeing "key down". The other probe went to two pins I designated as a NumLock LED. In terms of matrix refresh rate - I remember that enabling reporting to console slowed things down significantly, i2c slowed things down, enabling features slowed things down. No hard numbers unfortunately. ZMK - just because it's a fresher codebase & support for 32-bit only. I did no measurements of ZMK.
  - MivLives 5y ago
    Interesting, thank you for the numbers!

MivLives 5y ago

Wouldn't ZMK be slower due to having to handle bluetooth? Do you have the full data for each QMK feature written out anywhere? Or is just roughly something like, more features turned = more lag. Did you get faster input when you only used one side of the split?

the_gipsy 5y ago
I think you can run ZMK without bluetooth.
Scene_Cast2 5y ago
I tried a standard config (think BFO-9000 default config). Here are some numbers. Main refers to the left half of the keyboard connected to USB. "Other" refers to the right half, connected via a TRRS cable to the left half. Serial for comms, measurement on main half, other half disconnected. 7-13ms Serial, measurement on main half, other half connected. 8-16ms Serial, measurement on other half, main connected. 9-19ms i2c, measurement on main, other not connected, 5-15ms i2c, measurement on main, other connected, 6-16ms i2c, measurement on other, 10-20ms Not sure if any of the above is stat-sig. Measurement methodology - hook up one probe to the key and trigger on having the key scan seeing "key down". The other probe went to two pins I designated as a NumLock LED. In terms of matrix refresh rate - I remember that enabling reporting to console slowed things down significantly, i2c slowed things down, enabling features slowed things down. No hard numbers unfortunately. ZMK - just because it's a fresher codebase & support for 32-bit only. I did no measurements of ZMK.
- MivLives 5y ago
  Interesting, thank you for the numbers!