Keyboard input lag

[MegaWatt]

Just in case someone wants to look into this, this code may be helpful for getting started

https://github.com/yoctopuce-examples/r ... _usb_pi4.c

[Chief Blur Buster]

The best way to check your keyboard's scan rate is to measure the scan rate with an oscillocope, frequency counter, logic analyzer, some multimeters, etc. That site you linked to is worthless. It listed a keyboard with a 1.5ms matrix scan interval at 20ms.

latency is harder to test, you can only compare it to some other device of a known latency, or make your own latency tester to measure it directly. a keyboard with a 1.5ms scan interval might still have 10 to 20ms of debouncing, and 1 to 10ms of usb polling latency.

You can measure overall latency with a high speed camera, but it's pretty tedious and includes more than just the keyboard. You need many samples, and you can only really compare two keyboards, you can't find the absolute latency of a single keyboard with that method.

I agree.

Very tough to standardize automated keyboard latency testing.

Even different strike ferocities may not map to different human-finger responses -- sometimes different keybaord are latency-optimized to strong finger force versus a light finger force.

I think there's an opportunity to automate this with Arduino jerry-rigs.

Earth gravity is a known "constant" that helps automation -- force-wise and time-wise. So here:

<Random Brainstorm>

• Imagine clear plastic tubes (Home Depot standard) with standardized weights inside them (Ball bearing? Metal cylinder? Needs experimentation. Make sure tube breathes (e.g. drill side-holes at bottom) to avoid the plunger effect interfering with gravity math)
• Solenoid effect (railgun effect) can raise weights back upwards to reset drop height. (Or even magnet on a belt, but I'd try solenoid effect to raise object -- simpler and no moving parts).
• Turn off an millisecond-accurate electromagnet to drop object. Earth gravity is a known constant. (Or use vibration sensor on bottom of keyboard to detect strikes.)
• Theoretically, could even be inside a coil, aka solenoid, to eliminate a motorized-electromagnet raise of a ball bearing. Drop heights for a finger-width ball bearing would be quite shallow (just few centimeters) but it would have knowable mathematics due to known Earth gravity, upon turning off electromagnet to drop the ball bearing.
• Bounce tuning may be needed. For example, 2nd electromagnet at the bottom that turns on suddenly at the end of the drop (known gravity constant). This will control your bounciness of your ball bearing or metal weight. This can be tuned to an industry standard value theoretically to match finger bounciness, or even catch a mid-air first-bounce of ball bearing, for a brief-bounce test.
• Could eve support multiple drop heights to simulate different finger-strike ferocities.
• Add a cheap force sensor (if desired) to self-monitor forces if desired.
• Add a photodiode sensor (if desired) at bottom to self-monitor accuracy of rig.
• Occasionally measure this with camera to verify accuracy. Otherwise, just trust the math (subtract gravity-drop time from electromagnetic deactivation time). You could use a photodiode at the bottom as a double-verification for gravity behaviours, as a self-verifying element.

</Random Brainstorm>

Then publish it all as a standard sub-$100 hobbyist automated keyboard lag testing rig instructions. Buy the list off Amazon, build to instructions, and have results that can be successfully compared between keyboards.

It doesn't have to be perfect, but would be millisecond accurate with the right optimizing. It could automatically log data for 3 different strike velocities too, since the vertical drop height can vary to simulate that.

Swing-bar approaches can be done too (e.g. a pole with an outstretched object that rotates to strike a key). But I love simplifying things because vertical gravity is a known latency. Swing bars can also drop (e.g. drop forward towards the keyboard), though the math for a swingbar is a bit different. Or one can use a photodiode to monitor a keystrike, but that's harder for a swingbar approach than a drop approach. A microphone/force/vibration sensor on the keyboard can stand-in.

It may not be perfectly debounce-accurate, so some optimizing may be necessary, to make sure it accurately mimics the bounciness of a human finger.

It doesn't test other parts of the lag chain, but may reasonably measure keyboard lag for multiple finger strike ferocity effects.

This rig doesn't have to be perfect. Just need SpaceX-style brilliance to come up with something. Like my cheap pursuit camera invention successfully standing-in for a $30,000 motion-blur-measurement rig in accuracy.

I'd love to see standardized keyboard-latency test rigs that are millisecond accurate.

[Sparky]

Just had a flick over the code and it appears to be trying to test exactly what I'm interested in, did anyone get to use this code ? was any measurements made ?

Yep: viewtopic.php?f=10&t=5327

[MegaWatt]

A tube with ball bearing(s) is an awesome idea, the detection of the button being pressed is simply 2 wires / contacts on top of a keycap to a GPIO pin i.e. the ball bearing shorts out the wires / makes the circuit. Obviously they'll be loads of contact bounce but I'd go with the first detection of the the pin going high / low is the ball bearing hitting the button and start timing from there - in effect ignore any contact bounce.
I guess all the automation of moving the ball bearings could come later, I'd start with a manual setup for proof of concept first.

[synchronicity]

all these gaming companies are notoriously dishonest. Except for Logitech, maybe they have responsive keyboards, but that doesn't really matter when there are already very fast optical switch keyboards from Bloody:

https://www.amazon.com/B930-Tenkeyless- ... ref=sr_1_4

article on keyboard latency:
https://danluu.com/keyboard-latency/

benchmark including Corsair K70, demonstrating the ridiculous (30ms?) delay at 1000hz even:
https://www.youtube.com/watch?v=eEswl6kZq5k

Razer's optical switches are just sourced from Bloody.

[MegaWatt]

I've used a Razer huntsman some time ago and wasn't impressed at all, there was a debounce delay worse than a mechanical keyboard plus button chatter when the key was just on the actuation point.

Like most companies they'll have a marketing department that'll make something of an optical switch or anything they're told by engineering. It could be called dishonest or what others might see as the usual BS you get from companies trying to sell products. You need to cut through the BS to get to the real deal of the product, that's why reviews are so important and the likes of blur busters.

I wonder if this could be the keyboard that sets a bench mark or whether it's all marketing BS ?

https://steelseries.com/gaming-keyboards/apex-pro-tkl

[ko4]

Wooting is legit
https://twitter.com/sunjun_kim/status/9 ... 7173860352
very interesting read as well
https://blog.wooting.nl/what-influences-keyboard-speed/

all these gaming companies are notoriously dishonest. Except for Logitech, maybe they have responsive keyboards, but that doesn't really matter when there are already very fast optical switch keyboards from Bloody:

https://www.amazon.com/B930-Tenkeyless- ... ref=sr_1_4

article on keyboard latency:
https://danluu.com/keyboard-latency/

benchmark including Corsair K70, demonstrating the ridiculous (30ms?) delay at 1000hz even:
https://www.youtube.com/watch?v=eEswl6kZq5k

Razer's optical switches are just sourced from Bloody.

Yep, bloody boards and and the G-pro keyboard specifically are quick according to my testing
viewtopic.php?f=10&t=6301
Corsair boards are pretty quick as well. Unfortunately my testing method isnt millisecond accurate but they should be around 2-4ms slower than the g pro board

[deama]

I got a Bloody B975 about 2 months ago and I did notice an improvement over my normal keyboard, in addition to the actuation being very low, it registers the key at about 1/3rd of a key's press, took me a month to get used to it as I would "accidentally" press keys when typing cause I wasn't used to how sensitive it was.
Anyway, my old keyboard was a microsoft ergonomic keyboard, it had a nice layout, but I don't know if it's response time was any good though? I saw some guy comparing response times between gaming keyboards and normal keyboards and the microsoft ergonomic one came out 2nd best, with the best one being some apple one.

[Kulagin]

No idea exactly how you'd test this

Like this:

phpBB [video]

With Arduino. Spot a difference in motion to photon latency between 1000 Hz, 2000 Hz and 8000 Hz:


Read my other post on this topic for more info: viewtopic.php?f=10&t=7084#p53050

[MegaWatt]

Impressive testing but it reminds me of the story of the paper clip, that is a device to hold two pieces of paper together.

Option 1 - opto detector to detect the presence of paper, magnetically operated jaws to clamp the paper, microprocessor to read the opto detector to provide the necessary signal to a small transistor / relay to switch the high current to the magnetic jaws. power supply - battery etc, you get my drift.

Option 2 - a curly / springy wire that you slide the pieces of paper into aka a paper clip.

Option 1 is impressive but totally unnecessary - over kill.

So my method of putting two wires on top of a button which could be any keyboard, mouse, controller button, get the shorted out wires connected to a PC via an input pin on a LPT card, simple console app that detects the shorted out LPT pin and starts timing, waits for button to be registered which will include all the Windows software layers i.e. what a game would see. Obviously time the difference between the shorted out wires and the button press, I could knock this up in 1 day.

If you're not sure what a LPT card is -

https://www.amazon.co.uk/CERRXIAN-Paral ... 081W2CT4G/

I'd probably use pin 11 which is busy and pulled high and any of the ground pins, or just set a data pin high and use perhaps a 4K7 / 10K to the data pin to pull high, inpout32 to allow direct access to the parallel port registers.

Shed load of info on the net about the parallel port, random example -

http://www.labbookpages.co.uk/electroni ... lPort.html


I guess what method you use to actuate the button might have to be experimented with, obviously some metal object to the short the wires on top of the button you're testing, ball bearing, knife / fork / spoon, you could even go a bit further and use -

https://www.amazon.co.uk/Stroke-Solenoi ... 07SZCHYF7/

with the necessary LPT output pin and transistor - relay setup to automate.