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.

Sensors

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:

Hardware

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:

Breadth:"To place as many different kinds of sensors as possible into one device".Comment:: I feel as though this worked well in the Mark 1, within the scope of using many low-cost, off-the-shelf sensors, and in the context of the physical space limitations of placing them all within a very small space. My two comments in this regard are that: (1) The Mark 1 lacked an imaging sensor, such as a CCD. It seems like a bunch of sensors (like the polarimeter, or a simple spectrometer) might be easily rolled into an existing small imaging sensor, like a cell phone camera, with some modification, and this would greatly increase the sensing capabilities of the Tricorder. (2) Increasing the diversity of sensors is likely to be an ongoing process in Tricorder development. As new sensors are developed, it should be easy to incorporate them into the Tricorder with a minimum of effort, and only require upgrading the sensor board itself.

Tractability:"To try and use off-the-shelf components as much as possible, to decrease development time"Comment (Hardware):: On the hardware side, this went very well. Nearly everything in the Mark 1 was off-the-shelf, or could be made by easily modifying off-the-shelf components (such as in the case of adding linear polarizers to ambient light sensors, to create the linear polarimeter). Most analog sensors were replaced with low-noise "smart" sensors early on, to decrease noise and prevent having to develop hardware filters. I also experimented with creating custom sensors, such as a high energy particle detector from silicon photodiodes, and a visible spectrometer from a linear CMOS array, to see if small and inexpensive versions of these could be easily constructed with a minimum of effort. In some cases, the hardware focused on tractability at the sacrifice of ease of sourcing parts — for instance, both the original ACX705AKM LCD display and Epson SED1375 controller were relatively easy to use, and inexpensive, but also somewhat difficult to source in quantity, making it a bit tricky to build a large number of Tricorders.
Comment (Software):: The software generally went very well, and I was able to use low-level graphics code I had previously developed to get the Mark 1 up, running, and displaying sensor data quickly. Some of the low-level protocols for the sensors were tricky to debug without the use of a logic analyzer (which, as a student, I didn't have easy access to at the time). In addition, while I love Microchip's MPLAB IDE and PIC family of microcontrollers, the code-compile-program-verify-debug-repeat cycle of working with a microcontroller felt a little tedious at times — particularly when working with graphics or interface code, when one might move a UI widget over a few pixels, recompile, upload to the PIC, execute the code, check the placement, modify, and so forth, at length. Though a labor of love, it seemed like if this could be streamlined, it would have saved a lot of time, or allowed more features to have been added.

All in all, the development fit tractably in a 6-month time frame with as much spare time as a grad student could spare, and allowed plenty of time to prototype, explore different options, and learn a bunch from each of them.

Accessibility (comfort):"To create a device that was small enough to be easily carried with you in a pocket or bag, and that felt natural, not awkward, to use"Comment:: This was good. The Tricorder Mark 1 fits snuggly into my pocket, but decreasing its thickness would allow space for other things to be in ones pocket too. The flip design is extremely comfortable to use, and tends to mould to the contour of ones hand. The weight is comfortable, and mostly comes from the six AAA batteries in the bottom — so it has the potential to be decreased substantially by moving to a different power source.

Accessibility (cost):"To create something that was as inexpensive as possible, so that people might easily have access to them without having to worry about the cost".Comment:: This is something I don't feel I did very well on. A ballpark estimate for the component cost of a single Mark 1 was about $500 when I constructed it, which feels like too much. For every household to have their own Tricorder, it feels like something around $100 to $200 is a more accessible price range, and to have one in every child's hand such that they might easily learn more about their worlds both in and (especially) outside of school, that number likely has to be under $50. Thankfully, much of the cost comes from sensors (which are rapidly decreasing in cost), and from PCB production (which is almost negligible in quantity).

Intuitiveness:"To create simple and intuitive methods of visualizing the sensor data, that a high-school student would find easy to understand."Comment:: This worked, but only in as much as the limitations of an embedded system with an 8-bit 240x160 display and a 40MIPS microcontroller with 30k of RAM would allow. Data visualization and user interface design are avid interests of mine, and I'm very excited to sketch out visualization and interface ideas on the Tricorder that help the user explore. While the Tricorder Mark 1 is incredibly "cool", it would be wonderful for a Tricorder's visualizations and interface to be elegant, visually pleasing, and help convey some of the natural beauty present in the data.

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:

Sensor Expansion: Sensor board and motherboard are interconnected through a single flat flex cable (FFC), making it physically easy to upgrade. The sensor board contains a co-processor to handle low-level sensor communication, and a predefined protocol for all sensor communication, easing future sensor board development.

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:

External Memory Bus: Unlike most microcontrollers, the Atmel AT91RM9200 has a full external memory bus. This would allow one to have comparatively large amounts of external SDRAM for program execution, but also allow fast and direct memory writes to an external display controller.

Operating System Support: With its external memory controller, the AT91RM9200 is able to run a full (non-embedded) distribution of Debian Linux. There was also lots of documentation from a bunch of sources to help get one up and running with ARM Linux on the processor.

2-layer PCB compatibility: My research suggests that the AT91RM9200, at 180MHz, is about the fastest processor that one was likely to successfully
route a 2-layer board for — and migrating to a 4 layer board would increase prototyping costs quite a bit, which is prohibitive. Similarly, the processor is
available in a dense QFP package (with 208 pins spaced 0.4mm apart), which is close to the edge of what can be done with a 2-layer board before having to
migrate to a ball gate array.

Existence proofs: Apart from the official reference design, other folks had successfully used the processor to construct their own boards — and
this made me feel a lot better about tractability. The most popular of these designs was the Linux Stamp, which
also (critically) had collected plenty of documentation from other folks' attempts at booting custom AT91RM9200 boards, and distilled this information into a
simple tutorial.

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:

Schematics: Eagle files for the Motherboard, Sensor and Power Boards, as well as a number of smaller connector breakout boards

Boards: 2-layer Eagle board artwork

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.

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:

Sensors: Low-level functions to initialize each sensor, communicate with low-level sensor registers to retrieve sensor data, and parse that data
into a physically-grounded measure such as degrees Celsius or microTesla.

Communication: SPI communication routines that listen for sensor data requests from the host ARM processor, interpret the packets, and send sensor
data to the host.

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:

4.4 Known Errata

FT232R: Initially I had designed the FT232R USB-to-Serial system to be self-powered by the Tricorder, but this made it difficult for me to connect
except at initial power up. Modifying the configuration to be powered by the USB bus means that the FT232R will reset each time the USB cable is connected,
and made USB->Serial communication work with far less effort. Please see the reference designs in the FT232R datasheet.

Power / Lower Display Board

Big Capacitor: There's a lot going on in the Tricorder Mark 2, and a lot that uses 3.3V. I found the system stability vastly improved by sticking
a large capacitor on the 3.3V bus — as high a value as you can safely fit in (on the motherboard, as well). Ditto for the +5/-5V, or you may notice some flicker on the OLED displays.
Because of this, I tend to include plenty of 10uF 1206 capacitors on more recent projects, but those seemed big at the time.

TPS65131: For an unknown reason, the voltage collapses on the +5/-5V buck/boost/inverter circuit under any load. I migrated to the NCP5810, and have included a tiny
breakout that one can easily attach. This is where the brightly coloured wire wrap in the pictures below comes in. :)

Sensor Board

dsPIC33FJ64GP706: Pins 9 (GND) and 10 (VDD) are accidentally swapped on the schematic. The pins on the footprint are correct — simply swapping
these should fix the issue. On the fab board I just lifted the pins.

MLX90614: I seemingly forgot to physically connect the SMBUS pins back to some I/O pins on the processor. I wire wrapped these to
pins 52 (RD4) and 55 (RD7).

TCM8230MD: If you try to reflow the CMOS camera, it will melt. I found out later that it's supposed to be placed in a carrier that is soldered to
the board. Unfortunately I haven't been able to find one, so the camera remains untested.

SCP1000: Have been unable to successfully communicate with this sensor. The sensor is extremely difficult to solder and very easy to damage,
so it's not clear whether this is a hardware, software, or damage issue. Recommend migrating to a different barometric pressure sensor on future versions.

MCP6S26-PGA: Unable to successfully communicate with the MicroMag3 when the Programmable Analog Gain Array was attached. They share the same SPI
bus, and in the interests of time I simply unsoldered the MCP6S26 without further investigating the issue.

Acknowledgements

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".