1 Sensors
2 Hardware
      2.1 Design Philosophy
      2.2 Hardware Specifications
      2.3 Mechanical Design and Case
3 Development Notes
4 Source Files
      4.1 Electronics, Schematics, and
            Board Layout

      4.2 Parts list
      4.3 Source Code and Firmware
      4.4 Known Errata
5 Assembly Pictures and Interior
6 Exterior and Operating Pictures
7 Acknowledgements


Science Tricorder Mark 2

The Science Tricorder Mark 2 was a wonderful adventure of discovery to develop. It's my pleasure to be able to share it with you.

To introduce you to the Tricorder project, I'd like to begin with a story from the development of the very first Tricorder that I built. The first educational discoveries with the Tricorder came only moments after completing it, and walking about the workshop to "see what can't be seen". Upon holding the Tricorder near a power adapter plugged into the wall, you could see the oscillating magnetic fields on the magnetometer visualization. There they were, slowly bouncing back and forth, right in front of you. My father had taught me how transformers work from a young age — two coils are wound together, each having a different number of windings, where an oscillating magnetic field from one coil would induce a voltage in the other coil proportional to the ratio of their number of windings. I know how transformers work — I have known since he explained it to me, I know the equation that determines the output given the input and a certain number of windings — but I had never seen it work until then, until I had this Tricorder in my hands. It grounded my knowledge of the electromagnetic phenomena at work in transformers with something that I could easily watch and see, and use to see inside /any/ transformer, right in front of me. And from that moment on, it seemed like much of the mystery of how they worked I now understood — I could think about what was going on inside them easier and more naturally, now that I had visually grounded the science going on inside. This is why I built the Tricorder.

More educational discoveries came quickly — from finding all the heat leaks from different building materials in my graduate student apartment in a century home, to how much humidity is exhaled in a breath. The people I gave it to play with loved it too — I fondly remember characterizing the fields emitted by enormous nuclear magnetic resonance (NMR) spectrometers with researchers in chemistry and physics at McMaster University.

Again, it is my pleasure to be able to share this with you. I'm excited for all the discoveries you can make about the world around you.


The Science Tricorder Mark 2 prototype sensor board contains ten different sensing modalities, organized into three main categories: atmospheric sensors, electromagnetic sensors, and spatial sensors. Many of the sensors are similar to those used in the Science Tricorder Mark 1, where the differences are centrally in upgrading sensors to higher-resolution versions where possible. The prototype sensor board also includes an imaging sensor, in the form of a cell phone camera, that is untested. Sensor boards for the Mark 2 are designed to be self-contained, include separate microcontrollers for low-level sensor communication, and as such are more easily upgraded.

The sensing modalities and specific sensors used on this device, as well as some approximate summary specifications, are as follows:

Sensiron SHT11
Atmospheric Temperature and Humidity
-40°C to +120°C, ± 0.5°C accuracy
± 0.1°C repeatability
PNI Corp MicroMag3
3-axis Magnetic Field Sensor
±1100 µT range, 0.015µT resolution
up to 2000 samples/second
Sensiron SHT11
Atmospheric Temperature and Humidity
0 to 100% RH, ± 3% accuracy
± 0.1% repeatability
Avago ADJD-S311-CR999
Colour RGBC Sensor
10-bit resolution per channel
Absolute Pressure Sensor
30kPa to 120kPa, 1.5 Pa resolution
Melexis MLX90614
Non-contact IR Thermometer
-70°C to +380°C, 0.02°C resolution
± 0.5°C to ±4°C accuracy over range
Light-to-digital converter
300nm to 1000nm responsivity,
16-bit resolution
Lassen iQ
GPS Receiver
<5m (50%), <8m (90%) accuracy
1 Hz update
MaxBotix MaxSonar LV
Ultrasonic distance sensor
0-6m range (approx), 2.5cm resolution
Analog ADXL330 and Invensense IDG300
Sparkfun Inertial Measurement Unit breakout (5 degrees of freedom)
±500°/s Gyro
±3 g Acceleration


      2.1 Design Philosophy

The design philosophy of the Science Tricorder Mark 2 was heavily influenced by its predecessor, the Mark 1. Taking a step back to reflect upon the Science Tricorder Mark 1 design, there were particular aspects that ended up working well, and others that served as a learning experience for future development:

Broadly, in light of the success of the Tricorder Mark 1, as well as to encourage myself to exploring novel design ideas, I decided that the Science Tricorder Mark 2 should be an ambitious project. The above design considerations offered a bunch of areas to improve, and while the Science Tricorder Mark 1 felt like an incredibly cool device, it also felt as though with some work and exploration one might be able to develop a much more capable, more visually appealing work.

      2.2 Hardware Specifications

The Science Tricorder Mark 2 is a dramatic advancement from the Mark 1 design, and includes an ARM processor capable of running Linux, two beautiful Organic LED touchscreen displays, and a bunch of connectivity options including USB (device and host). To compare it to a familiar device, it's a little faster than a Nintendo DSi, while having about twice the RAM and higher resolution displays. The hardware specifications of the Science Tricorder Mark 2 are as follows:

A flow diagram of the Science Tricorder Mark 2, showing the major components and data paths (click to enlarge)

      2.3 Mechanical Design and Case

The Science Tricorder Mark 2 case is physically very similar to the case from the Tricorder Mark 1, with two notable exceptions. First, it is nearly half the thickness of the first Tricorder, making it even more portable. Second, it includes several ports on the right hand side for power, USB (host and device), and the micro SD socket containing the linux filesystem. Optionally, it also supports a headphone jack on the upper right-hand side. The Tricorder feels light in ones hand, and fits both easily and comfortably in ones pocket.

Similar to the Mark 1, the Mark 2 is constructed from polystyrene sheets cut to size, superglued, then filed and sanded for smoothness as well as to create connector ports. The structural parts (including most of the exterior faces) are 2mm thick to give it strength, where most of the interior faces (such as the borders around the displays, as well as the curved surfaces) are 1mm thick. The Tricorder Mark 2 in many of the pictures here does not yet have some polystyrene around the sensor compartment — this was to make it a bit easier to debug the sensor board, and can be added in later. This case also wasn't painted — I kind of like the semi-translucent white look, and the internal LEDs for power, charging, or communication status illuminate the side of the case in a way that looks great.

Much like the Mark 1, the Mark 2 must electrically connect the top and bottom sections through a flat flex cable. Where the Mark 1 used two small flat flex cables (one for power, the other for the touchpad), the Mark 2 used a single, wide flat flex cable. This extra width made constructing a working polystyrene hinge extremely challenging as the cable has to be internally twisted within the hinge, and using two stacked cables likely would have been easier.

Development Notes

The Science Tricorder Mark 2 was planned during Spring 2008, and actively developed starting August 2008 until December 2010 — largely over my fourth and early fifth years of graduate school.

Migrating to the ARM920T core: An early design choice was that the Mark 2 should be capable of running an operating system, which would greatly ease software development — instead of having to reflash firmware, one could simply upload a program by a variety of means. After exploring different microcontroller or full processor options, I decided to migrate to the Atmel AT91RM9200 32-bit ARM9 family processor for the following reasons:

OLED Displays and Touch Interface: Substantially updating the visualization performance of the Tricorder was a central design goal of the Mark 2. In concert with updating the processor to be capable of supporting higher frame rates and more computationally intensive visualizations, I searched for a modern high-resolution, small form factor display. Full-colour Organic LED display technology had just been released, and the specifications on the displays looked fantastic — extremely low profile, wonderful colour reproduction, substantially improved resolution over the Mark 1, and the potential for low power usage. The OLED displays were also available with resistive touch screens, which offered a natural mechanism for input.

I decided to pick up a few 2.8" 24-bit colour OLED displays with a 320x240 resolution, and made a breakout board for the 61-pin display connector that would (just barely) fit on a breadboard. After tinkering I was able to interface with the integrated Samsung S6E63D6 display controller, and successfully displayed a bitmap from Digital Blasphemy. The beauty of the displays immediately struck me — it genuinely felt like looking at the most bright, vivid piece of matte paper I had ever seen, with a nearly complete 180 degree viewing angle. They felt perfect for the Tricorder Mark 2.

The touch interface opened the possibility of replacing the touchpad on the bottom of the Mark 1 with a touch OLED display, allowing the bottom display to function as a reconfigurable input device. I thought that having both top and bottom displays being touch would open up some fun experiments with user interface design, and so I designed the system to include resistive touch screen controllers for both top and bottom displays.

The OLED displays have both high-bandwidth parallel as well as a low-bandwidth serial (SPI) interfaces. The top display was wired using the 16-bit external memory interface of the AT91RM9200, and mapped to its own chip select. The processor sees the display as two separate memory locations — one for data, and another for setting a control register. The interface is rather easy — after setting a few control registers, one can quickly write raw pixel data, or setup a dual buffer system for sending entire frames to implement thrash-free animation. The lower display uses a slower SPI interface, in large part because of the cost of having a custom high-density flex cable manufactured that contained enough conductors for the parallel interface. This functionally limits the bottom display refresh rate to about 2 fps, though one can update only the portions of the display that have changed and design the interface to hide this current limitation.

Sensor Board: Keeping with the design goal of breadth, I had decided that it should be easy to incorporate new sensors into the Tricorder in the form of an upgradeable sensor board. There are a bunch of different paths one could take with this — for instance, one might have a bunch of small interchangeable sensor boards, and a Tricorder capable of accepting several of these at once, and autodetecting their sensors. In this way, updating the (say) atmospheric sensors wouldn't require you to also replace the electromagnetic sensors, saving quite a bit of cost.

I decided to go with an architecture very similar to this. Instead of breaking out the digital interfaces of each of the sensors to the AT91RM9200 processor through a large connector (as in the Mark 1), the sensor board includes a dedicated microcontroller that handles all the low-level sensor interfaces, and communicates back to the main processor using a simple SPI protocol. I also experimented with developing a sensor metadata protocol, which would allow the Tricorder motherboard to autodetect the sensors, respective measurement modalities, and the measurement units of a given sensor board. I think this is a very good idea, and plan on further implementing it on future Tricorder versions.

For pragmatic reasons, instead of adopting multiple sensor boards, I kept with one single giant sensor board containing all of the sensors on the system. Because the sensor boards interface using a 4-wire SPI protocol, it would be technically easy to change the design to include multiple sensor boards — one would only have to route additional sensor board connectors onto the motherboard, and add additional chip select lines. Using one board kept it simple, and also allowed me to include a high-bandwidth parallel connection to the sensor board for experimenting with a CMOS camera. The AT91RM9200 doesn't include a camera interface (like some of the newer models), and so the camera interface was mapped to general I/O pins. The CMOS camera I used from Sparkfun ended up not being well documented, had issues with the surface mount footprint, and (I found out some time later) was intended to be plugged into a larger connector/carrier, which would explain why it melted during the reflow process.

The sensor package was very similar to that used in the Mark 1, with the exception that some sensors were swapped out for low-noise digital versions. Using a dsPIC family processor also allowed me to reuse most of the low-level interface code developed for the Mark 1, which dramatically reduced the firmware development time. Knowing that the central focus of the Mark 2 was to develop a better visualization suite and sensor interface platform, then later focus on developing better suites of sensors, I kept most of the sensors on headers so that I could swap them onto new boards if needed, during testing. This made the sensor board itself a bunch larger than it needed to be, but kept development simple.

Power Subsystem: A substantial amount of thought went into the power subsystem for the Mark 2, where this was more of an after thought for the first model. The Mark 1 ended up using linear regulators, which are simple, but require an input voltage higher than the voltage you'd like to generate. While the main bus was about 3V, for a 5V touchpad and 6V LCD backlight this meant a lot of AAA batteries, and these took up quite a bit of space and added a lot of weight.

The Mark 2 migrated to a high-density Lithium Ion Polymer battery, which nominally outputs 3.7V at 1000mAh, and is in a remarkably small and light weight package. The power system was designed with high efficiency buck/boost DC-DC converters, which would operate across most of the LiPoly battery's wide voltage swing of about +/- 0.5V, depending on its charge level. The main bus operated at 3.3V, but separate buses of +/- 5V were required for the OLED displays, where the +5V line was also used to supply USB host voltage for external devices such as memory sticks or WiFi adapters. The power board was designed to use the TPS65131 Postitive/Negitive DC-DC Converter, which is a buck/boost/inverter with really favourable specifications. Unfortunately after a bunch of effort I just couldn't get this part to function — the +5/-5V rails would collapse under any load, and a few different sets of eyes couldn't seem to find the issue. In light of this I ended up migrating to the NCP5810 +5V/-5V DC-DC converter, which is specifically designed for OLED purposes, and was easy to get up and running.

Lithium Polymer batteries, while able to pack a lot of power into a small area, need extra care to ensure that they're being charged and discharged safely. The DS2764 LiPoly High-Precision Battery Monitor was added to monitors charge and discharge rates, as well as temperature, and ensure things were safe. It also includes a bunch of useful features for voltage and current measurement to use as a battery gauge, and soft-power functions so that the Tricorder can turn itself off in software. The power board also includes a LiPoly charging circuit for easily charging the Tricorder Mark 2.

Operating Systems and Linux: The decision to go with Linux was generally a very positive experience. With the use of helpful tutorials I was able to install the bootloader, kernel images, and successfully boot the system quickly. With some work I had a gcc-arm cross compiler installed on my system to (quickly) compile kernel images, a native version of gcc installed on the Tricorder itself to compile user code, and some drivers for an external USB 802.11b wireless adapter working. I would generally develop code in Kdevelop under linux, scp/sftp it to the Tricorder, compile it over ssh, and test it out. While that may sound like a bunch of steps, it worked quickly, and felt streamlined. Because I'm a dork, there was also something pretty cool about sshing wirelessly into a Tricorder that I'd built, and developing code for it — then being able to pick it up and walk around the room to test it out.

Modifying or developing drivers to access the Tricorder's hardware (such as for the OLED displays or SPI peripherals) took some work. This process is generally much easier on a microcontroller — you're right at the hardware level, and by accessing a few registers with a few lines of code, you're quickly able to send and receive data to an external peripheral. When an operating system is involved, there are generally several layers of abstraction between user space code and low-level peripherals, so the process becomes more complicated. Using a JTAG debugger I was able to find the appropriate memory bus timings for the top OLED display, and modified a kernel driver in the ARM tree with the definitions for the Tricorder Mark 2 motherboard. To keep testing simple the OLED display interface I wrote lives in user space, which is unfortunate in that it's not recognized as a standard framebuffer device (and thus can't currently display something like X-Windows), but this helped keep things tractable at first. The state of the ARM SPI driver for the AT91RM9200 wasn't ideal, but with some work I had some userspace code working, and slightly modified the SPI kernel drivers to accept multiplexed chip selects, since the Tricorder Mark 2 has more SPI peripherals than the AT91RM9200 has chip selects. In all it was a great learning experience, and served as a good introduction to the ARM kernel drivers that could serve as a foundation for a more ambitious project, such as writing standard framebuffer drivers for the OLED displays in the future.

Source Files

      4.1 Electronics, Schematics, and Board Layout

The hardware source files are available in a single archive that includes:

Eagle also allows parts lists to be exported from these source files. The schematics and boards were designed to be within the free edition of Eagle CAD's limitations — a single schematic sheet, and a maximum routing area of 80x100mm — so please excuse a bit of density on the schematics in the name of accessibility.

The hardware source is available under an open TAPR Non-Commerial License. The source files can be downloaded here, and previewed below:

A single-page schematic of the Science Tricorder Mark 2 Motherboard and Sensor Board (click for PDF)

2-layer board artwork for the Tricorder Mark 2 Motherboard (left), Sensor Board (lower right), as well as
a JTAG connector breakout board (upper right).

A single-page schematic of the Science Tricorder Mark 2 Power Board and GPS Breakout (click for PDF)

2-layer board artwork for the Tricorder Mark 2 Power Board (left), GPS Board (center right), as well as
a sensor and power connector breakout board (lower right).

      4.2 Significant Parts List

The major components used in the Science Tricorder Mark 2, as well as some potential sources for less easy to find parts, are as follows:

Motherboard and Sensor Board

Symbol Manufacturer Part Number Function Source
IC1 FTDI FT232RL USB-to-Serial Converter Digikey
U1 Atmel AT91RM9200-QU-208 ARM920T Processor (180MHz) Digikey
U2 Micron MT48LC16M16A2P 32MB SDRAM Digikey
U3 Atmel AT45DB642D 8MB Dataflash Digikey
U4 Hirose DM3B MicroSD Socket Digikey
U5 Hirose HFQ461CT Connector for OLED Display Digikey
U6 - LED 3.3v LED, 0805 Package Digikey
U7 Hirose UX60A-MB-5ST Mini-USB Connector Digikey
U8 Toshiba TCM8230MD CMOS Camera Sparkfun
U9 Assmann AE9924 USB Host connector Digikey
U10 Maxim MAX6412UK28 Reset Supervisor Digikey/Maxim
U11 Seiko SSPT7F-12.5PF20PPM 32.768kHz Crystal, 12.5pf, 20ppm Digikey
U12 ECS ECX64 18.432MHz Crystal Digikey
U13 - LED 3.3V LED, 0805 Package Digikey
U14 Molex WM24032CT SD Card Socket Digikey
U15 - LED 3.3V LED, 0805 Package Digikey
U16 TI ADS7846 Resistive Touchscreen Controller Digikey
U17 FTI SFW8R-4STE1LF FFC Connector (for JTAG) FTI
U18 FCI 62674-241121ALF FFC Connector, 24 conductor Digikey
U19 TAOS TSL256X Light Intensity Sensor
U20 PNI MicroMag3 3-axis Magnetometer Sensor Sparkfun
U21 Avago ADJD-S371-QR999 RGB Colour Sensor Sparkfun
U22 Maxbotics LV-MAXSONAR-EZ1 Ultrasonic Distance Sensor Sparkfun
U23 - 2x10 0.1" Pitch header for JTAG
U24 Sparkfun IMU5DEG 5-DOF Inertial Measurement Unit Sparkfun
U25 Sparkfun IMU5DEG 5-DOF Inertial Measurement Unit Sparkfun
U26 VTI SCP1000 Absolute Pressure Sensor Sparkfun
U27 Melexis MLX90614 Non-contact Temperature Sensor Digikey or Future
U28 ECS 3963-BN Optional 20MHz Oscillator for Camera Digikey
U29 Sensiron SHT1x Temperature and Humidity Sensor
U30 Microchip MCP6S26-PGA Programmable Analog Gain Array Digikey
U31 Microchip dsPIC33FJ64GP706 Microcontroller Digikey
U32 - 2x04 0.1" Pitch Header for GPS Board
U33 FCI 62674-241121ALF FFC Connector, 24 conductor Digikey
U35 TI 74LVC138A 3-to-8 Decoder Digikey
U36 TI TPS789xx Voltage Regulator Digikey
U37 TI TPS789XX Voltage Regulator Digikey
U38 TI TPS79118 1.8V Voltage Regulator Digikey
U40 - 1x05 0.1" Pitch Header
U41 - 1x03 0.1" Pitch Header
U42 Panasonic EVQ BUTTON Reset Switch Digikey
U43 - LED 3.3V LED, 0805 Package Digikey
U44 National LM386 Op Amp Digikey
U46 - 1x02 0.1" Pitch Header
U47 CUI SJ-2524 3.55mm Headphone Connector Digikey
U48 FCI SFW15R-2STE1LF FFC Connector (top to bottom) Digikey
U49 FTI SFW8R-4STE1LF FFC Connector Digikey
U50 Rohm RBL161L Diode Digikey
DISP1 CMEL C0280QGLH-T 2.8" OLED Display, 16-bit colour, 320x240 resolution Vision-Opto or OSD

Power/Lower Display Board

Symbol Manufacturer Part Number Function Source
U1 Maxim MAX1555 LiPoly Battery Charger (USB Voltage) Digikey
U2 TI TPS63001 3.3V Buck/Boost Converter Digikey
U3 TI TPS65131 Positive/Negitive DC-DC Converter Digikey
U4 Dallas DS2764 LiPoly Battery Protector/Monitor
U5 Hirose HFQ461CT Connector for OLED Digikey
U6 - 1x02 0.1" Pitch header
U7 - LED 3.3V LED, 0805 Package
U8 IR IRLML6401 Mosfet Digikey
U9 IR IRLML6401 Mosfet Digikey
U13 Rohm RB161L Diode Digikey
U14 ON MBRM120L Diode Digikey
U15 ON MBRM120L Diode Digikey
U16 TI ADS7846 Resistive Touchscreen Controller Digikey
U17 - 1x02 0.1" Pitch header
U18 FCI 62674-241121ALF FFC Connector Digikey
U19 - 1x02 0.1" Pitch header
U20 CUI PJ-035-SMT Connector for Power (1.0mm ID, 3.5mm OD) Digikey
U21 GS405 Optional Connector and GPS Module Sparkfun
U22 FCI SFW15R-2STE1LF FFC Connector Digikey
U23 Lassen iQ Optional Connector and GPS Module Sparkfun
U24 - 2x04 0.1" Pitch header
U25 IR IRLML6401 Mosfet Digikey
DISP2 CMEL C0280QGLH-T 2.8" OLED Display, 16-bit colour, 320x240 resolution Vision-Opto or OSD
BAT1 Union PRT-00339 1000mAh LiPoly Battery Sparkfun

(Please see the Eagle source files for a more complete parts list)

      4.3 Source code and Firmware

The Science Tricorder Mark 2 contains two processors, and two sets of firmware — one for the AT91RM9200 core that runs linux and displays the graphical user interface, and a second for the dsPIC-based sensor co-processor that handles low-level sensor communication. The firmware for the sensor board is derived from the Science Tricorder Mark 1, and is written in Microchip C30 with project files for the MPLAB IDE. The source is divided into several sections:

The software for the AT91RM9200 core is a prototype for a graphical user interface that communicates with the sensor board and displays sensor data. It natively compiles using gcc on the Tricorder Mark 2 itself, or using a gcc-arm cross compiler on another platform (such as x86). To speed the development of the graphical interface, I wrote the code to be portable between
Debian/gcc/AT91RM9200 (target) and Windows XP/Visual Studio 2008/x86. By changing a single #define in portability.h, the code can compile a Win32 executable that redirects OLED display and touchscreen I/O to a hardware emulation thread for the user to interact with. Having the ability to compile and run graphical code across such vastly different environments is unusual, and made writing and testing GUI widgets much easier.

The software for the AT91RM9200 core is divided into several sections:

Both the sensor board firmware and the ARM920T graphical interface software are available in the source package, and are licensed under GPL v3.

      4.4 Known Errata

The Mark 2 was an ambitious project, and there are a few known errata:


Power / Lower Display Board

Sensor Board

In addition, there are a few features that were never tested:

Assembly and Interior Pictures

The bottom of the Science Tricorder Mark 2 motherboard. The sensor board is visible at the top.

The top of the Science Tricorder Mark 2 motherboard, with the top OLED display visible.

Another view of the bottom of the motherboard

The front of the prototype Sensor Board Mark 2A. Major components include the
Maxbotix ultrasonic range finger (left), various sensors (center), and the MicroMag3 3-axis magnetometer (right).

The back of the prototype Sensor Board Mark 2A. Major components include the
Sparkfun inertial measurement unit (left), dsPIC processor (center), and Maxbotix ultrasonic range finder (right)

The (mostly) power board of the Science Tricorder Mark 2, in the lower compartment. The bottom OLED display is also visible.

The power jack, charger, and lithium polymer battery protection circuit.

The errata notes that I ended up creating a very small NCP5810 OLED +5V/-5V breakout to replace the onboard unit, and placed it in the bottom compartment.

The lithium polymer battery fits snuggly in the open nook made by the L-shaped board, and replaces the 6 AAA batteries used in the Mark 1.

Exterior and Operating Pictures

The Science Tricorder Mark 2.

Another view of the Science Tricorder Mark 2. The OLED screens are extremely vivid, and have an incredible viewing angle.
They're almost like looking at the most vivid printed piece of paper you've ever seen. The iPod keyboard on the lower screen is just a bitmap underlay used for positioning for the touch keyboard code that I was using as a placeholder — you could use any bitmap, such as from Android (or design your own). The background on the top display is from a wonderful artist, Digital Blasphemy.

After getting some basic pixel graphics routines up including the font renderer and a bitmap loader, I worked on designing some widgets for displaying arbitrary sensor information. These widgets can take on any size, and progressively scroll the last 100 measurements from a given sensor from left to right. They're also auto-scaling, which is why you can see so much quantization error on the lower right widget -- it's displaying the non-contact temperature reading, which (in this case) is likely varying only small fractions of a degree.

If you look at the lower right widget, you can see three peaks — I've just waved my hand in front of the Tricorder three times, and it's picking up the heat. The widget auto-scales to the range of the minimum and maximum temperatures found in the recent measurements.

The widgets on the right side of the screen show the 3-axis magnetometer readings. Note the top 3 graphs showing the individual X/Y/Z axis field strengths, and the bottom widget showing the overall field strength. In this first of three images, I have brought a low intensity magnet near the Tricorder in a simple pattern — bringing it in once, then quickly twice, followed by three times. This is easily visible on the lower graph. The top-right graph is a sketch for a widget that displays a 3-dimensional direction, here the direction of the magnetic field. Also note the non-contact temperature widget, which has caught the temperature of the magnet as it passed into the field of view of the sensor.

The second of three images, showing the sensor data slowly scrolling from left to right.

The third of three images, showing the sensor data slowly scrolling from left to right.

The Tricorder has three ports on the top right side: (1) A microSD socket with the linux filesystem, (2) a USB device port that acts as a serial console, and (3) a USB Host port that allows one to connect an external USB device, such as a memory stick or a WiFi adapter. The image on the screen is another background from a wonderful site, Digital Blasphemy.

A display and font test on the bottom OLED screen after boot-up at the linux serial console. One can use the serial console for development, although I preferred to plug in a WiFi adapter and SSH/SFTP into the Tricorder to upload and run new code.

The Tricorder folds together wonderfully, protecting both organic LED touch displays.

Some of the scuff marks from the process of constructing the case are visible. Typically I hold the polystyrene parts together tightly with scotch tape while gluing them together, so that they can sit undisturbed for a while to bond.

The top bits for this case still aren't complete, to allow easy access to the sensor board for coding and debugging the Microchip dsPIC.

Another view of the Science Tricorder Mark 2, unfolded

Another view of the Science Tricorder Mark 2, unfolded


This project was generously sponsored in the form of commercial samples from both Atmel and Microchip's sampling program. I would also like to gratefully acknowledge the generosity of several folks who were more than happy to help out a graduate student building a Tricorder. In particular, Melexis very generously sent a wonderful assortment of their MLX90614 series of non-contact temperature sensors, for which I am ever thankful.

I would like to express my thanks to Paul Thomas, of the Linux Stamp, for publishing a set of step-by-step instructions for getting Debian Linux running on a AT91RM9200 system. Without his efforts, I am sure I would have found the process intimidating.

I would also like to thank my Dad, who taught me how to make, create, design, build, program, and solder from a young age. I consulted him for his advice at each stage of the project, and he is ever willing to lend a hand if I need one. He also financially contributed to the project, and very much wants a Tricorder to play with, because it's "really cool".

(c) 2011-2012 the Tricorder project. Terms of use. dream | share | make | give