Our great sponsors
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
> I notice very significant latency with my Moonlander Mk1, but that is most likely caused by the software and fancy layered kemaps I have created.
I'm not noticing all that much latency with my Ergodox EZ, but I'm also running QMK master[1] (rather than ZSA's fork via Oryx). It would be useful to note the firmware + revision in these tests.
40ms sounds like a lot of latency for twitchy games like StarCraft II (for which I've extensively customized my layout[2]); while I'm definitely enjoying the improved ergonomics in the game, I'm starting to wonder how much it's actually impacting my performance.
[1]: forked to https://github.com/rollcat/qmk_firmware
mosh is supposed to be pretty good for ssh latency: https://mosh.org
> Is ZSA's build known to have latency issues compared to QMK?
ZSA is using a patched QMK - they even let you download the exact source for each firmware build they make for you. At the time when I switched to vanilla QMK (that was already some years ago), ZSA were veeery far behind master; running the latest QMK release fixed a couple of issues for me (like hotplugging the halves), so I guess there could be other improvements? No idea really.
> Would a faster microprocessor help
In the MCU world, latency and clock speed can have a very linear relationship - until they suddenly don't. The microcontroller's job is very simple really: scan the key matrix at a certain frequency, perform key debouncing, compare the current state with the previous, and craft a USB HID packet with key press/release events.
So having twice the clock speed could theoretically let you scan twice as often, so it might let you cut the latency in half. Except we have those pesky physics getting in our way! For simplicity let's assume we don't have split halves (where there's an extra serial connection slowing things down); I'm no EE so I only grasp these concepts at the surface level, but signals take time to propagate, and long traces on the PCB (and cables too) have a tiny bit of their own capacitance. (Capacitors are like really fast, really tiny batteries - but they still take a tiny amount of time to charge and discharge, which does all sorts of interesting things to high-frequency signals.)
On top of that, the electrical connection that the pieces of metal are making inside the switch, are never perfect at the exact instant the switch is supposed to (de)register: a couple electrons might start jumping over the air even before contact is made, and the physical connection is subject to normal wear, amplifying the "edge case" effect over its lifetime - which all together means we have to actually spend a certain amount of time "looking" at the state of the switch, to let it settle and make sure we got it right.
We end up spending so much time letting physics do its job that in a trivial firmware, the MCU is actually spending a significant amount of time... just sleeping. Which means we were later able to cram all sorts of madness like individual RGB lightning or status displays, and never decreased the poll rate.
Where would these 40ms come from then? Well I wouldn't get near the problem without an oscilloscope, and unfortunately I don't have one.
> I'm just starting to get into custom keyboards.
Then I recommend studying the original ErgoDox firmware & build instructions! It's extremely straightforward compared to a beast like QMK, which actually uses a whole RTOS.
https://www.ergodox.io/; https://github.com/benblazak/ergodox-firmware
> Is ZSA's build known to have latency issues compared to QMK?
ZSA is using a patched QMK - they even let you download the exact source for each firmware build they make for you. At the time when I switched to vanilla QMK (that was already some years ago), ZSA were veeery far behind master; running the latest QMK release fixed a couple of issues for me (like hotplugging the halves), so I guess there could be other improvements? No idea really.
> Would a faster microprocessor help
In the MCU world, latency and clock speed can have a very linear relationship - until they suddenly don't. The microcontroller's job is very simple really: scan the key matrix at a certain frequency, perform key debouncing, compare the current state with the previous, and craft a USB HID packet with key press/release events.
So having twice the clock speed could theoretically let you scan twice as often, so it might let you cut the latency in half. Except we have those pesky physics getting in our way! For simplicity let's assume we don't have split halves (where there's an extra serial connection slowing things down); I'm no EE so I only grasp these concepts at the surface level, but signals take time to propagate, and long traces on the PCB (and cables too) have a tiny bit of their own capacitance. (Capacitors are like really fast, really tiny batteries - but they still take a tiny amount of time to charge and discharge, which does all sorts of interesting things to high-frequency signals.)
On top of that, the electrical connection that the pieces of metal are making inside the switch, are never perfect at the exact instant the switch is supposed to (de)register: a couple electrons might start jumping over the air even before contact is made, and the physical connection is subject to normal wear, amplifying the "edge case" effect over its lifetime - which all together means we have to actually spend a certain amount of time "looking" at the state of the switch, to let it settle and make sure we got it right.
We end up spending so much time letting physics do its job that in a trivial firmware, the MCU is actually spending a significant amount of time... just sleeping. Which means we were later able to cram all sorts of madness like individual RGB lightning or status displays, and never decreased the poll rate.
Where would these 40ms come from then? Well I wouldn't get near the problem without an oscilloscope, and unfortunately I don't have one.
> I'm just starting to get into custom keyboards.
Then I recommend studying the original ErgoDox firmware & build instructions! It's extremely straightforward compared to a beast like QMK, which actually uses a whole RTOS.
https://www.ergodox.io/; https://github.com/benblazak/ergodox-firmware