Quick Update: Capacitive Touch Wheel!

A project log for Open Source Science Tricorder

Science in your hand. A pocket-sized instrument capable of visualizing and exploring the world around you.

peter-jansenpeter jansen 08/12/2014 at 03:313 Comments

A quick update -- the capacitive touch wheel is working great!

I've been working through verifying the hardware (since there's a lot of it), and ensuring all the critical hardware bits are working before shifting focus to the software and user interface.  This is largely to make my mistakes cheaply -- it takes two weeks for new sets of boards to arrive, so it's important to figure out any issues sooner rather than later so that they can be sent out for another turn.

The capacitive touch board was one of the first of the half-dozen modular Arducorder Mini boards that I assembled, and one that I've been excited to get working -- it's the first capacitive touch sensor that I've designed.  I mentioned that in an earlier post I'd had trouble contacting the MPR121 capacitive touch sensor on these boards, even after putting together several capacitive touch boards (with progressively less of the board populated, to try and isolate the issue):

Making expensive (in terms of time) mistakes

My normal debug process is to try and isolate the problem -- first to determine if it's a hardware or software issue, then narrow it down to figure out what's going on.  Eagle footprints -- check.  Schematic verified -- check.  Three boards, three different MPR121 Arduino libraries, and one touch board jumpered to an Arduino Due later, the MPR121 still didn't appear to be communicating (while the real time clock on the same board seemed to be communicating fine).  This is a really unusual problem, and I'd convinced myself that as unlikely as it was, it was possible that the MPR121 chips had simply arrived dead, or that they were particularly heat sensitive and not amenable to being reflowed in a toaster oven (although the one I hand soldered made this last alternative less likely). 

To test this I ordered more touch boards (with slight revisions) from OSHPark, more MPR121 ICs from a different supplier, and an MPR121 breakout board from Sparkfun.  The boards arrived this past weekend, and I put one together with the new parts -- same issue, it didn't communicate.  I wired up the Sparkfun MPR121 breakout, and tried three MPR121 libraries (I2CDev, Sparkfun, and Adafruit, who just released one and a breakout to match) and two boards (Chipkit Max32 and Arduino Due) -- same issue.  It's extremely unlikely that parts from two different batches would be bad, and the Sparkfun breakout board should be tested during assembly -- What was going on?

For debugging purposes, I decided to try the same code and wiring on an Arduino Uno, not because I had any reason to expect that it'd be different, but just to see -- being their flagship product, it was likely it'd work, and maybe there was something subtly different with the timings. And it did work!  On goes the logic analyzer to see what's going on!

The MPR121 communicates over I2C, which is a two wire master/slave protocol with a bidirectional data line (SDA) and a clock line (SCL) that's clocked from the master.  Above we see the waveforms for the first communication to the MPR121 using the Adafruit library, with the Due on the top, and the Uno on the bottom.  The interesting thing is that the waveforms are nearly identical, and in both cases the MPR121 is acknowledging the communications by sending the ACK bit at the end of each transfer, but in the case of the Due (and Chipkit), the read commands are not returning data. 

There is one notable difference in the waveforms for the Due and Uno -- during the command to read data from the MPR121, the Uno is correctly sending an I2C "Repeated Start" condition between telling the device it wants to read and actually performing the read, where as the Due is instead sending an I2C "End" followed by a "Start".  In most cases that I've encountered this doesn't appear to be an issue, but the MPR121 datasheet clearly appears to show a "Repeated Start" condition for this transaction, so it's likely this is the culprit. 

Both devices (Uno and Due) were using virtually the same code -- so why was the Due behaving differently?  Some quick searching on the Arduino forum showed that this is apparently a known issue, that Repeated Starts are a new feature in the Wire library, and that they don't appear to be functioning correctly (or are unimplemented) for the Due.  The Chipkit is based on an older version of the Arduino platform (I believe it's around Arduino 0023 compatible), so this feature hadn't yet been implemented.  

I opened up the Chipkit Wire and TwoWireInterface (TWI) libraries and implemented the Repeated Start functionality exposed through the new Wire.endTransmission(sendStop:Boolean) function, and it ended up communicating and working fantastically!  A software issue after all, but rarely do you expect that part of the issue lies with the peripheral libraries -- and it's a great opportunity to push the changes back to the latest Chipkit release so that other folks can benefit.  Open source at work!

I've been expanding the Adafruit library (the simplest one that seemed to just work) with functionality for handling capacitive touch wheels, and calculating the touch angle by finding the center of mass on the N-electrode array, and seeing how it's distributed on the neighbouring electrodes.  I wrote a quick visualization that would display this angle (pictured above, and in the video at the top), and it works beautifully!  I opted to use an 8-electrode capacitive touch wheel to get as much resolution as possible, and it works far better than I had hoped -- it detects even very subtle changes in angle as you slide your finger around the wheel.  Fantastic!

This is a major milestone, and now the Arducorder Mini can finally get some input instead of scrolling through test displays from various sensors automatically.  I still have to implement some of the other MPR121 functionality to the Adafruit library, like GPIO buttons and LEDs, but now that I've verified the critical bits of the MPR121 and that the wheel is working, that's something that can likely wait a little bit while I move on to verify other hardware, like the CC3000. 

Other Quick Updates (Hardware)

Open Mini Spectrometer / Thermal Camera board: I wanted to have this board sent off this week -- it's one of the sensor boards that I'm most excited about -- but it's also one of the most complex.


In preparation for the Hackaday Prize Quarter Finals, I've been preparing to put all the source files (as they currently are) on github.  Since the HDP quarterfinals now only requires a single video that shows the prototype, I'll likely use the Arducorder Mini Project Concept Video that I put together for the first deadline a few weeks ago, since shooting the videos is so fun that it ropes me in for much longer than I should spend on it -- I'm only one person and there's plenty of code and hardware left to develop! :)

Speaking of which, the other night I was /dreaming/ about writing code (this is usually a sign that I need to take a few days off), and my alarm went off before I'd had the chance to finish it. In my half-asleepness, I grabbed my alarm and set it to half an hour later so I could go back to sleep, finish up the code, and commit it to github before waking up again.  Made the whole lab at school laugh this morning.  You know you're committed to open source when...  :)

Thanks for reading, and stay tuned!


peter jansen wrote 08/12/2014 at 17:39 point
Thanks Norman! I've been trying to update every week. Since I'm an artificial intelligence researcher by day, I largely get the bulk of my work on this project done on the weekends. Last weekend was filled with day-trip vacations, so there wasn't a lot of progress to post about. :)

I'd noticed that Heimann imager a few weeks ago -- it looks great, but it'd likely also double the bill of material cost for the project (and might be a little big to fit both a spectrometer and the thermal imager on a single board). One of the wonderful things about the Arducorder Mini design is that it's very modular, so you could design a new modular sensor board with just this thermal imager to take the place of another board.

  Are you sure? yes | no

Noman wrote 08/12/2014 at 17:41 point
Exactly, that's the beauty of your creativity. It is modular & adaptable.

  Are you sure? yes | no

Noman wrote 08/12/2014 at 13:06 point
Wonderful Dr. Jansen. I kept on visiting your project logs during last couple of weeks many time a day, to find nothing and excited that something cool is due to come up, it is here finally. Your project is at top over and above contestant's, because of ingenuity, knowledge, hard work and comprehensiveness.

Your debugging approach has lessons learnt for us all, I found that if apparently everything fine but things not working (as with me in case of Light Blue Bean and Spark Core recently), before ordering check for community, and it worked. Regarding thermal, Heimann HTPA 82x62 or 64x62 has better resolution but has a big price tag attached, somehow Eric got it at lower price.

You are alone but you have come a long way, looking at your dedication that plenty of code and hardware seems little, and you will acomplish it, for sure. You have our best wishes.

  Are you sure? yes | no