Author Topic: Beamspring USB  (Read 21059 times)

0 Members and 1 Guest are viewing this topic.

Offline xwhatsit

  • Thread Starter
  • Posts: 297
  • Location: NZ
Beamspring USB
« on: Mon, 24 June 2013, 02:36:11 »
Updated 2013-09-19:

Further updates of the source code (layers etc.) and revisions of the PCB are available at the thread at Deskthority

**************************************************************************************************

Updated 2013-07-02:

Released v0.1 of source and schematics, attached here: * beamspring-usb_0.1.tar.bz2

**************************************************************************************************

Finally managed to spend some time on this, some years after purchasing a couple of beamsprings...

Just a teaser for now, still writing the code (can read individual columns at the moment, the `keyboard' is actually a CDC-ACM serial port right now so I can communicate with it. Automatic calibration for the capacitance threshold is proving a little tricky and I don't want to just hardcode a value that works right now).
« Last Edit: Thu, 19 September 2013, 00:10:33 by xwhatsit »
Beam spring IBM 5251 (7361073/7362149) & IBM 3727 (5641316) | Model F IBM 122-key terminal & IBM PC-AT 84-key | Model M Unicomp 122-key terminal | Cherry MX Blue Leopold Tenkeyless

Offline dfj

  • Posts: 171
  • Location: Canada
  • Visit our irc: #geekhack on libera.chat!
Re: Beamspring USB
« Reply #1 on: Mon, 24 June 2013, 05:01:09 »
Intriguing!
  You are strobing the pcb via the device (in DAC mode?), and then reading it back via the adc?
How fast is it?
How are you offsetting/biasing the sense lines?

Me and Soarer have been intermittently poking at the F boards for a while now, and we have had some success with various prototypes, but (at least I don't) have much ready for general release yet.

Feel free to come bug us anytime (we tend to live on the IRC), but do respond to posts here as well. :)

I'd be glad to share what I've found, though my priority of late has been getting the beasts to scan *faster*, rather than support more devices.
  I still haven't tested on Beam Spring, so what the differences in threshold and direction will do to my code remains to be seen.

looking forward,
best of luck,
dfj
Fave Switch manus: IBM, Topre, Matias, ...

Offline xwhatsit

  • Thread Starter
  • Posts: 297
  • Location: NZ
Re: Beamspring USB
« Reply #2 on: Mon, 24 June 2013, 06:21:03 »
OK got some basic keyboard firmware now, still no autocalibration but getting there. Some false key repeats etc. which shows that the calibration isn't quite right (it seems to drift), but pretty good. Feels weird mashing the keys on a beamspring and having stuff actually appear on-screen :)

dfj: I'm doing it more or less as per the patent, pulsed columns, I=CdV/dt. So no ADC. Just a comparator with a tiny 12-bit DAC setting a threshold voltage. Much faster this way (I was rather concerned about scan time initially). I bias the rows up a little from Gnd, but there's no real need to (LM339 includes Gnd in common mode input range).

Biggest concern right now is the weirdness going on at the far left of the board, threshold voltage seems to want to be different there. Could be to do with the way I'm initialising the column drive lines (they're on shift registers as not enough MCU pins), as for a period they are floating high-Z. I'll get it on the scope at work tomorrow when I get a chance.

I'll post up schematic/layout/source code when I have things a bit more `done' and working. (This last paragraph typed on my fancy new USB beamspring :) )
« Last Edit: Mon, 24 June 2013, 06:27:52 by xwhatsit »
Beam spring IBM 5251 (7361073/7362149) & IBM 3727 (5641316) | Model F IBM 122-key terminal & IBM PC-AT 84-key | Model M Unicomp 122-key terminal | Cherry MX Blue Leopold Tenkeyless

Offline dfj

  • Posts: 171
  • Location: Canada
  • Visit our irc: #geekhack on libera.chat!
Re: Beamspring USB
« Reply #3 on: Mon, 24 June 2013, 07:08:07 »
  So - with the later F boards, IBM used a programmable multiplexed input comparator - it would take two inputs per cycle, first carrying the line to read, the second a small offset to the reference to compare with. This presumably allowed them to get a pcb/layout working more quickly, without needing to tune the whole pcb to use the same threshold. Minimizing crosstalk was still an issue - but one thing that really helped was pulling all the other strobe lines to ground firmly when strobing the column of interest.
  The beam-spring was not so lucky, and the early ones needed to be designed such that a single threshold would work for the whole board.

I scope it at 10x (high imp), and/or through a high-input-impedence op-amp to get a better pic of what effects my experiments are having...
 A few interesting artifacts I have observed: If your bias voltage is weakly driven, then the act of bringing a switch up or down will often put a ms long wave onto your sense line - up to 5 or ten times the size of the normal strobe-driven signals. I'm not sure how much it depends on your bias voltage, but - if you drive the bias harder, the effect is negligible. If you drive it *too* hard, however, your signal gets obliterated. :/
  The weaker you drive it, the longer it takes to recover after a strobe, of course.
I ended up driving the bias voltage relatively firmly through a switch, and turning it off prior to the strobes. This turned out to be how the programmable comparators that IBM used also applied their bias, so I stopped feeling guilty when I spotted that in a schematic for an early 4-line sense chip (likely very similar to what is in yours).
  Depending on how you set your bias, how fast you run your comparators and such... you can easily see drifts - sometimes the temporary drift, caused by a keypress, and sometimes temperature sensitivities if you used lame references, biases, or comparators - or perhaps overdrove them. :)
(I think remember I trying all those errors out for size).
  This was all old hat to IBM who had been using both mylar and pcb capacitive arrays as ROM for decades.
see: http://www.glennsmuseum.com/ibm/ibm.html down in the 'IBM System/360 Read-Only Storage (ROS)' section (warning: slow site)
  I tend to use a diode/resistor pair as a simple bias voltage which is easily turned off, but this introduces temperature sensitivity from the diode. I'm not sold on it, really, but it can be made to work.

more lucks. :)
dfj

PS: early prototype using teensy++ (at90usb1286), resistors and a single diode...

later prototype using lots of diodes (and optional, superfluous resistors) :p



 
Fave Switch manus: IBM, Topre, Matias, ...

Offline dfj

  • Posts: 171
  • Location: Canada
  • Visit our irc: #geekhack on libera.chat!
Re: Beamspring USB
« Reply #4 on: Mon, 24 June 2013, 07:09:24 »
And - grats on getting it typing. :)

(I just moved - my BmS are still packed, and they need to be merged together to make a working one, as both are busted/for parts)

dfj
Fave Switch manus: IBM, Topre, Matias, ...

Offline Parak

  • Posts: 532
Re: Beamspring USB
« Reply #5 on: Mon, 24 June 2013, 09:05:34 »
Nice! You reused the connector I take it? I've been trying to find new ones, but the closest I've been able to come are these for 1.6mm pcbs with 3.96 spacing, which makes 0.8 ones custom order only ($ludicrous).

Edit: on second look and remembering which connectors I have in my beam springs, it actually looks like you used a new one quite similar to the one I linked :P

As far as beam springs go though, it'd also be nice to consider doing something about contamination shields. The old ones are useless due to being all crumbly, and the lack of one makes me scared of actually using a beam spring for any length of time considering how ingress and debris sensitive the switch is compared to buckling spring :(
« Last Edit: Mon, 24 June 2013, 09:13:38 by Parak »

Offline xwhatsit

  • Thread Starter
  • Posts: 297
  • Location: NZ
Re: Beamspring USB
« Reply #6 on: Mon, 24 June 2013, 17:54:29 »
Schematic attached.

Parak: yes that's the connector I used. 3.96mm pitch. It was cheaper than that though---quite a few sellers carrying those for some reason, although a bit hard to work out what I was looking for at first. I have two beamsprings, both appear to be based roughly on 5251 but have different layouts (I think one is a 3278 layout). The first one (that is in the photos) I stripped down and removed the completely destroyed contamination shield. It's a very loose and `rattly' board. The second one, the 3278 layout board, is very tight and quiet, and still has its contamination shield.

dfj: Not 100% sure what you mean about bias, maybe I'm interpreting it wrong. As you can see from my schematic, I hold each each sense row a little about ground with the 47K/10K resistor divider, then through a 100K resistor to keep the impedance low enough between rows. Is this kind of what you meant, but you're switching it on and off? The main reason why I'm biasing it above ground is to stop the small negative spike (-150mV or so) out of the sense rows when I transition column drive line High->Low from annoying the comparators (I think LM339 can safely handle -0.3V but still...). The LM339 includes Gnd in common mode input range so that's the only real reason.

In the second attachment with the graph I show a small ngspice example. The (almost invisible) yellow trace is an individual column drive line. I use the 74HC4094s for that, and as they have a reasonable rise time, you get a derivative action in the form of current proportional to rise time in the capacitor (I=CdV/dt). The red trace shows an `up' key (about 4pF), the green trace shows a `down' key (about 0.4pF). After the drive line stabilises high, the current in the capacitor slowly dissipates back through the 100K resistor to the voltage divider (sitting at a little less than 1V). When the row drive line goes High->Low, you see the corresponding negative spike.

So I use the comparator to distinguish between the varying amplitudes of the spikes between 0.4pF and 4pF, by setting a reference voltage (the light blue trace) somewhere between the two spikes. The dark blue trace shows the output of the comparator connected to the `up' key, the pink trace shows the output of the comparator connected to the `down' key.

The actual spikes I get from the keyboard are less than shown in the spice graphs---more like 100mV or so. This could be because there's less capacitance than I modeled, or there's more stray capacitance sucking up the tiny amount current. Also, there are all the other capacitors on an individual row. In that spice trace I am also using 10K sense line drain resistors to the bias voltage, so it drains and charges more quickly.

Is this how you mean the bias voltage (the way I'm bringing the lines up to 1V or so), except that you're worried about the recovery time after the negative spike, so you were using a low impedance path back to the bias so as to bring the caps back again quickly after the spikes, but disconnecting the bias so it wouldn't overwhelm the spike when you were driving it? I haven't found that to be a problem as the caps drain pretty quickly, I'm getting about 4us per column, so 23 columns means about 10kHz scan rate (if you ignore all the USB stuff). Certainly quick enough to implement some filtering/debouncing (I still see a bit of bounce at very high scan rates), which has solved my key repeat issues I saw earlier.

I think I may know what is causing the left-hand side of the board to be a bit flaky right now. I do a single scan, then process the USB stuff (with all the drive lines tied low), rinse and repeat. The act of driving each column has injects a little bit of current into the switches through the resulting output through the sense lines. Then there's the high impedance drain path to Vbias maybe causing a low-pass filter thing (I now see why you might want to make it low impedance but disconnect it!). By the time I get to the third or fourth column the remaining columns have already `warmed up' so they respond nicely. I bet if I drove the board `backwards' (column 22 through 0) I would see the same effect on the opposite side of the board. I may be able to fix it by doing a dummy scan first, I can afford to as my scans are pretty quick.

Oh well will have to wait til tonight when I'm home, girlfriend pinched the car today and a beamspring board isn't ideal on a motorbike...

I would love to see more about that programmable comparator, I don't think I fully grep what you mean but it sounds very interesting.
Beam spring IBM 5251 (7361073/7362149) & IBM 3727 (5641316) | Model F IBM 122-key terminal & IBM PC-AT 84-key | Model M Unicomp 122-key terminal | Cherry MX Blue Leopold Tenkeyless

Offline xwhatsit

  • Thread Starter
  • Posts: 297
  • Location: NZ
Re: Beamspring USB
« Reply #7 on: Mon, 24 June 2013, 17:55:19 »
Sorry that png of the schematic was a bit rubbish, have attached the pdf.

Ah... the Model F technique you were talking about was using something like this: http://www.ti.com/lit/ds/snas530a/snas530a.pdf and modifying the reference voltage individually for each column or key? I could do that in theory (I have more or less a similar setup except the DAC and comparator are discrete) but the DAC speaks TWI/I2C so it takes an appreciable amount to set a new Vref (maybe 150us or so, plus time for the MCP4726 to settle, maybe another 10us, will have to check datasheet). The must have had a rather speedy programmable comparator.
« Last Edit: Mon, 24 June 2013, 18:08:36 by xwhatsit »
Beam spring IBM 5251 (7361073/7362149) & IBM 3727 (5641316) | Model F IBM 122-key terminal & IBM PC-AT 84-key | Model M Unicomp 122-key terminal | Cherry MX Blue Leopold Tenkeyless

Offline dfj

  • Posts: 171
  • Location: Canada
  • Visit our irc: #geekhack on libera.chat!
Re: Beamspring USB
« Reply #8 on: Mon, 24 June 2013, 23:55:17 »
Yeah - very much like that TI chip - except IBM had a nice one working in the late 70s, then an 8-way towards 80/81.
  So - yeah, by bias I intended the 50k/10k offset to get the voltage a bit away from zero, partly so it didn't dip below zero during recovery, and partly because I used diodes to protect the signals from each other.
  My design ended up a little more complicated than it needed to be, as I had originally intended to test (all 8 on most F boards) the sense lines after each strobe and thus requiring far less recovery time. Sadly, I wasn't able to keep the signals up long enough for the atmega's adc to read enough of them reliably.
  Currently, I'm using a sample and hold with 1nF caps, op-amps, and analog switches. This is a bit excessive, but working nicely.
I have a profoundly nasty usb scope: but I'm getting a complete 127 key scan off my F every 2ms, enabling the following which shows a very short keypress (a flick, actually) for two scan cycles, then releasing during the third scan, not triggering the threshold.
I paused the scan brieflly (100us, I think) to show where I sent the USB reports for the state changes (down, then up).

The 4.5ms between t1, t2, isn't really fair - I think it really came more than 0.5ms before the strobe got around to noticing... I am trying to get the F to be able to report a short press-release in better time than a cherry switch - since I am of the opinion that the F bounces less, so can safely report a key-break before a cherry scanner could. I'm nearly there, though.
Red is the strobe, blue the sense. Because I'm amplifying, I can get away (I claim) with running the adc excessively fast i.e. well into low bit unreliability. The blue probe was at 10x, so the amplified sense lines actually have closer to a 200mV difference between unpressed and pressed states. Also visible in the trace is the shorter, non-triggering, regular spike caused by the 'test pad' found on many F boards - it is sized such that it should be below the minimum sense value of any other key, though in later boards less of them are found (some have one for each sense line) and they ended up mostly a sanity check that the board was intact generating an error code if they ever scanned as a make.
  kk, naptimes.
Need to scribble up a schematic - parak amonst others need it shortly.
Fave Switch manus: IBM, Topre, Matias, ...

Offline xwhatsit

  • Thread Starter
  • Posts: 297
  • Location: NZ
Re: Beamspring USB
« Reply #9 on: Tue, 25 June 2013, 04:07:31 »
Thanks for the info. Interesting way to get the signals with the sample-and-hold---I suppose the additional complexity is due to the design decision to get an analogue result for each key rather than a straight digital yes/no. The advantage of your approach is that it becomes very easy to give each key its own threshold value, wildly different from the others if you wanted to. The way I've done it doesn't allow that. The trade-off is increased speed and a simpler circuit, with less flexibility and less tolerance for variances. I might have to consider that route when I get around to doing my two Model Fs (PC-AT 84-key and terminal 122-key) if what you say about IBM designing in more tolerance across individual boards.

I've now got the left-hand side of the board working reliably. Spend a great deal of time fiddling around with delays and thresholds and all sorts of nonsense, and kept getting `overlapping' keys (two sets of keys reporting the same row/column). Then I remembered that it was working fine last night at work before I took it home... left it sitting in the back seat of the car on the trip home with no case, after carrying it to the carpark in a downpour. I unplugged the controller board, blew it out, cleaned some fluff off it and between the keyboard PCB and the backplate (a good place for crap to collect) and plugged it back in---working perfectly. I must give the board a good scrubbing at work tomorrow to get all the flux off etc. Point taken about contamination shield too, Parak!

I'm using the board more or less like my PC-AT at the moment, treating the left-hand-side group of 10 keys as F1 through F10, and using the numpad for cursor keys and PageUp etc. As per how I used my 122-key Model M for a long time I've turned the tilde/backtick into Escape, and the <> (><?) key next to short LShift into tilde/backtick. All seems very comfortable.

So I'm more or less done. Still don't have automatic calibration implemented yet, it seems rather stable, but it is probably not a dumb thing to write as it saves having to guess a threshold voltage. It would rely on an `always low' and `always high' key (unused by an actual key) to be known, of which there is, but it kind of ruins my initial grand plans of a completely auto-configuring keyboard that you could just plug in and `teach' by pressing keys in response to prompts.

Need to work out exactly what my scanrate is. It's not as quick as it was (I have an extra couple of delays in there to allow things to calm down, might not be necessary now), and I've got a reasonably long filter (incrementing/decrementing integer value for each key executed each scan, min=0 max=15, >7=pressed, =<7=unpressed) right now as well. I'm also doing a `wasted' scan each time. I'll put it on my work scope tomorrow to see exactly how quick it is. If it's fast enough I'll just leave it with those extra tolerances in there for reliability, if not time to optimise.

I'll clean up the source and put it (with the schematics and layouts etc.) up on github somewhere when I get a chance.

What a damned nice keyboard! Can't wait to try this on my nice-and-tight newish 3278-layout 5251. This is the rattly one but it's probably one of the `fastest' feeling boards I've ever typed on, and very accurate (I'm still getting used to my PC-AT after a long time with my Model-M 122-key). Crisp and light but lots of feedback, both through the fingers and the ears. Impossible not to bottom out at the moment, there's very little movement post-actuation before you hit the backplate, will have to see if that's fatiguing after a full day coding.
Beam spring IBM 5251 (7361073/7362149) & IBM 3727 (5641316) | Model F IBM 122-key terminal & IBM PC-AT 84-key | Model M Unicomp 122-key terminal | Cherry MX Blue Leopold Tenkeyless

Offline xwhatsit

  • Thread Starter
  • Posts: 297
  • Location: NZ
Re: Beamspring USB
« Reply #10 on: Tue, 25 June 2013, 21:05:51 »
OK, all fitted back together and using it at work today with a layout roughly analogous to my PC-AT.

Some photos.
26487-0

Some miniaturisation over the past 30-40 years---especially with regard to the cables and connectors :)
26489-1

26491-2

A beamspring---a must-have for the modern-day workstation:
26493-3
Beam spring IBM 5251 (7361073/7362149) & IBM 3727 (5641316) | Model F IBM 122-key terminal & IBM PC-AT 84-key | Model M Unicomp 122-key terminal | Cherry MX Blue Leopold Tenkeyless

Offline dfj

  • Posts: 171
  • Location: Canada
  • Visit our irc: #geekhack on libera.chat!
Re: Beamspring USB
« Reply #11 on: Wed, 26 June 2013, 00:08:49 »
So purdy - and nice AT. :)

One of mine is still as I received it, still needs to have the barrier replaced.
About 1/3 done the schematic this AM - might have it for folks tomorrow night (say 10-ish gmt-5).

Grats on that... I breadboard up my circuits with through-hole to prototype, then perfboard to test... by the time stuff matures I tend to be onto some other crazy, and want to leave the design of a sane pcb to other folks. :)
dfj

 (btw: not to be mocking the particular choices of components - they are what I had knocking around, will choose better compatible examples shortly.)
Fave Switch manus: IBM, Topre, Matias, ...

Offline xwhatsit

  • Thread Starter
  • Posts: 297
  • Location: NZ
Re: Beamspring USB
« Reply #12 on: Wed, 26 June 2013, 00:36:48 »
Cool, I'm interested to see your circuit. I've never tried implementing sample and hold myself with discrete components; I've used the MCP3304 a few times (which would be ideal in some ways, nice and fast SPI and up to 8 single-ended channels if you want), but obviously it comes at a cost. Through-hole, too, for veroboard (although now I've discovered OSHPark I don't think I can be bothered with through-hole any more!). Yes I'm bad for prototypes too, but breadboarding this for more than a column or two wasn't really feasible due to the stray capacitance and long wires etc. Too much electrical noise floating around where I am, I'm a software developer for industrial machinery and happen to be based in the same place they build the machines so lots of three-phase contactors and servo drives causing all kinds of interference :P

OK I put my board on the scope, and I see I'm only getting 892Hz now for scan rate. I could try optimising but it's probably fine to be honest. I find I'm getting away with a debounce of 3 scans (integer counter, min=0 max=6, <=2 is unpressed, >2 is pressed). And I've ditched the dummy scan. This means despite a slower scan rate (by about a tenth) than what I originally had, it's still effectively quicker than most Cherry boards (that is if they stick to a full 5ms debounce). I don't know if I can bothered trying to optimise things (my shift register routines are fairly `dumb' right now, and cycle through the entire sequence just to clear or set a bit).
26524-0

Following picture shows two successive row drive pulses. You can see the gap inbetween them. This was a `gotcha' early on in the prototyping phase where I eventually realised that the negative spike from the High->Low transition was knocking out the immediate following positive spike from the Low->High transition on the next column.
26530-1

Following picture shows an unpressed key (LShift in this case). Yellow trace is the row drive pulse, blue is the returned sense column. It of course shows multiple peaks from the other rows being pulsed (which are not being scoped). You can see it's roughly about 100mV amplitude, and only just manages to recover back to neutral Vbias before the next pulse hits, so if we decrease the gap inbetween successive row drive pulses things will start to get a little bit more tricky. There is some variance between the sense waveforms on the next row drive pulse after the one we're scoping, I think it's the scope interfering more than anything else... 10K impedance on the scope isn't really enough, 100K or 1000K probes would be better I think!
26526-2

Following picture shows LShift being pressed. You can see there's a nice big difference between pressed and unpressed (about 50mV?) that it's relatively easy to use a comparator to distinguish between the two states, with some headroom for variance across the board.
26528-3

So yeah... to-dos include autocalibration, maybe an additional USB HID endpoint for debugging (and flashing new keymap?). Having an additional endpoint would be nice so I could trigger the board into USB DFU programming mode without having to take the case off and press RESET and PROG. Then I need to assemble another board and fit it to my other beamspring. That leaves one board leftover from OSHPark. Anybody have a 5251-style beamspring board they want to actually use?
Beam spring IBM 5251 (7361073/7362149) & IBM 3727 (5641316) | Model F IBM 122-key terminal & IBM PC-AT 84-key | Model M Unicomp 122-key terminal | Cherry MX Blue Leopold Tenkeyless

Offline dfj

  • Posts: 171
  • Location: Canada
  • Visit our irc: #geekhack on libera.chat!
Re: Beamspring USB
« Reply #13 on: Wed, 26 June 2013, 13:17:22 »
Sweet stuff.

  I assume you are good when holding down the other three keys on the column to reliably detect presses. The beam springs were mostly only 4-rows, and the pcb would be tweaked to minimize the crosstalk. I think the chips with the independent thresholds for each key allowed IBM to get up to 8 sense lines onto their boards. More than four clearly being helpful for the 122s, and other boards with a single or double F-row.
  Oh - if you find interference within the *row* - (e.g. holding down asdf and jkl then testing ';'), we found the independence of columns to be hugely improved by doing as the IBMs did, and pulling the unused columns firmly to ground with a low-impedence connection. Without that, enough keys being held on parallel rows and columns could create the analogue of the classic switch-based matrix 'ghost' key events. (thanks to Soarer fer this insight, I was tired when he first tried to explain it to me and it was like talking to a brick wall about numerous distant caps in parallel eventually becoming numerous enough to equate with a closer, angrier cap).

kk, I'm off to try to jot down some more of the current schematic. :)

dfj

PS: come visit some time on the irc.
http://webchat.freenode.net/?channels=geekhack
« Last Edit: Wed, 26 June 2013, 13:42:25 by dfj »
Fave Switch manus: IBM, Topre, Matias, ...

Offline xwhatsit

  • Thread Starter
  • Posts: 297
  • Location: NZ
Re: Beamspring USB
« Reply #14 on: Wed, 26 June 2013, 16:08:55 »
Yeah I fired up xkeycaps (a bit like Aqua key test as far as I can tell), and I seem to be able to get 6 keys at once in any combination I tried anywhere on the board without ghosting or missed keys. I haven't bothered implementing NKRO as I don't have a lot of use for it myself and there's other important things to finish first.

Point taken about 4 sense lines vs 8. I think I would need a minimum of two Vrefs when I get around to doing my Model F 122-key controller, as I'd need two LM339s (the quad comparator) and you'd want to be safe in case the two LM339s were different in characteristics. They are guaranteed to be pretty close on a single chip, but I don't know across two.

Yep I pull down the other rows. I stupidly used OE instead of STR with the 74HC4094s (doesn't really matter in practice though); I leave OE off (so leaving all rows floating) while I clock in my next shift register state (either to set a row high or everything off), then turn it back on. As OE is shared across all 74HC4094s and across all outputs on given 74HC4094, the other lines are pulled low when I bring one high. The `idle time' between consecutive row drive pulses you can see in the scope traces above is OE on, but with all 0s clocked into the shift register, so all lines are pulled low (to allow caps to drain).

Yeah I should dig out an IRC client (it's been a while) and idle some time.
Beam spring IBM 5251 (7361073/7362149) & IBM 3727 (5641316) | Model F IBM 122-key terminal & IBM PC-AT 84-key | Model M Unicomp 122-key terminal | Cherry MX Blue Leopold Tenkeyless

Offline dfj

  • Posts: 171
  • Location: Canada
  • Visit our irc: #geekhack on libera.chat!
Re: Beamspring USB
« Reply #15 on: Wed, 26 June 2013, 16:32:31 »
   Well - my thinking is that with the extra speed of using comparators I might eventually be able to ditch the sample and hold, just let the natural loft of the signal through the strobe do the trick. The main issue that drove me nuts is the wait for the sense lines to stabilize after each strobe. As long as I was only reading one sense line at a time, then I needed to recover for each key, and one or two more each to ameliorate noise. 10us was also close to the best I could do without drifting away from the reference. - 122 x 10us, x 2 and we're already at 2.5ms per scan, and we haven't actually done *anything*. Reading an adc twice, adding up some crap, preparing some USB junk - and it burned up my margin fast... I got that design under 5ms, but it was sketchy. Also my offset was based on diodes which would shift a bit as the temp at my desk changed from month to month. I had autosense, but only at boot... took me a bit to debug that. :)
  Right now I want something that other folks can assemble and get working, and with enough play left in the code that folks can add features without screwing up timing constraints. All sorts of cool features in some of the firmware floating around, from macros, layout layers, even little programmable shells... to nkro USB descriptors, LED craziness, etc... with a nice fast scan, I hope to be able to get the dependencies down so it will tuck into other folks firmware as an alternate scan routine.
   I tend to use the teensy, and yeah - has a debug chan, so - easier than watching through an app filter. (also - I get a log on disk).
  I hope you won't need to worry overly about the differences from one comp chip to the next - I'd expect it'd get eaten by the auto-sense when you search for a DAC value that is middly between up and down (assuming you are willing to reprogram your DAC relatively often). One nice thing about strobing each key independently: you don't need to scan in 'left to right, top to bottom' order - you could instead scan by vref, if your DAC was too slow SPI... there might be some fun hair jumping between columns, but you might be able to interleave column reads and get free recovery for other sense lines instead. Just how crazy will you let your code get?

:p

dfj


dfj
Fave Switch manus: IBM, Topre, Matias, ...

Offline CPTBadAss

  • Woke up like this
  • Posts: 14363
    • Tactile Zine
Re: Beamspring USB
« Reply #16 on: Wed, 26 June 2013, 17:04:57 »
xwhatsit, thank you for posting all this. I don't currently really get what you're doing EXACTLY, but I'm trying to read and digest it as best I can. If you could post some links...kind of like an idiot's guide or something, that'd be amazing. Otherwise, I'll be bugging dfj for a long time trying to iron out all these details.

But really though, I can't wait to see how this turns out. And hopefully this motivates Soarer and dfj to work on their Model F controllers! :D

Offline xwhatsit

  • Thread Starter
  • Posts: 297
  • Location: NZ
Re: Beamspring USB
« Reply #17 on: Wed, 26 June 2013, 19:59:42 »
CPTBadAss: heh yeah it's not immediately obvious how it all works. It took me a little while to figure it all out from the IBM patent (I copied their technique) as it's not the normal way you do capacitive sensing (like with touchscreens or soil moisture sensors or the touch buttons on a fancy Samsung TV)...

The basic principle is as follows.

Each key is a tiny capacitor. When it's unpressed, the capacitance is about 4pF, and when you press the key the capacitance drops to 0.4pF.  The problem is of course sensing the difference between those two values---and measuring capacitance isn't as straightforward some other things.

There's a variety of methods used to measure capacitance but a lot of them are quite slow, and we need to scan a whole bunch of keys in a short period of time. So we use a more uncommon technique that is possible because we only want to sense if a key is more than, say, 2pF, or less than it---we don't need to know the exact value.

Capacitors have an interesting effect of "differentiating" the voltage input to them. If you keep the input to a capacitor at the same level, it will output zero current. If you raise the input voltage, it will output current proportional to the rate of change of the input voltage. If you drop the input voltage, it will "output negative current" if that makes sense. So if you switch the output of a microcontroller ON into the input of capacitor, the capacitor sees a very quick rise of input voltage (and then stops changing while the output stays switched on) and will output a positive spike. When we switch the output back off, the capacitor sees a very quick drop of input voltage and outputs a negative spike (of current, but this gets converted back into voltage for other reasons). By the same token if you raised the voltage very slowly, you'd see a small positive output from the capacitor as long as the voltage keeps rising. Stop raising the voltage, and the output drops back to zero. Start lowering the voltage slowly and you'll see a small steady negative output... you get the point.

The important thing here is that those spikes are proportional to how big the capacitor is. So, if we keep sending our key capacitor pulses by switching our microcontroller output on and off, the spikes are bigger when a key is unpressed, and smaller when a key is pressed.

Now we have a change in voltage when a key is pressed instead of a change in capacitance, and that's much easier to measure.

We could use an analogue-to-digital converter to get the amount of voltage into our microcontroller (many microcontrollers have them built-in), but they're slow and our spike is tiny and only exists for a fraction of a second.

So we use a comparator. A comparator has two inputs, a "+" input and a "-" input, and one output. When the "+" input is at a higher voltage than the "-" input, the output of the comparator is switched on. When the "-" input is lower than the "+" input, the output is switched off.
 
We get a comparator then and hook up the "+" input to the other end of the key's capacitor. The "-" input is hooked up to a fixed voltage that is set halfway between the voltage spikes from an up key and a down key.  (This voltage can come from anywhere, initially I just used a variable resistor set with a screwdriver to change the voltage for tuning, but I use a digital-to-analogue converter on this board so I can change the value from my code).

What this means is now we can switch on the output of our microcontroller, the capacitor emits a voltage spike, the comparator then compares the spike to see if it's lower or higher than the threshold value, and will turn its output on or off accordingly. The output of the comparator is hooked up to an input on our microcontroller and we can then see if the key is pressed or not.

That's all there is to it really. The only complicated parts come in that there's many, many capacitors hooked up in a matrix (23 columns and 4 rows), so we use 4 comparators to read the 4 rows, and pulse each column in turn and read the 4 comparators at once to see the result. In this way it's very similar to a "normal" keyboard controller with "normal" keyswitches.

Hopefully that makes sense and isn't too long-haired.

These links show the principle of capacitive differentiation (and integration):

http://www.physics.ucla.edu/demoweb/demomanual/electricity_and_magnetism/ac_circuits/rc_integration_and_differentiation.html
http://www.tpub.com/neets/book9/37k.htm
« Last Edit: Wed, 26 June 2013, 20:05:15 by xwhatsit »
Beam spring IBM 5251 (7361073/7362149) & IBM 3727 (5641316) | Model F IBM 122-key terminal & IBM PC-AT 84-key | Model M Unicomp 122-key terminal | Cherry MX Blue Leopold Tenkeyless

Offline poxeclipse

  • Posts: 171
  • Location: Toronto, Canada
  • Hit me with music ... yes, me friend
Re: Beamspring USB
« Reply #18 on: Wed, 26 June 2013, 20:40:27 »
This is really great. Will it work on 3178 terminal  keyboards, e.g. 6052141 or 5640987 ?

Offline CPTBadAss

  • Woke up like this
  • Posts: 14363
    • Tactile Zine
Re: Beamspring USB
« Reply #19 on: Wed, 26 June 2013, 20:48:23 »
No, that explanation was lovely. I'm going to reread that post, your link, and then the rest of the thread a few times to try and understand. I hope you don't mind me bugging you more about this.

I'm an absolute plebe when it comes to this kinda stuff. Trying to learn though so thanks again!

Offline xwhatsit

  • Thread Starter
  • Posts: 297
  • Location: NZ
Re: Beamspring USB
« Reply #20 on: Wed, 26 June 2013, 21:05:24 »
This is really great. Will it work on 3178 terminal  keyboards, e.g. 6052141 or 5640987 ?
Note as-is, as the 3178 keyboard is a Model F, so the connector and number of rows/columns will be different so a new PCB would be needed. The basic principle wouldn't change though, aside from the fact Model F's have a smaller capacitance when the key is up, and more capacitance when the key is down (it's the other way around with the beam spring) and some concerns dfj has raised about Model F's not being manufactured with such tight tolerances in capacitance values across keys with the Model F. I hope to do a Model F controller in the near future, as I have a 122-key terminal and a 84-key PC-AT that would benefit.

No, that explanation was lovely. I'm going to reread that post, your link, and then the rest of the thread a few times to try and understand. I hope you don't mind me bugging you more about this.

I'm an absolute plebe when it comes to this kinda stuff. Trying to learn though so thanks again!
Heh that's good. I'm a software guy as far as my education goes so a bit of a plebe with electrons too :)
Beam spring IBM 5251 (7361073/7362149) & IBM 3727 (5641316) | Model F IBM 122-key terminal & IBM PC-AT 84-key | Model M Unicomp 122-key terminal | Cherry MX Blue Leopold Tenkeyless

Offline dfj

  • Posts: 171
  • Location: Canada
  • Visit our irc: #geekhack on libera.chat!
Re: Beamspring USB
« Reply #21 on: Wed, 26 June 2013, 21:55:39 »
  Luckily for us, the actual values are more like 40pF and ~10 pF (slightly different numbers on the Beam Spring, but - roughly ten times what x feared. To confirm this without doing math  - try attaching a few pF of (2-10) of parasitic cap to ground, you'll see it damage the signal, but it won't annihilate it the way it would if it were grossly larger than the underlying pads.
  ( I tried this a while back)
  Another way to sanity check my claim is to look up expected capacitance of parallel traces at different pitches, per inch - important to keep these rough estimates at the back of yer head anyway - since they are either irrelevant, or not - depending on your signal paths and strengths. In our case, the lengths are short, but still many inches, and it actually helps a little to increase separation between traces. Similarly running over a ground plane is great shielding, but also introduces a small parasitic... all these are on the scale of pF for these keyboards, so need to be managed, but don't make the problem intractable as they would if they were ten times larger relative to our signals.
 
To be clear: awesome work, and it will lead shortly to an excellent F controller as well, surely. Nigh guaranteed, actually, given that it is so close to the design of the original IBM electronics. I just couldn't resist nitpicking. :p

dfj
(also a CS bloke who has grabbed the wrong end of an iron more than once)
Fave Switch manus: IBM, Topre, Matias, ...

Offline xwhatsit

  • Thread Starter
  • Posts: 297
  • Location: NZ
Re: Beamspring USB
« Reply #22 on: Wed, 26 June 2013, 22:31:26 »
Ah interesting. I've never measured the actual capacitance (I think we have a meter with capacitance mode on it at work, but I've never tried it---no clue whether it can measure down low enough. I grabbed the 0.4pF and 4pF values from the patent. 10pF and 40pF makes sense though, as there's not a whole order of magnitude difference in the resulting signals.

In either case they're tiny wee signals and must have been a real pain in the arse to design for!

I think I might start assembling the other controller shortly so I can try out my other beamspring :)
Beam spring IBM 5251 (7361073/7362149) & IBM 3727 (5641316) | Model F IBM 122-key terminal & IBM PC-AT 84-key | Model M Unicomp 122-key terminal | Cherry MX Blue Leopold Tenkeyless

Offline xwhatsit

  • Thread Starter
  • Posts: 297
  • Location: NZ
Re: Beamspring USB
« Reply #23 on: Thu, 27 June 2013, 02:52:26 »
OK just lost a few paragraphs. Apparently geekhack server doesn't like more than a few photos uploaded at once :/

Assembled another controller and used it to convert my other beamspring to USB (a 3727). Went very smoothly. Nice layout, although losing F9 and F10 is a bit of a blow (only just got used to not having F11 through F24 after moving from 122-key Model M to the PC-AT Model F).

Noticed the label on the bottom, `Property of IBM'. Interesting!

In any case it's a beautiful board despite the scuffs on the outside. I've never had it apart and it's smooth as butter. A little quieter and deeper sounding than the 5251, as it has a fully intact internal foam layer and the contamination layer is all there. Still very tactile and nice luxury-car sounding `click' when it actuates.

Didn't get to use it much as assembled the controller, installed it in the board, calibrated the board (Vref is a little higher) and mapped the key layout and had to head home.

Looking forward to using it for a full day's work tomorrow :)

Photos follow.
Beam spring IBM 5251 (7361073/7362149) & IBM 3727 (5641316) | Model F IBM 122-key terminal & IBM PC-AT 84-key | Model M Unicomp 122-key terminal | Cherry MX Blue Leopold Tenkeyless

Offline damorgue

  • Posts: 1176
  • Location: Sweden
    • Personal portfolio
Re: Beamspring USB
« Reply #24 on: Thu, 27 June 2013, 03:24:55 »
Looks neat, looking forward to your comments after using it. A question from someone who has never touched one: How does the space bar feel? How is it stabilised? It looks quite long and I wonder if it very heavy or if it has a tendency to jam.

Offline xwhatsit

  • Thread Starter
  • Posts: 297
  • Location: NZ
Re: Beamspring USB
« Reply #25 on: Thu, 27 June 2013, 03:35:52 »
No the spacebar is pretty good. It's nicely stabilised with a long wire-type stabiliser (you can see it in IMG_490.jpg above). It's slightly heavier than the rest of the keys but we're not even close to having a PC-AT situation (need to rectify that on mine at some point, it can be fatiguing). It feels less tactile than the other keys and a bit more `mushy', so it's similar to a typewriter in some respects (the impression enhanced by the keyboards using IBM Selectric keys as far as I can see).

Doesn't jam---if the case has been reassembled correctly; the case has two halves with big left and right mounting stands for the keyboard assembly itself. The keyboard assembly is designed so it can be moved around on the stands to adjust for discrepancies in the folded sheetmetal. The end result is that if you let the board sit too far down on the stands when you tighten the screws, when you put the top cover on the cut-outs in the top cover will interfere with the bottom row of keys.
Beam spring IBM 5251 (7361073/7362149) & IBM 3727 (5641316) | Model F IBM 122-key terminal & IBM PC-AT 84-key | Model M Unicomp 122-key terminal | Cherry MX Blue Leopold Tenkeyless

Offline xwhatsit

  • Thread Starter
  • Posts: 297
  • Location: NZ
Re: Beamspring USB
« Reply #26 on: Tue, 02 July 2013, 00:57:16 »
Have got source into a workable state for some sort of release, GPL3 license. See first post.

The keyboard now auto-calibrates Vref (there is some `fuzz' in there I'm not totally comfortable with, but that's the nature of these things more often than not---I set the calculated point 3/4 of the way between the LO and the HI point the algorithm picks out).

Alternatively, the Vref value can be stored in EEPROM, which the keyboard will reads on boot. If the EEPROM value is 0xffff (default for unprogrammed EEPROM), then it auto-calibrates, otherwise it just uses the EEPROM value.

I've implemented a diagnostic interface (using HID just because it's easy) to allow setting said Vref, performing auto-calibrations on-demand, reading/writing keyboard scancodes and monitoring current key states (btw this showed me I have full NKRO---actual full NKRO across the entire board, hit all the keys at once if you want to---although I'm only sending 6 at a time over USB). It should allow setting up a keyboard from scratch without having to recompile/reflash. Diag interface also allows jumping the controller into the USB (DFU) bootloader so I don't have to keep pulling the shell off the keyboard to hit the RESET/PROG tact switches.

Currently I just have a command-line-only tool to drive and monitor the diagnostic interface (using libusb). I will eventually roll this into a cross-platform Qt GUI app to make it a bit easier to handle.

Likewise I got rid of my huge hard-coded keyboard matrix array. This is now stored in EEPROM (loaded on boot), and the diag interface allows loading and storing to the EEPROM on-demand.

The 3727 is proving a damned good day-to-day keyboard and has really grown on me. Even the Model F PC-AT feels decidely stiff and clunky now. The 3727 variant I'm using (can be seen on photos above) has a pretty handy layout and I haven't missed much.




« Last Edit: Tue, 02 July 2013, 01:11:01 by xwhatsit »
Beam spring IBM 5251 (7361073/7362149) & IBM 3727 (5641316) | Model F IBM 122-key terminal & IBM PC-AT 84-key | Model M Unicomp 122-key terminal | Cherry MX Blue Leopold Tenkeyless

Offline mkawa

  •  No Marketplace Access
  • Posts: 6562
  • (ツ)@@@. crankypants
Re: Beamspring USB
« Reply #27 on: Mon, 08 July 2013, 10:36:58 »
hey dfj! totally OT but is there any reasonably small circuit that can be used to turn a capacitive switch into a self contained unit? think cherry sized, all SMT, doesn't need its own pcb, the capacitive detection circuit can be soldered to the bottom side of a 2-4 layer pcb, but it MUST take the capacitive switch and output a binary logic signal given VCC..

to all the brilliant friends who have left us, and all the students who climb on their shoulders.

Offline dfj

  • Posts: 171
  • Location: Canada
  • Visit our irc: #geekhack on libera.chat!
Re: Beamspring USB
« Reply #28 on: Mon, 08 July 2013, 12:28:33 »
Sure - barring cost. one could use a cheap little uC for 2-3 bucks. Or a few passives, and a transistor, increasing time, labour, qa, but lowering component cost to under $1...
  Putting any components into a module raises cost, even the diode for cherries. multiply by 64-128 for a keyboard, and it's a lot less fun.
In terms of whether it could work for a super-small number, e.g. for a keychain - sure, but - it won't have the feel of a BS board, just that of one switch. Part of the difference between the M and F is the three layers of steel vs one in the M. This can't be reflected in a singel switch.
  For making a module for a free-form layout board, there are several other decent options.
first off - if you want to work in 3D, to make something kinesis like, I'd develop an M-module, rather than an F one, since the nkro advantage of capacitive sensing is wasted on modules, and the M is way easier to sense - would need no electronics.
  For making a single F switch, as a demo or keychain, one could both power, and convert to USB with an atiny or similar miniscule uC, as long as they have a working comparator. resistors could get you an offset voltage couple'd to the particulars of that exact switch.
  For making a free-form keyboard in x rows and columns, but still flat or barely curved in only one axis (like an F), then you can do a dense matrix, or a switched matrix... I wouldn't mind putting together a layout that let one put keys down in rows, however one liked - e.g. with or without lateral offset, with symmetric offset, etc... alternately, one could do rows like the recent fellow did with sliders.
  I find that the tricky parts of reading an F are not reading a single switch - even quickly; it is reading 128 of them, quickly, preserving nkro.
IBM switched to different sense chips with the F from the Beam spring - the beam springs were made carefully, with most of the keys have nearly the same sense thresholds.
 Most of the F boards had a chip which would choose one of 8 preset thresholds to compare against, which gave IBM more flexibility to layout their keyboards.
  When xwhatsit applies his controllers to F boards, I am going to be curious how many different values will be needed to sense the whole board. Experimentally, some of my boards are fairly well behaved with only a few switches out in space.

Bah, my brain is empty of dump, must go off and fill it with coffee.
dfj

Fave Switch manus: IBM, Topre, Matias, ...

Offline dfj

  • Posts: 171
  • Location: Canada
  • Visit our irc: #geekhack on libera.chat!
Re: Beamspring USB
« Reply #29 on: Mon, 08 July 2013, 13:16:29 »
BTW:

Code: [Select]

 8C 8F 8C 8C 8F 87 91 91   8C 8F 8C 8C 8F 87 91 91
 8C 8F 8C 8C 8E 87 91 91   8C 8F 8C 8C 8E 87 91 91
 8C 8F 8C 8C 8F 87 91 8F   9C 91 8C 8E 8F 87 93 8F
 8C 8F 8C 8E 8F 87 91 8F   89 8F 8C 8C 8E 87 91 8F
 8C 8F 8C 8C 8E 87 91 8F   83 8C 83 86 87 80 8C 88
 8F 91 8E 8E 93 8C 96 93   8C 8F 8C 8C 8F 87 93 8F
 8C 8F 8C 8E 8F 87 93 90   8C 8F 8C 8E 8E 87 93 91
 8C 8F 8C 8C 8F 87 93 8F   8C 8F 8C 8E 8F 87 93 93

 My default sense values, (after amplification, about 4.6x), at 5mV per, less 1.28V so it prints as a byte. :)
result ranges from 83 to 9C, with 9c being the test pad - so, higher than any legit unpressed state and lower than any legit pressed state. Just because it has these properties doesn't make it a good threshold, though - since for noise resistance, you want something closer to midway between the extrema produced by your actual, individual key.
 Converting the 83 : 131dec, * 5 = 655mv + 1280 mv = 1935mv / 4.6 is about 421mV - close to my 1 diode drop offset.
the 9C : 156 * 5 = 780mV + 1280 = 2060mv /4.6 = 448mV
This suggests that my board has a range of 27 mV between the actual sampled minimum unpressed key, and the theoretical max unpressed value.
actual measured max unpressed is 0x96, so only a few mV less than that at 441mV, 20mV higher than the other minimum.

I could produce a similar table for pressed values, but it takes longer since I have to press bunches of keys, and combine the table from multiple samples, etc...  so - I'll just claim without proof that the actual result is roughly symmetric with the pressed values starting a bit above the test pad, and some edging up towards a max of about 475mV, for a full range spread of about 50mV.
Not shown here is that (as it happens) the most extreme individual keys rise about 40mV when pressed, with the worst, a hair under 30mV.
  So - if xwhatsit replicated my setup - but used a constant threshold for his comparator, there would still be a few safe values to use on an F - in and about 27mV over the worst keys.. This would be quite vulnerable to noise, though with just a few mV being capable of knocking the key out of state. I expect that some degree of variable threshold will be needed for noise resistance, but hopefully the number of different thresholds needed would be small, to reduce the frequency of messing with it, and waiting for things to calm down.

ok - now I *reallly* need coffee.

dfj


Fave Switch manus: IBM, Topre, Matias, ...

Offline mkawa

  •  No Marketplace Access
  • Posts: 6562
  • (ツ)@@@. crankypants
Re: Beamspring USB
« Reply #30 on: Mon, 08 July 2013, 15:55:06 »
HHMMMMMMM
 
that's quite a lot of brain dump. much food for thought there. to make this clear, what i'm doing here is trying to think ahead; once the SSKs are revived and we can run them off at will, the next project is definitely a capacitive BS, but the computer scientist in me wants as little electrical weirdness as possible in the circuit..

to all the brilliant friends who have left us, and all the students who climb on their shoulders.

Offline xwhatsit

  • Thread Starter
  • Posts: 297
  • Location: NZ
Re: Beamspring USB
« Reply #31 on: Fri, 12 July 2013, 04:41:06 »
Interesting results.

I think 27mV is perfectly doable. I'm not getting much more than that with my beamspring. It's fairly noise immune as even on an F there's grounding everywhere so any transients would appear everywhere, even on Vref (proportionally, as the MCP4726 I'm using is just a fancy programmable resistor divider). Alternatively the key debounce filtering code would take care of any non-common-mode transients as long as they were brief.

If you wanted to increase the 27mV, there are two approaches given we're relying on I=CdV/dt;

 - Reduce dt. So, use a buffer or line driver gate instead of the weedy 74HC4094 (which has OK but not great rise times, especially when drive something with---lol---capacitance). Halve the rise time and get double 54mV instead.
 - Increase dV. These days it's pretty cheap to put a boost reg on the board, or, better yet, a charge pump voltage doubler would be perfect. You'd have to ditch the 5V 74HC4094 (you could use an old-school HEF4094, but the rise times probably aren't as good). Maybe a few BJT arrays to switch the higher voltage. 10V drive pulses mean 27mV becomes 54mV in theory, or go even higher if you want.

The other thing that I'd be interested to know is what the input impedence is like in your sample-and-hold circuit. Not having high enough impedence could be distorting the weedier keys with respect to the more grunty ones.

I spend my working life fixing hardware problems in software :P There's no harm in doing the reverse by throwing some (relatively cheap---especially when compared to the 80s!) hardware at a low-volume problem like this. Variable thresholds make it a software problem but it means a fast expensive DAC, or a fast expensive ADC, and complicated software (which must be a bastard to calibrate, as it means every key has to be pressed to get it sussed). The alternative is some additional hardware---which also has cost---but which make it a cleaner solution.

Will have to start work on an F controller when I get some free time :)
Beam spring IBM 5251 (7361073/7362149) & IBM 3727 (5641316) | Model F IBM 122-key terminal & IBM PC-AT 84-key | Model M Unicomp 122-key terminal | Cherry MX Blue Leopold Tenkeyless

Offline xwhatsit

  • Thread Starter
  • Posts: 297
  • Location: NZ
Re: Beamspring USB
« Reply #32 on: Fri, 12 July 2013, 05:05:41 »
So I posted up some pricing on the `other forum' the other day.

I now have to order some new PCBs to meet some orders and because of lead times on the PCBs I'm wondering how many to order.

I'll post up pricing and rationale here.
Quote
As far as I can see there are three ways to get a controller:

    Use the schematics/PCB/code released above to make your own, or buy one off somebody who is
    Buy an unsoldered/unprogrammed kit of parts from me and do it yourself (~$27 USD + shipping)
    Buy a fully-assembled/programmed/tested controller from me (~$50 USD + shipping)


First option would be the most fun and fastest if you are buying parts and PCBs locally.

Second option is also fun but you might be able to get the bits cheaper (I'm in New Zealand) if you take the first option. You also have to wait for it to be shipped from NZ, which might be a couple of weeks.

Third option gets you something that works (and has been tested on either my 5251 or 3727). It costs a bit more as I'm no pick-and-place machine and I'd really want to test it properly before shipping it out.


Cost breakdown is as follows.

The PCB cost is $USD9.12 from OSH Park. My cost for components is $NZD21.714 (see below), which is rougly $USD17.
(Attachment Link)

The remaining $USD23 for me to assemble and program/test the board is pretty conservative. I've no particular desire to make a profit on any of this (I don't think there's much of a market for this niche-in-a-niche), and would prefer that as many people as possible with beamsprings had the opportunity to use them (hence open-source), however I can't give my time away entirely.

This controller will all be a bit more compelling in a few weeks when I've had enough time to write a more user-friendly graphical remapping/diagnostic program. If people do want either option 2 or 3 from me, let me know either on here or through my email, tom@cornall.co.

Please let me know if you'd like a controller through option 2 or 3. I won't order much more than I need to (as the PCBs would be not-very-heavy paperweights now that all my beamsprings are USB and if nobody wants any more), and there is a decent lead time on PCBs due to the shipping time to NZ so you might have to wait a bit if I don't add you to the current order.

Cheers.
Beam spring IBM 5251 (7361073/7362149) & IBM 3727 (5641316) | Model F IBM 122-key terminal & IBM PC-AT 84-key | Model M Unicomp 122-key terminal | Cherry MX Blue Leopold Tenkeyless

Offline mkawa

  •  No Marketplace Access
  • Posts: 6562
  • (ツ)@@@. crankypants
Re: Beamspring USB
« Reply #33 on: Fri, 12 July 2013, 10:08:50 »
there's no 'other forum'. it's deskthority. the other forum in our community is deskthority. sorry, just your PSA for the day.

to all the brilliant friends who have left us, and all the students who climb on their shoulders.

Offline mkawa

  •  No Marketplace Access
  • Posts: 6562
  • (ツ)@@@. crankypants
Re: Beamspring USB
« Reply #34 on: Fri, 12 July 2013, 10:09:58 »
i don't have time or money right now but i'm in for the next batch. by then i should have more mindshare to devote as well.

to all the brilliant friends who have left us, and all the students who climb on their shoulders.

Offline dfj

  • Posts: 171
  • Location: Canada
  • Visit our irc: #geekhack on libera.chat!
Re: Beamspring USB
« Reply #35 on: Fri, 12 July 2013, 11:47:56 »
Input impedence seems fine, even with bog standard vanilla LM324AN. Because I use a disabled diode divider to provide the bias voltage, the dodgy keys mostly show just as lower and higher sense voltages. For probing with my cheap scope probes, 10x or ideally using a follower is needed to avoid a significant sense reduction. Input impedence matters here - so I amplify, then S&H. There are analog chips to do it, but only one (a 4x) seems to be viable between price and performance at low volume... still, it is $10 in small quantity, so I'd need 2, but it would replace 4 chips and a mess of passives... I'm going to try it out, personally, but other folks will want to make the call on what is better for them to assemble. Grr - more conditionals in the code. ;}

  I use the ADC on my uC to sense with - the built in crap on the atmel chips - and I only bother with the middle 8 bits of the '10 bit' result anyway. I set it to one clock multiple short of physical max, which is way more than recommended for getting mV readings, but because I use software thresholds and amplification, crap in the low bits and moderate nonlinearity don't much matter.
  Bah - need to fix the schematic (revert to last), and post a screenie and a presumptive BOM. You'll be able to offer even better criticism then.

  Once we have that out to a few folks getting tested, and mebbe settle on parts and layout a bit more, I'll commit the kicad files someplace friendly.

As it stands, this controller uses only through-hole parts, so could be assembled by anyone who can solder iCs without toasting them - or they can use socketses. ;}
There will be a batch order for pcb, since many folks want F controllers sooner, rather than later, and a public BOM listed at mouser and whoever else supports it.
 
Part of the issue for me, is that I need to divest myself of as much of the project as possible as soon as possible, since I am only coherent in springtime, which has ended here.
I want the hardware to be general enough to suffice without me for the next year... and the software scan-code to be the only thing I need to maintain/support.
Both Haata and Hasu have expressed willingness to accept scan code, (licenced reasonably) - which should get decently flexible full programmable keyboard controllers out there to folks who want them.
  The above is something you might want to look into too, of course - both are clean and modular, and make my own crazed scribblings seem like pure hackery. ;}
 
Amusingly, in the long run - once we both support both F and beam-spring, your tiny thin controller will have an advantage within the (few luckily) cramped  F cases - and topres,  but there will always be room for anything inside a beam-spring case.

almost coffeed,
dfj





Fave Switch manus: IBM, Topre, Matias, ...

Offline dfj

  • Posts: 171
  • Location: Canada
  • Visit our irc: #geekhack on libera.chat!
Re: Beamspring USB
« Reply #36 on: Fri, 12 July 2013, 15:34:52 »
BTW - http://www.google.com/patents/US3786497?printsec=drawing#v=onepage&q&f=false
It goes into a lot of detail on how IBM wanted to sense, though they weren't able to realize the plans on production keyboards until the later beam-springs, and early F boards.

and - here's a current schematic:
(If it's still blurry after you click on it, right click on the larger image and select 'view image' in your browser to get even closer to the original. )
27934-0


dfj
Fave Switch manus: IBM, Topre, Matias, ...

Offline AKIMbO

  • HHKBro
  • Posts: 1778
  • Location: Tennessee
  • Know Topre, Know Peace. No Topre, No Peace.
Re: Beamspring USB
« Reply #37 on: Sat, 13 July 2013, 07:16:19 »
Wow....just saw this project.  Looking excellent. 
Mkawa Beta SSK | IBM SSK | IBM Model AT F | IBM F 122 | IBM Unsaver | LZ-GH (62g ergo clears) | HHKB Pro2 Type-S | HHKB Pro2 | Realforce 87U-Silent (55g uniform) | Leopold FC660C | Omnikey 101 (blue alps) | Kingsaver (blue alps) | Zenith ZKB2 (green alps)
| KBD75 (box reds)

Offline mkawa

  •  No Marketplace Access
  • Posts: 6562
  • (ツ)@@@. crankypants
Re: Beamspring USB
« Reply #38 on: Sat, 13 July 2013, 09:39:05 »
dfj, if we were to do a self contained capacitive switch, do you think you would need an opa on _every_ switch? or do you think we could get away with a tiny FET?

to all the brilliant friends who have left us, and all the students who climb on their shoulders.

Offline dfj

  • Posts: 171
  • Location: Canada
  • Visit our irc: #geekhack on libera.chat!
Re: Beamspring USB
« Reply #39 on: Sat, 13 July 2013, 11:52:03 »
Give Parak, Soarer, dorkvader, a poke - they are also thinking on the module issue.
  Making cap boards act like conductive boards (e.g. as with hall-effect modules) is madness imo - since the advantage of cap (nkro scanning) is lost if you sense locally - might as well figure out a M-style module instead. The feel of an F will be different if constructed from different materials, e.g. more plastic in modules, rather than plastic sandwiched between steel, as the normal F.
  To make a module that was easier to install, but still let a pcb underneath handle the scan is roughly what other folks are looking at.
 Personally, I'm happy with the F-barrels as modules the way they are - I guess other folks aren't. :p

What is your goal with the module? Different goals result in more and less junk that might be needed to stuff into it - e.g. very free-form layout might well require a diode and keyswitch in a module. ease of assembly might only require a module which could capture the heel of an M/F flippie, to make it way easier to manage the assembly of beasts. If you want to make M/F keychains - then it also might be nice to stuff sense into the thing, as well as an LED for that matter. :)
   What might work, is an amazing number of things - what is reasonable - this depends on yer goals. :)

interested,
dfj

Fave Switch manus: IBM, Topre, Matias, ...

Offline mkawa

  •  No Marketplace Access
  • Posts: 6562
  • (ツ)@@@. crankypants
Re: Beamspring USB
« Reply #40 on: Sat, 13 July 2013, 17:18:52 »
Quote
To make a module that was easier to install, but still let a pcb underneath handle the scan is roughly what other folks are looking at.
yah that's kind of my feeling on the way forward too. the problem is that it's so damned hard to make new cases and pcbs for a true F style sense circuit that it's almost practically impossible. to get it to work on a DIY or hobby basis you'd have to require so much weird stuff from the user that it wouldn't be feasible...

basically, the very high-level goal is to duplicate the F feel _as much as is possible_ with a significantly simpler design.

anyway, tons of food for thought here. BUT we have to be able to hand-build arbitrarily sized M-designs imo before we (meaning ron, the sskr team, wcass, etc.) can really bite into a modernized F.

to all the brilliant friends who have left us, and all the students who climb on their shoulders.

Offline dfj

  • Posts: 171
  • Location: Canada
  • Visit our irc: #geekhack on libera.chat!
Re: Beamspring USB
« Reply #41 on: Sat, 13 July 2013, 20:00:38 »
Quote
BUT we have to be able to hand-build arbitrarily sized M-designs imo before we (meaning ron, the sskr team, wcass, etc.) can really bite into a modernized F.

True to some degree, but with multiple groups of folks attacking the sense and layout issues of the F, the mech/feel side, and the cases, I am pretty excited about the rate of progress.
  There will be a combination of folks' efforts to produce a modern layout beast sooner or later - sooner rather than later to the degree that people get excited enough to share the secrets they've discovered publicly. :)
  (yeh, my excuse is always that my code is sooo ugly, I 'just need to tidy it up a bit more' before I release more...)

'just a bit more tidy'
dfj
Fave Switch manus: IBM, Topre, Matias, ...

Offline mkawa

  •  No Marketplace Access
  • Posts: 6562
  • (ツ)@@@. crankypants
Re: Beamspring USB
« Reply #42 on: Sun, 14 July 2013, 07:44:31 »
take a random sample of the code on github if you need to reassure yourself :))

to all the brilliant friends who have left us, and all the students who climb on their shoulders.

Offline xwhatsit

  • Thread Starter
  • Posts: 297
  • Location: NZ
Re: Beamspring USB
« Reply #43 on: Wed, 14 August 2013, 21:21:15 »
Now have a flat-mounting method which will fit inside 3278s without needing an adapter board or an unobtainable 90° connector. Ugly but effective. Next job is a controller for Displaywriters.

31778-0
31780-1
31782-2
31784-3
31786-4
Beam spring IBM 5251 (7361073/7362149) & IBM 3727 (5641316) | Model F IBM 122-key terminal & IBM PC-AT 84-key | Model M Unicomp 122-key terminal | Cherry MX Blue Leopold Tenkeyless

Offline poxeclipse

  • Posts: 171
  • Location: Toronto, Canada
  • Hit me with music ... yes, me friend
Re: Beamspring USB
« Reply #44 on: Sat, 17 August 2013, 11:06:33 »
Now have a flat-mounting method which will fit inside 3278s without needing an adapter board or an unobtainable 90° connector. Ugly but effective. Next job is a controller for Displaywriters.

(Attachment Link)
(Attachment Link)
(Attachment Link)
(Attachment Link)
(Attachment Link)

Have 3 display writers for IBM 3178 waiting. I'll watch. Thank you.

Offline xwhatsit

  • Thread Starter
  • Posts: 297
  • Location: NZ
Re: Beamspring USB
« Reply #45 on: Sat, 17 August 2013, 21:27:27 »
Are they actual beamspring Displaywriters or the wee Model F 3178s which had the same layout? Model F controller will necessarily have to be a bit different.
Beam spring IBM 5251 (7361073/7362149) & IBM 3727 (5641316) | Model F IBM 122-key terminal & IBM PC-AT 84-key | Model M Unicomp 122-key terminal | Cherry MX Blue Leopold Tenkeyless

Offline poxeclipse

  • Posts: 171
  • Location: Toronto, Canada
  • Hit me with music ... yes, me friend
Re: Beamspring USB
« Reply #46 on: Sun, 18 August 2013, 07:30:46 »
Are they actual beamspring Displaywriters or the wee Model F 3178s which had the same layout? Model F controller will necessarily have to be a bit different.

Not beamspring. I thought you were referring to Model F, but it will happen, I hope.

Offline ch_123

  • * Exalted Elder
  • Posts: 5860
Re: Beamspring USB
« Reply #47 on: Sun, 08 September 2013, 08:29:19 »
The Model F displaywriter and the 3178 keyboards are quite different things:



« Last Edit: Sun, 08 September 2013, 08:33:03 by ch_123 »

Offline Oobly

  • * Esteemed Elder
  • Posts: 3929
  • Location: Finland
Re: Beamspring USB
« Reply #48 on: Mon, 02 December 2013, 02:48:40 »
Has anyone done some measurements on Topre switches yet? I suspect that designing a custom PCB and controller for Topre switches is a bit of a headache, but would like to give it a bash at some point. Ultimately I'd like to make a Topre version of my ergo board, but we'll see how things go step by step.
Buying more keycaps,
it really hacks my wallet,
but I must have them.

Offline mkawa

  •  No Marketplace Access
  • Posts: 6562
  • (ツ)@@@. crankypants
Re: Beamspring USB
« Reply #49 on: Mon, 02 December 2013, 03:38:12 »
have either of you looked at the RS08 and HC08 series of freescale MCUs? they're basically m6800s with stuff on them. claimed ADC read is 2.5us with compare. they carry one ACMP per core but it can be tied to a pin per cycle. increasingly unhappy with atmel's 8-bit offerings. far too many ISAs, too few features, too few pins. the only advantage of atmel's offerings is the arduino and teensy libraries, but most mature applications don't end up using much if anything out of the libraries (see: RAMPs/mightyboard application MCUs and the code that actually runs on them these days).

to all the brilliant friends who have left us, and all the students who climb on their shoulders.