-
Step 4: Beginning Prototype Assembly
07/09/2014 at 07:12 • 3 commentsA very exciting post after a weekend of beginning assembly!
Motherboard 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!
-
Board Layout Part 3: Lots of boards!
07/02/2014 at 04:24 • 0 commentsAnother 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. :)
Solder Stencils
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!
-
Step 3: Board Layout Part 2
06/21/2014 at 22:30 • 1 commentAnother 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.
Prototyping Components
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!
-
Step 3: Board Layout Part 1
06/17/2014 at 07:30 • 1 commentA 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!
-
Step 2: Concept and Industrial Design
06/08/2014 at 04:38 • 0 commentsLet'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.
User interface design, visualization, and human factors analysis are (as dorky as this might sound to non-academics) hobbies of mine, and I've picked up a bit of this from colleagues, friends/other grad students, and reading groups. I think the first two models did the visualization component very well, and had lots of potential in terms of user interface design. They both used touch interfaces, with the Cirque touchpad on the Mark 1, and the dual OLED touch displays on the Mark 2.
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:
Atmospheric
- Ambient Temperature and Humidity: Measurement Specialties HTU21D
- Ambient Pressure: Bosch Sensortec BMP180
- Multi-gas sensor: SGX-Sensortech MICS-6814
Electromagnetic
- 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
Spatial
- Inertial Measurement Unit: Invensense MPU-9150 9-axis (3-axis accelerometer, gyro, and magnetometer)
Other
- 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.
The Muse
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:
Next Steps
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!
-
An Introduction and Background
06/07/2014 at 04:36 • 0 commentsI 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.
Introduction
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.
Supporting Projects
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.