06/07/2014 at 04:36 •
I think it'd make a wonderful story to say that the fellow who designed real science tricorders made it into space, and so I've started the next chapter in my project.
Two years ago I introduced the Open Source Science Tricorders, which are handheld scientific measurement and visualization tools that can sense a bunch of things around them. They're basically real-world devices inspired by the fictitious devices used on the television series Star Trek. Where the devices used on the TV show were plot devices that allowed the science team to measure all sorts of things like neutron fields from stars or warp field distortions, my open source science tricorders also put nearly a dozen different sensing modalities into a single handheld device -- sensing a variety of atmospheric measurements (such as atmospheric temperature, pressure, or humidity), electromagnetic properties (such as magnetic fields, light intensity, colour, linear polarization, and IR temperature), and spatial measurements (including ultrasonic distance, GPS location, and an inertial measurement unit with accelerometers and gyros). The schematics, diagrams, documentation, pictures, and other source files were published on the Open Source Science Tricorder project website.
The reception was positively overwhelming. In just over a day around 100,000 people had come to the website and viewed the video. My inbox overflowed with people who loved the project, who wanted their own science tricorder to do citizen science, who wanted to contribute, as well as absolutely interesting and knowledgeable folks getting in touch. I was incredibly encouraged by the community enthusiasm, and gave a bunch of talks about open source science tricorders and their potential for science education.
Probably the most unreal of those public outreach talks was at TEDxBrussels, where I was on the bill with Woz, astronaut Yvonne Cagle, fellow maker Mitch Altman, and tons of other incredibly talented folks. As an academic I'm used to giving technical talks or lectures infront of a hundred or so folks, but the energy of standing infront of 2,200 people in one of the world's oldest opera houses was an incredible experience.
Where are we, and where are we going?
A bit of background -- above, we can see six different prototypes of the open source science tricorder. From top to bottom:
- The PIC powered Mark 1
- The Linux-powered dual OLED Mark 2
- The prototype Mark 3, an experiment in making something in a form factor like a modern phone, with only a single screen, and swapable sensor boards.
- The small prototype Mark 4, a bluetooth-connected "key fob" form factor with only a few sensors. This was largely an experiment in sensor fusion designed to make low-cost thermal images (some of these are in the TEDxBrussels talk)
- The prototype Mark 5a, which returned to having a broad array of onboard sensing capabilities, and a Linux-powered processor. WiFi issues made continuing development difficult.
- The prototype Mark 5b Arducorder, an experiment in creating a platform for sensing that is extremely accessible for beginners and advanced users alike, allowing for easy reprogramming and community hardware development. While most of the sensing components work fine, there are some issues with the new bleeding-edge display hardware, and (because of this novel hardware) not many other working examples or opportunities for community support just yet.
Unfortunately even the Mark 5b Arducorder was a bit ambitious, and used a variety of brand-new release parts and a completely different processor than I'm used to. As it stands, it would require a major redesign to get it functional and meet the design philosophy and goals, and one might as well take a step back and redesign things to be a bit simpler, with a higher chance of success.
Some pictures of the Mark5b last weekend, during development:
Finally getting the FT800 and 2.8" TFT in RGB mode to work on the Mark 5b Arducorder
Which took a little bit of hot-wiring...
And using a completely different board. Here, the ChipKit MAX32 with a PIC32MX microcontroller is connected to the SPI bus, where it can communicate with the FT800 display controller, the 2.8" TFT display, and the SD card.
I usually try to have a few different projects on the go -- one long term, one short term, and one somewhere in between. When you get burned out on one and need a change of pace, you can switch to another and still be productive, innovative, and pick up a bunch of new skills, which is better than spending a few off weeks practicing your web browsing skills.
The most recent of these projects is the Open Source Computed Tomography Scanner (or Open CT Scanner), which is an inexpensive desktop-sized CT scanner that I designed to become more hands-on familiar with computed imagery, as well as try my hand at non-traditional design elements and radically reduce the cost of a conventional device by making it entirely with rapid prototyping tools (in this case, a laser cutter). The project was recently featured in the homebrew section of Make Magazine Volume 38, which was really fantastic. This project also had a lot of hands-on time and experience with radiation sensing, and involved modifying an off-the-shelf sensor to be much more efficient -- something that will benefit the next open source science tricorder.
Earlier in the year, I also designed something I've been dreaming about since the Mark 1 -- a tiny, embedded visible light spectrometer. Spectrometers are used for chemical analysis or to determine the composition of an object, and there's been a lot of buzz the past few years about designing tiny spectrometers on a chip that can fit inside phones or other mobile devices. Still, there are few offerings that you can purchase, and I'm not aware of any that are at all inexpensive. There's definitely a lot of interest in this space though, and there are a bunch of folks that make enormous papercraft spectroscopes to attach to the cameras on their phones to begin to look at this.
The Open 3D-Printable Mini Spectrometer tries to address these issues by having a complete miniature visible light spectrometer suitable for embedded systems. With a digital interface you can easily connect it up to a microcontroller (like an Arduino), and away you go. It's also comparatively very inexpensive, with a parts cost of around $20. The entire spectrometer is around 1 x 2 x 2cm in volume, making it small enough to fit inside an open source science tricorder!
Where we're going -- the vision, and importance of the open source community
Something that I've not discussed before is the idea of a community, and how I learned it's importance to an open source project. When I released the source to the first two science tricorders, I poured a great deal of effort into cleaning and documenting the source files, building a website full of additional documentation and pictures, and filming a short video that would get folks really excited about them. It all worked fantastically, and the scope of the reach was positively overwhelming. But I'd failed to take into account that no matter how excited folks were, they still had to have a great deal of fairly advanced technical skills both in hardware and embedded programming in order to build their own, let alone contribute to the project. And so rather than form a community of open source science tricorder builders and developers, tinkerers, citizen scientists, and curious folks like I'd hoped, I was instead successful at forming a giant group of folks who are incredibly excited about science tricorders and want to be in that community, but need a little help.
It was a big learning experience for me. Where I'd designed the first two science tricorders for myself, my design focus had to shift -- I'd design them for the community. Infact, if I designed them right, they'd help build the community, by virtue of getting folks excited about learning, sensing, visualization, and being accessible. I think this is why it's taking so long to make a prototype that feels right -- I could always put together something designed for myself, again, since dealing with scale and the scope of accessibility is such a difficult task to balance -- but that wouldn't further the mission, and wouldn't build a community.
And so here, we set out together to document the design process of a next-generation, accessible open source science tricorder with the pragmatic aspects of having to keep it simple and low-risk enough to complete in a few months. There's something about a fixed deadline that helps take something from a research project to a complete functioning device, and with a bunch of parts already on their way, I'm excited to get to the design process, and document it here for other Makers, tinkerers, students, and scientists to learn from.
Next up, we'll cover the conceptual illustrations, scale drawings, and likely initial hardware specifications.
Thanks for reading!
About the Author
Peter Jansen is a Postdoctoral Research Fellow in artificial intelligence at the University of Arizona, where he works to try to teach computers how to learn and infer with concepts and language. He has an interdisciplinary background (a fancy academic word, meaning that he likes lots of things) in cognitive artificial intelligence, computational neuroscience, astrophysics, optics, and signal processing. As the founder of the Open Source Science Tricorder project and a number of other open projects, he works to further science educational outreach and ground science education through sensing.
06/08/2014 at 04:38 •
Let's have a look and see if we can figure out the project concept and begin the industrial design.
Previous Prototype Concept
Before we put together our new concept, let's have a look at some previous prototypes and see what worked really well, and what needs a bit of improvement.
Mark 1 and Mark 2
The first two models sure are cool -- they look like something straight out of Star Trek, except that they're real! That being said, they're kind of like a concept car -- super cool, but basically a nightmare to design, assemble, or manufacture. There are a bunch of flat flex cables that move power and data from the bottom of the case to the top, and these cables coiled in such a way that they'll fit while also having enough give to make sure everything closes and works properly. I've always known that this joint would be very difficult to manufacture, and a potential point of failure from all the flexing.
That being said, in terms of usability the models aren't just mini computers, they're sensing tools -- and many of those sensors are directional, meaning they have to be pointed at the object of interest in order to analyze it. It often felt a little funny to point the science tricorder at something and have the screen or the interface on an odd angle, so this is something that needs a bit of work.
Pragmatically, in terms of the total amount of case area and volume devoted to sensing, this always felt a bit unbalanced -- nearly all of the sensors were contained in the very front facing outward, with 90% of the device volume devoted to the computational bits, displays, input devices, batteries, and so forth. All very cool, but I think we can do better.
The Mark 5, the most recent prototype
For a case design for the Mark 5, this is what I had been thinking -- something a bit simpler, and easier to manufacture. The whole thing is normally folded (slided?) up, as you can see in this acrylic prototype:
The idea being, that when you want to use it, you would click some tabs on the sides that would automatically slide the whole thing out of its shell, exposing the display, and turning it on:
There are a bunch of really exciting aspects to this design:
- More sensors: There's much more sensor real estate, in spite of having less volume. The sensors are housed at the top, and you can place sensors on both the top and bottom of the board, doubling your outside-facing sensor area.
- Robust: The screen is protected when it's not in use, which is great for kids -- they could toss it into a backpack and not really have to worry. We could also toss it into our pockets with our house keys and not have to worry about it getting scratched or damaged.
There are also a few things that make this design challenging, or could use improvement:
- Size: When unfolded and in use, it feels very large in your hand. It's basically a modern cell phone design with double the length for the case.
- Friction and Mechanics: There's a good deal of friction, and a good deal of mechanics that are involved in making something robust without wear. We don't want folks to have to take their sensing hardware to the mechanic for an oil change, or to have to include lots of expensive parts like rails and bushings, or the associated assembly cost.
But we're getting close!
Rethinking things: Designing for simplicity, usability, and tractability
First, let's have a look at some hardware constraints that'll inform how we go about our design. Many of the design choices depend on each other -- for example, if we choose a large display, we'll also need a processor that has enough RAM to have a frame buffer, or some alternate external display controller (like the FT800).
Display: The display is one of the most critical elements and the one that generally requires the most resources, so we'll start with that. It'd be nice to have something sunlight readable, which means an OLED. Unfortunately mid-range OLEDs (like the ones on the Mark 2) are generally difficult to come by, for various business reasons that display manufacturers have explained to me. This means we will either have a smaller display under 2 inches, or a much larger display on the order of 4-7 inches. Moving to a smaller display greatly simplifies the processor, graphic hardware, and battery requirements, all of which make the device much less expensive. Let's see where we can go with this.
The two largest OLED displays that I've been able to find (with manufacturing lifetimes that I'm told will extend for at least the next few years) are the following:
- ER-OLED015-1 : 1.5" OLED, 128x128 pixels, 16-bit colour. This display seems to be easy to come by, and appears to go under a bunch of different part numbers. The total frame buffer size would be 128 x 128 x 2bpp = 32k .
- UG-6028GDEBF02 : 1.7" OLED, 160x128 pixels 16-bit colour. This one seems to be a little harder to get ahold of. The total frame buffer size would be 160 x 128 x 2bpp = 41k .
Let's choose one of these, with a slight preference to the larger display if we can find an easy and reliable source.
Processor: We'll need something with at least 41k for the frame buffer, with a good amount left for processing. Ideally we'd also like something that folks can reprogram easily. I have a bunch of experience with the PIC Microcontrollers from Microchip, which generally have the highest RAM offerings of any microcontroller I've used.
The ChipKit MAX32 is a port of the Arduino platform to the PIC32 family, and makes use of a PIC32MX795F512L with 128k of RAM, 512k of flash, a zippy 80Mhz processing speed, and a fantastic set of peripherals for interfacing to sensors. The MPLAB IDE by Microchip also has one of my very favorite debuggers, so if we need to break free of the ChipKit IDE and get closer to the core for more advanced features, there are fantastic tools available. The ChipKit also interfaces the PIC32 through an FT232 USB->Serial bridge, which is a very popular and reliable chip.
Sensors: Having a smaller screen means the whole device will be much less wide, but if we're clever and use all sides/faces of the device, we should still be able to fit in a variety of sensors. The sensors that consume a lot of volume could be localized in a small area on the bottom that would allow for some height, where as the other low-profile sensors could be distributed on the sides and front of the device. Ideally these sensor boards can be swapped in and out for newer sensors or different sensing package as they become available.
Here's a candidate list, adapted from the previous open source science tricrorder prototypes:
- Ambient Temperature and Humidity: Measurement Specialties HTU21D
- Ambient Pressure: Bosch Sensortec BMP180
- Multi-gas sensor: SGX-Sensortech MICS-6814
- 3-Axis Magnetometer: Honeywell HMC5883L
- Lightning sensor: AMS AS3935
- X-ray and Gamma Ray Detector: Radiation Watch Type 5
- Low-resolution thermal camera: Melexis MLX90620 16×4
- Home-built linear polarimeter: 2x TAOS TSL2561
- Colorimeter: TAOS TCS3472
- UV: Silicon Labs Si1145
- Open Mini Visible Spectrometer v1 using TAOS TSL1401CL 128-pixel detector, with NeoPixel light source
- Inertial Measurement Unit: Invensense MPU-9150 9-axis (3-axis accelerometer, gyro, and magnetometer)
- Microphone: Analog Devices ADMP401
The two main things missing here are the GPS, and the ultrasonic distance sensor. While a GPS requires about a square inch of hardware, that will just give you a set of coordinates -- in order to display maps, you need a lot more hardware. Phones already do this very well, so this might be a little out of scope (although it's still on the wishlist). The ultrasonic range finder is something that I'd love to include, but it's the largest sensor by a wide margin. I'd absolutely love a small distance detector with a range of 10 meters or so, perhaps optically based, and after the base unit is developed it'll give folks (including myself) a platform to develop and experiment with their own sensor boards and novel sensors.
Input: Because of the smaller screen and slimmer form factor, we're going to have to change from a touch screen to something different. There are two main things the user will have to do with an input device: navigate menus and options, and input text. Let's experiment with two options that fit the size profile, and see how they work. The first is a capacitive ring wheel sensor, that seem to be popular with handheld music players. Because I don't have a lot of experience with capacitive touch sensors, we'll also have a more conventional option as a backup -- a super low profile joystick.
Even the best sounding idea on paper may turn out to feel or work horribly from a usability perspective. So it's great to find (or make) a model that you can hold, manipulate, and get a feel for.
After searching around, just such an item was already handy, the case for the Radiation Watch Type 5 radiation sensor. It even has a perfectly sized circle for where the ring wheel or joystick would be, and the position feels very natural. With a bit of imagination we can think of what it'd be like with a ~30mm screen sitting atop, as well as some extra bulk in the back for the sensor package, and draft up some mock ups to make sure there's enough space for everything.
Mock Ups and Industrial Design
I put together some concept drawings for the industrial design. These are scale drawings, so in addition to describing the look and feel of the device, they're a reference for designing the shape and mechanical bits of the circuit boards.
It's important to make your mistakes cheaply, and so I've separated many of the subsystems onto separate boards. This means that if any issues crop up, we should be able to work on the rest of the project while the board house does another turn of one of the boards. I've separated the capacitive sensing board (because it may end up changing to a joystick or other input device), and the WiFi board (since I don't have a lot of experience with radio modules) from the motherboard. Four individual sensor boards -- front, bottom, and left/right side -- are also separate, for modularity.
Here's the mock up, with the different board layers exposed:
Many breakout boards and parts to evaluate the critical components are on their way, which is very exciting. Next up we'll do some prototyping, then layout the initial board.
Thanks for reading!
06/17/2014 at 07:30 •
A quick update after a weekend of marathon schematic creation and board design...
Schematic and Initial Board Layout
I've completed the first revision of the schematic. The device is using a PIC32MX795F512L microcontroller, which should be plenty of horsepower for the design, have plenty of space for the OLED framebuffer, and the I/Os are entirely mapped to the ChipKit Max32 design. This mini open source science tricorder should be fully programmable using the Arduino-compatible ChipKit MPIDE for beginners, while having an ICD3 header for the advanced power users who want to get close to the bare metal. Here I've also used the 128x128 OLED display, but there should be plenty of breathing room to expand to the 160x128 OLED in the next revision by expanding the board out a few millimeters, with minimal modifications.
I might have gone a little overboard with the sensor connectors, and browsed thousands of connectors on Digikey and Mouser looking for something perfect -- a right angle board-to-board connector that is low-profile, reasonably easy to prototype with, and provides solid mechanical connections. We'll see how these work out!
The sensor headers are also mirrored copies of each other, so that any sensor board should be able to plug into any location -- front, bottom, or either side (although only the bottom slot will have extra height clearance). I erred on exposing a variety of interfaces on the sensor headers to ensure that there'd be enough connectivity options in the future, including SPI, I2C, UART, 3 Analog, and 4 Digital I/O pins. Keeping this interchangeable/mirrored footprint is going to make routing a nightmare, especially on this 2 layer board, but I'm hopeful that it'll be solvable.
Now that most of the parts seem to fit, it's on to the routing!
Prototyping and Evaluation Components
Many of the parts and evaluation board have been trickling in for the new design. In particular, I'm very impressed with the OLED displays -- the colours are bright and vivid, there is a near 180° viewing angle, and I think it'll all look very sharp. They're a bit challenging to photograph well, but absolutely beautiful to the eye in person.
Just a quick update for tonight, thanks for reading, and stay tuned!
06/21/2014 at 22:30 •
Another quick update, now that the motherboard has been sent off to OSH Park to get made.
Motherboard Layout and Routing
I was able to complete the routing on the motherboard in the evenings this week, and sent it off yesterday. Tomorrow I'll be heading off to a conference, so it's great that the boards can get fabbed during this downtime. Some statistics:
- 2 layer design: 7mil minimum trace width, 13mil minimum drill size
- Dimensions: 87mm x 36mm
- Components: 81 components, 312 connections
The main design considerations were ensuring that there was a good routing path for an 8-bit memory lane between the PIC32 and OLED display, ensuring that each of the 4 sensor headers could be populated with 20 pins each (including I2C, SPI, UART, Analog, and Digital I/O pins), and ensuring that the power circuits (a 3.3V high-efficiency buck/boost for the main bus, and a 13V booster for the OLED display) were both layed out correctly.
In the end I think the layout turned out rather well -- the design is well segmented, with (largely) power on the bottom half and data lines on the top half. There was enough space to place the CC3000 wifi module on the motherboard itself, which should reduce the thickness of the device. I'd like to include a real time clock, and though there wasn't room on this revision, I made sure to include a line directly from VBAT to the Touch Interface Board connector, so that I could sneak one on there.
Next up are the capacitive touch wheel board, the 4 sensor boards, and the radiation sensor board. To keep the development pipeline full I'll try to put these together after the conference, and hopefully have them sent off to the board house just in time for the motherboards to come back and be built.
Since we're working on such a short development cycle, I've tried to order any components with long lead times ahead of time. Two of the Radiation Watch Type 5 radiation detectors arrived today (the same type that I used for the Open Source CT Scanner), and with a smaller version of the external comparator board that I designed for the CT scanner, these should be expanded to include detecting lower energy x-ray photons while being small enough to fit into the device!
Just a quick update today -- thanks for reading, and stay tuned!
07/02/2014 at 04:24 •
Another quick update after a weekend marathon of board layout!
Modular Sensor Boards
Recall that in Step 2: Concept and Industrial Design, we decided that the amount of sensing area for a given case size could be maximized by using all sides of the device for sensors. This allows us to design a smaller, more portable device, but also has a bunch of other design benefits, including modularity. By having four separate sensor boards, we can offer our users an upgrade path, and allow folks in the open source community to easily add sensing capabilities without sacrificing the benefit of the existing sensors. From a design standpoint, it also allows us to perfect the design of individual boards without having to do another turn of the entire sensing system, which saves a lot of time. Since the clock is ticking, it's all about making our mistakes cheaply.
I was able to layout the boards more compactly than I had originally thought, reducing their height by 5mm to 15mm -- and ultimately this may reduce the thickness of the entire device by 5mm, which is fantastic. The boards themselves are:
- Atmospheric Sensor Board (left): Containing the ambient temperature, pressure, and humidity sensors, as well as the multigas sensor.
- Inertial Measurement Unit and Magnetometer Board (right): I've coupled these two together purposefully. Inexpensive magnetic field sensors have really advanced in the last decade, moving from simply sensing field strength to giving a 3-axis measurement, allowing you to roughly determine the field direction. The MPU9150 IMU also happens to contain a magnetometer, and I'd like to experiment with advancing this even further by getting range data using the two magnetometers and a bit of geometry.
- Lightning and UV Board (front): The lightning sensor contains an RF antenna and needs a bit of room, so I've placed it on the front. I've also incorporated a UV sensor that's capable of determining the UV index. The UV sensor also contains some very coarse near-field IR distance measurement, and so I've included the LED for this, just incase. This front board also has a little bit of extra width, which was perfect for the MEMS microphone and amplifier circuit.
- Spectroscopy and Thermal Camera Board (bottom): I still have to layout this board, which will house the 3D Printable Mini Embedded Spectrometer, a light source, a low resolution thermal camera, and likely a linear polarimeter. I've had so much luck reducing the height of the rest of the sensor boards, I'm rethinking the layout, and seeing if I have enough room to lay down the spectrometer (saving a good deal of height), and incorporate the polarimeter on the back side of the board the 0th diffraction order so that everything's on the same optical path. That would be very exciting!
In general, I think there are two remarkable things about the sensor board design here. The first is that there's a very low barrier to entry into making your own sensor boards. Three copies of a given sensor board is only around $3 (shipped!) from OSHPark, and only absolute requires a header that's $2 in single quantity, meaning that folks can really and genuinely get into experimenting with rolling their own boards even on a serious budget. Second, the sensor connectors are mirrored, so that you can plug any sensor board into any of the 4 sensor connectors (left, right, front, or bottom), meaning that folks could conceivably mix and match with their own custom designs or upgrade as they see fit with minimal issues. That's great!
Capacitive Touch Interface Board
I like to include something new on each project that I've never used before, to get out of my comfort zone and gain a bit of breadth. In the design concept I decided to use a capacitive touch wheel as the primary user interface mechanism, with a few buttons for a tactile "click" experience when selecting items or moving backwards in the user interface.
After a great deal of research into capacitive touch wheels and parts, I settled on the MPR121 11-channel touch controller. There are fancier controllers out there that will automatically do the wheel calculations for you, but those parts were a little harder to source, and the central-mass calculations shouldn't be too computationally heavy anyway. I figured that more capacitive elements in your wheel equates to a higher wheel resolution, so I opted to use 8 segments, which is the near the high end of what I've seen any other designs use.
Part of getting out of my comfort zone here is actually drawing the wheel in Eagle CAD. I'd heard that they added in custom pad shapes in Version 6, but hadn't had the opportunity to learn how until now. It turns out it's as simple as drawing polygons around existing pads, which is a snap! This capacitive wheel is about 34mm in diameter, with an 8.5mm track width (which an appnote I read suggested as a good width for average finger size).
I'll admit that trying to make perfect curved arcs in the shape of the 8-segment twisty wheel really was a noodle scratcher for a while. I had zoomed out in the part and put my finger over the screen trying to eyeball the ideal ratio of curvature-to-distance for a finger being just over three pads at the extreme, and two pads nominally.
Being used to vector drawing packages like Adobe Illustrator, which is a beautiful piece of illustration software, it was a bit frustrating to deal with the limited arc drawing options in Eagle -- but of course it's a PCB package, not something meant for arbitrary vector drawing, and the folks at Cadsoft have done a really excellent job making Eagle extensible through scripts and transitioning the design format to an easily read XML. I didn't have time to put together an Eagle script to generate arbitrary perfect touch wheels, so the pragmatist in me ("make your mistakes cheaply") just set the grid resoution to 0.125mm, and traced over a wheel whose shape looked good. The results (above) are pretty good. I'm usually a bit of a perfectionist when it comes to laying out traces, but I decided that if approximating circles with lines was good enough for Sir Isaac Newton, it's good enough for me -- especially if the maximum it's out will be 0.125mm, or about 100 microns! Not bad for being more-or-less hand drawn. :)
Radiation Sensor Interface Board
The final board that's off being made at OSHPark this week is the Radiation Sensor Interface Board for the Type 5 High-Energy Particle Detector by Radiation Watch. Off the shelf these detectors appear to have a detection threshold somewhere around 60 to 80keV -- that is, the sensor will only detect photons with at least 60-80keV of energy, leaving it largely sensitive to only to gamma rays and the most energetic x-rays. For my Open Source CT Scanner project I had to modify these sensors to be much more sensitive to the lower-energy photons emitted by common radioisotopes. With a special backpack interface board I was able to get the detection threshold down to around 30keV, making the detector sensitive to much of the hard x-ray region, and generally much more useful for a bunch of applications.
Here I've placed this circuit onto a backpack board that sits on the back of the Radiation Watch Type 5 sensor board, and takes raw input directly from a test point on their board, and pushes it through a more sensitive detection circuit. The board is a slightly odd shape to ensure clear access to the battery connector on the left side of the motherboard. As a quick aside, this board also contains a small audio amplifier and micro speaker (only 6mm x 12mm) for generating PWM audio from the PIC32.
I'd though about using a piezo buzzer, but I think it'd be fun to havedecent sound capability. And honestly, I think it'd be more compelling if it sounded like a serious scientific instrument instead of a greeting card when it was alerting you that you'd just ventured a little too close to a nuclear reactor... Which is to say nothing of the sound for a space invaders clone someone is bound to create. :)
The solder stencils are also on their way from OSHStencils, and really make the job much easier. Where it used to take the better part of an hour to dot solder blobs onto 0603 pads and tweeze out excess paste from the TQFP pads, with a stencil you can do the same in only a minute or two. I'm still working on my technique -- I find that the 0.4mm/0.5mm pitch TQFP pads tend to get smeared and bridge without a little cleanup of the solder before reflow, but it's still much easier.
Being from the north, I tend to clean my stencils with a few drops of vodka, which led me to the strange discovery that solder paste, vodka, and mylar together smell almost exactly like potpourri. I have no idea why this is, unless my engineer of a father happens to hide rolls of solder in the holiday decorations. Maybe a future sensor board will contain a mid-IR spectrometer and be able to shed some light on the chemistry involved.
Thanks for reading! I'm expecting the motherboard and the rest of the components to arrive later this week, which means that the next update will very likely include actual hardware, which is fantastic! Thanks to everyone who's been following the project, and stay tuned!
07/09/2014 at 07:12 •
A very exciting post after a weekend of beginning assembly!
The bare motherboard PCBs and the rest of the components arrived this weekend, and I'm very happy to say that there's now a partially assembled prototype. There's of course still lots of hardware verification and software to write, but moments after finishing the motherboard I wrote a simple test for the OLED display, and took this quick test video. Of course my cat decided it was the perfect time for sits...
I remember nearly a decade ago when I first started designing and populating boards with surface mount parts, I started off like everyone else manually placing paste on each pad with a solder syringe, and then "fine tuning" these globs of paste with tweezers to make sure that there wasn't too little (which would cause a pin to fail to solder), or too much (which may cause a bridge with a neighbouring pin). Recently folks like OSHStencils have popped up, which make very inexpensive laser cut solder paste stencils. This not only saves a great deal of time, but cuts down on bridges or unsoldered pins. I'm still refining my technique -- I usually find for tight-pitch TQFPs with a bunch of pins I'll still prefer to manually solder them to reduce the chance of bridges (which can be difficult to repair), but for passives, small QFNs, or other parts with large pitches, these inexpensive solder stencils are absolutely great!
A set of tweezers and some time later, the parts on the bottom of the board are populated and ready to be reflowed.
When I first read about reflowing boards in a toaster oven, I wasn't sure what to think, but with a few inexpensive boards to practice on for your first few tries you can usually get fairly good results! For large boards sometimes you'll find the heat is a little uneven, and parts in one location of the board may reflow well before others. This certainly leads to cooking parts, especially delicate sensors, but if you watch it diligently you can usually minimize this. (Or, at least have a good idea what parts to replace when the board doesn't power correctly ;) ).
I usually try to keep all of the parts that I'd like to reflow on one side, and the parts that I'll hand solder on the other side.
One of the Arducorder mini motherboards, after reflowing. Looks beautiful! There was only one small bridge, on the TPS63001 buck/boost regulator.
Before populating the other side of the board, if possible I like to try and test the components on the first side. For multilayer boards I tend to put the power circuitry on the bottom side, and this allows the opportunity to test the voltages before populating the other side, and help narrow down potential issues if any issues pop up.
Everyone has aspects of design that they're good at, and some aspects that need a little work. Historically I know that I've tended to over-engineer power circuits, and haven't had a perfect success rate with complex buck/boost switching regulators, so I tend to treat these as a learning experience and give them extra attention. Here the FAN5331 boost regulator looks to be working properly, and successfully generating the 13V OLED supply. Great news, and score one for following those recommended layouts in the boost datasheet!
Making your mistakes cheaply
One of the most beneficial life lessons I've ever learned is the idea of making your mistakes cheaply, which is something my mentor in graduate school used to say. I remember before going to grad school, I used to look up at all these researchers and professors and other monster minds and think -- they must be such bright and intelligent folks from all their years of experience, and rarely make mistakes. Ten years later I'm a one of those researchers, and I make ten times more mistakes than I used to -- infact, research is so challenging I sometime say that I'm a professional mistake maker, because most of what I do is try out ideas that might not pan out. The difference is that I've had ten years to learn how to make those mistakes very quickly, ideally without much cost in time or resources, and quickly move onto finding the solution.
I bring this up because in the picture above (the top of the motherboard, hand populated), there is a mistake that I made cheaply this time, but only because I'd made it at a cost of days of debugging about four years ago instead of an hour this weekend. When you're in a time crunch you sometimes have to rush, and when you rush you sometimes tend to repeat your errors. Looking at the processor, can you spot the two pins on the bottom that have been lifted? Here, I've swapped the VDD and GND pins for one of the sets of power pins to the chip, causing the power and ground planes to be directly shorted. Thankfully there are many other sets of power pins on the processor that are all interconnected, so these two can be lifted until they're corrected in the next revision.
After hand populating the top of the board and resolving any soldering issues that popped up, I connected the Microchip ICD3 to the programming header, and programmed the Arduino-compatible chipKIT bootloader. It worked fantastically, and connecting to the FT232 USB-to-Serial bridge, the Arduino-compatible MPIDE successfully worked the first shot. Great news!
To test the OLED display, I wrote a quick driver that would access the SSD1351 display driver in 8-bit parallel mode, and fade some coloured displays in and out. This works great as well, and it was very rewarding after the assembly and verification to see a bright, beautiful organic led display light up, refresh at blazing speed, and show incredibly vivid colours. This has got me inspired and brainstorming about the user interface concept, and the best kind of test is one that gets you excited for the work that follows.
Next up is writing basic hardware and graphics drivers for the motherboard, verifying that everything works, and preparing for the touch wheel board and first batch of sensor boards that should arrive in time for the weekend. I also have to work out some measurements for the bottom (spectroscopy) sensor board, to see if I can fit in a more compact version of the spectrometer. With a large project like this on a schedule, much of the success is determined by filling the pipeline and ensuring that the next revision of boards are busy being made on the 12-day fab cycle while I'm tinkering away on the code.
Having hardware in hand is very encouraging, and things are really starting to get exciitng. Thanks for reading and to everyone who has sent in kind words of encouragement, and stay tuned!
07/16/2014 at 06:42 •
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 and the first time I've had such a tight clearance, but it ended up working out famously.
Here's the first sensor board of the Arducorder Mini! It's connected to one of the 4 interchangeable sensor module connectors on the top, and just waiting for some software to test it!
I wrote a quick test for the magnetometer to verify that measurements were coming out correctly, then went to work on writing a bit of software to encapsulate and display the data, and lay the very beginnings of a test user interface.
To help architect the software in a way that keeps it easier for other folks to modify, maintain, and use in other projects, I wrote the beginnings of a few modules:
- A framebuffer driver (with a backbuffer) for the ER-OLED015-1 1.5" OLED display, which is 128x128 pixels and 16-bit colour. This is a popular display in the OSH community, and most folks seem to be using it over SPI with Arduinos. Because the total frame buffer size would be 128 x 128 x 2bpp = 32k, most Arduinos don't have the capacity to store this framebuffer, and have to address the display pixel-by-pixel over SPI, which reduces the framerate, the kind of rendering you can do, and ultimately the user experience. The PIC32 used in the Arducorder Mini has plenty of RAM for the framebuffer (128k), and it's connected to the 8-bit parallel master port so that it can the display can be updated very quickly. I haven't precisely measured it, but I believe it's currently updating in the neighbourhood of 50-100fps, which is very good.
- A framebuffer graphics library that supports quickly writing basic graphics primitives (lines, circles, triangles, etc) to the framebuffer. To help make these functions more familiar to folks and easy to pick up I've started with the popular Adafruit graphics library, and am extending it as required.
- A graphing and visualization library for attractively graphing and displaying data in a variety of ways, with configurable options. This is a work in progress and something I'm very excited about, and the other night wrote the first widget -- a very basic graph with autoscaling (picture below, and in video). It's not terribly attactive right now, but the back end is all there.
- A sensor buffer storage class, for efficiently storing, using, and visualizing data (through the graphing and visualization library). Memory is a huge concern on microcontroller-based embedded systems, but I'd still like to be able to constantly record data from all the sensors in a buffer so that it's always "recording", and you can worry about discovering and analyzing the data rather than fumbling to try and save it while something interesting is going on!
There are also a few minor challenges that have some up using the standard Arduino libraries. The Chipkit port of the Arduino core to PIC32 is currently only compatible with Arduino 0023, rather than the newer Arduino 1+ standards. Some of the libraries for SPI also appear to be a little different. This is making some difficulties:
- SD card read speeds: From my game programming days, I learned that a lot of 2D graphics on PCs are rendered by having a large repository of bitmap graphical resources, and loading them (or "blitting" them) to the framebuffer. This has a lot of advantages -- instead of being limited to drawing your graphics in code using graphics primitives, you can use a professional illustration program and simply load in the results. This is what I'd planned to do with the Arducorder Mini, blitting bitmaps from the SD card (since there isn't enough RAM in the PIC32 to store more than one or two at once). There's a small hangup, in that the standard SD card library for the Chipkit has a read speed of only around 100k/second, which is a little slow, and much less than the ~2,500k/second theoretical maximum for an SPI bus running at 20Mhz. This makes the bitmap load time on the order of a second, when it needs to be about 10 times faster to really use this technique. Potential Workaround: There is a much faster SD card library called sdfat that is written for the Arduino 1.0+ libraries, but hasn't yet been ported to the Chipkit. I spent an evening trying to port over an earlier Arduino 0023 version without much luck (there is no debugger in the Arduino IDE, which is completely okay for a learning platform, but it makes me weep for serious library development). I'll have to revisit this.
- CC3000 library: The popular library to interface the Arduino with the CC3000 appears to be the Adafruit CC3000 library, but isn't currently Chipkit compatible. I'll likely have to port this as well.
Putting it all together
And here it is, all put together and with some very first test software. Looks great!
This week I also put together the first video for THP describing the concept behind the Arducorder Mini. It was a lot of fun to put together, and I hope you like it.
Thanks for reading, and stay tuned!
07/29/2014 at 06:14 •
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. :)
High-Energy Particle (Radiation) Detector Sensor Board
One of the biggest items on my open source science tricorder wishlist has been a high-energy particle detector, so I'm very happy to include the super-sensitive Radiation Watch Type 5 detector on the Arducorder Mini. The backpack board I've designed for it (above) includes the same external comparator that I added for the Open Source Computed Tomography (CT) Scanner project, so that it extends the range of the sensor to detecting lower-energy x-rays down to around 33keV.
This board also happens to house an extremely tiny speaker and audio amplifier so that the Arducorder Mini will be able to play back sound, which is one of the most popular feature requests I've had. The speaker is on this board for no other reason than that at 6x12mm it's still relatively large (compared to the other components), and space is at a premium on the motherboard.
For the backpack to make the Type 5 extra sensitive, it has to take the raw amplifier output from a test point on the Type 5 and connect it to an anchor point (TP1) that's directly above on the backpack. There's a 5 pin header that has to be soldered, which gives access to the less-sensitive regular output of the Type 5, and the noise output, which senses vibrations (which means the sensor output is invalid).
It all came together very well, and looks great!
Though I'm still looking for the perfect connector that's polarized, locking, mechanically sound, and exactly the height that would keep the Type 5 one lithium-polymer-batteries height off the motherboard, I was able to test the Type 5 with some jumpers. The result was 5cpm using the regular output, and about 20cpm with the super-sensitive output, and both went up substantially when bringing a 1 uCi Cadmium radioisotope check source near the sensor. Looking great!
A brief interlude -- both of my cats love Digikey boxes, and usually race to sit in the cushy packing material. If they fits, they sits.
Lightning et al. Sensor Board
A few pictures from assembling the Lightning et al. sensor board, which contains the AS3935 Lightning Sensor from AMS, the SI1145 UV sensor from Silicon Labs, and the ADMP401 MEMS microphone from Analog (as well as an amplifier circuit). Above is the ADMP401, on the back (inner-facing)side of the board.
The tricky bit about the Lightning board isn't that it's double sided, but that it's double sided with leadless parts on both sides. I try to avoid this, usually putting all leadless packages on one side, putting the board through only a single toaster-oven reflow cycle, and then working through all hand-solderable packages on the other side. This wasn't easily possible with the lightning board, so I decided to give double-sided toaster oven reflow my first try.
Here you can see parts on both sides -- most of them on the top, and the ADMP401 on the bottom.
The double-sided toaster oven reflow worked famously. I populated and reflowed the ADMP401 first, and then populated and reflowed the top of the board (placing the board upside down on another PCB, so the heavy parts wouldn't fall off on the second reflow cycle),
Atmospheric Sensor Board
I also populated, but haven't had time to test, the atmospheric sensor board. While I populated the atmospheric temperature, pressure, and humidity sensors, I realized the the current draw for the MiCS gas sensor is more than the PIC32 pins can source, and that it needs a second revision with some mosfets to ensure that it won't blow up some of the IO pins on the microcontroller. This is exactly why I'm building these first revision boards as soon as possible -- to find out what I forgot as I was building them.
Modular Sensor Suite (6 of the 7 Arducorder Mini boards)
Above is a set of 6 (out of the 7 total) sensor boards. I still have to design the most exciting board, the spectrometer / thermal camera board, and wanted to hold off until I'd assembled the rest of the Arducorder Mini to get an idea of size constraints, and if I can redesign the open mini embedded spectrometer to make it even smaller, and reduce the thickness of the entire Arducorder Mini.
Here three of the modular sensor boards are visible, with the spot for the fourth -- the spectrometer/thermal camera board, still unpopulated. The connector for the high energy particle detector can be seen on the bottom right side.
Capacitive Touch Wheel Board
Last but not least for this update, I'm eager to begin working on the user interface, and have populated several of the MPR121-based capacitive touch wheel boards. Unfortunately while I've had success contacting the real-time clock on the touch board, I haven't had any luck contacting the touch sensor. I've built three of the boards without luck (two using toaster oven reflow, and a third hand soldered), and have double-checked the footprint, schematic, soldering, and code, without luck. I'm fresh out of MPR121 ICs and touch boards, so I've ordered additional boards, MPR121's from a different source (incase the chips were dead), and a breakout board to hand-wire to the capacitive touch wheel in the mean time.
There's been a great amount of progress recently, and my focus for the near-term is to verify the hardware, and send out any revisions that are necessary. While those revisions are out, and once the hardware is reasonably stable, I can start to really push on the design of the user interface. I've had lots of ideas for an simple and intuitive visualization interface for sensor data, so it'll be interesting to finally put code to practice.
Already the prototype Arducorder Mini feels wonderful to hold in your hand and walk around detecting things, so I'm very excited to see how it takes shape in the coming weeks and months.
Thanks for reading!
08/12/2014 at 03:31 •
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)
- MPU9150 IMU: I wrote some code to test the MPU9150 3-axis accelerometer/gyro/magnetometer using the I2CDev library, and to graph the 6 axes on the same coloured graph. It seems to be working great!
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.
- Open Mini Spectrometer: I've been trying to redesign this to lay the whole spectroscope down (so requires less height), improve the spatial translation invariance, potentially move to a more sensitive detector, and potentially move to a laser-cuttable design (with a ~0.2mm laser-cut slit). I've also been trying to avoid as many prescription-ground optical surfaces as possible, which add fantastic amounts to the cost. Some very tiny and inexpensive front-silvered mirrors arrived today, so I'm excited to get back to this. I have to be careful though -- the first open mini spectrometer was designed in an afternoon, and this new version has to be kept tractable and similarly inexpensive. I think rapid iteration is especially important here -- I'd rather get something running end-to-end quickly than take months to work out the perfect spectroscope and leave the new version untested for so long.
- Low-resolution Thermal Imager: I'd initially planned on using the MLX90620 16x4 thermal sensor, both because it looks to have great thermal/resolution characteristics, and (until recently) was really the only game in town for the sub-$100 imager price range. Recently the Panasonic Grid Eye 8x8 array, as well as a similar (but slightly larger) offering from Omron have popped up. A really great Inexpensive Thermal Imager project arrived on Hackaday.io recently, and I've been really impressed that he posted his evaluations of each of these three sensors to verify their thermal characteristics. In his tests, the Omron appears to come out as the most stable, followed by the smaller Grid Eye and the MLX90620, both having largely similar characteristics despite the Grid Eye being half the price. I'd started redesigning the Spectrometer/Thermal Camera board to use the Grid Eye instead, only to find that they're out of stock nearly everywhere, and additional stock doesn't look like it'll arrive for another 3 months -- way too late for me. I think the Omron is too big, so it's back to the MLX90620, which still looks to be an excellent sensor with a larger temperature range than the Grid Eye, and a large range of framerates.
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!
08/27/2014 at 06:41 •
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 some of my rock-climbing buddies (who are optical physicists) with the idea of making a tiny pinhole spectrometer without any relay optics for a few weeks, so it was time to make a first prototype and see how it would work out.
One of those rock climbing optical physicists (who is much more skilled at climbing than I am) suggested that instead of 3D printing out the spectroscope as I did originally, that the ~0.2mm kerf of the laser cutter at our local hackerspace Xerocraft might yield a reasonably thin slit while being amenable to being built in 2.5D with a sandwich of laser cut pieces, like the Open Source CT Scanner. This is a great idea, so I decided to try it out.
In order to make a low-profile spectrometer that doesn't stick out, the spectroscope (the optical bits of the spectrometer) actually has to live on both sides of the circuit board. There should be about 6mm of clearance on the back of the board (between the sensor board and the motherboard), and about 8mm of clearance on top of the board. I drew a few sketches, and cut out a first test spectroscope that would fit on one the open mini spectrometer boards (for testing) out of some thin 1.5mm plastic that I found in the material bin (pictured above).
While I used an inexpensive 1000 line/mm transmission diffraction grating sheet for the first open mini spectrometer, I've seen a lot of folks (like PublicLabs.org) get impressive results with much larger spectroscopes built from DVDs used as 1350 line/mm reflection diffraction gratings. I decided to try laser-cutting a section of DVD to precisely fit into the laser-cut acrylic spectroscope sandwich, but it turns out this isn't a fantastic idea -- the tiny DVD-piece gratings end up being covered in residue from the process, or delaminating, or seemingly changing their properties entirely. I tried cutting out about half a dozen, and taking the best to make a solid attempt.
With most optical systems (especially spectrometers, where you're usually light starved and fighting a poor signal-to-noise ratio), it's important to have an absorptive light-tight matte black optical chamber that maximizes the chance that any stray light will get absorbed, and won't bounce around until it hits the detector. Aside from transparent plastic, the glossy white plastic I used here is probably the worst plastic you could build a spectrometer out of, so I spraypainted it flat matte black to reduce the noise.
Unfortunately this first iteration didn't yield a fantastic spectrometer -- likely from a combination of a poor grating with such a tiny chamber where placing baffles to capture the unused diffraction orders from the grating was nearly impossible. I think this means it's back to the transmission grating, and a bunch more iterating!
I'm also looking into off-the-shelf spectral sensors that might be suitable (and please feel encouraged to send in suggestions). While a very inexpensive open mini spectrometer is attractive, I'd be happy to include a more expensive sensor if it were off-the-shelf, fit the size requirements, and was reasonably capable.
It's important to remember how challenging this spectrometer miniaturization is -- above, the picture shows just how small I'm trying to miniaturize it to. That's tiny! And challenging, but I don't think impossible.
While most of the major components for the prototype Arducorder Mini have been chosen, I thought I'd highlight two cases where the final selection has a few alternatives.
The main display uses a bright, beautiful Organic LED (OLED) display with 16-bit colour, and is about 1.5" diagonal with a 128x128 pixel resolution. When I first started developing the design concept about three months ago I also ordered some slightly larger displays to choose between. At 160x128, these displays offer a little more display real-estate, but with a lead time measured in months I knew this decision would have to wait until these arrived.
I have to confess that in the new months that this project has been active from concept to prototype, I've really fallen in love with the tiny form factor of the Arducorder Mini with it's 1.5" display. It feels very good to hold in ones hand -- not too big, not too small -- and the minimal memory requirements of the 128x128 display keeps things tractable. I remember reading an interview with the Raspberry Pi folks some time ago where they said that if they were constantly chasing new hardware features, they'd have never finished and released their first design. I feel the same here -- I'm not sure that adding a small amount of display area will substantially increase the user experience enough to change a working industrial design, or warrant the risk of using a long lead time part during development. It's also important to me to use parts that are easy for people to source and keep the barrier for entry as low as possible, and these 1.5" OLEDs are an inexpensive easy to source part with an estimated long lifetime, so I think the decision will likely be to continue to use the existing (and great!) display.
Another part that I'm having a bit of trouble selecting is the connector that goes between the motherboard and the radiation sensor board. I designed this to have a standard 6-pin 0.1" header, but didn't actually select the part before sending off the board, thinking that I'd be able to find a mechanically sturdy polarized locking connector without issue. I had this locking receptacle in mind when I designed the part (the same used for the Olimex ICD2 PIC programmer), but it turns out it's meant to be a board-to-cable connector, and I haven't been able to find a mating end that's board-mount.
Above is an alternative, which makes me mechanically a little nervous for this application because it doesn't have a lock to ensure that the two halves don't come unconnected, but seems to have a very good connection. Unfortunately the pins are looped and a little too big for the holes on the PCB, so this one's out too. I feel like I've looked at literally thousands of connectors and haven't found one yet, but hopefully I'll strike gold and find a suitable locking 10-12mm stacking height connector shortly.
Atmospheric Sensor Board Revision 1
Last but not least, I also put together the first revision of the atmospheric sensor board, and sent it off to OSHPark. This version adds 3 MOSFETs for the heaters on the MiCS-6814 gas sensor, which require more current than the PIC32 pins can handle.
Now that the WiFi module is working and much of the hardware seems to be in a good place (or moving towards minor revisions), I'm going to try and design a first iteration of the spectrometer sensor board to send off by the end of the week, and then start working on the user interface concept and implementing the beginnings of the graphical user interface!
Thanks for reading, and stay tuned!