Keyboard Firmware Updates That Changed a Measurement

Two attitudes meet whenever a board ships with a firmware tool. One is to ignore the updater entirely, on the grounds that the keyboard works and an update can only break it. The other is to install every release the day it appears, on the grounds that newer must be better. We logged both approaches across several boards, and the measurements disagreed with each of them in turn.

Some updates moved a latency figure by more than a hardware change would have, and some moved it the wrong way. A few changed nothing at all except the version string. The pattern only becomes clear if you measure before and after, which almost nobody does because the updater does not ask you to.

What can firmware actually change in a keyboard?

Firmware controls the matrix scan order and rate, the debounce window, the report rate, and how the board behaves over the radio if it is wireless. Every one of those appears in an end-to-end latency figure, so a firmware change has more room to move the result than a switch swap does. It also controls power behaviour and lighting, which matter less.

The interesting consequence is that two boards with identical hardware can measure differently purely because of the code inside them. We saw that directly when the same model shipped with two firmware revisions and produced different distributions on the same rig.

How do you measure before and after without fooling yourself?

Keep everything else fixed: same port, same cable, same host, same time of day, and the same number of samples. Firmware differences are often smaller than day-to-day variation, so a handful of presses will not separate them. We used long runs and compared distributions rather than averages.

Record the version string before you flash. Several updaters do not show the previous version afterwards, and once it is gone there is no way to reproduce the earlier condition. On boards that allow downgrading, note the exact file as well, because releases are sometimes withdrawn.

Did any update actually reduce latency?

Two of them did, and both were debounce related. One release shortened the default window after the vendor evidently reviewed bounce data, and the end-to-end figure improved by a margin that a hardware change would have struggled to match. The improvement showed up in the average and in the worst case at the same time.

The other shortened the scan interval, which tightened the distribution without moving the average much. That is the more useful kind of change, because consistent timing is what a player actually adapts to. Both were free, and both were invisible unless measured.

Did any update make things worse?

One did, measurably and consistently. A release that added features to the lighting engine lengthened the worst case in our logs, presumably because the controller was doing more work between scans. The average barely moved, which is exactly why an average-only test would have missed it.

That case is worth remembering because the update was not a bug. It did what it promised, and it cost latency to do it. Vendors rarely publish that trade-off, so the only way to know is to run the measurement yourself after every release.

Why do worst cases move more than averages?

Because added work inside the controller shows up as occasional delays rather than a uniform shift. A scan that is normally prompt but occasionally waits for another task produces a long tail while the centre stays put. Averages are insensitive to tails, and tails are what a player feels.

Our standard report therefore includes the slowest slice of the distribution alongside the mean. Looking at the worst tenth of the samples changed the ranking of firmware versions on more than one board, and it changed it in the direction that matched how the board felt.

Does wireless firmware behave differently from wired?

It has more variables to tune. Radio firmware can change transmit power, retry behaviour and sleep transitions, and each of those affects timing. We saw a wireless release that improved battery life and widened the latency distribution at the same time, which is a completely reasonable trade that the release notes did not mention.

Wired boards have fewer knobs but are not immune. A change to how the controller handles the USB endpoint altered the spacing of reports on one unit, and that spacing is precisely what a high-rate setting depends on being even.

What should you do before pressing update?

Measure the current version, write the numbers down, and keep a copy of the current firmware file if the tool allows it. Then update and measure again with the same method. If the worst case got worse and you care about timing, look for a way back.

Read the notes for words about power, lighting or radio rather than latency. Those are the changes that tend to cost timing, because they add work to a controller that was previously doing very little between scans.

Is a board without updatable firmware a disadvantage?

Not necessarily. A fixed firmware cannot regress, and it cannot be improved either, which makes the measurement you take today valid for the life of the board. That predictability has real value if you have already found a unit you like.

The advantage of an updatable board is optionality: a vendor can fix a problem after you buy. The cost is that a vendor can also introduce one. Deciding which you prefer depends on how much you trust the release process, and measuring after each release is the only way to find out.

How often do these changes actually matter?

Rarely for typing and often for timing-sensitive use. A change of a fraction of a millisecond is invisible in a document and visible in a fast target switch, which is why the same update can be irrelevant to one reader and important to another. Knowing which reader you are is the first step.

For our purposes, any change that moves the worst case by more than the spread between two boards of the same class is worth acting on. That is a small number, and it is why the measurement has to be repeatable rather than casual.

What is the next thing worth logging?

How do you know whether an update is worth installing?

Read whether it touches the scan, the debounce, the report rate, or the radio. Those four change timing, and everything else mostly does not. A release that only addresses lighting or compatibility is unlikely to move a measurement in either direction.

Then measure after installing. That is the only reliable test, and it takes less time than reading the release notes carefully. Vendors do not publish latency deltas, so the measurement is the only source of that information.

What happens if an update is withdrawn?

Sometimes a release disappears from the tool, and occasionally a device is left on a version the vendor no longer offers. Keeping the previous file means you can go back, and it costs nothing to store. Several of our comparisons depended on having an older file available.

Where downgrading is not possible, the measurement you took before the update is still useful. It tells you what you lost, and it gives you something concrete to send to support rather than a general complaint.

Do different boards from the same vendor behave alike?

Not always, because firmware is often written per model rather than shared. We saw two boards from one vendor respond differently to the same nominal change, which means an experience with one product does not transfer to another in the same range.

Treating each board as its own case is the safe approach. The method stays the same and the conclusions have to be redrawn, which is a small price for avoiding a wrong assumption carried across from a different model.

Does an update change how a board behaves on battery?

It can, because power management lives in the same firmware as everything else. A release that improves standby behaviour sometimes changes how quickly the board returns to full reporting after idle, and that transition is visible as a slow first press after a pause.

Testing for it means logging a press after a deliberate pause as well as during continuous typing. A board that looks fast in a continuous run can be noticeably slower on the first press after rest, and that is what you feel in ordinary use.

What if the vendor never ships updates at all?

Then the board is a fixed quantity, and the measurement you take today describes it for as long as you own it. That is a legitimate design choice rather than a deficiency, and it removes a whole category of surprise from ownership.

It does mean any problem found after purchase stays. Weighing that against the benefit of occasional improvements is a personal call, and it depends mostly on how much you trust the vendor to test what they ship.

Once firmware is understood as a variable, the same before-and-after method applies to everything else that can change silently: a host update, a driver, a different port, or a new cable. Building the habit of measuring each change is more valuable than any single result, and it is how you find out which changes actually did something.