[Just showing off] Keyboard building tutorial

[komar007]

Hi,
I've finally got down to writing a tutorial which explains how a keyboard matrix works. I've been planning this for a longer time and finished it today at 2:30 am;).
I've explained the concepts of digital I/O, scanning, ghosting and jamming. I'm hoping to extend it later if there's enough interest.
It would be nice if you could give me some feedback and ideas for further parts.
Link: http://blog.komar.be/how-to-make-a-keyboard-the-matrix/


Thanks

[Dgsbllx]

Nice going, I'll have a read through when I get lunch

Thanks 

[AGmurdercore]

Awww sh*t this is just what i needed to start working more actively on my first keyboard building project. Thanks man!

[GeeGee]

Looks good!

[yasuo]

Nice,I want real picture and real examp keyboard handwired
seemed to be the season Handwired )

Good sir

[OldDataHands]

Looks nice! Add it to the Geekhack wiki?

[Game Theory]

Thank You Komar.  Read and bookmarked.

[komar007]

Thanks everyone!;)

[plastboks]

Awesome! Bookmarked for future reference.

[JPG]

Very nice explanation!

Still, I have one simple question to ask: How much time does it take for a typical controller to scan all the columns, determine the signal to send and send it?

The reason for this question is relatively simple: Many keyboard (and device) hype is all around the polling rate (like the 1000hz), but I have read more than once that anyway this 1000hz rate is not so useful since something else is slower (never knew what is). So I wanted to know if the slow part was the micro controller having to scan all the columns and work with the information before sending it to the computer, or if it's the computer itself that is too busy/slow managing the information input?

[komar007]

1000Hz scanning is definitely possible even on a slow microcontroller, but it doesn't make sense at all. If you just scan so fast without debouncing, you'll get multiple keypresses because of the mechanical bounce properties of switches (especially used ones). So the simplest way to debounce is to scan more slowly. It can even take up to 50ms for a switch to stop bouncing, so 20-50 times per second would be a sensible rate to scan.
The harder one is to actually remember for every key when it was pressed and ignore its press and release events for a particular period of time, like 50ms, but still scan fast.
So the whole difference between scanning at 1000Hz and 50Hz is that because you scan every 20ms, you can get up to 20ms lag, whereas with 1000Hz the lag is just 1ms. Whether it matters for a human being, I don't think so. I don't know if a human being is capable of noticing a 20ms lag at all... Except for that someone should make some research on the extra lag introduced by the protocol and the OS. The OS has a lot more important things to do than receiving keypresses, and I think it might take some extra time for them to get to the application.
As for limitations, 1000Hz is the limit for USB, because this is the maximum rate a keyboard can send new reports to the computer at. You also have to remember that any other devices connected to the same hub transmitting data will likely decrease this rate. USB devices are polled, so they can't initiate any transmission on their own, it all depends on the computer.

[AGmurdercore]

I don't much about this repeat rate but what i can say from personal exp is that this can matter alot in certain games like for instance starcraft 2, especially if you play zerg. With this high repeat rate you can make unit from the larva you have like instant and with just the normal repeat rate it takes some time. Sorry for the reference that not everyone will get but this is the best i can use in my case 

[nano]

1000Hz scanning is definitely possible even on a slow microcontroller, but it doesn't make sense at all. If you just scan so fast without debouncing, you'll get multiple keypresses because of the mechanical bounce properties of switches (especially used ones). So the simplest way to debounce is to scan more slowly. It can even take up to 50ms for a switch to stop bouncing, so 20-50 times per second would be a sensible rate to scan. The harder one is to actually remember for every key when it was pressed and ignore its press and release events for a particular period of time, like 50ms, but still scan fast.
So the whole difference between scanning at 1000Hz and 50Hz is that because you scan every 20ms, you can get up to 20ms lag, whereas with 1000Hz the lag is just 1ms. Whether it matters for a human being, I don't think so. I don't know if a human being is capable of noticing a 20ms lag at all... Except for that someone should make some research on the extra lag introduced by the protocol and the OS. The OS has a lot more important things to do than receiving keypresses, and I think it might take some extra time for them to get to the application.
As for limitations, 1000Hz is the limit for USB, because this is the maximum rate a keyboard can send new reports to the computer at. You also have to remember that any other devices connected to the same hub transmitting data will likely decrease this rate. USB devices are polled, so they can't initiate any transmission on their own, it all depends on the computer.

50ms seems a bit too long for a keyboard switch. Cherry MX Datasheets say they have a debounce time of maximum 5ms. I measured a very old MX Black switch from a keyboard I rescued from e-waste with a scope and even that old key only had a worst case debounce time of 3ms. We have a very nice thread about debouncing already that might be interesting for you .

There are debounce methods that can take advantage of 1000Hz scanning but as you said humans won't really notice the difference.

[Matt3o]

wow komar you are a rockstar!

[nano]

Very nice explanation!

Still, I have one simple question to ask: How much time does it take for a typical controller to scan all the columns, determine the signal to send and send it?

The reason for this question is relatively simple: Many keyboard (and device) hype is all around the polling rate (like the 1000hz), but I have read more than once that anyway this 1000hz rate is not so useful since something else is slower (never knew what is). So I wanted to know if the slow part was the micro controller having to scan all the columns and work with the information before sending it to the computer, or if it's the computer itself that is too busy/slow managing the information input?

It's easy to achieve true 1000Hz response with a atmega32u4 clocked at 16MHz. Soarer's converter is the best example.

[JPG]

From he knowledge I have accumulated this far, if the controller maintain the state of every switch in memory, it could scan the switches often enough to have no lag at all that would depend on the scan of the switches itself, since the longest wait time is the debounce of the switch itself. Still, the polling rate is an "added" wait time since it occurs after the debounce is completed (because one the debounce is completed and treated by the controller, the polling rate will be the longest added time).

So, in this perspective would using a ps/2 cable improve the chance the information is treated faster, or will it be negligible because of other factors?

My hypothesis behind all of these questions is that since there is already a "wait time" for the debounce and a "wait time" for the human reaction time (lets say 20ms and 50ms respectively at best), well if we manage to lower all the other waits so that they at least become insignificant compared t the other waits it would in fact be a good thing (for gamers). So if we manage to keep a <5 ms total time to do everything, it would mean be negligible compared to the 20 and 50 ms already there no matter what. But if the added time is in the order of 25/50 ms, then it is not negligible because it is in addition to the other wait times.

Am I thinking in the right direction or is there a big flaw in this reasoning?

[MOZ]

Amazing work!

[nano]

From he knowledge I have accumulated this far, if the controller maintain the state of every switch in memory, it could scan the switches often enough to have no lag at all that would depend on the scan of the switches itself, since the longest wait time is the debounce of the switch itself. Still, the polling rate is an "added" wait time since it occurs after the debounce is completed (because one the debounce is completed and treated by the controller, the polling rate will be the longest added time).

So, in this perspective would using a ps/2 cable improve the chance the information is treated faster, or will it be negligible because of other factors?

My hypothesis behind all of these questions is that since there is already a "wait time" for the debounce and a "wait time" for the human reaction time (lets say 20ms and 50ms respectively at best), well if we manage to lower all the other waits so that they at least become insignificant compared t the other waits it would in fact be a good thing (for gamers). So if we manage to keep a <5 ms total time to do everything, it would mean be negligible compared to the 20 and 50 ms already there no matter what. But if the added time is in the order of 25/50 ms, then it is not negligible because it is in addition to the other wait times.

Am I thinking in the right direction or is there a big flaw in this reasoning?

Your reasoning is very sensible!
The keyboard should not be the bottleneck for gamers and in fact its possible to get the keyboard latency as low as 1ms.
Soarer mentioned how to do so in the debounce thread. Instead of waiting until the Switch finished bouncing you send the key press as soon as the first "bounce" is received. Then you just make sure not to send other key presses for the next 5ms. With this method key presses and releases are send to the computer immediately with PS2 and every 1ms with USB. I think there is no difference between USB at 1000Hz and PS2 if you use the described debouce method.

[komar007]

Your reasoning is very sensible!
The keyboard should not be the bottleneck for gamers and in fact its possible to get the keyboard latency as low as 1ms.
Soarer mentioned how to do so in the debounce thread. Instead of waiting until the Switch finished bouncing you send the key press as soon as the first "bounce" is received. Then you just make sure not to send other key presses for the next 5ms. With this method key presses and releases are send to the computer immediately with PS2 and every 1ms with USB. I think there is no difference between USB at 1000Hz and PS2 if you use the described debouce method.

Yes, sending the keypress as soon as it's seen is the most sensible solution, of course debouncing should be performed for every switch separately, so that waiting for one key doesn't block the others.
I think I will end up doing just that for GH60 in the end, but it requires a bit more work of course.
I'm still curious if pro-gamers are really able to tell the difference. I promised someone (sorry, just don't remember whom) to release 2 versions of GH60 firmware with different scan rates and refund the money for GH60 for that person if they manage to tell me which is which reliably.
There's still time until GH60 is shipped so I'm just saying I haven't forgotten;)