Close

Spectrometer Board Design, and Beginning User Interface

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 09/04/2014 at 02:410 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 quickly available.

Next on the list of graphics routines is an attractive font renderer, which I seem to be spending a lot of time on -- but it's literally the (font) face that the user experiences with every interaction, so it's important to make it a positive experience. 

Spectrometer and Thermal Camera Board

I completed the design for the final sensor board that combines the spectrometer, an LED light source, a low resolution thermal imager, and several light sensors to build a tiny linear polarimeter.  This board has gone through a lot of mental iterations, but I'm very happy with the final design, and for this first iteration I erred on the side of making an instrument-quality sensor module with real utility, at the expense of a BOM that's a little higher than I'd like it.  

A number of folks have written to let me know that earlier this year Hamamatsu released their second-generation miniature spectrometer, the C12666MA micro-spectrometer, which is the only small off-the-shelf spectrometer part that I'm aware of.  At 20x12x10mm, this is a very small part -- even smaller than my open mini spectrometer (!) -- and it's specifications are about an order of magnitude or more better in nearly every way.  The trade-off is of course price, it being about an order of magnitude more expensive, too. But it looks beautiful, and I'm excited to see how it performs, as one of the first entries into the spectroscopic sensor landscape.  

As an aside, one of my central design goals with the Arducorder Mini is to keep everything as accessible as possible -- whether that's using the device, modifying the code, or keeping the cost low enough that it's affordable.  One of the great aspects of this design is that it's modular, and so while it's designed to be a complete multimodal instrument, different sensor boards can be left out (or added at a later date) if price is a concern.  As other lower-priced sensors become available, newer, updated, lower-cost boards can also be released, which is a fantastic design decision. 

Attaching the Radiation Sensor

I've made the plunge and selected the last connector for the design, which is the connector between the motherboard (top) and radiation sensor board (bottom).   This connector is critical to how the whole mechanical structure comes together, so I wanted to take my time and ensure that I chose a connector that would have a good height clearance and a strong mechanical connection. 

Here's the complete stack, from capacitive touch wheel (top), to motherboard, to battery, to radiation sensor backpack, to radiation sensor (bottom).  In the end this connector isn't entirely perfect -- there's about 2mm of extra height that will ultimately increase the thickness of the device a bit, but this is absolutely fine for now, and we can always move to a different connector if a better alternative presents itself.  

It's really rewarding to start to see the device take shape.  If everything goes as planned, the entire first revision (and several second revision boards) should be here and ready to assemble in about two weeks, and several of those are the /really/ cool sensing modalities like the spectrometer and the low-resolution thermal camera, so I'm quite excited to have it all together!

Thanks for reading, and stay tuned!

Discussions