geekhack
geekhack Community => Keyboards => Topic started by: cirthix on Mon, 30 August 2010, 21:02:05
-
I'd like to use the same controller for a project, does anyone know what they use?
-
Yeah it is absurd really as polling rate is more for mice than for keyboards.
With that said I'm sure there is some sort of polling scanning the matrix of the keyboard but not at those levels. And either way a keyboard is an on/off device what constant polling is there to be needed except for breaking a switch.
For a mice it is far, FAR more important as the mouse is constantly sending and receiving date to and from the computer. As an example the base 125Hz polling rate of current USB spec asks the mice were it is 125 times and the mice replies 125 times, or 1000/125=8ms(millisecond).
1Khz(1000Hz) is actually not a good idea for either keyboard or especially mice. The whole reasoning behind 1Khz is to achieve something called Haptic response or Haptic update rate, a state were the input lag is so minimal it feels almost instantaneous.
Ironically when applied to mice it fluctuates between 500-1Khz(600-800 averages) constantly it's why most people stick to 500Hz or to a number based on their refresh rate. Fluctuation not sure why could be a hardware issue or a USB spec issue but whatever it is 1Khz polling rate can affect the mouse itself as the fluctuations cause issues with aiming.
To get really super technical and a bit extreme some might say overkill but I hate to say that as sometimes overkill is great. But some people back when USB could achieve 125Hz constant early 2000s would in many multiplayer games match their polling rate, monitor refresh rate, and frame rate to say 125Hz refresh rate and achieve an extreme 1:1 scenario were everything matched up a lot on quake/unreal etc.etc. On a technical point it makes sense but it's going a bit out there to achieve consistency. But it does make a good point in that 500Hz, considering most mice have a fixed polling rate(125, 250, 500 etc.etc.) can't lock in values which at least conform to the refresh rate of the monitor say for the common 60Hz LCD monitor say 480Hz(480/60=8) or 540Hz(540/60=9). Since 500/60=8.333333(uneven).
Still that last paragraph is probably unnecessary and might be a bit out there but I'm sure to some it's still nice to know. Just remember that whole razer polling is just marketing.
-
If that's true, the computer probably polls the keyboard at that rate as opposed to the controller polling the matrix. Unless you typed at like a kajillion words a minute, you wouldn't need that fast of a controller. Also, isn't the ideal scan rate related to the debouncing time of the switch?
-
Fast typist(s) can reach 10-20 keystrokes per second:
(1000 ms / 20 keystrokes = 50 ms/keystroke)
Generally you have to wait until you get an "stable" result within an small
time frame, the value self is not critical because the debounce time of an
mechanical key is < 1ms, and no human finger press an key within 10ms
down and up..
Keyboard scan rates (http://geekhack.org/showwiki.php?title=Keyboard+scan+rates&&highlight=poll+rate)
-
Also, isn't the ideal scan rate related to the debouncing time of the switch?
Yeah, that what caused the issue with letter transposition on the Filco Zero and the Das III (among others).
-
My Filco Zero works fine. I type accurately though. YMMV.
What? You don't type with credit cards?
-
Oh, I was just making a joke about having to do something ridiculous to make the problem occur. I wasn't doubting the test. And, yes, I do blame ALPS.
-
I don't have diabeetus. That, and oatmeal makes me ****.
-
Generally you have to wait until you get an "stable" result within an small time frame, the value self is not critical because the debounce time of an mechanical key is < 1ms, and no human finger press an key within 10ms down and up..
Actually, you don't have to wait for a stable result -you can register the keypress instantly, but then ignore any following bounce. So for a press, you ignore any release for 10mS or so, and the reverse on release. Cherry datasheet says <5mS bounce, but you want a margin for when switches get worn.
Sure, I can't press any single key quicker than that, but I can press two keys within 1mS of each other, and I'd like the order to be registered correctly. Obviously I wouldn't be keeping that rate up, so throughput could be much lower over the USB/PS2 interface.
So apart from the fact that debounce time will be a multiple of the scan time, the two are unrelated, if it's done right.
-
Without context, it appears that CNet mistook actuation for the full travel distance evidenced by "half the throw action." It wouldn't be CNet's fault, though. Most of the early press materials said as much.
-
So much for in-depth reporting. I could be a reporter.
-Copy/Paste press release
-Change a few words to make it seem like I wrote something
-Add a little "Captain Obvious" analysis
-?????
-Profit!
-
That, and oatmeal makes me ****.
Wouldn't most food do that?
I would certainly be afraid if it didn't...
And wow, I can't believe that BS got that far, now we're going to be handling pissed buyers for years to come lol.
-
I don't know, Cnet purposefully prefaced with "According to Razer", so it isn't like they're drinking the koolaid, just distributing it.
-
Wouldn't most food do that?
Oatmeal is high in fiber. Eating high fiber foods can prevent constipation.
So, the statement about the oatmeal is another example of something vague enough to not be completely untrue, but misleading enough so that people may quote it wrong. I.e. it would be analogous to Razer's press release, if I understand correctly what people have said about that press release ...
-
The CNet piece was a "Blog," so the reporter could "report the news" without having to have verified facts or actually do any reporting "work." I love the Web and its "News" sites.
-
Actually, you don't have to wait for a stable result -you can register the keypress instantly, but then ignore any following bounce. So for a press, you ignore any release for 10mS or so, and the reverse on release. Cherry datasheet says <5mS bounce, but you want a margin for when switches get worn.
Sure, I can't press any single key quicker than that, but I can press two keys within 1mS of each other, and I'd like the order to be registered correctly. Obviously I wouldn't be keeping that rate up, so throughput could be much lower over the USB/PS2 interface.
So apart from the fact that debounce time will be a multiple of the scan time, the two are unrelated, if it's done right.
if you press 6 keys at once (USB), its quite hard to determine the order ;-)
For the USB report self the order of keycodes in array fields has no significance.
Order determination is done by the host software comparing the contents of
the previous report to the current report..
but apart from that you get quickly stable or debounced results, because an
human press the key(s). but sure logbook entries are good to prevent multiple
or bounced report of the same key.. ;-)
-
if you press 6 keys at once (USB), its quite hard to determine the order ;-)
I'll assume you mean not quite 'at once', but within the 1/125 second window between two USB reports ;-)
The keyboard controller could buffer the scans and send changes across multiple reports to keep the order correct. But that would introduce a latency, and be bad for gaming. The (imaginary) ultimate keyboard controller would be switchable between typing and gaming modes then ;-)
but apart from that you get quickly stable or debounced results, because an human press the key(s).
Errm, I don't think us humans help any! ;-)
-
1 msec (1000 Hz) is the time of an USB frame. Whether the keyboard controller could report in each frame depends on whether it has data ready to transmit and the USB bandwidth load (whether host asks for it).
________
digital vaporizers (http://digitalvaporizers.info)
-
The CNet piece was a "Blog," so the reporter could "report the news" without having to have verified facts or actually do any reporting "work." I love the Web and its "News" sites.
(http://1.bp.blogspot.com/_RVLfSMIB7K0/SurrrjF-FEI/AAAAAAAAa28/9XTBnkP74uI/s400/death-of-print-.png)