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:
Atmospheric Temperature and Humidity
-40°C to +120°C, ± 0.5°C accuracy
± 0.1°C repeatability
3-axis Magnetic Field Sensor
±1100 µT range, 0.015µT resolution
up to 2000 samples/second
Atmospheric Temperature and Humidity
0 to 100% RH, ± 3% accuracy
± 0.1% repeatability
Colour RGBC Sensor
10-bit resolution per channel
Absolute Pressure Sensor
30kPa to 120kPa, 1.5 Pa resolution
Non-contact IR Thermometer
-70°C to +380°C, 0.02°C resolution
± 0.5°C to ±4°C accuracy over range
300nm to 1000nm responsivity,
<5m (50%), <8m (90%) accuracy
1 Hz update
Ultrasonic distance sensor
0-6m range (approx), 2.5cm resolution
Sparkfun Inertial Measurement Unit breakout (5 degrees of freedom)
±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:
- 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.
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:
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:
|U1||Atmel||AT91RM9200-QU-208||ARM920T Processor (180MHz)||Digikey|
|U5||Hirose||HFQ461CT||Connector for OLED Display||Digikey|
|U6||-||LED||3.3v LED, 0805 Package||Digikey|
|U9||Assmann||AE9924||USB Host connector||Digikey|
|U11||Seiko||SSPT7F-12.5PF20PPM||32.768kHz Crystal, 12.5pf, 20ppm||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|
|U32||-||2x04||0.1" Pitch Header for GPS Board|
|U33||FCI||62674-241121ALF||FFC Connector, 24 conductor||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|
|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|
|DISP1||CMEL||C0280QGLH-T||2.8" OLED Display, 16-bit colour, 320x240 resolution||Vision-Opto or OSD|
|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|
|U16||TI||ADS7846||Resistive Touchscreen Controller||Digikey|
|U17||-||1x02||0.1" Pitch header|
|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|
|U23||Lassen||iQ||Optional Connector and GPS Module||Sparkfun|
|U24||-||2x04||0.1" Pitch header|
|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
4.4 Known Errata
The Mark 2 was an ambitious project, and there are a few known errata:
- 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. :)
- 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
Assembly and Interior Pictures
Exterior and Operating Pictures
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".