Anyone interested in an ADC-based capsense controller?

[DMA]

kitprog mass storage programming mode is for devices with f-RAM. Should actually work in linux - copying files to USB flash drive is a thing that Linux can do.

ReactOS.. don't know, might work but I wouldn't count on that.

There are evaluation windows copies which can be run in virtualbox. 90 or 180 days, don't remember. Your laptop almost certainly has that sticker with windows serial on it - that serial will work with windows 10. There are ways, legal ways.

[tigpha]

Yup, I think that I have found the official VM images at Microsoft. That might be just enough to enable me to do something useful with KitProg. The release notes recommend that "you could take advantage of your virtualization platform’s snapshotting capability so that you can start over with a fresh VM at any time and not have to worry about the guest operating system running out of trial time."

I'm not very confident yet that I'm able to participate much in the source code side, at least not until I've sorted out the MS-Windows and KitProg conundrum. But I can certainly assist by building a keyboard to try out the CY8CKIT-059 Development Board and binary images you are willing to share.

And thanks for taking a look at the siXTyPerCent thread. I agree that the metalwork is not trivial. I have a few ideas to try. One of them is to use a thinner, more springy type of steel for the perforated top plate, and to hold the steel sheet in a cylindrical shape inside a sturdy case. Also, perforate the holes in the sheet using a galvanic etch method. Hmm. I think that some images will provide a better explanation of what I have in mind.

[tigpha]

Well, I tried numerous VirtualBox appliance images from the Microsoft website, and they all failed. I shall try getting a PC from eBay instead.

[DMA]

"failed" as in?

[tigpha]

Well it seems it was a "fat fingers" or "need sleep" failure: I tried again this morning with a fresh download of IE9.Win7.For.Windows.VirtualBox.zip, and it booted up in VirtualBox, and I was able to activate the 90 day trial period. No idea what has changed over the last few hours.

Installing KitProg is now in the cross hairs...

[tigpha]

It looks as if I'm ready to rock: PSoC Creator 3.3 Service Pack 2 is installed on the MS-Windows-7 virtual machine. Next step is to get the hardware, and discover if VirtualBox can expose the device to the guest O/S. So far, except for the brain-burp yesterday, progress has been smooth and swift.

[alh84001]

Out of curiosity, have you tried running it under Linux using WINE? If you can't expose the hardware to the guest, that might be the way to go.

[Halvar]

You might need to install the (closed-source) Virtualbox Extension Pack on your host to use the host's USB ports, especially if you're using an older Virtualbox version (<5.0).

[tigpha]

It looks as if the VirtualBox version I'm running is 4.3.36 -- I hope that the PSoC Creator is only required to recompile source code, and that there is an alternative method of uploading the binary images.

There is a hint that the device can support "mass storage mode" but I've only so far seen a forum post that mentions this, and a Cypress knowledge-base article mentions this as a feature to be implemented by the customer.

Perhaps the mass-storage mode will serve as a configuration feature of the controller? That would be very handy indeed, to upload keyboard layout mappings with a simple file-write over USB to the keyboard.

[DMA]

Damn windows 10. I've created a Qt application (teach yourself C++ in 2 days!) only to discover that hid_read always returns 0 bytes on my machine.
It enumerates, it opens the device, but reading just doesn't work. If it's blocking - it just hangs, if non-blocking - 0 bytes are read.
AAARRRGH.
I see you guys almost finished making your own tho

2.5 hours later just stopped banging my head on the wall and admitted failure.
Installed visual studio, compiled MS HID samples just to see that the device sends the reports in a wrong way so that examples don't see it while they see the apple keyboard connected to the same machine at the same time.

Changed PID&VID&Usage page&usages to the media part of the apple keyboard - and lo, messages are received!
Simple test, 30 minutes in all. Why, why I didn't do it in the afternoon instead of trying to bruteforce?

Seems like I'll need to review the USB part. I suspect it's something to do with the fact that USB endpoints in LUFA seem bidirectional while in USBFS component they are strictly unidirectional. It's definitely not descriptors - they are copied from tmk_core LUFA protocol, so must work.
Oh the irony - cypress' HID example is a mouse. It only sends data one way. I suspect now it isn't a coincidence

---
Problem wasn't USBFS, it was DMA. When you send USB message to the host - you want to be EXTRA sure that it matches the length you declared in the HID report. Otherwise host will drop it. I was passing actual printed message length to USB_SendOutEP().
So I now have the debug print - and the skeleton for the configurator util which prints debug messages from the controller (though it's written in Qt - fight for statically linking the .exe is still ahead of me).
It's finally _somewhat_ usable. Will post to github today/tomorrow evening. Sure, you need PSoC Creator (for firmware) and Qt+Qt Creator (for the util) installed to use it - but if you're motivated enough, you can use it!
(Also need to check - may be hid_listen started working. That way QT will not be needed).

[DMA]

OK, here's the version that can display ADC readouts using it's utility.

https://github.com/dmaone/CommonSense

It doesn't send any keys - though it registers as a boot keyboard(not sure about boot flag tho. May be I removed it in frantic attempts to get the console to work)+extra keys.

Can serve as a bootloader + scanning ADC example, at least. Also some horrible, horrible Qt example.

Off to bed, it's 00:17 here already. Can finally sleep without having nightmares about Qt.

[alh84001]

Nice to see this progressing.Keep up the good work!

[Ratfink]

Psst...fix the license comment in your code to match the license under which you released your code!

[DMA]

Ratfink, you're talking about PSoC code?
Yeah, should do that. But that one is obviously a boilerplate and the LICENSE file in the root dir should cover it, no?

But if you're trying to tell me the code needs cleaning up - I agree 150% or may be even more. Just too tired

[alh84001]

These just arrived


I won't have time to play with them until the weekend though :/

[DMA]

alh84001 well, I've discovered today that I forgot to upload the bootloader to github
It _is_ easy to recreate, but still. Fixed that.

In other news I'm thinking now of storing keymaps in eeprom (turns out the kit has 2K bytes of it, rated at 1 million write cycles). By "thinking" I mean "writing the data structures, trying to understand matrix interface of tmk_core and figure out if I can get away with runtime-defined row and column counts".
With 1M write cycles (100K@55C average ambient temp. 10K@85C) wear levelling is not much of a problem, it seems.

So keymaps and basically every other setting (including rows/cols and scanning mode) can be stored in EEPROM.
But what if EEPROM fails on boot and you only have one keyboard and the host is locked so you can't access the utility to reload it?
I'm planning to use EEPROM as a storage only and have a configurable PANIC button which resets the controller if pressed with modified, but not yet saved, config - to reduce likehood of booting with unusable config.
Should I somehow guard it more, or should I just say "if you're stupid enough to save unusable config, you had it coming" and not care about it more than described above?

In _other_ other news it seems that bluetooth is out of consideration, because most of the battery drain is bluetooth itself. Power calculators look like "OK, the system as a whole will consume 2mA, and bluetooth will consume 20mA (USB is not much better, btw - 10mA in connected state, and suspend is not much less).
Need to check the actual power consumption tho - may be the matrix scan rate will have noticeable effect on power consumption after all.

[hasu]

DMA, thank you for your work and codes!

I didn't try it yet but just checked source code. I might be wrong but I guess your sensing method is using just with digital output pins and ADC, not PSoC specific module or technology. Do you think it is possible to implement the method on other controller with ADC such as AVR or Kinetis? And what do you think of advantage of PSoC against other controllers in terms of capacitive sensing?

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

Great, really fast scan speed. How can you improve resolution of sense, delay after strobing columns affects it?
https://github.com/dmaone/CommonSense/b ... .c#L46-L56



BTW, I was interested in PSoC "Capsense", in particular their "Crosspoint(CSX)" techninque for mutual-capacitance sensing. Though, it seems PSoC5 doesn't support the CSX oddly while PSoC4 does Have you tried CSX before?

[DMA]

hasu, you're correct, I'm sensing it in exactly this way. Enough GPIOs and a scanning ADC (or ADC per channel) should be sufficient.
One PSoC-specific feature I use is analog+digital pins. ADC input is also a digital output in "Open drain, pulls low" mode.
This can be done by connecting GPIO and ADC input at PCB. Don't know if other MCUs can set drive mode of the pin though.

Delays were there to give the signal time to settle. Seems they're not needed (probably because PSoC analog clock has built-in phase offset so this delay is built in) - hence comments.
I plan to implement scan delay trimming via setting ADC to external clock and using phase offset there (it's configurable from 0 to 10 us (or is it ns?)).

If you want to improve the resolution - switch 8 bits per sample to 12. Then your "12" will become 200. Or make an external Vref source. Or go differential, but that would consume another 8 pins. There are ways. Not worth it, IMO. Probably for detecting column skips after restart (ADC is configurable on the fly).

My initial idea for the controller was also using capsense. But I've read the manuals first and it seems that you either route every button separately or suffer 1NKRO. Or use the module in touchpad mode with multitouch, layout the sensor grid (not under the keys - just a rectangular grid) and fight with converting touch events at coordinates X:Y back to keypresses - so I did what current does, used the path of least resistance

After I did the prototype, I've found elektronika MC 7004 (soviet model F clone) technical manual. It has schematics and theory of operations. Turns out they use the same method I "reinvented", only they use amplifier with ~400x(tunable at the factory with a potentiometer) amplification feeding a comparator instead of the ADC.

Update: Though sensing actual keys probably outside of capsense domain, one can do volume sliders and touch detections using it. One of the ideas would be to sense hand presence near the keyboard and go into reduced power mode if not detected. (It is not clear if that will bring any power savings though - capsense component consumes 8mA, while difference between 3 and 24MHz CPU is 5mA.). It looks from the power calculator that there is some 80uA mode. Not sure it's useful tho.

[DMA]

Finally, some results.

https://www.instagram.com/p/BGN_7_8grs8 ... _wm5Mmwk0/

Shows matrix readouts on desktop. debug output is controlled from desktop in real time.
This means control protocol is working.
Decided to implement full config upload/download only to reduce number of commands in protocol.
Stepped into a pile of poo with bit fields - this actually played no small role in the above decision. Will pack on EEPROM write.

As you can see, row 9 is flickering. I think I've cold-soldered it.
It's actually good - this one will be a testbed for the noise immunity/bad contacts scenario
(Edit: it flickered because I mapped matrix columns 7 and 8 to the same displayed column. No flicker of any kind now.)

A word of warning - USB sockets on those prototype boards are quite fragile, almost torn it off on mine. Luckily I have four more - and the victim still works.

PS: Qt sucks. C++ also sucks, can't decide what sucks more.
Two IDEs simultaneously, different shortcuts, C in one, C++ in another, and python in vim at work will make me go insane sooner or later.

[lot_lizard]

This really is such brilliant work. I am beyond impressed. I think if others really understood what you were accomplishing here, and the possibilities of it, this would be much more widely followed.

PS... CommonSense is a perfect name

[Muirium]

Don't worry, Lizard, I think a lot of people don't really "get" controllers until they see something special revived or created *because* of one. Xwhatsit's achieved fame because it rescued Beamsprings, and then the oddball Model Fs like the Kishsaver family. Boom! Seeing the final result is what gets people excited. Besides the deep divers like us in this thread!

CommonSense is indeed a brilliant name. And I think describes my opinion of putting this controller into the heart of your Model MF project, precisely!


@DMA: How would you like to test this on a community-designed PCB? I've got an XTant PCB sitting around… at my brother's in America. Someone closer to you may well have something spare, too. Actually, where in the world are you?

See, I think your per-key threshold is the silver bullet to getting rock solid custom Model Fs. So let's get together and make it!

[DMA]

Looks like per-key threshold is not really needed, and interlaced scanning also doesn't worth the effort.
SNR is at least 4, signal in adjacent channel is at least 3 times weaker..
I will do those things - there's enough RAM and processing power for that. But frankly I don't see them used.
I think that even stuck key detection will be more useful than those.

I would like to test it on whatever you guys like to spare for a couple of weeks/months. A bit later, though - I still need to make this an actual keyboard. I've yet to generate the first keypress from this controller.
Just the PCB is not much use though - I don't have a metalworking shop yet to make top/bottom plates for it
Would really like to experience some beam springs for a couple of weeks before they go extinct.

Definitely remember putting the country to profile. But may be it was github. Seattle, US of A.

Since both IBM keyboards I've bought arrived heavily damaged to me - I would advise against shipping. But I can pick it up and bring it back in 1K mile radius. Haven't driven long-hauls in a while.

[lot_lizard]

Actually... If you are game, I would like to send you one of the FSSK/FEXT prototypes (metal version). The timing would probably work out pretty well since it will likely be a month before I have them constructed and comfortable with the results. I believe the 101-key PCB (FEXT) is just an extension of the SSK (I'll study the PCB a bit to confirm that), so it would be ideal for testing "two boards at once".

I am assuming you have an M shell you could throw it into? If you are interested, I'll probably just leave the PCB as-is (no controller), so you don't need to desolder anything. Let me know your thoughts... I agree with Muirium, this has the potential to be a dream controller for the MF project (for several reasons)

EDIT: plus you can give me some feedback. I was planning on putting one together to send across the pond for feedback (mini-tour), and maybe that is just the one I send you after you have worked things out

[Muirium]

A thousand miles, eh? Naturally, my XTant PCB is in a drawer at my brother's place in… drumroll… San Diego!

You just follow the I-5 for a little while…

[tigpha]

Hi DMA, The results so far look really promising. I have enough spare IBM Model F PC-XT parts to reproduce the experiment, except for the PSoC, and the unknown VirtualBox ingredient. I have no excuse really, save for "real life" and "work" and "paying bills" etc...

I agree with your opinion of C++. I used to work in C++ in a previous life, long ago. Bjarne is a clever guy, perhaps far too clever. Or is it a case of "design by committee"?

[DMA]

Fried a KitProg. Well, not exactly "fried", but it's no longer an SWD programmer. Luckily I have five of those and the kit was spared - resoldering it would be a hassle.
Note to self: don't try to connect snapped-off KitProg back with jumper wires.
Almost tore off USB connector from it, though (upd: not almost. Had to sacrifice an old USB mouse to the gods of Buckling Spring. The converter now has permanent connection to the cable).
Note to self: next time disconnect everything from the keyboard plate _before_ moving it.

But made a working "jump to bootloader" function (I was too smart for my own good with the bootloader - should've keep it simple), and emergency stop button - to be able to stop the madness if the device goes mad.

tigpha, that "real life" thing is time-consuming, true dat. Don't feel too bad - I just have a _really_ bad case of flu now, which prevents everything but sitting at home sneezing. No high fever though, so the brain and fingers work. So I suddenly have a large chunk of free time on my hands.

C++ by itself is not bad - python is much more evil, for example. It's just that trying to learn it in 2 days along with Qt makes your brain _really_ hurt.

Muirium, San Diego is not that far, you know. It's just that PCB itself is not very useful without the plates. XT plates will probably not work because of the layout modifications.
But I will go for a bit crazier idea - bond some carbon to the unicomp flippers to see how it works on the sense pad. I do understand that even if that works the springs are much shittier, but I will try to do it for !!science!!

[Muirium]

Maybe kinda oughta almost work. Just be careful not to get that carbon everywhere and make a mess! Fine stuff like that always goes right into my skin and no matter how I scrub, I leave dirty fingerprints on everything I touch for days…

By the way, that XTant PCB does have a corresponding XTant plate and donor XT to go along with it. That includes case, plates, original Model F flippers and springs. Even a nice pad of new foam and Xwhatsit controller to compare with. Besides the caps, which I put on my SSK, the whole kit is ready, I just never had time while I was last over there and wound up with too much group buy luggage to bring it back with me!

The custom plate may be a bit warped though. Doesn't look quite right to me. And I heard it needed some treatment to keep it free from eventual rusting. Sounded like quite a project, so that's why it's in a drawer. I'd rather see it put to some good science, especially if you wind up assembling a working XTant from it with your controller! I've heard Xwhatsit's is iffy in an XTant, which is why I'm keen for this project.

[DMA]

OIC. Makes sense then. Caps.. I have lots of those, I also happen to have a donor XT and the unicomp which will be replaced by The Dreadnought in a week, I hope (Well, it is replaced by AEKII now, but I'm on a verge of bringing the unicomp back. ALPS are mushy compared to the springs ).

San Diego is about 19 hours drive, +2 fuel ups +some food +rest stops makes it a bit more than 30.
So, the Independence Day weekend seems to be a good date. Need coordinates, contact info and a time window Sunday, July 3rd. Would be great if that's a whole day window - long haul trips are a bit unpredictable, hard to commit for a specific hour.

[Ratfink]

I just checked out of curiosity, and holy cow, this microcontroller is expensive. This, combined with the lack of a way to program the MCU on non-Windows operating systems makes me wonder if we should consider using a different chip for this project.

[DMA]

I just checked out of curiosity, and holy cow, this microcontroller is expensive. This, combined with the lack of a way to program the MCU on non-Windows operating systems makes me wonder if we should consider using a different chip for this project.

No wonder - it's top-of-the-line controller. Why put anything less into a one-per-series prototyping kit?
Is $5@50 expensive? Same series, same number of pins, twice the number of ADCs I need. Nothing else is used or will be used in this controller.
To put things in perspective - ATMEGA32U2 which is the heart of xwhatsit's controller is not much cheaper - $3.88@50 - but requires 4 more ICs.

CY8C5266AXI-LP033 will probably be even cheaper, but mouser doesn't know about it. (Just checked - Firmware compiles on it). There are even cheaper ones (СН8С5265*) - but I don't like to be restricted to 32K of flash. Current firmware (no keyboard functions or layouts!) plus bootloader is about 30K. I do think something can be done about it - but I doubt there will ever be even a thousand of those in existence, and saving a cost equivalent of 1 key barrel per device just doesn't worth it.

But. You lured me to the mouser.com away from Qt creator.
$4.87@50 if we're willing to go PSoC4200L and save whopping 13 cents.
Don't see the point downgrading to cortex M0 and 8K RAM though (CPU speed is not a problem - I'm currently running the kit @24MHz). Probably makes sense for unifying platform with BT keyboards (4200BLE hath the bluetooth) - but one still has to explain to me how exactly BT is useful in a 4kg behemoth. Prooobably as a keyboard for a notebook. This has to be a mac though, because normal notebooks have dock stations.