August Circuit Cellar: A Sneak Preview

The August (325) issue of Circuit Cellar magazine is jammed packed with useful technical information and inspiring, intriguing embedded electronics design stories.

Not a Circuit Cellar subscriber?  Don’t be left out! Sign up today:


Here’s a sneak preview of August Circuit Cellar:


Digital Guitar Amplifier/ Effects Processor—Part 2
Brian Millier details the digital guitar amplifier/effects unit he built using two Teensy Arduino modules.

A Range of Power Supplies for Hollow-State Guitar Amplifiers
Richard Honeycutt compares several different power supplies used for hollow-state guitar amplifiers.


Firmware Upgrade with the PIC32
Nick Sicalides delves into performing firmware upgrades using a bootloader on the Microchip PIC32

Getting Started with PSoC Microcontrollers (Part 2): Putting PSoC to Work
Nishant Mittal goes even deeper on the Cypress PSoC providing some useful design examples.

Moore’s Law and the Chip Industry’s Perfect Storm
In this Interview Q&A Krste Asanovic explains RISC-V and the open sourcing of processor architecture.


Power Analysis of a Software DES Encryption Routine
Columnist Colin O’Flynn examines how to break a software implementation of the DES security routine.

Reliability and Failure Prediction: A New Take
Craig Armenti and Dave Wiens discuss a better way to simulate PCB vibration and acceleration.

Preventing Unwanted Entry
Columnist Jeff Bachiochi takes us inside his exploration of electronic lock systems, getting down to the fine details.

Future of Embedded Security: Wi-Fi to the Danger Zone
This guest essay by Adam Cecchetti, CEO of Deja vu Security, explains how memory leaks in your embedded system could have life or death consequences.


Automatic Control (Part 4) The Implementation
George Novacek describes the PID temperature controller he built for a meat smoker.

Fully Differential Amplifiers
Robert Lacoste sings the praises of fully differential amplifiers and presents a few designs using them.

Build an Embedded Systems Consulting Company (Part 5) Axiom Wrap-Up
Bob Japenga shares more insights on running a successful embedded design firm built to last.

Circuit Cellar Newsletters to Focus on Microcontrollers, IoT and More

Circuit Cellar’s ongoing mission is to provide important information to help you make smart choices with your engineering projects—from prototype to production. As part of that effort, we’re now offering themed newsletter content each week that focuses on critical areas of system development.

Already a Circuit Cellar Newsletter subscriber? Great!
You’ll get the first “Microcontroller Watch” themed newsletter issue tomorrow.

Not a Circuit Cellar Newsletter subscriber?
Don’t be left out! Sign up now:

Our new enhanced weekly CC Newsletter will switch its theme each week, covering these four areas every month:

Microcontroller Watch. This newsletter keeps you up-to-date on latest microcontroller news. In this section, we examine the microcontrollers along with their associated tools and support products.

IoT Technology Focus. The Internet-of-Things (IoT) phenomenon is rich with opportunity. This newsletter tackles news and trends about the products and technologies needed to build IoT implementations and devices.

Embedded Boards. This content looks at embedded board-level computers. The focus here is on modules (e.g., Arduino, Raspberry Pi, COM Express, and other small-form-factor modules) that ease prototyping efforts and let you smoothly scale up production volumes.

Analog & Power. This newsletter content zeros in on the latest developments in analog and power technologies including DC-DC converters, AD-DC converters, power supplies, op-amps, batteries, and more.

Expansion Connector Sample Kits Target Makers

Samtec has announced the release of four unique Expansion Connector Sample Kits for Makers. These new kits allow continued growth and stacking of the most popular electronics platforms using standard 0.100″ (2.54mm) centerline IDC cables, sockets and headers. Rapid prototyping of innovative projects using open-source electronic platforms typically requires basic connectors and cable assemblies.

Samtec RasberryPi3Kit

Samtec has developed Expansion Connector Sample Kits for four of the most popular platforms:

  • Arduino Uno R3 Expansion Connector Sample Kit
  • BeagleBone Black Expansion Connector Sample Kit
  • ARM mbed Application Board Expansion Connector Sample Kit
  • Raspberry Pi 3 Expansion Connector Sample Kit

Samtec |

Interview: Massimo Banzi, Codeveloper of Arduino

It’s no secret that the Arduino development board has changed the way we look at working with electronics. All over the world, the little board has enabled millions of engineers, students, artists, and makers to get electronics projects up and going. We recently traveled to DotDotDot in Milan, Italy, to chat with Arduino codeveloper Massimo Banzi, who talked about the history of Arduino, the importance of makerspaces, and more.

Watch the video

Mouser Stocks STM32 LoRaWAN Discovery Board

Mouser Electronics currently offers the STMicroelectronics STM32 LoRaWAN Discovery Board. The new Discovery Kit and I-NUCLEO-LRWAN1 STM32 LoRa Arduino-compatible extension board (available to order from Mouser) offer you a development platform for learning and evaluating solutions based on LoRa and FSK/OOK radio frequency (RF) communication.Mouser_STSTM32LoRaWAN

The ST STM32 LoRaWAN Discovery Kit is based on an all-in-one Murata Type ABZ open module solution to address low-power wide area networks (LPWAN) and support the LoRaWAN long-range wireless protocol. An STM32L072 ARM Cortex-M0+ microcontroller—featuring 192 KB of flash memory, 20 KB of RAM, and 6 KB of EEPROM—powers the Type ABZ mdoule. The STM32L0 ultra-low-power microcontroller offers low-power design features, targeting battery-powered and energy-harvesting applications.

ST’s I-NUCLEO-LRWAN1 STM32 LoRa extension board includes a LoRaWAN module powered by an STM32L052 microcontroller, an SMA connector, a 50-Ω antenna, and headers compatible with Arduino Uno R3 boards. The board features three ST environmental sensors: an LSM303AGR accelerometer and magnetometer, an HTS221 relative humidity and temperature sensor, and an LPS22HB pressure sensor.

Both the Discovery board and NUCLEO board come with LoRaWAN class A-certified I-CUBE-LRWAN embedded software that enables designers to set up a complete LoRaWAN node.

Source: Mouser Electronics

Arduino-Based Liquid Level-Sensing Hardware

SST Sensing and Sparkfun recently developed an easy-to-use solution for single-point liquid detection using infrared technology. Highly accurate and reliable, the solution features an Optomax Digital liquid level switch, which is connected to an Arduino board via the TTL output and powered by the 5-V source. SST Sparkfun

Whether you’re a professional engineer or DIYer, you’ll find it easy to program the Arduino’s LEDs to indicate when the sensor is immersed in liquid (and thus determine if the liquid level is too high or low). The compact switch lends itself will to space-constrained applications. With long cabling, you can place the sensor near a liquid without putting the other electronics at risk. Since this is an optical solution, you can avoid a variety of issues (e.g., jamming and wear and tear) and ensure long operational lifespan.

SST offers the liquid level switch in a robust housing tip with either a Polysulfone or Trogamid construction (depending on the particular application requirements). The complete solution has an operational temperature range of –25°C to 80°C.

Source: SST

Arduino Program Timing

Ed Nisely explains how output pulses can reveal the progress of invisible firmware routines. After presenting a straightforward way to instrument your code, he covers the detailed timing produced by Arduino statements and functions.

While writing the Arduino program for the RGB LED lights mentioned in my May column (Circuit Cellar 310), I wondered how much time the floating-point trigonometric calculations required. Rather than wrap a software measurement around the code, I added a pair of instructions to flip an output bit, then watched the results on an oscilloscope. It’s a classic technique that helps you debug software when there’s no other way to see what’s going on inside your code or when elaborate tracing routines will disturb the firmware’s normal operation.

In this column, I’ll show a simple way to instrument your code, then take a look at the detailed timing produced by Arduino statements and functions. You’ll need an oscilloscope or logic analyzer for this technique, but even the least-expensive instruments will suffice.


Listing 1 shows the simplest Arduino program that produces a visible output. Those two lines toggle Pin 13, the LED found on nearly all Arduino boards, to form the 5.1 µs pulses in Photo 1, with each pulse marking one iteration of the loop() that executes continuously after finishing the configuration in the setup() section. Although the oscilloscope cursor readout provides three fractional digits, the true resolution is considerably worse, because each horizontal pixel covers 0.040 µs.

LISTING 1: The simplest possible Arduino program produces a single pulse on an output bit during each loop() iteration. Although the ATmega328 microcontroller can flip a bit with a single assembly language instruction, each of these high-level functions executes dozens of assembly instructions before and after the bit changes.

LISTING 1: The simplest possible Arduino program produces a single pulse on an output bit during each loop() iteration. Although the ATmega328 microcontroller can flip a bit with a single assembly language instruction, each of these high-level functions executes dozens of assembly instructions before and after the bit changes.

The Atmel ATmega328 microcontroller can toggle an output bit with a single instruction, which makes the digitalWrite() function in the Arduino runtime infrastructure seem overly elaborate: fifteen lines of code with a path length of 12 lines. Among other tasks, the code must select and verify the hardware port, produce a bitmask selecting the pin, handle the special case of a PWM pin, and disable interrupts while manipulating the port.

PHOTO 1 Each of the digitalWrite() functions producing this pulse requires 5.1 µs, roughly 50 instructions, on the 16 MHz ATmega328 microcontroller. The Arduino loop() adds 0.40 µs to the low portion of the waveform.

PHOTO 1: Each of the digitalWrite() functions producing this pulse requires 5.1 µs, roughly 50 instructions, on the 16 MHz ATmega328 microcontroller. The Arduino loop() adds 0.40 µs to the low portion of the waveform.

Homework: Find and examine the digitalWrite() function in the Arduino source code, then explain why all that additional logic isn’t optional.

The single AVR machine-level instruction that produces the waveform in Photo 1 is located near the end of the digitalWrite() function, with most of the execution time occurring before the output changes. The high part of the pulse therefore includes the short tail end of the first digitalWrite() and the longer beginning of the second, but the output pulse width shows the execution time through the complete function.

The 16 MHz crystal oscillator on the Arduino UNO clone board I used for these measurements produces a 62.5 ns instruction cycle, so each 5 µs pulse contains about 80 cycles. Most AVR arithmetic instructions require one or two cycles, branches require two or three, and subroutine CALL/RETURN pairs soak up eight, so assuming 1.6 cycles/instruction for short subroutines seems reasonable and allows you to figure the results in your head: 10 instructions per microsecond. That means the compiler translates the dozen high-level lines of code in the digitalWrite() function into 50 machine-level instructions.

Homework: Examine the compiler’s machine-level output to determine the actual number of instructions.

The low part of the pulse occurs as execution continues through the Arduino infrastructure as the loop() returns control to the first digitalWrite() line, adding 400 ns behind the scenes. That’s only six machine cycles, perhaps three or four machine instructions, and not much overhead at all.


Triggering your oscilloscope on the signal produced by Listing 1 should produce a steady display, but you’ll see “ghost” traces that seem to show missing pulses. Setting the trigger to produce single sweeps will eventually produce a display similar to Photo 2, with an obviously missing pulse.

PHOTO 2: A “missing pulse” occurs when a timer interrupt executes additional instructions that don’t appear in the user program. The interrupt can also occur when the pulse is high, causing an unexpectedly long pulse.

PHOTO 2: A “missing pulse” occurs when a timer interrupt executes additional instructions that don’t appear in the user program. The interrupt can also occur when the pulse is high, causing an unexpectedly long pulse.

Because the program’s logic (if you can call it that) lacks branches that could omit a pulse, the problem must lie elsewhere. Carefully examining the pulse timings shows that there’s not quite enough time for another pulse in that gap, which means the extended time came from a delay, rather than an omission.

The Arduino infrastructure includes a millis() function that reports the elapsed time in milliseconds since the microcontroller emerged from its most recent reset. A timer interrupt occurs every millisecond, with the interrupt handler updating a counter that the millis() function returns to the caller in a four byte unsigned long integer.

Because the loop() in Listing 1 iterates every 10.4 µs, the timer interrupt will occur once in every 96 pulses, stretching either the high or low part of the pulse. The advantage of an oscilloscope should be obvious: a problem that occurs 1% of the time might not appear amid all the “correct” values shown by a simple software measurement.

The if() statement in Listing 2 determines whether the return value from millis() has changed and, if so, produces a pulse on Pin 11. The lower trace in Photo 3 shows that pulse, with the oscilloscope triggering a single sweep on that pin and the trigger point at the middle of the screen. The upper trace comes from Pin 13, as before, and shows the same “missing” pulse due to the timer interrupt handler.

LISTING 2: The millis() function returns the number of milliseconds since the microcontroller emerged from the most recent reset. The comparison will be false 98.7% of the time, but that test adds 2 µs to the average loop() time.

LISTING 2: The millis() function returns the number of milliseconds since the microcontroller emerged from the most recent reset. The comparison will be false 98.7% of the time, but that test adds 2 µs to the average loop() time.

The cursors bracketing the 7.4 µs pulse in the upper trace show that the if() statement adds 2.3 µs to the execution time of the code in Listing 1, even when the value of millis() doesn’t change. The CPU uses those 35 clock cycles and two dozen instructions to call the millis() function, test its return value, then branch around the code inside the conditional block. You can see the effect of every instruction at this time scale!

PHOTO 3: The pulse in the lower trace shows that the “missing pulse” occurs when the return value of the millis() function changes. Testing the millis() value increases the loop() duration, as shown comparing the pulses in the top trace to those in Photo 2.

PHOTO 3: The pulse in the lower trace shows that the “missing pulse” occurs when the return value of the millis() function changes. Testing the millis() value increases the loop() duration, as shown comparing the pulses in the top trace to those in Photo 2.

The long pulse in the middle of the upper trace shows what happens just after the timer interrupt occurs: detecting the change, generating the sync pulse in the lower trace, and updating the Millis_Previous variable requires 22 µs, roughly 15 µs and 150 instructions more than the previous code.

A logic analyzer can trigger a capture based on the Boolean combination of many inputs, a situation that depends on having access to all those signals. A microcontroller buries those signals inside the CPU, where combining them into a trigger requires software, rather than hardware. A similar situation occurs with gate array logic, where a dab of additional logic inside an FPGA can generate suitable triggers, if you have a spare output pin, and may be the only way to isolate elusive glitches due to combinations that occur so rarely as to be invisible.

Homework: Move the statement that updates Millis_Previous between the two digitalWrite() functions, then measure the change in pulse width to determine the time required to update that variable.

As the number of statements inside the loop() increases, the likelihood that the timer interrupt will occur during the program also increases. This won’t make any difference to most programs, but when you’re watching a pulse on the oscilloscope, you don’t want a timer interrupt disturbing your measurements. The code in the next few examples will disable all interrupts just before raising the timing pulse and enable them after lowering it, forcing the timer interrupt to occur outside the critical section.

Download the entire article. This article appeared in Circuit Cellar 316 November 2016.

Ed Nisley is an electrical engineer and author in Poughkeepsie, NY. He has been writing for Circuit Cellar since Circuit Cellar 1, 1988. His regular column, “Above the Ground Plane,” appears every other month in Circuit Cellar magazine.

Tips for Predicting Product Reliability

British Prime Minister Benjamin Disraeli (1804–1881) once uttered: “There are lies, damned lies, and statistics.” I don’t say statistics lie, but not everything presented to us as a result of statistical analysis is necessarily true. Statistics are instrumental for investigation of many scientific and social subjects, but they’re just a tool. Incorrectly used, their results can be wittingly or unwittingly skewed and potentially used to prove or disprove just about anything.

One use of statistics in engineering is to predict product reliability, a topic I’ve addressed in several of my previous columns. In this article, I’ll investigate it further.


Predicted reliability is a probability of a product functioning without a failure for a given length of time. It is usually presented as a failure rate λ (Greek letter lambda) indicating the probable number of failures per million hours of operation. Its reciprocal Mean Time Between Failures (MTBF) or Mean Time to Failure (MTTF for irreparable products) is often preferred because it is easier to comprehend.

Having determined a product’s reliability, we can establish its criticality, the likely warranty and maintenance costs as well as to plan repair activities with spare parts quantities and their allocation. Figure 1 is the ubiquitous reliability bath tub curve. The subject of our discussion is the period called “Constant Failure Rate.”

Figure 1: Reliability bath tub curve.

Figure 1: Reliability bath tub curve.

Predicted reliability is not a precise number. It is a probability with less than 100% certainty that the product will work for the specified time. Unfortunately, many buyers, program managers, even design engineers do not recognize this and expect the predicted failure rate to be a certainty.

Most engineers aren’t expert statisticians, nor can every design organization afford such specialists on staff. Historical data to perform reliability prediction are rarely adequate in small companies. Luckily, the US military made the reliability prediction easy to calculate by following their Military Handbook: Reliability of Electronic Equipment (MIL-HDBK-217), now in version F (, based on data collected over many years.

The general method for calculating failure rate during the development stages is by parts count which, once all design details are known, is refined by parts’ stress analysis.

With the parts count method, the predicted failure rate is:Novacek 314 EQ1

In this equation, λEQUIP is the total equipment failures per million hours. λg is the generic failure rate for ith generic part. πQ is the quality factor for ith generic part. Ni quantity of ith generic part. n is the number of different generic part categories in the equipment. Using a spreadsheet, for example, you follow the Military Handbook by calculating failure rates for individual components.

A typical component failure rate model is:Novacek 314 EQ2

In this equation, λp is the part’s failure rate. λb is the part’s base failure rate. p are factors modifying the base rate for stress, application, environment, and so on.

The Military Handbook provides tables with statistical data for components’ base failure rate and all the pertinent p factors. It is one of several methods for calculating predicted reliability. I was interested to see how some different statistical methods compare with each other. For my inquiry I selected an Arduino Uno, which many readers are familiar with (see Photo 1). Not having the Arduino’s design details, I estimated operating conditions. Because I used the same estimates for all the calculations, the relative comparison of the results is valid, while the absolute value may be somewhat off.

Photo 1: Arduino Uno

Photo 1: Arduino Uno

I have a number of Arduino boards, Duemilanove and Uno, which are quite similar, and through the years have collectively clocked over 600,000 hours of continuous operation without a single failure (including all their peripheral circuits which are not, however, included in my calculations). Several of my Arduinos have worked in the garage with the recorded ambient temperature ranging from –32°C (–25.6°F) to 39°C (102.2°F), which falls under the military category “ground fixed” (GF) environment. I used this for my calculations. While components’ failure rates generally increase exponentially with temperature, operation below about 50°C (122°F) does not significantly increase the stress over a room temperature, so there would not be a significant difference in failure rate between those Arduinos working in the garage and those inside the house.


I performed two manual calculations according to MIL-HDBK-217F and one per HDBK 217 Plus using Mathcad. The failure rate of Item 1 in Table 1 was calculated per MIL-HDBK-217F for commercial parts. The MIL handbook has been criticized for two shortcomings. First, for the unrealistic penalty on commercial parts by today’s quality standards as compared to the military-screened parts. This is understandable in view of the second shortcoming: that the handbook has not been updated since 1995. At that time, component manufacturers discontinued screening their parts for military compliance, but simultaneously and up to the present, have been improving quality of manufacturing processes, thus increasing components’ reliability. Based on experience, I modified the components’ quality factors and the result is shown by Item 2.

Table 1: Calculated reliability of Arduino Uno

Table 1: Calculated reliability of Arduino Uno

There are a number of commercially available programs to aid in reliability prediction calculations. You only need to input the bill of material (BOM) with the components’ operating specifics, such as the temperature, derating, and so forth. The programs have built-in databases and do the calculations for you. Those programs are powerful, and in addition to the predicted failure rate, they can generate analyses such as Failure Mode and Effects Analysis (FMEA), Fault Tree Analysis (FTA), and others. Sadly, they are not inexpensive.

As there are different methodologies for calculating the predicted failure rate, these programs allow you to select which methodology you want to use. I performed 10 calculations for the same Arduino BOM and operating conditions by three computer programs per MIL-HDBK-217F, HDBK 217 Plus, Bellcore, Telcordia, Siemens, PRISM (which I believe is based on HDBK 217 Plus), and FIDES 2009 methodologies.

The results fall into two fairly consistent groups, roughly an order of magnitude (discounting Item 1) apart. Table 1 lists the calculated results and Figure 2 its graphic representation. Figure 2 displays the MTBF rather than the failure rate, which is easier to visualize.

Figure 2: Results tabulated in Table 1 shown graphically output.

Figure 2: Results tabulated in Table 1 shown graphically output.

As I already said, I discounted Item 1 which only demonstrates the MIL-HDBK-217F obsolete bias towards commercial parts. Items 3 and 4 show that the MIL-HDBK-217F implementation by commercial programs and my own adjustment, Item 2, are reasonably close. So are items 8, 10, and 13. These methodologies are geared towards tough military/aerospace applications and, therefore, I suspect, their statistical treatment is more conservative than that of Items 5, 6, 7, 11, and 12, which show the predicted MTBF up to more than a decade greater.

We should remind ourselves what those MTBF numbers mean. One hundred thousand hours MTBF represent 11.5 years of continuous operation! That’s a long time. It would be 23 years if operated only 12 hours daily. Many products become obsolete or fall apart before then. Consequently, I am rather skeptical about the predicted 578 years MTBF of Item #11.

Bellcore methodology was developed for telephone equipment, FIDES 2009 is the result of the efforts of the European aerospace manufacturers and the results are close to MIL-HDBK-217F. HDBK 217 Plus, Telcordia, Siemens and PRISM provided results by an order of magnitude greater.

It is important to strive for a realistic predicted failure rate because other analyses, not to mention design and manufacturing costs, warranty and spare parts allocation are affected by it. Later refinements of the calculated prediction by stress analyses, reliability testing and especially field experience should bring us close to the real value.


Which methodology should you use? My customers have always required MIL-HDBK-217, so I never had the headache of having to make and then justify my own choice. Despite its age, MIL-HDBK-217 continues to be alive and well to this day in the aerospace and military industries. In comparison with the results of Items 5, 6, 7, 9, 11, 12 MIL-HDBK-217 seems rather conservative, but when it comes to safety critical designs I much rather err on the safe side. My experience with the Arduinos doesn’t provide sufficient data to draw a general conclusion, although it appears to be better than the MIL-HDBK-217 predicts.

Ultimately, the field results will be the only thing that counts. All the calculations will be meaningless if the product’s reliability in field is not as required by the customer’s specification. Then you will be called upon to fix the design or the manufacturing process or both.

Reliability calculations differ from methodology to methodology, but if you are consistent using the same methodology, those numbers, coupled with experience, will enable you to judge what the field results will be. All my MTBF calculations met the specifications, but the field results have always exceeded those calculations. And that’s what really counts in the end.

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 for embedded control systems for aerospace applications. George wrote 26 feature articles for Circuit Cellar between 1999 and 2004. Contact him at with “Circuit Cellar” in the subject line.

Build an Accurate Milliohm Meter

A milliohm meter is a handy benchtop tool for measuring small electrical resistance values. In this article, Mark Driedger details how to build a microcontroller-based milliohm meter that accurately measures DC resistance from 10 mΩ to 10 kΩ.

I built an Arduino-based milliohm meter that accurately measures DC resistance from 10 mΩ to 10 kΩ. I used careful design techniques to cancel many error sources rather than resort to costly components. The milliohm meter is useful for tasks such as measuring transformer and inductor winding resistance, ammeter current shunts, and resistance of PCB tracks.

The finished milliohm meter

The finished milliohm meter

Measurement Method

The milliohm meter calculates the value of the resistor under test (Rx) by measuring the voltage across it and the voltage across a series-connected, known reference resistor (Rr) when driven by a test current. The measured resistance is simply: Rx = Vx/Vr × Rr.

A technique called synchronous rectification (also known as a lock-in amplifier) is used to enhance accuracy. The direction of the test current is alternated and measurements of Vx and Vr are made synchronously with the change in direction of the test current. As we will see, this cancels a number of error sources and is easy to implement on the Arduino.

Synchronous rectification can be thought of as narrowband filter at the switching frequency, implemented using a mixer (multiplier) at the switching frequency followed by a low-pass filter at DC (averaging). Normally, the switching frequency would be high enough (say, 1 kHz) to allow AC-coupled, high-gain amplifiers to be used and to move the filter passband well away from induced 60-Hz AC line voltages. In this implementation, the relatively slow ADC conversion speed prevents us from using a high switching frequency. However, we retain many other benefits of synchronous rectification with regard to reducing measurement error and we gain accuracy improvement in other ways.


An Arduino is used to control the synchronous rectification, read voltages Vx and Vr, and then compute and display the test resistor value. The test current is derived by paralleling four I/O pins through current-limiting resistors for each of the source and sink legs.

sad dsg

The circuitry

This increases the test current to roughly 100 mA, which is still well within the 40 mA/pin and 200 mA/chip limits of the Arduino processor, and the 150 mA limit of the Pro Mini’s onboard voltage regulator. The source and sink legs are alternately driven high and low to produce the test current.

sdfg sdgf

A look inside the meter

Measurement of Vx and Vr is made with an Analog Devices ADS1115 ADC, which has two differential inputs, a programmable gain amplifier (PGA) with 16× maximum gain, and 16-bit accuracy in a very small 10 MSOP package. The device costs between $10 and $15 on a small PCB module. Series resistors and film capacitors on the analog inputs provide some overload protection and noise filtering. At the highest gain, the meter resolution is approximately 75 µΩ/bit. Each measurement consists of two cycles of synchronous rectification, with 100 samples per cycle for a total of 200 samples.

An OLED module with an I2C interface is used for the display, although other options can be substituted with corresponding code changes. The meter is powered by a 9-V battery. Battery voltage is read through one of the analog input ports. Measurements are initiated with the push of the test switch to maximize battery life and minimize self-heating errors in the reference resistor. Each measurement takes roughly 2 s. Purchased modules are used for the Arduino, ADS1115 ADC, and the 64 × 128 OLED display, making it very easy to build.


OLED for displaying data


The meter is built using purchased modules and a small piece of protoboard for the shield. The ADC and display modules are available from multiple sources, and you can use any Arduino module of your choosing. (The photos and layout are for the Pro Mini.) Keep the ADC analog input wiring short and away from the processor. Use a four-wire connection to the reference resistor. Solder the drive leads farthest from the body, and the sense leads closer. The display module is mounted on the reverse side of the protoboard. The SDA/SCL I2C connections are brought from the Arduino module to the protoboard with a short cable and connector since they are not on the regular 0.1” grid.

dsf dsf

Protoboard layout

The ADS1115 module includes the pull-ups that are needed on the I2C interface lines (SDA, SCL).  I used a six-pin GX-16-6 connector for the probes. The additional two pins were used to close the battery circuit on the ground side, turning the meter on and off when the probes are connected.

The complete article appears in Circuit Cellar 314 (September 2016).

Mark Driedger has been experimenting with tube audio and electronics for over 35 years. His earned a BSc and MSc in Electrical Engineering in his native Canada. Mark has worked in the telecom industry for the past 28 years in various technical, business, and executive roles. He is currently COO for Procera Networks and lives in Dallas, TX.

FTDI Arduino-Compatible Touch-Enabled Display Shield Now Shipping

FTDI Chip recently announced the widespread availability of its originally crowdfunded CleO product (and accompanying accessories). FTDI Chip also offers access to software tools, step-by-step tutorials, and projects. FTDI CleOCleO is a simple to program, intelligent TFT display solution that for building human machine interfaces (HMIs) with higher performance than typical Arduino display shields. The initial CleO includes an HVGA resolution, 3.5″ TFT display featuring a resistive touchscreen. An FTDI Chip FT810 high-resolution embedded video engine (EVE) graphic controller executes the HMI operation. An FTDI FT903 microcontroller handles all the additional processing tasks. The advanced display shield provides high-quality graphical animation, even at 60-fps frame rates. In addition, its antialiased graphics capabilities render images in finer detail.

When CleO is combined with FTDI Chip’s NerO—which is an energy-efficient Arduino design capable of operating up to 1 W—it offers a far more powerful solution than a normal Arduino UNO/display shield package.

CleO has an array of useful accessories:

  • AT 57.15 mm × 54.35 mm, the CleO-RIO module provides a mechanism for stacking the CleO shield and an Arduino board together.
  • The CleO-Speaker module (63 mm × 63 mm × 23.8 mm) facilitates the playback music/tones for HMIs where audio functionality has been incorporated. There is also an audio line for input of audio from external sources.
  • The CleO-Camera module has an OV5640 0.25″ 5-megapixel CMOS image sensor plus flash LEDs and a 24-pin 0.5-mm pitch FFC cable.
  • A 9-V power adaptor provides the NerO/CleO solution with up to 1 A of current.

The CleO costs $69. Refer to FTDI’s new forum,, for design tips, application ideas, and more.

Source: FTDI Chip

Arduino Primo Features Nordic Semiconductor SoC

Nordic Semiconductor recently announced that Arduino’s new Arduino Primo features its nRF52832 Bluetooth low energy SoC. The IoT-targeted Arduino Primo PCB features native Bluetooth low energy wireless connectivity and includes Near Field Communication (NFC), Wi-Fi, and infrared (IR) technologies. In addition to being able to wirelessly connect to a wide array of Bluetooth low energy sensors, the Arduino Primo uses the nRF52832 SoC’s integrated NFC for secure authentication and Touch-to-Pair (a simple BLE pairing function requiring no user interaction), and has embedded IR for traditional remote control. Nordic_Arduino_Primo_PRINT

The Nordic nRF52832 SoC’s ARM processor has ample computational overhead to manage the Arduino Primo’s on-board accelerometer, temperature, humidity, and pressure sensors. The Nordic Semiconductor nRF52832’s features and specs include:

  • 64-MHz, 32-bit ARM Cortex-M4F processor
  • 2.4-GHz multiprotocol radio that’s fully compatible with the Bluetooth 4.2 specification and features –96-dB RX sensitivity and 5.5-mA peak RX/TX currents
  • 512-KB flash memory and 64-KB RAM, and a fully-automatic power management system to optimize power consumption.

You can program via the Arduino Integrated Development Environment (IDE) programming interface. If you want to access the Arduino Prio’s most advanced features and functionality, you can use any Nordic nRF52 Series-compatible Software Development Kit (SDK) or programming tools. For example, the nRF5 SDK for IoT enables you to develop IPv6 over Bluetooth low energy applications on the nRF52832 SoC.

Source: Nordic Semiconductor

Innovative Tech at Embedded World 2016

Attendance at the recent Embedded World 2016 conference in Nuremberg, Germany, increased 17% (30,063 trade visitors) over 2015. Wisse Hettinga was in attendance and took notes on some of the more interesting technologies on display. He writes:

Controllino: Open-Source PLC

Say “ino” and most engineers and electronics enthusiasts will think, “Arduino.” That also goes for “Controllino,” which is a programmable logic controller (PLC) based on Arduino hardware and software. Marco Riedesser started developing this new product after he repaired a coffee machine with parts he designed. His Controllino is intended for the new generation of automation experts who grew up with the Arduino platform. The Controllino is 100% compatible with the Arduino platform and makes use of the SDK. And, perhaps most importantly, it is an open development system. For more information, visit


NXP Semiconductors knows that innovative new technologies don’t appearing out of the blue, which is why it created the Hexiwear wearable development platform. Along with MikroElektronika, NXP is promoting this new piece of hardware to the design community via a Kickstarter campaign. hexiwear

Due to its compact design, you can use the Hexiwear as a watch or, if you need more functionality, you can click it onto the developer’s main board. The open-source Hexiwear’s features and specs include:

  • NXP Kinetis K64 MCU (ARM Cortex-M4, 120 MHz, 1M Flash, 256K SRAM)
  • BLE NXP Kinetis KW40Z multimode radio SoC (ARM Cortex-M0+, Bluetooth Low Energy & 802.15.4 Wireless MCU)
  • NXP FXOS8700CQ 3-D accelerometer and 3-D magnetometer
  • NXP FXAS21002 three-axis digital gyroscope
  • NXP MPL3115A2R1 absolute digital pressure sensor
  • NXP MC34671 600-mA, single-cell li-ion/li-polymer battery charger
  • TAOS TSL2561 light-to-digital converter
  • MEAS HTU21D digital humidity and temperature sensor
  • Maxim MAX3010x heart-rate sensor
  • Haptic feedback engine
  • 190-mAh 2C li-po battery
  • Capacitive touch interface
  • 1.1″ full color OLED display
  • 8 MB of additional flash memory

Intel Edison, What Did You Make?

When the Edison board was launched in 2014, it drew quite some attention from the community of makers. The board was heavy specified, wearable, and IoT ready. It allowed quick prototyping and the close connections with the Arduino world promised a smooth introduction into the world of designers and entrepreneurs with great ideas for the future. The module also came with seriously high price tag.edison

In the first months after the launch, there was a lot of interest. Some projects made it to the headlines, but things eventually quieted down around the platform. Was it the price, or was it the fact that the world of the x86 is different from the world of AVR or ARM? Or perhaps you need Linux knowledge to dig deeper into the system?

Embedded World 2016 in Nuremberg was a good opportunity to learn about the board’s status. According to Intel’s Ken Caviasca (VP in the IoT Group and GM of platform engineering and development), it is clear that Intel is still serious about addressing the makers community with the Edison module. A new board was announced on the Intel Developers Conference and the initiative is alive and well. Intel’s main objective for the Edison board is to get designers involved and to pick up new interest in the x86. Caviasca  confirmed that the Edison project is on target and many makers are using the platform for their designs. With a confident Intel about the future of  Edison, a big question remains: What will you make with it?

Execute Open-Source Arduino Code in a PIC Microcontroller Using the MPLAB IDE

The Arduino single-board computer is a de facto standard tool for developing microcomputer applications within the hobbyist and educational communities. It provides an open-source hardware (OSH) environment based on a simple microcontroller board, as well as an open-source (OS) development environment for writing software for the board.

Here’s an approach that enables Arduino code to be configured for execution with the Microchip Technology PIC32MX250F128B small-outline 32-bit microcontroller. It uses the Microchip Technology MPLAB X IDE and MPLAB XC32 C Compiler and the Microchip Technology Microstick II programmer/debugger.

Subscribe to Circuit Cellar magazine! Get 12 months of electrical engineering project articles, embedded design tutorials, embedded programming tips, and much more. We cover micrcontrollers, robotics, embedded Linux, IoT projects, and more!

Your own reasons for using this approach will depend on your personal needs and background. Perhaps as a long-term Arduino user, you want to explore a new processor performance option with your existing Arduino code base. Or, you want to take advantage of or gain experience with the Microchip advanced IDE development tools and debug with your existing Arduino code. All of these goals are easily achieved using the approach and the beta library covered in this article.

Several fundamental open-source Arduino code examples are described using the beta core library of Arduino functions I developed. The beta version is available, for evaluation purposes only, as a free download from the “Arduino Library Code for PIC32” link on my KibaCorp company website, From there, you can also download a short description of the Microstick II hardware configuration used for the library.

To illustrate the capabilities in their simplest form, here is a simple Blink LED example from my book Beginner’s Guide to Programming the PIC32. The example shows how this custom library makes it easy to convert Arduino code to a PIC32 binary file.

The Arduino code example is as follows: Wire an LED through a 1-K resistor to pin 13 (D7) of the Arduino. An output pin is configured to drive an LED using pinMode () function under setup (). Then under loop () this output is set high and then low using digitalWrite () and delay () functions to blink the LED. The community open-source Arduino code is:

The open-source example uses D13 or physical pin 13 on the Arduino. In relation to the PIC32MX, the D13 is physical pin 25. Pin 25 will be used in prototyping wiring.

Now, let’s review and understand the PIC32 project template and its associated “wrapping functions.”  The Arduino uses two principal functions: setup () to initialize the system and loop () to run a continuous execution loop. There is no Main function. Using the Microchip Technololgy XC32 C compiler, we are constrained to having a Main function. The Arduino setup () and loop () functions can be accommodated, but only as part of an overall template Main “wrapping” function. So within our PIC32 template, we accommodate this as follows:

Listing 2

This piece of code is a small but essential part of the template. Note that in this critical wrapping function, setup () is called once as in Arduino and loop () is configured to be called continuously (simulating the loop () function in Arduino) through the use of a while loop in Main.

The second critical wrapping function for our template is the use of C header files at the beginning of the code. The XC32 C compiler uses the C compiler directive #include reference files within the Main code. Arduino uses import, which is a similar construct that is used in higher-level languages such as Java and Python, which cannot be used by the MPLAB XC32 C.

The two include files necessary for our first example are as follows:

Listing 3

System.h references all the critical Microchip library functions supporting the PIC32MX250F128B. The Ardunio.h provides the Arduino specific library function set. Given these two key “wrapper” aspects, where does the Arduino code go? This is best illustrated with a side-by-side comparison between Arduino code and its Microchip equivalent. The Arduino code is essentially positioned between the wrapper codes as part of the Main function.

Blink side-by-side comparison

Blink side-by-side comparison

This approach enables Arduino code to execute on a Microchip PIC32 within an MPLAB X environment. Note that the Arduino code void setup () now appears as void setup (void), and void loop () appears as void loop (void). This is a minor inconvenience but again necessary for our C environment syntax for C prototype function definitions. Once the code is successfully compiled, the environment enables you to have access to the entire built-in tool suite of the MPLAB X and its debugger tool suite.

Configure the Microstick II prototype as in the following schematic. Both the schematic and prototype are shown below:

Exercise 1 schematic

Exercise 1 schematic

Exercise 1 prototype

Exercise 1 prototype

Table 1 compares Arduino core functionality to what is contained in the Microchip PIC32 expanded beta library. In the beta version, I added additional C header files to accomplish the necessary library functionality. Table 2 compares variable types between Arduino and PIC32 variable types. Both Table 1 and Table 2 show the current beta version has a high degree of Arduino core library functionality. Current limitations are the use of only one serial port, interrupt with INT0 only, and no stream capability. In addition, with C the “!” operator is used for conditional test only and not as a complement function, as in Arduino. To use the complement function in C, the “~” operator is used. The library is easily adapted to other PIC32 devices or board types.

Table 1

Table 1: Arduino vs Microchip Technology PIC32 core library function comparison

Talble 2

Table 2: Arduino vs Microchip Technology PIC32 core library variable types

If you use interrupts, you must identify to C the name of your interrupt service routine as used in your Arduino script. See below:

Interrupt support

Interrupt support

For more information on the beta release or to send comments and constructive criticism, or to report any detected problems, please contact me here.

Four test case examples demonstrating additional core library functions are shown below as illustrations.

Serial communications

Serial communications

Serial find string test case

Serial find string test case

Serial parse INT

Serial parse INT



Editor’s Note: Portions of this post first appeared in Tom Kibalo’s book Beginner’s Guide to Programming the PIC32 (Electronics Products, 2013). They are reprinted with permission from Chuck Hellebuyck, Electronic Products. If you are interested in reading more articles by Kibalo, check out his two-part Circuit Cellar “robot boot camp” series posted in 2012 : “Autonomous Mobile Robot (Part 1): Overview & Hardware” and “Autonomous Mobile Robot (Part 2): Software & Operation.”


Tom Kibalo

Tom Kibalo

Tom Kibalo is principal engineer at a large defense firm and president of KibaCorp, a company dedicated to DIY hobbyist, student, and engineering education. Tom, who is also an Engineering Department adjunct faculty member at Anne Arundel Community College in Arnold, MD, is keenly interested in microcontroller applications and embedded designs. To find out more about Tom, read his 2013 Circuit Cellar member profile.

Elektor Publishes the Ultimate Intel Edison Manual

Elektor’s latest publication on the Intel Edison is a must have for all those with an active interest in the Internet of Things. The book, Getting Started with the Intel Edison, focuses its attention on the Edison, a tiny computer, the size of a postage stamp, with a  lot of power and built-in wireless communication capabilities. In 128 pages, renowned author Bert van Dam helps readers get up to speed with the Edison by making it accessible and easy to use.  It is not a projects book, but a toolbox and guide that allows you to explore the wonderful world of the Intel Edison.

Source: Elektor

Source: Elektor

This book shows readers how to install the software on the Edison as well as on a Windows PC. The Edison Arduino breakout board is used because it is easy to work with. Linux, Arduino C++ and Python are also used and plenty of examples given as to how the Edison can interface with other software. Covering Wi-Fi and Bluetooth, the book also shows you a trick to program sketches over Wi-Fi. Once you have completed the book, not only will your Edison be up and running with the latest software version, but you will also have sufficient knowledge of both hardware and software to start making your own applications. You will even be able to program the Intel Edison over USB and wirelessly both in Arduino C++ and Python. This book is educational and interesting, and really helps to build your knowledge of all things Intel Edison.

Getting started with the Intel Edison is currently available for $35.

Source: Elektor

Utilize Simple Radios with Simple Computers

I ordered some little UHF transmitters and receivers from suppliers on AliExpress, the Chinese equivalent of, in order to extend my door chimes into areas of my home where I could not hear them. These ridiculously inexpensive units are currently about $1 per transmitter-receiver pair in quantities of five, including shipping, and are available at 315 and 433.92 MHz. Photo 1 shows a transmitter and receiver pair.  Connections are power and ground and data in or out.

Photo 1: 315 MHz Transmitter-Receiver Pair (Receiver on Left)

Photo 1: The 315-MHz transmitter-receiver pair (receiver on left)

The original attempt at a door chime extender modulated the transmit RF with an audio tone and searched for the presence of that tone at the receiver with a narrow audio filter, envelope detector, and threshold detector. This sort of worked, but I started incorporating the same transmitters into another project that interfered, despite the audio filter.

The other project used Arduino Uno R3 computers and Virtual Wire to convey data reliably between transmitters and receivers. Do not expect a simple connection to a serial port to work well. As the other project evolved, I learned enough about the Atmel ATtiny85 processor, a smaller alternative to the Atmel ATmega328 processor in the Arduino Uno R3, to make new and better and very much simpler circuits. That project evolved to come full circle and now serves as a better doorbell extender. The transmitters self identify, so a second transmit unit now also notifies me when the postman opens the mailbox.

Note the requirement for Virtual Wire.  Do not expect a simple connection to a serial port to work very well.


Figure 1 shows the basic transmitter circuit, and Photo 2 shows the prototype transmitter. There is only the ATtiny85 CPU and a transmitter board. The ATtiny85 only has eight pins with two dedicated to power and one to the Reset input.

Figure 1: Simple Transmitter Schematic

Figure 1: Simple transmitter schematic

One digital output powers the transmitter and a second digital output provides data to the transmitter.  The remaining three pins are available to serve as inputs.  One serves to configure and control the unit as a mailbox alarm, and the other two set the identification message the transmitter sends to enable the receiver to discriminate among a group of such transmitters.

Photo 2: 315 MHz Transmitter and ATtiny85 CPU

Photo 2: The 315-MHz transmitter and ATtiny85 CPU

When input pin 3 is high at power-up, the unit enters mailbox alarm mode. In mailbox alarm mode, the input pins 2 and 7 serve as binary identification bits to define the value of the single numeric character that the transmitter sends, and the input pin 3 serves as the interrupt input. Whenever input pin 3 transitions from high-to-low or low-to-high, the ATtiny85 CPU wakes from SLEEP_MODE_PWR_DOWN, makes a single transmission, and goes back to sleep. The current mailbox sensor is a tilt switch mounted to the door of the mailbox. The next one will likely be a reed relay, so only a magnet will need to move.

When in SLEEP_MODE_PWR_DOWN, the whole circuit draws under 0.5 µA. I expect long life from the three AAA batteries if they can withstand heat, cold, and moisture. I can program the ATtiny to pull the identification inputs high, but each binary identification pin then draws about 100 µA when pulled low. In contrast, the 20- or 22-MΩ pull-up resistors I use as pull-ups each draw only a small fraction of a microampere when pulled low.

When input pin 3 is low at power-up, the unit enters doorbell extender alarm mode. In doorbell extender alarm mode, the input pins 2 and 7 again serve as binary identification bits to define the value of the single numeric character that the transmitter sends; but in doorbell extender mode, the unit repetitively transmits the identification character whenever power from the door chimes remains applied.


Figure 2 shows the basic receiver circuit, and Photo 3 shows the prototype receiver. There is only the ATtiny85 CPU with a 78L05 voltage regulator and a receiver board.

Figure 2: Simple Receiver Schematic

Figure 2: Simple receiver schematic

The receiver output feeds the input at pin 5. The Virtual Wire software decodes and presents the received character. Software in the CPU sends tone pulses to a loudspeaker that convey the value of the identification code received, so I can tell the difference between the door chime and the mailbox signals. Current software changes both the number of beep tones and their audible frequency to indicate the identity of the transmit source.

Photo 3: The 315-MHz receiver with ATtiny85 CPU and 78L05 voltage regulator

Photo 3: The 315-MHz receiver with ATtiny85 CPU and 78L05 voltage regulator

Note that these receivers are annoyingly sensitive to power supply ripple, so receiver power must either come from a filtered and regulated supply or from batteries.

Photo 4 shows the complete receiver with the loudspeaker.

Photo 4: Receiver with antenna connections and loudspeaker

Photo 4: Receiver with antenna connections and a loudspeaker

Link Margin

A few inches of wire for an antenna will reach anywhere in my small basement. To improve transmission distance from the mailbox at the street to the receiver in my basement, I added a simple half-wave dipole antenna to both transmitter and receiver. Construction is with insulated magnet wire so I can twist the balanced transmission line portion as in Photo 5. I bring the transmission line out through an existing hole in my metal mailbox and staple the vertical dipole to the wooden mail post. My next mailbox will not be metal.

Photo 5: Simple half-wave dipole for both Tx and Rx increases link distance

Photo 5: Simple half-wave dipole for both Tx and Rx increases link distance

I don’t have long term bad weather data to show this will continue to work through heavy ice and snow, but my mailman sees me respond promptly so far.

Operating Mode Differences

The mailbox unit must operate at minimum battery drain, and it does this very well. The doorbell extender operates continuously when the AC door chime applies power. In order to complete a full message no matter how short a time someone presses the doorbell push button, I rectify the AC and store charge in a relatively large electrolytic capacitor to enable sufficient transmission time.

Photo 6: New PCBs for receive and transmit

Photo 6: New PCBs for receive and transmit


This unit is fairly simple to fabricate and program your self, but if there is demand, my friend Lee Johnson will make and sell boards with pre-programmed ATtiny85 CPUs. (Lee Johnson, NØVI, will have information on his website if we develop this project into a product: We will socket the CPU so you can replace it to change the program. The new transmitter and receiver printed circuit boards appear in Photo 6.

Dr. Sam Green (WØPCE) is a retired aerospace engineer living in Saint Louis, MO. He holds degrees in Electronic Engineering from Northwestern University and the University of Illinois at Urbana. Sam specialized in free space and fiber optical data communications and photonics. He became KN9KEQ and K9KEQ in 1957, while a high school freshman in Skokie, IL, where he was a Skokie Six Meter Indian. Sam held a Technician class license for 36 years before finally upgrading to Amateur Extra Class in 1993. He is a member of ARRL, a member of the Boeing Employees Amateur Radio Society (BEARS), a member of the Saint Louis QRP Society (SLQS), and breakfasts with the Saint Louis Area Microwave Society (SLAMS). Sam is a Registered Professional Engineer in Missouri and a life senior member of IEEE. Sam is listed as inventor on 18 patents.