Author Topic: Capacitive Keyboard Controller for IBM F style boards such as the XT/AT/122...  (Read 4243 times)

0 Members and 1 Guest are viewing this topic.

Offline dfj

  • Thread Starter
  • Posts: 171
  • Location: Canada
  • Visit our irc: #geekhack on Freenode!
I've been messing on and off with the F controller for a while, but this spring I managed to crack a couple of the more irritating problems with the help of some folks here and on the irc.
First version was just a breadboard thang, but I'm currently using a somewhat nicer soldered deal for extended testing, in text and gaming (and yes, typing on it now, of course).

Here are some shots of the prototypes:

[ Guests cannot view attachments ] 25230[/ATTACH] [ Guests cannot view attachments ] 25231[/ATTACH]
[ Guests cannot view attachments ] 25232[/ATTACH] [ Guests cannot view attachments ] 25233[/ATTACH]

This was done using a pair of analog switch arrays to regulate the sense lines in between probes.
With Soarer's encouragement I was able to get a cheaper and slightly safer to solder version working with 16 more diodes instead of the switches.  
This is what I am currently using:
[ Guests cannot view attachments ] 25234[/ATTACH] [ Guests cannot view attachments ] 25235[/ATTACH]
[ Guests cannot view attachments ] 25236[/ATTACH] [ Guests cannot view attachments ] 25237[/ATTACH]
[ Guests cannot view attachments ] 26020[/ATTACH] [ Guests cannot view attachments ] 26021[/ATTACH] [ Guests cannot view attachments ] 26022[/ATTACH]

The normal IBM controller scans the whole keyboard in about 16ms, while this version (and also the analog switch version) are able to reliably scan in about 5ms.
Whether this, or the fact that the board is fully nkro, will actually matter to anyone's ability to game on it - this would be an open question. :)
Personally, I like nkro. Right now I'm just using 'normal' USB so only get 6kro+metas however I have my own version of nkro over USB, similar to Soarer's and Hasu's that I've been using for the last year. This will get mixed in shortly as an option.
This implementation is using a teensy++ based microcontroller board since it needs at least 18 digital io and 8 analog inputs. A regular teensy might be used with the addition of a digital multiplexer, but I don't have any handy to try. This is an option for the future, since the smaller io microcontroller chips could be used bare on a simple board without needing to resort to much nasty SMT soldering.

So - here is a start to the mod-thread, I'm going to try to add more details on how it works (in particular how to scan an F matrix for others working on such code) including a schematic and some more explanatory photos of the thing stripped down.

here is a rough parts list:
1   teensy++ 2.0
18 1n48 fast diodes
8   1M ohm 1/8W resistors
1   0.1 uF catalytic cap (polarized is fine).
1   1 nF ceramic capacitor.
1   47 nF ceramic capacitor. (these ceramic caps are not as critical in the diode implementation).
a short length of IDE 40-line ribbon with 2 female connectors
a short length of 20-line ribbon with 2 female connectors
60+ pins.
22-30 gauge solid wire for the interconnects on the perf-board.
22-24 (ideally 22) gauge stranded wire to replace IBM's delicate ribbon with.
Perf-board - I used a 3x5" and some misc bits, but I'm somewhat confident it will fit on the 2x3" for the main part. How you attach your ribbons is up to you...

Rough Theory:
  The F keyboards are capacitive, when the buckling spring switch is pressed, it splats down a big flat black hammer, rather than the membrane striking hammer of the M. This black plastic hammer is actually conductive resin, so it acts as a plate of a capactior, and when it is actuated and flush against the board a controller can detect a change in capacitance.
  In actuality, when you look at the things on the PCB, you'll notice that there are two plates on top, where the hammer drops, and only one on the bottom. This odd arrangement seems to ameliorate the expected effect of having many other capacitors on the same sense line disrupt the ability to distinguish which ones were up or down during a strobe - in a rough analogy to the 'which three or four keys are down?' problem with contact switch based boards when they block or ghost.

(detailed pics here)

The 8 sense lines on the AT, XT (as we call it here) and 122 F keyboards run lengthwise along the board, as the rows of the matrix. Up to 16 columns (for the 122a) are strobed with 5V, one at a time (while the others are grounded) and the sense lines read to see which, if any, or all of the keys on that column were pressed. This is what IBM does, this is what I do.

[shot of whole matrix goes here]

The Sense:
  Here's where it gets fun. We have strobed a column (driven it from gnd to 5V), and are curious if some switch on that column is down, so we inspect that sense line (row) via reading from one of the ADC lines on our microcontroller.
We keep a small voltage on the sense line, so that we aren't too close to ground that electronics will get weird, but as far away from 5V as we can get away with, so that the strobe feels relatively stronger as a difference from our current voltage. I use about 500mV, the voltage drop of my diodes, while IBM uses about 800mV, which comes from somewhere inside their sense chip - not certain of more than that.  Now when the strobe hits, the sense line will rise by one amount when the key is up and another greater amount when the key is down. Certain keys end up different due to their location and other quasi-mystical effects, but a difference of from 23mV to 50 mV between the normal peak and the peak when pressed is what I tend to see. If I set a threshold at, say 20mV above normal and then whenever the peak is more than that I might have a keystroke, I ought to be able to detect presses. This much is true - but there are many artifacts. :)

  The device is sensitive to random noise - hence it is heavily shielded, above and below. This means that occasional devices nearby turning on, random static, and other EMR noise sources will intermittently cause an errant reading. IBM dealt with this by sensing twice, in their patent - however in their actual code (thanks John Elliott)  one can see that upon detecting a change they compare an entire fresh set of 8 samples to a second fresh set of 8 samples before they accept a state-change. that is, they throw away a first set of 8 samples, only using it as a signal to check for changes but not trusting it at all otherwise, then make 16 more measurements. This catches the vast majority of spurious keystrokes caused by errant noise. I was having noise problems for a bit, so I still have my code doing 3 more tests (also of 8 keys, i.e. all the sense lines) even though that problem has since been sorted out. It is a small fraction of a ms in additional time, that is only incurred on each keystroke, rather than every scan, so I won't unroll it until I'm certain I can get by with only two verifications. I scan three times as fast as IBM, so I am a little more vulnerable to noise.

Evil Keys:
  Some keys are more equal than other... or less equal, perhaps. I'm not dead sure why, but certain keys upon press generate a long-high pulse, sometimes over 100mV, for about 1ms on the sense line. Most keys do not do this. After Opening and repacking a board's hammers - not only will different keys will have the attribute, but also a different number of them. The problem is intermittent, a key doesn't always misbehave. My theories include dust, improper seating of the hammer, vibration induced static accumulation, and a prion disease.
  The keypresses ride that wave, so at first I tried to surf it... oh the madness.

Stabilization of the sense line:
  The 500mV that the sense lines live at when not being poked and probed - it comes from a diode and 10k resistor voltage divider. The diode gives us a constant voltage drop, and as I used the same type of diodes from the same reel, it is pretty consistant from diode to diode. If I just connected the sense line to that junction, however, it would wipe out the tiny signal from the keypress because 10k at 5V lets a fair bit of current through. A bigger resistor helps up to a point, but we need to keep the diode working, so there is a minimum amount of current needed. A big resistor between the sense line and the voltage divider does the trick, though - lets us see the keypresses, but still recover to the offset voltage of 500mV after a bit. Making the resistor smaller allows quicker recovery, but also acts more on our signal to bring it back towards 500mV - i.e. at 1M ohms, the signal looks pretty square, easy to read, but at 10k ohms, it is a steep sawtooth shape, not even reaching the original maximum. Unfortunately the big resistor also allows the evil keypresses above to rise higher and last longer.
  Using 300k resistors, instead of 1M, and adding code to detect and wait out the evil press spikes, I was able to get a working keyboard at 20ms for a full scan, which was sweet, but not as good as the 16ms scans that IBM managed... fine for a replacement of a dead controller, though...

Coming soon: more pics, including some crappy USB scope captures, binaries and source, though haven't decided yet on a license for the source likely gpl 2 or 3, assuming they don't fight with the libs I use.
Fave Switch manus: IBM, Topre, Matias, ...

Offline EverythingIBM

  • Posts: 1269
So this is why you were so quiet.

I didn't know they made twisties in green... thought they were only clear like in ripster's ghetto heatsink.
Keyboards: '86 M, M5-2, M13, SSK, F AT, F XT

Offline kishy

  • Posts: 1576
  • Location: Windsor, ON Canada
  • Eye Bee M
Glad to see this going public finally :)
As with everything, I will be happy to jump on the testing bandwagon.
Enthusiast of springs which buckle noisily: my keyboards
Want to learn about the Kishsaver?

Offline hasu

  • Posts: 2907
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Capacitive Keyboard Controller for IBM F style boards such as the XT/AT/122...
« Reply #3 on: Thu, 01 September 2011, 20:01:31 »
Wow, nice hack!
and looking forward to seeing the detail.

I have a plan to change physical key layout of HHKB though I've not worked anything yet.
My plan uses my own PCB and Atmel QTouch Library with stock Topre actuator(slider, housing, ring).
I have read some articles about capacitive sense but it is still mysterious to me :( So QTouch is a easy way to me.
TMK products:HHKB Alt  ⌨ConvertersAlps64FC660C AltFC980C Alt

Offline Quarzac

  • A very busy dude!
  • Posts: 675
  • Location: Berkeley, CA
  • Still around, sometimes.
Capacitive Keyboard Controller for IBM F style boards such as the XT/AT/122...
« Reply #4 on: Fri, 02 September 2011, 12:05:33 »
After reading this, I'm not totally sure what it is. Could someone enlighten me?
Got a smaller board with white ALPS, Montereys, Cherry Blues, Reds, or Clears you'd like to offload?  Shoot me a PM. Looking for a grey Leopold FC700R in particular.

Wyse buy colors were GSY for the dark grey, GBA for the light grey, and BBI for the fonts.

Offline dfj

  • Thread Starter
  • Posts: 171
  • Location: Canada
  • Visit our irc: #geekhack on Freenode!
Capacitive Keyboard Controller for IBM F style boards such as the XT/AT/122...
« Reply #5 on: Fri, 02 September 2011, 12:58:30 »
The controller of a keyboard is the part that usually contains a microcontroller running a small program that periodically scans the matrix of keys to determine which ones are physically down. For normal keyboards, the keys connect to some sort of physical switch so the controller can read and write (usually 3.3V or 5V) to the edges of the matrix (a grid) to figure out which keys are pressed. In the case of certain keyboards, the grid is capacitive rather than switch based. This means that when you put 5V (or whatever) onto a line on one side of the matrix (suppose column 4), then read the lines off of the other side, (in my case rows 1 to 8) you get a different sort of result. With a normal keyboard, you'd get 5V (say) on whichever rows had a key pressed on column 4 if there were any, and 0V on all of them, if there were not. For a Model F, you instead have a short period of time after you've set the column to 5V in which to read the row(s), before the pulse that was caused by the transition from 0 to five (which can pass through capacitors) vanishes. Furthermore, this pulse is tiny: a 20-50mV pulse that lasts for a few dozens of microseconds. Finally, even if the key is not depressed, a pulse is still seen - it is merely smaller, so one is looking at a change in size.

  In summary, I fancy this is interesting because it allows one to replace the controller on capacitive keyboards, as opposed to switch-based keyboards for which other folks have already released solutions. One might need to replace the controller because 1) your keyboard died - this means the electronic part, i.e. the controller. 2) you want to convert an old/strange keyboard to USB without wanting to reverse engineer the protocol... important because some boards do not include key _releases_ in their protocols, so converting them to a keyboard that supports two shifts, controls, alts and 'windose/apple command/meta' or whatever is not possible without an internal mod. 3) You want to physically add/move/remove keys from a keyboard.
[mental note, copy these justifications up into the file after a hair of editing.]
  This also might let one attempt to make a fully custom capacitive board... though that is a fair bit away from here.

yup, hope taht shed some light.
Fave Switch manus: IBM, Topre, Matias, ...

Offline dfj

  • Thread Starter
  • Posts: 171
  • Location: Canada
  • Visit our irc: #geekhack on Freenode!
Capacitive Keyboard Controller for IBM F style boards such as the XT/AT/122...
« Reply #6 on: Fri, 02 September 2011, 13:21:45 »
Yeah, configuring QTouch looked like a mighty hassle for me - I already hurt my brain getting the LUFA USB framework in and didn't want a second one living right under that, before I even got to the electronics.
  Ultimately one needs to sort out a certain amount of the physical circuitry regardless. The QTouch capsense hardware side will handle much of the line stabilization for you, which is nice - the stuff seemed a bit pricey for hobbyest budgets, but if you are targeting Topres (and where the hell are you getting them?) then the controller will be a small part of the cost, so I can't argue there.

luck, though, and lots of it... I can't wait to find out more about the topre guts.
Fave Switch manus: IBM, Topre, Matias, ...

Offline dfj

  • Thread Starter
  • Posts: 171
  • Location: Canada
  • Visit our irc: #geekhack on Freenode!
Capacitive Keyboard Controller for IBM F style boards such as the XT/AT/122...
« Reply #7 on: Fri, 02 September 2011, 15:16:02 »
Who are you talking to rip, and erm - I'm afraid I don't follow which part of an F key assembly you might be referring to as 'stem'... normally I consider the two arms which hang down around the spring, contained within the cylinder or barrel, and descending from the key to be the 'stem'. If you are talking about the black plate/foot that slaps down onto the pcb where on an M it would be the hammer, then I could clarify that it is a conductive piece of plastic, presumably made from a graphite-laden resin, which acts as the two movable plates within the 5-ish-plate capacitor system of an IBM cap switch.

  Ah - and someone just explained to me: rip measured the resistance of the flyplate at some point and didn't find one...
I _also_ measured the flyplate, and was able to do so more successfully, as I had accidentally broken one, so could touch the rough internal surface with my probe.
probes are pointsy, so make a crappy connection to poor resistors - and the exterior of the flyplate is very smooth, so the contact area is minimal. with a rough surface, or lots of force, the probe tip can make better contact and a large, but still useful, value can be read.
  I'll try to use some conductive goop to attach leads to my remaining bits of flyplate, see if I can get some rough estimates on how conductive the flyplate is...

I'll get back to ya'll sooner or later with some quasi-accurate numbers..
Fave Switch manus: IBM, Topre, Matias, ...