deskthority

Yes, that will do. Again, make sure that this is made 0.8 mm thick. The zip file attached can be send directly to any PCB manufacturer. Shipping will likely be more expensive than the boards themselves.

Ok great, thanks wcass.

My 30 pin connector from ebay arrived this week, so I had a go at wiring up my DisplayWriter last night. Happy to report that CommonSense is working well with it.
Thanks for your help with this wcass. I ordered some of your shims from oshpark, but haven't had to use them yet (the 1.6mm connector actually seems to be a fairly snug fit).

Hi DMA!
after years I'm finally ready to bring my FEXT to live and do it with the CapSense!!
First of all, happy to see the great success here! This will soon even be Bluetooth... omg..
Anyway I wanted to ask and propose to make a couple of explicit pictures/drawings of the wiring between controller and board(s) and then finally put it in the first post of this thread and in the documentation/github: what do you think?
If nothing fancy is ok I can offer myself to do a picture based on this one: For instance I know from i$ this one: So to avoid errors, the idea in this case would be to wire Pin 3, the first row, to P2.0 then Pin 4, the second row, to P2.3, etc (even if not clear where a 7th or 8th row would be mapped to, if at all possible), correct?
Similar for the columns, I expect Pin 13, the first column, to go to P1.1, Pin 14, second column, goes to P1.2, etc.., also correct?
And I guess it will be easy to find similar for model F XT/ Beamsprings / etc but I think what is important for the guide is to offer one or two examples, the rest is then more intuitive.
Maybe I could do even an ASCII art for the documentation! =)

Kr,
tent:wq

Congratulations!

tentator wrote: after years I'm finally ready to bring my FEXT to live and do it with the CapSense!!
First of all, happy to see the great success here! This will soon even be Bluetooth... omg..

I dunnot about BLE, haven't touched keyboards in like 3 months. Work, y'know

tentator wrote: So to avoid errors, the idea in this case would be to wire Pin 3, the first row, to P2.0 then Pin 4, the second row, to P2.3, etc (even if not clear where a 7th or 8th row would be mapped to, if at all possible), correct?

Yes. There are 8 rows - 2.0, 2.3, 2.4, 2.5..
Similar for the columns - there are 24 of those, but if you want more than 16 you have some desoldering to do.

As long as you solder cols to columns and rows to rows - you're fine (you can solder cols to rows and rows to columns - that would also work). if you wire col0 to column 2 and col2 to column 1 - your layout will look funny, but things will work.

I'm not an artist - but I take patches You can make a pull request or just PM the file to me - works either way.

Hi Again DMA,
quick double-check: so the 8 columns would be: 2.0, 2.3, 2.4, 2.5, 2.6, 2.7, 12.7 and 12.6, correct?
also: can you drive a solenoid with this board?

Kr,
tent:wq

tentator wrote: Hi Again DMA,
quick double-check: so the 8 columns would be: 2.0, 2.3, 2.4, 2.5, 2.6, 2.7, 12.7 and 12.6, correct?

Those are rows. Can only be 8 of those.
Columns are 1.0, 1.1, 1.2... - up to 24 of those.

tentator wrote: also: can you drive a solenoid with this board?

You'll need xwhatsit solenoid daughterboard for actual driving, but this board can control it.

yes sorry, wanted to write rows so the 8 listed ones are the correct ones?
the solenoid daughterboard from xwhatsit is something complex or could I just handwire a couple of resistors and caps myself?

What I wanted to do is just produce a complete pinout picture for others to reference to as well like the following:

tentator wrote: yes sorry, wanted to write rows so the 8 listed ones are the correct ones?
the solenoid daughterboard from xwhatsit is something complex or could I just handwire a couple of resistors and caps myself?

No, it's a small boost converter + triggering circuit. So I doubt you can handwire that
https://www.ebay.com/itm/Xwhatsit-SOLEN ... 2860110367

I just tuned in recently, so I'm still getting up to speed on where everything is; please forgive me for any pieces I'm missing. So far, I've had a look at threads about xwhatsit, dph, and commonsense. I see some merits and shortcomings to each of them, and perhaps there's some room to improve.

I've downloaded Cypress PSoC Creator and had a look at what I'd downloaded of the CommonSense design. It seems to open the BLE01_USB project while I wasn't looking for a Bluetooth design per-se, but I'll presume how the capacitive matrix is handled is independent of the host interface.

Looking at the PSoC design, one thing I hadn't expected is the sense of rows/columns seems to be reversed from IBM and the Xwhatsit designs, which drive many columns and sense on a few rows. What I'm seeing in PSoC creator appears to be the inverse, with 8 rows being driven, and 24 columns going through a mux to the single sensing ADC. My gut feeling is that the IBM/Xwhatsit arrangement may perform a little better: the sensing side of things is of course more sensitive to things, and a larger 24-input mux is sure to have more parasitics. Also, I think IBM's sense board layouts allow for more parasitic capacitance from the column lines to the surrounding ground ring, since cap there isn't a problem with the driver outputs to push them around. On the other hand, IBM's sense lines are shared between more keys and have more capacitance from the other inactive keys, and maybe this is the worse effect.

Another simple thing I'm seeing is with regard to the ADC input. I recall reading some complaints about the input of the ADC carrying over some memory of prior samples and corrupting new conversions. This being the case, I'm wondering, why not put an op-amp follower between the mux and the ADC? Assuming the op-amp isn't too crappy, this should quiet things a bit by completely isolating the cap matrix from any ADC kickback. I think it might also show that the memory of prior samples to be in the keyboard matrix itself rather than the ADC, but I'll need to think some more about that.

That said, I think I would insert the op-amp as a TIA instead, bringing the output and inverting inputs out to pins to attach an external integrating capacitor (and maybe a bleed resistor, and level-restore diode). I think this would bring things closer to IBM's design.

One last thought: in the TopController thread, there's a video showing I believe Flightcontroller readings as one key is pressed/released. I'm wondering how the numbers look when multiple keys are being pressed together. More specifically, for a particular key of interest, how does its min/max range change when all other keys on the same sense line (column?) are pressed simultaneously. Depending on the on/off capacitance ratio, it's possible that with enough keys pressed, none of them would actually get seen if the decision thresholds were set based on single-key presses (for type-F.. shouldn't be an issue with beamspring). In this regard, the drive few/sense many arrangement is probably a good thing.

Luns wrote: 02 Apr 2019, 06:31 I've downloaded Cypress PSoC Creator and had a look at what I'd downloaded of the CommonSense design. It seems to open the BLE01_USB project while I wasn't looking for a Bluetooth design per-se, but I'll presume how the capacitive matrix is handled is independent of the host interface.

Probably because BL comes before BO. Otherwise you'll be at Bootloader.

Luns wrote: 02 Apr 2019, 06:31My gut feeling is that the IBM/Xwhatsit arrangement may perform a little better: the sensing side of things is of course more sensitive to things, and a larger 24-input mux is sure to have more parasitics.

Just turn on your scope and see for yourself. I'm not forcing anybody to use any particular controller.

Luns wrote: 02 Apr 2019, 06:31Also, I think IBM's sense board layouts allow for more parasitic capacitance from the column lines to the surrounding ground ring, since cap there isn't a problem with the driver outputs to push them around. On the other hand, IBM's sense lines are shared between more keys and have more capacitance from the other inactive keys, and maybe this is the worse effect.

It kind of doesn't matter. What matters is 3us you must wait for things to stabilize before you read them out, and another 3-10 (depends on amount of ambient noise) for matrix to discharge. Readouts take 1us* per pin.
So yeah, can drive columns, it just will be 2 times slower for 8x16 and about 6 times for 4x23. Which is still not bad - 8x16 is scanned at about 3.6kHz, 4x23 - 7.7kHz. But why would I?
First versions used dual-ADC (limiting them to 56 series and above) - but I found shaving 16-24us per row not worth it, because 56 series was like $2 more expensive. I already can debounce in 1 USB tick, why bother.

Luns wrote: 02 Apr 2019, 06:31Another simple thing I'm seeing is with regard to the ADC input. I recall reading some complaints about the input of the ADC carrying over some memory of prior samples and corrupting new conversions. This being the case, I'm wondering, why not put an op-amp follower between the mux and the ADC? Assuming the op-amp isn't too crappy, this should quiet things a bit by completely isolating the cap matrix from any ADC kickback. I think it might also show that the memory of prior samples to be in the keyboard matrix itself rather than the ADC, but I'll need to think some more about that.

I recall spending a month on this (actually, those are two related problems). Page 3 or 4 of this topic IIRC. I solved this in a different way - I'm sure you can see how if you look at TopDesign.cysch a bit closer (or at comments in scan module).
Hint: drive modes for pins _do_ matter. OEs too.
Another thing is 5267 doesn't have op-amps. and 5467 is a bit more expensive.

Luns wrote: 02 Apr 2019, 06:31That said, I think I would insert the op-amp as a TIA instead, bringing the output and inverting inputs out to pins to attach an external integrating capacitor (and maybe a bleed resistor, and level-restore diode). I think this would bring things closer to IBM's design.

I'm too cheap for that shit. Diodes. Resistors. You need to pay for those things! Seriously though - show me an op-amp with zero input capacitance. I want to see that miracle.

Luns wrote: 02 Apr 2019, 06:31how the numbers look when multiple keys are being pressed together. More specifically, for a particular key of interest, how does its min/max range change when all other keys on the same sense line (column?) are pressed simultaneously.

If it changes - your discharge delay is too short.
If you remove ALL the ground traces between rows and columns - you'll see some crosstalk between columns.
Now if you have a LED-compatible dimmer at 50% in 2 meter radius, you'll see some interesting effects when scanning full-speed (matrix monitor mode slows things down considerably because scan module talks to USB and triggers rows at much slower rate - so you won't see them there) - but debouncing at 4 mostly takes care of that.
download/file.php?id=50370 - this caused me to change max debounce to 16.

Luns wrote: 02 Apr 2019, 06:31Depending on the on/off capacitance ratio, it's possible that with enough keys pressed, none of them would actually get seen if the decision thresholds were set based on single-key presses (for type-F.. shouldn't be an issue with beamspring). In this regard, the drive few/sense many arrangement is probably a good thing.

Why would it? It's not like you have shortage of charge carriers in a driving line. And if you don't - those are just caps connected in parallel. Each with it's own RC constant.

This post contains pretty detailed history of what was done and what were the problems. First 3 or 4 pages. There are pictures, even. Some with waveforms.

DMA wrote: 04 Apr 2019, 02:04

Luns wrote: 02 Apr 2019, 06:31My gut feeling is that the IBM/Xwhatsit arrangement may perform a little better: the sensing side of things is of course more sensitive to things, and a larger 24-input mux is sure to have more parasitics.

Just turn on your scope and see for yourself. I'm not forcing anybody to use any particular controller.

I intend to! Just waiting for my Cypress prototyping kit to show up.

DMA wrote: 04 Apr 2019, 02:04

Luns wrote: 02 Apr 2019, 06:31Also, I think IBM's sense board layouts allow for more parasitic capacitance from the column lines to the surrounding ground ring, since cap there isn't a problem with the driver outputs to push them around. On the other hand, IBM's sense lines are shared between more keys and have more capacitance from the other inactive keys, and maybe this is the worse effect.

It kind of doesn't matter. What matters is 3us you must wait for things to stabilize before you read them out, and another 3-10 (depends on amount of ambient noise) for matrix to discharge. Readouts take 1us* per pin.
So yeah, can drive columns, it just will be 2 times slower for 8x16 and about 6 times for 4x23. Which is still not bad - 8x16 is scanned at about 3.6kHz, 4x23 - 7.7kHz. But why would I?

First versions used dual-ADC (limiting them to 56 series and above) - but I found shaving 16-24us per row not worth it, because 56 series was like $2 more expensive. I already can debounce in 1 USB tick, why bother.

So the switch to driving rows was to reduce the number of drive transitions, and the time associated with each one. I see. I'm not too hung up on scan rates, and my thinking was still along the lines of keeping to how IBM did things. _red_ showed a plot of the column drive of his F122 pulsing 8 times for 8 rows in about 700us, which works out to a scan rate of about 60Hz - two orders of magnitude slower than what you got, but still quite adequate. I'm sure IBM's scan rate was limited by what the microcontrollers of the day (8048 I think) could do rather than analog issues. With one pulse per key, there's no difference in number of pulses whether you drive rows or drive columns.

DMA wrote: 04 Apr 2019, 02:04

Luns wrote: 02 Apr 2019, 06:31Another simple thing I'm seeing is with regard to the ADC input. I recall reading some complaints about the input of the ADC carrying over some memory of prior samples and corrupting new conversions. This being the case, I'm wondering, why not put an op-amp follower between the mux and the ADC? Assuming the op-amp isn't too crappy, this should quiet things a bit by completely isolating the cap matrix from any ADC kickback. I think it might also show that the memory of prior samples to be in the keyboard matrix itself rather than the ADC, but I'll need to think some more about that.

I recall spending a month on this (actually, those are two related problems). Page 3 or 4 of this topic IIRC. I solved this in a different way - I'm sure you can see how if you look at TopDesign.cysch a bit closer (or at comments in scan module).
Hint: drive modes for pins _do_ matter. OEs too.
Another thing is 5267 doesn't have op-amps. and 5467 is a bit more expensive.

Yes, I'm aware of your method of measuring ground. I suggested the OpAmp having found it in PSoC designer looking at TopDesign.cysch. If you skip it in order to use a cheaper chip, then fair enough. The chip in the CY8CKIT-059 has two opamps, so in the context of using that kit, the only reason I can see to not use the opamp is if it's been tried and showed no benefit. However, I'd expect its input capacitance to be way smaller than the ADC's own input, and it may free you from the alternate ground sampling - this would let you double your scan rate.

DMA wrote: 04 Apr 2019, 02:04

Luns wrote: 02 Apr 2019, 06:31That said, I think I would insert the op-amp as a TIA instead, bringing the output and inverting inputs out to pins to attach an external integrating capacitor (and maybe a bleed resistor, and level-restore diode). I think this would bring things closer to IBM's design.

I'm too cheap for that shit. Diodes. Resistors. You need to pay for those things! Seriously though - show me an op-amp with zero input capacitance. I want to see that miracle.

Both the diodes and resistors, I have plenty of kicking around, and literally cost a penny a piece. I'm willing to spend 2 cents if it yields a better design. So far as the input capacitance, it doesn't need to be zero to be an improvement, it only needs to be less than the ADC.

And actually, my preferred approach of the TIA wouldn't care about the input capacitance: the whole point is to present a virtual ground to the matrix so that all the parasitic capacitances are bypassed. The catch with doing this is that you'd need to strobe the drive line once per key as IBM did. Either that, or have a separate op-amp for each sense line as was done with the DPH design.

DMA wrote: 04 Apr 2019, 02:04

Luns wrote: 02 Apr 2019, 06:31how the numbers look when multiple keys are being pressed together. More specifically, for a particular key of interest, how does its min/max range change when all other keys on the same sense line (column?) are pressed simultaneously.

If it changes - your discharge delay is too short.

I think you're thinking of the opposite of what I was suggesting. If you press all the keys on the same drive line, the extra capacitance the one driver needs to discharge is more and requires the longer discharge delay. What I'm more concerned about is all keys on the sense line

DMA wrote: 04 Apr 2019, 02:04 If you remove ALL the ground traces between rows and columns - you'll see some crosstalk between columns.
Now if you have a LED-compatible dimmer at 50% in 2 meter radius, you'll see some interesting effects when scanning full-speed (matrix monitor mode slows things down considerably because scan module talks to USB and triggers rows at much slower rate - so you won't see them there) - but debouncing at 4 mostly takes care of that.
download/file.php?id=50370 - this caused me to change max debounce to 16.

Actually, for the homebrew key grid, I wonder how much putting a sheet of aluminum foil behind it might help. I suspect your glitching is getting picked up inductively, and having the adjacent metal shield would allow eddy currents to flow that would cancel the glitches.

DMA wrote: 04 Apr 2019, 02:04

Luns wrote: 02 Apr 2019, 06:31Depending on the on/off capacitance ratio, it's possible that with enough keys pressed, none of them would actually get seen if the decision thresholds were set based on single-key presses (for type-F.. shouldn't be an issue with beamspring). In this regard, the drive few/sense many arrangement is probably a good thing.

Why would it? It's not like you have shortage of charge carriers in a driving line. And if you don't - those are just caps connected in parallel. Each with it's own RC constant.

Again, I think you're thinking of extra cap on the drive line; my concern is sense. I don't think I've yet seen a reasonably complete analysis of what goes on with the cap matrix yet - there's usually talk of going from voltage to current, then things kinda wander into some vague notion of signals before ending up back at voltages without making a proper transition back. So, here goes:

[Anybody not up or a lecture, may want to bail out here. DMA, the following isn't entirely directed at you but I put it out there for the benefit of those who might not have the whole picture]


The way to measure an individual capacitor in the matrix is to ground everything except the drive terminal for the cap of interest. Raise the voltage of the drive terminal from 0 to V, and there will be a charge of V*Ckey that comes out of that capacitor's sense terminal into ground. There'll be other charges than that going into the drive terminal, but that's charge going through the other capacitances sharing it, and they all dump out to ground through the other sense lines.

So far so good, but the problem becomes one of how do you measure that charge coming out of the one sense line? Well, if instead of directly grounding the sense terminal, you put a very large shunt capacitor between the sense terminal and ground, then the charge being delivered to that capacitor will generate a voltage step. This voltage step has its own effect on the matrix too, but if this cap is large enough it'll be negligible and the step will be about V*Ckey/Cshunt

So it's at this point that things start to go in different directions. The approach I see all the controllers here aside from IBM's is to not use such a large capacitor: the smaller the capacitor, the larger the sensed voltage. In fact, they use no deliberate capacitor at all. An easy way to get to the end result is to just take the charge of V*Ckey that came out of the sense terminal, and just shove it back in. That charge creates a voltage step at the sense terminal that's inversely proportional to the total capacitance there. Basically, all the capacitance present on the sense line serves the function of the large shunt capacitance suggested earlier.

However, this total capacitance is not a fixed quantity: it's the sum of all the capacitances on the sense line, and consists of other key capacitances that vary whether the other keys are pressed or not. If we have keys with finite on capacitance and zero off capacitance, then when pressing one key, we will get an output voltage step of V. If we have two keys on the same sense line pressed, the output will be V/2. If we have 16 keys on the same sense line all pressed, the output will be V/16.

Now, in reality, keys have nonzero off capacitance too, so it's as though there's some number of keys on the sense line that are always present. If each key's off capacitance is 1/5 of the on capacitance, then a row of 16 keys would have an output of V/4 when one key is pressed, and one quarter of that with all 16 keys pressed.

So, is this a problem? That depends on what you chose for a sensing threshold. If you only ever test with a single key, you might see the voltage step of V/4 for a single key, and pick V/8 as your threshold for deciding whether the keys is pressed or not. But when you press all 16 keys of the row, the voltage step never exceeds that, and none of the keys get sensed.

The way around this is to go back to the notion of adding a large cap, but do it artificially. If we put an inverting amplifier on the sense terminal with a large gain of A and a feedback capacitor from the output to the input terminal of the amplifier, the sense matrix will see this as a large capacitor that's (1+A) times larger than feedback capacitor itself. The sense line will see very little voltage change, so the other capacitances there don't do much. The output of the amplifier however, will step down by V*Ckey/Cfeedback. This ratio just depends on the fixed feedback cap, and the capacitance of the one key of interest, and can be made comfortably large. The effect of all the other capacitances on the same sense line are essentially attenuated by A, which for the LM324 Amplifiers used in the DPH controller, is at least 100,0000.

For the 12pF/8.5pF values that wCass measured, we'd be talking around V/12 for one key, and V/16 for sixteen keys. These don't sound unreasonable, and likely wouldn't be a problem, but with these numbers, all sixteen keys off would also read V/16. However, other fixed parasitic capacitances on the board would attenuate the no-keys-pressed step size more than the others. Some of your plots had a step size that looks like something around 37mV or around 5V/135, in which case the other parasitic capacitances are probably dominating.

Luns wrote: 02 Apr 2019, 06:31 This being the case, I'm wondering, why not put an op-amp follower between the mux and the ADC?

I guess one consideration would be the limited bandwidth of the op-amp: it may not be fast enough to follow the mux output in time for the ADC sampler.

Luns wrote: 02 Apr 2019, 06:31keeping to how IBM did things.

It was like.. seventies. 5267 is somewhere around base S370 on the RAM front and faster than most if not all of the family. Tradeoffs were different and much more attention was paid to design - like every column on that model F PCB is impedance-matched with GPIO it's driven by. I just underdrive things and pretend I'm not violating the spec by pulling down the pins which might have negative voltage on them soon. And then it's like not negative voltage, just some current to source.

I strongly suspect the decision to drive columns was based on the cost of that square chip channel. I can't think of any other reason for 23x4 matrix. Well, there's acid - but IBM was on a wrong coast to partake in psychedelic experiences

Luns wrote: 02 Apr 2019, 06:31Yes, I'm aware of your method of measuring ground.

I'm not measuring ground. I'm draining the sampling cap. Don't even read the results - second stage DMA skips over them.

Luns wrote: 02 Apr 2019, 06:31the only reason I can see to not use the opamp is if it's been tried and showed no benefit.

5888 has 4 OpAmps, 4 comparators and 4 programmable blocks that can be told to be TIAs. I simply haven't seen a single reason to use them.
Current setup is simple. There's this magic piece of verilog ripped out of Scanning ADC component. It does the switching - even taking care of things like switching the channel at end of sampling, not conversion - but it doesn't really expect to have anything between MUX and ADC. I still don't know how long is the sampling window, btw. Likely long enough for the amp to stabilize, but no guarantees.

I strongly prefer simplest thing that works. For example, there will be no tap dance macros in CommonSense - unless somebody else writes them. The only excuse for having macros at all is scarcity of the beamspring switch mechanisms.
There's also this thing of not lying about things. If you look at the macros themselves - there are no such thing as "Ctrl-F1" macro trigger. Because modifiers don't exist and I'm not the one to guess what the host _thinks_ current modifiers are (yes, you can press Ctrl on one keyboard and F1 on the other. It will even work as expected!)

Luns wrote: 02 Apr 2019, 06:31Both the diodes and resistors, I have plenty of kicking around, and literally cost a penny a piece. I'm willing to spend 2 cents if it yields a better design.

There's this thing. It's called "manufacturability". You're not helping that by adding parts.

Minimal viable BOM for CS is 1xMCU, 3x1uF caps, 2x22Ohm resistors and an USB socket. It may be a bit fussy about the girth of your USB cable, FCC will probably ban it on sight, it _is_ a blatant violation of the datasheet (6x0.1uF + 3x1uF are _required_) - but it works. Allows for things like (Not sure what other 2 caps doing there - I might've placed them out of abundance of caution).
Now this _is_ a clowny design. No question. It should've had USB protector, for one - if somebody plugs CSSK into a wrong macbook pro USB-C port twice, worldwide supply of those will be depleted and I'll have to spend another 1.5 hours per QFN.
For even a hundred units I would put USB protector, shield capacitor, resettable fuse, that extra 1uF on VDDD so USB transceiver doesn't pull VBUS to 3 volts.. but those are strictly improvements. I can rest assured that it will work when assembled - unless I missed a ratline (happened. more than once!) or put a solder bridge somewhere.

Luns wrote: 02 Apr 2019, 06:31The catch with doing this is that you'd need to strobe the drive line once per key as IBM did. Either that, or have a separate op-amp for each sense line as was done with the DPH design.

OH WAI. TIA has zero input impedance. That's what killed DPH (well, actually it was the desire to maintain baseline voltage between zero and +5V - but the same thing conceptually.). Inability to store charge. You're forced to measure at a specific moment in time - very, very short moment. This just doesn't work.

Luns wrote: 02 Apr 2019, 06:31 I think you're thinking of the opposite of what I was suggesting. If you press all the keys on the same drive line, the extra capacitance the one driver needs to discharge is more and requires the longer discharge delay. What I'm more concerned about is all keys on the sense line

In theory, part of the charge that got to the sense line must spill to ground via other keys in the column. In practice it's probably offset by larger capacitance of the resulting system or something like that. Not noticeable.

Luns wrote: 02 Apr 2019, 06:31 Actually, for the homebrew key grid, I wonder how much putting a sheet of aluminum foil behind it might help. I suspect your glitching is getting picked up inductively, and having the adjacent metal shield would allow eddy currents to flow that would cancel the glitches.

Grounded - tremendously. Floating will make noise unbearable.

What you're describing in a long part is a matrix of ideal capacitors infinitely far from anything. In this case indeed, driving a line charges the line's capacitors, which causes current in the sense lines to balance charge carriers across the cap's dielectric wall. Once capacitor charges, it will stop. But in reality there are parasitic capacitancies and I abuse them, go reread the front post. It even has a link to graphic circuit simulator.

And btw you don't need to be so fixated on a single cap. you can sense all the lines in parallel - crosstalk will have to go via another drive line - which is grounded - but also it will need to jump across 2 capacitors - one to the drive line, another from it. Series of capacitors has 1(1/C1 + 1/C2) capacity, which is essentially zero in our case.

And the part from "shove it back in" beyond is missing some fundamental understanding of how capacitors work.

Adding TIA is not "adding a cap artificially" - TIA has zero input impedance, it will drain all the charge in nanoseconds and you'll be reading zeroes.
Adding a large cap sucks in any scenario - voltage is inverse square of charge state, 50% charged cap will produce 1/4 voltage of 100% charged one.
Also you're switching from measuring the capacitance directly to measuring a transfer function of the key capacitor. And suddenly slew rate DOMINATES. And with it impedance-matching becomes a fucking necessity because if you overdrive the line even a bit - ringing will kill you because suddenly there are HUGE ULTRA-HIGH FREQUENCY COMPONENTS which makes all your measuring useless.

Don't overcomplicate things. That's what killed DPH (technically it was crappy MK20 ADC and the desire to pull the floor above zero with continuous supply). xwhatsit suffers from the second problem too - but latching comparators overcome it. The cost is huge. But it works. Somewhat. Because at least on the one I've got ringing _is_ a problem. Not on every cycle, but regularly.

Test the stuff, too. Make a simple matrix in that clowny simulator above, try your sensing. If it doesn't work in ideal world (and it won't, p<0.01!) - how would it work in real one?

DMA wrote: 06 Apr 2019, 20:25 5888 has 4 OpAmps, 4 comparators and 4 programmable blocks that can be told to be TIAs. I simply haven't seen a single reason to use them.

I wasn't able to find the TIAs earlier, but it turns out that was because I was fiddling with the CSSK design which was uses a 5267. I don't understand why it let me place an Op-Amp in that space if the 5267 doesn't have Op-Amps. Anyway, moving over to the XTAnt design, I see the TIA in the library now. Unfortunately it has a maximum feedback cap of 4.6pF which isn't going to be enough if the key cap we're trying to sense is 12pF.

DMA wrote: 06 Apr 2019, 20:25 I strongly prefer simplest thing that works.

To me, a comparator is simpler than a multi-bit ADC, and my interests are in leaning things in that direction. What I'm trying to explore is why IBM could get away without a multi-bit ADC, without per-key thresholds, with slow 1970's microcontrollers, and still be able to build a robust capacitance sensing controller. If those methods are still accessible without excessive cost, why not use them?

DMA wrote: 06 Apr 2019, 20:25

Luns wrote: 02 Apr 2019, 06:31Both the diodes and resistors, I have plenty of kicking around, and literally cost a penny a piece. I'm willing to spend 2 cents if it yields a better design.

There's this thing. It's called "manufacturability". You're not helping that by adding parts.

Well, the same could be said of playing with designs based on flippers that are only available either new from a finite supply at $1 each or from cannibalizing old keyboards whose prices have doubled or tripled in the last few years.

It's a valid concern if you're planning on actually manufacturing and selling these in quantity, but in the context of building something as a personal project, perhaps not so much. My context is just a guy with a CY8KIT-059 in the mail. I imagine anybody willing to go through what it takes to acquire model F flippers can afford a few discrete components.

DMA wrote: 06 Apr 2019, 20:25

Luns wrote: 02 Apr 2019, 06:31The catch with doing this is that you'd need to strobe the drive line once per key as IBM did. Either that, or have a separate op-amp for each sense line as was done with the DPH design.

OH WAI. TIA has zero input impedance. That's what killed DPH (well, actually it was the desire to maintain baseline voltage between zero and +5V - but the same thing conceptually.). Inability to store charge. You're forced to measure at a specific moment in time - very, very short moment. This just doesn't work.

I subsequently found dfj's schematic, and was disappointed to see the opamps there weren't configured as TIAs, they were simple voltage followers. Sadly that puts it in the same camp as your and xwhatsit's designs in trying to sense voltage. What I see as the flaw with the DPH design is that there's nothing to explicitly define the DC point of the op-amp inputs. The inputs source a bias current of up to 100nA, but there's nothing there to sink that current, so the input voltages would float up and out of the op-amp's proper operating point.

Xwhatsit has a deliberate resistor for setting the DC point, but then struggles with that resistor also bleeding off the charge we're trying to detect. Your design correctly gets the DC point by discharging everything regularly.

DMA wrote: 06 Apr 2019, 20:25 And the part from "shove it back in" beyond is missing some fundamental understanding of how capacitors work.

The "shove it back in" is the application of linear superposition, and is a way to get the attenuation of a simple capacitor divider without having to mess with equations. If you're familiar with Miller capacitance, you'd recognize where I went with things from there.

https://en.wikipedia.org/wiki/Miller_effect

DMA wrote: 06 Apr 2019, 20:25 Adding TIA is not "adding a cap artificially" - TIA has zero input impedance, it will drain all the charge in nanoseconds and you'll be reading zeroes.
Adding a large cap sucks in any scenario - voltage is inverse square of charge state, 50% charged cap will produce 1/4 voltage of 100% charged one.

TIA is zero input impedance with an infinite amplifier gain. That's exactly the point of using them - parasitic capacitances have no effect when they're shunted by zero impedance. An infinite cap is zero impedance. With finite gain, it's a nonzero, though small impedance; a finite but still large cap. The large cap is not a physically large cap, it's the feedback capacitor made to look much larger than it really is by the amplifier - this is what I meant by artifical: the cap is made to look larger than it really is.

You don't read zeros unless you're looking at the amplifier input. That's like pointing a microscope at something then looking at the object with your naked eye rather than through the microscope. Tell me what you expect to see at the TIA output.

The TIA is draining all the charge from the sense line, by pushing through to the feedback capacitor instead. The feedback capacitor can chosen to be smaller than the parasitic capacitances (be they the other keys sharing the line or genuine parasitics) and thus give you a larger voltage to work with at the TIA output.

DMA wrote: 06 Apr 2019, 20:25 Also you're switching from measuring the capacitance directly to measuring a transfer function of the key capacitor.

What you're measuring isn't the capacitance directly, you're measuring the attenuation of a capacitor divider with the key capacitor against an arbitrary capacitance including all the other caps on the same sense lines, and an uncontrolled amount of parasitic cap. What I'm switching to is measuring the ratio of the key cap to a feedback cap that has a value that we choose for ourselves.

DMA wrote: 06 Apr 2019, 20:25 Test the stuff, too. Make a simple matrix in that clowny simulator above, try your sensing. If it doesn't work in ideal world (and it won't, p<0.01!) - how would it work in real one?

None of what I'm suggesting is novel or untested: it's literally a textbook building block for switched capacitor circuitry. Take a look at the second figure of http://www.seas.ucla.edu/brweb/teaching/AIC_Ch12.pdf .

BTW, I do want to say, forgive me if I come across as confrontational - that's not my intent at all, but I can see how things might be perceived that way. I appreciate everything you've done and shared here, and thank you for it! I didn't know the Cypress PSoCs even existed until learning of them here, and everything after the basic scanning of the key matrix through to flightcontroller is more work than I'd ever have the patience to endure.

Luns wrote: 07 Apr 2019, 05:16 To me, a comparator is simpler than a multi-bit ADC, and my interests are in leaning things in that direction.

It's simpler*. Problem is it doesn't really work. You need to know thresholds - or use ADC to get them at runtime, in which case not only you dragged ADC in, you also dragged in a DAC to set comparator thresholds. This may make sense if you have Unbelievably Crappy(sm) ADC, but a good DAC and comparator.
It is possible to discover thresholds with no ADC at all by trying all DAC settings - but you'll need a special mode in firmware for that, increasing complexity.

Luns wrote: 07 Apr 2019, 05:16What I'm trying to explore is why IBM could get away without a multi-bit ADC, without per-key thresholds, with slow 1970's microcontrollers, and still be able to build a robust capacitance sensing controller. If those methods are still accessible without excessive cost, why not use them?

"Excessive costs" things changed. IBM could go thru 10-15 PCB designs to achieve the flat field, but I guess ADCs were very expensive.
And I'm not sure about per-key thresholds - that square chip has runtime-configurable sensitivity from what I've heard.

Luns wrote: 07 Apr 2019, 05:16Well, the same could be said of playing with designs based on flippers that are only available either new from a finite supply at $1 each or from cannibalizing old keyboards whose prices have doubled or tripled in the last few years.

CS is known to work on topre (at my table), foam and foil (Sangdrax), it will likely will on Varmilo EC and other capacitive stuff. Turns out it also works for conductive switches as well, though I don't have any anti-ghosting.
At $6 it's a bit too expensive for mass-production, I agree. Also may be I chose a wrong word - may be "repeatability" is a better one.
As for "can afford a few discrete components" - Usually not, because those drag another PCB with them, and even if not they take space. And space is one thing you don't have because you need to use an existing case - sometimes conductive which adds to the fun.

Luns wrote: 02 Apr 2019, 06:31 Xwhatsit has a deliberate resistor for setting the DC point, but then struggles with that resistor also bleeding off the charge we're trying to detect. Your design correctly gets the DC point by discharging everything regularly.

And what does make you think that a device with zero input impedance connected to the cap won't bleed the charge immediately?

Luns wrote: 02 Apr 2019, 06:31Tell me what you expect to see at the TIA output.

I felt a great disturbance in the Force, as if millions of voices suddenly cried out in terror and were suddenly silenced.

Exaggerated - Vcc while there's charge and then zero. And since you don't have a sample-and-hold, your feedback capacitor will be drained by the same op-amp output that charged it.
And the funniest thing - I don't need larger voltage. I'm fine with 30mV - even with 10 - and if you have less, put ADC Vref on a resistive divider, that will easily get you to hundreds of uV range (not sure about tens).

Luns wrote: 02 Apr 2019, 06:31 What you're measuring isn't the capacitance directly, you're measuring the attenuation of a capacitor divider with the key capacitor against an arbitrary capacitance including all the other caps on the same sense lines, and an uncontrolled amount of parasitic cap.

Yes. I'm not. And this is, like, written in the first post of this thread. Don't care about capacitances, just voltages on the pins. And guess what - I have some magvalve keyboards on the table, I'm going to try exactly the same approach on those, and would not be surprised if it works (will probably need external caps on sense lines). Just need some time.

Although.. I'm not sure I'm measuring exactly that. I tried strong drive - got higher voltages on sense IIRC. Problem is stability. Ground becomes jumpy as hell. So I kind of came to terms with myself that I'm measuring the charge that made it thru the resistor (C is R for AC component, after all - I'm just generating a quarter of a period, 0 to +V) and try not to think too much about it.
I don't currently have a shortage of things to think about - 6K servers with elusive perf problems provide a lot of those.

Luns wrote: 02 Apr 2019, 06:31What I'm switching to is measuring the ratio of the key cap to a feedback cap that has a value that we choose for ourselves.

And you need all this tight control over environment because?.. This is not an LCR meter forum

Luns wrote: 02 Apr 2019, 06:31None of what I'm suggesting is novel or untested: it's literally a textbook building block for switched capacitor circuitry. Take a look at the second figure of http://www.seas.ucla.edu/brweb/teaching/AIC_Ch12.pdf .

But those are _switched_ capacitor circuits. And you didn't mention any switches so far.

Luns wrote: 02 Apr 2019, 06:31BTW, I do want to say, forgive me if I come across as confrontational - that's not my intent at all, but I can see how things might be perceived that way.

Forgive me for being defensive too. You're not the first to tell me (this will not work) or (I'm doing it wrong) or (IBM made it differently) or (it's too expensive, ATMEL is cheaper) or (not compatible with QMK so I won't get any mass adoption). I'm generally fine with those (except atmel one - fuck Harvard architecture and PROGMEM in particular.) - but I can't resist a good argument, especially with people who are wrong

You seem to have training in electronics - that's more than I have (though I had my own copy of school's electronics lab key). This knowledge is exactly what holds you back. You think you know things work - and you do. For the components. But there's emergent behavior. Circuit simulators can help, that's true. And then there's Reality - nothing helps there, it works the way it works, you can usually scope things (advanced triggers help greatly) but it doesn't necessarily lead to understanding how to fix it. See "mini-xwhatsit and the 1/! key".

Oh btw, there's another post with the beginning of this story: viewtopic.php?f=2&t=13819
It has a video of the first prototype: https://www.instagram.com/p/BFu7-Ifgru4 ... uQxv7wOU0/ and some early FC (which only had matrix monitor mode at that time ) which answer your question on "what if you press all the buttons": https://www.instagram.com/p/BGN_7_8grs8 ... _wm5Mmwk0/

Luns wrote: 02 Apr 2019, 06:31I didn't know the Cypress PSoCs even existed until learning of them here

It is not strictly necessary to use Cypress hardware. You just need the ability to put GPIOs to High-Z and a good ADC.
Cypress is somewhat unique in having _both_ pullup and pulldown on-chip resistors, but external 4k7 will work just fine.
UDBs just make your programming life easier - you assign the variable and eventually receive an interrupt. But nothing that can't be done by the core explicitly.
I actually made a scan module for kiibohd to do all this - the problem was that teensy 2.0 ADC is UNBELIEVABLY shitty.

Does anyone have compiled binaries for the configuration tool? I am having trouble building, both on windows and linux

Windows binaries are in releases section. https://github.com/dmaone/CommonSense/r ... tag/v0.2.1 supposed to be latest.

What are linux build errors?

Thanks DMA! The windows binaries are exactly what I needed to get up and running. Unfortunately I continued to tinker and didn't see your message until now, after I eventually got it to work . This is great though, since I didn't build a static version.

I think the linux issues I was having was just getting all the dependencies, but I don't recall where I left that.

But now I'm all set to start configuring. I do have another very basic question:

Does CommonSense sense with the rows or cols?

I'm working on converting a Fortune Systems keyboard with Digitran leaf spring switches. The mechanism on the PCB has the pads connected as rows and the leaf springs as cols.



Should the leaf spring be the one that is strobing and the pad sensing?

For what it's worth, I've tried switching back and forth between the two and it seems to function the same either way I configure it. Thanks again!

It didn't matter so far which side you drive. But for those switches it may.
But since you tested both ways and they seem not to differ - drive rows, because only 8 driving pins are possible right now.

It's not that it's hard to add more - but since all pins must be assigned it will require 100-pin MCU package => custom hardware.
The "$10 COTS hardware" capability is too important to lose.

Thanks again, really. I got up and running with this keyboard and everything works flawlessly.

I've been working on CommonSense quick-start guide aimed at non-technical folks. Hoping to finish it up and post later today.

I have a 3278 I'm trying to convert. I'm having trouble getting a clear picture of how to use the CY8CKIT-059 device to achieve this, could someone help me out? Thanks.

Does CommonSense support a solenoid / solenoid driver like the Xwhatsit's?

@PancakeMSTR what part of picture is unclear?

@JP! - yes, ExpHdr pins are for that. ExpHdr_0 and ExpHdr_2 will be solenoid driver active pins if you select "solenoid" in hardware setup.

DMA wrote: 16 Jul 2019, 18:45 @PancakeMSTR what part of picture is unclear?

@JP! - yes, ExpHdr pins are for that. ExpHdr_0 and ExpHdr_2 will be solenoid driver active pins if you select "solenoid" in hardware setup.

DMA wrote: 16 Jul 2019, 18:45 @PancakeMSTR what part of picture is unclear?

@JP! - yes, ExpHdr pins are for that. ExpHdr_0 and ExpHdr_2 will be solenoid driver active pins if you select "solenoid" in hardware setup.

• How do I wire the 3278 pinouts to the controller?

• Do I use xwhatsit's solenoid driver?

• What do I do once it's wired up?I.e., what steps do I need to take to program the controller once it's wired up?

Any help is greatly appreciated.

* you should figure that out yourself. Who knows what pinout _your_ PCB has.
* you can, although I can't personally understand why would one trade beamspring sound to an ersatz-typewriter. You can figure out how by reading the source, of course - but I'll add a README section about that thing.
* read the documentation. It tells you. The most complicated thing is making sure you wired your controller to PCB properly and chosen proper switch type when building firmware. The most finicky thing after you connected the controller is configuring thresholds - but it's described in enough detail - once you see the interface it will be obvious.

• you should figure that out yourself. Who knows what pinout _your_ PCB has.

You misunderstand the question entirely. I'm not asking for the problem of my specific keyboard to be solved, I'm asking for the general steps that need to be taken, the logic that needs to be followed, to wire the board pinouts to the controller. I'm asking for a guide, with examples, on how to solve the problem for any board, not mine specifically.

• you can, although I can't personally understand why would one trade beamspring sound to an ersatz-typewriter. You can figure out how by reading the source, of course - but I'll add a README section about that thing.

Because I want to, and I want to know how, and I don't know how.

• read the documentation. It tells you. The most complicated thing is making sure you wired your controller to PCB properly and chosen proper switch type when building firmware. The most finicky thing after you connected the controller is configuring thresholds - but it's described in enough detail - once you see the interface it will be obvious.

What documentation? Read up on how to write basic guides/tutorials/instruction manuals. I looked at the documentation on the github repo and it's barebones. Let me explain why this matters: If you want people to use your method, they are gonna be a lot more receptive if they see a guide that looks approachable. Otherwise, the concern is that they are gonna dump a bunch of time, effort, and money into a project that they have no idea if it is gonna work or not.


One of the main takeaways here is that we aren't experts, you are! And we need and are asking for help, because we will miss and mess up things that are so basic to you that you probably don't even think about them.

[Fortunately], someone has taken the initiative to start writing a beginner's/non-expert's guide, which having skimmed it already makes me 100x more confident I can actually use this method to convert my beamspring. Whereas, originally, I completely ignored your method in lieu of an xwhatsit due to lack of a clear guide.

"If you want people to use your method" - ooh, that's where you got me completely wrong. I don't. I'd rather not have people who value their time above mine and are concerned about dumping $10 for something that may not work. It just doesn't worth it.
Sorry for asking in another thread about why would you use xwhatsit over CS. I shouldn't have.

I'll update the readme to state all this explicitly.