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.