geekhack
geekhack Community => Keyboards => Topic started by: keyb_gr on Sat, 01 August 2009, 18:03:08
-
I was wondering what kind of matrix a standalone keypad might use (any input from owners?) and whether NKRO wouldn't be comparatively simple with those.
This brought me to the question of how many keys you could possibly squeeze into a rectangular m x n matrix without blocking effects, without using diodes of course.
The "no ghosting" approach
Getting (m + n - 1) keys is easy:
n 0 1 2 3 4 5 6 7 8 9 A B C D E F
m
0 x x x x x x x x x x x x x x x
1 x
2 x
3 x
4 x
5 x
6 x
7 x
No ghosting is possible in this matrix.
Throwing in some brains
Now let's say we have a somewhat smarter microcontroller. If we declare anything outside the first row and column invalid, we can do one more, i.e. (m+n) keys:
n 0 1 2 3 4 5 6 7 8 9 A B C D E F
m
0 x x x x x x x x x x x x x x x x
1 x
2 x
3 x
4 x
5 x
6 x
7 x
But that's not all. If we sacrifice the position we just added, we gain (m-1) other positions, for a total of (n + 2(m-1)):
n 0 1 2 3 4 5 6 7 8 9 A B C D E F
m
0 x x x x x x x x x x x x x x x
1 x x
2 x x
3 x x
4 x x
5 x x
6 x x
7 x x
In any 2x2 matrix segment, a maximum of 3 corners are in use, and when there are 3, the 4th one is the (0,0) position which we'll just declare invalid and ignore.
As you can see the benefit is greatest for a square matrix. (That one also has the largest number of internal connections for a given number of crosspoints, of course. #conn = 2mn - m - n, and mn = C.)
Higher dimensions
I wondered whether further efficiency might be gained when going to 3-dimensional matrices (given that we gained (m-2) positions over the one-dimensional case with a (m+n)*1 matrix and the same number of external connections).
For a m x n x o matrix, #conn = 3mno - mo - no - mn.
One might think that the number of connections would quickly rise to impractically high values, but it's not that bad, with 144 for a 4x4x4 matrix vs. 112 for an 8x8. Routing all of these might become a textbook-level mess though.
Unfortunately my imagination is not quite sufficient for on-the-fly inspections of 3D matrices, so I don't really have a good idea about the maximum blocking-free number of keys one might achieve here. Sounds like a job for a mathematician who's into topology or somesuch, or at least a 3D guy.
-
The 3rd matrix can fail if 4 keys are pressed.
I had the idea of a 3D matrix too, but the problem is that simple switches only make a connection between two points. If you used double pole switches or placed some electronics at every switch maybe you could get around that, but it would also defeat the point of multiplexing a grid of switches in the first place.
-
The 3rd matrix can fail if 4 keys are pressed.
For which ones, for example? I was assuming any registered keypresses outside the marked valid positions to be ignored.
I had the idea of a 3D matrix too, but the problem is that simple switches only make a connection between two points.
:doh:
:Cry:
Oh boy. How'd I miss that? :embarassed:
-
For which ones, for example? I was assuming any registered keypresses outside the marked valid positions to be ignored.
I think I was wrong, five keys may be needed to cause confusion.
E.g. pressing ABCDE or ABCEF has the same effect, linking 3 rows and 3 columns:
-
Still, 5 keys is pretty good actually. With a little bit of creative routing, you can make a fairly good layout with that.
The only problem now is to actually find a controller with that many outputs, which will most likely be expensive anyway. On the other hand, you could just take a standard microcontroller and employ some creative multiplexing to get that many output lines.
But then--why? The iRocks board I traced a few days ago (I'll post the matrix table tomorrow, too tired right now) is already pretty good with a standard 8x18 matrix (also includes ISO support in the layout); doing anything fancy will make everything horribly complicated and/or expensive.
You could go from regular 2-key rollover to 3-key rollover via software if you create a weird matrix where you assume seldom-used keys won't be pressed while pressing 2 other keys (if you do press them, though, it's time for ghosting!), but even this doesn't seem to be neccessary.
Any extra/non-standard components are quite expensive, whereas software is virtually free based on the number of keyboards you sell, so software alterations could be used to make this happen. The disadvantage: This would require some serious routing madness, quite possibly even a two-side PCB, making everything unattractive again, as they're expensive as well. Also--there aren't many seldom used keys.
A short example which also illustrates the problems quite nicely:
A B
1 w a
2 s ScrLck
3 NumLck d
4 q Pause
5 PrtSc e
6 space WinApp
If you make the assumption neither ScrollLock, NumLock, Pause, PrintScreen nor the Windows Application key is pressed with w and a, this will allow the controller to give you q, w, e, a, s, d and the spacebar "for free"--if you don't take routing into account. Now look at your keyboard and imagine a trace goind from S to Scroll Lock and you know why this isn't done as far as I know.
-huha
-
I think I was wrong, five keys may be needed to cause confusion.
E.g. pressing ABCDE or ABCEF has the same effect, linking 3 rows and 3 columns:
I see. So much for this, then.
Diodes ftw, it seems.
-
I see. So much for this, then.
Diodes ftw, it seems.
Yes, but they have to be fairly specific groups of five, so it still works pretty well.
And if you add just a few diodes here and there it would be even better, with minimal cost/work.
-
what's wrong with diodes? they don't add extra complexity to the layout and they are pretty cheap.
-
what's wrong with diodes? they don't add extra complexity to the layout and they are pretty cheap.
Ever tried adding diodes to a membrane? :-)
-
Ever tried adding diodes to a membrane? :-)
I wonder how the (Fujitsu-)Siemens folks did it. Glue them on?
-
Ever tried adding diodes to a membrane? :-)
Membrane? yakk :faint2:
I meant, if you design a matrix from scratch (with mechanical key switches :)) I don't see a reason for not using diodes.
-
Membrane? yakk :faint2:
I meant, if you design a matrix from scratch (with mechanical key switches :)) I don't see a reason for not using diodes.
I agree, but even the Model M uses a membrane to connect the switches to the controller, as do some other mechanical-switch keyboards.
So you need either diodes in the switches (like some Cherries) or the switches need to be mounted on a PCB where you can install diodes.
Model Ms are out of luck on both counts, so a diode upgrade would be difficult to impossible.
-
... (like some Cherries) ...
Oh I didn't know that. Very cool idea. I don't remember seeing it on their website though, can you send a link? I should bookmark it for future projects :)
-
To elaborate on Rajagra's statement: only the keys on one of the main lines would need diodes (either vertical, horizontal or diagonal). Other combinations cannot yield ghost keys if the controller is smart enough to discard ghosts in spots where there is no key.
Still, I wonder how the membrane for a matrix like this would look; don't forget you only gain 3 keys for each row and column you add. It may become quite complex for a 100+ key design.
-
Oh I didn't know that. Very cool idea. I don't remember seeing it on their website though, can you send a link? I should bookmark it for future projects :)
http://www.cherrycorp.com/english/switches/key/mx.htm
Second from last in the part number:
D No LED, with diode
Seemingly Cherry boards ship with "J" switches (jumper wire) then.
I have tried to photograph some diode-equipped blacks but couldn't really tell the orientation of the diode. A case for the multimeter, but I didn't feel like disassembling the G80-1000 (you actually need a screwdriver for those, and I'm spoiled from clipped 3000s).
Still, I wonder how the membrane for a matrix like this would look; don't forget you only gain 3 keys for each row and column you add. It may become quite complex for a 100+ key design.
I was thinking more of a numpad application. For 17 keys it shouldn't be that bad.