Compact 20A Hot Swap Controller Integrates MOSFET & Current Sensing

Linear Technology Corp. recently announced the LTC4234, a 20A Hot Swap controller with integrated MOSFET and current sensing, which provides a small footprint hot-plug solution for high-density circuit boards. The LTC4234 ensures safe board insertion and removal from live 2.9-to-15-V backplanes by controlling an internal N-channel power MOSFET to gently power up bulk capacitors and avoid sparks, connector damage and system glitches. By integrating the two most critical and largest Hot Swap components-power MOSFET and sense resistor, the LTC4234 reduces design time and saves board area. The internal, production-tested MOSFET’s safe operating area (SOA) is specified to ensure a rugged hot-plug solution, especially for space-constrained boards and cards in servers, network routers and switches, solid-state drives, and industrial systems.Linear LTC4234

Upon insertion, the LTC4234 waits for connector contact bounce to finish before soft-starting the output. A ground-referenced signal proportional to the load current is provided for monitoring with an external analog-to-digital converter (ADC). The current limit can be reduced from its 22.5A default with a single resistor, affording quick adjustment for dynamic load changes and various applications. For higher current applications, two LTC4234s are easily paralleled for a 40A solution. During overcurrent conditions, the controller limits MOSFET power dissipation by folding back its current limit for an adjustable timeout period. Undervoltage and overvoltage thresholds protect downstream loads against voltages outside a valid window, preventing circuit malfunction and damage.

The LTC4234’s features:

  • Enables safe board insertion
  • Integrated 4-mΩ MOSFET with sense resistor
  • Guaranteed safe operating area
  • Wide operating voltage range of 2.9 to 15 V
  • Current limit for overcurrent fault protection
  • Current and temperature monitor, power good & fault outputs
  • –40°C to 125°C Operating temperature range
  • 38-Pin 5 mm × 9 mm QFN Ppackage

The LTC4234 starts at $4.95 each in 1,000-piece quantities. Device samples and evaluation circuit boards are available online or from your local Linear Technology sales office.

Source: Linear Technology



DIY Network-Ready Polyphonic Music Controller

Hans Peter Portner’s Chimaera project is a touch-less, expressive, network-ready, polyphonic music controller released as open source hardware. It is a mixed analog/digital offspring of the Theremin. An array of analog, linear Hall effect sensors make up a continuous 2-D interaction space. The sensors are excited with Neodymium magnets worn on fingers.

Portner's Chimaera project

Portner’s Chimaera project

The device continuously tracks and interpolates position and vicinity of multiple present magnets along the sensor array to produce corresponding low-latency event signals. Those are encoded as Open Sound Control bundles and transmitted via UDP/TCP to a software synthesizer. The DSP unit is a mixed-signal board and handles sensor read out, event detection and host communication. It is based on an ARM Cortex M4 microcontroller in combination with WIZnet W5500 chip, which takes care of all low-level networking protocols via UDP/TCP.

First Prize — Chimaera: The Poly-Magneto-Phonic Theremin, Hans Peter Portner (Switzerland)

The poly-magneto-phonic Theremin

In his project write-up, Portner explains:

With its touch-less control (no friction), high update rates (2-4 kHz), its quasi-continuous spatial resolution and its low-latency (<1 ms), the Chimaera can react to most subtle motions instantaneously and allows for a highly dynamic and expressive play. Its open source design additionally gives the user all possibilities to further tune hardware and firmware to his or her needs. The Chimaera is network-oriented and configured with and communicated by Open Sound Control, which makes it straight-forward to integrate into any setup.

The hardware of the Chimaera consists of two types of printed circuit boards and an enclosure. Multiple sensor units are daisy-chained to form the sensor array and connected to a single digital signal processing (DSP) unit.

Sensor unit

Sensor unit

A single sensor unit consists of 16 linear hall-effect sensors spaced 5mm apart and routed to a single output through a 16:1 multiplexer which is switched by the DSP unit. Downstream the multiplexer, the analog signal runs through an amplification circuitry.

A modular hardware design consisting of identical sensor units and a single DSP unit embedded in a wooden case allows building devices with array sizes of 16-160 sensors.
A modular hardware design consisting of identical sensor units and a single DSP unit embedded in a wooden case allows building devices with array sizes of 16-160 sensors.

The DSP unit is a mixed-signal board and handles sensor read out, event detection and host communication. It is based on an STM32F303Cx ARM Cortex M4 microcontroller in combination with WIZnet W5500, a hardwired 100Mbit IPv4/PHY chip taking care of all low-level networking protocols via UDP/TCP. The board’s analog part features 10 analog inputs providing connection points for the sensor units, leading to a maximally possible array of 160 sensors. Those analog inputs connect directly to three in parallel running 12bit analog-to-digital converters.

Schematic of the DSP unit (STM32F303Cx part)

Schematic of the DSP unit (STM32F303Cx part)

Networking technology in a zero configuration setup has advantages in respect to long-distance transmission, operating system independence and inherent ability for network performances. We thus use the Open Sound Control (OSC) specification via UDP/TCP as low-level communication layer.

Schematic of the DSP unit (WIZnet W5500 part)

Schematic of the DSP unit (WIZnet W5500 part)

Portner’s project won First Prize in the WIZnet Connect the Magic 2014 Design Challenge. The entire project and its associated files are now available.

Eco-Friendly Home Automation Controller

The 2012 DesignSpark chipKIT Challenge invited engineers from around the world to submit eco-friendly projects using the Digilent chipKIT Max32 development board. Manuel Iglesias Abbatemarco of Venezuela won honorable mention with his autonomous home-automation controller. His design enables users to monitor and control household devices and to log and upload temperature, humidity, and energy-use sensor data to “the cloud” (see Photo 1).

The design comprised a Digilent chipKIT board (bottom), my MPPT charger board (chipSOLAR, middle), and my wireless board (chipWIRELESS, top).

Photo 1: The design comprised a Digilent chipKIT board (bottom), my MPPT charger board (chipSOLAR, middle), and my wireless board (chipWIRELESS, top).

The system, built around the chipKIT Arduino-compatible board, connects to Abbatemarco’s custom-made “chipSOLAR” board that uses a solar panel and two rechargeable lithium-ion (Li-on) cells to provide continuous power. The board implements a maximum power point tracking (MPPT) charger that deals with a solar panel’s nonlinear output efficiency. A “chipWIRELESS” board integrating a Quad Band GSM/GPRS modem, an XBee socket, an SD card connector, and a real-time clock and calendar (RTCC) enables home sensor and cloud connectivity. The software was written using chipKIT MPIDE, and the SD card logs the data from sensors.

“Since the contest, I have made some additions to the system,” Abbatemarco says. “The device’s aim is uninterrupted household monitoring and control. To accomplish this, I focused on two key features: the power controller and the communication with external devices (e.g., sensors). I used DesignSpark software to create two PCBs for these features.”

Abbatemarco describes his full project, including his post-contest addition of a web server, in his article appearing in Circuit Cellar’s May issue. In the meantime, you’ll find descriptions of his overall design, power management board, and wireless board in the following article excerpts.

The system’s design is based on a Digilent chipKIT Max32 board, which is an Arduino-compatible board with a Microchip Technology 32-bit processor and 3.3-V level I/O with almost the same footprint as an Arduino Mega microcontroller. The platform has all the computational power needed for the application and enough peripherals to add all the required external hardware.

I wanted to have a secure and reliable communication channel to connect with the outside world, so I incorporated general packet radio service (GPRS). This enables the device to use a TCP/IP client to connect to web services. It can also use Short Message Service (SMS) to exchange text messages to cellular phones. The device uses a serial port to communicate with the chipKIT board.

I didn’t want to deal with cables for the internal-sensor home network, so I decided to make the system wireless. I used XBee modules, as they offer a good compromise between price and development time. Also, if properly configured, they don’t consume too much energy. The XBee device uses a serial port to communicate with the chipKIT board.
To make the controller”green,” I designed a power-management board that can work with a solar panel and several regulated DC voltages. I chose a hardware implementation of an MPPT controller because I wanted to make my application as reliable as possible and have more software resources for the home controller task.

One board provides power management and the other enables communication, which includes additional hardware such as an SD card, an XBee module, and an RTCC. Note: I included the RTCC since the chipKIT board does not come with a crystal oscillator. I also included a prototyping area, which later proved to be very useful.

I was concerned about how users inside a home would interact with the device. The idea of a built-in web server to help configure and interact with the device had not materialized before I submitted the contest entry. This solution is very practical, since you can access the device through its built-in server to configure or download log files while you are on your home network.

To make the system eco-friendly, I needed to enable continuous device operation using only a solar panel and a rechargeable Li-ion battery. The system consumes a considerable amount of power, so it needed a charge controller. Its main task was to control the battery-charging process. However, to work properly, it also had to account for the solar panel’s characteristics.

A solar panel can’t deliver constant power like a wall DC adapter does. Instead, power varies in a complex way according to atmospheric conditions (e.g., light and temperature).
For a given set of operational conditions, there is always a single operating point where the panel delivers its maximum power. The idea is to operate the panel in the maximum power point regardless of the external conditions.

I used Linear Technology’s LT3652 MPPT charger IC, which uses an input voltage regulation loop. The chip senses the panel output voltage and maintains it over a value by adjusting the current drawn. A voltage divider network is used to program the setpoint.
You must know the output voltage the panel produces when operated at the maximum power point. I couldn’t find the manufacturer’s specification sheet for the solar panel, but the distributor provides some experimental numbers. Because I was in a hurry to meet the contest deadline, I used that information. Based on those tests, the solar panel can produce approximately 8 V at 1.25 A, which is about 10 W of power.

I chose 8 V as the panel’s maximum power point voltage. The resistor divider output is connected to the LT3652’s VIN_REG pin. The chip has a 2.7-V reference, which means the charge current is reduced when this pin’s voltage goes below 2.7 V.

I used a two-cell Li-ion battery, but since the LTC3652 works with two, three, and four cells, the same board with different components can be used with a three- or four-cell battery. The LT3652 requires an I/O voltage difference of at least 3.3 V for reliable start-up, and it was clear that the panel’s 8-V nominal output would not be enough. I decided to include a voltage step-up stage in front of the LT3652.

I used Linear Technology’s LT3479 DC/DC converter to get the panel output to around 18 V to feed the MPPT controller. This only works if the LT3562’s voltage control loop still takes the VIN_REG reference directly from the panel output. Figures 1 and 2 show the circuit.

Power management board

Figure 1: Power management board

Figure 2: Power management board

Figure 2: Power management board

I could have fed the chipKIT on-board 5-V linear regulator with the battery, but I preferred to include another switching regulator to minimize losses. I used Linear Technology’s LTC3112 DC/DC converter. The only problem was that I needed to be able to combine its output with the chipKIT board’s 5 V, either through the USB port or the DC wall adapter option.

The chipKIT board includes a Microchip Technology MCP6001 op-amp in comparator configuration to compare USB voltage against a jack DC input voltage, enabling only one to be the 5-V source at a given time. Something similar was needed, so I included a Linear Technology LTC4411 IC, which is a low-loss replacement ORing diode, to solve the problem.

To my knowledge, when I designed the board a battery gauge for two-cell lithium batteries (e.g., a coulomb counter that can indicate accumulated battery charge and discharge) wasn’t available. The available options needed to handle most of the computational things in software, so I decided it was not an option. I included a voltage buffer op-amp to take advantage of the LTC3112’s dedicated analog voltage output, which gives you an estimate of the instantaneous current being drawn. Unfortunately, I wasn’t able to get it to work. So I ended up not using it.

Building this board was a challenge, since most components are 0.5-mm pitch with exposed pads underneath. IC manufacturers suggest using a solid inner ground layer for switching regulators, so I designed a four-layer board. If you have soldering experience, you can imagine how hard it is to solder the board using only a hot air gun and a soldering iron. That’s why I decided it was time to experiment with a stencil, solder paste, and a convection oven. I completed the board by using a commercially available kitchen convection oven and manually adjusting the temperature to match the reflow profile since I don’t have a controller (see Photo 2).

Photo 3: Custom chipSOLAR board

Photo 2: Custom chipSOLAR board

The wireless board has all the components for GPRS communication and the 802.15.4 home network, as well as additional components for the SD file system and the RTCC. Figure 3 shows the circuit.

Figure 3: The communication board schematic is shown.

Figure 3: The communication board schematic is shown.

At the time of the contest, I used a SIMCom Wireless Solutions SIM340 GPRS modem. The company now offers a replacement, the SIM900B. The only physical differences are the board-to-board connectors, but the variations are so minimal that you can use the same footprint for both connectors.

During the contest, I only had the connector for the SIM340 on hand, so I based almost all the firmware on that model. Later, I got the SIM900B connector and modified the firmware. The Project Files include the #if defined clause for SIM900 or SIM340 snippets.

A couple of things made me want to test the SIM900B module, among them the Simple Mail Transfer Protocol (SMTP) server functionality and Multimedia Messaging Service (MMS). Ultimately, I discovered that my 32-MB flash memory version of the SIM900B was not suitable for those firmware versions. The 64-MB version of the hardware is required.
The subscriber identity module (SIM) card receptacle and associated ESD protection circuitry are located on the upper side of the board. The I/O lines connected to the modem are serial TX, RX, and a power-on signal using a transistor.

The chipKIT Max32 board does not have a 32,768-Hz crystal, so Microchip Technology’s PIC32 internal RTCC was not an option. I decided to include Microchip Technology’s MCP79402 RTCC with a super capacitor, mainly for service purposes as the system is already backed up with the lithium battery.

I should have placed the SD card slot on the top of the board. That could have saved me some time during the debugging stage, when I have had some problems with SD firmware that corrupts the SD file system. When I designed the board, I was trying to make it compatible with other platforms, so I included level translators for the SD card interface. I made the mistake of placing a level translator at the master input slave output (MISO), which caused a conflict in the bus with other SPI devices. I removed it and wire-wrapped the I/O lines.

Another issue with this board was the XBee module’s serial port net routing, but it was nothing that cutting some traces and wire wrap could not fix. Photo 3 shows all the aforementioned details and board component location.

Photo 3: This communication board includes several key components to enable wireless communication with sensors,  the Internet, and cellular networks.

Photo 3: This communication board includes several key components to enable wireless communication with sensors,the Internet, and cellular networks.

Editor’s Note: Visit here to read about other projects from the 2012 DesignSpark chipKIT Challenge.

The Future of Monolithically Integrated LED Arrays

LEDs are ubiquitous in our electronic lives. They are widely used in notification lighting, flash photography, and light bulbs, to name a few. For displays, LEDs have been commercialized as backlights in televisions and projectors. However, their use in image formation has been limited.

A prototype emissive LED display chip is shown. The chip includes an emissive compass pattern ready to embed into new applications.

A prototype emissive LED display chip is shown. The chip includes an emissive compass pattern ready to embed into new applications.

The developing arena of monolithically integrated LED arrays, which involves fabricating millions of LEDs with corresponding transistors on a single chip, provides many new applications not possible with current technologies, as the LEDs can simultaneously act as the backlight and the image source.

The common method of creating images is to first generate light (using LEDs) and then filter that light using a spatial light modulator. The filter could be an LCD, liquid crystal on silicon (LCoS), or a digital micromirror device (DMD) such as a Digital Light Processing (DLP) projector. The filtering processes cause significant loss of light in these systems, despite the brightness available from LEDs. For example, a typical LCD uses only 1% to 5% of the light generated.

Two pieces are essential to a display: a light source and a light controller. In most display technologies, the light source and light control functionalities are served by two separate components (e.g., an LED backlight and an LCD). However, in emissive displays, both functionalities are combined into a single component, enabling light to be directly controlled without the inherent inefficiencies and losses associated with filtering. Because each light-emitting pixel is individually controlled, light can be generated and emitted exactly where and when needed.

Emissive displays have been developed in all sizes. Very-large-format “Times Square” and stadium displays are powered by large arrays of individual conventional LEDs, while new organic LED (OLED) materials are found in televisions, mobile phones, and other micro-size applications. However, there is still a void. Emissive “Times Square” displays cannot be scaled to small sizes and emissive OLEDs do not have the brightness available for outdoor environments and newer envisioned applications. An emissive display with high brightness but in a micro format is required for applications such as embedded cell phone projectors or displays on see-through glasses.

We know that optimization by the entire LED industry has made LEDs the brightest controllable light source available. We also know that a display requires a light source and a method of controlling the light. So, why not make an array of LEDs and control individual LEDs with a matching array of transistors?

The marrying of LED materials (light source) to transistors (light control) has long been researched. There are three approaches to this problem: fabricate the LEDs and transistors separately, then bond them together; fabricate transistors first, then integrate LEDs on top; and fabricate LEDs first, then integrate transistors on top. The first method is not monolithic. Two fabricated chips are electrically and mechanically bonded, limiting integration density and thus final display resolutions. The second method, starting with transistors and then growing LEDs, offers some advantages in monolithic (single-wafer) processing, but growth of high-quality, high-efficiency LEDs on transistors has proven difficult.

My start-up company, Lumiode (, is developing the third method, starting with optimized LEDs and then fabricating silicon transistors on top. This leverages existing LED materials for efficient light output. It also requires careful fabrication of the integrated transistor layer as to not damage the underlying LED structures. The core technology uses a laser method to provide extremely local high temperatures to the silicon while preventing thermal damage to the LED. This overcomes typical process incompatibilities, which have previously held back development of monolithically integrated LED arrays. In the end, there is an array of LEDs (light source) and corresponding transistors to control each individual LED (light control), which can reach the brightness and density requirements of future microdisplays.

Regardless of the specific integration method employed, a monolithically integrated LED and transistor structure creates a new range of applications requiring higher efficiency and brightness. The brightness available from integrated LED arrays can enable projection on truly see-through glass, even in outdoor daylight environments. The efficiency of an emissive display enables extended battery lifetimes and device portability. Perhaps we can soon achieve the types of displays dreamed up in movies.

A Timely Look at RFID Technology

Most of us have had that annoying experience of setting off an alarm as we leave a store because one item in our bags has a still-active radio-frequency identification (RFID) tag. So it’s back to the cashier for some deactivation (or to security for some questioning).

Retailers love RFID, for obvious reasons. So do other industries and governments dealing with limiting building access; tracking goods, livestock and people; collecting highway tolls and public transit fares; checking passports; finding airport baggage; managing hospital drug inventory… The list goes on and on.

RFIDRFID is a big business, and it is anticipated to grow despite concerns about privacy issues. Market researcher IDTechEx recently estimated that the RFID market—including tags, readers, and software and services for RFID labels, fobs, cards, and other form factors—will hit $9.2 billion in 2014 and increase to $30.24 billion in 2024.

So it’s good timing for columnist Jeff Bachiochi’s series about passive RFID tagging. Part 1 appears in Circuit Cellar’s May issue and focuses on read-only tags and transponder circuitry. It also hints at Bachiochi’s unfolding RFID project.

Other May issue highlights include DIY project articles describing an MCU-based trapdoor lift system, a customizable approach to an ASCII interface for sending commands to a sensor tool and receiving data, and a solar-powered home automation controller that enables household-device management and cloud connectivity to log temperature, energy use, and other data.

In addition, our columnists explore low-power wireless data receivers, testing and analyzing old and new batteries in a personal collection, and designing data centers to participate in smart-grid power management.

If you are a female engineer in search of some inspiration, read our interview with embedded systems expert Elecia White. Also, find out why new technology means a bright future for LEDs in emissive microdisplays.

An Organized Space for Programming, Writing, and Soldering


Photo 1—This is Anderson’s desk when he is not working on any project. “I store all my ‘gear’ in a big plastic bin with several smaller bins inside, which keeps the mess down. I have a few other smaller storage bins as well hidden here and there,” Anderson explained.


Photo 2—Here is Anderson’s area set up for soldering and running his oscilloscope. “I use a soldering mat to protect my desk surface,” he says. “The biggest issue I have is the power cords from different things getting in my way.”

Al Anderson’s den is the location for a variety of ongoing projects—from programming to writing to soldering. He uses several plastic bins to keep his equipment neatly organized.

Anderson is the IT Director for Salish Kootenai College, a small tribal college based in Pablo, MT. He described some of his workspace features via e-mail:

I work on many different projects. Lately I have been doing more programming. I am getting ready to write a book on the Xojo development system.

Another project I have in the works is using a Raspberry Pi to control my hot tub. The hot tub is about 20 years old, and I want to have better control over what it is doing. Plus I want it to have several features. One feature is a wireless interface that would be accessible from inside the house. The other is a web control of the hot tub so I can turn it on when we are still driving back from skiing to soak my tired old bones.

I am also working on a home yard sprinkler system. I laid some of the pipe last fall and have been working on and off with the controller. This spring I will put in the sprinkler heads and rest of the pipe. I tend to like working with small controllers (e.g., the Raspberry Pi, BeagleBoard’s BeagleBone, and Arduino) and I have a lot of those boards in various states.

Anderson’s article about a Raspberry Pi-based monitoring device will appear in Circuit Cellar’s April issue. You can follow him on Twitter at @skcalanderson.

Client Profile: Invenscience LC

Invenscience2340 South Heritage Drive, Suite I
Nibley UT, 84321

CONTACT: Collin Lewis,

EMBEDDED PRODUCTS: Torxis Servos and various servo controllers

FEATURED PRODUCT: Invenscience features a wide range of unique servo controllers that generate the PWM signal for general RC servomotors of all brands and Torxis Servos. (The Simple Slider Servo Controller is pictured.) Included in this lineup are:

  • Gamer joystick controllers
  • Conventional joystick controllers
  • Equalizer-style slider controllers
  • Android device Bluetooth controllers

All of these controllers provide power and the radio control (RC) PWM signal necessary to make servos move without any programming effort.

EXCLUSIVE OFFER: Use the promo code “CC2014” to receive a 10% discount on all purchases through March 31, 2014.

Circuit Cellar prides itself on presenting readers with information about innovative companies, organizations, products, and services relating to embedded technologies. This space is where Circuit Cellar enables clients to present readers useful information, special deals, and more.

System Safety Assessment

System safety assessment provides a standard, generic method to identify, classify, and mitigate hazards. It is an extension of failure mode effects and criticality analysis and fault-tree analysis that is necessary for embedded controller specification.

System safety assessment was originally called ”system hazard analysis.” The name change was probably due to the system safety assessment’s positive-sounding connotation.

George Novacek ( is a professional engineer with a degree in Cybernetics and Closed-Loop Control. Now retired, he was most recently president of a multinational manufacturer of embedded control systems for aerospace applications. George wrote 26 feature articles for Circuit Cellar between 1999 and 2004.

Columnist George Novacek (, who wrote this article published in Circuit Cellar’s January 2014 issue, is a professional engineer with a degree in Cybernetics and Closed-Loop Control. Now retired, he was most recently president of a multinational manufacturer of embedded control systems for aerospace applications. George wrote 26 feature articles for Circuit Cellar between 1999 and 2004.

I participated in design reviews where failure effect classification (e.g., hazardous, catastrophic, etc.) had to be expunged from our engineering presentations and replaced with something more positive (e.g., “issues“ instead of “problems”), lest we wanted to risk the wrath of buyers and program managers.

System safety assessment is in many ways similar to a failure mode effects and criticality analysis (FMECA) and fault-tree analysis (FTA), which I described in “Failure Mode and Criticality Analysis” (Circuit Cellar 270, 2013). However, with safety assessment, all possible system faults—including human error, electrical and mechanical subsystems’ faults, materials, and even manuals—should be analyzed. The impact of their faults and errors on the system safety must also be considered. The system hazard analysis then becomes a basis for subsystems’ specifications.

Fault Identification

Performing FMECA and FTA on your subsystem ensures all its potential faults become detected and identified. The faults’ signatures can be stored in a nonvolatile memory or communicated to a display console, but you cannot choose how the controller should respond to any one of those faults. You need the system hazard analysis to tell you what corrective action to take. The subsystem may have to revert to manual control, switch to another control channel, or enter a degraded performance mode. If you are not the system designer, you have little or no visibility of the faults’ potential impact on the system safety.
For example, an automobile consists of many subsystems (e.g., propulsion, steering, braking, entertainment, etc.). The propulsion subsystem comprises engine, transmission, fuel delivery, and possibly other subsystems. A part of the engine subsystem may include a full-authority digital engine controller (FADEC).

Do you have an electrical engineering tip you’d like to share? Send it to us here and we may publish it as part of our ongoing EE Tips series.

Engine controllers were originally mainly mechanical devices, but with the arrival of the microprocessor, they have become highly sophisticated electronic controllers. Currently, most engines—including aircraft, marine, automotive, or utility (e.g., portable electrical generator turbines)—are controlled by some sort of a FADEC to achieve best performance and safety. A FADEC monitors the engine performance and controls the fuel flow via servomotor valves or stepper motors in response to the commanded thrust plus numerous operating conditions (e.g., atmospheric and internal pressures, external and internal engine temperatures in several locations, speed, load, etc.).

The safety assessment mostly depends on where and how essentially identical systems are being used. A car’s engine failure, for example, may be nothing more than a nuisance with little safety impact, while an aircraft engine failure could be catastrophic. Conversely, an aircraft nosewheel steer-by-wire can be automatically disconnected upon a fault. And, with a little increase of the pilots’ workload, it may be substituted by differential braking or thrust to control the plane on the ground. A similar failure of an automotive steer-by-wire system could be catastrophic for a car barreling down the freeway at 70 mph.


System safety analysis comprises the following steps: identify and classify potential hazards and associated avoidance requirements, translate safety requirements into engineering requirements, design assessment and trade-off support to the ongoing design, assess the design’s relative compliance to requirements and document findings, direct and monitor specialized safety testing, and monitor and review test and field issues for safety trends.

The first step in hazard analysis is to identify and classify all the potential system failures. FMECA and FTA provide the necessary data. Table 1 shows an example and explains how the failure class is determined.

This table shows the identification and severity classification of all potential system-level failures.
Eliminated Negligible Marginal Critical Catastrophic
No safety impact. Does not significantly reduce system safety. Required actions are within the operator’s capabilities. Reduces the capability of the system or operators to cope with adverse operating conditions. Can cause major illness, injury, or property damage. Significantly reduces the capability of the system or the operator’s ability to cope with adverse conditions to the extent of causing serious or fatal injury to several people. Total loss of system control resulting in equipment loss and/or multiple fatalities.

The next step determines each system-level failure’s frequency occurrence (see Table 2). This data comes from the failure rates calculated in the course of the reliability prediction, which I covered in my two-part article “Product Reliability” (Circuit Cellar 268–269, 2012) and in “Quality and Reliability in Design” (Circuit Cellar 272, 2013).

Use this information to determine the likelihood of each individual system-level failure.
Frequent Probability of occurrence per operation is equal or greater than 1 × 10–3
Probable Probability of occurrence per operation is less than 1 × 10–3 or greater than 1 × 10–5
Occasional Probability of occurrence per operation is less than 1 × 10–5 or greater than 1 × 10–7
Remote Probability of occurrence per operation is less than 1 × 10–7 or greater than 1 × 10–9
Improbable Probability of occurrence per operation is less than 1 × 10–9

Based on the two tables, the predictive risk assessment matrix for every hazardous situation is created (see Table 3). The matrix is a composite of severity and likelihood and can be subsequently classified as low, medium, serious, or high. It is the system designer’s responsibility to evaluate the potential risk—usually with regard to some regulatory requirements—to specify the maximum hazard levels acceptable for every subsystem. The subsystems’ developers must comply with and satisfy their respective specifications. Electronic controllers in safety-critical applications must present low risk due to their subsystem fault.

The risk assessment matrix is based on information from Table 1 and Table 2.
Probability / Severity Catastrophic (1) Critical (2) Marginal (3) Negligible (4)
Frequent (A) High High Serious Medium
Probable (B) High High Serious Medium
Occasional (C) High Serious Medium Low
Remote (D) Serious Medium Medium Low
Improbable (E) Medium Medium Medium Low
Eliminated (F) Eliminated

The system safety assessment includes both software and hardware. For aircraft systems, the required risk level determines the development and quality assurance processes as anchored in DO-178 Software Considerations in Airborne Systems and Equipment Certification and DO-254 Design Assurance Guidance for Airborne Electronic Hardware.

Some non-aerospace industries also use these two standards; others may have their own. Figure 1 shows a typical system development process to achieve system safety.
The common automobile power steering is, by design, inherently low risk, as it continues to steer even if the hydraulics fail. Similarly, some aircraft controls continue to be the old-fashioned cables but, like the car steering, with power augmentation. If the power fails, you just need more muscle. This is not the case with the more prevalent drive- or fly-by-wire systems.

FIGURE 1: The actions in this system-development process help ensure system safety.

FIGURE 1: The actions in this system-development process help ensure system safety.


How can the risk be mitigated to at least 109 probability for catastrophic events? The answer is redundancy. A well-designed electronic control channel can achieve about 105 probability of a single fault. That’s it. However, the FTA shows that by ANDing two such processing channels, the resulting failure probability will decrease to 1010, thus mitigating the risk to an acceptable level. An event with 109 probability of occurring is, for many systems, acceptable as just about “never happening,” but there are requirements for 1014 or even lower probability. Increasing redundancy will enable you to satisfy the specification.
Once I saw a controller comprising three independent redundant computers, with each computer also being triple redundant. Increasing safety by redundancy is why there are at least two engines on every commercial passenger carrying aircraft, two pilots, two independent hydraulic systems, two or more redundant controllers, power supplies, and so forth.

Human Engineering

Human engineering, to use military terminology, is not the least important for safety and sometimes not given sufficient attention. MIL-STD-1472F, the US Department of Defense’s Design Criteria Standard: Human Engineering, spells out many requirements and design constraints to make equipment operation and handling safe. This applies to everything, not just electrical devices.

For example, it defines the minimum size of controls if they may be operated with gloves, the maximum weight of equipment to be located above a certain height, the connectors’ location, and so forth. In my view, every engineer should look at this interesting standard.
Non-military equipment that requires some type of certification (e.g., most electrical appliances) is usually fine in terms of human engineering. Although there may not be a specific standard guiding its design in this respect, experienced certificating examiners will point out many shortcomings. But there are more than enough fancy and expensive products on the market, which makes you wonder if the designer ever tried to use the product himself.

By putting a little thought beyond just the functional design, you can make your product attractive, easy to operate, and safe. It may be as simple as asking a few people who are not involved with your design to use the product before you release it to production.

Test Pixel 1

Member Profile: Walter O. Krawec

Walter O. Krawec

Walter O. Krawec

Upstate New York

Research Assistant and PhD Student, Stevens Institute of Technology

Walter has been reading Circuit Cellar since he got his first issue in 1999. Free copies were available at the Trinity College Fire Fighting Robot Contest, which was his first experience with robotics. Circuit Cellar was the first magazine for which he wrote an article (“An HC11 File Manager,” two-part series, issues 129 and 130, 2001).

Robotics, among other things. He is particularly interested in developmental and evolutionary robotics (where the robot’s strategies, controllers, and so forth are evolved instead of programmed in directly).

Walter is enjoying his Raspberry Pi. “What a remarkable product! I think it’s great that I can take my AI software, which I’ve been writing on a PC, copy it to the Raspberry Pi, compile it with GCC, then off it goes with little or no modification!”

Walter is designing a new programming language and interpreter (for Windows/Mac/Linux, including the Raspberry Pi) that uses a simulated quantum computer to drive a robot. “What better way to learn the basics of quantum computing than by building a robot around one?” The first version of this language is available on his website ( He has plans to release an improved version.

Walter said he is amazed with the power of the latest embedded technology, for example the Raspberry Pi. “For less than $40 you have a perfect controller for a robot that can handle incredibly complex programs. Slap on one of those USB battery packs and you have a fully mobile robot,” he said. He used a Pololu Maestro to interface the motors and analog sensors. “It all works and it does everything I need.” However, he added, “If you want to build any of this yourself by hand it can be much harder, especially since most of the cool stuff is surface mount, making it difficult to get started.”

Client Profile: Digi International, Inc

Contact: Elizabeth Presson

Featured Product: The XBee product family ( is a series of modular products that make adding wireless technology easy and cost-effective. Whether you need a ZigBee module or a fast multipoint solution, 2.4 GHz or long-range 900 MHz—there’s an XBee to meet your specific requirements.

XBee Cloud Kit

Digi International XBee Cloud Kit

Product information: Digi now offers the XBee Wi-Fi Cloud Kit ( for those who want to try the XBee Wi-Fi (XB2B-WFUT-001) with seamless cloud connectivity. The Cloud Kit brings the Internet of Things (IoT) to the popular XBee platform. Built around Digi’s new XBee Wi-Fi
module, which fully integrates into the Device Cloud by Etherios, the kit is a simple way for anyone with an interest in M2M and the IoT to build a hardware prototype and integrate it into an Internet-based application. This kit is suitable for electronics engineers, software designers, educators, and innovators.

Exclusive Offer: The XBee Wi-Fi Cloud Kit includes an XBee Wi-Fi module; a development board with a variety of sensors and actuators; loose electronic prototyping parts to make circuits of your own; a free subscription to Device Cloud; fully customizable widgets to monitor and control connected devices; an open-source application that enables two-way communication and control with the development board over the Internet; and cables, accessories, and everything needed to connect to the web. The Cloud Kit costs $149.

I/O Raspberry Pi Expansion Card

The RIO is an I/O expansion card intended for use with the Raspberry Pi SBC. The card stacks on top of a Raspberry Pi to create a powerful embedded control and navigation computer in a small 20-mm × 65-mm × 85-mm footprint. The RIO is well suited for applications requiring real-world interfacing, such as robotics, industrial and home automation, and data acquisition and control.

RoboteqThe RIO adds 13 inputs that can be configured as digital inputs, 0-to-5-V analog inputs with 12-bit resolution, or pulse inputs capable of pulse width, duty cycle, or frequency capture. Eight digital outputs are provided to drive loads up to 1 A each at up to 24 V.
The RIO includes a 32-bit ARM Cortex M4 microcontroller that processes and buffers the I/O and creates a seamless communication with the Raspberry Pi. The RIO processor can be user-programmed with a simple BASIC-like programming language, enabling it to perform logic, conditioning, and other I/O processing in real time. On the Linux side, RIO comes with drivers and a function library to quickly configure and access the I/O and to exchange data with the Raspberry Pi.

The RIO features several communication interfaces, including an RS-232 serial port to connect to standard serial devices, a TTL serial port to connect to Arduino and other microcontrollers that aren’t equipped with a RS-232 transceiver, and a CAN bus interface.
The RIO is available in two versions. The RIO-BASIC costs $85 and the RIO-AHRS costs $175.

Roboteq, Inc.

Client Profile: Pololu Robotics

Pololu Robotics
920 Pilot Road
Las Vegas, NV 89119


Pololu Robotics Zumo

Pololu Robotics Zumo

Embedded Products/Services: Pololu designs, manufactures, and distributes a variety of robotic and electronic parts. Get the building blocks for your next project at Pololu, where you can find wheels, motors, motion controllers, basic prototyping supplies, sensors, complete robot kits, and more. Pololu also offers a custom laser cutting service starting at $25.

Product information: The Pololu Zumo robot is an Arduino-controllable tracked robot platform that measures less than 10 cm × 10 cm, which is small enough to qualify for Mini Sumo. The Zumo includes two micro-metal gearmotors coupled to a pair of silicone tracks, a stainless steel bulldozer-style blade, six infrared reflectance sensors for line following or edge detection, a three-axis accelerometer and magnetometer, and a buzzer for simple sounds and music. A kit version is also available.

Exclusive offer: Use coupon code ZUMOCC20 for 20% off any one item in Pololu’s Zumo category (

PC-Programmable Temperature Controller

Oven Industries 5R7-388 temperature controller

Oven Industries 5R7-388 temperature controller

The 5R7-388 is a bidirectional temperature controller. It can be used in independent thermoelectric modules or in conjunction with auxiliary or supplemental resistive heaters for cooling and heating applications. The solid-state MOSFET output devices’ H-bridge configuration enables the bidirectional current flow through the thermoelectric modules.
The RoHS-compliant controller is PC programmable via an RS-232 communication port, so it can directly interface with a compatible PC. It features an easily accessible communications link that enables various operational mode configurations. The 5R7-388 can perform field-selectable parameters or data acquisition in a half duplex mode.

In accordance with RS-232 interface specifications, the controller accepts a communications cable length. Once the desired set parameters are established, the PC may be disconnected and the 5R7-388 becomes a unique, stand-alone controller. All parameter settings are retained in nonvolatile memory. The 5R7-388’s additional features include 36-VDC output using split supply, a PC-configurable alarm circuit, and P, I, D, or On/Off control.

Contact Oven Industries for pricing.

Oven Industries, Inc.

G-Code CNC Router Controller

Brian Millier constructed a microcontroller-based, G-code controller for a CNC router. So, we gave the retired instrumentation engineer space to publish a two-part series about his project.

In Part 1 (Millier-CC-2013-04-Issue 273), Millier explains the basics of G-code and how it is converted into three-axis motion, via the router’s three stepper motors. In Part 2, he describes his design of the router’s axis controller (powered by three small microcontrollers) and the host controller (powered by a more powerful microcontroller).

He calls the project one of the most challenging he has ever tackled.

So why bother? Especially when the combination of a PC and ArtSoft’s Mach3 software is a common and affordable approach to running a CNC router? Well, like most DIYers, Millier couldn’t resist an opportunity to learn.

“I want to be upfront and say that this is probably not the most practical project I have ever done,” Millier says in Part 1. “You can usually pick up a used PC for free, and the Mach3 software is professional-grade and handles much more complex G-code programs than my DIY controller will. However, it did provide me with a challenging programming task, and I learned a lot about designing a program with many concurrent tasks, all of which are quite time critical. Even if you are not interested in building such a controller, you may find interesting some of the techniques and tricks I used to provide the multi-axis stepper-motor motion.”

Millier’s two articles focus on the two main tasks of his project.

“The first was to understand the G-code language used to program CNC machines well enough to be able to write the firmware that would parse the G-code commands into something that a microcontroller could use to control the stepper motors used for each of the three axes,” he says. “The second task was to design the hardware/firmware that would actually control the three stepper motors, all of which had to move synchronously at accurate, ramped speeds.”

Millier wraps up his project by saying: “This was probably the most challenging project I’ve tackled, outside of work projects, in many years. In particular, the Basic program code for both of the controllers ran beyond 3,500 lines.”

You can Millier-CC-2013-04-Issue 273. The second article is available via Circuit Cellar’s webshop.