6 days ago •
A quick update, with some of the high-risk high-gain aspects of the project!
CC3000 WiFi Module and ChipKit Library Port
It's great to get out of your comfort zone and learn new skills or expand your familiarity with different aspects of design. For me, in addition to the capacitive touch wheel, I decided to include the popular CC3000 WiFi module from Texas Instruments. I think connectivity fits a lot of the use cases for a science tricorder-like device, from kids using social media to share their sensing and measurements to engage themselves and their friends, to nerdy scientists that spend their entire days in the lab (like me) who would like to push all their raw data to somewhere like data.sparkfun.com for sharing, advanced visualization, or later analysis. Personally, a neat visualization experiment I'd like to try is to sit the Arducorder Mini on my desk for an afternoon when we're expecting a storm, and visualize the storm coming in through data -- the decreasing temperature and pressure, increasing humidity, reducing distance-to-lighting, and it'd be neat to see if any x-rays from close lightning strikes are detectable and coincide with the lightning detection.
This is my first use of a WiFi module in a project, and so my concerns in terms of hardware were routing the antenna traces correctly, and being able to successfully interface with the module using an open library. There are a number of open reference designs for the CC3000 antenna circuit, and space being at a premium I ended up using the same layout as the folks who designed the open Spark Core (thanks Spark team!). In terms of open ilbraries, Adafruit released their CC3000 Library, which was recently ported to the Due, which would give me a trail of github commits to look through when porting to the ChipKit MAX32-based system that the Arducorder Mini is based upon. It all looked good, so I incorporated the CC3000 module into the Arducorder Mini motherboard.
To make a bit of a long story short, I ran into a problem similar to the issue with the capacitive touch sensor requiring the ChipKit I2C library to be updated from the Arduino 0023 libraries to the new Arduino 1.x (post-Due) libraries, to make use of the additional features that have been added in the last few years. With the capacitive touch sensor, it was fairly easy to add the repeated stop condition support from the newer Arduino 1.x I2C/Two-Wire libraries, but the Adafruit CC3000 library is based on the much larger Arduino 1.x ethernet library, so there was a good deal of effort involved -- porting the Adafruit CC3000 library from the AVR/Due to the PIC32 from the top, while simultaneously updating the ChipKit Arduino peripheral libraries from the bottom.
Fully updating the ChipKit libraries to Arduino 1.x would be a full-time task for someone familiar with their inner workings for a good week or two, so it's well beyond the scope of this project -- but after a solid weekend of work I was able to successfully port enough of the Arduino 1.x ethernet library (and its dependencies) to then port the Adafruit CC3000 library to the ChipKit! The picture above shows success, and the Arducorder Mini successfully fetching its first webpage and displaying it over the serial console. Great stuff!
In the end, this means that in order to compile the Arducorer Mini firmware, I'll also have to maintain an updated version of the MPIDE on the github repository. A side effect of this will be that Chipkit folks should be able to enjoy the benefit of some (partial) Arduino 1.x compatibility.
Open Mini Spectrometer
In addition to the WiFi module, the other high-risk high-gain aspect of the Arducorder Mini is creating a new version of the open mini spectrometer suitable for one of the low-profile modular sensor boards. I really needed to build (and not code) last weekend, and have been boring...
Read more »
21 days ago •
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...
Read more »
a month ago •
A big update with lots of pictures -- I've been building and testing many of the first revision sensor boards.
Watching the PWM of your soldering station's power supply!
One of the things I remember most from building the Open Source Science Tricorder Mark 1 is that the moment I had it built and programmed -- around 2am, late one weekend, doing laundry at my parents house in the finest grad student tradition -- I immediately looked around for things to sense. The magnetometer visualization on the Mark 1 was always my favorite, and holding the Mark 1 up to a wall-mount power supply I was able to see the fields of the transformer bouncing back and forth, only moments after finishing the device. Definitely very cool, and very memorable. Years later we were hunting down some high magnetic fields in a mens washroom under an NMR lab at school, which is probably the second most memorable (and probably one of the most hilarious) moments of science I've had.
I decided that, with many of the Arducorder Mini sensor boards up and running, and a basic multi-series graph visualization plotting the x, y, z (RGB) and total (white) field strengths from the magnetometer, that it'd be interesting to place it near my heavy soldering station -- heavy from a big transformer in its base -- and see what we could see.
The solder station works by pulsing the heater on the soldering iron to keep it at a set temperature. When the internal temperature sensor reads the iron is too cold, it likely pours on the juice to keep it at a given temperature. The neat thing is that this appears to happen in discrete chunks of time a second or two apart -- looking at these two pictures, we can see a roughly sinusoidal magnetic field strength (white line) from the transformer -- my first guess is that this is that this is the 60Hz line frequency aliased by whatever the sampling frequency is of the magnetometer here (about 20Hz). But, in the first picture, something really interesting is visible -- the field strength suddenly shoots up for half a second, likely signifying that the soldering station has engaged the heater on the iron. Very neat to watch!
And here's a quick video I took while testing the magnetometer (and microphone -- the purple series).
Modular Sensor Boards
I try to make my mistakes cheaply, so recently I've been building as many of the first-revision boards to verify their functionality, and note any issues or modifications for the next revision. Pictured here (above) is the sensor board that contains the lightning, UV, and audio sensors (front), and the atmospheric sensor board that contains the atmospheric sensors like temperature, pressure, and humidity (right).
The same view, but here I've just waved a pair of piers that are slightly magnetic near the Arducorder Mini to show the simple multi-series graph widget. There's still a great deal to do on this widget, but it's a good start for easily graphing a few related sets of data, and the autoscaling feature means it's entirely hands free.
To verify the functionality of the microphone, I wrote something that would pipe the data to a graph, and started singing to watch the waveforms. (Actually, the first thing I did was to put on some music with a beat, put the Arducorder Mini up to the speaker, and see if I could watch both the audio waveform and the magnetic field from the speaker, but I think I'd have to look at the data a little closer or plot it overtop of each other to verify that the field strength changes were correlated with the audio amplitude). Still, very cool for something that's just starting!
The UV sensor also looks to be communicating okay, and the data changes when I place my hand over it, but it'll need a bit more work to verify the measurements. I didn't happen to have a storm handy to test the lightning sensor, but the breakout board I have seems to be particularly good at detecting whenever the air conditioner turns on, so I'll have to work with that until a storm rolls in. :)
Read more »