deskthority

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:

<SNIP>

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:
<SNIP>

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.

Noise:
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.