[Done] CommonSense controller - better capsense!

DMA

13 Jun 2016, 22:35

TL;DR: Turns out it's all implemented in kiibohd like 2 years ago - see Scan/DPH/*. Unfortunately, kinetis has CRAPPIEST ADCs I've seen so far, so it didn't go anywhere. That, and the key difference I discovered (a week ago, as of 2016-11-06) that ADC has a sampling capacitor large enough to charge the next sense line and screw up measurements - so I interlace ADC readings with pins shorted to the ground to discharge that damn cap and get stable readouts as a result. This is a trivial change, not hardware-specific.

-=-

In case you're still wondering what the hell this is all about - I'm trying to make an ADC-based capsense controller.
In a way this is continuation of the great xwhatsit's work, with some important differences.

Theory of operation:
If you want to make you want to claw your eyes out know more about capacitors, read it there, in all it's Comic Sans glory. There probably other guides, but it's hard to find one that explains energy storage. It even has pictures - but I have something better. Pr0n.
Spoiler:
This is the circuit simulator for one capacitive key. Click it. Look at the current going back and forth. Press "Any" key, see how the signal changes on the 'scope. You will notice that when the key is pressed, the line returns to zero much slower. It does so, because larger capacitor can transfer more energy from one pulse. But it still does.

"What attracts is to zero?" one might ask. The answer is "load resistance". Increase the resistance and you'll have less decay, making pulses more square. So, if you want to know the key state and you want to use comparators - eventually, instead of measuring just that the peak has occured (it happens every time in the ideal world, btw - the comparator just misses it if it's short enough.), you'll soon find yourself measuring the time signal spends above the threshold, and in the end of it even that doesn't help because the waveform you're looking at exactly matches the driving waveform.

Drag the "Load" slider all the way to the right to observe that firsthand.
You will notice that the wave slowly drifts down. It does so to reduce DC component of the signal - because capacitors effectively block DC. If you click the generator and set duty cycle to 50% - you'll get the perfect symmetry eventually :)

But The Real World is a bit more complex than that. Because in the real world there is a capacitance between the ground and the sense line. It is called "parasitic capacitance".
And this is where things get interesting.
NOW THROW THE REALITY SWITCH. If you are going to do that in a simulator already open - Please drag the "load" slider all the way to the left before that, or you spoil the surprise.

Now try to press any key.
See the difference? That's right, peak height depends on capacitance now. That's because the key charges the parasitic capacitance now (charging capacitor has zero* resistance), and the load discharges it. But the key capacitance limits the amount of energy that can be transferred thru it. Because charge equals capacitance times voltage, and after capacitor is fully charged it doesn't conduct anymore current.
BUT.
If the parasitic capacitance is larger than the key capacitance - key cannot fully charge it. So the voltage on the parasitic capacitance will be lower than driving voltage. Or equal to it, if the key capacity is more than parasitic.

So if you ramp up the load resistance again - you will see nice and square signal, proportional to the key capacity. With large enough load resistance this voltage can be measured at leisure, not involving sample-and-hold circuits or any other complicated stuff. All you need is an ADC and an muliplexor (or a separate ADC for every channel if you want to go baroque).
So yes, essentially I'm using the keyboard as capacitance to voltage converter.
Now, if you press the key in simulator at exactly the right moment, you'll get huge DC offset. To prevent that I'm tying the inputs to the ground when not used. PSoC allows the pin to be analog in and digital out at the same time - but on other devices this can be achieved by connecting 2 pins together, provided the MCU can have the pin configured as "open drain, drives low".

In theory, there's no difference between theory and practice.
You would expect that it would work, wouldn't you? Everything will be nice and smooth, like it is on the XT keyboard (if you cut the row trace and connect oscilloscope to the PCB end of the cut):
xt_rows.jpg
xt_rows.jpg (40.87 KiB) Viewed 4180 times
Spoiler:
Nope. Reality is much, much worse.

You discover it gradually. First, there's this:
monitor-released-explained.png
monitor-released-explained.png (18.13 KiB) Viewed 4180 times
4 on the real key is pure luck. It rarely happens. Unless you start scanning the matrix all the time, about 1k times per second. Then you'll notice that it happens about 5 times a second.

Then you'll notice the amazing signal level connsistency.
monitor-pressed-explained.png
monitor-pressed-explained.png (21.52 KiB) Viewed 4180 times
The "?" key pressed gives off less singal than the lucky key from previous example. Enter gives about as much - but there's a twist, it is noisy as hell. It pretends to be 1 in resting state, but if you're lucky, couple times a second it's 3.
Backspace gives a healthy strong 9. But it has a downside - sometimes it lights up half of it's row. Including F10 and especially F11, which will toggle your browser's fullscreen mode. What a nice surprise.

Then you get out the scope (cheap, USB one) and see that signal levels, indeed, different and nicely square.
key_released.jpg
key_released.jpg (57.87 KiB) Viewed 4180 times
Well, almost. They have those Burj Dubais at the start of the pulse and at the end of it. If you zoom them in, they have classical decaying sinusoidal form. This is called "ringing". RF designers go a looong way to avoid that.
OK, not a problem, just wait a couple microseconds for it to settle and then measure!
key_pressed_explained.jpg
key_pressed_explained.jpg (65.77 KiB) Viewed 4180 times
Nope.

And then you zoom out and see...
teh_horror.jpg
teh_horror.jpg (70.01 KiB) Viewed 4180 times
Teh horror. Those things are everywhere. EVERYWHERE!! But they're short.
Also is looks like they sometimes happen on their own. Look, that's how driving pulses positioned relative to each other in neighboring columns:
adjacent_columns.jpg
adjacent_columns.jpg (55.5 KiB) Viewed 4180 times
(here I remembered that I actually try to scan even/odd lines 4 columns apart.)
Will check tomorrow with different delay configurations - though I know from today's experiments that putting 200 us delay after each column scan does not help. Will probably also post less JPEGy pictures, though don't count on that.
Right now I think about double scanning on the spot and discarding the higher value. Or push the current results and abandon this whole thing.
Or just implement plain old debouncing. It doesn't seem to be needed though.

Sources are here - bootloader, firmware and configuration utility.
Hardware used is CY8CKIT-059 prototyping kit. Since the kit is $10 - there's no GB for building the controller. It's hard to beat $10 price. If, however, project MF is revived or Ellipse will decide to switch controller to CommonSense - there will be custom hardware, too.

Current status:
* feature parity with xwhatsit AND MORE.
Last edited by DMA on 30 May 2018, 16:32, edited 11 times in total.

HuBandiT

14 Jun 2016, 01:25

Just a quick drive-by suggestion without really understanding the situation: would the Microchip PIC CTMU perhaps be of use?

DMA

14 Jun 2016, 03:21

HuBandiT wrote: Just a quick drive-by suggestion without really understanding the situation: would the Microchip PIC CTMU perhaps be of use?
Thank you for pointing me there. AN1375 finally explained to me how all those capacitive touchscreens work and what limits number of fingers recognized at the same time. There's easter egg in there - look at items 47 and 48.

CTMU measures capacity by pumping known charge (known current * known time) into the external circuit and measuring resulting voltage between pin and the ground. Doesn't matter how many capacitors are there - the bigger the capacitance, the lower the voltage.

this one pushes as much charge into the matrix column and measures how much of it got out of the row line. And compares "how much I usually get for this column" vs "how much I've got this time". Doesn't care about absolute values - don't know if it even can figure those out. Most probably not.
But it's simpler. ADC is one of the components of CTMU. Not a central one :)

User avatar
lot_lizard

14 Jun 2016, 03:52

Please eliminate the ? in your title after better :)... You are crushing this, and can't wait to see the results in the coming months

DMA

14 Jun 2016, 05:19

lot_lizard wrote: Please eliminate the ? in your title after better :)... You are crushing this, and can't wait to see the results in the coming months
But how can I know? It may turn out to be be worse than the existing ones!

Also I cannot find how to edit the title. So let it be that way until at least the second controller in existence! :)

User avatar
lot_lizard

14 Jun 2016, 05:46

DMA wrote:
lot_lizard wrote: Please eliminate the ? in your title after better :)... You are crushing this, and can't wait to see the results in the coming months
But how can I know? It may turn out to be be worse than the existing ones!

Also I cannot find how to edit the title. So let it be that way until at least the second controller in existence! :)
I know, and have faith... Stop the silly talk. Hint on the title.... Update the first post and try editing the title.

EDIT:. what you are doing is wicked difficult. Eyes on the prize

DMA

14 Jun 2016, 07:29

lot_lizard wrote: Update the first post and try editing the title.
Done! Didn't occur to me that the post itself is special.

DMA

14 Jun 2016, 10:30

Managed to transfer config to the device. No saving to EEPROM yet. That's for tomorrow.

Almost had to resort to external programmer - changed commands enum and forgot which command code is "go to firmware update mode". Was able to bruteforce it back to the bootloader though.

In other news switched Qt IDE to FakeVim (Yes, I'm a connoseur of ViM) - but PSoC creator doesn't have that and Oh Hilarity. Switching to different editor every 5 minutes is a headache. Staves off Alzheimer, though. At least they say so.

DMA

18 Jun 2016, 09:02

Wireshark sucks. Spend almost an hour staring at the MAGIC - the host sends an empty packet to the keyboard AND IT TURNS ON THE LEDS.
First I thought that the keyboard somehow remembers you pressed caps lock and lights it up when instructed by a host to do so.
But then I connected a second keyboard to my machine and the same empty packets were sent to that keyboard and it recognized the LED status.

And then I tried to search Teh Internetz for this and found ONE post. Luckily the author was kind enough to go back to it after a _year_, literally, and post an update that yes, wireshark indeed completely misses the data stage of control transfers.

And this kind of described at usbpcap site, but in a very vague way. It says it doesn't support split transactions - and it seems that control transfers consist exclusively of those.

It is a first time wireshark fails me. I feel betrayed!

Luckily, HID reports seem to be dumped intact. (I'm doing all that because I've accidentally noticed that LEDs on my controller use interrupt transfers, and on the apple keyboard (and unicomp, as later testing shows) it uses control transfers. Trying to figure out where on which stage exactly I fucked up - and if it's me or cypress).

DMA

19 Jun 2016, 13:18

Interlaced scanning, 1mS console report interval. New, simpler descriptors for console.

Suddenly there's lots of ringing - pretty high-voltage ringing at that. Keypress generates sparks across the whole row somehow. Luckily they are very short, but debouncing is definitely needed.
Probably has something to do with USB report frequency - time to get the scope out.

Also found out that "?" key has a very weak signal. What's worse, the dot key has very strong one, and it creates quite strong signal on the former. Don't know yet what to do and what causes this. May be scope will shed some light on that too..

User avatar
Ratfink

19 Jun 2016, 17:21

[Nerd note: I've never heard of a console report interval measured in a unit for electrical conductance.]

That's weird about different keys being weaker or stronger than each other. Can you estimate the SNR for the '?' key, given the noise from the '.' key and its own weak signal? I'm just wondering how weak/how much noise we're talking about here.

DMA

19 Jun 2016, 19:20

Turns out I accidentally disabled row discharge logic, so those sparks were the charge left over from the key press.
Fixed now. Will leave non-interlaced scan there in config anyway - beam springs should not have that much crosstalk but have more columns, this will shorten the scan time little bit.
Ratfink wrote: [Nerd note: I've never heard of a console report interval measured in a unit for electrical conductance.]
What would you expect at 5 am after 2 hours of fruitless attempts to understand what's going on? :)
At least it's not mSv!
Ratfink wrote: That's weird about different keys being weaker or stronger than each other. Can you estimate the SNR for the '?' key, given the noise from the '.' key and its own weak signal? I'm just wondering how weak/how much noise we're talking about here.
SNR is literally negative. Noise floor is 4-5, Pressing '?' raises voltage to 13-15, pressing '.' raises it to 16-18. In interlaced scan mode, though, noise floor is 2-3, pressing '?' gives 14-16, pressing '.' is still 2-3.
Units are 2mV, if my math is correct. 2.048V/10 bit.

I've noticed something interesting, btw. Next column to '.' there's something that looks like a button which is constantly pressed, but with weakest signal of them all. 10-11 units.
This can be used for automatic calibration methinks. Just scan the matrix couple of times, determine the average voltage level, determine what keys stand out, scan again and select maximum from the keys that are below average and minimum from the keys above it. Can even do this at powerup. Even in worst case - keys pressed at boot time - this will allow for reliable sensing.
Will try to do that today.

HuBandiT

19 Jun 2016, 20:21

Any reason why we don't just charge all capacitors to a nominal value while idle, and then just keep measuring voltage across them to sense when capacitance changed due to actuation, topping them off as needed occasionally?

DMA

19 Jun 2016, 21:12

HuBandiT wrote: Any reason why we don't just charge all capacitors to a nominal value while idle, and then just keep measuring voltage across them to sense when capacitance changed due to actuation, topping them off as needed occasionally?
We'll need to measure time very precisely, as opposed to measure voltage pretty coarsely (by today's standards, at least).

Also I cannot figure out how to measure separate capacitors in pretty vast network. I'm shorting everything to ground, then I untie rows from the ground and drive _one_ of the columns up. So there's only 8 capacitors which are measured at any time, and every one of them is connected to a different pair of pins. Trying to measure the whole matrix at the same time will require significant math - like MRT or x-ray crystallography :)

HuBandiT

19 Jun 2016, 22:28

DMA wrote:
HuBandiT wrote: Any reason why we don't just charge all capacitors to a nominal value while idle, and then just keep measuring voltage across them to sense when capacitance changed due to actuation, topping them off as needed occasionally?
We'll need to measure time very precisely, as opposed to measure voltage pretty coarsely (by today's standards, at least).

Also I cannot figure out how to measure separate capacitors in pretty vast network. I'm shorting everything to ground, then I untie rows from the ground and drive _one_ of the columns up. So there's only 8 capacitors which are measured at any time, and every one of them is connected to a different pair of pins. Trying to measure the whole matrix at the same time will require significant math - like MRT or x-ray crystallography :)
It's completely possible I'm fundamentally misunderstanding the situation. But what I gather is that we have an N×M matrix of capacitors; assuming we can connect to ground one pin of a row of capacitors at a time, as well as we can connect the other pin of a column of capacitors one column a time, we can address each single capacitor individually, and then measure its voltage, and charge/discharge it individually.

For simplicity, let's assume the keyboard starts up with all keys released. Now the microcontroller can address each capacitor individually and charge it up to a nominal value. After they are charged, the microcontroller keeps scanning the capacitors: addressing each of them individually in turn, and measuring the voltage. The moment one of the keys is pressed and the hammer is starting to approach the capacitor electrodes on the PCB, the capacitance will start to change, and, since there is no transfer of energy, this will cause the voltage across the capacitor to change as well. The microcontroller, during scanning, can sense the changed voltage (debounce if necessary). When the key is released, the capacitance - and together with it the voltage - will return to its resting value.

Of course since this is not a theoretical, perfect circuit, there will be non-zero current flowing, so the capacitors will gradually discharge over time. So the microcontroller, after measuring the voltage on the capacitor, can also make a comparison: if the voltage has fallen below a threshold, top up the capacitor to the nominal voltage again (some logic will have to be added to recharge long held-down keys to a proper value as well). Or, just characterize/calibrate the rate of charge/energy per capacitor, and instead of charging to a target voltage (and taking into account whether the key is supposed to be up or down at the moment) recharge each capacitor just as much as it actually needs to replenish its energy (this would be particularly easy to do with the constant current source of the CTMU and a timer/PWM).

With this arrangement, energy flow in the system would be minimized (since we will try to keep all capacitors in a steady state electrically) - which not only means reduced EMI and reduced current consumption, but also enables a much faster scanning frequency, which in turn enables a very clean and reliable debouncing as we would be scanning fast enough to observe the hammer approaching and bouncing in "slow motion".

DMA

19 Jun 2016, 22:41

Hmm. Testing is definitely needed.
EMI would definitely not be a problem tho - PCB sits in a metal cage, after all :)

Need to find a way to get the current consumption accurately.. I suspect we're talking about uAmps here.
Scanning rates above 1kHz is impractical, as I found out - you can only send 1k reports per second over USB, is seems.

HuBandiT

19 Jun 2016, 22:51

DMA wrote: Hmm. Testing is definitely needed.
EMI would definitely not be a problem tho - PCB sits in a metal cage, after all :)

Need to find a way to get the current consumption accurately.. I suspect we're talking about uAmps here.
Scanning rates above 1kHz is impractical, as I found out - you can only send 1k reports per second over USB, is seems.
Technically, you could send 8k reports per second over high-speed (480Mbit/s) USB (USB 2.0).

But that's not where the higher scanning rate comes into play - but instead for accurately detecting order of keypresses as well as debouncing. If we accept the 0,4 m/s finger speed figure Cherry tests their mechanical switches with, an 1kHz scanning rate results in 0,4 mm mechanical resolution, one tenth of key travel - if you touch type quickly, and roll keys in a way that they are following each other closer than this distance (which I think can happen for fast typists), you risk transposing the order of keys merely due to your low scanning rate. And then let's not begin on debouncing mechanical keys. (As a tangent, if a keyboard scans keys at 400 Hz, the mechanical resolution becomes 1 mm, with a 100 Hz scanning rate it becomes 4 mm, with 50 Hz it's 8 mm. Think of this the next time you fault yourself for being a bad typist for apparently transposing letters when typing fast.)

So while a reporting rate of 1 kHz or faster is probably only interesting to gamers (and researchers in neurology!), key scanning itself could very well benefit from a faster scan rate (if otherwise technically feasible).

I think. :)

DMA

20 Jun 2016, 04:39

HuBandiT wrote: Technically, you could send 8k reports per second over high-speed (480Mbit/s) USB (USB 2.0).
Well, after I get this one working, it would probably make sense to move to another controller which understands USB 2.0 high speed.
So while a reporting rate of 1 kHz or faster is probably only interesting to gamers (and researchers in neurology!), key scanning itself could very well benefit from a faster scan rate (if otherwise technically feasible).

I think. :)
Yeah, hit that landmine today.
Turns out there's a lot of noise in the signal. I mean if you don't even touch the keyboard, some keys shoot up to 50 units for a very brief time - which is like 3x the signal "?" key gives off when pressed.
4x oversampling mostly takes care of that, but the row with BkSp in it is especially noisy for some reason and, if you're lucky, quickly hitting BkSp several times produces up to 5 keypresses which break through the averaging momentarily.
Because of this I'm rewriting this post from the notebook's keyboard - BkSp triggered developer console + full screen + something else in Chrome :)

Per-key calibration and debouncing are still needed, it seems.

HuBandiT

20 Jun 2016, 08:28

DMA wrote: Turns out there's a lot of noise in the signal. I mean if you don't even touch the keyboard, some keys shoot up to 50 units for a very brief time - which is like 3x the signal "?" key gives off when pressed.
Since you yourself said the electronics is sitting in a metal cage, you should not be experiencing that level of noise (as in EMI). I suspect you have a bug: either an actual software bug, or you did not correctly account for the dynamic behaviour of the electronics in your model. Since it only happens sporadically, that smells to me like some kind of a timing inconsistency issue.

DMA

21 Jun 2016, 10:06

In theory, there's no difference between theory and practice.
You would expect that it would work, wouldn't you? Everything will be nice and smooth, like it is on the XT keyboard (if you cut the row trace and connect oscilloscope to the PCB end of the cut)?

I'm too lazy to reupload all the pictures - look in the original post, under the second spoiler, it's nicely illustrated even.

I remembered that I actually try to scan even/odd lines 4 columns apart, so it's a bit wrong though - the pulses are much closer.
Will check tomorrow with different delay configurations - though I know from today's experiments that putting 200 us delay after each column scan does not help. Will probably also post less JPEGy pictures, though don't count on that.

Right now I think about double scanning on the spot and discarding the higher value. Or push the current results to github and abandon this whole thing.
Or just implement plain old debouncing. It doesn't seem to be needed though - looks like the sheer mass of the flipper, force of the spring and relatively large detection distance do the debouncing trick in hardware.
I plan on setting up ADC to the maximum sampling frequency it can (they promise 1Msps, but I doubt I'll be able to record that fast) and see if I can detect the ongoing flipper in flight. Would be interesting. Single-channel scan should get 5us resolution, I think - more if I'm lucky, though I don't believe in less than 3us cycle.

HuBandiT

21 Jun 2016, 12:40

Lovely illustrations. However, they only reinforce my conviction that there is simply too much dynamic behaviour going on, and you'd be better off by the more static arrangement I suggested. (You might need a different measurement architecture for that though.)

Don't give up. Simplify the problem. Try "scanning" just one single key. Do the issues (noise) still happen then?

Also, do you have schematics up somewhere? Maybe someone better than me with analog could take a look. More eyes squash more bugs.

DMA

21 Jun 2016, 17:17

HuBandiT wrote: Don't give up. Simplify the problem. Try "scanning" just one single key. Do the issues (noise) still happen then?

Also, do you have schematics up somewhere? Maybe someone better than me with analog could take a look. More eyes squash more bugs.
No, of course I wouldn't give up. It's almost working and I have workaround(s).
You can't scan a single key - or rather you can, but you'll make whole thing 4 times slower. I'm already doing what can be done - that is, grounding the alternating row lines to prevent crosstalk (which is working extremely well, btw).

schematics is "take a prototype kit, connect to 122key model F". This is a very early stage.
Ringing is a result of impedance mismatch, I know that. I also know that matching it would require several full-size prototypes and will need to be done on every PCB design anew. So more universal solution is needed (also this problem would surface no matter the measuring method).

I think I'll just implement the glitch filter (double scan, get minimum value) and be done with it. Or add a very low ESR small capacitor near the input (low-pass filter) to short out those transients - but I want to keep BOM as low as possible. Also all those ribbon cables and other stuff protruding out of Faraday's cage will only add noise - so countermeasures are needed anyway.

I also plan moving to custom schematics for ADCs instead of using the scanning ADC component. I have 2 SAR ADCs on a chip, after all - and in the custom case I have a bit more influence on mux design.

getting xwhatsit's controller to poke it with the scope would be beneficial at this stage. I suspect that it's the same hell - but need to confirm.

HuBandiT

21 Jun 2016, 21:59

DMA wrote: You can't scan a single key - or rather you can, but you'll make whole thing 4 times slower.
I meant to suggest, instead of checking/scanning all the hundredsome keys, just for purposes of simplifying the problem, scan only a single key, and observe behaviour.
DMA wrote: I'm already doing what can be done - that is, grounding the alternating row lines to prevent crosstalk (which is working extremely well, btw).

schematics is "take a prototype kit, connect to 122key model F". This is a very early stage.
Ringing is a result of impedance mismatch, I know that. I also know that matching it would require several full-size prototypes and will need to be done on every PCB design anew. So more universal solution is needed (also this problem would surface no matter the measuring method).
I beg to disagree. If you keep the caps charged and topped up all the time (my suggestion above), instead of charging and discharging them during each scan cycle (as you do currently), you would have much much fewer transients to worry about.

On another note, could the ringing you observe maybe caused by the parasitic LC circuit of the C of the switch (and parasitics) and L being the parasitic inductance of your PCB traces and cables? I don't think you can have ringing without some kind of L.

I wish I had more time for this - is it difficult to get a copy of the KB hardware to play with?

User avatar
wcass

22 Jun 2016, 00:33

First off ... i'm enthusiastically following this. i would love something simpler, smaller, and cheaper than xwhatsit. Remember that the UI is important. Xwhatsit did a pretty good job, and Aikon too.

i know it is tempting to call mutual-capacitance electrodes "rows" and "columns" but we should probably try to avoid that. Design-wise, the two electrodes are often not interchangeable. Also, i believe that IBM and Topre implemented them differently - IBM went with "rows detect" but i think that Topre went with "columns detect". Calling the electrodes rows/columns is just too ambiguous.

The different documentation sources call them different things ... "Tx", "signal", or "drive" for the electrodes that do that - "Rx", "sense", or "detect" for the other.
Last edited by wcass on 22 Jun 2016, 01:11, edited 1 time in total.

HuBandiT

22 Jun 2016, 00:52

wcass wrote: i know it is tempting to call mutual-capacitance electrodes "rows" and "columns" but we should probably try to avoid that. Design-wise, the two electrodes are often not interchangeable. Also, i believe that IBM and Topre implemented them differently - IBM went with "rows detect" but i think that Topre went with "columns detect". Calling the electrodes rows/columns is just too ambiguous.

The different documentation sources call them different things ... "Tx", "signal", or "drive" for the electrodes that do that - "Rx", "sense", or "detect" for the other.
Interesting! Do you maybe have any pointers to documentation on this? (Or is it already in the IBM patent(s)?) And/or do you have a suggestion as to what DMA should change or do differently?

DMA

22 Jun 2016, 01:22

wcass valid point.
drive/sense makes more sense, that's true. Don't have much interest in topre though - and IBM seem to always have driving columns :)

Anyway - will need to stick with software workarounds - hardware design will be too expensive. QFN packages are mighty hard to hand-solder, so every iteration will not only require a new PCB, but also assembly. I can do etching at home, but soldering SMDs that small is outside of my skill.

User avatar
wcass

22 Jun 2016, 01:23

HuBandiT wrote: Interesting! Do you maybe have any pointers to documentation on this? (Or is it already in the IBM patent(s)?) And/or do you have a suggestion as to what DMA should change or do differently?
I can't program so i can't advise on that. I'm OK at hardware design though - capacitive switch matrix and controller PCB layout. If you give me a controller schematic, i'll draft it up.

HuBandiT

22 Jun 2016, 01:31

DMA wrote: soldering SMDs that small is outside of my skill.
Are you sure?: https://www.google.hu/search?q=smd+sold ... 8weYzrSwDA. SparkFun I recall also has quite convincing videos on the topic, both for soldering iron and for hot air gun.

User avatar
wcass

22 Jun 2016, 01:32

DMA wrote: Anyway - will need to stick with software workarounds - hardware design will be too expensive. QFN packages are mighty hard to hand-solder, so every iteration will not only require a new PCB, but also assembly. I can do etching at home, but soldering SMDs that small is outside of my skill.
I used to etch at home but for small PCB prototypes, OshPark does a great job; 3x your design for $5 per square inch including world-wide delivery (though slow delivery outside of USA). Your controller should be under 3 square inches, so about $5 per controller for the PCB. I get solder paste stencils from OshStencil (about $5) and use a hotplate for reflow. Pick-n-place is the hardest part of assembly now. I have a rework station, but prefer the hotplate.

HuBandiT

22 Jun 2016, 01:38

wcass wrote:
HuBandiT wrote: Interesting! Do you maybe have any pointers to documentation on this? (Or is it already in the IBM patent(s)?) And/or do you have a suggestion as to what DMA should change or do differently?
I can't program so i can't advise on that. I'm OK at hardware design though - capacitive switch matrix and controller PCB layout. If you give me a controller schematic, i'll draft it up.
Sorry, I meant do you have info on the electrical difference between using the capacitors in capacitive keyboards one polarity vs the other polarity.

I am having a strong inkling to have a go at this with Microchip PIC microcontrollers, but I don't have a distilled design yet, and I wouldn't want to piss with other people's private parts onto the high voltage lines so to say. If however you guys feel experimentative enough, I could be interested in having a go.

But first off, do we know the capacitance figures (on/off, or at least a range) we are working with?

Post Reply

Return to “Workshop”