Hacking a TypeMatrix 2030

[dmw]

As a testbed for firmware development, I've taken a TypeMatrix 2030 keyboard, and replaced its microcontroller with Atmel's AT90USBKey demo board.  Unfortunately, I didn't take pictures of the building process, but I can share the finished product.

Starting with the keyboard:


I removed the original board, and cut off the end with the original MCU.  Then I painstakingly soldered tiny wires from the mylar edge connector, the LEDs, and power & ground lines to a AT90USBKey that I had already used for another project.  I also connected buttons (for setting the keyboard into DFU mode) and a JTAG connector.

I very carefully cut holes in the case for the buttons and the various connectors, and actually had to excavate a portion of the tray so that the demo board would sit low enough to not be pressed on by the keyboard.  Here are some pictures of the results:




Here is a picture from the side showing one of the DFU buttons:



This is Atmel's JTAG ICE MkII, which I use for firmware debugging and flashing the MCU.



Here is a side view showing the USB mini-B connector, the JTAG connector and the other DFU button (sorry for the blur):



To actually connect the JTAG ICE, the hole in the case would have been too big.  So I made a little extension adaptor:



Here's a sequence showing how it all goes together:

[lowpoly]

Very, very nice.

Did you start on the programming? Does it work?

My next project - should I ever start with it - would require a micro controller like this as my current 3rd party controller only supports one (meta-)function key.

[dmw]

Does it work?

I've actually gotten quite far with the programming.  I've got it fully functional under the big three OSs (Mac, Linux, Windows).  Ghost-key blocking is implemented.  Multi-key macros work, with modifiers.  I've recently changed from using Atmel's proprietary USB libraries to the open-source MyUSB, but now it's only recognized on the Mac.  I've still some debugging work to do there.

My big goal with the firmware is to make it fully programmable.  There are many relationships in the current firmware that are hard-coded that need to be made dynamic so that they can be specified by an external programming utility.  Right now, it is technically fully programmable, but only by recompiling and replacing the entire firmware.

[lowpoly]

Ghost-key blocking is implemented. Multi-key macros work, with modifiers.

Could you provide some details on these two points?

[philodox]

Right now, it is technically fully programmable, but only by recompiling and replacing the entire firmware.

That might be good enough... just make a utility to choose all the options and 'flash your keyboard'.

[fakstory]

do you have somes code to hack the keyboard typeMatrix?

[lowpoly]

Looks like the OP is gone.

[dmw]

Not gone, just hibernating.  Things got a bit hectic for me right after joining.  

lopoly:  are you still interested in details about ghost-key blocking and multi-key macros?

fakstory:  are you looking for the source code to my project?  If so, you'll have to wait a bit.  I plan to release it when I'm closer to where I want to be with it.

[lowpoly]

lopoly:  are you still interested in details about ghost-key blocking and multi-key macros?

Yes, I am.

Welcome back.

[dmw]

Thanks!

On a membrane switch keyboard, it's possible that certain combinations of keys will produce extraneous key presses.  Basically, the pressed keys complete not only their own circuits, but inadvertently also complete the circuit for keys not pressed.  The keyboard firmware must be able to recognize when this will occur and suppress output of key presses when in this state.  My firmware does this.  This problem does not occur with keyboards having discrete switches that also have appropriate diodes connected with each switch.

It is also possible with my firmware to set any key to produce any combination of key presses, including modifier keys like control, shift, etc.  These can be a single set of key presses (e.g. ctrl+alt+delete) or a whole sequence of key presses (e.g. win+r, http://geekhack.org, return).  The size and number of macros is limited only by the amount of flash on the mcu.

Is this the sort of info you were looking for?

[lowpoly]

How do you filter the ghost keys and distinguish these from intentionally pressed key combinations?

[dmw]

It's pretty simple actually.  While scanning the keyboard matrix, if two or more keys are pressed in a single row, then we check all other rows to see if they have keys pressed in the same columns.  If this state is detected, the firmware returns an error packet.

For example, if row 1 has columns 3 and 5 active, and row 4 also has column 3 active, row 4 column 5 will erroneously appear to be active, so the keyboard is put into an error state until the keys are released.

Dave Dribin's Keyboard Matrix Help page describes the ghost key situation pretty well.

It's a challenge to design a keyboard membrane that minimizes these ghost keys for common key combinations.

[keyb_gr]

It's a challenge to design a keyboard membrane that minimizes these ghost keys for common key combinations.

Here's the one for a Model M, for example. (The 102nd key for ISO layouts seems to be on column a4 according to personal testing, possibly at a4-b8.)

[dmw]

That's a good example.  If you look at the matrix on that page, you'll see that with the exception of right control and right shift, all modifier keys are on unique rows and columns.  Since these keys are more likely than others to be used in combination in regular use, they must be placed this way to avoid the ghost-key problem.

[lowpoly]

It's pretty simple actually.  While scanning the keyboard matrix, if two or more keys are pressed in a single row, then we check all other rows to see if they have keys pressed in the same columns.  If this state is detected, the firmware returns an error packet.

For example, if row 1 has columns 3 and 5 active, and row 4 also has column 3 active, row 4 column 5 will erroneously appear to be active, so the keyboard is put into an error state until the keys are released.

Dave Dribin's Keyboard Matrix Help page describes the ghost key situation pretty well.

It's a challenge to design a keyboard membrane that minimizes these ghost keys for common key combinations.

Thanks.

So if I understand this correctly, you just don't forward any keypresses to the bus when a ghosting situation might occur?

As for matrix design, modern Cherry boards use even more connections to the controller than the traditional 8+16.

[dmw]

So if I understand this correctly, you just don't forward any keypresses to the bus when a ghosting situation might occur?

Technically true but not precisely. While the firmware doesn't forward any key presses to the host when in this state, it does send a packet to the host with all six possible key slots filled in with the code for ERRORROLLOVER. And it doesn't do this when the condition might occur, but rather when it would occur.  While in this error state, the host still considers to be pressed those keys that were down prior to the error state. And when enough of the keys that caused the error state are released, a normal packet with the current keyboard state is sent to the host, from which the host can determine if any keys have been pressed or released.
 

As for matrix design, modern Cherry boards use even more connections to the controller than the traditional 8+16.

Yeah, a larger matrix would result in fewer conflicts.

[lowpoly]

Thanks for clarifying.

[pmyshkin]

Yeah, a larger matrix would result in fewer conflicts.

So there must be a trade-off between using more diodes and using more wires, right? Otherwise why would anyone bother with diodes for NKRO?

[lowpoly]

For full NKRO without diodes you would need a 1x104 matrix (I think?). I suspect that would require an unusual controller chip. If possible at all. Using diodes and a standard controller is probably cheaper and easier.

[talis]

For full NKRO without diodes you would need a 1x104 matrix (I think?). I suspect that would require an unusual controller chip. If possible at all. Using diodes and a standard controller is probably cheaper and easier.

You could probably do a hybrid method similar to this with no diodes, put the less used keys on a matrix (F 1-12, prtsc, scrlk etc) and each of the alphanumeric + modifiers on their own lines using a modern micro controller as the controller.   That would probably add about $3-$4USD per unit to the production cost.

For mass production tho, most small signal diodes cost around $0.01 or less, meaning you can do the whole board for ~$1USD.

[dmw]

Unless it's my Kinesis Keypad.  Diodes under each key but somehow it's still  only 2 key rollover.  The engineer must have forgotten a step.

Wow, that's lame.  Sounds like good hardware with crappy firmware.

[dmw]

Hey lowpoly,

At the start of this thread, you mentioned a possible future project with an MCU.  Care to share what you had in mind?

[lowpoly]

I think it was a Model M based mini (alpha only) with NEO layout. The way things have developed it's not going to happen for some time. If ever.

Could be that the controller in my current mini project might be micro controller based after all. If the USB hub, ps/2 to usb converter and kbd controller were done separately it would require more parts than neccessary. At least that's what I've been told.

[talis]

Welcome to Geekhack!

Unless it's my Kinesis Keypad.  Diodes under each key but somehow it's still  only 2 key rollover.  The engineer must have forgotten a step.

Thank you.


I know its off topic, but they're probably playing some tricks to reduce the matrix size.  You could potentially scan 21(24) keys with a 3x4 matrix (rather then needing the 5x5 or 6x4 you'd otherwise need) if you use a diode on each switch.  You just have to give up anything but 2KRO to do it.  

Either that, or person who designed the key matrix forgot to tell the person who designed the controller what they were doing.

[lowpoly]

How would that 3x4 matrix work, with reversed polarity?

[talis]

I think something like this should work :



I haven't thought it through fully, so there may be some weird conditions, but you should be able to scan once, then swap the row/cols and scan again.

You'd get into a strange state if 2 keys are held down in the same row with oppositely polarized diodes, which may explain the 2KRO.