internal thinkpad keyboard/trackpoint interface (Page 1 of 2)

The arduino libraries actually give you the ability to send the proper keystrokes - it is just not using the default interface.  The speed issues looked to be more specific to the particular implementation that was done, I could see a couple of ways that it looked like it could be speeded up (all theoretical, I didnt build that hardware to test it).

The specific layout of the matrix also appears not to have had major changes over the years, but there are always the regional layout variations and the small shuffling of keys between each model, so some tool for the changing of the matrix would be good.  I've actually got the matrix layout for the qwerty x220 and x230 keyboards - you can often extract this table from the firmware upgrade files.

I'm slowly trying to source some connectors, after which I will probably be building a quick and dirty adaptor (parhaps to an arduino, like you suggest) - while we have the connector pin out, I'm considering the exact pin functions are still only assumptions until I have actually seen it work.

For many years, the thinkpad keyboard has been arranged as a 16x8 matrix, so that is the minimum number of IO lines requred on your microcontroller for a working keyboard - The trackpoint adds another 3, the Fn and Power switch another two and the various LEDs add another 4, so to have every feature of the keyboard working, it will needs 35 IO lines.

I've got a bunch of ideas for circuit and hardware design, but so far they are still ideas...

PS. all that being said, the very first thing I did was purchase a lenovo external USB keyboard (part 55Y9003, lenovo Australia appears to have stock but not the US store) - tinkering with building my own is more of a long-term plan

Hi, I have done some work on this area before (disclosure: I wrote the instructables and github code you posted) and I think I should share some experience I've had with it.

So the hard part of this project is to get the receptacle that connects to the keyboard. It's expensive since they are proprietary and requires buying in bulk. Not all alibaba carries around this receptacle. They all say that they do but it's all lies. It took me several months to track down a few suppliers, which I don't think I have their contacts details anymore since it's been 2 years since I had dealing with them. If you guys are making a group effort, I'd recommend going through official JAE distributors. Or if you're game enough, you can use solid copper wires/magnetic wires with diameter of more than 30awg and solder them directly onto the keyboard connector - use a very fine tip and as low temperature as possible.

After getting the receptacle is to dig out the schematics for your keyboard connector. Have fun digging.

Using the Arduino Leonardo/Micro has has the disadvantage of having to use external I/O expanders as they do not have the required number of pins for interfacing with the keyboard: 16 rows + 8 cols + 3 trackpoint + 1 FN = 28. The reason why the Arduino implementation is slow is, I think, because of the expanders. If you're pursuing this, I recommend learning to program a USB supported microcontroller, either 8-bit or 32-bit. The 16-bit realm is very expensive for some reason. I personally use MSP430 because I've had experience with the chips before I started the project. I'd recommend reserving the UART pins for UART if you want to later expand the board to support interfacing with Bluetooth as well.

Microchip PIC18 would also work well, they are cheap, available in DIP packages and fairly straight forward to program. They don't have as many internal pull-up resistors however, so there would be a lot more external components.

The TrackPoint uses PS/2 mouse interface. Look up TrackPoint System Specifications version 4.

Once the hardware is sorted, it's all about programming.

I have sold a few USB interface boards for my T60 keyboard as they were leftovers from a successful implementation on Tindie. (forum doesn't allow more than 1 link so you'd have to search it up)

I'm slowly working on a Bluetooth implementation at the moment. It's not much different from the USB but since they are powered from a battery, the code and board would have to be optimized for low power consumption. Everything that I've had so far on this project is summarized here:
https://flashandrc.wordpress.com/catego … -keyboard/

Have fun with your crowd-sourcing. (The forum doesn't allow more than 1 links so I remove all the url tags)

Here is the link to my project log about the foldable Palm Keyboard, which uses the z-axis conductive tape for connecting the ribbon wire to the PCB. If we could do something simmilar with the thinkpad keyboards, it would spare the whole expensive connector part..:
http://hackaday.io/project/3839-convert … ard-to-usb

Do you know, if there is an usable component of the connector in any layout programm?
Perhaps it could be possible to fit the connector on the mentioned board for the Palm foldable keyboard (see my hackaday.io project link above).
This way we could do an universal PCB which works with the palm keyboards and (most) of the thinkpad keyboards. Only difference would be the software needed to load on it.

I just digged hardware stuff and happen to own a new spare keyboard from the 600 series. I'll exchange that with the very worn one on my 600 and will look into the idea to connect it without a connector (using the z-axes conductive double sided tape from 3M).

@rampadc:
do you have 1or 2 of the connectors with receptacle you could spare to help us? Or at least the exact name/discription of it?

I thought more of that is a supprisingly low price. I would even thing about a lot of 500 pcs and ask for the possibility to get 1-3 sample parts for verification.

Oh i wasn't clear enough. What I ment was a board which holds both connectors, from which only one is used (because they use mostly the same pins) and have the fitting software to drive any keyboard that is connected. Could even raise several additional use cases, if planned a bit sofisticated. (e.g. place holes for adding standard head pins...).

I'm willing to jump in here. If we think about making a good board that will work with a lot of thinkpads keyboards and will convert the Palm ones, I could think that 500 people may be interested.

yes thats the basic idea. Mayby planing the debugging part as some "easy to break of" in case the board gets to big to fit in the plam keyboard otherwise.

I just removed the original PCB from the Palm Keyboard and hope to get the components removed till the weekend. Then I'll look for ways to digitize it for further use. There was a hint in the hackaday forum, which not compleetly understand:
http://forums.hackaday.com/viewtopic.ph … p;start=20
The post from Osgeld. But I don't understand exactly how to keep the scale with this method. And perhaps don't have a scanner with high enough resolution...

The palm keyboard has a 12x8 Matrix, so 20 pins needed, which is exactly the amount an atmega32u4 used on arduinos is using.
The thinkpad keyboards will need more (about 35 according to hamish), so I'm back to quare one with the idea of making a"hybrid board" for both use cases. Basicly because I have very limited skills in circuit design, but copying the arduino nano schematics and adapt it to my little board will work.
So far I didn't found any arduino with a mc that has USB internal and 35+ I/O lines...
Your opinions to that?
Use another mc for the hybrid board idea or just make 2 boards?

Using two chips looks like an annoying answer - it adds effort to the code complexity, the cost and the build.  However, If you were going to use two chips, one option that looked good is to use an actual keyboard controller chip - I found the TI tca8424 (at £1.60 for qty 1) which is a I2C connected keyboard controller for embedded keyboards - it even generates the data in basically the same format as needed for the USB (it is a HID over I2C chip).  It doesnt handle the fancy way the "Fn" key is controlled on the thinkpad keyboards,  but everything else should just work.

I've been looking at non Atmel chips for this - looking mostly at various ARM cortex m0 chips - after a fair whack of research on the currently available micros, I've decided to try using the efm32zg222.  Which unfortunately doesnt quite have enough IO lines for the simplest design, but I expect to be able to work around that once I have a better idea of exactly how the keyboard is wired up (I can probably multiplex some of the LEDs together, but I need to be sure)

I have a dev kit for the ef32zg222 and it appears to work as advertised.  It is a low-power, low-price (~£1 each in low quantities) microcontroller which has an open source software-USB stack available.

I'm still arranging to get some keyboard connectors - which will allow me to build a rats-nest test rig to keep working at the keyboard reverse engineering.

I did a quick schematic design for this once I selected the parts, and nothing jumped out at me as being too strange (if you are interested http://www.zot.org/~hamish/hw/keyboard.pdf )  I have not started any PCB layout

So, my next steps are - wait for the connectors, then use them to both confirm the keyboard and check PCB layout measurements.

Dont worry, none of that is nonsense!  One big reason why not to use the atmel chips is in the price - the smallest of those four options (the AT90USB646) is ~£6.20, which is quite expensive for what you get.

I'm in two minds about the arduino compatibility:  Ultimately, it is a crutch that can make more advanced/efficient code difficult to achive - and can limit the hardware choices.  However, it can also make it easier for someone to start something new from scratch - I dont know how many people will be interested in using a keyboard interface as a "start from scratch" project, so I dont know if that gives much value.

I dont see why we should not at least try to make one PCB that would work for multiple different keyboards.  Once we start laying out the PCB, it should be pretty quick to see if all the parts will fit inside the mounting limitations.  Using some kind of daughter-board is just another way to make it more complex and hard to build.  It might end up just as simple to just have two circuit boards - one for each specific mounting point layoug.

I still expect to have make one board (at least) that is not size optimised and would not have all the right mounting points - just to give myself enough room for testing and debuging - so this is probably a problem that can be sorted out in time.  In fact, having a couple of revisions at the board make it simpler to itterate over ensuring the mechanical constraints are right.

The connection to the keyboard is done by 3M doule-sided tape, which is conductive ony in z-axis. The flat-flex wires from the keyboard matrix sits dirctly on top. (think of is as glued instead of soldered).
Problem with shortening the pad is, that the housing holds the wires down on the end that sticks the most inside the board. It is possible to shorten the pads (and the wires accordenly), but could result in connectin problems (I think that's the reapon the soldered teensy variant failed partly).

To the Atmel/adruino/uC stuff I'm as devided as you. But if we keep it to keyboards and make the changing of the code easy for differen matrices of keyboards, I'm fine with non-arduino, too (more importent to me is CC and GNU licence).

To the board space: The backside is still an option. I could think of placing the uC there and have some of the inner layers to route (even the original board is at least 4 layers).  Backdraw is, that ther need to be cut an hole in the case, but it's easy enough to have a little ps- file as a cutting stencil done.

As to the QFN package: I won't mind to organize the population done by a professional service, as I did with the senoko boards.

To get started here is my idea: I'll do a prototyping board for the palm keyboard (pads in place and some breakout cable, simply making the matrix easier to access) and we start with your prototyping board. something like a double row of standard headers, where one is for each matrix part (perhaps I should visualize that..)

Anyway I have the dxf file of teh original measurement done.

So you think it's worth trying in the given space? Nice.
I sent you a forum mail with 2 links to the files.

Well, my connectors arrived, so I can now try and build a rats-nest connection to the keyboard.

I also just noticed that the conversation with mclien petered out there, without me actually posting an update - for the record, the TQFP48 package I had in mind doesnt fit in the space he has available. So, I'm going to ignore that for the moment as we think of options.

I've also got most of an open source tool-chain going for the EFM32 microcontroller, with all the compiling and programming being done with standard debian packages (well, openocd needed to be upgraded to the current experimental version to support SWD - but thats still 'standard', right?).  The bit missing is that I still need to work through about a third of the Board-Support package and either remove it or work out its licences.