Embedded Sensor Innovation at MIT

During his June 5 keynote address at they 2013 Sensors Expo in Chicago, Joseph Paradiso presented details about some of the innovative embedded sensor-related projects at the MIT Media Lab, where he is the  Director of the Responsive Environments Group. The projects he described ranged from innovative ubiquitous computing installations for monitoring building utilities to a small sensor network that transmits real-time data from a peat bog in rural Massachusetts. Below I detail a few of the projects Paradiso covered in his speech.


Managed by the Responsive Enviroments group, the DoppelLab is a virtual environment that uses Unity 3D to present real-time data from numerous sensors in MIT Media Lab complex.

The MIT Responsive Environments Group’s DoppleLab

Paradiso explained that the system gathers real-time information and presents it via an interactive browser. Users can monitor room temperature, humidity data, RFID badge movement, and even someone’s Tweets has he moves throughout the complex.

Living Observatory

Paradiso demoed the Living Observatory project, which comprises numerous sensor nodes installed in a peat bog near Plymouth, MA. In addition to transmitting audio from the bog, the installation also logs data such as temperature, humidity, light, barometric pressure, and radio signal strength. The data logs are posted on the project site, where you can also listen to the audio transmission.

The Living Observatory (Source: http://tidmarsh.media.mit.edu/)


The GesturesEverywhere project provides a real-time data stream about human activity levels within the MIT Media Lab. It provides the following data and more:

  • Activity Level: you can see the Media Labs activity level over a seven-day period.
  • Presence Data: you can see the location of ID tags as people move in the building

The following video is a tracking demo posted on the project site.

The aforementioned projects are just a few of the many cutting-edge developments at the MIT Media Lab. Paradiso said the projects show how far ubiquitous computing technology has come. And they provide a glimpse into the future. For instance, these technologies lend themselves to a variety of building-, environment-, and comfort-related applications.

“In the early days of ubiquitous computing, it was all healthcare,” Paradiso said. “The next frontier is obviously energy.”

Embedded Wireless Made Simple

Last week at the 2013 Sensors Expo in Chicago, Anaren had interesting wireless embedded control systems on display. The message was straightforward: add an Anaren Integrated Radio (AIR) module to an embedded system and you’re ready to go wireless.

Bob Frankel demos embedded mobile control

Bob Frankel of Emmoco provided a embedded mobile control demonstration. By adding an AIR module to a light control system, he was able to use a tablet as a user interface.

The Anaren 2530 module in a light control system (Source: Anaren)

In a separate demonstration, Anaren electrical engineer Mihir Dani showed me how to achieve effective light control with an Anaren 2530 module and TI technology. The module is embedded within the light and compact remote enables him to manipulate variables such as light color and saturation.

Visit Anaren’s website for more information.

CC274: A Sensory Experience

The May issue of Circuit Cellar provides a number of articles focusing on how to utilize measurements and sensors in your designs.

Knowing how to generate a magnetic field to calibrate a sensor can help with a number of

Winding 25 turns of 26 AWG enamel wire on a toroid is normally difficult, but that slit made it very easy. You would wind much smaller wire on a toroid used as an inductor.

DIY projects. Most electronic devices use inductors or transformers that depend on magnetic fields. In the May issue, Ed Nisley describes how he used a small ferrite toroid to produce a known magnetic field, which he utilized to calibrate some cheap Hall-effect sensors he obtained on eBay (p. 52).

“While the results certainly don’t transform cheap sensors into laboratory instruments, you can use them for tech jewelry with a clear conscience,” Nisley says. “You’ll also have a better understanding of magnetic fields, which may come in handy when you’re building inductors.”

Whether you’re designing a small controller for your own use or an electronic device for mass production, it’s important to keep “testability” in mind. So, it’s a good idea to make a dedicated tester for your product part of the design process at the outset. Such a tester can ensure your device is working properly in your workshop—before it ships to a customer. On page 56, George Novacek describes how an inexpensive tester can bolster an electronic device’s reliability and increase its marketability.

Brothers Robert and Donald Kunzig, both with backgrounds in the telecommunications industry, stepped outside the technologies most familiar to them when they took on an ambitious project—to produce an accurate and easy to use wireless, energy-usage monitor. They also wanted the monitor to hold its collected data even during a power outage or a router issue. Did they succeed? Check out their article on page 18 to find out.

The DNA sequencer’s design includes a motor controller, a light sensor amplifier, and an injector driver circuit.

While DNA, the molecule that provides genetic instruction to all living organisms, is complex, building a DNA sequencer can be relatively simple. Fergus Dixon used a light sensor amplifier,  a motor controller, and an injector driver circuit to fulfill a customer’s request for a DNA sequencer with a color screen and full connectivity via Ethernet or Bluetooth (p. 26)

If you’re a DIYer who is nervous about possible levels of radiation in your home, find out how to build a hand-held radiation sensor on page 60.

Also, Jesús Calviño-Fraga describes how he built a serial port-to-SPI bridge programmer, the “S2S Dongle,” which functions without a pre-programmed microntroller (p. 34).

Finally, this issue includes articles that wrap up intriguing projects Circuit Cellar introduced in April.

Last month, Jeff Bachiochi explored the musical instrument digital interface (MIDI). In Part

An Atmel ATmega88 microcontroller is at the heart of the CNC router controller.

2, he focuses on a hardware circuit that can monitor the MIDI messages sent between his project’s MIDI devices, which include a Harmonix drum kit used with the Xbox version of the Rock Band video game (p. 68).

Brian Millier calls his construction of a microcontroller-based, G-code controller for a CNC router one of his most challenging DIY projects. The second article in his series focuses on two functional blocks: the axis controller and the host controller (p. 42.)

Q&A: Stephan Lubbers (Sensory Innovation)

Stephan Lubbers enjoys sensing technology. He is a creative engineer and inventor whose designs often build on his need to monitor data and figure out how things work. Steve and I recently discussed some of his designs, his contest-entry process, his thoughts on the future of embedded technology, and what’s currently happening on his workbench.—Nan Price, Associate Editor

NAN: Where are you located?

Stephan Lubbers

Stephan Lubbers in his workspace

STEVE: I live in Dayton, OH.

NAN: Where did you go to school and what did you study?

STEVE: My formal education is a BS in Computer Science from Wright State University, Fairborn, OH. Outside of schools, I’ve taught myself many things ranging from radio electronics to achieving an extra class amateur radio license, to assorted computer languages, to FPGA programming—all from just sitting down and saying, “Let’s learn this.”

NAN: Tell us about your current occupation.

STEVE: I am employed as a Senior Software Engineer at Beijing West Industries, where I develop embedded systems that go under the hood of high-end automobiles. (BWI is the owner of what was once General Motors’s Suspension and Brakes components company.) If your “Service Vehicle Soon” light comes on, I may have written the code behind it.

NAN: Tell us about your technical interests.

STEVE: My technical interests fall into two categories. I like to build systems around new sensing technologies and I build systems to support ham radio.

I never really thought about specific technical interests until I was asked this question. Looking at the Circuit Cellar contests I’ve entered and exploring my parts closet, I discovered that I have an abundance of sensors and sensor systems. When a new sensing device comes out, I often get one, play with it, and then look around for something to do with it. That usually results in an invention of some kind. I’ve analyzed the motion of rodeo bulls and dogs with microelectromechanical (MEMS) accelerometers, tracked eyeball movements with optical sensors, and computed automobile speeds using both GPS and microwave electronics. I don’t know if it is cause or effect, but I was always amazed by the “tricorder” on Star Trek. Do I like sensors because of Scotty and Mr. Spock? Or did I watch Star Trek because of the gadgets? I don’t know.

My love of electronics led me to amateur radio at a young age. I wasn’t as much interested in talking to other people as I was in exploring the technology that enables people to talk. I had a little success building RF devices but found that I had a real knack for digital systems. I’ve used that ability to create satellite tracking controllers, antenna switchers, and computer-to-radio interfaces.

NAN: How long have you been reading Circuit Cellar?

STEVE: I’ve subscribed to Circuit Cellar since Issue 1. I still believe the tagline that said “Inside the Box Still Counts.”

NAN: You’ve written four articles for Circuit Cellar. Some focus on data logging, monitoring, and analysis. For example, your article “Precision Motion-Sensing System Analyzer” (Circuit Cellar 192, 2006) is about a microcontroller-based, motion-sensing system for bull riders. What inspired you to create this system?

STEVE: Several things came together to spark the creation of the “Precision Motion-Sensing System Analyzer,” a.k.a. the BuckyMeter. I had already begun work on a motion-logging system but had no clear goal in mind. Shortly after the logger started working, Circuit Cellar announced its 2005 design contest. I had a short-term goal of entering the contest with my data logger. But what should I log?

My dad provided the suggestion to strap the logger onto the back of a rodeo bull. My parents had become fascinated by the sport of professional bull riding and thought it would be fun to get behind the scenes by doing this science experiment. One of the questions I had when designing the system was: “What kind of maximum G force can I expect to see?” Nobody had an answer, but the doctors responsible for repairing bull riders thought it was an interesting question. They, too, wanted to know that answer. That question opened a few doors to give us access to some bulls. EE Times printed a humorous article about my experience strapping an electronic device on the back of 1,200 lb of angry cow. It was definitely an experience!

The BuckyMeter hardware went through several iterations. In the end, an off-the-shelf Motorola Z-Star evaluation module could be used to instrument the bull with the added bonus of wireless data logging.

The project died out after a trip to instrument competition-grade bulls from American Bucking Bull, Inc. (ABBI). In hindsight, I learned an important lesson about managing customer expectations. I went to Oklahoma on a mission to collect data and try out an engineering prototype. I think the people I met with were expecting to see a polished product. Their impression, after our meeting, was that an electronic scoring aid was too slow and too complicated.

NAN: Another article, “Electronic Data Logging and Analysis: A How-To Guide for Building a Seizure-Monitoring System” (Circuit Cellar 214, 2008), describes an Atmel ATmega32-based electronic monitoring system that enables pet owners and vets to monitor epileptic seizure patterns in dogs. How does the microcontroller factor into the design?

STEVE: My seizure monitor was an offshoot of the rodeo bull motion-sensing system. The original processor had way more power than was needed and it was difficult to hand solder the part. With a working baseline from the BuckyMeter, it was easy to pick a different chip to work with. I had some experience with Atmel AVRs from a previous Circuit Cellar contest, so I looked at its product line. I had a good estimate for RAM/ROM requirements, and I decided it would be nice to have additional SPI channels to interface with the accelerometers. That led to the selection of the ATmega32. It didn’t hurt that another Atmel contest popped up in 2006 when I was in the middle of the design.

I have always wanted to expand my data beyond a single patient to see if my theory held up, so I supplied systems to some other people with epileptic dogs. This required continuous design updates mostly to keep up with outdated parts. Unfortunately, I never got any data back from the systems I gave away. My pet (and science guinea pig) passed away a few years ago, so I don’t have a subject to continue with this project.

NAN: At the end of your article, “Doppler Radar Design” (Circuit Cellar 243, 2010), you note that upgrades to the project (e.g., an enclosure and a portable power supply) could make the system “an easy-to-use mobile device.” Tell us about the design. Did you end up implementing any of those upgrades?

STEVE: Doppler Radar Design has been my most popular project. I get e-mails all the time asking how to reproduce it. As I stated in the article, the RF section is now hard to come by and expensive. Not being an RF engineer, I haven’t been able to recommend replacement parts.

The project started when my dad loaned me the microwave electronics to play with. He had wired them up for two-way ham radio communications. I couldn’t manage to make any radio contact with anybody but myself, so I started looking for other experiments to perform. In one of the experiments, I learned how to make a motion detector. From that, I decided to try to turn the project into a speed radar.

This project took help from a lot of other people because I really didn’t know what I was doing. Some radar discussions on the Internet outlined the basic design for Doppler speed radar, so I followed the suggestions, essentially a transmitter/receiver pair supplied by my borrowed Gunnplexer and a frequency detector (FFT) to show the Doppler shift of the returned signal. Accounting for the radio frequency in use gives you the speed of the reflected target, which in my case was a car.

When I discovered Ramsey Electronics sells a radar kit for $100, I decided that my Doppler radar was really just a science experiment. It was educational for me, but for everyone who contacted me just wanting to have their own radar, the Ramsey option was cheaper, more accurate, and already packaged for portability.

I did get some helpful hints from Alan Rutz at SHF Microwave Parts Company, who suggested something called a dielectric resonator oscillator (DRO) could be used in place of the Gunnplexer I used. The advantage of his approach is that DROs are available and cost about $20. I have not yet been successful with this upgrade.

NAN: The Renesas Electronics RX62N development board is at the heart of your KartTracker’s monitoring system (“KartTracker: A GPS-Based Vehicle Timing & Monitoring System,” Circuit Cellar 259, 2012). Tell us about the design and how the KartTracker functions.


KartTracker: A GPS-Based Vehicle Timing & Monitoring System

STEVE: The KartTracker came about one day when the neighborhood NASCAR fans went out racing karts. We wondered how fast we went, so the local engineer (me) set about finding out.

I started with a GPS receiver and a data logger and drove around the track to see what happened. As it turns out, GPS receivers automatically give you your speed! That was too easy, so I started looking for more features.

The next couple of races I watched, I tried to pay attention to more than just the action and saw that teams were very concerned with lap times. Well, I could time my laps, but that didn’t seem very interesting or complicated enough. Then I saw a qualifying session where the TV showed a continuous real-time comparison between two cars. That seemed cool! If I could build that, I could race myself to see if I was doing better or worse.

So, the KartTracker concept was born. A GPS receiver feeds continuous position data into a Renesas RX62N board. The software continuously compares my time at some location against the last time I was there. It’s like looking at the lap time, but it updates every couple of seconds so you have continuous feedback.

All the timing data is retained so later we can compare times against each other and brag about who went the fastest. I would like to broadcast the times back to the spectators, but that radio is a project for another day.

NAN: You received an Honorable Mention for your 2010 Texas Instruments DesignStellaris Design Contest entry, “Hands-Free USB Mouse.” Tell us about the project and your contest-entry process.

Hands-Free USB Mouse

2010 Texas Instruments DesignStellaris Design Contest Honorable Mention “Hands-Free USB Mouse”

STEVE: My eyePOD hands-free USB Mouse is a head-mounted motion sensor that controls the mouse cursor on a PC. By moving your head, the mouse moves around the screen. You wink your eyes to click the mouse buttons. The goal was to produce a PC interface for someone who couldn’t use a typical mouse, with a secondary goal of teaching me about USB. There are some problems in certain lighting conditions, but overall it works pretty well.

After about a dozen contest entries, I have a bit of a process for creating an entry. I hope I don’t hurt my future chances by sharing my secrets, but since you asked, three things need to line up for me to start a project (contest or otherwise): I need an idea, I need some technology, and I need motivation.

Author James Rollins says, “Don’t ask where the ideas come from.” But, if you have to know, his story ideas come from a box. My contest ideas come from a little red notebook. In reality, we don’t know where the actual ideas come from, but when we get ideas we put them in the box (or book) and make a withdrawal when we need to use an idea.

Part two is that there needs to be a technology that will support the idea. I couldn’t build a rodeo bull monitor until there were cheap accelerometers available. I couldn’t build the KartTracker without a GPS. So, keep a list of technologies you like in your box of ideas.

Finally, you need motivation to execute the project. At work, your boss provides the motivation in the form of a paycheck. At home, you might have a dog that needs help or a neighbor who supplies beer for the answer of how fast his kart is. When I put the three pieces together, I have the starting point for a project. Apply your abilities and start building.

The only biggie after that is time management. Somewhere there is a deadline you need to meet. Do consistent work on your project and prioritize what needs to be done. I have a knack for drawing a line through the critical parts of a project to make sure I have something working when the end is near. You can always go back and improve a working project, but if you have too many half-built features, you have nothing to fall back on when time runs out. A good example is the radio link for the KartTracker. Without GPS and timing software, the project would be nothing. When I had time remaining, I added file I/O and data storage on an SD card. Nice features, but they weren’t necessary to demonstrate the project. The radio link fell by the wayside when entry time came up.

Finally, don’t forget the book report at the end. The judges need to know what you did, so you need to write about it. Who knows? Circuit Cellar might like what you wrote and decide to turn it into an article.

NAN: Have you recently purchased any embedded technology tools to help you with your data logging, monitoring, and analysis projects?

STEVE: My most recent tech purchase was an iPod Touch funded from a recent Circuit Cellar publication. Before you say, “That’s not embedded,” let me explain. I tend to make the user interfaces to my projects simple and to the point. Circuit Cellar contest deadlines don’t lend themselves to creating a new fancy interface for each project. Instead, I would offload debugging, control, and extra features to an external system. I started out using RS-232 serial to a PC. For portability and speed, I moved to a PalmPilot with an infrared data access  (IrDA) interface. A Bluetooth or Wi-Fi interface seems like a logical progression to me. The iPod Touch has these interfaces and it leaves me with a new gadget to play with.

A more embedded acquisition is the Texas Instruments MetaWatch. If you haven’t seen one of these, it’s a stylish digital watch that talks to your smartphone. For the more adventurous, the source code is available so you can add your own features. There must be something great that I can do with a wrist-mounted computer, I just haven’t had the “ah-ha” moment yet.

NAN: Are you currently working on or planning any embedded-design-related projects?

STEVE: I call my current project the SeeingEye for a dog. The blind have used guide dogs since the 16th century. That’s a huge debt man owes his best friend! To help repay that debt, I’m creating a twist on the seeing eye dog by creating a seeing eye for a friend’s vision-impaired dog. Using the sensors and technology robots use for collision avoidance, the SeeingEye will detect obstacles in a dog’s path. The trick seems to be the user interface to convey the collision avoidance information and training the dog to respond correctly to the stimulus. I figure if microchips in robots can learn to avoid walls, then puppy neurons should be able to do the same thing. I still have more work to do to figure out how to get the sensor to stay in place.

SeeingEye board

SeeingEye for dogs, circuit board


SeeingEye for dogs, in “use”

NAN: Do you have any thoughts on the future of embedded technology?

STEVE: As a builder of embedded systems, I am amazed at all of the things we can do with high-speed processors and multiple megabytes of memory. It seems like if we can imagine it, we can build it.

As a user of embedded technologies, it sometimes seems like the engineers are trying to be too clever by stuffing anything they can into the box whether those features are needed or not.

The complexity of some devices has skyrocketed to the point that stability has been affected and users don’t know what features they have or how to use them. We now take for granted a constant stream of software updates to our devices and press reset when it doesn’t work as desired.

Einstein is credited with saying, “Everything should be made as simple as possible, but no simpler.” I’d like to see the industry adopt Einstein’s advice and the “Keep it simple, stupid!” (KISS) principle to help us manage the growing complexities. We’d spend less time serving our devices by trying to make them work and more time being served by our devices as they flawlessly do the work we want done.

Autonomous Mobile Robot (Part 1): Overview & Hardware

Welcome to “Robot Boot Camp.” In this two-part article series, I’ll explain what you can do with a basic mobile machine, a few sensors, and behavioral programming techniques. Behavioral programming provides distinct advantages over other programming techniques. It is independent of any environmental model, and it is more robust in the face of sensor error, and the behaviors can be stacked and run concurrently.

My objectives for my recent robot design were fairly modest. I wanted to build a robot that could cruise on its own, avoid obstacles, escape from inadvertent collisions, and track a light source. I knew that if I could meet such objective other more complex behaviors would be possible (e.g., self-docking on low power). There certainly many commercial robots on the market that could have met my requirements. But I decided that my best bet would be to roll my own. I wanted to keep things simple, and I wanted to fully understand the sensors and controls for behavioral autonomous operation. The TOMBOT is the fruit of that labor (see Photo 1a). A colleague came up with the name TOMBOT in honor of its inventor, and the name kind of stuck.

Photo 1a—The complete TOMBOT design. b—The graphics display is nice feature.

In this series of articles, I’ll present lessons learned and describe the hardware/software design process. The series will detail TOMBOT-style robot hardware and assembly, as well as behavior programming techniques using C code. By the end of the series, I’ll have covered a complete behavior programming library and API, which will be available for experimentation.


The TOMBOT robot is certainly minimal, no frills: two continuous-rotation, variable-speed control servos; two IR (850 nm) analog distance measurement sensors (4- to 30-cm range); two CdS photoconductive cells with good lux response in visible spectrum; and, finally, a front bumper (switch-activated) for collision detection. The platform is simple: servos and sensors on the left and right side of two level platforms. The bottom platform houses bumper, batteries, and servos. The top platform houses sensors and microcontroller electronics. The back part of the bottom platform uses a central skid for balance between the two servos (see Photo 1).

Given my background as a Microchip Developer and Academic Partner, I used a Microchip Technology PIC32 microcontroller, a PICkit 3 programmer/debugger, and a free Microchip IDE and 32-bit complier for TOMBOT. (Refer to the TOMBOT components list at the end of this article.)

It was a real thrill to design and build a minimal capability robot that can—with stacking programming behaviors—emulate some “intelligence.” TOMBOT is still a work in progress, but I recently had the privilege of demoing it to a first grade class in El Segundo, CA, as part of a Science Technology Engineering and Mathematics (STEM) initiative. The results were very rewarding, but more on that later.


A control system for a completely autonomous mobile robot must perform many complex information-processing tasks in real time, even for simple applications. The traditional method to building control systems for such robots is to separate the problem into a series of sequential functional components. An alternative approach is to use behavioral programming. The technique was introduced by Rodney Brooks out of the MIT Robotics Lab, and it has been very successful in the implementation of a lot of commercial robots, such as the popular Roomba vacuuming. It was even adopted for space applications like NASA’s Mars Rover and military seekers.

Programming a robot according to behavior-based principles makes the program inherently parallel, enabling the robot to attend simultaneously to all hazards it may encounter as well as any serendipitous opportunities that may arise. Each behavior functions independently through sensor registration, perception, and action. In the end, all behavior requests are prioritized and arbitrated before action is taken. By stacking the appropriate behaviors, using arbitrated software techniques, the robot appears to show (broadly speaking) “increasing intelligence.” The TOMBOT modestly achieves this objective using selective compile configurations to emulate a series of robot behaviors (i.e., Cruise, Home, Escape, Avoid, and Low Power). Figure 1 is a simple model illustration of a behavior program.

Figure 1: Behavior program

Joseph Jones’s Robot Programming: A Practical Guide to Behavior-Based Robotics (TAB Electronics, 2003) is a great reference book that helped guide me in this effort. It turns out that Jones was part of the design team for the Roomba product.

Debugging a mobile platform that is executing a series of concurrent behaviors can be daunting task. So, to make things easier, I implemented a complete remote control using a wireless link between the robot and a PC. With this link, I can enable or disable autonomous behavior, retrieve the robot sensor status and mode of operations, and curtail and avoid potential robot hazard. In addition to this, I implemented some additional operator feedback using a small graphics display, LEDs, and a simple sound buzzer. Note the TOMBOT’s power-up display in Photo 1b. We take Robot Boot Camp very seriously.

Minimalist System

As you can see in the robot’s block diagram (see Figure 2), the TOMBOT is very much a minimalist system with just enough components to demonstrate autonomous behaviors: Cruise, Escape, Avoid, and Home. All these behaviors require the use of left and right servos for autonomous maneuverability.

Figure 2: The TOMBOT system

The Cruise behavior just keeps the robot in motion in lieu of any stimulus. The Escape behavior uses the bumper to sense a collision and then 180° spin with reverse. The Avoid behavior makes use of continuous forward-looking IR sensors to veer left or right upon approaching a close obstacle. The Home behavior utilizes the front optical photocells to provide robot self-guidance to a strong light highly directional source. It all should add up to some very distinct “intelligent” operation. Figure 3 depicts the basic sensor and electronic layout.

Figure 3: Basic sensor and electronic layout

TOMBOT Assembly

The TOMBOT uses the low-cost robot platform (ArBot Chassis) and wheel set (X-Wheel assembly) from Budget Robotics (see Figure 4).

Figure 4: The platform and wheel set

A picture is worth a thousand words. Photo 2 shows two views of the TOMBOT prototype.

Photo 2a: The TOMBOT’s Sharp IR sensors, photo assembly, and more. b: The battery pack, right servo, and more.

Photo 2a shows dual Sharp IR sensors. Just below them is the photocell assembly. It is a custom board with dual CdS GL5528 photoconductive cells and 2.2-kΩ current-limiting resistors. Below this is a bumper assembly consisting of two SPDT Snap-action switches with lever (All Electronics Corp. CAT# SMS-196, left and right) fixed to a custom pre-fab plastic front bumper. Also shown is the solderless breakout board and left servo. Photo 2b shows the rechargeable battery pack that resides on the lower base platform and associated power switch. The electronics stack is visible. Here the XBee/Buzzer and graphics card modules residing on the 32-bit Experimenter. The Experimenter is plugged into a custom carrier board that allows for an interconnection to the solderless breakout to the rest of the system. Finally, note that the right servo is highlighted. The total TOMBOT package is not ideal; but remember, I’m talking about a prototype, and this particular configuration has held up nicely in several field demos.

I used Parallax (Futaba) continuous-rotation servos. They use a three-wire connector (+5 V, GND, and Control).

Figure 5 depicts a second-generation bumper assembly.  The same snap-action switches with extended levers are bent and fashioned to interconnect a bumper assembly as shown.

Figure 5: Second-generation bumper assembly

TOMBOT Electronics

A 32-bit Micro Experimenter is used as the CPU. This board is based the high-end Microchip Technology PIC32MX695F512H 64-pin TQFP with 128-KB RAM, 512-KB flash memory, and an 80-MHz clock. I did not want to skimp on this component during the prototype phase. In addition the 32-bit Experimenter supports a 102 × 64 monographic card with green/red backlight controls and LEDs. Since a full graphics library was already bundled with this Experimenter graphics card, it also represented good risk reduction during prototyping phase. Details for both cards are available on the Kiba website.

The Experimenter supports six basic board-level connections to outside world using JP1, JP2, JP3, JP4, BOT, and TOP headers.  A custom carrier board interfaces to the Experimenter via these connections and provides power and signal connection to the sensors and servos. The custom carrier accepts battery voltage and regulates it to +5 VDC. This +5 V is then further regulated by the Experimenter to its native +3.3-VDC operation. The solderless breadboard supports a resistor network to sense a +9-V battery voltage for a +3.3-V PIC processor. The breadboard also contains an LM324 quad op-amp to provide a buffer between +3.3-V logic of the processor and the required +5-V operation of the servo. Figure 6 is a detailed schematic diagram of the electronics.

Figure 6: The design’s circuitry

A custom card for the XBee radio carrier and buzzer was built that plugs into the Experimenter’s TOP and BOT connections. Photo 3 shows the modules and the carrier board. The robot uses a rechargeable 1,600-mAH battery system (typical of mid-range wireless toys) that provides hours of uninterrupted operation.

Photo 3: The modules and the carrier board

PIC32 On-Chip Peripherals

The major PIC32 peripheral connection for the Experimenter to rest of the system is shown. The TOMBOT uses PWM for servo, UART for XBee, SPI and digital for LCD, analog input channels for all the sensors, and digital for the buzzer and bumper detect. The key peripheral connection for the Experimenter to rest of the system is shown in Figure 7.

Figure 7: Peripheral usage

The PIC32 pinouts and their associated Experimenter connections are detailed in Figure 8.

Figure 8: PIC32 peripheral pinouts and EXP32 connectors

The TOMBOT Motion Basics and the PIC32 Output Compare Peripheral

Let’s review the basics for TOMBOT motor control. The servos use the Parallax (Futaba) Continuous Rotation Servos. With two-wheel control, the robot motion is controlled as per Table 1.

Table 1: Robot motion

The servos are controlled by using a 20-ms (500-Hz) pulse PWM pattern where the PWM pulse can from 1.0 ms to 2.0 ms. The effects on the servos for the different PWM are shown in Figure 9.

Figure 9: Servo PWM control

The PIC32 microcontroller (used in the Experimenter) has five Output Compare modules (OCX, where X =1 , 2, 3, 4, 5). We use two of these peripherals, specifically OC3, OC4 to generate the PWM to control the servo speed and direction. The OCX module can use either 16 Timer2 (TMR2) or 16 Timer3 (TMR3) or combined as 32-bit Timer23 as a time base and for period (PR) setting for the output pulse waveform. In our case, we are using Timer23 as a PR set to 20 ms (500 Hz). The OCXRS and OCXR registers are loaded with a 16-bit value to control width of the pulse generated during the output period. This value is compared against the Timer during each period cycle. The OCX output starts high and then when a match occurs OCX logic will generate a low on output. This will be repeated on a cycle-by-cycle basis (see Figure 10).

Figure 10: PWM generation

Next Comes Software

We set the research goals and objectives for our autonomous robot. We covered the hardware associated with this robot and in the next installment we will describe the software and operation.

Tom Kibalo holds a BSEE from City College of New York and an MSEE from the University of Maryland. He as 39 years of engineering experience with a number of companies in the Washington, DC area. Tom is an adjunct EE facility member for local community college, and he is president of Kibacorp, a Microchip Design Partner.

DIY Internet-Enabled Home Control System

Why shell out hundreds or thousands of dollars on various home control systems (HCS) when you have the skills and resources to build your own? You can design and implement sophisticated Internet-enabled systems with free tools and some careful planning.

John Breitenbach did just that. He used a microcontroller, free software, and a cloud-based data platform to construct a remote monitoring system for his home’s water heater. The innovative design can email or text status messages and emergency alerts to a smartphone. You can build a similar system to monitor any number of appliances, rooms, or buildings.

An abridged version of Breitenbach’s article, “Internet-Enabled Home Control” (Circuit Cellar 264, July 2012), appears below. (A link to the entire article and an access password are noted at the end of this post.) Breitenbach writes:

Moving from the Northeast to North Carolina, my wife and I were surprised to find that most homes don’t have basements. In the north, the frost line is 36˝–48 ˝ below the surface. To prevent frost heave, foundations must be dug at least that deep. So, digging down an extra few feet to create a basement makes sense. Because the frost line is only 15 ˝ in the Raleigh area, builders rarely excavate the additional 8’ to create basements.

The lack of basements means builders must find unique locations for a home’s mechanical systems including the furnace, AC unit, and water heater. I was shocked to find that my home’s water heater is located in the attic, right above one of the bedrooms (see Photo 1).

Photo 1: My home’s water heater is located in our attic. (Photo courtesy of Michael Thomas)

During my high school summers I worked for my uncle’s plumbing business (“Breitenbach Plumbing—We’re the Best, Don’t Call the Rest”) and saw firsthand the damage water can do to a home. Water heaters can cause some dramatic end-of-life plumbing failures, dumping 40 or more gallons of water at once followed by the steady flow of the supply line.

Having cleaned up the mess of a failed water heater in my own basement up north, I haven’t had a good night’s sleep since I discovered the water heater in my North Carolina attic. For peace of mind, especially when traveling, I instrumented my attic so I could be notified immediately if water started to leak. My goal was to use a microcontroller so I could receive push notifications via e-mails or text messages. In addition to emergency messages, status messages sent on a regular basis reassure me the system is running. I also wanted to use a web browser to check the current status at any time.


The attic monitor is based on Renesas Electronics’s YRDKRX62N demonstration kit, which features the RX62N 32-bit microcontroller (see Photo 2). Renesas has given away thousands of these boards to promote the RX, and the boards are also widely available through distributors. The YRDK board has a rich feature set including a graphics display, push buttons, and an SD-card slot, plus Ethernet, USB, and serial ports. An Analog Devices ADT7420 digital I2C temperature sensor also enables you to keep an eye on the attic temperature. I plan to use this for a future addition to the project that compares this temperature to the outside air temperature to control an attic fan.

Photo 2: The completed board, which is based on a Renesas Electronics YRDKRX62N demonstration kit. (Photo courtesy of Michael Thomas)


Commercial water-detection sensors are typically made from two exposed conductive surfaces in close proximity to each other on a nonconductive surface. Think of a single-sided PCB with no solder mask and tinned traces (see Photo 3).

Photo 3: A leak sensor (Photo courtesy of Michael Thomas)

These sensors rely on the water conductivity to close the circuit between the two conductors. I chose a sensor based on this type of design for its low cost. But, once I received the sensors, I realized I could have saved myself a few bucks by making my own sensor from a couple of wires or a piece of proto-board.

When standing water on the sensor shorts the two contacts, the resistance across the sensor drops to between 400 kΩ and 600 kΩ. The sensor is used as the bottom resistor in a voltage divider with a 1-MΩ resistor up top. The output of the divider is routed to the 12-bit analog inputs on the RX62N microcontroller. Figure 1 shows the sensor interface circuit. When the voltage read by the analog-to-digital converter (ADC) drops below 2 V, it’s time to start bailing. Two sensors are connected: one in the catch pan under the water heater, and a second one just outside the catch pan to detect failures in the small expansion tank.

Figure 1: The sensor interface to the YRDK RX62N board


One of my project goals was to push notifications to my cell phone because Murphy’s Law says water heaters are likely to fail while you’re away for the weekend. Because I wanted to keep the project costs low, I used my home’s broadband connection as the gateway for the attic monitor. The Renesas RX62N microcontroller includes a 100-Mbps Ethernet controller, so I simply plugged in the cable to connect the board to my home network. The open-source µIP stack supplied by Renesas with the YRDK provides the protocol engine needed to talk to the Internet.

There were a couple of complications with using my home network as the attic monitor’s gateway to the world. It is behind a firewall built into my router and, for security reasons, I don’t want to open up ports to the outside world.

My Internet service provider (ISP) occasionally changes the Internet protocol (IP) address associated with my cable modem. So I would never know what address to point my web browser. I needed a solution that would address both of these problems. Enter Exosite, a company that provides solutions for cloud-based, machine-to-machine (M2M) communications.


Exosite provides a number of software components and services that enable M2M communications via the cloud. This is a different philosophy from supervisory control and data acquisition (SCADA) systems I’ve used in the past. The control systems I’ve worked on over the years typically involve a local host polling the hundreds or thousands of connected sensors and actuators that make up a commercial SCADA system. These systems are generally designed to be monitored locally at a single location. In the case of the attic monitor, my goal was to access a limited number of data points from anywhere, and have the system notify me rather than having to continuously poll. Ideally, I’d only hear from the device when there was a problem.

Exosite is the perfect solution: the company publishes a set of simple application programming interfaces (APIs) using standard web protocols that enable smart devices to push data to their servers in the cloud in real time. Once the data is in the cloud, events, alerts, and scripts can be created to do different things with the data—in my case, to send me an e-mail and SMS text alert if there is anything wrong with my water heater. Connected devices can share data with each other or pull data from public data sources, such as public weather stations. Exosite has an industrial-strength platform for large-scale commercial applications. It provides free access to it for the open-source community. I can create a free account that enables me to connect one or two devices to the Exosite platform.

Embedded devices using Exosite are responsible for pushing data to the server and pulling data from it. Devices use simple HTTP requests to accomplish this. This works great in my home setup because the attic monitor can work through my firewall, even when my Internet provider occasionally changes the IP address of my cable modem. Figure 2 shows the network diagram.

Figure 2: The cloud-based network


Web-based dashboards hosted on Exosite’s servers can be built and configured to show real-time and historical data from connected devices. Controls, such as switches, can be added to the dashboards to push data back down to the device, enabling remote control of embedded devices. Because the user interface is “in the cloud,” there is no need to store all the user interface (UI) widgets and data in the embedded device, which greatly reduces the storage requirements. Photo 4 shows the dashboard for the attic monitor.

Photo 4: Exosite dashboard for the attic monitor

Events and alerts can be added to the dashboard. These are logical evaluations Exosite’s server performs on the incoming data. Events can be triggered based on simple comparisons (e.g., a data value is too high or too low) or complex combinations of a comparison plus a duration (e.g., a data value remains too high for a period of time). Setting up a leak event for one of the sensors is shown in Photo 5.

Photo 5: Creating an event in Exosite

In this case, the event is triggered when the reported ADC voltage is less than 2 V. An event can also be triggered if Exosite doesn’t receive an update from the device for a set period of time. This last feature can be used as a watchdog to ensure the device is still working.

When an event is triggered, an alert can optionally be sent via e-mail. This is the final link that enables an embedded device in my attic to contact me anywhere, anytime, to alert me to a problem. Though I have a smartphone that enables me to access my e-mail account, I can also route the alarm message to my wife’s simpler phone through her cellular provider’s e-mail-to-text-message gateway. Most cellular providers offer this service, which works by sending an e-mail to a special address containing the cell phone number. On the Verizon network, the e-mail address is <yourcellularnumber>@vtext.com. Other providers have similar gateways.

The attic monitor periodically sends heartbeat messages to Exosite to let me know it’s still working. It also sends the status of the water sensors and the current temperature in the attic. I can log in to Exosite at any time to see my attic’s real-time status. I have also configured events and alarms that will notify me if a leak is detected or if the temperature gets too hot…

The complete article includes details such about the Internet engine, reading the cloud, tips for updating the design, and more.  You can read the entire article by typing netenabledcontrol to open the password-protected PDF.

DIY Solar-Powered, Gas-Detecting Mobile Robot

German engineer Jens Altenburg’s solar-powered hidden observing vehicle system (SOPHECLES) is an innovative gas-detecting mobile robot. When the Texas Instruments MSP430-based mobile robot detects noxious gas, it transmits a notification alert to a PC, Altenburg explains in his article, “SOPHOCLES: A Solar-Powered MSP430 Robot.”  The MCU controls an on-board CMOS camera and can wirelessly transmit images to the “Robot Control Center” user interface.

Take a look at the complete SOPHOCLES design. The CMOS camera is located on top of the robot. Radio modem is hidden behind the camera so only the antenna is visible. A flexible cable connects the camera with the MSP430 microcontroller.

Altenburg writes:

The MSP430 microcontroller controls SOPHOCLES. Why did I need an MSP430? There are lots of other micros, some of which have more power than the MSP430, but the word “power” shows you the right way. SOPHOCLES is the first robot (with the exception of space robots like Sojourner and Lunakhod) that I know of that’s powered by a single lithium battery and a solar cell for long missions.

The SOPHOCLES includes a transceiver, sensors, power supply, motor
drivers, and an MSP430. Some block functions (i.e., the motor driver or radio modems) are represented by software modules.

How is this possible? The magic mantra is, “Save power, save power, save power.” In this case, the most important feature of the MSP430 is its low power consumption. It needs less than 1 mA in Operating mode and even less in Sleep mode because the main function of the robot is sleeping (my main function, too). From time to time the robot wakes up, checks the sensor, takes pictures of its surroundings, and then falls back to sleep. Nice job, not only for robots, I think.

The power for the active time comes from the solar cell. High-efficiency cells provide electric energy for a minimum of approximately two minutes of active time per hour. Good lighting conditions (e.g., direct sunlight or a light beam from a lamp) activate the robot permanently. The robot needs only about 25 mA for actions such as driving its wheel, communicating via radio, or takes pictures with its built in camera. Isn’t that impossible? No! …

The robot has two power sources. One source is a 3-V lithium battery with a 600-mAh capacity. The battery supplies the CPU in Sleep mode, during which all other loads are turned off. The other source of power comes from a solar cell. The solar cell charges a special 2.2-F capacitor. A step-up converter changes the unregulated input voltage into 5-V main power. The LTC3401 changes the voltage with an efficiency of about 96% …

Because of the changing light conditions, a step-up voltage converter is needed for generating stabilized VCC voltage. The LTC3401 is a high-efficiency converter that starts up from an input voltage as low as 1 V.

If the input voltage increases to about 3.5 V (at the capacitor), the robot will wake up, changing into Standby mode. Now the robot can work.

The approximate lifetime with a full-charged capacitor depends on its tasks. With maximum activity, the charging is used after one or two minutes and then the robot goes into Sleep mode. Under poor conditions (e.g., low light for a long time), the robot has an Emergency mode, during which the robot charges the capacitor from its lithium cell. Therefore, the robot has a chance to leave the bad area or contact the PC…

The control software runs on a normal PC, and all you need is a small radio box to get the signals from the robot.

The Robot Control Center serves as an interface to control the robot. Its main feature is to display the transmitted pictures and measurement values of the sensors.

Various buttons and throttles give you full control of the robot when power is available or sunlight hits the solar cells. In addition, it’s easy to make short slide shows from the pictures captured by the robot. Each session can be saved on a disk and played in the Robot Control Center…

The entire article appears in Circuit Cellar 147 2002. Type “solarrobot”  to access the password-protected article.

The Basics of Thermocouples

Whether you’re looking to build a temperature-sensing device or you need to add sensing capabilities to a larger system, you should familiarize yourself with thermocouples and understand how to design thermocouple interfaces. Bob Perrin covered these topics and more in 1999 Circuit Cellar Online article , “The Basics of Thermocouples.” The article appears below in its entirety.

A mathematician, a physicist, and an engineer were at lunch. The bartender asked the three gentlemen, “what is this pi I hear so much about?”

The mathematician replied, “pi is the ratio of a circle’s circumference to its diameter.”

The physicist answered, “pi is 3.14159265359.”

The engineer looked up, flatly stated, “Oh, pi’s about three,” then promptly went back to doodling on the back of his napkin.

The point is not that engineers are sloppy, careless, or socially inept. The point is that we are eminently practical. We are solvers of problems in a non-ideal world. This means we must be able to apply concepts to real problems and know when certain effects are negligible in our application.

For example, when designing first- or second-order filters, 3 is often a close enough approximation for pi, given the tolerance and temperature dependence of affordable components.

But, before we can run off and make gross approximations, we must understand the physical principles involved in the system we’re designing. One topic that seems to suffer from gross approximations without a firm understanding of the issues involved is temperature measurement with thermocouples.

Thermocouples are simple temperature sensors consisting of two wires made from dissimilar alloys. These devices are simple in construction and easy to use. But, like any electronic component, they require a certain amount of explanation. The intent of this paper is to present and explain how to use thermocouples and how to design thermocouple interfaces.


Figure 1a shows a thermocouple. One junction is designated the hot junction. The other junction is designated as the cold or reference junction. The current developed in the loop is proportional to the difference in temperature between the hot and cold junctions. Thermocouples measure differences in temperature, not absolute temperature.

Figure 1a: Two wires are all that are required to form a thermocouple.

To understand why a current is formed, we must revert to physics. Unfortunately, I’m not a physicist, so this explanation may bend a concept or two, but I’ll proceed nonetheless.

Consider a homogenous metallic wire. If heat is applied at one end, the electrons at that end become more energetic. They absorb energy and move out of their normal energy states and into higher ones. Some will be liberated from their atoms entirely. These newly freed highly energetic electrons move toward the cool end of the wire. As these electrons speed down the wire, they transfer their energy to other atoms. This is how energy (heat) is transferred from the hot end to the cool end of the wire.

As these electrons build up at the cool end of the wire, they experience an electrostatic repulsion. The not-so-energetic electrons at the cool end move toward the hot end of the wire, which is how charge neutrality is maintained in the conductor.

The electrons moving from the cold end toward the hot end move slower than the energetic electrons moving from the hot end move toward the cool end. But, on a macroscopic level, a charge balance is maintained.

When two dissimilar metals are used to form a thermocouple loop, as in Figure 1a, the difference in the two metal’s affinity for electrons enables a current to develop when a temperature differential is set up between the two junctions.

As electrons move from the cold junction to the hot junction, these not-so-energetic electrons are able to move easier in one metal than the other. The electrons that are moving from the hot end to the cold end have already absorbed a lot of energy, and are free to move almost equally well in both wires. This is why an electric current is developed in the loop.

I may have missed some finer points of the physics, but I think I hit the highlights. If anyone can offer a more in-depth or detailed explanation, please e-mail me. One of the best things about writing for a technical audience is learning from my readers.


If you use thermocouples, you must insert a measurement device in the loop to acquire information about the temperature difference between the hot and cold junctions. Figure 1b shows a typical setup. The thermocouple wires are brought to a terminal block and an electric circuit measures the open circuit voltage.

Figure 1b: To use a thermocouple, you must have a measurement system.

When the thermocouple wires are connected to the terminal block, an additional pair of thermocouples is formed (one at each screw terminal). This is true if the screw-terminals are a different alloy from the thermocouple wires. Figure 1c shows an alternate representation of Figure 1b. Junction 2 and junction 3 are undesired artifacts of the connection to the measurement circuitry. These two junctions are commonly called parasitic thermocouples.

Figure 1c: The act of connecting a measurement system made of copper introduces two parasitic thermocouples.

In a physical circuit, parasitic thermocouples are formed at every solder joint, connector, and even every internal IC bond wire. If it weren’t for something called the Law of Intermediate Metals, these parasitic junctions would cause us endless trouble.

The Law of Intermediate Metals states that a third metal may be inserted into a thermocouple system without affecting the system if, and only if, the junctions with the third metal are kept isothermal (at the same temperature).

In Figure 1c, if junction 2 and junction 3 are at the same temperature, they will have no effect on the current in the loop. The voltage seen by the voltmeter in Figure 1b will be proportional to the difference in temperature between Junction 1 and Junctions 2 and 3.

Junction 1 is the hot junction. The isothermal terminal block is effectively removed electrically from the circuit, so the temperature of the cold junction is the temperature of the terminal block.


Thermocouples produce a voltage (or loop current) that is proportional to the difference in temperature between the hot junction and the reference junction. If you want to know the absolute temperature at the hot junction, you must know the absolute temperature of the reference junction.

There are three ways to find out the temperature of the reference junction. The simplest method is to measure the temperature at the reference junction with a thermistor or semiconductor temperature sensor such as Analog Devices’ TMP03/04. Then, in software, add the measured thermocouple temperature (the difference between the hot junction and the reference junction) to the measured temperature of the reference junction. This calculation will yield the absolute temperature of the hot junction.

The second method involves holding the reference junction at a fixed and known temperature. An ice bath, or an ice slushy, is one of the most common methods used in laboratory settings. Figure 2 shows how this is accomplished.

Figure 2: By inserting a short pigtail of Metal A onto the terminal block where Metal B would normally connect, we move the cold junction.

Alternately, we could have omitted the pigtail of Metal A and just immersed the terminal block in the ice. This would work fine, but it would be much messier than the method shown in Figure 2.

Sometimes, the temperature of the cold junction (terminal block) in Figure 1c is allowed to float to ambient. Then ambient is assumed to be “about 25°C,” or some other “close enough” temperature. This method is usually found in systems where knowing the temperature of the hot junction is not overly critical.

The third method used to nail down the cold junction temperature is to use a cold junction compensation IC such as the Analog Devices AD594 or Linear Technology LT1025. This method sort of combines the first two methods.

These ICs have a temperature sensor in them that detects the temperature of the cold junction. This is presumably the same temperature as the circuit board on which the IC is mounted. The IC then produces a voltage that is proportional to the voltage produced by a thermocouple with its hot junction at ambient and its cold junction at 0°C. This voltage is added to the EMF produced by the thermocouple. The net effect is the same as if the cold junction were physically held at 0°C.

The act of knowing (or approximating) the cold junction temperature and taking this information in to account in the overall measurement is referred to as cold junction compensation. The three techniques I discussed are each methods of cold junction compensation.

The ice bath is probably the most accurate method. An ice slushy can maintain a uniformity of about 0.1°C without much difficulty. I’ve read that an ice bath can maintain a uniformity of 0.01°C, but I’ve never been able to achieve that level of uniformity. Ice baths are physically awkward and therefore usually impractical for industrial measurements.

The off-the-shelf cold junction compensation ICs can be expensive and generally are only accurate to a few degrees Celsius, but many systems use these devices.

Using a thermistor, or even the PN junction on a diode or BJT, to measure the cold junction temperature can be fairly inexpensive and quite accurate. The most common difficulty encountered with this system is calibration. Prudent positioning of the sensor near, or on the terminal block is important.

If the terminal block is to be used as the cold junction (see Figure 1b), the terminal block must be kept isothermal. In practice, keeping the terminal block truly isothermal is almost impossible. So, compromises must be made. This is the stock and trade of engineers. Knowing what is isothermal “enough” for your application is the trick.

Lots of money can be wasted on precision electronics if the terminal block’s screw terminals are allowed to develop a significant thermal gradient. This condition generally happens when power components are placed near the terminal blocks. You must pay careful attention to keeping the temperature stable around the terminal blocks.

There are two broad classes of temperature-measurement applications. The first class involves measuring absolute temperature. For example, you may want to know the temperature of the inside of an oven relative to a standard temperature scale (like the Celsius scale). This type of application requires that you know precisely the absolute temperature of the reference junction.

The second type of measurement involves measuring differences in temperature. For example, in a microcalorimeter, you may want to measure the temperature of the system, then start some chemical reaction and measure the temperature as the reaction proceeds. The information of value is the difference between first measurement and the subsequent ones.

Systems that measure temperature differences are generally easier to construct because control or precise measurement of the reference junction isn’t required. What is required is that the reference junction remain at a constant temperature while the two measurements occur. Whether the reference junction is at 25.0°C or 30.0°C isn’t relevant because the subtraction of consecutive measurements will remove the reference junction temperature from the computed answer.

You can use thermocouples to make precise differential temperature measurements, but you must ensure the terminal block forming the cold junction is “close enough” to isothermal. You must also ensure that the cold junction has enough thermal mass so it will not change temperature over the time you have between measurements.


Thermocouples are given a letter designation that indicates the materials they are fabricated from. This letter designation is called the thermocouples “type.” Table 1 shows the common thermocouples available and their usable temperature ranges.

Table 1: There are a wide variety of industry-standard alloy combinations that form standard thermocouples. The most commonly used are J, K, T, and E.

Each thermocouple type will produce a different open-circuit voltage (Seebeck voltage) for a given set of temperature conditions. None of these devices are linear over a full range of temperatures. There are standard tables available that tabulate Seebeck voltages as a function of temperature.[1] There are also standard polynomial models available for thermocouples.

Thermocouples produce a small Seebeck voltage. For example, a type K thermocouple produces about 40 µV per degree Celsius when both junctions are near room temperature. The most sensitive of the thermocouples, type E, produces about 60 µV per degree Celsius when both junctions are near room temperature.

In many applications, the range of temperatures being measured is sufficiently small that the Seebeck voltage is assumed to be linear over the range of interest. This eliminates the need for lookup tables or polynomial computation in the system. Often the loss of absolute accuracy is negligible, but this tradeoff is one the design engineer must weigh carefully.


When designing a thermocouple interface, there are only a few pieces of information you need to know:

  • what type of thermocouple will be used
  • what is the full range of temperatures the hot junction will be exposed to
  • what is the full range of temperatures the cold junction will be exposed to
  • what is the temperature resolution required for your application
  • does your system require galvanic isolation
  • what type of cold junction compensation will be used

If the answer to the last question requires the analog addition of a voltage from a commercial cold junction compensation IC, then the manufacturer of the IC will probably supply you with an adequate reference design. If you plan to do the cold-junction compensation either physically (by an ice bath) or in software (by measuring the cold junction’s temperature with another device), then you must build or buy a data-acquisition system.

Galvanic isolation is an important feature in many industrial applications. Because thermocouples are really just long loops of wire, they will often pick up high levels of common-mode noise. In some applications, the thermocouples may be bonded to equipment that is at line voltage (or higher).

In this case, galvanic isolation is required to keep high-voltage AC out of your data acquisition system. This type of isolation is usually accomplished in one of two ways—using either an opto-isolator or a transformer. Both systems require the thermocouple signal conditioner to allow its ground to float with respect to earth ground. Figure 3a and 3b outlines these schemes.

Figure 3: Galvanic isolation to a few thousand volts is easy (but a little expensive) using opto-isolation (a) and inexpensive (but a bit more challenging) using a VFC and a transformer (b).

Because the focus of this article is on the interface to the thermocouple, I’ll have to leave the details of implementing galvanic isolation to another article.

Given the tiny voltage levels produced by a thermocouple, the designer of the signal-conditioning module should focus carefully on noise rejection. Using the common-mode rejection (CMR) characteristics of a differential amplifier is a good place to start. Figure 4 shows a simple yet effective thermocouple interface

Figure 4: The common-mode filter and common-mode rejection characteristics pay off in thermocouple amplifiers.

The monolithic instrumentation amplifier (in-amp) is a $2–$5 part (depending on grade and manufacturer). These are usually 8-pin DIP or SOIC devices. In-amps are simple differential amplifiers. The gain is set with a single external resistor. The input impedance of an in-amp is typically 10 gigaohms.

Certainly you can use op-amps, or even discrete parts to build a signal conditioner. However, all the active components on a monolithic in-amp are on the same dice and are kept more-or-less isothermal. This means in-amp characteristics behave nicely over temperature. Good CMR, controllable gain, small size, and high input impedance make in-amps perfect as the heart of a thermocouple conditioning circuit.

Temperature tends to change relatively slowly. So, if you find your system has noise, you can usually install supplementary low-pass filters. These can be implemented in hardware or software. In many systems, it’s not uncommon to take 128 measurements over 1 s and then average the results. Digital filters are big cost reducers in production systems.

Another problem often faced when designing thermocouple circuits is nulling amplifier offset. You can null the amplifier offset in a variety of ways [2], but my favorite is by chopping the input. Figure 5 shows how this process can be accomplished.

Figure 5: An input chopper like a CD4052 is all that is necessary to null signal conditioner offsets.

Thermocouples have such small signal levels, gains on the order of 1000 V/V are not uncommon, which means an op-amp or in-amp with a voltage offset of even 1 mV will have an offset at the output on the order of volts.

The chopper in Figure 5 allows the microcontroller to reverse the polarity of the thermocouple. To null the circuit, the microcontroller will take two measurements then subtract them.

First, set the chopper so the ADC measures GAIN (Vsensor + Voffset). Second, set the chopper so the ADC measures GAIN (–Vsensor + Voffset).

Subtract the second measurement from the first and divide by two. The result is GAIN*Vsensor. As you can see, this is exactly the quantity we are interested in. The in-amp’s offset has been removed from the measurement.


In 1821, Thomas J. Seebeck discovered that if a junction of two dissimilar metals is heated, a voltage is produced. This voltage has since been dubbed the Seebeck voltage.

Thermocouples are found in everything from industrial furnaces to medical devices. At first glance, thermocouples may seem fraught with mystery. They are not. After all, how can a device that’s built from two wires and has been around for 180 years be all that tough to figure out?

When designing with thermocouples, just keep these four concepts in mind and the project will go much smoother. First, thermocouples produce a voltage that is proportional to the difference in temperature between the hot junction and the reference junction.

Second, because thermocouples measure relative temperature differences, cold junction compensation is required if the system is to report absolute temperatures. Cold-junction compensation simply means knowing the absolute temperature of the cold junction and adjusting the reparted temperature value accordingly.

The third thing to remember is that thermocouples have a small Seebeck voltage coefficient, typically on the order of tens of microvolts per degree Celsius. And last, thermocouples are non-linear across their temperature range. Linearization, if needed, is best done in software.

Armed with these concepts, the circuits in this article, and a bit of time, you should have a good start on being able to design a thermocouple into your next project.

Bob Perrin has designed instrumentation for agronomy, soil physics, and water activity research. He has also designed embedded controllers for a variety of other applications.


[1] www.omega.com/pdf/temperature/z/zsection.asp

[2] B.Perrin, “Practical Analog Design,” Circuit Cellar, #94, May 1998.


AD594, TMP03/04
Analog Devices

Texas Instruments (Burr-Brown Corp.)

Linear Technology

This article was originally published in Circuit Cellar Online in 1999. Posted with permission. Circuit Cellar and CircuitCellar.com are Elektor International Media publications.


In Memoriam: Richard Alan Wotiz

Richard Alan Wotiz—a multitalented electronics engineer, inventor, and author—provided the international embedded design community with creative projects and useful electronics engineering lessons since the early 1980s when he graduated from Princeton University. Sadly, Richard passed away unexpectedly on May 30, 2012 while hiking with a group of friends (a group called “Take a Hike”) in Santa Cruz County, California.

Richard Alan Wotiz

Richard started writing his “Embedded Unveiled” column for Circuit Cellar magazine in 2011. You can read each of his columns by clicking the links below:

Prior to becoming a columnist, Richard placed highly in several international embedded design challenges. Amazingly, he won First Prize in both the Texas Instruments 2010 DesignStellaris Challenge and the 2010 WIZnet iMCU Challenge. That’s right—he won First Place in both of Circuit Cellar’s 2010 design challenges!

Richard published intriguing feature article about some of his prize-winning projects. Interestingly, he liked combining his passion for engineering with his love of the outdoors. When he did so, the results were memorable designs intended to be used outdoors: a backpack water level monitor, an earth field magnetometer, and an ABS brake system for a mountain bike.

Richard’s ABS system is built around a Texas Instruments EKK-LM3S9B96 evaluation board, which contains the Stellaris LM3S9B96 microcontroller and support circuitry. The mechanism mounts to the front fork in place of the reflector, and the control unit sits on a bracket that’s also attached to the handlebars. A veritable maze of wires runs to the various sensors on the brake levers and wheels.

His other projects were well-built systems—such as his single-phase, variable-speed drive for AC induction motors—intended to solve real-world problems or handy DIY designs—such as his “Net Butler” network control system—that he could use in his daily life.

Richard’s single-phase, variable-speed drive for AC induction motors is an excellent device for powerful, yet quiet, pump operation. Designed for use with a capacitor-start/capacitor-run motor, it includes active power factor correction (PFC) and inrush current limiting. This is the drive unit. A Microchip Technology dsPIC30F2020 and all of the control circuitry is at the upper right, with all of the power components below. The line filter and low-voltage supplies are in a separate box to the left. It’s designed to sit vertically with the three large filter capacitors at the bottom, so they stay as cool as possible.

Richard named his finished network control system the “Net Butler.” This innovative multifunctional design can control, monitor, and automatically maintain a home network. Built around a WIZnet iMCU7100EVB, the design has several functions, such as reporting on connected network devices and downloading Internet-based content.

I last saw Richard in March 2012 at the Design West Conference in San Jose, CA. As usual, he stopped by our booth to chat about his work and Circuit Cellar magazine in general. He had a great passion for both, and it showed whenever I spoke with him. He was a true believer of this magazine and its mission. During our chat, he asked if he could write about the seven-processor Intel Industrial Control Robotic Orchestra system on display at the conference. I agreed, of course! His enthusiasm for doing such an article was apparent. Soon thereafter he was at the Intel booth taking photos and notes for his column.

I’m happy to announce that the column—which he titled “EtherCAT Orchestra”—will appear in Circuit Cellar 264 (July 2012).

Richard’s work was a wonderful contribution to this magazine, and we’re grateful to have published his articles. We’re sure Richard’s inventive design ideas and technical insight will endure to help countless more professionals, academics, and students to excel at electronics engineering for years to come.

Wireless Data Control for Remote Sensor Monitoring

Circuit Cellar has published dozens of interesting articles about handy wireless applications over the years. And now we have another innovative project to report about. Circuit Cellar author Robert Bowen contacted us recently with a link to information about his iFarm-II controller data acquisition system.

The iFarm-II controller data acquisition system (Source: R. Bowen)

The design features two main components. Bowen’s “iFarm-Remote” and the “iFarm-Base controller” work together to as an accurate remote wireless data acquisition system. The former has six digital inputs (for monitoring relay or switch contacts) and six digital outputs (for energizing a relay’s coil). The latter is a stand-alone wireless and internet ready controller. Its LCD screen displays sensor readings from the iFarm-Remote controller. When you connect the base to the Internet, you can monitor data reading via a browser. In addition, you can have the base email you notifications pertaining to the sensor input channels.

You can connect the system to the Internet for remote monitoring. The Network Settings Page enables you to configure the iFarm-Base controller for your network. (Source: R. Bowen)

Bowen writes:

The iFarm-II Controller is a wireless data acquisition system used to remotely monitor temperature and humidity conditions in a remote location. The iFarm consists of two controllers, the iFarm-Remote and iFarm-Base controller. The iFarm-Remote is located in remote location with various sensors (supports sensors that output +/-10VDC ) connected. The iFarm-Remote also provides the user with 6-digital inputs and 6-digital outputs. The digital inputs may be used to detect switch closures while the digital outputs may be used to energize a relay coil. The iFarm-Base supports either a 2.4GHz or 900Mhz RF Module.

The iFarm-Base controller is responsible for sending commands to the iFarm-Remote controller to acquire the sensor and digital input status readings. These readings may be viewed locally on the iFarm-Base controllers LCD display or remotely via an Internet connection using your favorite web-browser. Alarm conditions can be set on the iFarm-Base controller. An active upper or lower limit condition will notify the user either through an e-mail or a text message sent directly to the user. Alternatively, the user may view and control the iFarm-Remote controller via web-browser. The iFarm-Base controllers web-server is designed to support viewing pages from a PC, Laptop, iPhone, iTouch, Blackberry or any mobile device/telephone which has a WiFi Internet connection.—Robert Bowen, http://wireless.xtreemhost.com/

iFarm-Host/Remote PCB Prototype (Source: R. Bowen)

Robert Bowen is a senior field service engineer for MTS Systems Corp., where he designs automated calibration equipment and develops testing methods for customers involved in the material and simulation testing fields. Circuit Cellar has published three of his articles since 2001:

Design West Update: Intel’s Computer-Controlled Orchestra

It wasn’t the Blue Man Group making music by shooting small rubber balls at pipes, xylophones, vibraphones, cymbals, and various other sound-making instruments at Design West in San Jose, CA, this week. It was Intel and its collaborator Sisu Devices.

Intel's "Industrial Controller in Concert" at Design West, San Jose

The innovative Industrial Controller in Concert system on display featured seven Atom processors, four operating systems, 36 paint ball hoppers, and 2300 rubber balls, a video camera for motion sensing, a digital synthesizer, a multi-touch display, and more. PVC tubes connect the various instruments.

Intel's "Industrial Controller in Concert" features seven Atom processors 2300

Once running, the $160,000 system played a 2,372-note song and captivated the Design West audience. The nearby photo shows the system on the conference floor.

Click here learn more and watch a video of the computer-controlled orchestra in action.

Robot Design with Microsoft Kinect, RDS 4, & Parallax’s Eddie

Microsoft announced on March 8 the availability of Robotics Developer Studio 4 (RDS 4) software for robotics applications. RDS 4 was designed to work with the Kinect for Windows SDK. To demonstrate the capabilities of RDS 4, the Microsoft robotics team built the Follow Me Robot with a Parallax Eddie robot, laptop running Windows 7, and the Kinect.

In the following short video, Microsoft software developer Harsha Kikkeri demonstrates Follow Me Robot.

Circuit Cellar readers are already experimenting Kinect and developing embedded system to work with it n interesting ways. In an upcoming article about a Kinect-based project, designer Miguel Sanchez describes a interesting Kinect-based 3-D imaging system.

Sanchez writes:

My project started as a simple enterprise that later became a bit more challenging. The idea of capturing the silhouette of an individual standing in front of the Kinect was based on isolating those points that are between two distance thresholds from the camera. As depth image already provides the distance measurement, all the pixels of the subject will be between a range of distances, while other objects in the scene will be outside of this small range. But I wanted to have just the contour line of a person and not all the pixels that belong to that person’s body. OpenCV is a powerful computer vision library. I used it for my project because of function blobs. This function extracts the contour of the different isolated objects of a scene. As my image would only contain one object—the person standing in front of the camera—function blobs would return the exact list of coordinates of the contour of the person, which was what I needed. Please note that this function is a heavy image processing made easy for the user. It provides not just one, but a list of all the different objects that have been detected in the image. It can also specify is holes inside a blob are permitted. It can also specify the minimum and maximum areas of detected blobs. But for my project, I am only interested in detecting the biggest blob returned, which will be the one with index zero, as they are stored in decreasing order of blob area in the array returned by the blobs function.

Though it is not a fault of blobs function, I quickly realized that I was getting more detail than I needed and that there was a bit of noise in the edges of the contour. Filtering out on a bit map can be easily accomplished with a blur function, but smoothing out a contour did not sound so obvious to me.

A contour line can be simplified by removing certain points. A clever algorithm can do this by removing those points that are close enough to the overall contour line. One of these algorithms is the Douglas-Peucker recursive contour simplification algorithm. The algorithm starts with the two endpoints and it accepts one point in between whose orthogonal distance from the line connecting the two first points is larger than a given threshold. Only the point with the largest distance is selected (or none if the threshold is not met). The process is repeated recursively, as new points are added, to create the list of accepted points (those that are contributing the most to the general contour given a user-provided threshold). The larger the threshold, the rougher the resulting contour will be.

By simplifying a contour, now human silhouettes look better and noise is gone, but they look a bit synthetic. The last step I did was to perform a cubic-spline interpolation so contour becomes a set of curves between the different original points of the simplified contour. It seems a bit twisted to simplify first to later add back more points because of the spline interpolation, but this way it creates a more visually pleasant and curvy result, which was my goal.


(Source: Miguel Sanchez)
(Source: Miguel Sanchez)

The nearby images show aspects of the process Sanchez describes in his article, where an offset between the human figure and the drawn silhouette is apparent.

The entire article is slated to appear in the June or July edition of Circuit Cellar.

Aerial Robot Demonstration Wows at TEDTalk

In a TEDTalk Thursday, engineer Vijay Kumar presented an exciting innovation in the field of unmanned aerial vehicle (UAV) technology. He detailed how a team of UPenn engineers retrofitted compact aerial robots with embedded technologies that enable them to swarm and operate as a team to take on a variety of remarkable tasks. A swarm can complete construction projects, orchestrate a nine-instrument piece of music, and much more.

The 0.1-lb aerial robot Kumar presented on stage—built by UPenn students Alex Kushleyev and Daniel Mellinger—consumed approximately 15 W, he said. The 8-inch design—which can operate outdoors or indoors without GPS—featured onboard accelerometers, gyros, and processors.

“An on-board processor essentially looks at what motions need to be executed, and combines these motions, and figures out what commands to send to the motors 600 times a second,” Kumar said.

Watch the video for the entire talk and demonstration. Nine aerial robots play six instruments at the 14:49 minute mark.

Zero-Power Sensor (ZPS) Network

Recently, we featured two notable projects featuring Echelon’s Pyxos Pyxos technology: one about solid-state lighting solutions and one about a radiant floor heating zone controller. Here we present another innovative project: a zero-power sensor (ZPS) network on polymer.

The Zero Power Switch (Source: Wolfgang Richter, Faranak M.Zadeh)

The ZPS system—which was developed by Wolfgang Richter and Faranak M. Zadeh of Ident Technology AG— doesn’t require battery or RF energy for operation. The sensors, developed on polymer foils, are fed by an electrical alternating field with a 200-kHz frequency. A Pyxos network enables you to transmit of wireless sensor data to various devices.

In their documentation, Wolfgang Richter and Faranak M. Zadeh write:

“The developed wireless Zero power sensors (ZPS) do not need power, battery or radio frequency energy (RF) in order to operate. The system is realized on polymer foils in a printing process and/or additional silicon and is very eco-friendly in production and use. The sensors are fed by an electrical alternating field with the frequency of 200 KHz and up to 5m distance. The ZPS sensors can be mounted anywhere that they are needed, e.g. on the body, in a room, a machine or a car. One ZPS server can work for a number of ZPS-sensor clients and can be connected to any net to communicate with network intelligence and other servers. By modulating the electric field the ZPS-sensors can transmit a type of “sensor=o.k. signal” command. Also ZPS sensors can be carried by humans (or animals) for the vital signs monitoring. So they are ideal for wireless monitoring systems (e.g. “aging at home”). The ZPS system is wireless, powerless and cordless system and works simultaneously, so it is a self organized system …

The wireless Skinplex zero power sensor network is a very simply structured but surely functioning multiple sensor system that combines classical physics as taught by Kirchhoff with the latest advances in (smart) sensor technology. It works with a virtually unlimited number of sensor nodes in inertial space, without a protocol, and without batteries, cables and connectors. A chip not bigger than a particle of dust will be fabricated this year with the assistance of Cottbus University and Prof. Wegner. The system is ideal to communicate via PYXOS/Echelon to other instances and servers.

Pyxos networks helps to bring wireless ZPS sensor data over distances to external instances, nets and servers. With the advanced ECHELON technology even AC Power Line (PL) can be used.

As most of a ZPS server is realized in software it can be easily programmed into a Pyxos networks device, a very cost saving effect! Applications start from machine controls, smart office solutions, smart home up to Homes of elderly and medical facilities as everywhere else where Power line (PL) exists.”

Inside the ZPS project (Source: Wolfgang Richter, Faranak M.Zadeh)

For more information about Pyxos technology, visit www.echelon.com.

This project, as well as others, was promoted by Circuit Cellar based on a 2007 agreement with Echelon.

Robot Nav with Acoustic Delay Triangulation

Building a robot is a rite of passage for electronics engineers. And thus this magazine has published dozens of robotics-related articles over the years.

In the March issue, we present a particularly informative article on the topic of robot navigation in particular. Larry Foltzer tackles the topic of robot positioning with acoustic delay triangulation. It’s more of a theoretical piece than a project article. But we’re confident you’ll find it intriguing and useful.

Here’s an excerpt from Foltzer’s article:

“I decided to explore what it takes, algorithmically speaking, to make a robot that is capable of discovering its position on a playing field and figuring out how to maneuver to another position within the defined field of play. Later on I will build a minimalist-like platform to test algorithms performance.

In the interest of hardware simplicity, my goal is to use as few sensors as possible. I will use ultrasonic sensors to determine range to ultrasonic beacons located at the corners of the playing field and wheel-rotation sensors to measure distance traversed, if wheel-rotation rate times time proves to be unreliable.

From a software point of view, the machine must be able to determine robot position on a defined playing field, determine robot position relative to the target’s position, determine robot orientation or heading, calculate robot course change to approach target position, and periodically update current position and distance to the target. Because of my familiarity with Microchip Technology’s 8-bit microcontrollers and instruction sets, the PIC16F627A is my choice for the microcontrollers (mostly because I have them in my inventory).

To this date, the four goals listed—in terms of algorithm development and code—are complete and are the main subjects of this article. Going forward, focus must now shift to the hardware side, including software integration to test beyond pure simulation.

A brief survey of ultrasonic ranging sensors indicates that most commercially available units have a range capability of 20’ or less. This is for a sensor type that detects the echo of its own emission. However, in this case, the robot’s sensor will not have to detect its own echoes, but will instead receive the response to its query from an addressable beacon that acts like an active mirror. For navigation purposes, these mirrors are located at three of the four corners of the playing field. By using active mirrors or beacons, received signal strength will be significantly greater than in the usual echo ranging situation. Further, the use of the active mirror approach to ranging should enable expansion of the effective width of the sensor’s beam to increase the sensor’s effective field of view, reducing cost and complexity.

Taking the former into account, I decided the size of the playing field will be 16’ on a side and subdivided into 3” squares forming an (S × S) = (64 × 64) = (26, 26) unit grid. I selected this size to simplify the binary arithmetic used in the calculations. For the purpose of illustration here, the target is considered to be at the center of the playing field, but it could very well be anywhere within the defined boundaries of the playing field.

Figure 1: Squarae playing field (Source: Larry Foltzer CC260)

Referring to Figure 1, the corners of the square playing field are labeled in clockwise order from A to D. Ultrasonic sonar transceiver beacons/active mirrors are placed at three of the corners of the playing field, at the corners marked A, B, and D.”

The issue in which this article appears will available here in the coming days.