Project Logs

Collapse

• And then there were three...

  peter jansen • 03/10/2015 at 17:47 • 3 comments

  A quick update -- I was packing up the Arducorder to ship off to @Mike Szczys for the Hackaday Prize booth at SXSW, and thought I'd snap a picture of it fitting snugly in it's new instrument case and shipping enclosure. I hope the folks at SXSW enjoy it, and all the other finalist projects from 2014!

  The other exciting news is that I've /finally/ completed two more Arducorders, with the exception of their enclosures. The original enclosure had some specially machined standoffs inside, and so I'm hoping to put together a slightly modified enclosure with entirely off-the-shelf hardware later this week. Each Arducorder has 7 double-sided PCBs totalling about 200 components, and takes me the equivalent of four full days to assemble (this work is really intended for pick-and-place machines), so it's really incredible to see them when they're finished.

  One of these -- the second one made -- is going to my very excited father, who helped teach me to make, build, solder, and learn from a very young age. I've been tinkering with developing a science tricorder-like device with everything on my sensor wishlist for nearly ten years, and have always said that the second one off the line would be very warmly given to him, as thanks for helping show me the joy of being a scientist, and being a wonderful and supportive dad.

  Developing a complete, modern open source science tricorder-like device has been on my bucket list for a long while, and the Hackaday prize helped me reformulate the project into something tractable enough that it could be designed and built in five months, capable enough that I could include exciting new sensors like micro-spectrometers and high energy particle detectors, and elegant enough that it could make both myself (and, a panel of judges) happy to carry it around in one's pocket. I'm sure like all the other finalists, the last three months were incredibly intense, and between the lab at school and my Arducorder building I was putting in 12 to 16 hour days, every day. I was desperately scared of being knocked out of the competition after the semifinals -- not because I wanted to win, but because I wanted to finish, I knew it would take until the end of October to get there, and I had been pushing myself so hard for so long that I'd likely have collapsed and slept for a week were I knocked out, and lost some steam. I'm extremely grateful that things worked out the way they did, and that the Arducorder is a real, working device that sits on my desk, and has a complete set of plans for folks to build their own, improve upon the design, or use aspects of it for their own projects.

  With the Hackaday Prize 2015 launched today, I'm very excited to see what folks will come up with to help change the world, and make it a better place. I'd like to thank the folks at SupplyFrame for putting this incredible competition together, and helping me make the Arducorder possible.

  Update: More Pictures

  The first three Arducorders that I've built are complete, and they look beautiful. I'd vastly underestimated the time that it would take me to assemble them -- each unit likely has somewhere around 80 hours in it, which is more than double what I was expecting. For those building their own, don't forget that the driver for the touch wheel has a noise threshold that may need to be calibrated for each unit.

  They fit perfectly into a Pelican 1120 case, which are very compact travel cases with plenty of room for extras, like USB drives with firmware.

  Thanks for reading!

• Spectrometer Group Buy, and see the Arducorder at CES!

  peter jansen • 01/07/2015 at 06:37 • 0 comments

  Just a quick update, and my apologies for taking a while to update -- I think I speak for all the Hackaday prize finalists when I say that the push to finish was absolutely exhausting! In the mean time I've been very busy catching up on writing two papers in the lab, visiting with family over the holidays, taking care of a sick kitty, and trying to find a few hours of rest.

  Arducorder at CES
  

  The good folks at Hamamatsu have borrowed the Arducorder this week to help demonstrate their beautiful C12666MA micro-spectrometer in action. If you happen to be at CES, be sure to drop by the Hamamatsu booth to check it out!

  Micro-spectrometer Group Buy

  The C12666MA micro-spectrometer is a beautiful instrument, but it's also not the easiest to get ahold of in small quantities. The folks over at Group Buy (who helped get the FLIR Lepton thermal imager out into the community) have a group buy for the micro-spectrometer at the fantastic price of $180, or about $50 off the regular single-quantity pricing. This is a really fantastic deal, and if you've been assembling your own Arducorder (or would like to experiment with the C12666MA micro-spectrometer), it's a great opportunity. As of writing there are only 4 days left to get in on this group by, so you'll likely want to act quickly.

  Power Switch!
  

  Every designer has aspects of a project that they do well, and places where they could use a little improvement. Power circuits are where I usually need improvement, and I tend to overengineer them for efficiency so much that occasionally they're simply too complex to work on the first revision. The Arducorder has a very good and high-efficiency buck/boost power circuit, but the case design was missing an important element -- the acrylic slider that covers the power switch, and lets you easily turn the unit on! Free yourself from the bounds of having to carry around a tiny screwdriver or paperclip, and cut out this power switch slider :).

  Just a quick update -- thanks for reading!

• Project Video, and Plotly data!

  peter jansen • 10/28/2014 at 06:33 • 1 comment

  
  

  The project video is up! It's been a very busy few weeks building the final revision boards, putting together an enclosure, and adding the final features to the software. I'm absolutely thrilled at the results, and I hope it helps you make little discoveries -- everywhere.

  Connectivity with Plotly
  

  The Arucorder Mini now interfaces with Plotly -- a website that's like social media for data, that I've absolutely fallen in love with. After hours of rearchitecting the Plotly Arduino library (with Chris from Plotly's help -- thanks Chris!), there is now a beautiful, fast library for Arduino that supports multiple streams, blazing fast transfers, and normal plotting functions. Please use it, and send me links to your amazing streams.

  The Arducorder now supports one touch uploading to Plotly -- you can literally pull the device out of your pocket, and in 20 seconds have sensor data streaming or spectra shared with friends on the other side of the planet. It's really incredible, and I'm pleased with the results.

  The data used in the video is all available on the Arducorder Mini Plotly profile. Here are direct links to some of the data, including:

  • Solar Spectrum, Incandescent Spectrum (both black bodies), Flourescent Spectrum (above). I think you can even resolve the deviations from black-body radiation in the solar spectrum to see the O2 lines and Aerosol contributions near the peak!
  • Pulse width histograms for the Barium-133 and Cadmium-109 radioisotope sources

  In addition, I will try to keep some of the data from the live streams used in the video active, including the atmospheric stream, magnetic field stream, radiation stream, and inertial measurement unit stream.

  Build Instructions and Acrylic Case
  

  I've tried to put together a case that would help draw people in, while being functional and easy to construct and disassemble for tinkering. Thanks to Connor and David from Xerocraft for helping me figure out the settings for precision laser engraving, and machining the delrin standoffs!

  Thanks to everyone for their kind words and helpful comments over the project! While designing and building the device is very rewarding, I feel like the real fun is just starting -- actually using the device, and having a reconfigurable scientific multitool to explore the world around us.

  I hope you enjoy the video, and thanks for reading!

• Hardware Revisions -- Preparing for Release

  peter jansen • 10/11/2014 at 05:47 • 6 comments

  After a marathon programming session, the different modules of the software came together wonderfully for the prototype video nearly two weeks ago -- it's been very exciting to see the Arducorder Mini hardware coupled with an attractive and intuitive user interface:

  
  

  Hardware Errata

  I tend to think of first prototypes as a sketch -- in hardware -- that's as close to the final project as time and experience afford, but with the knowledge that for a sufficiently complex project there will always be an errata, or list of items that need to be modified or corrected in the next revision. The idea here is to make our mistakes cheaply so that everything has the best possible chance of working the first time -- and to ensure that we have enough wiggle room to tinker with any critical bits that don't work the first time, so we can quickly narrow down any design changes for the next revision.

  With PCB turn times taking about two weeks, my recent focus has been revising the few issues that popped up when validating the hardware, and sending these new boards off to be made. It's my hope that if everything validates fine, that these boards will be the first official release candidate for the Arducorder Mini.

  Motherboard

  I confess that when I designed most of the first revision boards, I failed to include mount points on the motherboard and capacitive touch board that would allow the whole thing to be placed in an enclosure! This was a bit of an issue, since the motherboard is only 2-layers, and so densely populated that I had to increase the size a small amount (4mm in both width and height) to accommodate four M2 mounting holes. If I was willing to increase the PCB specifications to 4-layers the board would have been significantly less dense and made mounting much easier, but I'd like to keep the specifications as low as possible so that the boards can be made inexpensively, and the open source community can easily modify the designs with the free version of Eagle CAD. I remember years ago reading that when Stephen Hawking was writing A Brief History of Time, his publisher told him that his readership would be halved for every equation he placed in the book. I feel the same about open hardware -- for every barrier I place on people easily modifying the hardware -- expensive software, 4 layer boards, etc -- that it will reduce the reach by at least an order of magnitude. So I'm trying to keep it simple and accessible.

  Other than mechanical considerations -- the four mounting points, and switching to a connector for the capacitive touch board itself with mounting holes -- there are a few minor schematic changes for the motherboard:

  • Added I2C pullup resistors on motherboard
  • Fixed VCC/GND pin swap on two sets of the PIC32 pins
  • The OLED 13V booster VIN is now sourced from the 3.3V regulator instead of the battery. When sourced from the battery and the booster was disabled, the OLED 13V line would be equal to VBAT, causing a few pixels to stay on, and draining the battery a bit.

  These are largely minor changes, and the technical challenge is largely in rerouting big chunks of an existing board for the modifications.

  The capacitive touch wheel board also has largely mechanical modifications to allow it to securely mate with the motherboard, and to mount in a case. The parts have all been moved to the underside of the board (except for the two pushbuttons), leaving a flat surface for some acrylic to mate with for the touch wheel. I'm hoping to have the opportunity to camp out infront of the laser cutter at Xerocraft one evening in the next week or so to design an attractive case with the hardware in hand.

  To help the indicator LEDs for battery charging and programming to shine through to the front face of the enclosure, I've added the small notch along the length of the bottom of the capacitive touch board. Inventables has some back-surface laser-engravable acrylic that looks very interesting, so I've ordered a few pieces and I'm excited to see what some...

  Read more »

• Tile-based User Interface, and Spectrometer Board!

  peter jansen • 09/17/2014 at 06:31 • 1 comment

  User Interface Design

  Visualization and user interface design is a hobby that I really enjoy, and I've been lucky enough to have friends and colleagues who are usability and visualization folks that I've been able to periodically soak information up from.  The open source science tricorders present a really interesting UI problem -- where most mobile devices have at most a few different sensing modalities, here we have 12 different physical sensors, each of which measures between 1 and 3 different things!  What's more, while some of these measurements are single values (like temperature, say 24C), others are vector values (like the three separate 3-axis vectors coming from the MPU9150 -- one vector for acceleration, rotation, and magnetic field strength, giving nine values total, from a single sensor).  In the extreme case, the spectrometer returns a vector of 256 values. That's a lot of data!  I'm really not aware of any other device that comes close to having so many different kinds of sensing data pouring into it constantly, and while this is very exciting, it's also challenging -- we want folks to intuitively browse and navigate through that data very quickly. 

  I've spent the past few weeks researching design concepts for user interfaces by browsing popular design websites, and talking to some friends, and I think I've settled on a very intuitive, attractive, and useful interface design.  I'll confess that I've been working harder, not smarter about this in recent years -- I'd try and design very complicated things that looked like how other people had done mobile devices and visualization (like android phones), which is a fantastic amount of work for a single human being.  Starting this Arducorder mini project almost 4 months ago, and keeping it attractive and capable but tractable has finally helped me work smarter about this, and figure out a lightweight, usable and intuitive interface concept. 

  I like the idea of live tiles.  When done well, it reminds me of Danny Hillis's idea (30 years ago) about maximizing the amount of computing silicon active on a processor at any one time, but attractively applied to data visualization.  Instead of having icons that just take up space and give you a name, here you have tiles that display a live updating value.  This is powerful from a usability perspective -- instead of having to enter each application to obtain this information (which can consume a lot of time), the most important information is available at a glance from many applications.  While this has largely been applied to communication (e.g. messaging), web (weather/news), and I'm sure sensing applications, here we're going to construct an interface  made almost entirely of sensor data. 

  The really interesting aspect (if you're a data abstraction nerd, like me) is that if we consider only this special case -- visualizing sensor data through tiles -- then we can formulate the software engineering aspect of this very elegantly.  If each tile has a sensor data buffer behind it, then we can browse it's most recent data on the top of the tile, then activate the tile to display additional (historical) data and different visualizations.  If we abstract the sensor data buffer into a few different types, like continuous streaming data (from something like a temperature sensor or an accelerometer) and discretely sampled data (from something like a lightning sensor, that only activates when an event occurs), then we can get rid of the idea of an application.  The design concept becomes browsing sensor data buffers first through a high-level tile interface, and then activating an individual buffer and using a suite of generic visualization tools to better explore it. 

  Interface Implementation

  All of the software engineering aside, what the user sees is very attractive -- tiles with live data that they can browse through very quickly with...

  Read more »

• Spectrometer Board Design, and Beginning User Interface

  peter jansen • 09/04/2014 at 02:41 • 0 comments

  A quick update with lots of progress designing the spectrometer (and thermal camera) board, attaching the radiation sensor board, and beginning to work on the low-level routines for the user interface!

  Fast and Efficient Bitmap Rendering

  Now that much of the hardware is in good shape (or being fabbed), I've been working on the low-level software and APIs that would support building an intuitive and attractive user interface. 

  A bit of background -- from my hobby of indie game development in undergrad and participating in the Ludum Dare 48-hour game competitions (a really fun experience!), I've picked up that in a desktop system (and some embedded systems), a graphical user interface is often functionally implemented as a large collection of bitmaps stacked atop each other with transparent layers.  This has the benefit of being able to make large changes to the user interface through editing configuration files that describe which bitmap corresponds to which background or widget or font (instead of recompiling code), and also allows the user interface artist to easily use whatever tools they're most comfortable illustrating in to rapidly iterate without having to use middleware, or (even worse) be constrained to building an interface entirely out of low-level graphics primitives like squares, ellipses, and triangles.

  This is the approach that I'd initially planned on using, but I'd discovered about a month ago when running a display verification test that the ChipKit SD card library has a read speed of around 100k/sec, which puts the time to load and display a bitmap on the order of about one second -- far too slow for an interface.  There are faster libraries like sdfat, but these required more than a solid evening of porting, and at some point you have to put these on the wishlist, accept the constraints, and exploit the benefits of your existing system while architecting it in such a way that you could drop more advanced functionality in later with a minimum of effort. 

  Posterizer Tool

  While loading bitmaps from an SD card is currently slow, the PIC32MX processor that the Chipkit Max32 uses does have 512k of flash memory that (in addition to code) can store bitmaps that can be loaded very quickly.  A full screen (128x128) 16-bit (2bpp) bitmap takes 32k of memory, so we can't fit very many in memory, but if we manage our resources and store things efficiently, we should have plenty of space for backgrounds and widgets and icons in ~128k or so. 

  One way of compressing bitmaps is to reduce the colour depth -- if we can reduce an image from 16-bit colour (64k colours) to 8-bit (256 colours) or 4-bit colour (16 colours), then we can store the image in half to a quarter of the space.  The trick is selecting a smaller colour palette so that the final "posterized" image still looks very good. 

  There are automated algorithms to do this, but they often give non-ideal results, and I want this thing to look /good/.  I've been looking at user interface concept art the last few days to get ideas, and I'd had the idea of having a main menu that showcases a space theme by having a scrolling background under an icon-based main menu with multiple pages of icons, similar to Android.  I grabbed a copy of NASA's amazing public "earth at night" photograph, downsampled it to 256x128, and used manual posterizing tool I quickly put together in Processing to reduce the colour depth to 4-bit, and store the image as a static array in flash.  Despite being 256x128, the image only uses 16k of flash, and the manual conversion (above) is so good compared to an automated algorithm that I would never have known it was poserized if I didn't do it myself!  It also scrolls back and forth at about 50fps, which looks really impressive.  While I'm still deciding the final user interface concept, it was a good test, and a useful tool to compress the graphic assets into flash so that they're...

  Read more »

• Update: Now with 100% more WiFi!

  peter jansen • 08/27/2014 at 06:41 • 2 comments

  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 »

• Quick Update: Capacitive Touch Wheel!

  peter jansen • 08/12/2014 at 03:31 • 3 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...

  Read more »

• Sensor Board Mega-Update!

  peter jansen • 07/29/2014 at 06:14 • 4 comments

  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...

  Read more »

• First Sensor Boards

  peter jansen • 07/16/2014 at 06:42 • 5 comments

  A bunch of the sensor boards arrived this week!  I confess that holding them in your hand is a lot different than seeing them in Eagle CAD -- these new sensor boards are tiny. 

  Modular Sensor Boards

  The first three (of five) sensor boards arrived, with the radiation sensor board (and the touch interface board) arriving a few days later.  The spectrometer board is the only sensor board that still has to be designed, and I'm waiting on laying it out until I have a better idea of how the radiation sensor board fits on the back.  The spectrometer is the largest sensor in the device, but if there's room I might be able to lay it down and make the entire device even thinner -- definitely worth holding off a few weeks on.

  The first thing that struck me is that these sensor boards are *tiny* -- much smaller than any of my previous boards.  They're about the size of the tip of my finger!  I think the idea of utilizing as much real estate on the outside of the device as possible for sensors (rather than just having them all face towards the front) is really a fantastic design idea for keeping the device small. 

  These boards are so tiny that they're a bit of a challenge to attach a solder stencil to. Since invariably many of the parts I use end up having very fine pitches (0.4 to 0.5mm), my favorite method of stenciling is to clamp the board and stencil in a clamp, adjust it so it's aligned, then squeegee on some solder paste.

  Here, the sensor board combining the Honeywell HMC5883L 3-axis magnetometer (left) and the Invensense MPU9150 9-axis accelerometer/gyro/magnetometer (right) is being assembled.

  Here's the board, with solder paste.  Looks good!  The paste on the MPU9150 is a little misaligned by a few tenths of a millimeter, but it tends to sort itself out during the reflow process.  I usually adjust some of the more worrisome looking misaligned paste around with a pair of tweezers before placing the components.

  Here's the board with paste and after the components have been placed.  Time for reflow!

  I tend to reflow most of my boards in a $20 toaster oven.  It sounds crazy the first time you hear it, and you feel crazy the first time you do it, but it usually works out very well.  Sparkfun has a tutorial on converting toaster ovens into reflow ovens, but I live a little more dangerously and just set the heat to maximum and bake -- watching the board like a hawk until it reflows, and then popping it out of the oven immediately after.  

  These sensor boards are /so small/ that they will fall through the grill of the toaster oven, so I've layed this one on an old coaster -- er -- breakout board from another project.  I'm also trying not to snap pictures for too long, since I have to pull it out as soon as it reflows or the parts will cook!

  The finished magnetometer and inertial measurement unit sensor board.  Not shown was attaching the sensor board connector to the back of the board -- a 20 pin double-row 2mm-pitch male connector. 

  I hadn't yet soldered on the sensor board connectors to the motherboard, in part because they were low on stock, so I could only order enough for a few boards. These have alignment pins that go through the board (and make routing a little more challenging), but it's worth it -- they align in exactly the correct, orthogonal orientations. 

  I confess that one of my largest anxieties about this design was the sensor board connectors.  I literally looked through thousands of connectors on Digikey searching for one that was both right-angle, board-to-board, medium-density, strong enough to firmly mechanically support the sensor boards, and larger than a 0.5mm pitch for easy alignment and soldering. There were not many options.  The ones I settled on looked like they would have /exactly/ the right mechanical clearance if the board could be routed within 10 mil of the connector footprint, which is a little tight...

  Read more »

View all 16 project logs