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.

Build a Microcontroller-Based Mail Client

Does the sheer amount of junk mail that fills your Inbox make you hate everything about e-mail? If so, it’s time to have a little fun with electronic mail by building a compact microcontroller-based mail client system. Alexander Mann designed a system that uses an Atmel ATmega32 and a Microchip Technology ENC28J60 Ethernet controller to check continuously for e-mail. When a message arrives, he can immediately read it on the system’s LCD and respond with a standard keyboard.

Mann writes:

My MiniEmail system is a compact microcontroller-based mail client (see Photo 1). The silent, easy-to-use system doesn’t require a lot of power and it is immune to mail worms. Another advantage is the system’s short start-up time. If you want to write a quick e-mail but your PC is off, you can simply switch on the miniature e-mail client and start writing without having to wait for your PC to boot up and load the necessary applications. All you need is an Ethernet connection and the MiniEmail system.

Photo 1: The complete MiniEmail system includes an LCD, a keyboard, and several connections. (A. Mann, Circuit Cellar 204)


The hardware for the MiniEmail system is inexpensive. It cost me about $50. The LCD is the most expensive part. To keep things simple, I left the system’s power supply, 5- to 3.3-V conversion crystals, and latch out of Figure 1.

Figure 1: This is a block diagram of MiniEmail’s hardware. The arrows indicate the directions of data flow between the devices. The rounded boxes indicate parts that do not sit on the circuit board.

The main components are an Atmel ATmega32 microcontroller and a Microchip Technology ENC28J60 Ethernet controller. Because a mail client is a piece of complex software, you need a fast microcontroller that has a considerable amount of program space. The MiniEmail system uses almost all of the ATmega32’s features, including the SPI, internal EEPROM and SRAM, counters, USART interface, sleep modes, all 32 I/O lines, and most of the 32 KB of program memory. The ENC28J60 is a stand-alone Ethernet controller that provides basic functionality for transmitting frames over an Ethernet connection. It has 8 KB of built-in SRAM, which can be divided into transmit and receive buffers as desired, and it provides several interrupt sources (e.g., when new packets have arrived). The ATmega32 also has 128 KB of external SRAM connected as well as an LCD, which is a standard module with a resolution of 128 × 64 pixels.

Take a look at the ATmega32’s pin connections in Figure 2. Ports A and C are used as 8-bit-wide general I/O ports, one of which is latched using an NXP Semiconductors 74HC573.

Figure 2: Here’s the complete schematic for the MiniEmail. The LF1S022 is the RJ-45 connector for the Ethernet connection.

The two ports provide data connections to the LCD and SRAM (U3). For the SRAM, you need three additional wires: write (*RAM_WR), read strobe (*RAM_RD), and the seventeenth bit of the address (ADDR16). The LCD connector (CON1) uses five additional wires (for the signals CS1, CS2, DI, EN, and RW). CS1 and CS2 are taken from the general I/O port A (DATA6 and DATA7) and determine which of the two halves of the LCD is selected (i.e., the two controllers on the LCD module you are talking to). RW (where you can use ADDR16 again) sets the direction of the LCD access (read or write). DI describes the type of instruction sent to the LCD. EN is the enable signal for read and write cycles. For the keyboard, you need only two pins: KEY_DATA and KEY_CLOCK. The clock signal must be connected to an external interrupt pin, INT1. One additional wire is needed to switch the latch (LE).

You are left with eight I/O pins on the ATmega32’s ports B and D. RXD and TXD are connected to a MAX232, an RS-232 level converter that also provides the negative supply voltage needed for the LCD (LCD_VOUT in Figure 2). The ATmega32’s USART functionality is used as a debugging interface. It isn’t needed for normal operation.


The firmware for this project is posted on the Circuit Cellar FTP site. I wrote the firmware in C language with a few small parts of inline assembler. I used the open-source software suite WinAVR, which includes the GNU GCC compiler with special libraries for AVR devices and avrdude, a tool for the in-system programming of AVR microcontrollers…


The user interface consists of three control elements: menus, edit fields, and an elaborate text editor. A special screen (the Mail Menu) enables you to quickly browse through your mailbox. After power-up, the system displays a greeting message. After a short while, the Main menu appears (see Photo 2).

Photo 2: This is a screenshot of MiniEmail’s main menu. In the upper-right corner, a clock shows the current time, which is retrieved from the Internet. An arrow to the left of the menu items indicates the selected item. (A. Mann, Circuit Cellar 204)

The Compose Mail, Check Mailbox, and Configuration submenus form a hierarchical menu structure. When the other items listed beneath the respective menu titles in the diagram are activated (e.g., start the text editor), they enable you to input data, such as a username and password, or retrieve mail from the mail server. “Standby” is the only action that is accessible directly from the main menu. All other actions are grouped by function in the submenus.


With respect to the firmware, sending mail is much easier than reading it, so let’s first focus on the Compose Mail menu. The first item in the menu starts the text editor so you can enter the body of your letter. You then enter the recipient’s mailing address and the subject of your e-mail, just like you would do when sending e-mail from your PC. Additional fields, such as CC or BCC are not included, but since this requires only one more line in the header of the mail, it is not difficult. Your e-mail also needs a reply address, so the recipient knows who sent the mail. The reply address is normally the same for all of the messages you write. The text you enter in this edit field is stored in the ATmega32’s EEPROM, so you don’t have to type it every time you write a letter. After you select the last menu item, “Send” initiates the dispatch of the mail and displays a message that indicates whether or not it was successful.


What makes this part more sophisticated is the ability to handle not only one e-mail at a time, but also fetch mail from the server. The system can determine which messages are new and which messages have been read. It can also extract data such as the sender, subject, or sent date from the header of the mail and then display the information.

The amount of mail the firmware can handle is limited by the size of the external SRAM. The maximum number of e-mails is currently 1,024. (If you’ve got more mail, you will be so busy answering it that you won’t have time to build your own MiniEmail client—or you should delete some old mail). Note that 1,024 is the number of unique identifiers that the system can remember. The server assigns a unique identifier to each piece of mail. The system uses the identifiers to keep track of which letters are new on the server, which have already been read, and which have been marked for deletion.

All of the header data for all of the 1,024 messages cannot be held in SRAM at once; only the most recent (about 50) mail headers are held. When you want to browse through older e-mails, the firmware automatically reconnects to the server and fetches the headers of the next 50 e-mails.

When you select Check Mailbox in the main menu, you get to a submenu where you can retrieve and read mail. Before you can collect your mail, you must enter your username and password, which can be stored in EEPROM for your convenience. The firmware then retrieves the headers and displays the Mail Menu, where you can browse through your e-mail. Apart from the size and the date, the first 42 characters of the subject and the mail sender are shown. In the first row, additional icons indicate (from left to right) whether a message is new, has been marked for deletion, or has been read. You can view the content of the selected message by pressing Return. When the mail is fetched from the server, it is prepared for viewing. The header and HTML tags, as well as long runs of the same character, are stripped from the mail and base64 decoding (used to encode 8-bit characters) is performed, so the content of the message is as readable as plain text. Binary attachments (e.g., images) can’t be handled. Following this, the mail is viewed in the text editor (with editing disabled).

A similar action is performed when you press “r” in the Mail Menu. In that case, you can edit the text so you can add your reply. Leaving the text editor will bring you back to the Send Mail menu, where the reply address and subject will be filled in so your mail will be clear for take-off. To delete a message, simply press D to mark it for deletion….


I hadn’t imagined how many details would need to be considered when I started this project more than a year ago. It has been a very interesting and challenging project. It has also been a lot of fun.

The MiniEmail system provides all of the basics for communicating via email, but such a project is never really finished. There are still dozens of items on my to-do list. Fortunately, the ATmega32 can be replaced with a new member of the AVR family, the Atmel ATmega644, which is pin-compatible to the ATmega32 and has twice the flash memory (and internal SRAM). That will provide enough space for many of my new ideas. I want to get rid of the static IP address, add CC and BCC fields, use a bigger display or a smaller (variable-width) font, improve the filtering and display of mail content and attachments, and add an address book (it would be best in combination with an additional external EEPROM with an SPI, such as the AT25256).

This project proves, rather impressively, that the ATmega32 and the ENC28J60 are a powerful combination. They can be used for many useful Internet applications. My e-mail client system is surely one of the most exciting. I can think of many other interesting possibilities. At the moment, my MiniEmail assembly serves as an online thermometer so I can check my room’s temperature from anywhere in the world…

Mann’s entire article appears in Circuit Cellar 204, 2007. Type “miniemailopen”  to access the password-protected article.

Free Webinar: Bridge Android & Your Electronics Projects

Do you want to add a powerful wireless Android device to your own projects? Now you can, and doing so is easier than you think.

With their high-resolution touchscreens, ample computing power, WLAN support, and telephone functions, Android smartphones and tablets are ideal for use as control centers in your projects. But until now, it has been difficult to connect them to external circuitry. Elektor’s AndroPod interface board, which adds a serial TTL port and an RS-485 port to the picture, changes this situation.

The Elektor AndroPod module

In a free webinar on June 21, 2012, Bernhard Wörndl-Aichriedler (codesigner of the AndroPod Interface) will explain how easy it is to connect your own circuitry to an Android smartphone using the AndroPod interface. Click here to register.

Elektor Academy and element14 have teamed up to bring you a series of exclusive webinars covering blockbuster projects from recent editions of Elektor magazine. Participation in these webinars is completely free!

Webinar: AndroPod – Bridging Android and Your Electronics Projects
Date: Thursday June 21, 2012
Time: 16:00 CET
Presenter: Bernhard Wörndl-Aichriedler (Codesigner of the Andropod Interface)
Language: English is an Elektor International Media publication.

Issue 263: H2M & M2M Communication

Before I introduce this issue, I’d like to bring your attention to our recently redesigned website, It enables engineers and programmers around the world to communicate and share ideas via project articles, videos, and social media. The site’s features range from project posts (how-to articles, videos, and photos) to daily updates about products and industry news. We also run short write-ups on actual circuit cellars and workbenches in the well-received “Workspaces” section of the site. I encourage you to submit photos and info about your workspaces. Share your space with the design community!

Now let’s focus on this issue, which has articles on both human-to-machine (H2M) and machine-to-machine (M2M) communication. Topics as diverse as smart switch management and human motion-sensing systems are covered.

Kevin Gorga kicks off the issue with his “AC Tester” project (p. 14). It is an isolated variable voltage power source that includes an electronic circuit breaker for testing and debugging equipment. An mbed controller displays voltage and current, and it controls the breaker’s trip point and response time.

Circuit Cellar published 15 of Aubrey Kagan’s articles from 2000 to 2010. In an interview on page 24, Aubrey shares some of his engineering experiences from designing controllers for mines in Africa to helping create specs for the remote control arm on the International Space Station.

On page 28, Fergus Dixon presents a ’Net-connected controller for up to 50 smart switches for lighting systems. The controller’s RTC pulses a 24-V AC line once or twice to turn off the smart switches at the end of the day.

Final PCB with a surface-mount Microchip Technology ENC28J60 Ethernet chip (Source: F. Dixon, CC263)

Turn to page 36 if you’re interested in computer vision technology. Miguel Sánchez introduces depth camera technology, and describes how he used Microsoft’s Kinect in an interactive art project.

On page 44, columnist Bob Japenga starts an articles series on the subject of concurrency in embedded systems. In this article, he defines concurrency and covers some concurrency-related pitfalls.

Last month columnist George Novacek examined the topic of product testing and simulation. In this issue, he tackles a different yet equally important topic: diode ORing (p. 48).

On page 52, columnist Ed Nisley carefully explains MOSFET channel resistance. He describes power MOSFET operation and explores the challenges of using a MOSFET’s drain-to-source resistance as a current-sensing resistor.

A serious RF designer should have a sound understanding of frequency mixers. On page 58, columnist Robert Lacoste summarizes the basics of RF mixers and presents real-life applications.

A simple single-diode unbalanced mixer and its simulation done with Labcenter's Proteus. The RF and LO frequencies are 340 MHz and 300 MHz respectively. You can see on the output spectrum that these two frequencies are still visible, but as well as the difference 40 MHz and sum 640 MHz, among others. (Source: R. Lacoste, CC263)

Jeff Bachiochi wraps up the issue with an article about a DIY, MCU-based blood pressure cuff project (p. 68). He converted a manual blood pressure cuff into an automatic cuff by adding an air pump, a solenoid release valve, and a pressure sensor.

Circuit Cellar Issue 263 (June 2012) is now available on newsstands.

A Workspace for Radio & Metrology Projects

Ralph Berres, a television technician in Germany, created an exemplary design space in his house for working on projects relating to his two main technical interests: amateur radio and metrology (the science of measurement). He even builds his own measurement equipment for his bench.

Ralph Berres built this workspace for his radio and metrology projects

“I am a licensed radio amateur with the call sign DF6WU… My hobby is high-frequency and low-frequency metrology,” Berres wrote in his submission.

Amateur radio is popular among Circuit Cellar readers. Countless electrical engineers and technical DIYers I’ve met or worked with during the past few years are amateur radio operators. Some got involved in radio during childhood. Others obtained radio licenses more recently. For instance, Rebecca Yang of chronicled the process in late 2011. Check it out: and

Do you want to share images of your workspace, hackspace, or “circuit cellar” with the world? Click here to email us your images and workspace info.


Q&A: Lawrence Foltzer (Communications Engineer)

In the U.S., a common gift to give someone when he or she finishes school or completes a course of career training is Dr. Seuss’s book, Oh, the Place You’ll Go. I thought of the book’s title when I first read our May interview with engineer Lawrence Foltzer. After finishing electronics training in the U.S. Navy, Foltzer found himself working in such diverse locations as a destroyer in Mediterranean Sea, IBM’s Watson Research Center in Yorktown Heights, NY, and Optilink, DSC, Alcatel, and Turin Networks in Petaluma, CA. Simply put: his electronics training has taken him to many interesting places!

Foltzer’s interests include fiber optic communication, telecommunications, direct digital synthesis, and robot navigation. He wrote four articles for Circuit Cellar between June 1993 and March 2012.

Lawrence Foltzer presented these frequency-domain test instruments in Circuit Cellar 254 (September 2011). An Analog Devices AD9834-based RFG is on the left. An AD5930-based SFG is on the right. The ICSP interface used to program a Microchip Technology PIC16F627A microcontroller is provided by a dangling RJ connector socket. (Source: L. Foltzer, CC254)

Below is an abridged version of the interview now available in Circuit Cellar 262 (May 2012).

NAN: You spent 30 years working in the fiber optics communication industry. How did that come about? Have you always had an interest specifically in fiber optic technology?

LARRY: My career has taken me many interesting places, working with an amazing group of people, on the cusp of many technologies. I got my first electronics training in the Navy, both operating and maintaining the various anti-submarine warfare systems including the active sonar system; Gertrude, the underwater telephone; and two fire-control electromechanical computers for hedgehog and torpedo targeting. I spent two of my four years in the Navy in schools.

When I got out of the Navy in 1964, I managed to land a job with IBM. I’d applied for a job maintaining computers, but IBM sent me to the Thomas J. Watson Research Center in Yorktown Heights, NY. They gave me several tests on two different visits before hiring me. I was one of four out of forty who got a job. Mine was working in John B. Gunn’s group, preparing Gunn-oscillator samples and assisting the physicists in the group in performing both microwave and high-speed pulsed measurements.

One of my sample preparation duties was the application of AuGeNi ohmic contacts on GaAs samples. Ohmic contacts were essential to the proper operation of the Gunn effect, which is a bulk semiconductor phenomenon. Other labs at the research center were also working with GaAs for other devices: the LED, injection laser diode, and Hall-effect sensors to name a few. It turned out that the evaporated AuGeNi contact used on the Gunn devices was superior to the plated AuSnIn contact, so I soon found myself making 40,000 A per square centimeter pulsed-diode lasers. A year later I transferred to Gaithersburg, MD, to IBM-FSD where I was responsible for transferring laser diode technology to the group that made battlefield laser illuminators and optical radars. We used flexible light guides to bring the output from many lasers together to increase beam brightness.

As the Vietnam war came to an end, IBM closed down the Laser and Quantum Electronics (LQE) group I was in, but at the same time I received a job offer to join Comsat Labs, Clarksburg, MD, from an engineer for whom I had built Gunn devices for phased array studies. So back to the world of microwaves for a few years where I worked on the satellite qualification of tunnel (Asaki) diodes, Impatt diodes, step-recovery diodes, and GaAs FETs.

About a year after joining Comsat Labs, the former head of the now defunct IBM-LQE group, Bill Culver, called on me to help him prove to the army that a “single-fiber,” over-the-hill guided missile could replace the TOW missile and save soldier lives from the target tanks counterfire.

NAN: Tell us about some of your early projects and the types of technologies you used and worked on during that time.

LARRY: So, in 1973-ish, Bill Culver, Gordon Gould (Laser Inventor), and I formed Optelecom, Inc. In those days, when one spoke of fiber optics, one meant fiber bundles. Single fibers were seen as too unreliable, so hundreds of fibers were bundled together so that a loss of tens of fibers only caused a loss of a few percent of the injected light. Furthermore, bundles presented a large cross section to the primitive light sources of the day, which helped increase transmission distances.

Bill remembered seeing one of C. L. Stong’s Amateur Scientist columns in Scientific American about a beam balance based on a silica fiber suspension. In that column, Stong had shown that silica fibers could be made with tensile strengths 20 times that of steel. So a week later, Bill and I had constructed a fiber drawing apparatus in my basement and we drew the first few meters of fiber of the approximately 350 km of fiber we made in my home until we captured our first army contract and opened an office in Gaithersburg, MD.

Our first fibers were for mechanical-strength development. Optical losses measured hundreds of dBs/km in those days. But our plastic clad silica (PCS) fiber losses pretty much tracked those of Corning, Bell Labs, and ITT-EOPD (Electro-Optics Products Division). Pretty soon we were making 8 dB/km fibers up to 6 km in length. I left Optelecom when follow-on contracts with the army slowed; but by that time we had demonstrated missile payout of 4 km of signal carrying fiber at speeds of 600 ft/s, and slower speed runs from fixed-wing and Helo RPVs. The first video games were born!

At Optelecom I also worked with Gordon Gould on a CO2 laser-based secure communications system. A ground-based laser interrogated a Stark-effect based modulator and retro-reflector that returned a video signal to the ground station. I designed and developed all of that system’s electronics.

Government funding for our fiber payout work diminished, so I joined ITT-EOPD in 1976. In those days, if you needed a connector or a splice, or a pigtailed LED, laser or detector, you made it yourself; and I was good with my hands. So, in addition to running programs to develop fused fiber couplers, etc., I was also in charge of the group that built the emitters and detectors needed to support the transmission systems group.

NAN: You participated in Motorola’s IEEE-802 MAC subcommittee on token-passing access control methods. Tell us about that experience.

NAN: How long have you been designing MCU-based systems? Tell us about your first MCU-based design.

LARRY: I was in Motorola’s strategic marketing department (SMD) when the Apple 2 first came on the scene. Some of the folks in the SMD were the developers of the RadioShack color computer. Long story short, I quickly became a fan of the MC6809 CPU, and wrote some pretty fancy code for the day that rotated 3-D objects, and a more animated version of Space Invaders. I developed a menu-driven EPROM programmer that could program all of the EPROMs then available and then some. My company, Computer Accessories of AZ, advertised in Rainbow magazine until the PC savaged the market. I sold about 1,200 programmers and a few other products before closing up shop.

NAN: Circuit Cellar has published four of your articles about design projects. Your first article, “Long-Range Infrared Communications” was published in 1993 (Circuit Cellar 35). Which advances in IR technology have most impressed and excited you since then?

LARRY: Vertical cavity surface-emitting lasers (VCSEL). The Japanese were the first to realize their potential, but did not participate in their early development. Honeywell Optoelectronics was the first to offer 850-nm VCSELs commercially. I think I bought my first VCSELs from Hamilton Avnet in the late 1980s for $6 a pop. But 850 nm is excluded from Telecom (Bellcore), so companies like Cielo and Picolight went to work on long wavelength parts. I worked with Cielo on 1310-nm VCSEL array technology while at Turin Networks, and actually succeeded in adding VCSEL transmitter and array receiver optics to several optical line cards. It was my hope that VCSELs would find their way into the fiber to the home (FTTH) systems of the future, delivering 1 Gbps or more for 33% of what it costs today.

Circuit Cellar 262 (May 2012) is now on newsstands.

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,

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:

User Interface Innovation: Collaborative Navigation in Virtual Search and Rescue

An engineering team from Virginia Tech’s Center of HCI and Department of Computer Science recently won first place in the IEEE’s 2012 3DUI Contest the for their Collaborative Navigation in Virtual Search and Rescue Escort (CARNAGE) project. The project was designed to enable emergency responders to collaborate and safely navigate a dangerous environment such as a disaster area.

The contest was open to researchers, students, and professionals working on 3-D user interface technologies. Entrants were challenged to design an application to enable two users—situated in different locations with his or her own UI—to navigate a 3-D environment without speaking to each other.

Collaborative Augmented Rescue Navigation and Guidance Escort UI (Source: Virginia Tech News, YouTube)

The Virginia Tech team—comprising Felipe Bacim, Eric Ragan, Siroberto, and Cheryl Stinson—described their design in a concise system description, which is currently available on the 3DUI 2012 contest website:

Our task specifically looks at communication between a scene commander and a disaster relief responder during a search and rescue operation. The responders inside the environment have great difficulty navigating because of hazards, reduced visibility, disorientation, and lack of survey knowledge of the environment. Observing the operation from outside of the disaster area, scene commanders work to help coordinate the response effort  [1, 2]. With the responder’s notifications about the environment, scene commanders can provide new instructions, alert the responders to risks, and issue evacuation orders. Since neither the commander nor the responder has complete information about the environment, effective communication is essential.

As technology advances, the incorporation of new tools into search and rescue protocols shows promise for improving  operation efficiency and safety. In this research, we explore the  use of 3D user interfaces to assist collaborative search-and-rescue. Ideally, users should be able to focus on their primary tasks in the VE, rather than struggle with travel and way finding. Using virtual reality (VR) as a prototyping testbed, we implemented a proof-of-concept collaborative guidance system. Preliminary evaluation has demonstrated promising results for efficient rescue operations.

The team also created an explanatory 6:16-minute project video:

Click here for more information about the IEEE Symposium on 3D User Interfaces in Costa Mesa, CA.

Source: Virginia Tech News


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

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

RFI Bypasssing

With GPS technology and audio radio interfaces on his personal fleet of bikes, Circuit Cellar columnist Ed Nisley’s family can communicate to each other while sending GPS location data via an automatic packet reporting system (APRS) network. In his February 2012 article, Ed describes a project for which he used a KG-UV3D radio interface rigged with SMD capacitors to suppress RF energy. He covers topics such as test-fixture measurements on isolated capacitors and bypassing beyond VHF.

Photo 2 from the Febuary article, "RFI Bypassing (Part 1)." A pair of axial-lead resistors isolate the tracking generator and spectrum analyzer from the components under test. The 47-Ω SMD resistor, standing upright just to the right of the resistor lead junction, forms an almost perfect terminator. (Source: Ed Nisley CC259)

Ed writes:

Repeatable and dependable measurements require a solid test fixture. Although the collection of parts in Photo 2 may look like a kludge, it’s an exemplar of the “ugly construction” technique that’s actually a good way to build RF circuits. “Some Thoughts on Breadboarding,” by Wes Hayword, W7ZOI, gives details and suggestions for constructing RF projects above a solid printed circuit board (PCB) ground plane.

You can read this article now in Circuit Cellar 259. If you aren’t a subscriber, you can purchase a copy of the issue here.


GPS-Based Vehicle Timing & Tracking Project

The KartTracker’s Renesas kit (Source: Steve Lubbers CC259)

You can design and construct your own vehicle timing system at your workbench. Steve Lubbers did just that, and he describes his project in Circuit Cellar 259 (February 2012). He calls his design the “Kart Tracker,” which he built around a Renesas Electronics Corp. RX62N RDK. In fact, Steve writes that the kit has most of what’s need to bring such a design to fruition:

Most of the pieces of my KartTracker are already built into the Renesas Electronics RX62N development board (see Figure 1). The liquid crystal display (LCD) on the development board operates as the user interface and shows the driver what is happening as he races. The integrated accelerometer can be used to record the G forces experienced while racing. A serial port provides connections to a GPS receiver and a wireless transmitter. Removable flash memory stores all the race data so you can brag to your friends. You now have all of the pieces of my KartTracker.

The following block diagram depicts the relationship between the CPU, base station, flash drive, and other key components:

KartTracker Diagram (Source: Steve Lubbers CC259)

The software for the system is fairly straightforward. Steve writes:

The KartTracker software was built around the UART software sample provided with the RX62N development kit. To provide file system support, the Renesas microSD/Tiny FAT software was added. Finally, my custom GPS KartTracker software was added to the Renesas samples. My software consists of GPS, navigation, waypoints, and display modules. Support software was added to interface to the UART serial port, the file system, and the user display and control on the RX62N circuit board.

Pseudocode for the main processing loop (Source: Steve Lubbers CC259)

Read Steve’s article in the February issue for more details.

If you want to build a similar system, you should get familiar with the Renesas RX62N RDK. In the following video, Dave Jones of EEVBlog provides a quick and useful introduction to the RX62N RDK and its specs (Source: Renesas).

Good luck with this project. Be sure to keep Circuit Cellar posted on your progress!

Click here to purchase Circuit Cellar 259.