Capacitive touch module

SmashedTransistors · 2019-01-30 22:32:56 UTC

With a 10cm x 10cm sensor... That's not really useful for musical apps.

lokki · 2019-01-30 22:52:15 UTC

it depends...the aforementioned theremin could be an application two of those plates, one for volume, one for pitch...

SmashedTransistors · 2019-01-30 23:19:10 UTC

A full sized theremin with a range of about 50cm is very challenging if you want to do something else than sweeps.

I plan to use the touch sensors to get a lot of parameter selectors (one sensor per parameter group). Once a parameter group is selected, I'll use 4 soft pots to enter the values that would be displayed on an OLED... no knobs, flat synth but fast access to the parameters.

The layout would look like that:

mpr121                   softpots            OLED

Param select            Param edit       Param display
                     _    _    _    _
O  O  O  O  O       | |  | |  | |  | |       _____
O  O  O  O  O       | |  | |  | |  | |      |_____|
O  O  O  O  O       | |  | |  | |  | |
O  O  O  O  O       | |  | |  | |  | |
O  O  O  O  O       |_|  |_|  |_|  |_|

lokki · 2019-01-31 07:02:49 UTC

ah nice! curious to see this thing once you have it running.

about theremins: yes, it is very challenging to play the instrument in a "musical" way anyhow, so you will need all the range you can get. on the one i built i had about 2 metres of sensitivity, but i had to adjust that a little, since otherwise my body would also change the pitch and volume

SmashedTransistors · 2019-01-31 21:02:16 UTC

That's quite a sensitive device !! I've made one a long time ago but its range was about 30cm... good enough for sci fi effects from the 50s.

I get my inspiration from the - underrated and forgotten - Akai AX80 : one button per parameter and a knob to change its value.

I'd prefer to access instantly a page of 4 or 6 parameters. In my opinion, softpot (or capacitive slider) are faster to set than a knob: you press it where you want and that's it.

The mpr121 allow to have a lot of buttons with relatively little effort and cost.

With some tips, based on using two pads per touch zone, it may be possible to get more than 12 touch zones per mpr121 (30 or 36). Experimentation will tell me if it's really possible as soon as i receive the mpr121 breakouts.

Something else i want to experiment is capacitive sliders.
I wonder if they can be practically done with mpr121, in step mode or in "analog" mode.
That would cost less than softpots and be more versatile.
https://m.eet.com/media/1158271/cap2fig4b.gif

@deadsy, did you experimented these tips ?

deadsy · 2019-01-31 22:36:09 UTC

The electrode geometries I experimented with were fairly conservative. ie - finger tip size with touch on/off type functionality. I'm looking to make something akin to an omnichord strum plate. If you look at the driver you will see a table of config values in the *.axo that can be used to setup any of the registers of the device. In theory you should be able to tune different electrode configs without having to alter the core driver code.

SmashedTransistors · 2019-02-08 00:06:57 UTC

Hi @deadsy,

I have an incompatibility issue regarding .ram2 memory allocation.

error: _rxbuf causes a section type conflict with pool
   static uint8_t _rxbuf[8]   __attribute__ ((section (".sram2")));
                  ^
In file included from C:\Users\User\DOCUME~1\axoloti/build/xpatch.cpp:1:0:
C:/Users/User/Documents/axoloti/axoloti-contrib/objects/deadsy/mpr121/mpr121.h:121:17: note: 'pool' was declared here

  static uint8_t pool[32] __attribute__ ((section(".sram2")));

In the xpatch.cpp, my _rxbuf and _txbuf are static arrays in a function for each OLED128x64nice class

void setup(){
  static uint8_t _txbuf[132] __attribute__ ((section (".sram2")));
  static uint8_t _rxbuf[8]   __attribute__ ((section (".sram2")));
  txbuf = _txbuf;
  rxbuf = _rxbuf;
  init();
}

As far as i understand, the pool is a static array in a global static function defined in mpr121.h which is intended to be shared by mpr121 classes (in the xpatch.cpp "object instances" are duplicated/renamed classes)

static void *mpr121_malloc(size_t size) {
  static uint8_t pool[32] __attribute__ ((section(".sram2")));
  static uint32_t free = 0;
  void *ptr = NULL;
  // round up to 32-bit alignment
  size = (size + 3) & ~3;
  chSysLock();
  if ((free + size) <= sizeof(pool)) {
    ptr = &pool[free];
    free += size;
  }
  chSysUnlock();
  return ptr;
}

It seems that having a global .sram2 array conflicts with having them inside classes ??
I have no idea how to solve this issue.

deadsy · 2019-02-08 16:16:31 UTC

Let me take a look at it....

SmashedTransistors · 2019-02-08 17:44:57 UTC

Thanks @deadsy

I moved the include code into an axo file in a similar fashion to the OLED objects and it seems to work fine now but i don't really understand why it did not worked with the static mpr121 malloc function.

deadsy · 2019-02-08 18:14:43 UTC

Here's a fix - I'll check it in this weekend after I have tested it a bit more.

diff --git i/objects/deadsy/mpr121/mpr121.h w/objects/deadsy/mpr121/mpr121.h
index f8a6888..067ca93 100644
--- i/objects/deadsy/mpr121/mpr121.h
+++ w/objects/deadsy/mpr121/mpr121.h
@@ -118,7 +118,7 @@ struct mpr121_state {
 // Allocate a 32-bit aligned buffer of size bytes from sram2.
 // The memory pool is big enough for 4 concurrent devices.
 static void *mpr121_malloc(size_t size) {
-       static uint8_t pool[32] __attribute__ ((section(".sram2")));
+       static uint8_t pool[32] __attribute__ ((section(".sram2.x")));
        static uint32_t free = 0;
        void *ptr = NULL;
        // round up to 32-bit alignment

Basically gcc doesn't want to assign two variable of different types to the same segment.
Apparently pool and _rxbuf are considered different types because one is declared in a C++ class.

But - If we say pool is in sram2.x - then that's a different segment so far as gcc is concerned.
Fortunately the linker script assigns sram2.* segments to SRAM2, so we're golden.

axoloti/build/xpatch.map

.sram2          0x2001c000       0xac
 *(.sram2)
 .sram2         0x2001c000       0x8c /home/jasonh/work/axo/axoloti/build/xpatch.o
                0x2001c000                rootc::instanceOLED128x32__2lines__1::setup()::_rxbuf
                0x2001c008                rootc::instanceOLED128x32__2lines__1::setup()::_txbuf
 *(.sram2.*)
 .sram2.x       0x2001c08c       0x20 /home/jasonh/work/axo/axoloti/build/xpatch.o

SmashedTransistors · 2019-02-09 16:32:41 UTC

That's great

I have tweaked an experimental mpr121 object so that i can have a look at the filtered data.

Here is my experimental layout

At the left is a diplexed keypad, it only needs 6 inputs for 15 keys, the trick is that some inputs are shared by keys. As far as i experimented, the sensitivity of the mpr121 allows this trick.

On the right is a ~15 cm long slider... it will be more experimental as i want it to be continuous and only use 6 inputs (diplexing + interpolation).

lokki · 2019-02-09 17:11:59 UTC

why not use a softpot? seems like a "stretch" to use the capacitive sensor for that

SmashedTransistors · 2019-02-09 17:21:27 UTC

Yes, if it works it would be a low cost alternative to softpots.
Another advantage is that i would only need to connect the I2C to get keypad, sliders and OLED working

SmashedTransistors · 2019-02-10 00:21:14 UTC

I experimented somewhat this afternoon.
It is quite difficult to get it working, especially if i don't want to touch the electrodes directly. As I add some plastic film, the sensitivity is OK for normal use but it is slightly problematic with the diplexing trick and for slider interpolation. Maybe I need to find some really thin adhesive plastic film.

I think I'll try to find a good source for 200mm softpots as i plan to use 6 of those

lokki · 2019-02-10 07:14:55 UTC

or you diy:

http://electro-music.com/forum/post-382662.html

apart from that, i ordered them from mouser or digikey, since i could not find a better source. if you find one, please let me know!

SmashedTransistors · 2019-02-10 08:48:09 UTC

I won't try to do it myself, i want to make something reliable

I've ordered 5 x 200mm softpots from mouser right now (I already have one spare).

Even so, i'll continue to experiment with the mpr121

lokki · 2019-02-10 08:58:10 UTC

just be aware, that softpots greatly vary from one to another in linearity etc. so best to use lookup-tables for each if you need uniform response from all of them.

SmashedTransistors · 2019-02-10 09:24:26 UTC

I will use them for data entry with an OLED that will display the values, I think that even a 10% deviation will be OK for that purpose.

This would look like:

mpr121 would be used for 24 touch switches to select params and maybe control some leds.

[EDIT]
Here goes the "Fria synth" (named after queen Fria from Flash Gordon comics).

lokki · 2019-02-20 23:19:13 UTC

great!! looks pretty great to me. how does the mpr121 behave? no "false" touches detected on any of the nearby fields for example? was it straightforward to set up?

SmashedTransistors · 2019-02-20 23:29:18 UTC

Yes, the MPR121 works quite fine.
At the moment i have only one MPR121 (top 12 keys) and it is just under the touch pads (15mm 15mm each) connected with some wrapping wire no longueur than 50mm to avoid parasitic capacitance.
The box is shielded with copper tape. To avoid parasitic capacitance with the shielding, i did not shielded near the touch pads.

I covered the touch plates with a transparent plastic film (as used to cover/protect books).

I experimented with thicker transparent plastic sheets, 1.25mm thick seamed to work fine.