3 ms·
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 lik
by 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 agoI think you can run ZMK without bluetooth.
- Scene_Cast2 5y agoI 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 agoInteresting, thank you for the numbers!