PCB-only capacitive keyboard?

[amyk]

Note that most if not all of the specialty cap-sense ICs are really just some normal MCU (8051 is common) running some preloaded firmware.

[Nominal Animal]

Thanks for the info on the MPR121. I had come across it too and thought it looked promising -- although you would need quite a few for a full-size keyboard. But if the MPR121 as a dedicated sensor IC still implies speed/precision readeoffs,

Only because I need the high sample rate to be able to calculate a reliable velocity/acceleration values.  For actual touch, i.e. when the sensor capacitance crosses a set limit, it has additional features that make it extremely suitable for those.  I do believe that MPR121 would work perfectly in a touch keyboard, where a finger touching the PCB surface is equivalent to pressing a key there, at least if you use one pin per key (for infinite rollover).  It even has touch and release thresholds you can program for each input separately, so you can trivially compensate for different key electrode shapes if you want.

The Adafruit break-out board is easily available (including at Mouser and Digikey for under 8€), so you might wish to get one to play with.  Copper tape works quite well for electrode experimentation, but you can do with even conductive ink.

LCSC does have MPR121Q in QFN-20 in stock, for $2 apiece in lots of ten, so they're not exactly cheap; and it needs two regulated voltages (3.3V and 1.8V).

I would hope that sensitivity (and hence maximizing the electrode surface) is not critical for a PCB-only keyboard. Since I will only have a thin layer of soldermask and silkscreen on top of the electrodes, I would hope for a pretty strong capacitance change upon touch?

For sure, even a quarter-inch thick glass panel in front won't be a problem.  It acts as a dielectric, so all you need to do is to change the electrode shape or spacing to compensate.

NXP AN3863 (originally from Freescale) contains a lot of useful information on electrode patterns and their effects, and the logic behind.

As others have mentioned, one does not need a dedicated chip for this, especially if one uses a matrix approach.  Each key is then at the intersection of one row electrode and one column electrode.  You measure the capacitance by treating each intersection as a capacitor, and measuring how long it takes for the capacitors to charge or discharge (a set of capacitors at a time, of course).  As seen from MPR121, typical capacitances measured are in the 10pF - 10nF range.

[ebastler]

A quick update on Atmel MCU options, after I took a closer look. Atmel has created a bit of a mess...

There is a "new QTouch library", the use of which is recommended for new designs. This relies on the dedicated Peripheral Touch Controller (PTC) available in some of their MCUs. Atmel provide an online project builder at https://start.atmel.com/ which, once you select "QTouch" in the middleware menu, shows the available microcontrollers: many ATSAMs with ARM core, only a few of the older AVRs. For my Enigma idea I need an MCU with a larger pin count (> 64), and unfortunately none of these is available much sooner than a year from now.

There is also an older QTouch library, which supports non-PTC microcontrollers (not recommended for new designs). A "QTouch Project Builder" is available as an add-on in Microchip Studio. It lets you select the number of buttons and sliders you want, then suggests a list of supported MCUs -- which is pretty short, containing some ATmegas and ATXmegas. Again, these MCUs are currently unavailable.

The ATmega2560 mentioned earlier in this thread and its relatives are not supported in either approach, even though their datasheet claims QTouch support. That information must be outdated; maybe some earlier QTouch library did support these? I guess I am done with Atmel for this project and will look for other MCUs -- although the supply situation at STM and NXP does not look much better...

[MK14]

There are some, example follows:

https://www.digikey.co.uk/en/products/detail/microchip-technology/ATSAMD51P19A-AU/7390336

https://ww1.microchip.com/downloads/en/DeviceDoc/SAM_D5x_E5x_Family_Data_Sheet_DS60001507G.pdf

ARM® Cortex®-M4F SAM D51 Microcontroller IC 32-Bit Single-Core 120MHz 512KB ( 512K x  8 ) FLASH 128-TQFP (14x14)

Peripheral Touch Controller (PTC)
– Capacitive Touch buttons, sliders, and wheels
– Wake-up on touch
– Up to 32 self-capacitance and up to 256 mutual-capacitance channels

With a massive, 2 (claimed) available in stock.

Seems to have 32 capacitive touch channels or 256 mutually capacitive ones (whatever those are?).

I think there are quite a few MCUs, which can do it.  It just seems the component/chip shortages, are making the combined requirements, rather tricky, at the moment.

[tooki]

Seems to have 32 capacitive touch channels or 256 mutually capacitive ones (whatever those are?).

Wiki:

There are two types of capacitive sensing systems: mutual capacitance, where the object (finger, conductive stylus) alters the mutual coupling between row and column electrodes, which are scanned sequentially; and self- or absolute capacitance where the object (such as a finger) loads the sensor or increases the parasitic capacitance to ground.

And in the section on projected capacitive touch sensing:

There are two types of PCT: self capacitance, and mutual capacitance.

Mutual capacitive sensors have a capacitor at each intersection of each row and each column. A 12-by-16 array, for example, would have 192 independent capacitors. A voltage is applied to the rows or columns. Bringing a finger or conductive stylus near the surface of the sensor changes the local electric field which reduces the mutual capacitance. The capacitance change at every individual point on the grid can be measured to accurately determine the touch location by measuring the voltage in the other axis. Mutual capacitance allows multi-touch operation where multiple fingers, palms or styli can be accurately tracked at the same time.

Self-capacitance sensors can have the same X-Y grid as mutual capacitance sensors, but the columns and rows operate independently. With self-capacitance, current senses the capacitive load of a finger on each column or row. This produces a stronger signal than mutual capacitance sensing, but it is unable to resolve accurately more than one finger, which results in "ghosting", or misplaced location sensing.

[ebastler]

Thanks, tooki -- you beat me to it with the explanation on self vs. mutual capacitance sensors. One more addition:

From the datasheets and layout guides I have read over the past days, the consensus seems to be that mutual capacitance sensors are more forgiving regarding the PCB layout. You can have longer traces between MCU and touch sensors, and can place traces, active components or ground layers on the back side of the PCB behind the sensors. Makes sense, since mutual capacitance sensors detect a capacitance change between the two electrodes at a row/column crossing, and do not "see" the capacitance of traces and electrodes vs. their environment.

[MK14]

Thanks, tooki -- you beat me to it with the explanation on self vs. mutual capacitance sensors. One more addition:

From the datasheets and layout guides I have read over the past days, the consensus seems to be that mutual capacitance sensors are more forgiving regarding the PCB layout. You can have longer traces between MCU and touch sensors, and can place traces, active components or ground layers on the back side of the PCB behind the sensors. Makes sense, since mutual capacitance sensors detect a capacitance change between the two electrodes at a row/column crossing, and do not "see" the capacitance of traces and electrodes vs. their environment.

Thanks, that is very interesting.

The ESP-S3's, which are often available and reasonably priced (or at least they have been, with some of the ESP32 range).  Have 14 capacitance sensing pins.
I wonder if you can repurpose them, and use them as a 7 x 7 = 49 matrix (obviously other matrix layouts possible), mutual capacitance sensing keyboard?

ESP32's documentation and/or libraries, are not always the best though.

ESP32's tend to be relatively low pin count, you mentioned wanted lots of pins.  But I think the latest ones, have something like 57 GPIO pins, available, on the best version/variant of the ESP32-S3.  I.e. There are a number of slightly/partly different ESP32-S3's.

EDIT:  No, my mistake, apparently 45 GPIO pins, and maybe the 57 was the total pin count.  Datasheet:

https://www.espressif.com/sites/default/files/documentation/esp32-s3_technical_reference_manual_en.pdf#iomuxgpio

[ebastler]

The ESP-S3's, which are often available and reasonably priced (or at least they have been, with some of the ESP32 range).  Have 14 capacitance sensing pins.
I wonder if you can repurpose them, and use them as a 7 x 7 = 49 matrix (obviously other matrix layouts possible), mutual capacitance sensing keyboard?

Yes, in principle that's how it works. However, at least for the Atmel MCUs (which I reviewed more closely), the matrix needs pairs of pins for each of the colums,  plus one extra pin for the whole arrangement. So 5*4 = 20 sensors is the most you could address with 5 + (4+4) + 1 = 14 pins.

For my "Enigma touch" idea, the pin count adds up quickly: Besides the 26 keyboard keys, one needs four capacitive sliders (to model the rotor wheels), 3-4 further touch buttons for mode settings, a lamp array, and the 26-position plugboard. For the Atmel touch sensor architecture that adds up to approx. 70 I/Os, limiting the choice to larger MCU packages (LQFP-100 or so) if I want to get by with just the one chip.

[MK14]

approx. 70 I/Os, limiting the choice to larger MCU packages (LQFP-100 or so) if I want to get by with just the one chip.

Digikey seem to have around 90 of these, 144 pin TQFP's, PIC32MZ's.

https://www.digikey.co.uk/en/products/detail/microchip-technology/PIC32MZ0512EFF144-I-PH/5323497

The datasheet, confusingly doesn't mention about touch sensing (as far as I can see), at the top, in the features section.  But it does have lots of pins/I/O, including 48 analogue input pins (ADC Channels), which it does seem to mention about using them for capacitive touch sensing, lower down, in the very long datasheet.

They are rather pricey, at $14.78, one-off price.

I stopped looking, but evener high pin count versions of that chip series, I think exist, and MIGHT be available.

[MK14]

The ESP-S3's, which are often available and reasonably priced (or at least they have been, with some of the ESP32 range).  Have 14 capacitance sensing pins.
I wonder if you can repurpose them, and use them as a 7 x 7 = 49 matrix (obviously other matrix layouts possible), mutual capacitance sensing keyboard?

Yes, in principle that's how it works. However, at least for the Atmel MCUs (which I reviewed more closely), the matrix needs pairs of pins for each of the colums,  plus one extra pin for the whole arrangement. So 5*4 = 20 sensors is the most you could address with 5 + (4+4) + 1 = 14 pins.

For my "Enigma touch" idea, the pin count adds up quickly: Besides the 26 keyboard keys, one needs four capacitive sliders (to model the rotor wheels), 3-4 further touch buttons for mode settings, a lamp array, and the 26-position plugboard. For the Atmel touch sensor architecture that adds up to approx. 70 I/Os, limiting the choice to larger MCU packages (LQFP-100 or so) if I want to get by with just the one chip.

I had a somewhat quick check through on this.  It does seem to be 49 (Matrix) Keys, for some of the ESP32 devices, such as the ESP32-S2 and ESP32-S3.  A possible reason for this confusion, is that in some schemes, some of the pins, are actually GPIO pins, not ADC input pins as such.

Just in case, I was wrong on this.  I checked with the ESP32's manafacture's website (Espressif), and this is what they say:

Touch Matrix

Touch matrix button consumes several channels(at least 2 + 2 = 4 channels), it gives a solution to use fewer channels and get more buttons. ESP32-S2 supports up to 49 buttons. Touch matrix button looks like as the picture below:

Webpage in question:
https://docs.espressif.com/projects/esp-idf/en/latest/esp32s2/api-reference/peripherals/touch_element.html

It also seems the ATMEGA2560 with their library (I also checked this), but one of the options (their latest thing, 'the designer/creator') is not available.  But that doesn't stop you from using their libraries.  If I understand things correctly.
Also, alternative, possibly better Atmel (now Microchip), parts seem to be in stock, in Digikey.
But I agree, you may have to use an older version of their software/packages/libraries stuff.
N.B.  I'm definitely NOT sure about the ATMEL stuff.  If you want to use it.  Please DOUBLE CHECK!!!.
I'm not being definitive/exact and could easily be WRONG.  Because ATMEL were taken over, by Microchip, so I don't really pay much attention to ATMEL, in general.  Also the parts shortage, means some of their stuff is very difficult to obtain.
Or to put it into other words, I'd have to spend serious amounts of time reading their datasheets, and building their hardware.  But it's NOT my project, so I don't plan/intend to do it.  So, I'm only indicating a possibility, as regards this thread and Atmel.

Given the apparently wide availability of the ESP32's, both as components (good prices, from what I've seen) and as keenly priced development boards.  Also, that they are rather modern parts, with somewhat fast CPUs, for the price.  I'd be tempted, to give the ESP32's, consideration.
The documentation, is not always, the best.  But if you think the alternative(s) are way over priced and/or unavailable for a claimed 12 months waiting time.  In my book, that is a good excuse for looking at the ESP32's.

In summary, I'm NOT sure you need as many CPU/MCU pins, as you seem to be saying.  (I'm assuming here, that 49 keys, is enough to make all your keyswitches and stuff).
If it isn't, you could still have a pair of ESP32's.

Don't feel pressured, into using ESP32's though.  I'm just trying to level the playing field.  There are many MCU's which can do this.

[ebastler]

Many thanks for looking into this, MK14!

The ESP32s do look tempting indeed -- seems like they have well-developed touch sensing, are cost-effective, and still reasonably available. My only reason not to use them in my current project is the need for many pins, as mentioned above.

I have given up on Atmel as well as Microtech (PICs). With both of them, it seems that capacitivce touch was a thing before 2010 or so, and then they stopped maintaining it. Datasheets mention the hardware capability, but their QTouch or mTouch tools can't be trusted to support it. The ATmega2560 should be supported if you don't use the configuration tool, but then their official library example code required an outdated version of the ASF framework which is nowhere to be found... While I have used the ATtiny and ATMega family a lot, I can't be bothered with documentation and software archeology... Microchip's documentation seems poorer than Atmels in general (even back when it was up to date).

Renesas looks like a strong contender -- well-developed touch functionality, decent and up-to-date documentation. But their MCUs seem geared towards professional customers; I could not find many project examples on the 'net, and many processor types are apparently not stocked by Mouser even in normal times. And I did not feel like learning yet another new IDE...

For the moment I have settled on an STM32 -- after finding one which is actually available. STM has not the greatest touch support: No proper mutual capacitance sensing; keyboard matrices are possible, but they measure the capacitance of the row and column lines independently (capacitance against the environment). So one probably does not get the robustness improvement, and they can't do multi-touch. But I have used STM32 processors before and know my way around their IDE; and their documentation seems current and quite decent.

If and when my "Enigma touch" actually becomes reality, I'll post an update here. I have started to play with component layout and front panel design, but getting the touch hardware and software to work will defnínitely take a while. Maybe a project for the Christmas break?

[tooki]

You do realize that Atmel doesn't exist anymore, since it merged into Microchip?

[MK14]

Many thanks for looking into this, MK14!

The ESP32s do look tempting indeed -- seems like they have well-developed touch sensing, are cost-effective, and still reasonably available. My only reason not to use them in my current project is the need for many pins, as mentioned above.

I have given up on Atmel as well as Microtech (PICs). With both of them, it seems that capacitivce touch was a thing before 2010 or so, and then they stopped maintaining it. Datasheets mention the hardware capability, but their QTouch or mTouch tools can't be trusted to support it. The ATmega2560 should be supported if you don't use the configuration tool, but then their official library example code required an outdated version of the ASF framework which is nowhere to be found... While I have used the ATtiny and ATMega family a lot, I can't be bothered with documentation and software archeology... Microchip's documentation seems poorer than Atmels in general (even back when it was up to date).

Renesas looks like a strong contender -- well-developed touch functionality, decent and up-to-date documentation. But their MCUs seem geared towards professional customers; I could not find many project examples on the 'net, and many processor types are apparently not stocked by Mouser even in normal times. And I did not feel like learning yet another new IDE...

For the moment I have settled on an STM32 -- after finding one which is actually available. STM has not the greatest touch support: No proper mutual capacitance sensing; keyboard matrices are possible, but they measure the capacitance of the row and column lines independently (capacitance against the environment). So one probably does not get the robustness improvement, and they can't do multi-touch. But I have used STM32 processors before and know my way around their IDE; and their documentation seems current and quite decent.

If and when my "Enigma touch" actually becomes reality, I'll post an update here. I have started to play with component layout and front panel design, but getting the touch hardware and software to work will defnínitely take a while. Maybe a project for the Christmas break?

Thanks for the nice, detailed, clear and very quick response.   

That sounds very sensible.  The STM32's, are just (in some cases), suffering from the same component shortages, as other MCUs (give or take a bit).

We are in strange times (component shortage wise).  Despite, having an involvement with electronics, for rather a long time.  I've never seen it like this.  It reminds me of (reports), about World War 2, where all sorts of items were (understandably), in short supply or unavailable.

You hadn't seemed to post in the thread for a while, so I was somewhat confused as to what had happened.

I was always somewhat fascinated by touch panels.  With the early/original CMOS logic devices (4000 series), you just needed to forget to connect an input, to accidentally create a touch switch effect.

The complication (my own issue), that I have with some of the modern MCUs.  Is they can have data manuals/guides, which can total 15,000 pages (very, very approximate number indeed).  Which (unlike the old days, when the MCU databook, was something you could physically obtain, and potentially read its 250..500+ or so (estimated) pages, over a quiet weekend, and then (feel like you) know almost everything there is about that MCU.
Also the 8 bit (original) MCUs, were so much easier to use, in days of old.

Things can get rather scary (data sheet/book) wise, these days.  My mind still gets blown by the functionality, of the very high end MCUs these days.  Even things like Ethernet, graphics, full cryptographic systems, etc, can be built in.  Probably more functionality and computing power, than a typical standard PC, from perhaps 30 years ago (very approximately).

It seems to boil down to learning new skills, whereby you have to accept, reading the entire range of data books/sheets and app notes, on a particular (high end), MCU, is not especially practicable.  So, limiting oneself, to searching or seeking out the relevant sections, is what seems to be best.

You seem just right as regards Renesas.

You do realize that Atmel doesn't exist anymore, since it merged into Microchip?

Yes, I know.  But some of their chips, such as the Arduino ones, still seem quite popular, and have quite a lot of projects and information available, for them.

[ebastler]

You do realize that Atmel doesn't exist anymore, since it merged into Microchip?

Yes, sure. But Microchip continues to make the former Atmel product lines in parallel with their PICs (for the time being). To avoid confusion between the product lines, I tend to still refer to the AVRs as "Atmel microcontrollers".

Microchip themselves are a bit inconsistent in their use of the brand: "Atmel Studio" is now "Microchip Studio", but many of the data sheets and software components still go by the Atmel name.

[tooki]

You do realize that Atmel doesn't exist anymore, since it merged into Microchip?

Yes, I know.  But some of their chips, such as the Arduino ones, still seem quite popular, and have quite a lot of projects and information available, for them.

The products still exist, it's the company that doesn't. They're now Microchip.

[ebastler]

A quick follow-up here. A week ago I have received my PCBs for a design using capacitive touch keys and sliders, built around the STM32F373. (A part which is somewhat available, has the required number of I/Os, and is from a manufacturer who's IDE I have used before, with limited grinding of teeth.)

Unfortunately STM's implementation -- hardware, documentation, TSL touch sensing library, and HAL code generator -- turns out to be buggy as hell. A few finds from the past week:

• Three touch inputs which the datasheet declares as "limited sensitivity, recommend you don't use them" are simply not supported at all by the TSL touch library.
• Two further inputs for which the datasheet does not mention any restrictions are not supported either.
• Under unclear circumstances the STM32Cube code generator creates a total mess of configuration code, e.g. by duplicating some input channel declarations and dropping others. Deleting all touch sensor assignments in the GUI and starting over seems the only way to resolve this.
• The raw data generated by the individual capacitive slider electrodes are in the range of 1000 to 6000 counts. But the GUI only lets you select a threshold of 0..255 to detect active sensors. Clearly a scaling error in the slider implementation; the touch buttons' raw data scale properly.
• There is a dedicated app note explaining how to determine correction factors for the sliders, to balance out asymmetries in the response of their individual electrodes. But you can't enter these factors into the library's configuration data, since the code generator will insist on overwriting them with the default values of 1.0 every time you run it.
• No matter whether raw data are corrected or not, the touch position calculated for the linear sliders is essentially a random number.

Since I have designed the present board around the STM32, I will try to muddle through for this project. But unless some major revelations occur, I don't think STM32 will be my platform of choice if I ever revisit capacitive touch...