Blur Busters Forums

haven't felt any issue, did some test on some software or web soft (http://www.microsoft.com/appliedscience ... gDemo.aspx) but it did fine, but if you have a specific test you want me to try, I can try it

dhaine wrote:haven't felt any issue, did some test on some software or web soft (http://www.microsoft.com/appliedscience ... gDemo.aspx) but it did fine, but if you have a specific test you want me to try, I can try it

To test debouncing, press and release keys at different speeds to see if it sometimes registers two keypresses when it should only register one(particularly in performance mode, otherwise I don't really see why they make the slower mode default).

Given the way the keyboard captures input you may also want check the robustness when simultaneously pressing different keys that use the same pin on the MCU, like 8,9,0(not on the numpad). There will be other combinations that use the same pin, and maybe more keys on that same pin, but those were what I could easily figure out from online PCB photos. Like make sure 9 doesn't register when you're abusing 8 and 0, and make sure no other keys register presses when you're flicking all 3. I don't really EXPECT a problem here, but it's always best to verify.

Also, roll-over isn't ghosting. Basically, if you're already holding 8 keys down, does the 9th keypress get sent over USB? A keyboard has N key roll over where N is the minimum number of keys guaranteed to simultaneously register. If the keyboard says "NKRO" instead of say "6KRO" then you're supposed to be able to register any number of keypresses without messing anything up. Ghosting is when pressing two keys is electrically indistinguishable from pressing a third too. This shouldn't be the case on the cherry keyboard, but it's not as clear-cut as it is with keyboards that use diodes to isolate rows or columns.

no bug found

has any one tried to use this software to compare keyboard speed and what do you think about it ?

http://www.bloody.com/pk/

i cannot seems to get a winner whatever i'm comparing, even the bloody b640 with "optical switch", maybe logitech g910 got a slight advantage but even then it's really hard to tell, i cannot seems to draw a winner, and even then cherry mx6 looks a bit behind qpad mk85/b640/g910

Someone at https://www.reddit.com/r/thinkpad/comme ... d/e6n9dc3/ reported that pressing two keys simultaneously on the MasterKeys Pro S, a 1000Hz keyboard, makes one of the two keys appear first every time. That sounds like either the firmware is garbage or the actuation point is super inconsistent between different keys (but consistent within a single key). Has anyone else seen anything like this on a 1000Hz keyboard?

Also, by the way dhaine, your Bloody comparison posts here and at overclock were very useful to me. I think I've collected most of the keyboard latency testing done and you're the only one who benchmarked the keyboards which claim low latency. If others are interested, I can compile the info I've found.

ad8e wrote:Someone at https://www.reddit.com/r/thinkpad/comme ... d/e6n9dc3/ reported that pressing two keys simultaneously on the MasterKeys Pro S, a 1000Hz keyboard, makes one of the two keys appear first every time. That sounds like either the firmware is garbage or the actuation point is super inconsistent between different keys (but consistent within a single key). Has anyone else seen anything like this on a 1000Hz keyboard?

Also, by the way dhaine, your Bloody comparison posts here and at overclock were very useful to me. I think I've collected most of the keyboard latency testing done and you're the only one who benchmarked the keyboards which claim low latency. If others are interested, I can compile the info I've found.

Well, if it's on the same row(electrically, not necessarily physically), then it's going to be reading them at the same time(likely 8 or 16 keys are sampled simultaneously, with the whole lot shifted into memory so that they can be worked on in parallel), but still recording the results in the same arbitrary order within that row, as it takes some more work for the microcontroller to get through the debounce logic. In order to reverse that order the "second" key needs to be pressed one loop earlier. If you decode the USB packets, you'll probably find those keys are first marked pressed in the same packet, so long as the keys were pressed within a scan interval of each other. That can be several milliseconds, even if the USB polling rate is 1khz.

Thanks. So he's being screwed by his keyboard hardware, since the internal scan rate is much longer than 1ms, not just the debounce time. The USB 1000Hz on that keyboard must then be mainly for marketing purposes, like a gold-plated Reliant Robin.

It seems to me that the /r/MechanicalKeyboards community is focused mainly on customizability, build quality, and physical feel, but finds it harder to notice bad electronics, or perhaps doesn't realize how bad the electronics can be. The manufacturers don't make it easier either, with the "gaming" label being meaningless, and none of the manufacturers are willing to present data supporting their claims. Right now, the only product with benchmarks supporting good internals is the K70 Rapidfire, but it has flashy LEDs, plus durability and repair issues...

It can be a latency chain. 1000Hz can still be useful in reducing keyboard latency, even if scan latency is unchanged.

IMHO, tests will need to be developed to measure this.

Just like 60fps at 120Hz can have lag than 60fps at 60Hz in certain lag metrics.

The three approaches I think are best all have in common a test platform capable of both GPIO and USBHost.

1: Mechanical input to USB output. Attach an accelerometer or contact microphone to a mechanism that can press keys with good repeatability. measure the time between when the mechanism touches the key to when the keypress arrives over USB. (has the advantage of compatibility with all types of keyswitch and polling method, disadvantage is that it's hard to know exactly what a human keypress looks like, and consistently replicate it). Still probably the best method.

2: electrically driven event to USB output. Test device includes an electrically controlled switch(e.g. a SSR), which is connected in parallel to the keyswitch. Measure the time between when your test platform tells that switch to close, and when the keypress arrives over USB. (requires characterization and simulation of switch bounce for comparable measurements across different debounce techniques)

3: Electrical input to USB output. Attach keyswitch directly to test platform input pins, and measure the time between the test platform's first detection to the signal coming over USB. (requires reverse engineering the keyboard's scan pattern to account for the time periods in which the key is not being sampled).

Sparky wrote:The three approaches I think are best all have in common a test platform capable of both GPIO and USBHost.

The easy way I can think of is to slam the mouse button into a keyboard button at high speed. This causes some delay from physical key pressing speed, which is acceptable because humans have delay from pressing keys too. The computer times these events accurately on both Windows and Linux, and on a variety of tested consumer PCs/laptops. Choosing a good mouse button is important.

Chief Blur Buster wrote:It can be a latency chain. 1000Hz can still be useful in reducing keyboard latency, even if scan latency is unchanged.

Latency chain is right, but I expected the internal behavior to be better. The Masterkeys Pro S performs even worse than a standard OEM keyboard. They just added 1000Hz to make it look good, since nobody tests keyboards.

ad8e wrote:

Sparky wrote:The three approaches I think are best all have in common a test platform capable of both GPIO and USBHost.

The easy way I can think of is to slam the mouse button into a keyboard button at high speed. This causes some delay from physical key pressing speed, which is acceptable because humans have delay from pressing keys too. The computer times these events accurately on both Windows and Linux, and on a variety of tested consumer PCs/laptops. Choosing a good mouse button is important.

The problem is there isn't a good baseline for mouse latency. At least so far all I've seen are mice compared with other mice. Repeatability might also be an issue. There's also the uncertainty added by the USB polling interval. At best you're looking at a couple ms uncertainty in either direction on the relative measurement, without an absolute baseline.