Toward a design for the next Open Source Science Tricorder

It’s been a full, unbelievable two months. The Tricorder project has been everywhere from Slashdot to MSNBC to Forbes. I’ve given talks, met wonderfully amazing open source hardware folks, been humbled by an inbox full of eager citizen scientists hoping to learn more about their worlds, and picked up a life (for the second time — they tell you in grad school you’ll likely have to do this at least a few times) and moved to the San Francisco Bay area to design Medical Tricorders, win a race for an X-PRIZE, and help transition health care into an information science. I’d say that’s a lot for two months! Now that the press has calmed down a bit, and my inbox has slowed to an almost manageable trickle, I’ve been able to play and tinker a bit with the next Open Source Science Tricorder design.

Folks have asked a bunch about the next design — what sensors will it have, what will it look like, and so forth. I’ve been sketching out some designs in hardware and in code a while now, playing with creative elements to see what works well, and what needs work, and how the design can be kept tractable, exciting, inexpensive, and have the potential for manufacture so that folks can actually have Open Source Science Tricorders in their hands. Seeing the challenge that folks are having with building and modifying the earlier Science Tricorders (and rightfully so — they’re very complicated to assemble), it’s clear that I can do a lot better on my accessibility design goal. In light of this, I’d like the next design to be extremely easy for regular folks to modify over a weekend, both in hardware and software, maybe by adding a new analog sensor or changing one of the visualizations, and in this way serve as a vehicle for beginning to learn programming and electronics. The Science Tricorders are all about science, and helping people explore their worlds and learn about science, and the idea of making them as easy as possible to modify meshes very well, I think. I confess that I have partially selfish motivations for this — I feel like it would be extremely rewarding to read about all the interesting ways people have modified their Science Tricorders and all the wonderful things they’re learning about the world with them while I eat my fruitloops in the morning and begin the day.

I’ve tinkered with two experimental designs for the next Science Tricorder. One (pictured above), that I’ve been working with over the last half year, is an experiment in keeping things inexpensive and pervasive by placing sensors on something as small as a keyfob, that everyone could keep with them. The device would be paired with a smartphone for visualization, which saves the size and expense of adding a display to a design. It’s a pretty design (especially with the RGB led’s), and fun to play with something so tiny. The two hitches are that it’s difficult to include a diverse array of sensors in the design, and that by requiring a smartphone you’re discluding kids from carrying one around unless they also borrow their parents expensive phones, which is clearly a non-ideal use case.

The second and earlier design (pictured above) came after the Mark 2. The Mark 2 is absolutely beautiful, but it was a huge undertaking for only a single science nerd to develop, no matter how nerdy. And it was expensive. I tried experimenting with low cost design, and so the processor was changed from the ARM9 core running linux to one of the most powerful microcontrollers at the time (a PIC32MX), the dual OLED displays were swapped for a single TFT, and — critically — most of the sensors were taken out, replacing them with headers that sensors could be plugged into. This design experiment had good elements — it was definitely moving towards making things less expensive, and added connectivity options (like bluetooth) that I liked, but it strayed a bit too far off the path. I feel like Science Tricorders are about having lots of sensors integrated in a small package, and readily available. I don’t want folks to have to carry around a bag full of sensors with them, or have to swap sensors in and out on the field, only having some subset of them available at any given time.

So, two good experiments, and lots of lessons learned. With these “concept sketches” of the next Science Tricorder — sketches in hardware and in code — I’ve been designing something different from both and closer (at least conceptually) to the Mark 1 and Mark 2 designs. I think what comes out of this process will likely be fairly close to the final design for the next Open Source Science Tricorder.

The clam shell design of the Mark 1 and 2 is great, but it’s mechanically difficult and requires an extra screen for the bottom, which requires extra electronics — it really contributes to making things expensive. The keyfob is on the other end of the spectrum — tiny, inexpensive, and no screen at all. The PDA-style design was somewhere in the middle, but I’m not a fan — it’s very plain, and the screen is out in the open and could easily be damaged. It’s also very flat, and challenging to find space for everything (sensors, electronics, etc) to fit. With all this in mind, I’ve been trying to figure out a good mechanical design that I like.

I mocked this one up in Google Sketchup. It’s kind of inspired by the Tricorders in the Enterprise series, in that the screen is essentially in a protective pouch, and can be slid out for use. I flared out the sensor section (top), and added a bit of an angle on it. Often I’ve been mounting the sensors at a 90° angle from the screen, which would mean to sense something infront of you you have to hold the unit completely horizontal and look down at the screen. By having the sensors mounted at about a 30-60° angle, which seems to be where you naturally tend to hold the Tricorders when you’re walking around with them, you’ll be sensing what’s infront of you, but also holding the screen at an easily viewable angle — both to yourself, and to the folks around you. In that way I hope to make it more usable, and help bring the folks around a Tricorder user into the experience.

This is just a rough mock up, and I’m sure it’ll change a bunch. I was going to print one out to play with, before remembering parts to my 3D printers are hidden away in a UHAUL storage container until I find somewhere to live in the bay area!

To get a rough idea of whether things would fit, I sketched up a drawing in Adobe Illustrator with some of the big (potential) parts, and started shifting them around to get a rough idea on size. There are plenty of other things to fit in, but many of them are pretty tiny, and the details of their placement tends to be sorted out when designing the circuit board.

My working list of sensors and “big” parts is currently:

  • Ambient Temperature, pressure, and humidity: likely Sensiron’s new SHT20 sensor (that replaces the SHT1x series), as well as a BMP085 pressure sensor, which looks /way/ easier to work with than the SCP1000 in the previous models.
  • Non-contact Temperature: likely a Melexis MLX90614 series sensor. These are great, and Melexis has been very generous with samples in the past.
  • 3-axis Magnetometer: still not sure on this one, but likely a HMC5883L or similar. These have very similar specs to the MicroMag3 in the first two models, but the sensor itself is far smaller. I’d also like to experiment with having two magnetometers mounted some distance apart, to give not just 3-axis direction and field strength, but ideally also the distance to the field source.
  • Light level and colourimetry: I’m thinking some of TAOS’s (now AMS) line of sensitive light and colour sensors. Some of these have very high dynamic ranges, so they’ll be useful across a broad range of light levels. The Avago colour sensor I used in the Mark 2 had a small internal white LED to illuminate the sample, so I might have to include something similar beside the colour sensor.
  • Distance sensor: likely a MaxSonar by Maxbotics. They have some newer models that are supposed to have better resolution, range, and noise rejection. I’d really love to use a laser-based range finder, but I don’t think there are any tiny (or inexpensive) options yet.
  • Inertial Measurement Unit: everyone’s very excited about the Invensense MPU6050 integreated 3-axis accelerometer and gyro, and they have a version coming out that also includes a 3-axis magnetometer — which could act as the second magnetometer mentioned above.
  • Sound: this was a big request. There were always headers for microphones on the first two models, but this model will include an internal microphone for doing FFTs/frequency analysis and such.
  • Gamma ray detector: another big request. I’ve been experimenting with this since the Mark 1, but noise has always been an issue. Gieger tubes are way too large, and have hefty voltage requirements. PIN photodiodes still seem like the way to go, and folks have posted schematics online that seem to do okay — so this is definitely something to investigate again. I have also thought of coupling a scintillation crystal with a photodiode, but I’m sure cost, noise, and finding enough tiny scintillation crystals to make more than a few would be trouble — so directly using the photodiode as a detector (without a scintillator) may be a good compromise.
  • Gas sensor: another request, and one that still needs a bunch of research before it’s officially on the list. I’d love to include a gas sensors that could sense something like greenhouse gasses emitted by vehicles or industry, or something simlar. Most of the sensors I’ve found are large, and use heaters that both heat the whole unit up until it’s very hot, and require a lot of power. I’d love to hear about a small, low-power sensor.
  • Display: If Alibaba is correct, there’s a chance that the 2.8″ OLED touch displays used in the Mark 2 are back on the market, and so I’m looking at seeing if there’s a good supply of them for the forseeable future. If not, I’ll have to find an inexpensive TFT that’s bright and has good viewing angles — I’d love to hear about one, if you have one and a supplier in mind.
  • Connectivity: definitely at least one of bluetooth or WiFi. Bluetooth would be nice for pairing with a close-by device (like a laptop or smartphone) if you’re out in a field somewhere, where WiFi would be nice if you’re at home or school — but WiFi modules are traditionally a bit more expensive, too. I’m still not sure on which one to go with.

I’m still deciding on the processor — there are one or two more options that I’d like to check out before making a decision, and hopefully their evaluation boards should arrive in the next few weeks.

I’m eager to hear comments on this high-level design before plunging into the details. If you have thoughtful comments, suggestions, or sensor/part recommendations, I’d love to hear your comments — either here, or sent to peter at tricorderproject dot org .

stay tuned!

Leave a Reply