Model F controllers

[Muirium]

Exciting indeed!

The beeper is indeed just a one-trick piezoelectric pony. I presume its purpose was for system feedback, given the simplicity of the little banking terminal it was designed for. Still, if you could treat it to the same logic you use on the solenoids, they can do the same kind of tricks.

Being 12 hours apart, it is of course night now in Scotland. I'll get the camera out again in daylight to take the picture to answer your question about the pins. I can barely read the labels myself in electric light.

[wcass]

if your 6 pin header on the right is a standard 6 pin AVR ISP header and if MOSI is not use for something else ....

sound card header.jpg (168.89 KiB) Viewed 7244 times

[xwhatsit]

Thanks for tracing them through! Wonder what DVR stands for?

Nope it's not an ISP header; the boards use the ATmega32U2, so come from the factory preloaded with a DFU bootloader, so I've never bothered to put an ISP header on them.

The pinout I have is as follows:

Code: Select all

Layout:
2 4 6
1 3 5

1 = Vcc
2 = GPIO
3 = GPIO
4 = GPIO
5 = GPIO
6 = GND

So the problem is the +5V and GND need to be diagonally opposite. I don't want to risk using a GPIO as +5V or GND, as it may suck more current then the GPIO wants to source/sink. So I think a pin swap (move GND to the next row) on the connector is probably the easiest; those pins can normally be popped out of the sockets with a couple of jewellers screwdrivers or similar. Either that or bridge the GND pin on the controllers to the next row.

[wcass]

it could be OVR - not sure. too small to know for sure.

i've never had a problem moving a pin or three. a good picture of where they need to go is all we need.

[xwhatsit]

Well finally managed to find some time to add enough smarts to the software (util and firmware) to handle variable-sized keyboards of different sorts (everything was hard-coded before).

I soldered one up, then attached it to my 122-key terminal.

It works! (This post typed on it as proof )

Pretty well too. There's a couple of tweaks to make, mostly resistor values; the key-capacitors don't drain fast enough after each pulse, I was getting situations where the key in the same column but next row was getting wiped out if both were pressed. I think this is down to a) my key-drain resistor divider being too high-impedence to drain a whole 8 rows as fast as 4 rows were draining, and b) the capacitance of each key is higher in the Model F compared to the beamspring, making it easier to sense. For now, to fix the problem, I've just increased a delay value inside the code to wait between pulsing each column; in the beamspring it was about 10us, for now it's closer to 50us. This means our 650Hz scan rate drops down to about 500Hz. I'll try tweaking the resistor values to see if I can get this back down.

The auto-calibrate part of the firmware needs to be fixed as well, as its logic is backwards for a Model F (pressed keys produce higher voltages than unpressed keys, the reverse of beamsprings).

Here's a picture of a scan (don't worry about the blue line, that's just a single column being strobed):

3.png (3.34 KiB) Viewed 7212 times

You can see the nice big jump when you hold a key down. Very easy to measure.

And some crap pics of it fitted to my 122-key terminal. Apologies for a) the green wires (long ago when I was first playing around with the board I accidentally snapped the brittle single-core ribbon cable) and b) the crap photos from my crap phone.

photo 1.JPG (148.92 KiB) Viewed 7212 times

photo 2.JPG (100.53 KiB) Viewed 7212 times

photo 3.JPG (113.96 KiB) Viewed 7212 times

photo 4.JPG (106.54 KiB) Viewed 7212 times

photo 5.JPG (109.86 KiB) Viewed 7212 times

Looking at those pics now I'm surprised it works with all the crazy green wires everywhere. I suppose the Model F just has high enough thresholds (bigger capacitors) that it's much easier to sense.

[Muirium]

Nice! And beeper header sighted! Wcass is right: this is indeed the pinout:



Arise, Kishsaver, I summon thee!

[wcass]

Great work!

I've heard others curse the old ribbon cables too. It is difficult to find ribbon cable with .156" pitch. I might try to make some by sandwiching solid core between vinyl sheets and running that through a laminator. If it works well, I'll probably do another group give-away. What gauge wire do you think would work best?

I have a couple microUSB sockets comming in the mail. Guess where i plan on putting it.

ks1.jpg (200.45 KiB) Viewed 7142 times

The attachment ks2.jpg is no longer available

[Muirium]

Micro USB sockets? Got a link? I was looking for those literally this afternoon for another project!

And it's not half bad an idea for a Kishy, either…

[Daemon Raccoon]

Ooh, that's a lovely hammered bronze/copper paint job on your Kishsaver, wcass.

[wcass]

Micro USB sockets? Got a link? I was looking for those literally this afternoon for another project!

And it's not half bad an idea for a Kishy, either…

I will use one or the other depending on how each fits (the first sits higher than the 2nd). I'm trying to reduce or eliminate trimming the case. I ordered from Mouser.

http://www.mouser.com/ProductDetail/TE- ... oZwQ%3d%3d

http://www.mouser.com/ProductDetail/FCI ... 8XVWvEtwKs

[Muirium]

Nice! Thanks for the links. Be sure to take some internal and external pictures when you do. I love a removable cable, given how I store my keyboards on shelves.

The other project I mentioned involves aluminium project boxes and protocol converters. I like those to have sockets on both ends, too.

[nourathar]

great work, I'm a groupie and I will build all your converters as they become stable/available !

and I was wondering: would another version of your converter work for Keytronic boards, since that is also capacitive sensing ?

[HaaTa]

For the DPH controller I'm trying to make a general purpose cap sense controller. But likely some extra work will be needed for each new type of cap sense. Likely the same sort of deal with xwhatsit's as well.

There may be some issues though connecting the controller to the board though depending on how large each of the caps are.

[xwhatsit]

Cool, I like sockets. I only avoided sockets on this because I was worried about clearance (the Model Fs are positively modern in packaging clearances compared with the beamsprings!).

nourathar—what, you didn't feel you got enough punishment last time?! On the plus side you will have a healthy stock of nearly all the bits you need

I can't say I've met a Keytronic board, what are they? In theory, yes, as long as it's get ≤16 columns and ≤8 rows. For science!

[HaaTa]

xwhatsit, how are you dealing with un-used strobe lines? Depending on the keyboard (kishsaver), some strobe lines aren't used. Strobing them causes issues at least on the DPH controller.

Right now, I detect whether the strobe is attached to GND then remove the strobe from strobe list.

Edit:
The DPH controller supports up to 18 strobes atm (though more is also doable) and 8 sense lines.

[nourathar]

Not punishment; practice !
so now I need to apply those skills !

[xwhatsit]

Ah interesting. So they're grounded? Good information to know! That would produce a direct short to ground (briefly)

Yes I might need to add another knob to the GUI util to control it. Either that or have multiple hex files/binaries for Kishsavers and everything else—I already do this through the makefile for the beamsprings boards and others (it's all one codebase for me).

[xwhatsit]

For the DPH controller I'm trying to make a general purpose cap sense controller. But likely some extra work will be needed for each new type of cap sense. Likely the same sort of deal with xwhatsit's as well.

There may be some issues though connecting the controller to the board though depending on how large each of the caps are.

Yes you're right, mostly would be around packaging etc. C.f. this Model F board is basically identical to the Beamspring Displaywriter in terms of schematic, except the pinout of the board is quite different and uses an edge connector compared with a ribbon cable.

However, I'm suprised how resilient the controller seems to be to all kinds of horrible crossed wires and spaghetti mess (see my green-wire pictures above). You might be get away with a lot more abuse than I thought. Mightn't be tidy, but anything labelled `general purpose' rarely is.

[HaaTa]

Haha, yeah, there are a bunch of gotcha's for Model F boards (one of the reasons it's taken me so long ).

• Some Model Fs have test points, which are in random places
• Test points look like keys that are being held down at startup (another problem situation)
• Dirty PCBs...this affects capsense ALOT

Let me know if you run into any weird issues (I've probably already seen it ).

My next task is to write a new keymapping file format that supports stuff like layering and macros (combos, sequences). And forward looking stuff like analog switches (going to be working on these soon).

[xwhatsit]

Those are exactly the same things I went through with the beamspring controllers (it's basically the same stuff after all, IBM just changed the mechanics of the keyswitch more or less).

The test points I use for the autocalibration (I assume you do too—I think that's what IBM intended them for); when the user assigns the key layout in the GUI, any leftover nodes on the matrix that don't correspond to keys they assign to either `(PRESSED)' or `(RELEASED)'. After that's done, autocalibration can be used (when setting up a new board you need to play with the Voltage Reference spinbox in the GUI util until the keys look/press right on the matrix monitor).

Here's a pic of what I'm talking about:

util_model_f_122.png (72.31 KiB) Viewed 7076 times

Of course once a few have been done, one can just save the layouts off each board and pre-program it onto each controller so it autocalibrates first time.

Copy you on the dirty PCBs; this has been a pain in the neck with the beamsprings, as the so-called `contamination shield' breaks down and leaves little flakes on the PCB which gives false keypresses etc. I'm surprised my Model F 122-key is working fine, as I reassembled it some years ago with very little attention to cleanliness. I can only assume that that's down to the greater pressed/unpressed threshold (moar capacitance) on the Model Fs w.r.t the beamsprings.

[HaaTa]

One thing to watch out for, not all Model F boards have test points...

Fancy GUI
Yeah, I want an arbitrary number of layers with fallthrough capability (so you can do things like switch Capslock and Ctrl). I support a lot more keyboards, so I also want things like combining keymaps to make a Colemak layout for multiple keyboards (without having to redefine it for each new keyboard I support).

Not sure I'll do EEPROM saving though, might not have enough space for the tables I want to include.

[xwhatsit]

One thing to watch out for, not all Model F boards have test points...

Fancy GUI
Yeah, I want an arbitrary number of layers with fallthrough capability (so you can do things like switch Capslock and Ctrl). I support a lot more keyboards, so I also want things like combining keymaps to make a Colemak layout for multiple keyboards (without having to redefine it for each new keyboard I support).

Not sure I'll do EEPROM saving though, might not have enough space for the tables I want to include.

Boards without `pressed' testpoints (there will always be `low' testpoints I assume, surely there's no board out there which uses every node of the matrix, 12x8 or 16x8 or otherwise) will probably not be able to use autocalibration then I suppose, requiring pushing the override button. No dramas, I find once a board is autocalibrated at startup it doesn't really drift; possibly between different PCs (my laptop doesn't get anywhere near supplying 5V, it's close to the 4.5V limit) things change a bit but not by much (my design is ratiometric; the DAC uses Vcc as its vref).

I've got four layers at the moment (base plus three remaps). With a 16x8 (128 nodes) matrix and 1-byte scancodes, this means half of my ATmega32U2's EEPROM is used on the mappings, and there's a few more bytes here and there for storing the voltage reference, expansion port modes, layer entry conditions etc. I imagine I'll have a healthy amount of EEPROM leftover for macro support once that's added. What else were you thinking of putting in the EEPROM? I assume you have a whole 1K to play with as well.

...

I had a play around over lunch and swapping the 47K/10K resistor divider for key-drain for a 4.7K/1.0K divider, I can boost the scanrate up to 550Hz or so. I might leave it at that; there's no point in going too much higher, as you then start having to increase your number of debouncing scans to compensate. I expect there's a probably a hard cap on both Beamsprings and Model Fs of around 2–3ms per key (so 333–500Hz) for mechanical reasons (yes, capacitive keyboards still need debouncing, there's just less bounce). In any case, after adding NKRO and layers and all the other crap my original 1KHz scanrate on the beamsprings dropped down to around 600Hz; most of the gains could probably come from optimising the rest of the code a bit better, rather than playing with the scanning.

Sorted out the autocalibration as well. Really confused myself with active-low and active-high terminology; the LM339 has open-collector N-channel outputs, so the row inputs to the µC are the opposite of what the keyboard is (Model F→active high, Beamspring→active low) ... d'oh!

Getting used to typing on the Model F, it's nice having so many F-keys and a proper numpad, but still miss the sound and feel of the 3727 Beamspring with the solenoid firing

[quantalume]

Getting used to typing on the Model F, it's nice having so many F-keys and a proper numpad, but still miss the sound and feel of the 3727 Beamspring with the solenoid firing

Hmmm...maybe we can come up with a retrofit solenoid for the F models.

I know what you mean about the F-keys though. I have all of the LHS F-keys set up for editing functions and the entire top row for launching programs. I don't hardly need a mouse, which is a good thing since it is so far away.

[HaaTa]

dfj has found that some boards do drift, probably due to the diodes/voltage refs (temperature).
Our design has a min expected increase threshold vs. the unpressed sense value per key. So far this has worked well for the Model F boards tested (Unsaver, Kishsaver, 50 key, 122).



As for macros.
If I exclude time based macros, there are two types. Sequences and Combos. This is both from the input and output perspective. Arbitrary sequence/combo input is another one, not hard, but requires more memory.

For example, defining:
Ctrl + a; release; b
To result in (but not lose Ctrl+a for normal purposes):
"Mary had a little lamb" + RightShift

Doing arbitrary stuff like that gets a bit lengthy. And while this example isn't useful, demonstrates what I want my keyboard to be able to do in hardware.

For analog stuff I want:
Press a @ 20% => a
Press a @ 80% => A

For things like solenoids I want to be able to define:
Keys a -> z => fire solenoid

Then include layers on top of this.

I think I've figured out most (if not all the) edge cases to make stuff just a bunch of tables which are interpreted by a capability functions.


Model Cs have solenoids iirc.

[xwhatsit]

Ah right; dfj's controller probably drifts due to all of the diodes and stuff like op-amps, which wouldn't be particularly temperature-stable. The capacitance itself changes very little, so the LM339A comparators which I use for thresholding (which have massive gain, being comparators and aren't really subject to temperature drift) keep giving the same results, more or less. The DAC I'm using (DAC101S101) is pretty stable too. The key-drain resistor divider might change a bit, but that's not critical so doesn't really affect things if it did (it already flails about wildly as keys are strobed).

I can see the analogue stuff might be a bit painful to stuff into 1K! Sounds very cool. I was just going to aim for equivalence with Soarer's converter in terms of macros; I'll be very excited to see what you produce!

Model C? Hmm! Relevant to my interests

[xwhatsit]

All right, fresh boards. One for my PC-AT, one to go in the post to Murium for Kishsaver testing. All gone!

photo 1.JPG (275.73 KiB) Viewed 7047 times

Analogue (row sense) end:

photo 2.JPG (303.74 KiB) Viewed 7047 times

µC end:

photo 3.JPG (291.97 KiB) Viewed 7047 times

[xwhatsit]

Now fitted inside my PC-AT (typing on it now, man I need to fix that heavy spacebar, it's ridiculous).

Holy balls, never ever want to desolder/solder one of those ribbon cables again. Need to find a better method for testing these when I start making them for other people. Who ever EVER thought through-hole technology was a good idea?! IBM had already used surface-mount in the 60s (with the Apollo landing guidance computer), why didn't they stick with a good thing!

Melted the ribbon cable a bit, hence the kapton tape (just in case):

IMG_1161.JPG (186.24 KiB) Viewed 7014 times

Close-up showing comparison with old controller, and pin-swapped ribbon cable connector for LEDs (they work by the way; quite amusing to tell the expansion header that it's to operate in "Beamspring Solenoid" mode and watch the Caps-Lock LED blink away for every keypress):

IMG_1162.JPG (268.18 KiB) Viewed 7014 times

Oh yeah and my current desk. All running off USB with ibm-capsense-usb controllers of some description (that's my new name for the project, can't call it "beamspring-usb-5251" anymore—maybe I should set up a combined thread once I hit v1.0). I didn't bring the other beamspring (5251) in from the next room, as my desk is rather full.

IMG_1163.JPG (253.7 KiB) Viewed 7012 times

[woody]

Interesting scratchpad notes you have.

[Muirium]

All the best riddles are written on floppy disk. The curved indent on the active note looks suspiciously like the footprint of a drinking glass!

In any case, have a good one, Xwhatsit. Your controllers look beautiful and I'm right chuffed to be putting one to the Kishsaver test! Cheers!

Now, about that software… (Is this the latest version? Ditto for the graphical utility? I'm on OS X…)

[xwhatsit]

My coaster is actually a proper floppy disk. There's piles of the things at work; down here in the antipodes we only recently got CD-ROMs of course.

The GUI util is still under a bit of development, finished adding the column-skip feature to avoid shorts on things like Kishsavers (my boards unfortunately cannot autodetect which columns are live and dead, as I use serial-to-parallel shift registers for my column drives, instead of GPIO, so I can't set them as inputs with pullups to check). Also need to add the extra stuff (expansion port, column skips) to the import/export file format.

Should be done in the next day or two, then I'll round up a Windows machine and a Mac OS X machine and get the utils compiled for a proper release.

Murium's controller is on its way, hopefully in two or three weeks we'll know if it mounts OK inside a Kishsaver