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

Microcontroller-Based Digital Thermometer Display

With the proper microcontroller, a digital temperature sensor, an SD memory card, and a little know-how, you can build a custom outdoor digital thermometer display. Tommy Tyler’s article in the July issue of Circuit Cellar explains how he built such a system. He carefully details the hardware, firmware, and construction process.

The following is an abridged version of Tyler’s project article. (The complete article appears in Circuit Cellar 264.)

Build an MCU-Based Digital Thermometer

by Tommy Tyler

Wondering what to do with your unused digital photo frame? With a little effort, a tiny circuit board assembly can be installed in the frame to transform the colorful thin film transistor (TFT) screen into the “ultimate” outdoor thermometer display (see Photo 1). Imagine a thermometer with real numeric digits (not seven-segment stick figures) large enough to be read from 40¢ to 50¢ away under any lighting conditions. Combine that with a glare-free, high-contrast screen, wide viewing angles, and an accuracy of ±0.5°F without calibration, and you have a wonderful thermometer that is more a work of art than an instrument, and can be customized and proudly displayed.

Almost any size and brand digital photo frame can be used, although one with 4.5″ or 7″ (diagonal) screen size is ideal for 2″-high digits. If you don’t have a discarded frame to use, some bargains are available for less than $30, if you look for them. Search online for overstocked, refurbished, or open-box units. The modifications are easy. Just drill a few holes and solder a few wires. The postage-stamp size PCB is designed with surface-mount components, so it’s small enough to tuck inside the frame. None of the modifications prevent you from using the frame as it was originally intended, to display photographs.

Photo 1: A TFT screen is easily transformed into an outdoor thermometer with the addition of a small circuit board.


Although digital photo frames vary in details and features, their basic functions are similar. Nearly all of them can store pictures in external memory, usually a small SD card like those used in digital cameras. Most have a half dozen or so push-button switches that control how the frame operates and select what is being displayed. There’s usually a Menu button, an Enter or Select button, and several cursor buttons for navigating through on-screen menus.

Photo frames feature a slideshow viewing mode that automatically steps through pictures in sequence. You can set the time each picture is displayed to your preference. You can also turn off the timer and have a manual, single-step slideshow mode where a selected picture is continuously displayed until another is selected with a button press. That’s the mode of operation used for the thermometer, and it is key to its accuracy.

The photo frame is loaded with images showing every possible temperature, in precise ascending order. Following power-up, the frame enters Slideshow mode displaying the first image in memory, which provides a known starting point. Based on repeated temperature measurements, the frame keeps incrementing or decrementing the image, 1° at a time, until the display matches the true temperature. After this initial synchronization, the display is simply incremented or decremented whenever the temperature rises or falls by 1° or more.

The frame responds so reliably, the display never gets out of sync with the true temperature. Following a power interruption, the thermometer automatically resynchronizes itself. In fact, for an interesting and reassuring demonstration at any time, just momentarily turn off power. Synchronization might take a minute or so due to the system’s response time, but that’s not considered a problem because presumably power interruptions will be infrequent.


Figure1 shows a schematic of the thermometer. A Microchip Technology PIC18F14K22 microprocessor U1 periodically polls U3, a factory-calibrated “smart” temperature sensor that transmits the digital value of the current temperature via I/O pin RC5. PIC output pins RC4 and RC3 drive sections of U2, a Texas Instruments TS3A4751 quad SPST analog switch with extremely low on-state resistance. Two of these solid-state switches are wired in parallel with the mechanical switches in the frame that increment and decrement the displayed temperature. RC6 provides an auxiliary output in case you are working with a rare photo frame that requires a third switch be actuated to enter Slideshow mode…

Figure 1: This schematic of the thermometer shows a portion of the Coby DP700 photo frame with a voltage comparator input that responds to different voltage levels from its >and< switches.

Figure 1 includes a portion of the Coby DP700 schematic showing such an arrangement. Switches SW3 (>) and SW4 (<) share input Pin 110 of the frame processor chip (U100). SW3 pulls the voltage down to about 1.5 V to increment the display, and SW4 pulls it all the way down to 0 V to decrement it. If you can gain access to the solder terminals of these switches, you can build this project. Using a solid-state analog switch for U2 enables the PIC control board to work with virtually any model photo frame, without having to worry about voltage, polarity, or switch circuit configuration.

PIC output RB7 continually transmits a running narrative of everything the thermometer is doing. Transistor Q1 provides a standard RS-232 serial output at 38400 bps, no parity, and two Stop bits using the DTR pin for pull-up voltage. This is mainly for testing, troubleshooting, or possibly experimenting with firmware changes. The board also includes a standard in-circuit serial programming (ICSP) interface for programming the PIC with a Microchip PICkit2 development programmer/debugger or similar programming tool.

Photo2 shows the thermometer circuit board assembly…

Photo 2: The thermometer circuit board assembly. The five-pin header is a direct plug-in for a Microchip PICkit2 programmer. The three-pin header is the diagnostic serial output.


I used a Coby DP700 photo frame as an example for the project because it is widely available, easy to modify, and has excellent quality for a low price. Figure 2 shows the basic components of this frame…

Figure 2: The Colby DP700 photo frame’s basic components

The ribbon cable is long enough to enable the display to swing open about 90°, but not much more. That makes it awkward to hold it open while making wiring connections, unless you have more hands than I do. One solution is to use a holding fixture made from a scrap of lumber to protect the ribbon cable from stress or damage during modification and testing.

Cut a piece of ordinary 1″ × 4″ pine board exactly 7.5″ long. Chamfer opposite ends of the board at the bottom on one side, and cut a notch in the center of that edge (see Photo 3a). Loosen the bezel and slide it up just far enough so that you can insert the board into the rear enclosure near the bottom, below the lower edge of the bezel (see Photo 3b).

Photo 3a: The lower edge of a pine board is notched and chamfered. b: The board is attached to the rear enclosure near the bottom, below the lower edge of the bezel.

The board’s chamfered corners should clear the inside radius of the rear enclosure. Temporarily tape the bezel and rear enclosure together while you fasten the board in place with two of the four bezel screws. Leave the board installed until you have completed the entire project, including all testing.

When you need to access the main circuit board to solder wires and install the PIC board, swing the bezel and display perpendicular to the rear enclosure like an open book and secure it firmly to the fixture board with masking tape (see Photo 4a). Later, during set up and testing when you need to see the screen, swing the bezel and display back down and secure them to the rear enclosure with masking tape (see Photo 4b).

Photo 4a: The bezel and display are firmly secured to the fixture board with masking tape. b: During setup and testing the bezel and display can be swung down and secured to the rear enclosure with masking tape.


The only mechanical modification is adding a 3.5-mm stereo jack to connect the remote temperature sensor. You may be able to drill a 0.25″ hole in the frame and attach the jack with its knurled ring nut. But sometimes the stereo plug sticks out in a way that spoils the appearance of the frame or interferes with mounting it on a wall. Here’s a way to install the jack that keeps it and the sensor cable flat against the rear of the frame and out of sight.

Cut a piece of perforated project board 0.6″ × 0.7″ and enlarge the three to five holes that line up with the terminals on the side of the jack with a 3/32″ drill (see Figure3). The perforated board acts as a spacer for the stereo plug when cemented to the enclosure.

Figure 3: The perforated board spaces the jack away from the rear enclosure to clear the stereo plug.

Before attaching anything to the perforated board, use it as a guide to drill matching terminal holes through the rear enclosure. Select a position low and to the right in the recessed area so it clears the power connector but does not extend below the lower edge of the rear enclosure (see Photo 5)…

Photo 5: Use the perforated board as a drilling guide


Referring to the wiring diagram in Photo 6, first prep the main PCB by attaching six insulated wires about 8″ to 10″ long, one wire to 3.3 V, one wire to ground, two wires to SW4, and two wires to SW3.

Photo 6: Wiring diagram

Solder all nine wires to the PIC board—six from the main PCB and three from the stereo jack. Trim the excess wire length so the PIC board will lie easily in the empty space beside the main PCB. Route the wires so they won’t get pinched when the bezel and display are replaced. Use masking tape to hold everything in place and keep the PIC board from shorting out.


The Microchip DS18S20 digital temperature sensor is a three-lead package the same size as a TO-92 transistor (see Figure 4)…

Insulating short spliced leads with sleeving is always a problem because the sleeving gets in the way of soldering. One way to keep the probe small and strong is to drip a little fast-set epoxy on the soldered leads, after ensuring they aren’t touching, and rotate the unit slowly for a couple of minutes until the epoxy stops running and begins to harden. Weatherproof the entire assembly with an inch or so of 0.25″ heat-shrink tubing.


Some photo frames don’t have internal memory, so I used a plug-in SD memory card for the temperature images. That also makes it easy to change the appearance of the display whenever you want. Any capacity card you can find is more than adequate, since the images average only about 25 KB each and 141 of them is less than 5 MB. A good source for generic 32-MB SD cards is OEMPCWorld. Their SD cards cost less than $4 each, including free shipping via U.S. Postal Service first-class mail. Just search their site for “32-MB SD card.”

A download package is available with images in 16 × 9 format showing temperature over the range from –20 to 120°F in numerals about 2″ high. The 16 × 9 images will naturally fit the Coby screen and most other brands. There’s also a set of 4 × 3 images for frames with that format. Actually, either size will work in any frame. If you use 4 × 3 images in the 16 × 9 Coby with Show Type set up as Fit Screen, there will be bars on the sides. But if it is set up as Full Screen, the images will expand to eliminate the bars, and the numerals will be about 2-5/8” high.

The download filenames have a sequential numeric prefix from 100 to 240, so Windows will list them in order before you copy them to the SD card. Notice that the sequence of images is as follows: 70°, 71°, 72°…119°, 120°, –20°, –19°, –18°…–2°, –1°, 0°, 1°, 2°…67°, 68°, 69°. The first image is not the lowest temperature. That’s so synchronization can start from 70° instead of all the way from –20°. You can split the temperature range like this as long as there are no extraneous pictures on the SD card, because the frame treats the SD card, in effect, as an endless circular memory, wrapping around from the highest to lowest image when incrementing, and from lowest to highest when decrementing…


It’s always best to make sure frame power is disconnected before plugging or unplugging the temperature sensor. Position the frame so that the screen is visible. Plug in the sensor and SD card, then connect power to the frame. After a few seconds, what you see on the screen will depend on how the frame was last used and set up. It may start showing pictures from internal memory, or it may start showing temperature images from the SD card. In either case, the pictures will probably start changing rapidly for a while because the frame thinks it is synchronizing its initial display to the temperature of the sensor. You can’t use on-screen menus to check the setup of the frame while it is flipping through all those pictures, so you must wait. After a couple minutes, when things settle down and the display stops rapidly changing, press Menu to bring up the main menu. Use the left or right arrow buttons to select the Set Up sub menu, then use the Enter, Left, Right, Up, and Down buttons to set up the following parameters: Interval Time = Off, Transition Effect = No Effect, Show Type = Fit Screen, Magic Slideshow = Off…

After completing all the setup adjustments, momentarily disconnect power from the frame and confirm that it properly powers up. The Coby logo should appear for a few seconds, followed by the first image in memory, the starting temperature of 70°F. About 12 s later, the display should start changing in 1° steps until it gets to the current temperature of the sensor. Warm the sensor with your hand to ensure the sensor is responding.

This is a good time to demonstrate an error indicator designed into the thermometer to alert you if the PIC can’t communicate with the temperature sensor. Disconnect power and unplug the sensor, then restore power with the sensor disconnected. The display will start at 70°F as before, but this time it will keep incrementing until it reaches 99°F, where it will stop. So if you ever notice the display stuck on 99° when you know it’s not that hot outside, check to see if the sensor is unplugged or damaged.

If everything seems to be working properly, you can skip the following section on troubleshooting. Close the frame and start thinking about how and where you will install it…


Credit for design of the PIC firmware goes to Kevin R. Timmerman—a talented freelance software design engineer, and owner of the Compendium Arcana website—who collaborated with me on this project. Kevin’s backyard in Michigan, as well as mine in Colorado, were the beta-test sites for the design.

A firmware download includes the temperature.hex file needed for programming the PIC, as well as the following source files in case you want to make changes:






The file named one_wire.c deals exclusively with sending and receiving messages to/from the temperature sensor. If you use a photo frame other than the Coby DP700 that has some special requirements, the only file you might need to modify is inverted_main.c. The firmware is available on the Circuit Cellar FTP site.


When you finish the project, you will have the satisfaction of knowing you probably have the most accurate thermometer in the neighborhood—providing you take reasonable precautions in locating the sensor. Don’t place it in sunlight or near heat sources (i.e., vents or ducts). Even placing it too close to a poorly insulated wall, roof, or window can affect its accuracy. There are articles online about the best places to install outdoor thermometers.

Even after you have completed your modifications to the frame and closed it back up, there are endless ways to customize the project to your taste…

For those living overseas or accustomed to expressing temperature in Centigrade, the download includes an alternate set of images covering the range from –28.9°C to 48.9°C. Images such as 70°F, 71°F, 72°F, and so forth are replaced with their Centigrade equivalents 21.1°C, 21.7°C, 22.2°C, and so forth. The thermometer control can’t tell the difference. It goes on incrementing and decrementing images as if it were displaying the temperature in Fahrenheit. By showing temperature in tenths of Centigrade degrees, the thermometer accuracy is unchanged. The temperature sensor is inherently a Centigrade device, and one could modify the PIC firmware to use the reported temperature in degrees C without ever converting it to degrees Fahrenheit. But this method is a lot easier, and enables you to change between Centigrade and Fahrenheit by just swapping the SD card…

Tommy Tyler graduated with honors from Vanderbilt University with a degree in Mechanical Engineering. He retired after a career spanning more than 40 years managing the product design of industrial instrumentation, medical electronics, consumer electronics, and embedded robotic material transport systems. Tommy earned 17 patents from 1960 to 1995. His current hobbies are electronics, technical writing and illustration, and music. Tommy is a contributing expert to the JP1 Forum on infrared remote control technology.


DP700 Digital photo frame

Coby Electronics Corp. |

PIC18F14K22 Microprocessor, DS18S20 digital temperature sensor, and PICkit2 development programmer/debugger

Microchip Technology, Inc. |

TS3A4751 quad SPST Analog switch

Texas Instruments, Inc. |

The project files (firmware and images) are available on Circuit Cellar’s FTP site. The complete article appears in Circuit Cellar 264.

Seven-Controller EtherCAT Orchestra

When I first saw the Intel Industrial Control in Concert demonstration at Design West 2012 in San Jose, CA, I immediately thought of Kurt Vonnegut ‘s 1952 novel Player Piano. The connection, of course, is that the player piano in the novel and Intel’s Atom-based robotic orchestra both play preprogrammed music without human involvement. But the similarities end there. Vonnegut used the self-playing autopiano as a metaphor for a mechanized society in which wealthy industrialists replaced human workers with automated machines. In contrast, Intel’s innovative system demonstrated engineering excellence and created a buzz in the in the already positive atmosphere at the conference.

In “EtherCAT Orchestra” (Circuit Cellar 264, July 2012), Richard Wotiz carefully details the awe-inspiring music machine that’s built around seven embedded systems, each of which is based on Intel’s Atom D525 dual-core microprocessor. He provides information about the system you can’t find on YouTube or hobby tech blogs. Here is the article in its entirety.

EtherCAT Orchestra

I have long been interested in automatically controlled musical instruments. When I was little, I remember being fascinated whenever I ran across a coin-operated electromechanical calliope or a carnival hurdy-gurdy. I could spend all day watching the many levers, wheels, shafts, and other moving parts as it played its tunes over and over. Unfortunately, the mechanical complexity and expertise needed to maintain these machines makes them increasingly rare. But, in our modern world of pocket-sized MP3 players, there’s still nothing like seeing music created in front of you.

I recently attended the Design West conference (formerly the Embedded Systems Conference) in San Jose, CA, and ran across an amazing contraption that reminded me of old carnival music machines. The system was created for Intel as a demonstration of its Atom processor family, and was quite successful at capturing the attention of anyone walking by Intel’s booth (see Photo 1).

Photo 1—This is Intel’s computer-controlled orchestra. It may not look like any musical instrument you’ve ever seen, but it’s quite a thing to watch. The inspiration came from Animusic’s “Pipe Dream,” which appears on the video screen at the top. (Source: R. Wotiz)

The concept is based on Animusic’s music video “Pipe Dream,” which is a captivating computer graphics representation of a futuristic orchestra. The instruments in the video play when virtual balls strike against them. Each ball is launched at a precise time so it will land on an instrument the moment each note is played.

The demonstration, officially known as Intel’s Industrial Control in Concert, uses high-speed pneumatic valves to fire practice paintballs at plastic targets of various shapes and sizes. The balls are made of 0.68”-diameter soft rubber. They put on quite a show bouncing around while a song played. Photo 2 shows one of the pneumatic firing arrays.

Photo 2—This is one of several sets of pneumatic valves. Air is supplied by the many tees below the valves and is sent to the ball-firing nozzles near the top of the photo. The corrugated hoses at the top supply balls to the nozzles. (Source: R. Wotiz)

The valves are the gray boxes lined up along the center. When each one opens, a burst of air is sent up one of the clear hoses to a nozzle to fire a ball. The corrugated black hoses at the top supply the balls to the nozzles. They’re fed by paintball hoppers that are refilled after each performance. Each nozzle fires at a particular target (see Photo 3).

Photo 3—These are the targets at which the nozzles from Photo 2 are aimed. If you look closely, you can see a ball just after it bounced off the illuminated target at the top right. (Source: R. Wotiz)

Each target has an array of LEDs that shows when it’s activated and a piezoelectric sensor that detects a ball’s impact. Unfortunately, slight variations in the pneumatics and the balls themselves mean that not every ball makes it to its intended target. To avoid sounding choppy and incomplete, the musical notes are triggered by a fixed timing sequence rather than the ball impact sensors. Think of it as a form of mechanical lip syncing. There’s a noticeable pop when a ball is fired, so the system sounds something like a cross between a pinball machine and a popcorn popper. You may expect that to detract from the music, but I felt it added to the novelty of the experience.

The control system consists of seven separate embedded systems, all based on Intel’s Atom D525 dual-core microprocessor, on an Ethernet network (see Figure 1).

Figure 1—Each block across the top is an embedded system providing some aspect of the user interface. The real-time interface is handled by the modules at the bottom. They’re controlled by the EtherCAT master at the center. (Source. R. Wotiz)

One of the systems is responsible for the real-time control of the mechanism. It communicates over an Ethernet control automation technology (EtherCAT) bus to several slave units, which provide the I/O interface to the sensors and actuators.


EtherCAT is a fieldbus providing high-speed, real-time control over a conventional 100 Mb/s Ethernet hardware infrastructure. It’s a relatively recent technology, originally developed by Beckhoff Automation GmbH, and currently managed by the EtherCAT Technology Group (ETG), which was formed in 2003. You need to be an ETG member to access most of their specification documents, but information is publicly available. According to information on the ETG website, membership is currently free to qualified companies. EtherCAT was also made a part of international standard IEC 61158 “Industrial Communication Networks—Fieldbus Specifications” in 2007.

EtherCAT uses standard Ethernet data frames, but instead of each device decoding and processing an individual frame, the devices are arranged in a daisy chain, where a single frame is circulated through all devices in sequence. Any device with an Ethernet port can function as the master, which initiates the frame transmission. The slaves need specialized EtherCAT ports. A two-port slave device receives and starts processing a frame while simultaneously sending it out to the next device (see Figure 2).

Figure 2—Each EtherCAT slave processes incoming data as it sends it out the downstream port. (Source: R. Wotiz))

The last slave in the chain detects that there isn’t a downstream device and sends its frame back to the previous device, where it eventually returns to the originating master. This forms a logical ring by taking advantage of both the outgoing and return paths in the full-duplex network. The last slave can also be directly connected to a second Ethernet port on the master, if one is available, creating a physical ring. This creates redundancy in case there is a break in the network. A slave with three or more ports can be used to form more complex topologies than a simple daisy chain. However, this wouldn’t speed up network operation, since a frame still has to travel through each slave, one at a time, in both directions.

The EtherCAT frame, known as a telegram, can be transmitted in one of two different ways depending on the network configuration. When all devices are on the same subnet, the data is sent as the entire payload of an Ethernet frame, using an EtherType value of 0x88A4 (see Figure 3a).

Figure 3a—An EtherCAT frame uses the standard Ethernet framing format with very little overhead. The payload size shown includes both the EtherCAT telegram and any padding bytes needed to bring the total frame size up to 64 bytes, the minimum size for an Ethernet frame. b—The payload can be encapsulated inside a UDP frame if it needs to pass through a router or switch. (Source: R. Wotiz)

If the telegrams must pass through a router or switch onto a different physical network, they may be encapsulated within a UDP datagram using a destination port number of 0x88A4 (see Figure 3b), though this will affect network performance. Slaves do not have their own Ethernet or IP addresses, so all telegrams will be processed by all slaves on a subnet regardless of which transmission method was used. Each telegram contains one or more EtherCAT datagrams (see Figure 4).

Each datagram includes a block of data and a command indicating what to do with the data. The commands fall into three categories. Write commands copy the data into a slave’s memory, while read commands copy slave data into the datagram as it passes through. Read/write commands do both operations in sequence, first copying data from memory into the outgoing datagram, then moving data that was originally in the datagram into memory. Depending on the addressing mode, the read and write operations of a read/write command can both access the same or different devices. This enables fast propagation of data between slaves.

Each datagram contains addressing information that specifies which slave device should be accessed and the memory address offset within the slave to be read or written. A 16-bit value for each enables up to 65,535 slaves to be addressed, with a 65,536-byte address space for each one. The command code specifies which of four different addressing modes to use. Position addressing specifies a slave by its physical location on the network. A slave is selected only if the address value is zero. It increments the address as it passes the datagram on to the next device. This enables the master to select a device by setting the address value to the negative of the number of devices in the network preceding the desired device. This addressing mode is useful during system startup before the slaves are configured with unique addresses. Node addressing specifies a slave by its configured address, which the master will set during the startup process. This mode enables direct access to a particular device’s memory or control registers. Logical addressing takes advantage of one or more fieldbus memory management units (FMMUs) on a slave device. Once configured, a FMMU will translate a logical address to any desired physical memory address. This may include the ability to specify individual bits in a data byte, which provides an efficient way to control specific I/O ports or register bits without having to send any more data than needed. Finally, broadcast addressing selects all slaves on the network. For broadcast reads, slaves send out the logical OR of their data with the data from the incoming datagram.

Each time a slave successfully reads or writes data contained in a datagram, it increments the working counter value (see Figure 4).

Figure 4—An EtherCAT telegram consists of a header and one or more datagrams. Each datagram can be addressed to one slave, a particular block of data within a slave, or multiple slaves. A slave can modify the datagram’s Address, C, IRQ, Process data, and WKC fields as it passes the data on to the next device. (Source: R. Wotiz)

This enables the master to confirm that all the slaves it was expecting to communicate with actually handled the data sent to them. If a slave is disconnected, or its configuration changes so it is no longer being addressed as expected, then it will no longer increment the counter. This alerts the master to rescan the network to confirm the presence of all devices and reconfigure them, if necessary. If a slave wants to alert the master of a high-priority event, it can set one or more bits in the IRQ field to request the master to take some predetermined action.


Frames are processed in each slave by a specialized EtherCAT slave controller (ESC), which extracts incoming data and inserts outgoing data into the frame as it passes through. The ESC operates at a high speed, resulting in a typical data delay from the incoming to the outgoing network port of less than 1 μs. The operating speed is often dominated by how fast the master can process the data, rather than the speed of the network itself. For a system that runs a process feedback loop, the master has to receive data from the previous cycle and process it before sending out data for the next cycle. The minimum cycle time TCYC is given by: TCYC = TMP + TFR + N × TDLY  + 2 × TCBL + TJ. TMP = master’s processing time, TFR = frame transmission time on the network (80 ns per data byte + 5 μs frame overhead), N = total number of slaves, TDLY  = sum of the forward and return delay times through each slave (typically 600 ns), TCBL = cable propagation delay (5 ns per meter for Category 5 Ethernet cable), and TJ = network jitter (determined by master).[1]

A slave’s internal processing time may overlap some or all of these time windows, depending on how its I/O is synchronized. The network may be slowed if the slave needs more time than the total cycle time computed above. A maximum-length telegram containing 1,486 bytes of process data can be communicated to a network of 1,000 slaves in less than 1 ms, not including processing time.

Synchronization is an important aspect of any fieldbus. EtherCAT uses a distributed clock (DC) with a resolution of 1 ns located in the ESC on each slave. The master can configure the slaves to take a snapshot of their individual DC values when a particular frame is sent. Each slave captures the value when the frame is received by the ESC in both the outbound and returning directions. The master then reads these values and computes the propagation delays between each device. It also computes the clock offsets between the slaves and its reference clock, then uses these values to update each slave’s DC to match the reference. The process can be repeated at regular intervals to compensate for clock drift. This results in an absolute clock error of less than 1 μs between devices.


The orchestra’s EtherCAT network is built around a set of modules from National Instruments. The virtual conductor is an application running under LabVIEW Real-Time on a CompactRIO controller, which functions as the master device. It communicates with four slaves containing a mix of digital and analog I/O and three slaves consisting of servo motor drives. Both the master and the I/O slaves contain a FPGA to implement any custom local processing that’s necessary to keep the data flowing. The system runs at a cycle time of 1 ms, which provides enough timing resolution to keep the balls properly flying.

I hope you’ve enjoyed learning about EtherCAT—as well as the fascinating musical device it’s used in—as much as I have.

Author’s note: I would like to thank Marc Christenson of SISU Devices, creator of this amazing device, for his help in providing information on the design.


[1] National Instruments Corp., “Benchmarks for the NI 9144 EtherCAT Slave Chassis,”


Animusic, LLC,

Beckhoff Automation GmbH, “ET1100 EtherCAT Slave Controller Hardware Data Sheet, Version 1.8”, 2010,

EtherCAT Technology Group, “The Ethernet Fieldbus”, 2009,

Intel, Atom microprocessor, www/us/en/processors/atom/atom-processor.html.


Atom D525 dual-core microprocessor

Intel Corp.

LabVIEW Real-Time modules, CompactRIO controller, and EtherCAT devices

National Instruments Corp.

Circuit Cellar 264 is now on newsstands, and it’s available at the CC-Webshop.

Issue 264: A Case for the DIY Electronics Fix

Most of today’s expensive electronics systems are engineered to be left alone—meaning, the manufacturer doesn’t want you opening, servicing, or tweaking the products on your own. But that doesn’t mean intelligent, inquisitive engineers shouldn’t give modern electronics gadgets a good hack. The rewards tend to outweigh the drawbacks. As Steve Ciarcia argues in Circuit Cellar 264 (July), you stand to learn a lot by looking inside electronics systems, especially broken ones. Even if you can’t fix them, you can pull out the components and use them in future projects.

In “Fix It or Toss It?” he writes:

No prophetic diatribes or deep philosophical insights this month. Just the musings of an old guy who apparently doesn’t know when to throw in the towel. Let me explain.

I have a friend with a couple LCD monitors he purchased about two years ago. Perhaps due to continuous duty operation (only interrupted by automatic “Sleep mode”), both were now exhibiting some flakiness, particularly when powering up from “sleep.” More importantly, if power was completely shut down, as in a power failure, they wouldn’t come back on at all without manual intervention. He asked if they could be repaired or must they be replaced.

Since I remembered something about a few manufacturers who’d had a bunch of motherboard problems a while back due to bad electrolytic capacitors, I suspected a power supply problem. Of course, agreeing to look into the problem and figuring out how to get inside the monitors was a whole different issue. Practically all of today’s electronics are not meant to be opened or serviced internally at all. Fortunately, my sledgehammer disassembly techniques weren’t so bad that I couldn’t reassemble them. In the process, I found several bulging and leaking capacitors on the power supply board. After replacing the capacitors, the monitors came right up with no problems.

Power supplies just seem to have it out for me. Recently, I had a wireless router stop working and, after a little diagnosing, I determined that its power supply (an external wall-wart) had failed. While hardly worth my time, I was curious, so I cracked open the sealed case to see just how complicated it was. Sure enough, replacing one scorched electrolytic capacitor and gluing the case back together put me back in business.

All this got me thinking about the relative value of various electronic devices. What is the replace/repair decision line? These $200 high-tech electronic LCD monitors failed because of $3 worth of old-tech components that I was fortunately able to fix. It took time to do the repair that has some value, but it also takes time to shop for and purchase a replacement. There must be better monitors these days for the same price. Should I have told him to toss them and use the opportunity to upgrade?

It’s interesting to consider the type of person who repairs stuff like this (being an EE with a fully equipped lab doesn’t hurt either). I mean, I do it primarily because I like knowing how things work. Okay, so I’m getting a little carried away after fixing a couple burnt capacitors, but there’s still an incredible sense of satisfaction in being able to put something back together and having it work. Since I was a kid, dissecting circuits and equipment helped me understand the design choices that were made, and my curiosity naturally lead me to engineering.

Now, I recognize that people like me who repair their own electronics for curiosity or adventure are very much in the minority. So, what about the average person with a failed piece of $200 electronics? For them, the only goal is getting the functionality back as soon as possible. Do they go to a repair service where it takes longer and involves a couple trips? Worse yet, some things just can’t be repaired, and the bad news then is having both the repair “inspection” cost and the replacement cost. I’m guessing that in 99% of typical cases, the no-brainer decision is to toss the failed unit and buy a new one—without ever giving me a chance to tear it apart and play with it.

Let’s face it. Taking modern equipment apart to make even simple repairs is next to impossible. The manufacturers use every trick in the design book to minimize the cost of the goods. This means leaving out features that might make end-user repair easier. Cases that snap together (once)—or worse, are heat-welded together—are cheaper than cases with screws or latches. Most board electronics are custom-labeled surface mount devices, everything uses custom connectors, and the short cabling between boards has no slack to swing out subassemblies for access, and so forth. You couldn’t even fit a scope probe inside most of this stuff if you tried. Sure, some manufacturers do still put component reference designators in the silkscreen, but I suspect it’s so they can repair subassemblies on their production line before final assembly, not make it easier for me to poke around.

Anyway, like I said, there’s no prophetic conclusion to be drawn from all of this. I fix stuff because I enjoy the challenge and I usually learn something from it. Even if I can’t repair the item, I usually keep some of the useful components and/or subassemblies for experimenter one-off projects or proof-of-concept prototypes. You never know when something in the junk box might prove useful.

Circuit Cellar 264 (July 2012) is now available on newsstands and at the Circuit Cellar Webshop.

Issue 264: EQ Answers

The answers to the Circuit Cellar 264 (July) Engineering Quotient are now available. The problems and answers are listed below, along with a schematic.

Problem 1a—Is it possible to transmit on-off (DC) signals between two pieces of equipment in both directions simultaneously on the same wire, in much the same way that telephones do for audio?

Source: D. Tweed, CC264

Answer 1a—Why not? Hybrids work just as well at DC as they do for audio; you just need a receiver with balanced inputs, like an RS-422 buffer:

All resistors are the same value (e.g., 4,700 Ω) and the transmit driver needs to be a voltage source (low impedance).

If the transmitter switches between, say, 0 V and 5 V, the opposite receiver will see a voltage differential of 0 V and 2.5 V, respectively, while the local receiver will just see 0V.

For long lines, you’ll probably want to use lower resistances and you’ll want to limit the slew rate of the transmitter so that the receiver doesn’t produce glitches on the transitions of the local transmitter.

If the RS-422 receiver is replaced with an op-amp differential amplifier with a gain of 2, then any analog voltage transmitted by one end will be reproduced at the other end.

Problem 1b—But doesn’t a true hybrid use transformers, or at least some tricky transformer simulation with op amps to ensure the transmitted signal does not appear on the receive port?

Answer 1b—No. A hybrid is just a bridge circuit, with one arm of the bridge replaced by the line and the termination at the far end. The transmit signal is applied to two opposite corners of the bridge and the receive signal is taken from the other two corners.

In order to provide the Tx/Rx isolation, the bridge must be balanced, which in the example above, means that the lower resistor on each side must match the impedance of the line/far end combination. For DC and short lines, a simple resistor suffices. At audio frequencies and with the long unshielded twisted pairs used in telephony, a more complex matching impedance is required.

Transformers are used only because it’s the easiest way (and the only passive way) to get a balanced drive and/or receive signal — the transmit driver and receiver cannot share a ground. In order to mass produce phones that were dirt cheap, yet simple and reliable, the phone company figured out how to use a multi-winding transformer to provide the both the isolation and the balanced/unbalanced conversion in both directions, usually with a single resistor and capacitor to provide the line matching. As noted, modern electronic phones use active electronics to achieve the same things.

As always, the theory is simple, but the practical implementations can get complicated.

Problem 2a—The conventional way to calculate the magnitude (length) of a vector is to take the square root of the sum of the squares of its components. On small processors, this can be somewhat difficult (especially the square root operation), and various approximations are used instead.

One approximation that works surprisingly well for 2-D vectors and complex numbers is to take the absolute values of the two components, compare them, then add 1/3 of the smaller to the larger.

What is the maximum error using this method?

Answer 2a—If we restrict the discussion to unit vectors at various angles A, the x component is cos(A) and the y component is sin(A), and the correct magnitude is 1.

Furthermore, let’s concentrate on angles between 0 and 45° — then we know that both cos(A) and sin(A) are positive and that cos(A) > sin(A). (The absolute value and compare operations provide the symmetry that covers the rest of the unit circle.) The approximation then gives the result

Magnitude = cos(A) + sin(A)/3

Graphing this shows that this is most negative (0.943) at 45° and most positive (1.054) at approximately 18.4° (the actual angle is given by atan(1/3) —can you show why?). The peak error is therefore –5.7%, +5.4%.

Problem 2b—Is there a similar formula that gives even better results?

Answer 2b—Yes. One more multiplication operation gives a result that has less than 4% error:

Magnitude = 0.960433 × max(|x|, |y|) + 0.397826 × min(|x|, |y|)

This function is most negative at 0° and 45°, and most positive at 22.5°. The error is ± 3.96%. This form is well-suited to DSPs that have multiply-accumulate units. The two constants can be expressed as 62943/65536 and 26072/65536, respectively.

Contributor: David Tweed

Q&A: Ayse Kivilcim Coskun (Engineer, BU)

Ayse Kivilcim Coskun’s research on 3-D stacked systems has gained notoriety in academia, and it could change the way electrical engineers and chip manufacturers think about energy efficiency for years to come. In a recent interview, the Boston University engineering professor briefed us on her work and explained how she came to focus on the topics of green computing and 3-D systems.

Boston University professor Ayse Kivilcim Coskun

The following is an excerpt from an interview that appears in Circuit Cellar 264 (July 2012), which is currently on newsstands.

NAN: When did you first become interested in computer engineering?

AYSE: I’ve been interested in electronics since high school and in science and physics since I was little. My undergraduate major was microelectronics engineering. I actually did not start studying computer engineering officially until graduate school at University of California, San Diego. However, during my undergraduate education, I started taking programming, operating systems, logic design, and computer architecture classes, which spiked my interest in the area.

NAN: Tell us about your teaching position at the Electrical and Computer Engineering Department at Boston University (BU).

AYSE: I have been an assistant professor at BU for almost three years. I teach Introduction to Software Engineering to undergraduates and Introduction to Embedded systems to graduate students. I enjoy that both courses develop computational thinking as well as hands-on implementation skills. It’s great to see the students learning to build systems and have fun while learning.

NAN: As an engineering professor, you have some insight into what excites future engineers. What “hot topics” currently interest your students?

AYSE: Programming and software design in general are certainly attracting a lot of interest. Our introductory software engineering class is attracting a growing number of students across the College of Engineering every year. DSP, image processing, and security are also hot topics among the students. Our engineering students are very keen on seeing a working system at the end of their class projects. Some project examples from my embedded systems class include embedded low-power gaming consoles, autonomous toy vehicles, and embedded systems focusing on healthcare or security applications …

NAN: How did you come to focus on energy efficiency and thermal challenges?

AYSE: Energy efficiency has been a hot topic for embedded systems for several decades, mainly due to battery-life restrictions. With the growth of computing sources at all levels—from embedded to large-scale computers, and following the move to data centers and the cloud—now energy efficiency is a major bottleneck for any computing system. The focus on energy efficiency and temperature management among the academic community was increasing when I started my PhD. I got especially interested in thermally induced problems as I also had some background on fault tolerance and reliability topics. I thought it would be interesting to leverage job scheduling to improve thermal behavior and my advisor liked the idea too. Temperature-aware job scheduling in multiprocessor systems was the first energy-efficiency related project I worked on.

NAN: In May 2011, you were awarded the A. Richard Newton Graduate Scholarship at the Design Automation Conference (DAC) for a joint project, “3-D Systems for Low-Power High-Performance Computing.” Tell us about the project and how you became involved.

AYSE: My vision is that 3-D stacked systems—where multiple dies are stacked together into a single chip—can provide significant benefits in energy efficiency. However, there are design, modeling, and management challenges that need to be addressed in order to simultaneously achieve energy efficiency and reliability. For example, stacking enables putting DRAM and processor cores together on a single 3-D chip. This means we can cut down the memory access latency, which is the main performance bottleneck for a lot of applications today. This gain in performance could be leveraged to run processors at a lower speed or use simpler cores, which would enable low-power, high-performance computing. Or we can use the reduction in memory latency to boost performance of single-chip multicore systems. Higher performance, however, means higher power and temperature. Thermal challenges are already pressing concerns for 3-D design, as cooling these systems is difficult. The project focuses on simultaneously analyzing performance, power, and temperature and using this analysis to design system management methods that maximize performance under power or thermal constraints.

I started researching 3-D systems during a summer internship at  the Swiss Federal Institute of Technology (EPFL) in the last year of my PhD. Now, the area is maturing and there are even some 3-D prototype systems being designed. I think it is an exciting time for 3-D research as we’ll start seeing a larger pool of commercial 3-D stacked chips in a few years. The A. Richard Newton scholarship enabled us to do the preliminary research and collect results. Following the scholarship, I also received a National Science Foundation (NSF) CAREER award for designing innovative strategies for modeling and management of 3-D stacked systems.

The entire interview appears in Circuit Cellar 264  (July 2012).

Electronics Engineering Crossword (Issue 264)

The answers to Circuit Cellar’s July Electronics Engineer crossword puzzle are now available.

Issue 264 crossword answers


3.     IONIZATION—Occurs when an atom or molecule gains either and positive or negative charge

4.     ANDROIDPHONE—In “Audio-Enhanced Touch Sensors” (Circuit Cellar, May 2012), Matt Oppenheim said one of the stumbling blocks of using this for data collection is that it will try to recharge itself whenever you connect it to a USB port. [two words]

6.     FOLTZER—Circuit Cellar interviewee who participated in Motorola’s IEEE-802 MAC subcommittee on token-passing access control methods. [two words]

13.   COORDINATEDUNIVERSALTIME—A method of keeping the world in sync [three words]

14.   CICCHINELLI—Circuit Cellar published his book about a commonly used computer programming language in 2010

17.   HACKSPACE—i.e, “a circuit cellar”

18.   CHIP—A basic component of an electronic device

19.   VOLTAGEREFERENCE—National Semiconductor’s LM385 series is an example of an adjustable one. [three words]


1.     DOPPLEREFFECT—A phenomenon that occurs when a vehicle sounding a siren approaches, passes, and recedes from an observer [two words]

2.     WAVEFORMGENERATOR—A device that produces electronic signals [two words]

5.     ANGSTROM—Equals 1/10,000,000,000 m

7.     ISOTHERMALPROCESS— ΔT = 0 [two words]

8.     COMPARATOR—A device that compares two voltages or currents and switches its output to indicate which is larger

9.     NSPE—Organization formed in 1934 by bridge engineer David Steinman

10.   EMI—Acronym; common cause of electronic data corruption and subject of Novacek’s December 2011 Circuit Cellar article [two words]

11.   PIEZOELECTRICITY—Occurs when crystals acquire a charge after being compressed, twisted, or distorted (e.g., quartz)

12.   WIDLAR—American electrical engineer (1937–1991); IC pioneer

15.   LEDDRIVER—Circuitry that regulates or provides powers to a light source [two words]

16.   JOULE—Symbolized by 10th letter of the alphabet

20.   RTOS—Hint: acronym. Unscramble the following: IETEORGSEPSMNYMRLTIAEAT

CC264: Plan, Construct, and Secure

Circuit Cellar July 2012 features innovative ideas for embedded design projects, handy design tips with real-world examples, and essential information on embedded design planning and security. A particularly interesting topic covered in this issue is the microcontroller-based home control systems (HCS). Interest in building and HCSes never wanes. In fact, articles about such projects have appeared in this magazine since 1988.

Circuit Cellar 264 (July 2012) is now available.

Turn to page 18 for the first HCS-related article. John Breitenbach details how he built an Internet-enabled, cloud-based attic monitoring system. Turn to page 36 for another HCS article. Tommy Tyler explains how to build a handy MCU-based digital thermometer. You can construct a similar system for your home, or you can apply what you learn to a variety of other temperature-sensing applications. Are you currently working on a home automation design or industrial control system? Check out Richard Wotiz’s “EtherCAT Orchestra” (p. 52). He describes an innovative industrial control network built around seven embedded controllers.

John Breitenbach's DIY leak-monitoring system

The wiring diagram for Tommy Tyler's MCU-based digital thermometer

The rest of the articles in the issue cover essential electrical engineering concepts and design techniques. Engineers of every skill level will find the information immediately applicable to the projects on their workbenches.

Tom Struzik’s article on USB is a good introduction to the technology, and it details how to effectively customize an I/O and data transfer solution (p. 28). On page 44, Patrick Schaumont introduces the topic of electronic signatures and then details how to use them to sign firmware updates. George Novacek provides a project development road map for professionals and novices alike (p. 58). Flip to page 62 for George Martin’s insight on switch debouncing and interfacing to a simple device. On page 68, Jeff Bachiochi tackles the concepts of wireless data delivery and time stamping.

Jeff Bachiochi's hand-wired modules

I encourage you to read the interview with Boston University professor Ayse Kivilcim Coskun on page 26. Her research on 3-D stacked systems has gained notoriety in academia, and it could change the way electrical engineers and chip manufacturers think about energy efficiency for years to come. If you’re an engineer fascinated by “green computing,” you’ll find Coskun’s work particularly intriguing.

Special note: The Circuit Cellar staff dedicates this issue to Richard Alan Wotiz who passed away on May 30, 2012. We appreciate having had the opportunity to publish articles about his inventive projects and innovative engineering ideas and solutions. We extend our condolences to his family and friends.

Circuit Cellar Issue 264 (July 2012) is now available on newsstands. Go to Circuit Cellar Digital and then select “Free Preview” to take a look at the first several pages.