• 

• 

• 

• Home
• About and Story
• Tricorder Mark 1
• Tricorder Mark 2
• Community Forum
• Blog
• Contact

 

Contents
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:

      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:

• Processor: Atmel AT91RM9200 ( ARM920T 32-bit RISC core / 180MHz )
• Displays: Dual 2.8" Organic LED displays, 320x240 resolution, 16-bit colour depth
• Display Controller: Integrated Epson S6E63D6
• Input: Dual resistive touchscreens (one on each Organic LED display)
• Memory: 32MB SDRAM
• Flash: Atmel AT45DB642D 8MB Dataflash for boot
• SD Card socket: Micro SD socket, stores Linux OS and filesystem
• Battery: Rechargeable Lithium Polymer (1000mAh)
• Ports: USB device (serial console), USB Host (for connecting memory sticks, WiFi, etc.), External Power Adapter
• Sensor Board Processor: Microchip dsPIC33FJ64GP706 ( 16-bit / 40MIPS / 16k RAM / 64K FLASH )
• 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.

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.

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.

      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.

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:

• 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:

• Sensors: Functions to request sensor data from the sensor board, and interpret sensor data packets
• Font Renderer: Functions to render text on the screen with a preloaded bitmap-based font
• Graphics: Basic functions for bitmap loading, as well as fundamental drawing (pixels, lines, etc.)
• Widgets: Simple widgets to contain and display sensor data, such as the auto-scaling graph with a FIFO buffer.
• On-screen Keyboard: Functions for a simple on-screen QWERTY keyboard, with a customizable bitmap graphic
• Touchscreen: Functions to poll the resistive touchscreen and retrieve position data

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:

Motherboard

• JTAG: Added a jumper from AT91RM9200 Pin 115 (NRST) to JTAG FFC connector pin 6 (JTAG_NTRST)
  
• 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.

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

• Optional audio subsystem (Motherboard): Untested
• GPS Breakout boards: Lassen iQ works on the Mark 1, but untested here. GS405 module untested.
• TSL256x footprint: Untested
• SHT11: Works on the Mark 1, but untested on the Mark 2

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.

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