Dialog to Buy at Atmel for $4.6 Billion

Dialog Semiconductor and Atmel Corp. recently announced Dialog will acquire Atmel in a cash and stock transaction for approximately $4.6 billion. According to reports, the deal will likely close in the first quarter of 2016.

The transaction—which has been unanimously approved by the boards of directors of both companies and is subject to regulatory approvals in various jurisdictions, as well as the approval of Dialog and Atmel shareholders—will likely close in Q1 2016. Jalal Bagherli will continue as Chief Executive Officer and Executive Board Director of Dialog.

Two-Pin, Self-Powered Serial EEPROM for the IoT

Atmel recently announced a two-pin, single-wire EEPROM intended for the Internet of Things (IoT), wearables, and more. The self-powered devices don’t require a power source or VCC pin, with a parasitic power scheme over the data pin. They provide ultra-low power standby of 700 nA, 200 µA for write current, and 80 µA for read current at 25°C.

The AT21CS01/11 devices eliminate the need for external capacitors and rectifiers with its parasitic power scheme over a single data pin. Plus, their ultra-high write endurance capability to allow more than 1 million cycles for each memory location to meet the requirements for today’s high-write endurance applications.

The AT21CS01/11 products include a simple product identification with a plug-and-play, 64-bit unique serial number in every device. Furthermore, they deliver industry-leading electrostatic discharge (ESD) rating (IEC 61000-4-2 Level 4 ESD Compliant), so a variety of applications (e.g., cables and consumables) can tolerate exposure to the outside environment or direct human contact while still delivering high performance.

The new devices follow the I2C protocol, which enables easy migration from existing EEPROM with less overhead and the capability to connect up to eight devices on the same bus. The AT21CS01 devices offer a security register with a 64-bit factory programmed serial number and an extra 16 bytes of user-programmable and permanently lockable storag.

The AT21CS01 is intended for low-voltage applications operating at 1.7 to 3.6 V. For applications that require higher voltage ranges (e.g., Li-Ion/polymer batteries), the AT21CS11 supports a 2.7 to 4.5 V operating range.

The AT21CS01 devices are available in production quantities in three-lead SOT23, eight-lead SOIC, and four-ball WLCSP. Pricing starts at $0.32 in 5,000-piece quantities. The AT21CS11 will be available in Q4 2015.

Source: Atmel

Ultra-Low Power Wi-Fi Platform for IoT Applications

Atmel and MXCHIP recently announced that they’re jointly developing an ultra-low power Internet of Things (IoT) platform with secure Wi-Fi access to the cloud, enabling designers to quickly bring IoT devices to market. The platform combines Atmel’s ultra-low power SMART SAM G ARM Cortex-M4-based MCUs and its SmartConnect WILC1000 Wi-Fi solution with MXCHIP’s MiCO IoT operating system (OS), servicing a full range of smart device developers for IoT applications. The integrated platform is intended to give IoT designers the confidence that their battery-operated devices will have longer battery life and their data will be securely transferred to the cloud.

Atmel’s WILC1000 is an IEEE 802.11b/g/n IoT link controller leveraging its ultra-low power Wi-Fi transceiver with a fully integrated power amplifier. This solution delivers the industry’s best communication range of up to +20.5-dBm output, ideal for connected home devices. Integrated in packages as small as a 3.2 mm × 3.2 mm WLCSP, the Atmel WILC1000 link controller leverages in this platform Atmel’s SAM G MCU, an ideal solution for low-power IoT applications and optimized for lower power consumption, incorporating large SRAM, high performance and operating efficiency with floating-point unit in an industry-leading 2.84 mm × 2.84 mm package. When combined with secure Wi-Fi technology, the joint IoT platform connects directly to each other or to a local area network (LAN), enabling remote system monitoring or control. For increased security, the platform comes with an optional Atmel ATECC508A, which is the industry’s first crypto device to integrate ECDH key agreement, making it easy to add confidentiality to digital systems including IoT nodes used in home automation, industrial networking, accessory and consumable authentication, medical, mobile and other applications.


To accelerate the IoT design process, the platform includes the MiCOKit-G55 development kit, technical documentation, application notes and a software development kit.

Source: Atmel

Quad Bench Power Supply

The need for a bevy of equipment for building and testing presents a problem: how to deliver an adequate power supply while keeping workbench clutter to a minimum. Brian decided to tackle this classic engineering conundrum with a small, low-capacity quad bench power supply.

To the right of the output Johnson posts are the switches that set the polarity of the floating supplies—as well as the switch that disconnects all power supply outputs—while leaving the unit still powered up.

To the right of the output Johnson posts are the switches that set the polarity of the floating supplies—as well as the switch that disconnects all power supply outputs—while leaving the unit still powered up.

In “Quad Bench Power Supply,” Millier writes:

I hate to admit it, but my electronics bench is not a pretty sight, at least in the midst of a project anyway. Of course, I’m always in the middle of some project that, more often than not, contains two or three different projects in various stages of completion. To make matters worse, most of my projects involve microchips, which have to be programmed. Because I use ISP flash memory MCUs exclusively, it makes sense to locate a computer on my construction bench to facilitate programming and testing. To save space, I initially used my laptop’s parallel port for MCU programming. It was only a matter of time before I popped the laptop’s printer port by connecting it to a prototype circuit with errors on it.

Fixing my laptop’s printer port would have involved replacing its main board, which is an expensive proposition. Therefore, I switched over to a desktop computer (with a $20 ISA printer port board) for programming and testing purposes. The desktop, however, took up much more room on my bench.

You can’t do without lots of testing equipment, all of which takes up more bench space. Amongst my test equipment, I have several bench power supplies, which are unfortunately large because I built them with surplus power supply assemblies taken from older, unused equipment. This seemed like a good candidate for miniaturization.

At about the same time, I read a fine article by Robert Lacoste describing a high-power tracking lab power supply (“A Tracking Lab Power Supply,” Circuit Cellar 139). Although I liked many of Robert’s clever design ideas, most of my recent projects seemed to need only modest amounts of power. Therefore, I decided to design my own low-capacity bench supply that would be compact enough to fit in a small case. In this article, I’ll describe that power supply.


Even though I mentioned that my recent project’s power demands were fairly modest, I frequently needed three or more discrete voltage levels. This meant lugging out a couple of different bench supplies and wiring all of them to the circuit I was building. If the circuit required all of the power supplies to cycle on and off simultaneously, the above arrangement was extremely inconvenient. In any event, it took up too much space on my bench.

I decided that I wanted to have four discrete voltage sources available. One power supply would be ground referenced. Two additional power supplies would be floating power supplies. Each of these would have the provision to switch either the positive or negative terminal to the negative (ground) terminal of the ground-referenced supply, allowing for positive or negative output voltage. Alternately, these supplies could be left floating with respect to ground by leaving the aforementioned switch in the center position.

This arrangement allows for one positive and two positive, negative or floating voltage outputs. To round off the complement, I added Condor’s commercial 5-V, 3-A linear power supply module, which I had on hand in my junk box. Table 1 shows the capabilities of the four power supplies.

I wanted to provide the metering of voltage and current for the three variable power supplies. The simultaneous voltage and current measurement of three completely independent power supplies seemed to indicate the need for six digital panel meters. Indeed, this is the path that Robert Lacoste used in his tracking lab supply.

As you can see, there are four power supplies. I’ve included all of the information you need to understand their capabilities.

As you can see, there are four power supplies. I’ve included all of the information you need to understand their capabilities.

I had used many of these DPM modules before, so I was aware of the fact that the modules require their negative measurement terminal to float with respect to the DPM’s own power supply. I solved this problem in the past by providing the DPM module with its own independent power source. Robert solved it by designing a differential drive circuit for the DPM. Either solution, when multiplied by six, is not trivial. Add to this the fact that high-quality DPMs cost about $40 in Canada, and you’ll see why I started to consider a different solution.

I decided to incorporate an MCU into the design to replace the six DPMs as well as six 10-turn potentiometers, which are also becoming expensive. In place of $240 worth of DPMs, I used three inexpensive dual 12-bit ADCs, an MCU, and an inexpensive LCD panel. The $100 worth of 10-turn potentiometers was replaced with three dual digital potentiometers and two inexpensive rotary encoders.

Using a microcontroller-based circuit basically allows you to control the bench supply with a computer for free. I have to admit that I decided to add the commercial 5-V supply module at the last minute; therefore, I didn’t allow for the voltage or current monitoring of this particular supply.


Although there certainly is a digital component to this project, the basic power supply core is a standard analog series-pass regulator design. I borrowed a bit of this design from Robert’s lab supply circuit.

Basically, all three power supplies share the same design. The ground-referenced power supply provides less voltage and more current than the floating supplies. Thus, it uses a different transformer than the two floating supplies. The ground-referenced supply’s digital circuitry (for control of the digital potentiometer and ADC) can be connected directly to the MCU port lines. The two floating supplies, in addition to the different power transformer, also need isolation circuitry to connect to the MCU.

Figure 1 is the schematic for the ground-referenced supply. As you can see, a 24VCT PCB-mounted transformer provides all four necessary voltage sources. A full wave rectifier comprised of D4, D5, and C5 provides the 16 V that’s regulated down to the actual power supply output. Diodes D6, R10, C8, and Zener diode D7 provide the negative power supply needed by the op-amps. …

The ground-referenced power supply includes an independent 5-V supply to run the microcontroller module.

The ground-referenced power supply includes an independent 5-V supply to run the microcontroller module.


As with every other project I’ve worked on in the last two years, I chose the Atmel AVR family for the MCU. In this case, I went with the AT90S8535 for a couple of reasons. I needed 23 I/O lines to handle the three SPI channels, LCD, rotary encoders, and RS-232. This ruled out the use of smaller AVR devices. I could’ve used the slightly less expensive AT90LS8515, but I wanted to allow for the possibility of adding a temperature-sensing meter/alarm option to the circuit. The ’8535 has a 10-bit ADC function that’s suitable for this purpose; the ’8515 does not.

The ’8535 MCU has 8 KB of ISP flash memory, which is just about right for the necessary firmware. It also contains 512 bytes of EEPROM. I used a small amount of the EEPROM to store default values for the three programmable power supplies. That is to say, the power supply will power up with the same settings that existed at the time its Save Configuration push button was last pressed.

To simplify construction, I decided to use a SIMM100 SimmStick module made by Lawicel. The SIMM100 is a 3.5″ × 2.0″ PCB containing the ’8535, power supply regulator, reset function, RS-232 interface, ADC, ISP programming headers, and a 30-pin SimmStick-style bus. I’ve used this module for prototypes several times in the past, but this is the first time I’ve actually incorporated one into a finished project. …

eded to operate the three SPI channels and interface the two rotary encoders come out through the 30-pin bus. As you now know, I designed the ground-referenced power supply PCB to include space to mount the SIMM100 module, as well as the IsoLoop isolators. The SIMM100 mounts at right angles to this PCB; it’s hard-wired in place using 90° header pins. The floating power supplies share a virtually identical PCB layout apart from being smaller because of the lack of traces and circuitry associated with the SIMM100 bus and IsoLoop isolators.

The SIMM100 module has headers for the ISP programming cable and RS-232 port. I used its ADC header to run the LCD by reassigning six of the ADC port pins to general I/O pins.

When I buy in bulk, it’s inevitable that by the time I use the last item in my stock, something better has taken its place. After contacting Lawicel to request a .jpg image of the SIMM100 for this article, I was introduced to the new line of AVR modules that the company is developing.

Rather than a SimmStick-based module, the new modules are 24- and 40-pin DIP modules that are meant to replace Basic Stamps. Instead of using PIC chips/serial EEPROM and a Basic Interpreter, they implement the most powerful members of Atmel’s AVR family—the Mega chips.

Mega chips execute compiled code from fast internal flash memory and contain much more RAM and EEPROM than Stamps. Even though flash programming AVR-family chips is easy through SPI, using inexpensive printer port programming cables, these modules go one step further by incorporating RS-232 flash memory programming. This makes field updates a snap. …

The user interface I settled on consisted of a common 4 × 20 LCD panel along with two rotary encoders. One encoder is used to scroll through the various power supply parameters, and the other adjusts the selected parameter. The cost of LCDs and rotary encoders is reasonable these days. Being able to eliminate the substantial cost of six DPMs and six 10-turn potentiometers was the main reason for choosing an MCU-based design in the first place.

Brian Millier’s article first appeared in Circuit Cellar 149.

ARM MCUs wtith Capacitive Touch Hardware Support for HMI and LIN Applications

Atmel recently announced its next-generation family of automotive-qualified ARM Cortext-M0+-based micrcontrollers with an integrated peripheral touch controller (PTC) for capacitive touch applications. The new SAM DA1 is the first series in this Atmel |SMART MCU automotive-qualified product family, operating at a maximum frequency of 48 MHz and reaching a 2.14 Coremark/MHz.Atmel Corporation SAM DA1

Atmel’s SAM DA1 series is ideal for capacitive touch button, slider, wheel or proximity sensing applications and offers high analog performance for greater front-end flexibility. The new devices are available down to a very compact QFN 5 × 5 mm package with wettable flanks for automated optical inspection.

Eliminating external components and offering more robust features, devices in the SAM DA1 series come with 32 to 64 pins, up to 64 KB of flash memory, 8 KB of SRAM, and 2-KB read-while-write flash memory and are qualified according to the AEC Q-100 Grade 2 (–40° to 105°C).

Key Features of Atmel’s SAM DA1 Series

  • Atmel |SMART ARM Cortex-M0+-based processor
  • 45 DMIPS
  • Vcc 2.7 to 3.63 V
  • 16- to 64-KB Flash; 32 to 64 pins
  • Up to six SERCOM (Serial Communication Interface), USB, I2S
  • Peripheral Touch Controller
  • Complex PWM
  • AEC Q100 Grade 2 Qualified

To accelerate the design development, the ATSAMDA1-XPRO development kit is available to support the new devices. The new SAM DA1 series is also supported by Atmel Studio, Atmel Software Framework and debuggers.

Contact Atmel to sample the SAM DA1 series.

Source: Atmel

Utilize Simple Radios with Simple Computers

I ordered some little UHF transmitters and receivers from suppliers on AliExpress, the Chinese equivalent of Amazon.com, 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: www.citrus-electronics.com.) 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.

Microcontroller-Based Wireless Pedometer & Pace Tacker Project

Anyone can easily order a pedometer or GPS sports watch on the Internet. But engineers like challenges, right? With the right parts and a little knowhow, you can engineer your own microcontroller-based wireless Bluetooth pedometer and pace tracker.

In the article, “Run With It” (Circuit Cellar 203, December 2014), Ellen Chuang and Julie Wang explain how they built an Atmel ATmega1284P microcontroller-based wireless pedometer and pace tracker. They wrote:

There’s a simple question most runners, walkers, and joggers ask themselves: How fast am I going? There are various tools for measuring pace, including step counters, GPS units, and smartphone applications. Pedometers are common tools for tracking physical activity. However, pedometers are typically either self-contained units that are out of sight and out of mind or expensive products like the FitBit and Nike+. So, for our culminating design project for Cornell University’s ECE 4760 Microcontrollers course, we decided to create a low-budget wireless pedometer and pace tracker.

The wireless pedometer hardware implementation includes a (a) foot module and a (b) wrist module on the right.

The wireless pedometer includes a foot module (a) and a wrist module (b).

Chuang and Wang’s design is notable because they enabled it with Bluetooth so they could connect it with other Bluetooth devices. In addition, they separated the user interface from the measurement unit.

Our system contains two separate modules: a foot-mounted module that captures acceleration data and a wrist-mounted module with a user interface. The foot module captures your acceleration data, lightly processes it to find values of interest, and sends the data over Bluetooth to the wrist module. The wrist module then further processes the information to determine if a step has occurred. The wrist module also handles user input and displaying information on an LCD.

To use the device, the foot unit is strapped on your lower leg and the wrist unit is either strapped to your wrist or held in your hand. At power-up, the units automatically pair over a Bluetooth link. The wrist unit powers up in Configuration mode, which enables you to use the two push buttons to adjust your stride length and also your desired pace in minutes per mile. You are first prompted for your stride length—the average length of one step—and then the targeted speed in minutes per mile. The Enter button enables you to confirm the parameters, exit Configuration mode, and enter into Pace Display mode. In Pace Display mode, the LCD displays the cumulative number of steps, your calculated pace, and your desired pace. At any point, you can reenter Configuration mode by toggling a switch on the wrist module.

Both modules contain an Atmel ATmega1284P microcontroller and an HC-05 Bluetooth master/slave module.

The foot unit contains a 1.5-g, single-axis Freescale Semiconductor MMA2260D accelerometer orientated with its positive measurement axis pointed away from the center of the Earth. We’ll refer to this direction as the z-axis. The analog data coming from the accelerometer is very noisy. To filter out the excessive noise, the accelerometer data passes through a low-pass filter with a cutoff frequency around 33 Hz using a 10-kΩ resistor and 470-nF capacitor. Human stride frequency typically falls between 185 and 200 strides per minute, or around 3.33 Hz. In order to capture this frequency, as well as higher frequency signals that correspond to other foot movements, we set the low-pass filter’s cutoff frequency to 33 Hertz. Additionally, to fully utilize the internal ADC’s 10-bit range, we dropped the voltage across a 20-kΩ resistor…

This is the foot unit. We used MAX233/RS-232 for debugging purposes and not for the final foot module.

This is the foot unit. We used MAX233/RS-232 for debugging purposes and not for the final foot module.

The wrist unit includes a 16 × 2 LCD a number of user input buttons/switches, status-linked LEDs, and a Bluetooth transceiver (see Figure 2). The three buttons and switch are used in Configuration mode. Additionally, we included the following LEDs: a red LED on the board that toggles every time a step is detected; a yellow LED that toggles every time a packet is received via Bluetooth; and a green “keep alive” LED. The software on the microcontroller manages all of these tasks, which we cover in the next section.

The complete article appears in Circuit Cellar 293 (December 2014).

Read Your Technical Documentation (EE Tip #145)

Last year we had a problem that showed up only after we started making the product in 1,000-piece runs. The problem was that some builds of the system took a very long time to power up. We had built about 10 prototypes, tested the design over thousands of power ups, and it tested just fine (thanks to POC-IT). Then the 1,000-piece run uncovered about a half-dozen units that had variable power-up times—ranging from a few seconds to more than an hour! Replacing the watchdog chip that controlled the RESET line to an ARM9 processor fixed the problem.

But why did these half dozen fail?

Many hours into the analysis we discovered that the RESET line out of the watchdog chip on the failed units would pulse but stay low for long periods of time. A shot of cold air instantly caused the chip to release the RESET. Was it a faulty chip lot? Nope. Upon a closer read of the documentation, we found that you cannot have a pull-up resister on the RESET line. For years we always had pull-ups on RESET lines. We’d missed that in the documentation.

Like it or not, we have to pour over the documentation of the chips and software library calls we use. We have to digest the content carefully. We cannot rely on what is intuitive.

Finally, and this is much more necessary than in years past, we have to pour over the errata sheets. And we need to do it before we commit the design. A number of years ago, a customer designed a major new product line around an Atmel ARM9. This ARM9 had the capability of directly addressing NOR memory up to 128 MB. Except for the fact that the errata said that due to a bug it could only address 16 MB. Ouch! Later we had problems with the I2C bus in the same chip. At times, the bus would lock up and nothing except a power cycle would unlock it. Enter the errata. Under some unmentioned conditions the I2C state machine can lock up. Ouch! In this case, we were able to use a bit-bang algorithm rather than the built-in I2C—but obviously at the cost of money, scheduling, and real time.—Bob Japenga, CC25, 2013

Got Problematic Little Bits? (EE Tip #142)

While testing a project, something strange happened (see the nearby image). The terminal showed nonsense, but the logic analyzer properly displayed “Elektor” in ASCII. The latter also indicated that the UART was operating at 4800 baud instead of the 19200 baud that I had programmed (at least that’s what I thought), a difference with a factor of four. The change I had made in my code was a fourfold increase in the clock speed of the dsPIC. The conclusion I had to arrive at is that the clock speed was not being changed. But why not?

Source: Raymond Vermeulen (Elektor, October 2011)

Source: Raymond Vermeulen (Elektor, October 2011)

The inspiration came, and where else, in the shower. In a hobby project, I had used an ATmega32u4 with a bootloader whose only limitation was being unable to program the fuse bits. “That’s not going to be…” I was thinking. But yes, the bootloader I used in my dsPIC cannot program the configuration bits either. Experienced programmers would have realized that long ago, but we all have our off-days. (The solution is to use a “real” programmer, such as the ICD3).—By Raymond Vermeulen (Elektor Labs, Elektor, October 2011)


A Coding Interface for an Evaluation Tool

John Peck, a test engineer at Knowles Electronics in Itasca, IL, has used ASCII interfaces to test equipment since he was a graduate student.

“I love test equipment with open, well-documented, ASCII command sets,” he says. “The plain text commands give a complicated instrument a familiar interface and an easy way to automate measurements.”

So when Peck needed to automate the process of reading his ultrasonic range finder’s voltage output, he wanted an ASCII interface to a voltmeter. He also wanted the meter to convert volts into distance, so he added an Atmel AVR Butterfly microcontroller into the mix (see Photo 1). “I thought it would be easy to give it a plain text interface to a PC,” he says.

Atmel AVR Butterfly

Atmel AVR Butterfly

The project became a bit more complex than he expected. But ultimately, Peck says, he came up came up with “a simple command interface that’s easy to customize and extend. It’s not at the level of a commercial instrument, but it works well for sending a few commands and getting some data back.”

If you would like to learn more about how to send commands from a PC to the AVR Butterfly and the basics of using the credit card-sized, single-board microcontroller to recognize, parse, and execute remote commands, read Peck’s article about his project in Circuit Cellar’s May issue.

In the italicized excerpts below, he describes his hardware connections to the board and the process of receiving remote characters (the first step in receiving remote commands). Other topics you’ll find in the full article include setting up a logging system to understand how commands are being processed, configuring the logger (which is the gatekeeper for messages from other subsystems), recognizing and adding commands to extend the system, and sending calibration values.

Peck programmed his system so that it has room to grow and can accommodate his future plans:

“I built the code with AVR-GCC, using the -Os optimization level. The output of avr-gcc –version is avr-gcc (Gentoo 4.6.3 p1.3, pie-0.5.1) 4.6.3.

“The resulting memory map file shows a 306-byte .data size, a 49-byte .bss size, and a 7.8-KB .text size. I used roughly half of the AVR Butterfly’s flash memory and about a third of its RAM. So there’s at least some space left to do more than just recognizing commands and calibrating voltages.”

“I’d like to work on extending the system to handle more types of arguments (e.g., signed integers and floats). And I’d like to port the system to a different part, one with more than one USART. Then I could have a dedicated logging port and log messages wouldn’t get in the way of other communication. Making well-documented interfaces to my designs would help me with my long-term goal of making them more modular.”

These are the connections needed for Atmel’s AVR Butterfly. Atmel’s AVRISP mkII user’s guide stresses that the programmer must be connected to the PC before the target (AVR Butterfly board).

Figure 1: These are the connections needed for Atmel’s AVR Butterfly. Atmel’s AVRISP mkII user’s guide stresses that the programmer must be connected to the PC before the target (AVR Butterfly board).

The AVR Butterfly board includes an Atmel ATmega169 microcontroller and some peripherals. Figure 1 shows the connections I made to it. I only used three wires from the DB9 connector for serial communication with the PC. There isn’t any hardware handshaking. While I could also use this serial channel for programming, I find that using a dedicated programmer makes iterating my code much faster.

A six-pin header soldered to the J403 position enabled me to use Atmel’s AVRISP mkII programmer. Finally, powering the board with an external supply at J401 meant I wouldn’t have to think about the AVR Butterfly’s button cell battery. However, I did need to worry about the minimum power-on reset slope rate. The microcontroller won’t reset at power-on unless the power supply can ramp from about 1 to 3 V at more than 0.1 V/ms. I had to reduce a filter capacitor in my power supply circuit to increase its power-on ramp rate. With that settled, the microcontroller started executing code when I turned on the power supply.

After the hardware was connected, I used the AVR downloader uploader (AVRDUDE) and GNU Make to automate building the code and programming the AVR Butterfly’s flash memory. I modified a makefile template from the WinAVR project to specify my part, programmer, and source files. The template file’s comments helped me understand how to customize the template and comprehend the general build process. Finally, I used Gentoo, Linux’s cross-development package, to install the AVR GNU Compiler Collection (AVR-GCC) and other cross-compilation tools. I could have added these last pieces “by hand,” but Gentoo conveniently updates the toolchain as new versions are released.


Figure 2: This is the program flow for processing characters received over the Atmel AVR Butterfly’s USART. Sending a command terminator (carriage return) will always result in an empty Receive buffer. This is a good way to ensure there’s no garbage in the buffer before writing to it.

To receive remote commands, you begin by receiving characters, which are sent to the AVR Butterfly via the USART connector shown in Figure 1. Reception of these characters triggers an interrupt service routine (ISR), which handles them according to the flow shown in Figure 2. The first step in this flow is loading the characters into the Receive buffer.

Figure 3: The received character buffer and pointers used to fill it are shown. There is no limit to the size of commands and their arguments, as long as the entire combined string and terminator fit inside the RECEIVE_BUFFER_SIZE.

Figure 3: The received character buffer and pointers used to fill it are shown. There is no limit to the size of commands and their arguments, as long as the entire combined string and terminator fit inside the RECEIVE_BUFFER_SIZE.

Figure 3 illustrates the Receive buffer loaded with a combined string. The buffer is accessed with a pointer to its beginning and another pointer to the next index to be written. These pointers are members of the recv_cmd_state_t-type variable recv_cmd_state.

This is just style. I like to try to organize a flow’s variables by making them members of their own structure. Naming conventions aside, it’s important to notice that no limitations are imposed on the command or argument size in this first step, provided the total character count stays below the RECEIVE_BUFFER_SIZE limit.

When a combined string in the Receive buffer is finished with a carriage return, the string is copied over to a second buffer. I call this the “Parse buffer,” since this is where the string will be searched for recognized commands and arguments. This buffer is locked until its contents can be processed to keep it from being overwhelmed by new combined strings.

Sending commands faster than they can be processed will generate an error and combined strings sent to a locked parse buffer will be dropped. The maximum command processing frequency will depend on the system clock and other system tasks. Not having larger parse or receive buffers is a limitation that places this project at the hobby level. Extending these buffers to hold more than just one command would make the system more robust.

Editor’s Note: If you are interested in other projects utilizing the AVR Butterfly, check out the Talk Zombie, which won “Distinctive Excellence” in the AVR Design Contest 2006 sponsored by ATMEL and administered by Circuit Cellar. The ATmega169-based multilingual talking device relates ambient temperature and current time in the form of speech (English, Dutch, or French). 

Q&A: Andrew Godbehere, Imaginative Engineering

Engineers are inherently imaginative. I recently spoke with Andrew Godbehere, an Electrical Engineering PhD candidate at the University of California, Berkeley, about how his ideas become realities, his design process, and his dream project. —Nan Price, Associate Editor

Andrew Godbehere

Andrew Godbehere

NAN: You are currently working toward your Electrical Engineering PhD at the University of California, Berkeley. Can you describe any of the electronics projects you’ve worked on?

ANDREW: In my final project at Cornell University, I worked with a friend of mine, Nathan Ward, to make wearable wireless accelerometers and find some way to translate a dancer’s movement into music, in a project we called CUMotive. The computational core was an Atmel ATmega644V connected to an Atmel AT86RF230 802.15.4 wireless transceiver. We designed the PCBs, including the transmission line to feed the ceramic chip antenna. Everything was hand-soldered, though I recommend using an oven instead. We used Kionix KXP74 tri-axis accelerometers, which we encased in a lot of hot glue to create easy-to-handle boards and to shield them from static.

This is the central control belt-pack to be worn by a dancer for CUMotive, the wearable accelerometer project. An Atmel ATmega644V and an AT86RF230 were used inside to interface to synthesizer. The plastic enclosure has holes for the belt to attach to a dancer. Wires connect to accelerometers, which are worn on the dancer’s limbs.

This is the central control belt-pack to be worn by a dancer for CUMotive, the wearable accelerometer project. An Atmel ATmega644V and an AT86RF230 were used inside to interface to synthesizer. The plastic enclosure has holes for the belt to attach to a dancer. Wires connect to accelerometers, which are worn on the dancer’s limbs.

The dancer had four accelerometers connected to a belt pack with an Atmel chip and transceiver. On the receiver side, a musical instrument digital interface (MIDI) communicated with a synthesizer. (Design details are available at http://people.ece.cornell.edu/land/courses/ece4760/FinalProjects/s2007/njw23_abg34/index.htm.)

I was excited about designing PCBs for 802.15.4 radios and making them work. I was also enthusiastic about trying to figure out how to make some sort of music with the product. We programmed several possibilities, one of which was a sort of theremin; another was a sort of drum kit. I found that this was the even more difficult part—not just the making, but the making sense.

When I got to Berkeley, my work switched to the theoretical. I tried to learn everything I could about robotic systems and how to make sense of them and their movements.

NAN: Describe the real-time machine vision-tracking algorithm and integrated vision system you developed for the “Are We There Yet?” installation.

ANDREW: I’ve always been interested in using electronics and robotics for art. Having a designated emphasis in New Media on my degree, I was fortunate enough to be invited to help a professor on a fascinating project.

This view of the Yud Gallery is from the installed camera with three visitors present. Note the specular reflections on the floor. They moved throughout the day with the sun. This movement needed to be discerned from a visitor’s typical movement .

This view of the Yud Gallery is from the installed camera with three visitors present. Note the specular reflections on the floor. They moved throughout the day with the sun. This movement needed to be discerned from a visitor’s typical movement .

For the “Are We There Yet?” installation, we used a PointGrey FireFlyMV camera with a wide-angle lens. The camera was situated a couple hundred feet away from the control computer, so we used a USB-to-Ethernet range extender to communicate with the camera.

We installed a color camera in a gallery in the Contemporary Jewish Museum in San Francisco, CA. We used Meyer Sound speakers with a high-end controller system, which enabled us to “position” sound in the space and to sweep audio tracks around at (the computer’s programmed) will. The Meyer Sound D-Mitri platform was controlled by the computer with Open Sound Control (OSC).

This view of the Yud Gallery is from the perspective of the computer running the analysis. This is a probabilistic view, where the brightness of each pixel represents the “belief” that the pixel is part of an interesting foreground object, such as a pedestrian. Note the hot spots corresponding nicely with the locations of the visitors in the image above.

This view of the Yud Gallery is from the perspective of the computer running the analysis. This is a probabilistic view, where the brightness of each pixel represents the “belief” that the pixel is part of an interesting foreground object, such as a pedestrian. Note the hot spots corresponding nicely with the locations of the visitors in the image above.

The hard work was to then program the computer to discern humans from floors, furniture, shadows, sunbeams, and cloud reflections. The gallery had many skylights, which made the lighting very dynamic. Then, I programmed the computer to keep track of people as they moved and found that this dynamic information was itself useful to determine whether detected color-perturbance was human or not.

Once complete, the experience of the installation was beautiful, enchanting, and maybe a little spooky. The audio tracks were all questions (e.g., “Are we there yet?”) and they were always spoken near you, as if addressed to you. They responded to your movement in a way that felt to me like dancing with a ghost. You can watch videos about the installation at www.are-we-there-yet.org.

The “Are We There Yet?” project opens itself up to possible use as an embedded system. I’ve been told that the software I wrote works on iOS devices by the start-up company Romo (www.kickstarter.com/projects/peterseid/romo-the-smartphone-robot-for-everyone), which was evaluating my vision-tracking code for use in its cute iPhone rover. Further, I’d say that if someone were interested, they could create a similar pedestrian, auto, pet, or cloud-tracking system using a Raspberry Pi and a reasonable webcam.

I may create an automatic cloud-tracking system to watch clouds. I think computers could be capable of this capacity for abstraction, even though we think of the leisurely pastime as the mark of a dreamer.

NAN: Some of the projects you’ve contributed to focus on switched linear systems, hybrid systems, wearable interfaces, and computation and control. Tell us about the projects and your research process.

ANDREW: I think my research is all driven by imagination. I try to imagine a world that could be, a world that I think would be nice, or better, or important. Once I have an idea that captivates my imagination in this way, I have no choice but to try to realize the idea and to seek out the knowledge necessary to do so.

For the wearable wireless accelerometers, it began with the thought: Wouldn’t it be cool if dance and music were inherently connected the way we try to make it seem when we’re dancing? From that thought, the designs started. I thought: The project has to be wireless and low power, it needs accelerometers to measure movement, it needs a reasonable processor to handle the data, it needs MIDI output, and so forth.

My switched linear systems research came about in a different way. As I was in class learning about theories regarding stabilization of hybrid systems, I thought: Why would we do it this complicated way, when I have this reasonably simple intuition that seems to solve the problem? I happened to see the problem a different way as my intuition was trying to grapple with a new concept. That naive accident ended up as a publication, “Stabilization of Planar Switched Linear Systems Using Polar Coordinates,” which I presented in 2010 at Hybrid Systems: Computation and Control (HSCC) in Stockholm, Sweden.

NAN: How did you become interested in electronics?

ANDREW: I always thought things that moved seemingly of their own volition were cool and inherently attention-grabbing. I would think: Did it really just do that? How is that possible?

Andrew worked on this project when computers still had parallel ports. a—This photo shows manually etched PCB traces for a digital EKG (the attempted EEG) with 8-bit LED optoisolation. The rainbow cable connects to a computer’s parallel port. The interface code was written in C++ and ran on DOS. b—The EKG circuitry and digitizer are shown on the left. The 8-bit parallel computer interface is on the right. Connecting the two boards is an array of coupled LEDs and phototransistors, encased in heat shrink tubing to shield against outside light.

Andrew worked on this project when computers still had parallel ports. a—This photo shows manually etched PCB traces for a digital EKG (the attempted EEG) with 8-bit LED optoisolation. The rainbow cable connects to a computer’s parallel port. The interface code was written in C++ and ran on DOS. b—The EKG circuitry and digitizer are shown on the left. The 8-bit parallel computer interface is on the right. Connecting the two boards is an array of coupled LEDs and phototransistors, encased in heat shrink tubing to shield against outside light.

Electric rally-car tracks and radio-controlled cars were a favorite of mine. I hadn’t really thought about working with electronics or computers until middle school. Before that, I was all about paleontology. Then, I saw an episode of Scientific American Frontiers, which featured Alan Alda excitedly interviewing RoboCup contestants. Watching RoboCup [a soccer game involving robotic players], I was absolutely enchanted.

While my childhood electronic toys moved and somehow acted as their own entities, they were puppets to my intentions. Watching RoboCup, I knew these robots were somehow making their own decisions on-the-fly, magically making beautiful passes and goals not as puppets, but as something more majestic. I didn’t know about the technical blood, sweat, and tears that went into it all, so I could have these romantic fantasies of what it was, but I was hooked from that moment.

That spurred me to apply to a specialized science and engineering high school program. It was there that I was fortunate enough to attend a fabulous electronics class (taught by David Peins), where I learned the basics of electronics, the joy of tinkering, and even PCB design and assembly (drilling included). I loved everything involved. Even before I became academically invested in the field, I fell in love with the manual craft of making a circuit.

NAN: Tell us about your first design.

ANDREW: Once I’d learned something about designing and making circuits, I jumped in whole-hog, to a comical degree. My very first project without any course direction was an electroencephalograph!

I wanted to make stuff move on my computer with my brain, the obvious first step. I started with a rough design and worked on tweaking parameters and finding components.

In retrospect, I think that first attempt was actually an electromyograph that read the movements of my eye muscles. And it definitely was an electrocardiograph. Success!

Someone suggested that it might not be a good idea to have a power supply hooked up in any reasonably direct path with your brain. So, in my second attempt, I tried to make something new, so I digitized the signal on the brain side and hooked it up to eight white LEDs. On the other side, I had eight phototransistors coupled with the LEDs and covered with heat-shrink tubing to keep out outside light. That part worked, and I was excited about it, even though I was having some trouble properly tuning the op-amps in that version.

NAN: Describe your “dream project.”

ANDREW: Augmented reality goggles. I’m dead serious about that, too. If given enough time and money, I would start making them.

I would use some emerging organic light-emitting diode (OLED) technology. I’m eyeing the start-up MicroOLED (www.microoled.net) for its low-power “near-to-eye” display technologies. They aren’t available yet, but I’m hopeful they will be soon. I’d probably hook that up to a Raspberry Pi SBC, which is small enough to be worn reasonably comfortably.

Small, high-resolution cameras have proliferated with modern cell phones, which could easily be mounted into the sides of goggles, driving each OLED display independently. Then, it’s just a matter of creativity for how to use your newfound vision! The OpenCV computer vision library offers a great starting point for applications such as face detection, image segmentation, and tracking.

Google Glass is starting to get some notice as a sort of “heads-up” display, but in my opinion, it doesn’t go nearly far enough. Here’s the craziest part—please bear with me—I’m willing to give up directly viewing the world with my natural eyes, I would be willing to have full field-of-vision goggles with high-resolution OLED displays with stereoscopic views from two high-resolution smartphone-style cameras. (At least until the technology gets better, as described in Rainbows End by Vernor Vinge.) I think, for this version, all the components are just now becoming available.

Augmented reality goggles would do a number of things for vision and human-computer interaction (HCI). First, 3-D overlays in the real world would be possible.

Crude example: I’m really terrible with faces and names, but computers are now great with that, so why not get a little help and overlay nametags on people when I want? Another fascinating thing for me is that this concept of vision abstracts the body from the eyes. So, you could theoretically connect to the feed from any stereoscopic cameras around (e.g., on an airplane, in the Grand Canyon, or on the back of some wild animal), or you could even switch points of view with your friend!

Perhaps reality goggles are not commercially viable now, but I would unabashedly use them for myself. I dream about them, so why not make them?

Arduino Uno Blueprint — Free Download

Elektor.Labs recently produced an Arduino Uno blueprint poster for element14. The poster details everything you need to know about the Arduino Uno.

Download it for free here.

Download your Arduino Uno poster

Download your Arduino Uno poster

The poster also includes coding notes that will get you working with your Arduino Uno in no time.

About the Arduino Uno:

  • Core Architecture: AVR
  • Core Sub-Architecture: megaAVR
  • Silicon Core: ATmega328
  • Features: The Arduino Uno is powered via USB or an external supply. It’s programmed with Arduino software.

Recent Arduino-related articles from Circuit Cellar:


CC279: Working with RobotBasic

In Circuit Cellar’s October issue, columnist Jeff Bachiochi introduces readers to RobotBasic, a free robot control programming language that you can use to control real or simulated robots, and provides a detailed explanation on how to use it.

Photo 1: This army of robots all use the RobotBASIC Robot Operating System (RROS). Note the large robot has an arm located just above the wheels that is controlled by a second RROS. It uses an on-board laptop running a RobotBASIC (RB) application. The small robots are all controlled via a Bluetooth link from an external PC running an RB application.

Photo 1: This army of robots all use the RobotBASIC Robot Operating System (RROS). Note the large robot has an arm located just above the wheels that is controlled by a second RROS. It uses an on-board laptop running a RobotBASIC (RB) application. The small robots are all controlled via a Bluetooth link from an external PC running an RB application.

“About five years ago, John Blankenship and Samuel Mishal coauthored Robot Programmer’s Bonanza, a book explaining the freely available RobotBASIC IDE they offer. RobotBASIC (RB) is a powerful language that enables you to use standard BASIC syntax (or a modified C-style syntax ( i.e., ++, +=, !=, and &&) to quickly write a program to control and simulate a robot with many types of sensors,” Bachiochi says. “This is a great tool to teach programming.”

RB, with more than 800 commands and functions, can also be a tool for non-robotic applications such as tackling tough engineering problems or creating animated simulations, Bachiochi says.

It’s likely that anyone who starts out simulating with RobotBasic will eventually want to control real robot hardware.

“There is no need to worry,” Bachiochi says. “RB was written to make use of a PC’s I/O. The parallel port is a good source for digital I/O and the serial port is well suited for external communication. The same commands used for robot movement in the simulator can alternatively be sent to a serial port establishing a sort of serial robot command protocol. But, tethered robots aren’t so cool, and many robots are too small to tote around a PC as their “great and powerful Oz.”

“Luckily, much has changed since RB’s original concepts were put into practice,” he adds. “We all know what has happened to these PC ports. They’ve fallen under the USB’s mighty power. RB doesn’t care whether it is talking with a serial port or a USB virtual serial port. USB offers inexpensive Bluetooth dongles and can create wireless serial communication to external devices.”

Bachiochi also discusses the RobotBASIC Robot Operating System (RROS), created to support RB’s serial robot command protocol. The module is available from RB’s website.

“The RROS is a preprogrammed module that can receive communication from RB, interpret commands, and directly interface to hardware,” Bachiochi says. “The module is a Pololu Baby Orangutan robot controller, consisting of an Atmel ATmega328P microcontroller and a Pololu TB6612 dual motor driver carrier in a DIP24 form factor. You can use the module (which comes preprogrammed with the RROS) to build robots like those shown in Photo 1.”

Bachiochi’s look at RB and RROS is a two-part series. In Part 2, appearing in Circuit Cellar’s November issue, Bachiochi will explain how to translate between RROS and the iRobot Create Open Interface.

So, if you want explore a programming language that can take you from simulated to real-world robotics control, check out the October and November issues.


Microcontroller-Based Heating System Monitor

Checking a heating system’s consumption is simple enough.

Heating system monitor

Determining a heating system’s output can be much more difficult, unless you have this nifty design. This Atmel ATmega microcontroller-based project enables you to measure heat output as well as control a circulation pump.

Heating bills often present unpleasant surprises. Despite your best efforts to economise on heating, they list tidy sums for electricity or gas consumption. In this article we describe a relatively easy way to check these values and monitor your consumption almost continuously. All you need in order to determine how much heat your system delivers is four temperature sensors, a bit of wiring, and a microcontroller. There’s no need to delve into the electrical or hydraulic components of your system or modify any of them.

A bit of theory
As many readers probably remember from their physics lessons, it’s easy to calculate the amount of heat transferred to a medium such as water. It is given by the product of the temperature change ΔT, the volume V of the medium, and the specific heat capacity CV of the medium. The power P, which is amount of energy transferred per unit time, is:

P= ΔT × CV × V // Δt

With a fluid medium, the term V // Δt can be interpreted as a volumetric flow Vt. This value can be calculated directly from the flow velocity v of the medium and the inner diameter r of the pipe. In a central heating system, the temperature difference ΔT is simply the difference between the supply (S) and return (R) temperatures. This yields the formula:

P = (TS – TR) × CV × v × pr2

The temperatures can easily be measured with suitable sensors. Flow transducers are available for measuring the flow velocity, but installing a flow transducer always requires drilling a hole in a pipe or opening up the piping to insert a fitting.

Measuring principle
Here we used a different method to determine the flow velocity. We make use of the fact that the supply and return temperatures always vary by at least one to two degrees due to the operation of the control system. If pairs of temperature sensors separated by a few metres are mounted on the supply and return lines, the flow velocity can be determined from the time offset of the variations measured by the two sensors…

As the water flows through the pipe with a speed of only a few metres per second, the temperature at sensor position S2 rises somewhat later than the temperature at sensor position S, which is closer to the boiler.

An ATmega microcontroller constantly acquires temperature data from the two sensors. The time delay between the signals from a pair of sensors is determined by a correlation algorithm in the signal processing software, which shifts the signal waveforms from the two supply line sensors relative to each other until they virtually overlap.The temperature signals from the sensors on the return line are correlated in the same manner, and ideally the time offsets obtained for the supply and return lines should be the same.

To increase the sensitivity of the system, the return line sensor signals are applied to the inputs of a differential amplifier, and the resulting difference signal is amplified. This difference signal is also logged as a function of time. The area under the curve of the difference signal is a measure of the time offset of the temperature variations…

Hot water please
If the heating system is also used to supply hot water for domestic use, additional pipes are used for this purpose. For this reason, the PCB designed by the author includes inputs for additional temperature sensors. It also has a switched output for driving a relay that can control a circulation pump.

Under certain conditions, controlling the circulation pump can save you a lot of money and significantly reduce CO2 emissions. This is because some systems have constant hot water circulation so users can draw hot water from the tap immediately. This costs electricity to power the pump, and energy is also lost through the pipe walls. This can be remedied by the author’s circuit, which switches on the circulation pump for only a short time after the hot water tap is opened. This is detected by the temperature difference between the hot water and cold water supply lines…

Circuit description
The easiest way to understand the schematic diagram is to follow the signal path. It starts at the temperature sensors connected to the circuit board, which are NTC silicon devices.

Heating system monitor schematic

Their resistance varies by around 0.7–0.8% per degree K change in temperature. For example, the resistance of a KT110 sensor is approximately 1.7 kΩ at 5 °C and approximately 2.8 kΩ at 70 °C.

The sensor for supply temperature S forms a voltage divider with resistor R37. This is followed by a simple low-pass filter formed by R36 and C20, which filters out induced AC hum. U4a amplifies the sensor signal by a factor of approximately 8. The TL2264 used here is a rail-to-rail opamp, so the output voltage can assume almost any value within the supply voltage range. This increases the absolute measurement accuracy, since the full output signal amplitude is used. U4a naturally needs a reference voltage on its inverting input. This is provided by the combination of R20, R26 and R27. U5b acts as an impedance converter to minimise the load on the voltage divider…

Thermal power

PC connection
The circuit does not have its own display unit, but instead delivers its readings to a PC via an RS485 bus. Its functions can also be controlled from the PC. IC U8 looks after signal level conversion between the TTL transmit and receive lines of the ATmega microcontroller’s integrated UART and the differential RS485 bus. As the bus protocol allows several connected (peer) devices to transmit data on the bus, transmit mode must be selected actively via pin 3. Jumper JP3 must be fitted if the circuit is connected to the end of the RS485 bus. This causes the bus to be terminated in 120 Ω, which matches the characteristic impedance of a twisted-pair line…

[Via Elektor-Projects.com]

Q&A: Colin O’Flynn (Engineering and “Pure” Research)

Colin O’Flynn

NAN: Where are you located?

COLIN: I’m currently living in Halifax, Nova Scotia, Canada. I’m originally from Hamilton, Ontario, Canada, and had been living in Edinburgh, Scotland for almost two years before I moved to Halifax.

NAN: How did you become interested in electronics?

COLIN: Like many people in this area, I did start at a very young age. If I had to pin one event as the starting of my life-long interest in electronics, it was getting one of those “20-in-1” kits from RadioShack as a present. My parents always encouraged my interest in electronics, but as they were a commercial airline pilot and a chartered accountant, it wasn’t the case of them initially pushing me in the same direction they started!

My dad found me a few small “learn-to-solder” kits, which I enjoyed. At age 8, I assembled my first real kit, the LED-Tric Christmas tree featured in the December 1994 issue of Popular Electronics. My parents have kept bringing that tree out as a Christmas decoration every year since, and it still works.

Besides my parents, I also had help from local people interested in electronics and became friends with many of the local electronics store owners. I spent many hours building projects from magazines like Electronics Now, Popular Electronics, Circuit Cellar, and the various Forrest M. Mims III books. I find it interesting to see the recent surge in “maker” culture. It’s something that has really been going on for years. Growing up, there wasn’t such a thing as maker spaces, but there were local people with interesting workshops who would share projects. It’s great to see this a little more mainstream now, as it means more opportunities for people to get involved at any stage of their life in this fascinating world.

NAN: What is your current occupation? Are you still consulting for projects related to 802.15.4 wireless communications?

COLIN: I’m currently a graduate student at Dalhousie University pursuing a PhD. I decided to go back to school for the chance to do more “pure” research. It’s also fun to have access to a range of tools I wouldn’t otherwise get—the lab I sit in has an anechoic chamber, for example. And we have most of the latest versions of high-end software like MATLAB (including most of the add-ons), 3-D electromagnetic antenna simulation software, FPGA design software, and so forth.


I’m only loosely involved in 802.15.4 projects for now, and not actively following the latest developments and standards. Having said that, a friend of mine has gotten involved in creating small, wireless modules called RadioBlocks.

They use an IEEE 802.15.4 radio combined with a small ARM Cortex-M0 microcontroller. They use an open-source mesh networking software we created called SimpleMesh, so most of my recent work on 802.15.4 has been around this project. The mesh software is designed to do the basic job of sending a block of data to another node, and otherwise staying out of the way. I previously did a lot of work using IPv6 on such small sensor networks, but haven’t been active in that area lately.

At Dalhousie, I’m working on the area of side-channel analysis of cryptographic systems, specifically power analysis. This area has a simple idea: if you have a microcontroller or other embedded controller, it typically has some internal data bus. When those data lines switch state, it takes power. But the power actually depends on the data. Imagine a databus switching from all 1s to all 0s in a clock cycle, compared to staying at all 1s. Likewise, different operations, such as a MUL compared to a LDI, have different power signatures. If you measure the current consumption on each clock cycle, you can learn something about the data being processed, and then often the secret key. Practically speaking, you can measure this current even with an electromagnetic probe, so you don’t need to physically modify the circuit board.

I gave a presentation at Black Hat Abu Dhabi in December 2012 about some of this work. If you are interested, the slides and white paper are available online at Blackhat.com, or from my personal website NewAE.com. You can see the photo above showing an example of attacking a microcontroller-based smart card. The capture software might look something like where you can see different computations the card is performing directly from the power trace. In this case, each burst is a round of the AES-128 computation.

NAN: Many of your projects include Atmel microcontrollers. Why Atmel?

COLIN: It’s no secret I’ve been a big fan of Atmel’s AVR microcontroller, but it wasn’t my first. I don’t know the exact lineage of my microcontroller work, but one of the first things I learned on was an AMD 2900 Evaluation and Learning Kit. A local electronics store happened to have it in stock. They had gotten it from someone cleaning out old inventory, as even at that time it was old. I added heatsinks, as the several amps it drew when powered with 5 V made a lot of those chips very hot. And, of course, you had to keep the entire board powered up if you didn’t want to lose you program you’d been manually entering. From there, I moved onto a Z80 trainer board, which let you program with a hex-entry keypad, and eventually I moved onto programming it from the computer. I designed a Z80 computer board but never built it—I still have the piece of transparency with the taped out PCB design and photosensitive PCB on which I was to expose it. That’s more than 10 years old now, so I suspect the chemicals in it have degraded a little!

I forget exactly why I picked up the AVRs, but I had one of the first AVRs released, Atmel’s AT90S1200, which I programmed in Assembly. After Assembly, I programmed them in BASIC (using MCS Electronics’s BASCOM-AVR), going as far to write a neural network in

BASCOM-AVR. Even today, I think BASIC gets a bad rap. It was almost the original “Arduino” environment, as you could drop down LCD drivers, ADC, and so forth without ever knowing much about how it worked, and with a really intuitive feel. I moved onto C sometime later, and used C almost exclusively for embedded development since. For some time, I was fairly involved in the tools used in the AVR world, such as WinAVR. Atmel donated a considerable amount of equipment to me, as at the time I was a high school student using these devices for science fair projects. I think that’s a great example of how such corporate donations pay off. I’ve almost exclusively used AVR processors since I am so familiar with them because of that. In addition, as a student with little money but lots of time, I was happy to spend hours each day on AVRFreaks.net or working on open-source tools. While Atmel probably ended up giving me around $3,000 worth of tools, I’m sure the value of work I performed for free in terms of open-source tool contributions or forum posts would be worth many times this.

A funny story around all this work: In undergrad, we used the Atmel AVR microcontrollers. During one of the first labs they distributed a tutorial on how to set up the WinAVR tools and compile your first program. As it turned out, this guide was something I wrote years prior and had posted to the WinAVR website. Sufficient to say, I did OK in that class.

NAN: Tell us about NewAE.com. What kind of information is available on the site?

COLIN: I’ve run NewAE.com since 2001, although it’s not really designed to be the type of website one checks for new content daily. If I’ve spent some time solving a problem that I think other people could use, I’ll put a post up. Sometimes this is a complete project, such as my IEEE 802.15.4 sniffer. Sometimes it’s just a small post, such as how to set up the AVR USB keyboard for 5-V operation, which wasn’t described in the manual. I also use it for keeping copies of any published papers or presentations.

I’ve more recently been posting some ongoing research to the site, including blog posts with ongoing projects, rather than just waiting until it’s completely finished! In that vein, I started a YouTube channel with some technical videos (www.youtube.com/user/colinpoflynn). A big collection of these are from when I taught a digital logic course and recorded all my presentations from that.

My content spans a huge range of topics—everything from showing my students how to get screen captures, to a demonstration of my soldering station, to recordings of my academic paper presentations. I don’t like duplicating work. I’ll only go to the effort of making a video or website post if I really couldn’t find the information elsewhere. Because of this, I don’t have one specific topic you could expect to learn about. I’ve never been aiming to be like EEVBlog!

NAN: You wrote “It’s a SNAP: A Flexible Communications Protocol” (Circuit Cellar 139, 2002) more than 10 years ago. Do you still use SNAP in any of your current projects?

COLIN: I have to admit that I haven’t used SNAP in probably eight years! Of course now, when needing to network devices, I’m more likely to turn to a wireless standard.

NAN: Your article “Open-Source AVR Development” (Circuit Cellar 196, 2006) provides an introduction to the AVR-GCC toolchain for AVR microcontrollers. The article references the Cygwin project and Sourceforge’s WinAVR project. How do these components work in the design?

COLIN: The Cygwin project is still something I use regularly, as it lets you run a variety of Unix-like tools on Windows. The Linux command line is extraordinarily powerful, and it is makes it simple to access things like C compilers, text parsing utilities, and scripting tools. With Cygwin, one can have a Linux-like experience under Windows, which I used in that article to build some of the tools you are developing for AVR. By comparison, WinAVR is just a number of prebuilt tools for the AVR development. While it’s more work to build your own tools, sometimes you require special features that were not available in the premade tools.

NAN: Atmel products have played a starring role in several articles you have published in Circuit Cellar. For example, an AT90S4433 microcontroller was featured in “It’s a SNAP: A Flexible Communications Protocol” (Circuit Cellar 139, 2002), an ATmega88 AVR RISC microcontroller was featured in “Digital Video in an Embedded System” (issue 184, 2005), an AT45DB041 DataFlash and an ATmega88 microcontroller were featured in “Open-Source AVR Development” (issue 187, 2006), and an AT90USBKEY demonstration board was featured in “Advanced USB Design Debugging” (issue 241, 2010). Why Atmel microcontrollers/boards? What do you prefer about these products?

COLIN: As I mentioned before, I have a long history with Atmel products. Because of this, I already have the debug toolchains for their chips and can get projects up very quickly.

When picking boards or products, one of the most important considerations for me is that readers can buy it easily. For me, this means I can get it at DigiKey (and I’ll check Farnell for our UK friends). Part of this comes from being in Canada, where DigiKey was one of the first distributors offering cheap and fast shipping to Canada.

NAN: Are you currently working on or planning any microprocessor-based projects?

Binary Explorer Board

COLIN: My current big project is something I designed over the summer of 2012. It’s called the Binary Explorer Board and is something I used when teaching a course in digital logic at Dalhousie University. I needed a simple, programmable logic board and nothing I could find was exactly right. In particular, I needed something with an integrated programmer, several switches and LEDs, and an integrated breadboard. The students needed to be able to use the breadboard without the CPLD to learn about discretely packaged parts. All the CPLD-based trainers I found didn’t have exactly what I wanted in this regard.

The embedded part is the USB interface using an Atmel AT90USB162 microcontroller, although I plan on later upgrading that to an XMEGA for lower cost and more code room. The firmware is powered by Dean Camera’s excellent open-source USB library called LUFA (www.fourwalledcubicle.com/LUFA.php). This firmware lets students program the CPLD on the board easily over USB. But the cool thing is you can go even further and use the device as a generic programmer for other AVRs or CPLDs/FPGAs. For example, you can mount an AVR on the breadboard, connect it to the USB interface, and program that through the Arduino IDE. The entire board would retail for $35 in single-unit quantity, so it’s cheaper than most textbooks. I’m working on making it a real product with Colorado Micro Devices right now.

The design environment is the standard Xilinx toolchain, although I’ve made a number of predefined projects to make it simple enough for students with zero previous design experience to use. The idea is to get students familiar with the real tools they might see in the industry. Around this project, it’s interesting to note I choose a Xilinx CPLD because of my familiarity with Xilinx devices and design tools. This familiarity comes from years ago when Xilinx donated to me a part for a project I was working on. Now throngs of students will be exposed to Xilinx devices, all because Xilinx was willing to donate some parts to a student.

There is always an assortment of half-finished projects, too. I started designing a battery tester, which could simulate characteristics you’d typically see when driving small wireless nodes from coin-cell batteries. I started planning on using an AVR USB microcontroller and doing all the data logging myself. I then found this LabJack device, which simplified my life a lot, as they had basically a generic USB-based logging/control module.

NAN: What do you consider to be the “next big thing” in the embedded design industry?

COLIN: Wireless and the “Internet of Things” will eventually be a big thing, which means design engineers will need to become more familiar with things like protocols and realistic transmission characteristics. I use the word “realistic,” as part of this world is separating hype from reality. There’s certainly a huge disconnect between the marketing hype around all these various wireless protocols and how well they work in practice. When designing a product that will use a wireless technology, it’s likely some commercial off-the-shelf (COTS) module will be used, so the engineer may think they can remain blissfully unaware of RF or networking things. But the engineer still needs to have a rough idea about how many devices might fit in an area on a single network or the advantage of selecting certain protocols.

Another thing of interest to me is programmable logic, such as FPGAs. It’s been interesting to see the tools that try to turn anybody into an FPGA designer becoming more mainstream, or at least letting you program FPGAs in more common languages (e.g., C/C++). They are still fairly specialized and more likely to be used by a hardware engineer looking to improve productivity, compared to a software engineer who needs to offload an algorithm into a FPGA. But I think they could fairly quickly get to the point that engineers with some FPGA experience could implement considerably more complex designs than they would have otherwise been able to had they been required to design everything from scratch.

In a somewhat similar vein, we are starting to see the availability of multicore devices coming down to embedded levels. Learning to program them in a way to take advantage of these new cores is a useful skill to pick up. I recently started using both the OpenMP API and Cilk++ development software on some of my programs. My work wasn’t targeting an embedded project, but instead regular full-size multicore computers, but it’s still a useful (and fairly simple) skill to pick up.

NAN: Tell us a little about your workbench. What are some of your favorite design tools?

Colin’s Workbench

COLIN: My initial workbench was the kitchen table, although other family members were frequently concerned about eating in the same space as these various items with warning labels about lead. My next workbench was a long, custom-built bench in Hamilton, Ontario. My current bench in Halifax was again custom-built, and I’ll take you few of its features. I’d like to point out by “custom-built” I mean built by myself with a jigsaw and some plywood, not an artesian finely crafted piece of furniture.

Due to a back injury, I work standing up, which you can’t see in the photo. It’s actually quite refreshing, and combined with a good quality antifatigue mat and stool to lean up against means I can work long hours without tiring. A cover comes down to hide everything in my desk, which was a feature partially required by my significant other, who didn’t want guests to see the typical mess of wires it contains. When closed, it also gives it some protection against any rogue water leaks. For my computer, I use a trackball instead of a mouse, and the keyboard and trackball are mounted on a plate tilted underneath the desk in a “negative” tilt angle, adjusted to most natural angle. And, because there is no way to see the keyboard while typing, it tends to keep anyone else from borrowing my computer to look something up!

I’ve wired a ground fault interrupter (GFI) into the desk, so all my power outlets are protected. If I ever did something dumb like dropping a scope ground on a live wire, the GFI socket would at least give me a hope of protecting the scope and myself. There are many outlets above and below the desk, and also a ground jack for the antistatic strap beside the thermal wire strippers. The outlets under the desk let me plug in things in a hidden manner—printers, USB hubs, and other permanent devices get wired in there. I’ve wired a number of USB hubs to the top of my desk, so I typically have around 12 free USB slots. You always seem to run out otherwise!

Most of my tools are off the desk and stored in the drawers to either side. I made the “drawers” just pieces of wood with minimal sides—the idea being most of the time you are placing PCBs or tools down, so the lack of high sides prevents you from piling too much into them! All the cables get stored on hooks to the left of my desk, and I’ve got a whiteboard that sticks up when I’m working on a problem.

SMD Organization

I store all my SMD parts in small envelopes stored in index card holders in the bottom left of my desk. While I’m not a static-phobic, I also didn’t want to use plastic film strips or plastic bags. So the paper envelopes at least I hope don’t generate much static, even if they don’t dissipate it. It’s very easy to label all your parts and also this system holds up to a high dynamic range of stock numbers. For example, capacitors get split into 10.1–99.9 nF, 100 nF, 100.1–999.9 nF, and so forth. Because you seem to end up with loads of 100-nF capacitors, they get their own envelope. It’s trivial to change this division around as you get more parts, or to group part sizes together.

In terms of interesting tools: my soldering station is probably my favorite tool, a Metcal MX500 I got used from eBay. The response time on these is unbelievable. I put a video up to show people just because I’ve been so impressed with it. There are other manufactures that now make stations with the same RF-heating technology I believe, and I always encourage everyone to try one. I’ve been using the DG8SAQ Vector Network Analyzer (VNWA) for a while too. It’s a very affordable way to get familiar with VNA and RF measurements. It’s especially fun to follow along with some of the “Darker Side” columns in Circuit Cellar. Rather than just hearing about the mysterious world of RF, you can do experiments like viewing the response of several different decoupling capacitors mounted in parallel. I’ve got an old TiePie TiePieSCOPE HS801 parallel-port oscilloscope mounted underneath my desk, and still use it today. A lot of my work is digital, so have an Intronix LogicPort digital analyzer, a Beagle USB 480 protocol analyzer, and oodles of microcontroller programming/debug tools from different manufacturers.