Anyone interested in an ADC-based capsense controller?

[DMA]

ADC-based means noise immunity, per-key autocalibration and ludicrous scanning speed (one column in about 15us - make it 20 with other keyboard tasks - times 32 (can only scan odd/even rows at the same time to keep the crosstalk down) = 1.5kHz scanning rate for the 122-key model F. Beamspring users should get about 1kHz (or 2kHz, depends if crosstalk is as bad as on XT keyboard) - don't have any of those around though. But the scope is not needed for testing - so this should not be a problem.

It's built on a $10 cypress prototype kit with zero additional parts (well, wires/sockets and USB cable are extra parts, but still).

I'm currently testing it on my XT keyboard and about to start testing on 122-key one I've recently got.

I'm using tmk_core. hasu will probably not approve the way it's integrated into PSoC creator's project, but I plan to clean up a bit (cypress' IDE cannot into makefiles - at least I can't make it to do that yet - hey, I'm only using it for a week!)

If there's any interest - I'll try to make the code less hairy and find a way to publish it in a decent way (psoc creator produces some dreadful binary stuff - need to somehow convert it into more readable form so that diffs are possible.)

If not - well, it will save me some days making it decent and writing docs

[Muirium]

When you say interested, you mean "anyone want this shipped in the mail?" Because in that case: sure!

I'm being facetious, but I do so to make an earnest point. For every person who can understand code and help you, there's many more who want the product but can't code for shit. I'm one of them! So don't mistake a potential lack of answers for comprehensive disinterest. There's more than one audience out there.

As nontechnical as I am, I do however recognise the value of individual threshholds. Xwhatsit's controller could sorely use those for much of the vintage hardware we use it on.

So, are you thinking of doing Bluetooth?

[Halvar]

Sounds awesome! Definitely interested in trying it! I have some Model Fs, an FEXT (F'ed Model M) and Beamspring boards that I can try it on. I might be able to help with coding, too, if time permits.

I'm sure a controller based on $10 off-the-shelf hardware that can maybe even do more than xwhatsit's would definitely be most welcome to many people here.

What prototype kit did you use?

[DMA]

@Muirium it's a bit too early for "shipped in the mail". "Interest" in this case defined as "should I even publish that or I'm the only one interested in that?"
It actually started with "I want a capsense controller but I'm too cheap for $40 xwhatsit's one. But hey, there's a promising $10 kit with some analog parts!" If I knew that there's $4 CY8CKIT-049 - it would even be $4

Bluetooth should be possible with CY8CKIT-142/143A - but those are not as convenient to flash - you have to have a separate programmer and I'm not sure KitProg will do. Also I'm a bit worried about battery life - means "need to experiment with lower CPU frequencies".

@Halvar the kit I'm using is http://www.cypress.com/CY8CKIT-059. Any psoc kit w/SAR, USB and enough GPIOs should do, I now think.
Not much coding there - tmk_core handles practically everything, and the matrix scanner is literally
* write 1 bit to control register to untie rows from the ground
* write 1 bit to columns register
* tell ADC to start, wait till it's ready,
* tie rows back to the ground
* reset columns
* wait a bit so rows are completely discharged.

[Muirium]

Heh, like I said Dima, interest comes in different forms. You have something with great potential here.

What makes Xwhatsit's controller so good—besides for pioneering the return of Beamsprings and Kishsavers, outright—is his fancy, pretty intuitive GUI for setting them up and customizing, plus the fact he built the controllers themselves as a product for lazy asses like me. Even something as simple as hooking up a module like a Teensy to the edge connector these boards use is dauntingly difficult for nontechnical sorts like me. We want Lego level simple! And that's where the most interest of all lies.

Re: power saving, I've heard the key is to dynamically vary the scan rate. Let the controller race to sleep. The Bluetooth side of things is already highly power optimized, so it's down to us to keep the keyboard side of the controller as efficient as we can. Slower peak scan rate is one way, for sure. No need to tempt us with 1 KHz response times when we're more interested in feeding that through comparatively laggy wireless! But the real savings are in slowing down and down again when a second, or a minute have gone by without human input on the keys. And besides: these boards have plenty of case space for cramming full with battery packs!

[Halvar]

Ordered and excitedly waiting for instructions.

I'm not sure yet on how you boiled capacity sensing down to a single ADC conversion without additional hardware here. Are you using the SoC's capsense capabilities? Are they fast enough? (I should probably read the data sheet before even asking that...)

[DMA]

Muirium got it. Well, it would be a long time before this comes in that particular form. Sorry for that. Maybe if Ellipse makes another production run of his new model Fs with this controller..

Halvar I do not use capsense capability - from what I've read there will not be any multitouch even in the mutual capacitance mode - unless you want to emulate the touchpad, and then you'll have to make sense of touch events you get out of the capsense module.
May be I didn't dig deep enough into docs tho. That datasheet is huge, and there are tons of other datasheets - for every component PSoC Creator supports. They also have LOTS of actually useful code examples - which also have documents explaining their operation.

I'm using scanning SAR ADC, which is a standard component from the library.
It is possible to use the delta-sigma ADC the chip has to make a scanning one, but one has to assemble it from analog mux + ADC + LUT + timing blocks. There is even a code example for that, but it's quite complex.

I'm driving the column high then measuring voltage on the rows - like xwhatsit's controller does.
Difference is he only measures relative to the threshold which is set per-column, and I have a luxury to know the actual voltage on every (other) row which will allow me to recognize every intersection in the matrix separately.

I also have the rows tied to the ground most of the time, so that charge doesn't accumulate when I'm not measuring it, and PSoC5 tolerates up to -0.5V on GPIO pins. So I do not need resistive dividers - helps to retain the tiny charge in addition to reducing the BOM.
ADC itself has high input resistance, so I have approximately square wave on the ADC input - at least there's a shelf and it stays there long enough for ADC to measure it.

[Halvar]

Brilliant. Seems simple enough with these amazing chips. Looking forward to testing it.

[Ray]

So, the cypress kit is all you need to connect to the capacitive matrix of a model F and you can get a working usb-protocol out of the kit?
If that is so, that's awesome.
I am interested in looking into it, but when I look over my desk I really should finish other stuff first

[hasu]

nooice work!
I also got this today from local store.


I already got my pants off. Hope to get your code and instruction before I catch bad cold!

[alh84001]

Guys, do you think something similar could be done with Cypress PSoC 4 (a friend has a couple of them lying around, collecting dust). It's a 32-bit Cortex M0 system, and doesn't have USB connectivity, so I thought about using it for sensing and outputting PS/2, and then using any other converter to do the job for PS2<->USB.

I guess it all depends on how hard would it be to cut out the USB output from tmk and plug-in code to output PS/2. Probably not worth the effort, but still, makes me kind of curious.

[Halvar]

I'm ready, too. Didn't peel any clothes off yet though.

Don't let Mu's Steve Jobs impersonation scare you off!

PaperCamera2016-05-25-21-32-34.jpg (136.37 KiB) Viewed 8643 times

[Muirium]

My Steve impression involves driving you to the mountains, heading on up some peak, perilously close to sundown, and then making certain demands about your project…

[DMA]

That got escalated quickly. Didn't count on you guys getting the kits by this time.
Sorry to have you waiting.

I've got to the stage where the controller is told to reboot when "reset" key is pressed on a keyboard (and not the other key). It's not very stable - I'm comparing to the fixed value which is quite close to absolute maximum seen - but it works after a couple of seconds holding that button down

I felt it's the time to get some debug info out.
You see, when I wrote the PoC, I had my debug printed on a 16x2 character LCD attached to 2.0..2.6 (don't try to attach to any other pins, btw - component just won't work, spent 3 hours figuring that out back then).
It looked like this - https://www.instagram.com/p/BFu7-Ifgru4 ... uQxv7wOU0/ and I was happy with it.

You guys probably don't have one - and when solder the kit to the keyboard, you won't have much contiguous pins left: https://www.instagram.com/p/BFxzMOJArsF ... nF2-O7-00/ (don't make my mistake - don't solder the kit so that button and led are facing the insides of the keyboard!)

So I feel obliged to make at least hid_listen work before I publish it. Because all you have on this board is one blue LED, and that's not very useful, debugging-wise. And I had to disable hardware debugging - can't find 2x8 contiguous pins otherwise. Other option was to desolder one capacitor (3.2 has 1uF bypass capacitor connected to it), but I'm against irreversible changes.

I'm currently banging my head on the wall getting hid_listen to work. Getting "Device disconnected, reconnecting" 100 times a second. USBpcap shows the packets flowing in, but they seem to contain garbage. If this sounds familiar - please tell me what it is and how to fix. The code that sends the data is the same I used in ADB-USB converter and it works fine there.

alh84001, this can be done on PSoC4 (It has one SAR, that's enough). You can even make it in a single device with those $4 kits - the scanning code would run on PSoC4 and talk via UART to the KitProg, which will provide USB (Yes, KitProg can be reflashed to be anything you want it to be - it just doesn't have as many GPIOs. I now have two ADB-USB converters made from those - one of which is used with this very keyboard - I can share the project.). I would make PSoC4 just a matrix scanner - this way it's resembles the original controllers more, kkkk.
If you don't have that kit - changing the protocol to ps/2 in tmk_core is relatively easy. It has "host driver" interface which contains 5 functions - for setting leds and sending keyboard, mouse, media, system and I forgot what.

What worries me more is that properly adding support for the new platform requires modification of the core files.
hasu, since you are here - can you please get this more modular? Something like what's done for delays - it includes wait_api.h as a fallback and I just had to put that file in proto/PSoc5 and quite happy with the results.
I can, of course, add more #ifdefs and submit a pull request - but it would be nice if one can just use the core repo without touching ANY files to add a new platform.

Sorry for making you wait, gentlemen. Didn't anticipate so much enthusiasm.

PS: Can't dedicate more than 3h on weekdays, unfortunately. So, should have something by Monday.
Worst case the debug will come over the keyboard interface - like, it will actually be typed by the keyboard - because that I already got that working and can basically copy-paste.

[hasu]

Saw the video and looking forward to your work more now.
But seem like I will have to get clothes on and learn PSoc before try it. Not in a hurry. Take time!

What worries me more is that properly adding support for the new platform requires modification of the core files.
hasu, since you are here - can you please get this more modular? Something like what's done for delays - it includes wait_api.h as a fallback and I just had to put that file in proto/PSoc5 and quite happy with the results.
I can, of course, add more #ifdefs and submit a pull request - but it would be nice if one can just use the core repo without touching ANY files to add a new platform.

If you have some ideas open issue for this on tmk_core repository. More modularity would be nice.

[DMA]

PSoC is really easy to learn. Tons of actually working examples right there in creator.
Normal application to bootloadable one is easily done in an evening, for example.
Or this very prototype in a form displayed in the video.

USB component is the only tricky thing I've found. Mostly because you can't just type your HID reports in a file, you have to use GUI. Also there's no such thing as bidirectional endpoints, and because of that you have to have two endpoints in the keyboard.
Also I couldn't get the keyboard with extra and system keys to work on OSX from the first try - ended up removing that interface.
Also had to set USB ID to Apple ANSI keyboard - this way it doesn't show the keyboard configuration window (which did not go away whatever I do )

Also the important advice which I cannot write in letters large enough - look at the schematics before you even think of connecting something to the GPIOs. P0, for example, has 3 of it's pins have external capacitors between them and the ground. Which only becomes noticeable if you actually try to do something at higher frequencies or involving small currents. I had a very stable 0.1mV at the row 2 (lower left in the video) and tried to figure out why for a couple of hours. Went as far as scraping the mask from the sense pads on that row.

OK, back to USB debugging.

[DMA]

..looks like calibration is not needed 8- ]
I mean you just need to fire all the columns to detect the dead ones and get the idea of the noise floor, and you're set.
With 8 bit resolution key up is <3 (sometimes 4), key down is 8-9.
Crosstalk _is_ there when scanning all rows at once, but column readouts look like
1-1-1-3-8-1-1-1 (row 5 pressed)
1-3-8-3-8-1-1-0 (2+4)
2-4-11-10-8-1-1-0 (3+4)
10-4-9-3-8-1-1-0 (1+3+5)
12-11-9-4-8-1-1-0 (1+2+3+5)

300us per matrix scan. Yes, _u_s.

Time to bring the tmk_core in - for matrix state detection etc etc

[Muirium]

Analog sensing is one of the best things about capsense. Any interest in a user-variable trigger for key actuation? I don't mean for calibration, I mean for actual actuation height control.

It doesn't make much (if any) sense on IBM because those boards had click mechanisms to make the key state as binary as possible. But on Topre and some other capsense boards, the sliders are more linear and so being able to play with actuation height becomes quite desirable. Especially on the fly! And especially per key, too.

[Ray]

As Mu said, it doesn't make sense for IBM boards.
And even if I wanted to drive a Topre board with this, I would say focus on one thing after the other. Analog sensing might be nice (with next to no tactility in the switches), but certainly isn't a feature that is much sought-after here.

[Muirium]

True. I mention it early because I'd like to keep it at the back of people's minds. Don't want early design decisions to inadvertently rule this out in the distant future.

Note: I am **NOT** talking about providing the host computer analog inputs, like a game controller. That's a whole other game to play.

This is more what I am after:

Mmm delicious Knobforce

Knob nice but not essential! The ability to vary that threshold, while typing, is my thing. Ideally for different keys, but one setting across the whole board also makes sense.

[DMA]

Hehehh. When you're looking at the key 1000 times a second - it's much less binary, let me tell you!
Note to self - figure out if debouncing is needed.

As for topre - well, looks like some tuning tool a-la xwhatsit's tool is needed.

[tigpha]

Hi DMA, I'm another spectator watching this thread. I have a few IBM Model F rebuild ideas that are missing a suitable controller. This little gem from Cypress might fit the bill very nicely. I don't have the experience of Sensei Hasu in coding such things as TMK, but I am a professional telecoms systems programmer, and keen to try new stuff.

[DMA]

@tigpha where to read about your ideas? I am also thinking about putting those model F keys into something more modern in layout. And cheaper to make. Cheaper and simpler to make, mostly. Don't have my own metalworking shop, you know.
The controller was a first step

[tigpha]

So far, only ideas and drawings.

The concept is to reuse parts salvaged from an IBM PC-XT, cut down to 60% format, and pierce a few more holes to accommodate the slightly modified layout. If the prototype satisfies me, I will ask a laser cutting shop I have tried a while ago to help with a final design of barrel plate and backing plate.

I'm still considering options for making the PCB. Maybe I'll follow the same path as Wcass, and order mine from PCBWay. I was thinking of etching the PCB myself, but it seems to be a lot of effort.

I've managed to revive three IBM 5291 "Bigfoot" terminal keyboards but I'd love to build a 60% Model F from either one of my PC-XT keyboards, for easier transportation.

You mention debouncing the keys. I think that you will need to consider this, because although one of the Bigfoots needed no debouncing, the other two did, to a small degree. Soarer described an elegant algorithm that implements debounce without adding any latency.

[DMA]

I actually just had an idea about debouncing - with 2 scans per ms I'll probably be able to see the key approaching the PCB. Need to test tho - that means I'll need some buffer internally. USB I/O slows things down if there are lots of transfers.

[DMA]

Need a name for the project.

Since hid_listen doesn't work for me and using wireshark is quite tiresome (usbpcap pops up UAC window _every_time_, also reading the output is not what I call a pleasant experience) - downloaded xwhatsit's util, compiled it and is about to chop hid_listen into it. Can't leave it as "ibm-capsense-usb-util.exe" - would be confusing as hell.

So I need a different name and I'm currently low on creativity - remembering C and learning embedded programming drained that pretty severely, you know.

"boxwood" is the only thing I can muster right now - because cypress chips and "boxwood" translated to russian is "самшит" which just sounds awesome.

Upd: or make it support both IBM and topre (and MC7004) and call it "common sense".

[DMA]

Found "original IBM model F" documentation semi-accidentally. xwhatsit got it mostly right!
There's MC 7004 russian keyboard, which was copied from the model F.
And it has a manual in Russian with schematics, functional description etc etc.

It was scanned and put on the internet in 2009. In DVJU format. Created somewhere around 1980 - no (c) on it anywhere because "intellectual property" is not something that existed in USSR. Scan quality is abysmal.

Soviet electronic industry couldn't into IBM6014810 (..and small-batch ICs in general) so they made it from analog mux, transistor amplifier(factory-trimmed), comparator and a flip-flop - because 8049 is too weak to read things when it's forming the strobe.
So, no per-key calibration. Not even per-row. One potentiometer is all there is.

[tigpha]

I've had a look at the Cypress product documents. It certainly mentions CapSense® a lot, and Cypress also offers prototyping kits with capacitive keypad arrays. Farnell sells the CY8CKIT-059 PSoC® 5LP Prototyping Kit for £7.30 plus £3.95 handling charge for orders less than £20 (boo!).

Darned it, for a few pennies over a tenner, I might just buy one and start hacking hardware and software.

How do I get started? Cypress offers tools for MS-Window, but I'm utterly Linux/Unix here, no MS-Windows in my code workshop...

[DMA]

tigpha that's the main problem with cypress - all their tools are windows-only

Even the programmer. Doesn't run under wine, doesn't run under mono. Lots of frustration on the forums. Cypress guys apologize, but it looks like the Creator is such a mess internally that it's unportable.
Even the PSoC programmer is windows-only.

KitProg sources are available though - so flashing can theoretically work using other host OS. There's also SWD and JTAG, of course.
Compiler is GCC, external compiler can be used - but there's not much point in that, for actual SoC configuration you must use the creator.

There's freeSoC2 ($50) and sparkfun even ported arduino IDE to it - but "to unlock it's full potential you'll need to use PSoC Creator" in their own words.

So yeah, windows VM is the only way right now - at least for initial configuration. Sorry about that.
Bootloader host seem to be portable though - so flashing already-built firmware should not be a problem.

[tigpha]

Hi DMA, That's unfortunate. No need for you to apologise, it's not your fault in any way.

I had read the forum post from someone trying to program the PSoC from a Raspberry Pi, which sounds exactly like the kind of engineer that Cypress really ought to be selling to, but no: "We have not yet tested the KitProg Mass-storage with Linux based OS.The Mass-storage firmware in Kitprog is not yet ready for Linux OS."

The "not yet ready for Linux" might be a vague hint that Cypress is working on mending that huge glaring "feature"...

In the meanwhile, yes, it looks as if I might have to buy a cheap used laptop/PC off eBay just to get MS-Windows exclusively for KitProg. That makes the project much more expensive than the £10 I was contemplating earlier.

I wonder if KitProg is able to run under ReactOS?