Dangerous Prototypes

(http://http://kaspar.h1x.com/nomech_mini-0.1-alpha-brd.svg)
(http://http://kaspar.h1x.com/nomech_mini-0.1-alpha-brd_back.svg)

So this is a 4x4 projected capactive touch board using Atmega32u4 and back-fire LEDs for each button. I want to send the gerbers to Seeed sooon so any advice/feedback is very much appreciated.

It fits SoB 100x80mm but the top acrylic will sit right on top of the PCB as the dielectric properties of whatever is touching the electrodes matters a lot.

If this works well then I might scale it up to 8x8. I want it to work as a cheap monome (http://http://monome.org/) replacement without using mechanical buttons; hence the name "nomech".

This is designed using KiCAD.

• everything on github (http://https://github.com/kasbah/nomech_mini-hw)
• everything as a zip (http://https://github.com/kasbah/nomech_mini-hw/archive/v0.1.zip)

Everything is licensed CC-BY-SA-3.0

(http://http://creativecommons.org/licenses/by-sa/3.0/)

Nice project.

The buttons are very close. You may have some problems with adjacency with the buttons and misaligned touches, even though you have guard-rings. Especially with people that have large fingertips. Something you will need to test with different dielectrics and thickness.

If you want to replace mechanical buttons, then you have to be very careful about response-time, which is very important with the monome. Capacitive touch sensors are not the fastest interactions if you care about stability. Also, the use of USB can inject line-noise and that can make life very difficult.

With all that said, I'd really want to hear your experience while developing this project as it may be a universal usable keyboard for many other uses as well.

Thanks Bertho!

The buttons are very close. You may have some problems with adjacency with the buttons and misaligned touches, even though you have guard-rings. Especially with people that have large fingertips. Something you will need to test with different dielectrics and thickness.

I will have to test with some fat-fingered people :D
Those are actually not guard-rings but the driving electrodes. What I am trying is very similar to and he has some code I can copy/learn from.

(http://http)

If you want to replace mechanical buttons, then you have to be very careful about response-time, which is very important with the monome. Capacitive touch sensors are not the fastest interactions if you care about stability. Also, the use of USB can inject line-noise and that can make life very difficult.

Yeah, I guess one of my main worries is that the MCU won't be beefy enough for all the DSP that needs to be done. If I have trouble with line noise then that's another matter.

I will post my results either way though.

Yea, definitely an interesting project.  I've been wanting to do something with the capacitive touch sensors that are builtin in the modern pic/avr microcontrollers for a while now...

I read that having leds under the touch sensors can be problematic as well since the readings differ depending if the led is on or not.

Anyhow, keep us posted.

It's not really builtin. Logic pins are doing the driving and [s:]ADCs are[/s:] the analog comparator (AC) is doing the sensing. That you can use an [s:]ADC[/s:] AC pin as a logic pin is essential for this design and the ADC sampling capacitor is useful for single-electrode designs as you don't need any additional components.

Yeah, the LEDs might be a problem. I have followed Atmel's recommendations but we shall see. That's why I am not going for 8x8 right away.

EDIT: Corrections after realizing the ADC is not involved in this design.

If the LEDs do affect the keys, would it be possible to compensate?

If the LEDs do affect the keys, would it be possible to compensate?

Maybe, I am havn't spent enough time looking at what the analog readings should look like. It will be easier to do when I have the boards anyway.

I have sent off the gerbers after stitching the ground plane a bit more, removing an unconnnected track and making some of the outside text invisble. I will update the main post from v0.1-alpha to v0.1 and then post some pics when I get the boards.

I ordered 5x PCBS in white and 5 SoB-DP10080 acrylic plates as well (makes two and a half cases). Anyone interested in a PCB?

A few hours after sending of the gerbers I realised a stupid mistake. If the top acrylic is going to sit right on top of the PCB then I should have used an SMT ISP header (on the component side). I contacted Seeed but it was too late as it's gone into production.

I have thought about a few solutions:

• Hack up an ISP connector/jig that is semi-permanent and doesn't require soldering to the board
• Do a really temp connection to the ISP and just get a bootloader on it ASAP (but connecting a button force-load it will be a problem too)
• Try and solder a header on the component side only
• Cut/engrave the top acrylic to make room for header legs

I like one and two the best as they have no effect on the look of the device. Two might be the least amount of work if I come up with a clever way to load the bootloader. How does Arduino trigger the bootloader from their IDE? Is it routine in the main program that's automatically included?

You can solder the header on the component/solder side without it protruding to the other side. Alternatively, just put some wires on the side that does not get covered.

Prototypes are prototypes. There are always things that need to be changed. With capacitive sensing, you may need several versions before you have the (semi-)optimal setup. I do not think that I've made one single board in my life that was exactly right the first time. There are always some details that pop up later on.

So I got the PCBs last week. I got 12 total even tough I had only ordered 5. Likely because they ran a white panel just for me. Thanks Seeed!

I scrambled to order the parts and ordered some wrong LEDs. I decided to solder one up without LEDs and just the bare minimum to get cap sensing done and sent over USB. I ended up soldering the ISP-header on the component side as suggested and I am keeping that side open for the time being as I like to poke around the board with a scope.

(http://http://i.imgur.com/qPIZDxG.jpg)
(http://http://i.imgur.com/S16JAGm.jpg)

One of the first things I noticed before soldering was that I failed to take the routing bit size into account when drawing the cut-outs for the LEDs. They will still fit the LEDs fine but they don't look very nice.

(http://http://i.imgur.com/Z3ytZjf.png)

So after some wrangling with the code I got the charging and discharging of the sampling capacitor working.
CH1 is the slope pin which is used for discharging the sample capacitor (and then measuring the time it takes to discharge ).

These are the pulses on the drive side.

(http://http://i.imgur.com/yqvbRe6.gif)

This is what the bottom of the sampling capacitor looks like. You can see it charge up and then discharge when the slope pin goes high.

(http://http://i.imgur.com/7RRcpdT.gif)

Eventually I got the AVR interrupts to work and could actually measure the time to zero crossing. I took some measurements which I can use as a baseline as I add components and change the code.

(http://http://nbviewer.ipython.org/5985435)
See this IPython notebook for details. (http://http://nbviewer.ipython.org/5985435)

But there you have it. It is sensing touch so I am pretty chuffed! I am yet to discover how robust it is.

EDIT: Code is up on github too: https://github.com/kasbah/nomech_mini-code (https://github.com/kasbah/nomech_mini-code)

hi,
It looks great :)

I understand the yellow line, it is the capacitor discharging and charging. But I don't understand the blue line :s

The yellow line is actually the slope which causes the capacitor to discharge. The blue line in the first screenshot is the charge pump which is on the bigger electrodes.

The blue line in the second screenshot is the bottom of one of the capacitor accumulating a negative voltage and then discharging when the slope goes high. When it is discharging, the time taken to reach 0V is what is measured to see if that electrode has a finger on top of it.

You can read a better explanation of how this all works on svo's project page. (http://http://svo.2.staticpublic.s3-website-us-east-1.amazonaws.com/capsensor/index.en.html)

I have been recording the behavior of this board, still using only one electrode. One thing I noticed right away are some pretty predictable spike(s) when you start reading the serial data, within 200 samples/lines. In these graphs below the blue is the first reading, and the green is a subsequent reading after opening and closing the serial interface programmatically. The y-axis is the charge reading which is reduced if a touch were to occur. The higher it is the more charge there is. So these spikes in charge will occur if I manually stop and close and re-open the serial interface but not if I do it programmatically. Pretty strange. See this IPython notebook for details. (http://http://nbviewer.ipython.org/urls/raw.github.com/kasbah/nomech_mini-code/3d4c909039f1d5822b99ab58f536389efcc71111/tests/quality/Untitled1.ipynb)

(http://http://nbviewer.ipython.org/urls/raw.github.com/kasbah/nomech_mini-code/3d4c909039f1d5822b99ab58f536389efcc71111/tests/quality/Untitled1.ipynb)

I even tried two different programs to read the serial data. (http://http://nbviewer.ipython.org/urls/raw.github.com/kasbah/nomech_mini-code/3d4c909039f1d5822b99ab58f536389efcc71111/tests/quality/initial%2520spike%2520evidence.ipynb)

Then  I took some long term stability readings (http://http://nbviewer.ipython.org/urls/raw.github.com/kasbah/nomech_mini-code/3d4c909039f1d5822b99ab58f536389efcc71111/tests/quality/long%2520term%2520stability%25202.ipynb) which showed a surprising variance in the untouched charge reading when left to run for several hours.

(http://http://nbviewer.ipython.org/urls/raw.github.com/kasbah/nomech_mini-code/3d4c909039f1d5822b99ab58f536389efcc71111/tests/quality/long%2520term%2520stability%25202.ipynb)

So I am not sure what to make of that. The read value varies by a larger extent on it's own that it does when it is touched, i.e. the noise actually exceeds the signal. Of course this is over several hours so the next step is to figure out the maximum frequency of these changes and basically high-pass filter the input before trying to detect a touch.

The spikes in the measurements look like feed-forward noise. The opening/closing of the port may depend on the USB bus state and the OS you are running (start/stop a program involves a lot more work than programmatic open/close) . The activity changes the bus voltage and may feed into the rest of the circuit. I think you, at least, need to add ferrite beads to the power input. You may also need to dampen the entire cable with a (larger) ferrite bead.

Secondly, you need to have a very close look at the power plane layout and decoupling setup/routing. A good power design is paramount to noise immunity.

The long time drift can be caused by many things. The majority can be separated into environmental and electrical. The environmental parameters influence your circuit without physical contact and are mainly related to moisture and local EM-fields (mainly 50/60Hz noise). The electrical parameters are PSU stability and noise injection.

You can distinguish between the two by electrically isolating your test-setup. No computer or (mains) PSU connections allowed. You need optical interfaces and a (very low ESR) battery. The result is an indication of the environment. From that you often can deduce which electrical parameters influence your system.

Environmental fluctuations are normally calibrated out in software by the sample-CPU by readjusting the base-line measurements continuously.

Note 1: it may also help to turn the power-plug 180 degrees at your outlet. This is no joke. The effect of exchanging phase/zero of your mains has influence on how noise propagates and how it couples in/to the environment.

Note 2: If you take power from USB and use it directly, you have lost by default. The USB voltage is very unstable and variations from 4.5V..5.2V is no exception. The supply needs to be stabilized before you can do anything sensible with it in sensitive electronics.

Wow, thanks for your input Bertho. A lot of stuff to think about there.

I have previously done a USB bus-powered device design with a much higher budget. (http://http://alphasphere.com) There I raised the voltage to 6V with a switching regulator and dropped it back down to 5V with a linear regulator. Additionally I added a lot of EMC filtering following the advice of our consultants.

For this design I wanted to keep it as bare-bones as possible; see how far I can take it. That said, I think I will experiment with adding a linear regulator and just using 3v3 throughout.

Environmental fluctuations are normally calibrated out in software by the sample-CPU by readjusting the base-line measurements continuously.

My thinking at the moment is to set a minimum magnitude and frequency threshold to classify something as a touch. Those fluctuations caused by moisture, temp, EM-fields whatever are hopefully always much slower than a change caused by touch.

I will take some of the other points into consideration and see how I can use them and measure their effects.

To follow up on my previous post... I cloned your repo and looked at the design. There are several things that can give you lots of potential problems:
- Vusb used directly without filtering and no stabilization.
- Vusb missing 10uF bypass (datasheet page 256)
- AVcc filtered by ferrite bead instead of 10uH as suggested (datasheet page 302)
- Split ground-plane on back, connected through 8mil trace and stitches (needs analysis)
- Missing ground-plane parts (needs analysis)
- Small Vcc and GND traces
- Bypass capacitor Vcc/GND connections not aligned to the power they bypass (atmega pin 2, 7 and 14)
- C20 bypass creates a small single winding coil
- Power diversion after decoupling (AVcc takes power after pin 2)

I think I can find more if I look closer.

Edit: A small thing; you need to reorder the libraries in kikad. I got the wrong atmega symbol and needed to move your libs to the top.

Edit 2: I strongly suggest you use 0603 components. They are easier to place and will improve the PCB design.

Wow again! I will try and prototype some of these and use this as a checklist when I do the re-design.

- Split ground-plane on back, connected through 8mil trace and stitches (needs analysis)
- Missing ground-plane parts (needs analysis)

Could you clarify what you mean here? The 8mil trace and stitching is potentially not enough?  Missing how? What kind of analysis?

By the way, would you be interested in a board? I have a lot spare. I am happy to cover the post in exchange for brutally honest criticism of my design, like this.

EDIT: With regards to the KiCAD problem, could you try to checkout the fix_dual_atmega_libs branch (http://https://github.com/kasbah/nomech_mini-hw/tree/fix_dual_atmega_libs) and see if that fixes it? Here it is as a zip (http://http://kaspar.h1x.com/nomech_mini-hw-93dc9a27b.zip) if you don't want to git.

[quote author="kasbah"]Wow again! I will try and prototype some of these and use this as a checklist when I do the re-design.[/quote]
Great. Let us know here so we (I) may make suggestions if necessary.

[quote author="kasbah"]

- Split ground-plane on back, connected through 8mil trace and stitches (needs analysis)
- Missing ground-plane parts (needs analysis)

Could you clarify what you mean here? The 8mil trace and stitching is potentially not enough?  Missing how? What kind of analysis?[/quote]
You need to check what parts of the design are covered by the ground-plane and how currents in it will effect stability. If you force a current to go in circles, then you are no better off and actually introduce a lot of problems. You need to be sure that the ground-plane properly acts as a shield and conductor.

[quote author="kasbah"]By the way, would you be interested in a board? I have a lot spare. I am happy to cover the post in exchange for brutally honest criticism of my design, like this.[/quote]
I'll PM you.
Is there any other way in honest than brutally? ;-) I can sugar-coat everything, but that takes many words and I'd be unsure if the message would get across. As I wrote in another recent post, you learn from your mistakes. But you can only learn from them if you know those mistakes. If you disagree with my analysis, then I appreciate all comments and appreciate precise and concise criticism (even if it would hurt my preconceptions or dent my self-image of invincibility). I too learn from mistakes and are probably a bit ahead in the mistake count ;-)

If you disagree with my analysis, then I appreciate all comments and appreciate precise and concise criticism (even if it would hurt my preconceptions or dent my self-image of invincibility).

I will try and disprove them to the best of my abilities and resources. Only the test results will show us what's what.

Did you see my edit about the KiCAD problem above?

[quote author="kasbah"]Did you see my edit about the KiCAD problem above?[/quote]
Yes, it works.

You also need to do the same for the PCB designer. There the local libs are at the bottom too (you can see that in the .pro file with a text editor).

So I have gone through all the points you raised on the forum and via email Bertho, thanks again for spending time on this.

I posted the ones I definitely agreed with or at least fully understood on the GitHub issue tracker (http://https://github.com/kasbah/nomech_mini-hw/issues?state=open)

Some others I am a bit less clear on.

- Split ground-plane on back, connected through 8mil trace and stitches (needs analysis)

So I guess you are talking about here?

In which case I did reluctantly do that and didn't see a way to avoid it. I thought it's not so bad with two vias on each side connected to the ground plane at the front.

- Missing ground-plane parts (needs analysis)

I could really use some clarification on where you mean here.

- Small Vcc and GND traces

So the rules I used for everything are:

Clearance:    0.2032mm
Track Width:  0.2032mm
Via Dia:      0.899mm
Via Drill:    0.635mm

The width is more than enough for 500mA (which only the power track from the USB could ever theoritically reach) according to the KiCAD calculator:



Which outputs:

- vias are a mess with very small annular ring and large holes

A mess how exactly? I can't increase the via diameter, what would you suggest for the drill?

- C20 bypass creates a small single winding coil

Could you illustrate this so I can verify it and possibly avoid it in the future?

The other thing is that you do not need a resistor for each LED. You can suffice with one set of column resistors. You already need to scan the matrix, so there is no difference and it saves another 12 resistors.

The way I was planning to scan the matrix would allow for one row to be fully illuminated at the same time. It is be possible to scan them one by one but likely at the cost of maximum brightness. The same goes for issue #9 (http://https://github.com/kasbah/nomech_mini-hw/issues/9) actually. I will research further but I really want this to be nice and bright. The LEDs will have to rethought when scaling up to 8x8 anyway though, most likely I will add some shift-registers.

[quote author="kasbah"]Some others I am a bit less clear on.[/quote]
I will try to address the points raised one by one, as much as possible. Going to split into some more posts because some issues need a bit more work to clarify.

[quote author="kasbah"]

- Split ground-plane on back, connected through 8mil trace and stitches (needs analysis)

So I guess you are talking about here?
<snip image>
In which case I did reluctantly do that and didn't see a way to avoid it. I thought it's not so bad with two vias on each side connected to the ground plane at the front.
and
- Missing ground-plane parts (needs analysis)[/quote]
That is one  problem, yes. But I raised the comment on the ground-place on the right side under the atmega. It is actually located on the front (kicad colors confuse me).
The second part (really on the back) is under the USB connector. I do not understand why you removed the ground-plane from the opposite side. It would actually improve the situation to have it available. It would also improve the ground connection to upstream considerably.
That also goes for removing the ground plane from under the atmega (also back). The lone front plane under the atmega should be connected to the extended plane on the back. (I'll make an image to point it out in another post)


[quote author="kasbah"]

- Small Vcc and GND traces

<snip>
The width is more than enough for 500mA (which only the power track from the USB could ever theoretically reach) according to the KiCAD calculator:
<snip>[/quote]
The problem with small traces for Vcc/GND are not of DC resistance, but inductance.

Each trace has inductance, which is unavoidable, and it works against changing current. Small traces create a low-pass filter with the combination of high(er) inductance and DC resistance. It may not be much, but enough to create noise on the power-rails and there you do not want it..


[quote author="kasbah"]

- vias are a mess with very small annular ring and large holes

A mess how exactly? I can't increase the via diameter, what would you suggest for the drill?[/quote]
I suggest 0.4mm drill and 8mil annular ring (0.2032mm annular ring; i.e. 0.4mm drill and 0.8048mm via diameter). Your holes are huge for vias and your annular ring is less than 6mil (most China manufacturer's limit). A 0.4mm hole can support a fully loaded 1.25mm trace. If you have not enough space, then you can go to 0.3mm via-holes (for traces <1mm). Most China PCB have 0.3mm as drill-limit.

[quote author="kasbah"]

The other thing is that you do not need a resistor for each LED. You can suffice with one set of column resistors. You already need to scan the matrix, so there is no difference and it saves another 12 resistors.

The way I was planning to scan the matrix would allow for one row to be fully illuminated at the same time. It is be possible to scan them one by one but likely at the cost of maximum brightness. The same goes for issue #9 (http://https://github.com/kasbah/nomech_mini-hw/issues/9) actually. I will research further but I really want this to be nice and bright. The LEDs will have to rethought when scaling up to 8x8 anyway though, most likely I will add some shift-registers.[/quote]
However, you still do not need 16 resistors. Four will do just fine. Only one row (mosfet driver) is activated at a time. That means that only one led in a column draws current through a top-side mounted resistor (all column-anodes connected and all row-.cathodes connected) You can have all 4 LEDs in all four columns on at the same time...

However, you still do not need 16 resistors. Four will do just fine. Only one row (mosfet driver) is activated at a time. That means that only one led in a column draws current through a top-side mounted resistor (all column-anodes connected and all row-.cathodes connected) You can have all 4 LEDs in all four columns on at the same time...

Ah yes, that _was_ stupid. I'll file a bug.

[quote author="kasbah"]

- C20 bypass creates a small single winding coil

Could you illustrate this so I can verify it and possibly avoid it in the future?[/quote]
[attachment=1]
Green circle: backdoor Vcc connection pin 7 and via (at right side inside circle) connection to C19/L2 +5V after decoupling.
Yellow circle: GND connection loops to decoupling capacitor
Blue circles: GND reference not taken from decoupling capacitor dereferencing the level and reducing the decoupling's effect and introducing noise on the power-rails.

The ground-plane under the atmega is cut short on the right side and I do not fully understand why.

[attachment=0]
Above image shows the decoupling as I would design it (uses 0603). It would be important not to break the ground-plane between ping 2...7 (left side where D+ and D- are routed out) to ensure the USB module's references to be exactly correct.

The trick lies in that no power is extracted after the decoupling capacitor and that the decoupling capacitor is located closely next to the power-leads of the chip. When you look at the pin-placement of the atmega, then you see that Vcc and GND pins are located next to each other. This is done purposefully so you can have the decoupling placed as close as possible. The placement of the GND via and Vcc connection are at the side of the capacitor, which reduces parasitic inductance. The connections ensure that the atmega "sees" the decoupling before anything else.

---

[quote author="Bertho"]
The problem with small traces for Vcc/GND are not of DC resistance, but inductance.

Each trace has inductance, which is unavoidable, and it works against changing current. Small traces create a low-pass filter with the combination of high(er) inductance and DC resistance. It may not be much, but enough to create noise on the power-rails and there you do not want it..
[/quote]
This is an interesting subject, how much change in inductance are we speaking about here?  And do you have any absolute figures?

Is there any degradation serious enough to cause any forseeable problem when decreasing the width of a 3 cm long power trace from say 14 mil down to 7? (When having proper decoupling a few mm's from the vcc pad and a ground plane)

I realize that of course best practices says use a 4-layer board with ground/vcc planes and decouple until you drop. But in real life that might not be possible all the way:-)

[quote author="matseng"][quote author="Bertho"]
The problem with small traces for Vcc/GND are not of DC resistance, but inductance.
Each trace has inductance, which is unavoidable, and it works against changing current. Small traces create a low-pass filter with the combination of high(er) inductance and DC resistance. It may not be much, but enough to create noise on the power-rails and there you do not want it..[/quote]
This is an interesting subject, how much change in inductance are we speaking about here?  And do you have any absolute figures?[/quote]
For example look at http://http://www.analog.com/library/analogdialogue/archives/39-09/layout.html.

[quote author="matseng"]Is there any degradation serious enough to cause any forseeable problem when decreasing the width of a 3 cm long power trace from say 14 mil down to 7? (When having proper decoupling a few mm's from the vcc pad and a ground plane)[/quote]
The difference between a 7mil, 14mil and 25mil trace of 3cm is about 37nH vs. 33nH vs. 30nH resp.
As said, it has a higher inductance, but that is not the whole story. One problem is the impedance of the trace; the DC resistance also increases with smaller traces, increasing the impedance. For higher frequencies, the skin-effect becomes a serious problem with small traces. It will make it even harder to get varying currents through the trace.
The actual performance is also highly dependent which traces are next to the power trace and under it (maybe a GND-plane).

[quote author="matseng"]I realize that of course best practices says use a 4-layer board with ground/vcc planes and decouple until you drop. But in real life that might not be possible all the way:-)[/quote]
Well, not all designs require that much rigorous treatment. It depends on the requirements of your setup. It is often not a question whether or not it will work (for most hobby-type electronics), but how much internal noise and EM interference you are generating.
Another part is how well it will work. If you try to use a 16bit ADC, then you better make sure you have thought about the design(*). If you use high frequencies, say >50MHz, then you also will run into walls of trouble if you do not take care (even on a 4-layer). Everything becomes a transmission line(**) and makes life a hell.


(*) A 16bit ADC at 1V input needs to distinguish ~15uV per count. Having 10mV noise on your power supply will not really help and requires power supply rejection ratios >60dB just to get rid of that noise (and over a very broad frequency band). Let us not speak of 18bit ADCs, shall we...

(**) The power supply acts as a transmission line too (also at lower frequencies mainly due to switching currents). If you do not take care, then you will get signals to bounce in the power trace(s) wreaking havoc on EM and noise performance.

Above image shows the decoupling as I would design it (uses 0603). It would be important not to break the ground-plane between ping 2...7 (left side where D+ and D- are routed out) to ensure the USB module's references to be exactly correct.

That does look a lot better than what I have and isn't too different from what I had tried to do but I guess my downfall was routing the signal tracks before the power. The other thing I had in the back of my mind is that I wanted one decoupled power pin to lead to the next if you know what I mean? So that you say you have 10uF at the start and the 100nF and then that goes to the pin, then to another 100nF and to the next pin.That was a tip I had read somewhere but I can't find the source for anymore, does that ring a bell at all?

The ground-plane under the atmega is cut short on the right side and I do not fully understand why.

This was done to keep the ground away from the analog traces. The recommendation was to keep any ground planes, or any traces at all really, as far as possible away from the sense lines. I carried this forward to any of the analog tracks as I just wasn't sure about the effect on them. So what I basically kept the ground plane on the digital and drive side and removed it from the analog (sense) side.

Ok, time for an update...

Kasbah and I have been talking a bit off-board on the project and I designed a new board with experience from the first version going into the result. Also, a test-version of an 8x8 board was designed. Both PCBs came back from manufacturing today and look very nice. More test will be posted as soon as the components arrive and some boards are assembled.
[attachment=1]
[attachment=0]

---

I finally got the components and time to put it all together. Still have to test, but I can see the Atmel's DFU bootloader and no shorts are detected. Some LEDs did light up, so I guess they are mounted correct too.

[attachment=2]
[attachment=0]
[attachment=3]
[attachment=1]

---

A quick update.

I've coded up the 4x4 board and did some measurements. It is running on the 8MHz internal oscillator (runs at 3.3v) and is not optimized in any way. The buttons are (slowly) scanned at ~244 buttons/s or ~15.2 frames/s.

The code calculates an average value for each button (IIR style length 2^2). The result is the current measurement minus the average plus 2048, effectively creating the first derivative biased at 2048 (biased because it would do an unsigned wrap otherwise).
[attachment=0]
Each downward spike is a "button press" and the upward spike a "button release". The last one displayed is my palm touching the entire 4x4 area.

Each button generates a +/-100 count delta, which, in this unoptimized system, is quite nice. You can also see the bleed of the buttons. I'll need to analyze the data a bit more and measure physically to see what can be done to optimize performance.

---

Hey Bertho, would love to look at the code. I think I was scratching my head trying to get to where you are a few weeks back.
This is still through the acrylic right? Have you noticed any good way to set the threshold for actual touch as opposed to hovering above?

Also, what did you use for the graphs? That looks nice.

[quote author="kasbah"]Hey Bertho, would love to look at the code. I think I was scratching my head trying to get to where you are a few weeks back.[/quote]
[attachment=0]
It is a piece of hack-code. Anything else is directly from your git repo. I have not bothered to do anything fancy and there are many things that need to be done yet. I just wanted to get output to see if the hardware worked.

[edit: except that it now runs 8MHz on the internal osc, so the fuses are changed l:0xe2, h:0xdf and e:0xf3.]

The LEDs are also being addressed with this code, just to see if they'd turn on/off as expected (they do).

Please note, there is a small thing in the schematic, where XD3 drives X2 and XD2 drives X3. The labels got swapped. The order is not really important, just annoying when you don't know why something is not working as expected (took me over an hour to see the labels were exchanged).

Also, the LED rows are not consecutive (1, 0, 2, 3 for PD4..7). Layout ease was a preference to software ease.

This is still through the acrylic right? Have you noticed any good way to set the threshold for actual touch as opposed to hovering above?

Yes, this is through the acrylic (the sick of beige one). The thresholds will probably be around 100 counts at the current settings, but there are problems yet to be addressed. The pumping and the rebound from slope-activation (residual charges) have not yet been looked into properly. One channel has a count of ~2100 whereas the others are around 1450. That is an imbalance that I need to look at. The order and default of the output/input/HiZ settings is important and I have not addressed that correctly.

Also, what did you use for the graphs? That looks nice.

Gnuplot (http://www.gnuplot.info/ (http://www.gnuplot.info/)) for the graph, very basic plot command, no fancy stuff done on it.

[attachment=0]
It is a piece of hack-code. Anything else is directly from your git repo. I have not bothered to do anything fancy and there are many things that need to be done yet. I just wanted to get output to see if the hardware worked.

Haha wow, that all looks really different to anything I would have come up with, going to take me a while to understand it. So I guess you moved away from using a timer based drive (pump) just to get something working? Or is there another reason? Also, did you try the pcb_v2_stable branch un-modified?

[quote author="kasbah"]Haha wow, that all looks really different to anything I would have come up with, going to take me a while to understand it. So I guess you moved away from using a timer based drive (pump) just to get something working? Or is there another reason?[/quote]

The basic idea is that there are 16 pump functions, each with the correct pin setup. The functions are generated as macro-expansions and put into an array. Most of the defines expend to constant expressions that set/clear one bit.

There is various bloat in there from testing left, right, up and down and it needs to be cleaned. Sometimes I wish I was an infamous psychic genius and could feel the errors before I coded them :-) Alas, I revert to bloating trail and error for that seems to work too.

I killed the timer based pump because I simply wanted to pump as fast as possible. Using a timer would have generated quite a bit of overhead.

The main loop is triggered by timer 3 to perform a pump/slope on an x/y coordinate. Every time all channels are scanned it will print the result.

Also, did you try the pcb_v2_stable branch un-modified?

No. By the time you sent me the link I was already busy hacking ;-)

Actually, it took me some time to determine that 3.3V is absolutely too low for the 16MHz crystal to function properly. The core apparently runs, USB enumerated, but I got no output and various odd errors. When I moved to 8MHz, I was already too deep into the hack than to build another version less evolved...

Really interesting solution. Did you leave off the 16Mhz oscillator on the build then?

I killed the timer based pump because I simply wanted to pump as fast as possible. Using a timer would have generated quite a bit of overhead.

Oh really? I was under the impression that a timer would be the way to go for the highest speed. I did see it top out at 125kHz or something (can't recall exactly).

[quote author="kasbah"]Really interesting solution. Did you leave off the 16Mhz oscillator on the build then? [/quote]
No, it is on there. You need to short Vcc with VBus (JP1 or on the exposed test pads) to use it.

Quote

I killed the timer based pump because I simply wanted to pump as fast as possible. Using a timer would have generated quite a bit of overhead.

Oh really? I was under the impression that a timer would be the way to go for the highest speed. I did see it top out at 125kHz or something (can't recall exactly).

I'm bit-banging the pump and it runs at ~500kHz with 8Mc master clock.

I have just gotten back to the studio and was able to open your package. The boards look even more beautiful in person!

I programmed it with your new NoMech.c and the new fuse settings and the LEDs blinking scared me a bit! It doesn't seem to enumerate as a USB device though. The DFU bootloader did enumerate before I programmed it.

EDIT: Nevermind, I had the the system clock rate set wrong. Playing with it now :)

What delta do you get from the sensors through the acrylics?  My pads only have a delta of about 35 through soldermask+silk+2.55mm Seeedstudio acrylics.  The counts goes from 695 down to 660 on an average pad.

Without the acrylic it goes from 705 down to 80 (the pad of the finger) or 250 (only the tip)

With the counter timer running at Fosc at 8MHz, I see about 200..250 counts change through 2.55mm acrylic with the finger covering the pad. With only a fingertip it ranges at 100..150.

The count when no finger is there ranges from 1500..2100, depending which pad is measured and it is highly unoptimized and not calibrated in any way at this moment.

These measurements are with 4.7nF holding cap and 1M slope discharge.

When doing it at 5V and 16MHz, then the count values nearly double.

Holy half-dead project Batman!

So I didn't do any work on this project for ages but it was always in the back of my mind. I did engrave a front panel way back when but I wasn't happy with the LED diffusion (it is worse than it looks in the video). I left it in this state for ages. The sensing needs some work as well, obviously.

(http://https://www.youtube.com/watch?v=j1yK75QxzOI)

Then recently I rediscovered a tonematrix flashlet (http://http://dagobah.net/flash/ToneMatrix.swf) similar to the one that got me interested in musical grids in the first place. I was inspired to try and replicate this whole experience in hardware (integrating the audio and everything). So there are a few sides to doing this:

• 1. LED Diffusion
     
• 2. Capacitive Sensing
     
• 3. Audio Synthesis

1. LED Diffusion

I decided to try and make some smaller nicer looking electrodes and use the substrate as an LED diffuser and had some prototypes made.

(http://http://imgur.com/USIR2eX)

I think the diffusion works nicely. An inner layer of acrylic with cutouts to prevent the spill would almost make it perfect but I am not happy with the yellow/green colour of FR4. I read that CEM3 is white and I tried to find some manufacturers for that but as far as I can tell it is actually opaque and wouldn't work as an LED diffuser. If anyone has any suggestion for a solution I am all ears.  I am thinking to revert something closer to the old mode of back-fire LEDs and use some white acrylic (I have some on order).

2. Capacitive Sensing

(http://http://imgur.com/VscY2WJ)

I designed this using a very convoluted process of drawing in InkScape and converting to KiCad using some self-written Haskell program but also converting to Geda-PCB using Pstoedit and merging gerbers together. What a mess. I am hoping to release my SVG program as an easy to use and reliable converter of SVG to KiCad once I make it more user-friendly.

I haven't tried very hard to make capacitive sensing work on this new electrode design. I didn't put any microcontroller on board and I probably want to increase the size of the electrodes anyway so it doesn't seem like it's worth putting the effort in at this point.

3. Audio Synthesis

(http://http://imgur.com/WoEDLNx)

I got myself a Teensy 3.1, mainly because Paul Stroffrogen has been putting loads of effort into an audio library for them (http://https://github.com/PaulStoffregen/Audio). I prototyped some bell sounds in PureData (http://http://puredata.info/) and got as far as mixing some sine waves together on the Teensy.

So that's where I am at currently: waiting on some white acrylic and working on the synthesis. I need to really work on the sensing firmware as well but I can't decide whether to do this on the AVR or try and jump to the ARM (that's on the Teensy) right away.

I put Bertho's design on kitnic.it (a project sharing site I created): https://kitnic.it/boards/github.com/kasbah/nomech/ (https://kitnic.it/boards/github.com/kasbah/nomech/)

This should allow you to easily buy the required parts if you want to build one. The firmware still needs a lot of work unfortunately.

Bertho, let me know if you want the site to link to your GitHub repo instead of my fork.