So after that thread on cherry's keyboard controller, I got curious about my WASD V1's input latency. So naturally I broke out my soldering iron and voided my warranty. I'm now able to use an arduino to snoop a keypress directly, and pass that on to the computer, but the problem is I'm not able to do time correlation between the raw USB input from both devices(at least, not with wireshark and USBPcap). Anyone know some USB probing software that can grab raw USB data from two devices simultaneously? How about something that logs the exact time a key is pressed?
I realize it's not ideal to measure things that way, It would be better to attach the keyboard directly to the microcontroller, but I don't have a microcontroller that can act as a USB host right now, I may end up getting one in order to eliminate the arduino's USB delay and the OS as variables.
All I know so far is that the arduino on an interrupt is faster than the keyboard, though that could just be USB polling priority. (I also grabbed the part number off the keyboard controller: holtek ht82k94e ). I suspect the keyboard is between 1ms and 3ms slower than the arduino, but I have some work ahead of me to figure out exactly how big the difference is.
Measuring keyboard input lag
Re: Measuring keyboard input lag
nice work, you can write your own program that communicates with the arduino and gets key presses
there's also
http://arduino.cc/en/Reference/USBHost
but thats only for the arduino due
there's also
http://arduino.cc/en/Reference/USBHost
but thats only for the arduino due
Re: Measuring keyboard input lag
I ended up just adding a delay to the arduino until the keyboard registered the keypress first. Took about 8.5ms of delay before the keyboard registered the keypress before the arduino, which is weird because the keyboard sampled that key at least 3 times in that time. It does point to instantaneous polling, though I would have expected a much higher polling rate in that case.
As for why my initial guess was low, the arduino keyboard library is slower than expected. For example, these two lines take about 7.5ms:
As for further testing, maybe my mouse, maybe a $5 keyboard. I don't think I'll worry about the 1ms measurement uncertainty unless I test something with low enough latency that it makes a difference.
One other possibility is that the key I sampled with the arduino(keypad -), is considered low priority, and sampled less frequently than the keys that get more use.
As for why my initial guess was low, the arduino keyboard library is slower than expected. For example, these two lines take about 7.5ms:
Code: Select all
Serial.println(micros());
Keyboard.println(1);
One other possibility is that the key I sampled with the arduino(keypad -), is considered low priority, and sampled less frequently than the keys that get more use.
Re: Measuring keyboard input lag
You could just use the "bloody" mouse latency software and modify your keyboard and arduino to send M1/M2 commands and actuate them simultaneously. In Windows you can treat the keyboard as a mouse.
I think it wouldn't be too complicated to write a program that registers and timestamps keyboard events as reported by Windows, unfortunately there's nothing like that out there as far as I am aware.
I think it wouldn't be too complicated to write a program that registers and timestamps keyboard events as reported by Windows, unfortunately there's nothing like that out there as far as I am aware.
Re: Measuring keyboard input lag
That's a terrible way to measure click latency of two mice, but the software might be useful for what I'm doing, provided it displays the result in <1ms increments, so I can figure out whether the arduino or keyboard is getting polled by the system first.stirner wrote:You could just use the "bloody" mouse latency software and modify your keyboard and arduino to send M1/M2 commands and actuate them simultaneously. In Windows you can treat the keyboard as a mouse.
I think it wouldn't be too complicated to write a program that registers and timestamps keyboard events as reported by Windows, unfortunately there's nothing like that out there as far as I am aware.
Re: Measuring keyboard input lag
How is it a terrible way to measure click latency? It's actually rather precise and consistent, more so than I could achieve with my camera.
Re: Measuring keyboard input lag
By terrible, I mean I wouldn't trust it to correctly identify which mouse is faster, if they're within 5ms of each other. There are just too many confounding issues, like switch pretravel, actuating force, the leverage in the mouse button acting on the microswitch, USB polling rates, OS, etc. Then there's the issue of no absolute reference, you don't know the latency of the faster mouse, just the difference between two mice. A good way to measure the latency of a mouse is basically the same as a good way to measure the latency of a keyboard. Get a microcontroller that can act as a USB host, probe the switch terminals directly, and compare the actuation time to when that information gets sent over USB. Not the only way, but I think it's the cheapest. A raspberry pi might also work.
I did some testing using that bloody latency comparator and autohotkey to remap keyboard to mouse, but autohotkey is just too slow to get useful data out of it. Any idea for a better way to remap keyboard to mouse?
I did some testing using that bloody latency comparator and autohotkey to remap keyboard to mouse, but autohotkey is just too slow to get useful data out of it. Any idea for a better way to remap keyboard to mouse?
Re: Measuring keyboard input lag
Well, you obviously adjust your test setup so the devices are set to the same polling rate and preferably don't share controllers. The program accounting for physical traits of switch actuation isn't necessarily bad as that is a real latency factor in use as well. But you can use a common switch on both PCBs. I'd think the program is pretty accurate since it only intercepts Windows input reports just like a "mouserate" tester would.
You are right in that it is only able to provide relative results. I just think it's a simple little tool that can tell you at least something meaningful about which mouse you should use in terms of click latency and it's really the only of its kind out there afaik.
I do agree that more sophisticated setups using dedicated controllers and their ability to provide absolute measurements are superior.
In Windows you can use the Ease of Access Center to treat the keyboard as a mouse. Unfortunately only M1 or M2 can be mapped at one time as far as I am aware.
You are right in that it is only able to provide relative results. I just think it's a simple little tool that can tell you at least something meaningful about which mouse you should use in terms of click latency and it's really the only of its kind out there afaik.
I do agree that more sophisticated setups using dedicated controllers and their ability to provide absolute measurements are superior.
In Windows you can use the Ease of Access Center to treat the keyboard as a mouse. Unfortunately only M1 or M2 can be mapped at one time as far as I am aware.
Re: Measuring keyboard input lag
I don't mean just having them set to the same polling rate, but knowing which one gets polled first, and how far out of phase they are. I also don't quite trust windows drivers to give me consistent latency from two mice in use at the same time. Still just too many variables that need investigating. Using a microcontroller as the USB host, you get full control over everything except the device you're testing, very easy to eliminate variables. I may look into ease of access, but unless I can tell it to map '-' to click, I'll have to open the keyboard back up and move my test lead. I wonder if I can get my arduino to simulate both a keyboard and a mouse simultaneously, that would be a good way to test the latency penalty for different methods of keybinding.stirner wrote:Well, you obviously adjust your test setup so the devices are set to the same polling rate and preferably don't share controllers. The program accounting for physical traits of switch actuation isn't necessarily bad as that is a real latency factor in use as well. But you can use a common switch on both PCBs. I'd think the program is pretty accurate since it only intercepts Windows input reports just like a "mouserate" tester would.
You are right in that it is only able to provide relative results. I just think it's a simple little tool that can tell you at least something meaningful about which mouse you should use in terms of click latency and it's really the only of its kind out there afaik.
I do agree that more sophisticated setups using dedicated controllers and their ability to provide absolute measurements are superior.
In Windows you can use the Ease of Access Center to treat the keyboard as a mouse. Unfortunately only M1 or M2 can be mapped at one time as far as I am aware.
I also took apart a $5 membrane keyboard(kensington), but couldn't find anything convenient to probe. The microcontroller was a bare die potted onto the PCB, and there weren't any exposed pads or pins between the membrane and the microcontroller to solder a lead to. If someone cares enough I might scrape away some solder mask and probe a couple of the traces (no diodes here, so I need to reverse engineer it a bit in order to figure out which traces to probe.)
Re: Measuring keyboard input lag
Polling variance between the two devices stays within 1ms at 1kHz, so it should not be that much of a concern, although I understand your general skepsis regarding Windows' input handling of two polled devices. And like I said, I agree that using testing equipement you have full control over and get absolute measurements from is the way to go if you are looking to provide confident results.
KP_5 is used for pointer click (http://windows.microsoft.com/en-us/wind ... se-pointer). I don't want you to further mess with your WASD but I care enough to have you screw with that throwaway. Keyboard quality concerns in regards to gaming are pretty underdeveloped. I had to come up with my own tests to check for matrix scan rate and polling rate for example, no such insight out there. No real understanding of a keyboard's PS/2 latency behaviour out there either. Keyboard latency is something I would like to have proper tests for - be it to find out if there are any true low latency models to be had, if hardware or firmware modifications are possible, if some of those optical keyboards are good or just to know whether to use USB, PS/2 or good old serial.
KP_5 is used for pointer click (http://windows.microsoft.com/en-us/wind ... se-pointer). I don't want you to further mess with your WASD but I care enough to have you screw with that throwaway. Keyboard quality concerns in regards to gaming are pretty underdeveloped. I had to come up with my own tests to check for matrix scan rate and polling rate for example, no such insight out there. No real understanding of a keyboard's PS/2 latency behaviour out there either. Keyboard latency is something I would like to have proper tests for - be it to find out if there are any true low latency models to be had, if hardware or firmware modifications are possible, if some of those optical keyboards are good or just to know whether to use USB, PS/2 or good old serial.