Vehicle Computer Targets Comms + Control

MEN Micro has announced the BC50R, a maintenance-free box computer that has been designed for data acquisition applications in rugged environments in vehicles such as trains, commercial vehicles, mobile machines or ships. All interfaces are implemented on rugged M12 connectors (USB, digital input and output, Gigabit Ethernet, CAN and legacy serial I/O). The housing is compliant to the IP65 protection class.

On the inside, the system offers two PCI Express Mini card slots with two SIM card slots for WLAN, GNSS or 3G/4G functionality. The necessary antenna connectors can be made available at the front panel. It is powered by an AMD Embedded G-Series APU (Accelerated Processing Unit), the T48N, running at 1.4 GHz. The use of the Embedded G-Series makes for high scalability in CPU (single/dual core) performance. The BC50R is equipped with 2 GB of DDR3 SDRAM and offers SD card and mSATA slots. The system is designed for fanless operation at temperatures from -40 to +70°C (+85°C for up to 10 minutes), its special aluminum housing with cooling fins serves as a heat sink for the internal electronics and in this way provides conduction cooling.

The BC50R supports a 24 VDC and 36 VDC nom. class S2 power supply in compliance with EN 50155 or power supplies which comply with ISO 7637-2 (E-mark for automotive) (nominal input voltage 24 V) or with EN 60945 (ship). The power can be switched on and off using an ignition signal on the power connector, and a shutdown-delay time after switching off the power can be adjusted by software.

The combination of the various CPU/GPU options with the available selection of external interfaces (realized via separate graphics and I/O interface boards within the system) makes for an flexible system design that can quickly be tailored to a wide variety of applications.

MEN Micro |

DIY Dead Man’s Switch (No Microcontrollers)

A “dead man’s switch” (abbreviated here as DMS) is a very useful device for applications where the effect of forgetting to turn something off ranges from a mild annoyance to costly or dangerous consequences. We first learned about the DMS from a locomotive engineer, who explained vividly that an engineer is supposed to press a button every minute to keep the locomotive going, otherwise the machine stops. Less “dramatic” applications include turning off lights or other equipment after a period of time.

The ideal DMS provides several minutes of “on” time, requires no programming, external controls, additional power supplies and no modifications of the existing equipment. In effect, no changes should occur in the standard operating procedures of using the equipment. To reset the timer from “off” back to “on,” it is desirable to either use a button or just cycle the power.

Ironically, a multitude of electronic timers available online or at home improvement retail stores are highly over-engineered. These timers either require programming of specific date-times to be “ON” or have very long pre-sets, require changes in equipment wiring, etc.


This article presents a DMS design that has been tested and currently in use in two different systems. One is controlling a UV source and another is controlling a hydrogen gas line valve. If someone forgets to turn off the UV source, the repairs are costly. When it comes to forgetting to turn off hydrogen, a violent explosion may happen!

The DMS works as follows. First, there are no microcontrollers—just plain physics. Capacitors C1 (bipolar, electrolytic) and C2 make a voltage divider (see Figure 1). Note this timer was originally designed for the European voltage; however, it is very simple to recalculate the capacitor divider for the US voltage.

Figure 1: This is the timer schematic. The Reset button S1 is optional.

Figure 1: This is the timer schematic. The Reset button S1 is optional.

The voltage is rectified by a bridge and smoothed by C3. The voltage on C3 is approximately 13 V. When the timer is powered on, both capacitors C4 and C5 are quickly charged each to a half of the supply voltage. FET is turned on and relay is engaged. At the same time, the charge begins a slowly redistribution between the capacitors, with C5 discharging via R3 and C4 further charging. Note that diode D1 is not conducting. When C5 is discharged enough, FET is turned off. This causes the relay to disengage. The timer will continue to be in this state as long as the power is provided, because C4 is effectively blocking any current flow. If the power is removed, D1 opens up to discharge C4 via R2. Remember: C5 is already discharged. Thus, the timer is reset to its initial condition. In addition, a manual reset switch S1 is added in case if it is more convenient to reset the timer by pushing a button rather than briefly disconnecting the mains power.


With the indicated components, the “on” time is for approximately 6 minutes. Changing C4 and C5 adjusts the “on” time. Our hydrogen valve control system uses capacitances of 30 µF each, resulting in approximately 25 minutes of “on” time. Note that the capacitances of C4 and C5 must be the same.


Dr. Alexander Pozhitkov has an MS in Chemistry and a PhD in Genetics from Albertus Magnus University in Cologne, Germany. For 12 years he has been involved with interdisciplinary research relating to molecular biology, physical chemistry, software, and electrical engineering. Currently, Dr. Pozhitkov is a researcher at the University of Washington, Seattle. His technical interests include hardware programming, vacuum tubes, and high-voltage electronics.

Hans-Joachim Hamann is a staffer at the Max Planck Institute for Evolutionary Biology.


Member Profile: Scott Weber

Scott Weber

Scott Weber

Arlington, Texas, USA

Scott said he started his Circuit Cellar subscription late in the last century. He chose the magazine because it had the right mix of MCU programming and electronics.

He has always enjoyed mixing discrete electronic projects with MCUs. In the early 1980s, he built a MCU board based on an RCA CDP1802 with wirewrap and programmed it with eight switches and a load button.

Back in the 1990s, Scott purchased a Microchip Technology PICStart Plus. “I was thrilled at how powerful and comprehensive the chip and tools were compared to the i8085 and CDP1802 devices I tinkered with years before,” he said.

Scott said he recently treated himself to a brand-new Fluke 77-IV multimeter.

Scott is building devices that can communicate through USB to MS Windows programs. “I don’t have in mind any specific system to control, it is something to learn and have fun with,” he said. “This means learning not only an embedded USB software framework, but also Microsoft Windows device drivers.”

“Embedded devices are popping up everywhere—in places most people don’t even realize they are being used. It’s fun discovering where they are being applied. It is so much easier to change the microcode of an MCU or FPGA as the unit is coming off the assembly line than it is to rewire a complex circuit design,” Scott said.

“I also like Member Profile Joe Pfeiffer’s final comment in Circuit Cellar 276: Surface-mount and ASIC devices are making a ‘barrier to entry’ for the hobbyist. You can’t breadboard those things! I gotta learn a good way to make my own PCBs!”

Web-Based Remote I/O Control

The RIO-2010 is a web-based remote I/O control module. The Ethernet-ready module is equipped with eight relays, 16 photo-isolated digital inputs, and a 1-Wire interface for digital temperature sensor connection. The RIO-2010’s built-in web server enables you to access the I/O and use a standard web browser to remotely control the RIO-2010’s relay.

The RIO-2010 can be easily integrated into supervisory control and data acquisition (SCADA) and industrial automation systems using the standard Modbus TCP protocol. The I/O module also comes with RS-485 serial interface for applications requiring Modbus RTU/ASCII. Its built-in web server enables you to use standard web-editing tools and Ajax dynamic page technology to customize your webpage.

Contact Artila for pricing.

Artila Electronics Co., Ltd.

Low-Cost, High-Performance 32-bit Microcontrollers

The PIC32MX3/4 32-bit microcontrollers are available in 64/16-, 256/64-, and 512/128-KB flash/RAM configurations. The microcontrollers are coupled with Microchip Technology’s software and tools for designs in connectivity, graphics, digital audio, and general-purpose embedded control.

The microcontrollers offer high RAM memory options and high peripheral integration at a low cost. They feature 28 10-bit ADCs, five UARTS, 105-DMIPS performance, serial peripherals, a graphic display, capacitive touch, connectivity, and digital audio support.
The PIC32MX3/4 microcontrollers are supported with general software development tools, including Microchip Technology’s MPLAB X integrated development environment (IDE) and the MPLAB XC32 C/C++ compiler.

Application-specific tools include the Microchip Graphics Display Designer X and the Microchip Graphics Library, which provide a visual design tool that enables quick and easy creation of graphical user interface (GUI) screens for applications. The microcontrollers are also supported with a set of Microchip’s protocol stacks including TCP/IP, USB Device and Host, Bluetooth, and Wi-Fi. For digital audio applications, Microchip provides software for tasks such as sample rate conversion (SRC), audio codecs—including MP3 and Advanced Audio Coding (AAC), and software to connect smartphones and other personal electronic devices.

The PIC32MX3/4 family is supported by Microchip’s PIC32 USB Starter Kit III, which costs $59.99 and the PIC32MX450 100-pin USB plug-in module, which costs $25 for the modular Explorer 16 development system. Pricing for the PIC32MX3/4 microcontrollers starts at $2.50 each in 10,000-unit quantities.

Microchip Technology, Inc.

MCU-Based Prosthetic Arm with Kinect

James Kim—a biomedical student at Ryerson University in Toronto, Canada—recently submitted an update on the status of an interesting prosthetic arm design project. The design features a Freescale 9S12 microcontroller and a Microsoft Kinect, which tracks arm movements that are then reproduced on the prosthetic arm.

He also submitted a block diagram.

Overview of the prosthetic arm system (Source: J. Kim)

Kim explains:

The 9S12 microcontroller board we use is Arduino form-factor compatible and was coded in C using Codewarrior.  The Kinect was coded in C# using Visual Studio using the latest version of Microsoft Kinect SDK 1.5.  In the article, I plan to discuss how the microcontroller was set up to do deterministic control of the motors (including the timer setup and the PID code used), how the control was implemented to compensate for gravitational effects on the arm, and how we interfaced the microcontroller to the PC.  This last part will involve a discussion of data logging as well as interfacing with the Kinect.

The Kinect tracks a user’s movement and the prosthetic arm replicates it. (Source: J. Kim, YouTube)

The system includes:

Circuit Cellar intends to publish an article about the project in an upcoming issue.

Member Profile: Richard Lord

Richard Lord is an engineer, author, and photographer whose article series on an innovative digital camera controller project will begin in the October issue of Circuit Cellar.  Lord’s Photo-Pal design is an electronic flash-trigger camera controller built around a Microchip Technology PIC16F873. It features four modes of operation: triggered shutter, triggered flash, multiple flash, and time lapse. Now you too can take sound-triggered photos.

The Photo-Pal enables Richard to take amazing photos like this and capture high-speed action.

  • Member Name: Richard H. Lord
  • Location: Durham, NH, United States
  • Education: BS Electrical Engineering 1969, MS Biomedical Engineering, 1971
  • Occupation: Retired electronics hardware design engineer
  • Member Status: Richard said he has subscribed to Circuit Cellar for at least 14 years, maybe longer.
  • Technical Interests: Richard’s interests include photography, model railroading, and microcontroller projects.
  • Most Recent Embedded Tech-Related Purchase: Richard’s most recent purchase was a Microchip Technology dsPIC30F4013 digital signal controller.
  • Current Project: Richard is working on a Microchip PIC16F886-based multipurpose front panel interface controller.
  • Thoughts on the Future of Embedded Technology: “With the ready availability of prepackaged 32-bit processor modules, it’s easy to forget there are many applications where 8-bit controllers are more appropriate”, Richard said. He continued by saying he gets a lot of enjoyment from the challenge of working within the capabilities and constraints of the smaller microcontrollers.

DIY 10.1˝ Touchscreen Home Control System

Domotics (home automation) control systems are among the most innovative and rewarding design projects creative electrical engineers can undertake. Let’s take a look at an innovative Beagle Board-based control system that enables a user to control lights with a 10.1˝ capacitive touchscreen.

Domotics control system

The design features the following modules:

• An I/O board for testing purposes
• An LED strip board for controlling an RGB LED strip
• A relay board for switching 230-VAC devices
• An energy meter for measuring on/off (and also for logging)

ELektor editor and engineer Clemens Valens recently interviewed Koen van Dongen about the design. Van Dongen describes the system’s electronics and then demonstrates how to use the touchscreen to control a light and LED strip.

As Valens explains suggests, it would be a worthwhile endeavor to incorporate a Wi-Fi connection to enable cellphone and tablet control. If you build such system, be sure to share it with our staff. Good luck! is an KCK Media website.

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.

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.

MCU-Based “PHOTO-PAL” Camera Controller

A while back, I designed a camera and flash control device that will be the subject of a future Circuit Cellar magazine article.  This device, which I affectionately call Photo-Pal, allows me to use sound (or a contact closure) to trigger a high-speed electronic flash after a user specified delay. The device consists of a microphone amplifier, a Microchip Technology PIC16F873A microcontroller, a 2 × 16 character LCD, and six pushbuttons for the user interface. Delay from sound trigger input to flash trigger output can be adjusted from 1 to 59,999 ms.

The Photo-Pal design (Source: R. Lord)

The high-speed photos are taken in complete darkness with the flash as the only light source for the photo.  The Photo-Pal device also controls the camera shutter. Once the room lights have been turned off, an “arm” push button input causes Photo-Pal to remotely press the camera shutter button, causing the camera shutter to open. The sound trigger input is also enabled. The triggering sound then starts a delay countdown, which then triggers the flash output. Once the flash has fired, the Photo-Pal then releases the camera shutter. 

For the last several months, I have been experimenting with using Photo-Pal to freeze the action of a light bulb being shattered by a hammer, water droplets rebounding from a surface, and eggs being shattered by a pellet from a BB gun.

The BB gun timing setup (Source: R. Lord)


For the photos using the BB gun to smash an egg, I needed to make a cradle to hold the gun so that each shot would be aimed at the same location. I also needed to establish how long it took for the pellet to reach the egg.

An egg hit by a BB (Source: R. Lord)

To make the measurement, I bolted three sheets of plastic together and drilled a large “target” hole. I then sandwiched two sheets of aluminum foil between the three sheets of plastic so that the two foil layers were separated. The microphone for the Photo-Pal was attached to the cradle so that it would be triggered when the BB gun was fired. My oscilloscope was triggered by the Photo-Pal flash output with delay set at 0, and the interval was measured between the time of the trigger output and the moment when the two sheets of aluminum foil were shorted together by the pellet passing through them. With the target set 4 feet from the muzzle of the BB gun, this time interval was measured to be 25 ms. For the egg photographs, I added another 20 ms to the delay so that the flash would catch the egg in mid-burst, after it had started to fly apart. The 45-ms delay was then programmed into Photo-Pal for the photos.

Egg smashed and sound-triggered flash (Source: R. Lord)


The Photo-Pal device has several other modes of operation where it can produce a burst of flash outputs for a stroboscopic effect, or can activate the camera’s shutter from sound or at periodic intervals for time lapse photographs. As you can see, the Photo-Pal device is a useful photography tool that also can be a lot of fun to play with.

Richard Lord holds a B.S. in Electrical Engineering and an M.S. in Biomedical Engineering. During his career, he has designed digital electronics for an aerospace company and several telecommunication test equipment manufacturers. Working as a consultant in the 1980s, Richard designed several medical pulmonary test instruments and the electronics for an autonomous underwater robot. His 2011 article “Panning Control: A Digital Indexing Panoramic Tripod Head” appeared in Circuit Cellar 248.

Editor’s note: Do you have an article or tutorial you’d Circuit Cellar to consider for publication? Do you want to share photos of your personal electronics workspace, hackspace, or “circuit cellar”? Click here to submit your proposal. Write “Submission” or “Proposal” in the subject line of your email.

Radiant Floor Heating Zone Controller Project

Even if you aren’t interested in designing a radiant floor zoned heating system, you can study this innovative project and apply what you learn to any number of building control and automation applications. Dalibor Zaric’s Radiant Floor Heating Zone Controller is built around an NXP Semiconductors LPC2134 ARM processor that’s connected to an Echelon Pyxos chip. The project won Second Place in Echelon’s 2007 “Control Without Limits” design competition.

The heat zone controller system (Source: Echelon & Dalibor Zaric)

Zaric provides the following details in his project documentation:

“• Power supply to unit is 24VAC and controller has switching power supply to provide 24VDC for Pyxos network as well 5V for logic, there is 3.3V linear regulator as well.

• There are four relay with 24VAC output to power up thermoelectric zone valve on radiant floor heating manifold. These outputs are protected with 1.85A self resetting fuse to prevent overloading. This block has as well 24VAC/DC dry contact to provide a call for heat to boiler or optional zones pump.

• Pyxos power supply filter and Pyxos chip provides Pyxos network connection for future sensors and thermostats. Pyxos thermostat will be more cost effective than regular LONWorks sensors/thermostats.

• RS-485 driver will provide future Modbus connection for local touch screens or smart home systems with Modbus connections. There is end of line resistors enabled with the dip switches beside connector.

• 3150 Neuron board with 64K flash provides LONWorks connection to the controller.”


The heat zone controller diagram (Source: Echelon & Dalibor Zaric)

For more information about Pyxos technology, visit

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


Solid-State Lighting Solutions Project

Electronics system control, “green design,” and energy efficiency are important topics in industry and academia. Here we look at a project from San Jose-based Echelon Corp.’s 2007 “Control Without Limits” design competition. Designers were challenged to implement Pyxos technology in innovative systems that reduced energy consumption. Daryl Soderman and Dale Stepps (of INTELTECH Corp.) took First Prize for their Solid State Lighting Solutions project.

The Pyxos chip is on the board (Source: Echelon & Inteltech)

So, how does it work? Using the Pyxos FT network protocol, this alternative lighting project is a cost-effective, energy-efficient solution that’s well-suited for use in residential, commercial, or public buildings. You can easily embed the LED lighting and control system—which features SSL lighting, a user interface, motion detectors, and light sensors—in an existing network. In addition, you can control up to five zones in a building by using the system’s fully programmable ESB-proof touchpad.

Another view of the Pyxos chip is on the board (Source: Echelon & Inteltech)


For more information about Pyxos technology, visit

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