[quantalume▼]

Caps switch? That's one use for it, I suppose. Finally a sensible place to put caps lock.

I think this switch forced the display into all-caps mode, if I recall correctly. I already have plans to replace the caps lock key with a Ctrl from one of my XTs. Tom's firmware doesn't support macros yet, so I can't do the double shift trick like we can with Soarer's.

[xwhatsit▼]

That's such a nice board. Jealous. Would swap my PC-AT for it in a heartbeat!

Some points about it—I've been talking with poxeclipse on GH about his:

• It has a solenoid. Sweet! Makes sense, as it was there to replace a beamspring keyboard like-for-like
• The ribbon pinout is different. I've designed an adaptor board (you can see it on the first page) that will attach to the controller with a right-angle pin header
• The controller is a massive old-school beamspring-style thing, so the mounting holes are completely different and won't match the Model-F-USB controller, but it would be easy enough with some double-sided foam tape or you could make some mounting brackets easily enough.
• That lovely blue switch is, unfortunately, mounted to the controller directly. To use it, you'd have to desolder it and figure out some way to mount it in-place.

There would be no problem adding some code to make the switch do something. You'd need to do a bit of wiring so you could use the solenoid driver at the same time as the switch; no issue there, the solenoid driver uses two GPIO, and there's four GPIO available on the 6-pin header—so you just need to split the ribbon cable into a Y.

The three examples of original controllers for these I've seen photos of are fascinating. Two are the same, one is a bit of a rationalisation. In the first two, there are numerous hacky-looking air wires and even a diode or two soldered on between pins on the controller. These mods are clearly IBM-original. The boards must have been very low volume for IBM to bother with this kind of rework and not just issue a new controller with the fixes integrated (as the third controller appears to be).

[quantalume▼]

• It has a solenoid. Sweet! Makes sense, as it was there to replace a beamspring keyboard like-for-like
• The ribbon pinout is different. I've designed an adaptor board (you can see it on the first page) that will attach to the controller with a right-angle pin header
• That lovely blue switch is, unfortunately, mounted to the controller directly. To use it, you'd have to desolder it and figure out some way to mount it in-place.

Interesting. Is that the only Model F with a solenoid?

Regarding the switch, maybe I could layout a board that incorporates your capsense controller, the 3178 adapter and the switch.

Edit: Wow, thanks for those pics! Never thought I'd see yellow wires in an IBM product.

[xwhatsit▼]

I don't know of any others; there were variations on this particular board (sans numpad for instance, but same case), presumably to match the `typewriter'/`keypunch' etc. versions of the beamsprings they were replacing. Wouldn't be surprised if there was some other completely different Model F out there with a solenoid though! IBM seems to have all kinds of weird and wonderful stuff that somehow remains hidden for years (c.f. Kishsaver).

Yes, that would be a pretty tidy way to do it, make it so it can screw into the screwholes as well. I don't have dimensions otherwise I'd do it myself. Will be a pretty large/expensive board though to reach both sets of screwholes. If you do end up with extras from OSH Park poxeclipse might be keen!

The reason why I'm certain it's an IBM hack-job (although maybe it was a field mod?) is because here's photos of another controller with the same mods:
http://geekhack.org/index.php?topic=504 ... msg1148666

[webwit▼]

I might swap you one for a couple of your controllers.

[xwhatsit▼]

[mbodrov▼]

xwhatsit, do you think your controller can be made capable of driving the IBM RT PC capacitive keyboard as well? (http://deskthority.net/photos-videos-f8/ibm-rt-e57888-t4101.html) With the peculiar 3-trace capacitive pad design.

[xwhatsit▼]

Wow what a neat board! Have never heard of such a thing.

In theory, yes. They're still wee capacitors that change in value when a key is pressed, and arranged in a row/column matrix. The main problem will be connecting up the rows and columns appropriately (boring stuff like dealing with the fact it's not a 30-pin ribbon cable).

I'd be keen to give it a go though. If you have one and own a multimeter then why not!

EDIT: I see what you're talking about with the three-trace thing—you mean how each pad is split in half but, unlike IBM, has a trace going to each side. I'm not sure why this is necessary; as I can't see the other side of the PCB in those photos, it may be that that is simply the row and column connection to each side, and the underside of the PCB is the passive plate (unlike IBM, which has the top and bottom as rows and columns, and passive plate is on the top as one half of the split plate). The only way to tell would be to get more photos and do some probing.

[Muirium▼]

Intriguing board! I'm with HaaTa, looks so similar to Topre that the same designer must have been at work. Anyone ever selling those will have plenty of interest from both IBM and Topre fans!

I didn't realise there was anything more complex to IBM capsense than two pads: one side columns, one side rows. What's this about half pads and passive plates? (So not an engineer!)

[xwhatsit▼]

If you look at the IBM matrices, they have this on the top for the rows (although sometimes alternating rows between columns instead of what I show here):

Code: Select all

---+---------------------+------------------
   |                     |
   |    +---+  +---+     |    +---+  +---+
   |    |   |  |   |     |    |   |  |   |
   +----|   |  |   |     +----|   |  |   |
        |   |  |   |          |   |  |   |
        +---+  +---+          +---+  +---+


...and this on the bottom for the columns:

Code: Select all

                |                     |
                |                     |
               +---+                 +---+
               |   |                 |   |
               |   |                 |   |
               |   |                 |   |
               +---+                 +---+
                |                     |
                |                     |   


The column is driven with a pulse, which goes into the rectangle on the bottom. That is pulse is reflected in the right-hand rectangle on the top which is directly above—which importantly is not connected to anything! This is then reflected into the actual plate attached to the keyswitch above, then across and back down to the *left-hand* rectangle, which is actually connected to the row with a trace. We then pick up the result on that row.

So there's actually three capacitors in play here. There's the bottom-column-to-top-RHS cap, then there's the top-RHS-to-key cap, then there's the key-to-top-LHS cap. The two caps on the top (the ones that involve the keyswitch) are the ones that change in value when the key moves.

This is from IBM's patent (4,274,752 if you want to look it up), it shows the three caps quite clearly:

[Muirium▼]

Crikey! What'd they go and do all that for? I expect there's either some sound engineering explanation for the passive plate, or a bit of trial and error was involved and this was what worked best in the lab.

[xwhatsit▼]

It's not passive per se. I called it that because it's not hooked up to anything, but it's still hooked up, just capacitively (capacitively coupled I think is the word). I can't quite figure it out; at first I thought they would do it because it gives you *two* capacitors which are being affected by the key, so you get more change when the key moves. However, those capacitors are in series, which halves the capacitance, which would negate that.

I think the reason is that if you simply stacked them up one over each other (removing the third unattached plate), you would have three plates like this:

Code: Select all

__________________________
KEYPLATE KEYPLATE KEYPLATE
__________________________
            |
          -----
          -----
            |
___________________________
TOP ROW TOP ROW TOP ROW TOP
___________________________
PCB PCB PC  | B PCB PCB PCB
PCB PCB P ----- PCB PCB PCB
PCB PCB P ----- PCB PCB PCB
PCB PCB PCB | B PCB PCB PCB
___________________________
BOTTOM COL BOTTOM COL BOTTO
___________________________


So you have two capacitors now, no problem. Except, the top capacitor is varying in value, as the keyswitch is moving. However, very importantly, you only have the bottom capacitor wired up. So you won't see a change in value, making it useless.

That's my theory anyway.

[quantalume▼]

It's 1 June today. Is it time to make up our minds and finalize the orders? I'm still debating whether or not to layout a board for the 3178. I could make another board just for the switch here at home using toner transfer, a resist pen or my CNC router.

[quantalume▼]

Also, I was thinking how nice macro capability would be. I know it's on your list and that you are thinking of using the same file format as Soarer. Have you contacted him to see if he would share part of his code? Just the file parser/assembler would be a giant help.

Edit: Thinking about this some more, maybe Soarer could just reveal to you the format of the assembled binary files, and you could read them in with your utility. That way you wouldn't need to write an assembler. There are a few considerations, like how he forces a default base layer whereas you have a fully-configurable base layer.

[xwhatsit▼]

Yep June 1st yesterday, so my job this afternoon is to start sending out confirmations/final bills to everyone. I'll update the first post to match.

Macros are definitely working their way to the top of my to-do list. I think the parsing/assembling side of it should be pretty trivial, as if you look at the language structure (I took a peek at his very well put-together documentation), the language is basically the executed bytecode, or at least how I'd implement the execution. The reason why I decided to follow a similar macro language to him as that a) it's very easy to implement because of the closeness to the execution, and b) people are very familiar with it and happy to use it, despite being pretty low-level.

I think I'd forego the separate assembler binary, and integrate something into my main GUI util (have a code window somewhere that allows you to type what you want). That way the existing import/export system still encompasses the entire keyboard setting.

The main difficulties lie around making the GUI not look like crap, and partcularly the actual implementation within the keyboard code, as RAM is rapidly running out, and I don't want to impact performance overly. There is still a good chunk of EEPROM left, and on the AVRs reading EEPROM is relatively fast (a few cycles per byte), so I think playing the macros directly off EEPROM is probably the way to go.

A lot of the keyboard scanning is actually sleeps/delays, waiting for analogue stuff to happen. I've toyed with the idea of shifting to an interrupt-based/event-driven scanning approach, where I can do all of the fancy stuff like assembling NKRO USB reports, layers, macros etc. as fast as possible during sleeps while the keyboard scanning handles itself. If scan-rate drops too low (I think 300Hz would be ``too slow'' as now we're down to original IBM rates) then I'd shift to that method.

[Muirium▼]

Excellent stuff.

The GUI is perfectly workable, as it is, and already a good leap ahead of Soarer for newbs. Putting macros in there is the right way to go, too. Sure, it could look fancier, but the functionality is sound and it's easy to learn on first sight. (With a few gotchas about keyboard focus that I banged on about when I met them! Now mostly resolved.)

Here's an idea. This project covers a limited array of physical layouts. There are only so many beam springs and Model Fs. Can the controller itself recognise what keyboard model it's inside? If not, no matter, the user can select from a list. Then, instead of just a bare matrix view (which I'd keep anyway for initial definitions and diagnostics) we could present a graphic of the actual physical layout they see in keys before them, and put the mapping and macro commands in there. It'd certainly look nice, if it worked!

So instead of this:



Something more like this:

[xwhatsit▼]

That would be very handy, but it's actually the vast number of layouts that stopped me from implementing something like that initially. The beamsprings come in all sorts of shapes and sizes, and the Model Fs are relatively varied as well. There is unfortunately no way to auto-detect what sort of keyboard is underneath.

The main problem is that the actual key layout sometimes bears no resemblance to the underlying matrix, even on boards that look like they have a similar layout.

That said, it would be doable with a bit of sweat. Perhaps an idea would be to make the layout user-customisable so they can associate matrix nodes with key placement themselves?

I'll tackle the macros first then have a look at a nice way to handle this when I get a chance. I can definitely see the utility of it, especially after dealing with remaps across the 122-key Model F terminal

[xwhatsit▼]

Oh—I've updated the first post with details about the June 1st batch order:

June 1st order has closed, order confirmations have been sent out and I'm now waiting to get confirmations back from everybody before I place the orders for PCBs and parts.

Once I place the order, the PCBs will probably take the longest to get back, even with expedited shipping. I am allowing 2–3 weeks before everything arrives, although hopefully will be sooner.

Once I start assembling I will keep this thread up-to-date with progress photos etc.

If you were interested, there are a total of 39 different boards that have been ordered (including Solenoid Drivers and 3178 adaptors etc.). Looks like my tweezers and solder-paste-syringe muscles are going to get a workout

[quantalume▼]

If you were interested, there are a total of 39 different boards that have been ordered (including Solenoid Drivers and 3178 adaptors etc.). Looks like my tweezers and solder-paste-syringe muscles are going to get a workout

You can send my 3178 adapter unassembled if it makes things any easier on you.

[xwhatsit▼]

Ha!

Actually it's all the 30-pin (well, 60 pins for the beamspring edge connectors really!) through-hole stuff that is the real pain. I have a reflow setup at home... time to build a wave-soldering machine? Sounds dangerous and fun

[xwhatsit▼]

Have ordered PCBs (rather a lot of them, because of minimums, 48 in all!), now OSH Park is assigning them to panels. Looks like all of these orders will be assigned to the June 5th panel, so should be a reasonably quick turnaround.

[xwhatsit▼]

The PCBs are at the fab and OSH Park expects to get them back on June 15th. Then they're in the mail to NZ. Meanwhile, all the parts are ordered and mostly in the mail, apart from a few things that were out of stock and had to be sourced overseas. I was also short a few connectors, but a very helpful Deskthority member is helping me out in that regard! At this stage it still looks like the PCBs will get here last.

[Muirium▼]

Feature request for the Kishsaver's beeper: beep on calibration, instead of every key press. Or even better: beep on (a configurable?) rollover, rather than general keystrokes.

As you might have guessed, I've been fighting with earthing, and so I'm looking to turn the beeper into a better diagnostic tool. There's something about the way I have my unsecured prototype PCB mounted in the Kishsaver's slender depth that messes up my attempts to ground it properly. Including even this:

I now have two such cables installed, after that one there alone was still not enough. This time I flipped it around so there's less fighting with the main USB cable when the case is closed. Bearing in mind how small the Kishsaver is, the Z axis matters:

Whenever the controller isn't well and truly earthed, it senses a right old monsoon of false positive keystrokes, making for a lot of fun, and beeping, if I haven't muted it. Much to my frustration, it'll do this after a few days of good behaviour. So I'm iterating my way toward a good solution, while listening to beeps all along the way!

The beeper definitely has potential as a feedback system quite aside from its original purpose. When the controller does go ape, it mashes a lot of keys, so beeping on that specifically would be great for watching out on dodgy ground.

Anyway, I doubt this will be a widespread problem, beyond my one and only Kishsaver. They're tight little boards (very slender profile compared to other Model Fs) but the production version of the controller has the right mounts to get the job done without a jump.

[xwhatsit▼]

That's odd that you aren't getting a good electrical connection with that setup. One potential cause might be that the ring terminal is much larger than the exposed copper on the screwhole; as the gold ENIG finish on the copper is perfectly level, it may be that the surrounding soldermask and you're not getting a perfect air-tight seal that cold-welds like a screw terminal or whatever. The ring terminal then might be oxidising (I don't know what the plating is on your ring terminals is).

What I'd suggest doing is building up a layer of solder on the screwhole footprint on the controller, much like IBM did with their original controllers (see below). It doesn't need to be quite as thick and lumpy as what IBM did, but enough so that the ring terminal contacts it first and when you tighten the nut on the other side you get a nice air-tight cold-weld.

This will be slightly tricky—you'll need to leave your soldering iron against the pad for a long time to get a good joint—because I haven't put any thermal relief on that pad, and it's connected directly to the ground plane. So you'll find the whole controller PCB will heat up and get pretty warm before the solder starts to flow nicely. There's no problem with that, but you might find you're holding the soldering iron to the pad for 30s or so (depending on how grunty your iron is). This is perhaps what was causing your hand-soldered wires to come loose in the first place.

I regret not sending you a pre-made grounding strap with the board, sorry about that. I've got some nice industrial screw terminals I use for things like 400V 3-phase drives and I've found them to be pretty good on the beamspring boards. I'll be sure to include these with the Rev2 boards intended to be used with 3178s, as they will need to be grounded manually like this too.

EDIT: in your second picture, is the keyboard-end of the grounding strap fully tightened against the steel mount? It looks like the screw isn't tightened all the way up, but it could just be an unusual shoulder-bolt style of screw.

[Muirium▼]

Yeah, it's just an unusual screw. I dug into my miscellaneous drawer, because IBM's originals had an annoying hex head that I don't have quite the right tool to tighten conveniently.

What I did today was add a second cable, much like that one, to the other end of the controller. This time it is in fact pressed against solder — the same mess that I originally stuck a bare wire onto — and I bolted it up pretty good. I'll need a week or so to know if it's holding properly, given past experience!

[JBert▼]

I hope it works for you, but if it doesn't you could in theory add a star washer:

However, while posting it hit me that you might prefer a plain washer, it looks like this one might eat into the copper. A plain washer should match the exact size of the copper of course, otherwise you would still get the same problem.

[Muirium▼]

I do have a few (rather mungy) of those star washers of various sizes. If and when I have to go in there again, I'll give them a shot. The washers I'm using now are likely all too big, because I didn't understand the "cold weld" concept while I installed them!

[mougrim▼]

Wow. You've done great job. Sadly I missed it It's the easiest USB conversion for AT board I saw. Basically plug and play...

[xwhatsit▼]

Most of the components have arrived here in NZ, and OSHPark have sent me a million emails with shipping notifications a couple of days early Will be baking time soon!

[xwhatsit▼]

Wow. You've done great job. Sadly I missed it It's the easiest USB conversion for AT board I saw. Basically plug and play...

Cheers—I don't know about plug and play though; that's the case for the beamsprings, but for the Model Fs there's that mungy ribbon cable to desolder and resolder. I think Soarer's still got full marks there