The Inner Workings of Empirisoft's DirectIN Keyboards...
... And why some of our engineering tricks won't be noticeable to the casual observer.
If you were to rip apart a regular keyboard and carefully examine the electronics inside, you'd see that all of the keys are arranged in a matrix of rows and columns.
x x x x x x x x x
x x x x x x x x x
x x x x x x x x x
etc.
This allows a large number of keys to be used while dramatically lowering the wires required in the interface. A 4 x 5 matrix can handle 20 switches but only requires 9 wires to be connected to the main microprocessor. Pins on a microprocessor are expensive, so it's good to use as few of them as possible.
To determine if a key is pressed, an electrical signal is applied to one of the columns. Then, the microprocessor tests the rows to see if the same signal is present. If it is, the switch located at the intersection of the row and column has been pressed.
Then, the next column is energized and the rows are checked again. These steps are repeated as many times as there are columns and rows in the keyboard.
Most keyboards accomplish this scanning cycle every 10 - 20 milliseconds. And this is fine - after all, how many people type faster than 100 characters per *second*?
It turns out that there are two areas where timing uncertainty can be added to your measurements: in the keyboard scan and in the debounce process.
What happens if a you press a key just *after* its particular column has been pressed? If you're measuring reaction times, your measurement could be off by 19 mS! This is uncertainty caused by the scanning process. It's no big deal if you're working on an email. But if you're probing the inner workings of the human mind, you might be concerned with the accuracy of your measurements.
At their most physical level, all switches are mechanical devices. And if we're talking about pushbutton switches which spring back in position after being pressed, the engineer who designs the circuit needs to worry about debounce glitches.
Basically, when a mechanical switch is closed, the metal contacts inside bounce back and forth before settling in their final position. All of this bouncing can trick the microprocessor into believing that several keypresses occurred, when only one was intended.
It takes 5 - 50 mS for an average pushbutton switch to 'settle' to it's final state.
So most circuit designers will take notice when a key is pressed for the first time, then check back 5 - 50 mS later to see if the the key state is still the same. If it is, the keypress is considered valid and the system acts accordingly.
For most people, a total system delay of 20 - 100 mS isn't even perceptible.
But if you're reading this, it's because you demand a much greater precision in your timing measurements.
I can't divulge all of our secrets here, but I will say that we've basically eliminated the scanning and debounce uncertainties from our keyboard design.
When you use an Empirisoft DirectIN keyboard, the state of each and every key is transmitted to your host computer 1000 times per second. It's clean and simple and very, very elegant.
The only wrinkle is that the design we're using is transparent to the end user. You won't notice that a 'spacebar' character is sent to your host computer within 1 mS of being pressed. It will just appear.
Stay tuned - we'll be publishing a series of extensive tests which compare our hardware with about a dozen off-the-shelf keyboards. The results will surprise you...
Hope this helps.
John
