Rad-Tolerant megaAVR MCU for Space Applications

Atmel Corp. is now shipping the ATmegaS128 microcontroller targeting next-generation space applications. Atmel’s first Rad-Tolerant device, ATmegaS128 delivers full wafer lot traceability, a 64-lead  CQFP, space screening, space qualification according to QML and ESCC flow, and total ionizing dose up to 30 Krad (Si) for space applications.

The ATmegaS128 is available in a ceramic hermetic packaging and is pin-to-pin and drop-in compatible with existing ATmega128 MCUs. This provides flexibility between commercial and qualified devices and thus enables faster time-to-market and lower development costs.

Features and specs:

  • High-performance, low-power Atmel AVR 8-bit MCU
  • High endurance, non-volatile memory
  • Robust peripherals including 8- and 16-bit timers/counters, 6 PWM channels, 8-channel, 10-bit ADC, TWI/USARTs/SPI serial interface, programmable watchdog timer, on-chip analog compactor
  • Power-on reset and programmable brown-out detection
  • Internal calibrated RC oscillator
  • External and internal interrupt sources
  • Six sleep modes
  • Power-down, standby and extended standby

A complete STK600 starter kit and development system for the ATmegaS128 AVR MCU is available. You can design with an industrial version of the ATmega128—with the exact pin-out of the ATmegaS128—to save costs. The new AVRs are supported by the proven Atmel Studio IDP for developing and debugging Atmel SMART ARM processor-based MCUs and Atmel AVR MCU applications, along with the Atmel Software Framework.

Source: Atmel

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]