1 2 3 Previous Next

Energy Harvesting Solutions

109 posts

We Have A Winner!

Posted by doctorcdf Aug 20, 2013
Good morning -
grandprize.jpgFirst and foremost, a big thank you to all of the Energy Harvesting Challenge participants: we have been impressed with the way their ingenuity and efforts have pushed the frontiers of this technology.
As ever, it's been difficult to select a winner.
Monte Chan has been a dynamic presence throughout this event, and his batteryless wireless remote control points the way to the future. We're glad he continues to experiment with the technology although the competition has formally ended.
However, our choices for the grand prize are Wojciech Gelmuda's Carbon Monoxide Detector and Victor Sluiter's Egg Timer. These projects fulfil the stated goal of providing a practical prototype of a device that could be powered by Energy Harvesting.  Shortly, both Wojciech and Victor will be receiving bundles from Würth Elektronik, Energy Micro and Linear Technology.  The bundle includes boards, gift certificates and other cool gear.
Again, our sincere congratulations to both Wojciech and Victor.

Current News

web imidi1.jpg

The next IDIOTic item is the parasitically powered Inverted MIDI Slave Unit.

This unit can be used for lots of different purposes ranging from just a simple status monitor or a device to control lights and the light's brightness, pan and tilt or to drive more complex items such as musical synthesizers and large public displays.

The picture above shows it displaying received MIDI messages. Great for testing and diagnostics.


MIDI (Music Instrument Digital Interface) is a current loop interface used for connecting electronic musical instruments and control devices together.

MIDI uses optocouplers to provide electrical isolation between devices.

It is just a 31,250 bps serial communication over a current loop.

The odd 31,250 bit rate was selected to keep costs low (back in the 1980's) by enabling its timebase to be derived from a 1MHz clock source that is divided by 32.

1,000,000/32 = 31,2500

The specification stipulates that it uses a 5mA current loop.

It uses current on to represent a logical '0' and an current off for a logical '1'.

The attached slave unit uses an optocoupler such as a Sharp PC900 to convert theses current states into logic level voltages that can then be decoded using standard UART.

The current control is done via a 5V voltage serially feeding two 220 ohm resistors in the master unit and a 220 ohm resistor and optocoupler diode at the Slave.


With this arrangement when idle there is no current passing and hence no energy to harvest. This the opposite to standard industrial and TTY current loops.

By inverting the signalling arrangement (to align with standard current interfaces) we can provide harvestable power idle state.

If desired electrical isolation can be retained with the addition of an additional power supply to provide isolated power in the slave device.



web imidi0.jpg

This is a picture of the MIDI interface PCB made for the STK3700.

It can been seen populated and connected in the first picture of this article.


The Current Loop energy harvester is connected in series in the current loop replacing the slave's 220 ohm resistor.

With the diode drop energy harvesting system the available power is about

P = VI

0.6 x 0.005 = 3mW.


This is enough to power to initialise and operate EFM32 on a periodic basis.

To operate on a continuous or more frequent basis more power is required.

This can be addressed from several different fronts;

     1. The inverted MIDI signalling can have its current increased by the adjustment of the inline current control resistors.

     This current should not be increased to more than 20mA to exceed the Energy Harvester's rating. I am sucessfully using 15mA (for 9mW).


     2. Power consumption of the slave unit be reduced.

     The largest burden is the optocoupler. It is currently drawing 2.3mA (@VMCU).

     It can be replaced with a digital isolator that draws about 0.3mA or other feasible option.


     3. The use of the LEUART is not an option.

     The LEUART is limited to 9600 baud and MIDI operates at 31,2500 baud thus require the unit to operate with a standard UART in Energy Mode 1.

Piezo de resistance!

Here is a demonstration of a very basic piezo speaker powering the Energy Harvesting Solution To Go Kit.



By bending its diaphragm backwards and forwards by with just my fingers yields over 10 volts peak-peak and enough current to be harvested.



Batteries not included

Here's a demonstration of the first IDIOT product.

The IDIOT Energy Harvesting TV Remote Control.

No batteries required.

Today while traversing the corridors of the University, I came across this sign:



It's a promotional sign for the nanotechnology lab of the University of Twente, apparently they're diving into the energy harvesting material science. Although probably not relevant to what they're actually doing, the demo is funny; you can light up each LED corresponding to the peltier tile:



No fancy processing needed here: behind each peltier, a small converter modul harvests the energy and powers the corresponding LED:


A Key Point

web kbint.png

This is a circuit can be used to support a 4x4 key matrix and be made energy efficient by not requiring perpetual polling. This is done by the use of interrupt inputs.

When a key is pressed, the KBINT ISR (Interrupt Service Routine) is launched with then commences keyboard polling to determine which key was pressed, performs the desired action and then goes back to sleep.

In the sleep state;

     The key rows are configured as outputs where all outputs are pulled low.

     The key columns are configured as inputs with their pullup resistors enabled.

     The KBINT pin is configured as an input with a falling edge interrupt attached and its pullup resistor enabled.


The KBINT is connected in a wired NOR configuration using the diodes sense if any column is pulled low.

The KBINT input is high in the sleep state. When a key is pressed then KBINT pin gets pulled down via the short created between a key column and key row thus activating the ISR.


Note: A reduced part count is accomplishable where there are a sufficent number of edge detect interrupt inputs available for use as the key columns.

In this case each column has an assigned ISR that needs to be configured to process the key input.


If there is a need for ESD (Electrostatic Discharge) protection or current limiting current limiting resistors can be added to the column and row signals (and interrupt inputs) that feed the microcontroller.

Sorry for the Interruption to the current Service.

The remote buttons are interrupt driven and its supporting code is so simple.



The interrupts are configured using;

  /* Setup interrupts */

  GPIO_IntConfig (gpioPortB, 9, false, true, true);

  GPIO_IntConfig (gpioPortB, 10, false, true, true);




I didn't even have to specify the ISR (Interrupt Service Routine) function names.

It was already done.


The corresponding ISRs are;

  /* Push button 0 interrupt handler */
  void GPIO_ODD_IRQHandler(){
    GPIO->IFC = 1<<9;




  /* Push button 1 interrupt handler */
  void GPIO_EVEN_IRQHandler(){
    GPIO->IFC = 1<<10;


IRSend() is just a function that I set up to send IR commands.


It's a easy as that!

It's all in the timing!

Configuring the EFM32 to produce the correct timing for the InfraRed signals is easy.

All the fiddly work has been done and hidden from the developer.

All the developer needs to do is include and call upon the Clock Management Unit (CMU) API from the EFM library.

For a 1MHz inbuilt Oscillator Frequency we use,



To derive the carrier frequency we can allocate and configure Timer 0 to produce a 50% duty cycle by counting the desired number of 1MHz cycles for 38-41kHz;

  • Total Timer Time
  • Active Portion Time


The calculation is 1,000,000/38000 is about 26 so we can use 26 for the Total Timer Period and half that 13 for the active portion time.

This is done in code using;

  CMU_ClockEnable(cmuClock_TIMER0, true);                              // Enable Timer0 Clock

  TIMER0->ROUTE = TIMER_ROUTE_LOCATION_LOC3 |  TIMER_ROUTE_CC0PEN;     // Route Timer 0 CC0 output to LOC3(which is PD1)

  TIMER0->CC[0].CTRL = TIMER_CC_CTRL_MODE_PWM;                         // Configure as PWM Generator

  TIMER0->CC[0].CCV  = 13;                                             // Active Timer Time

  TIMER0->TOP        = 26;                                             // Total Portion Time


We require another timer to produce desired lengths carrier frequency bursts. This is done by Timer1.

It is configured to 1 microsecond resolution by using;

  TIMER1->TOP = length_us;

  while (!(TIMER1->IF & TIMER_IF_OF));                                 // Wait configured time


  // Stop Timer
  TIMER1->CNT = 0;
  TIMER1->IFC = ~0;


All easy stuff.


The NEC IR protocol for TVs

This is a very simple protocol.

This protocol consists of sending a sequence of 38kHz carrier bursts in a known fashion that is understood by the remote device.

The protocol is asynchronous meaning that IR command can be sent at anytime and is not synchonised to any other signal such as a clock signal.

The TV waits for a Start of Sequence burst to commence decoding the incoming signal.


This is defined as a 9ms active carrier burst followed by a 4ms inactive pause.

Logical bits are defined as;

  • '0' - 562.5uS active burst followed by a 562.5uS inactive pause
  • '1' - 562.5uS active burst followed by a 1675uS inactive pause

(or thereabouts - There are some slight timing variations around.)


web volume up.bmp

Since the bit transmission times are different in duration to keep the datagrams identical in duration the datagram has an equal number of logical '0' bits and logical '1' bits.

This is done by sending the desired byte value followed by its one's complement value ensuring an equal number of '1' and '0's.


The data bits are arranged in 8 bit bytes and are sent LSB (Least Significant Bit) first.


The actual datagram sent to the TV is nothing more than;

  • Start Condition
  • DeviceID
  • Command
  • A trailing '0' bit to signify the end of datagram
  • An inactive period to make the total time equal 108mS before sending another datagram.

With one exception - the repeat command which is just;

  • a 9ms burst
  • followed by a 2.2ms inactive period
  • with a trailing '0' bit
  • and inactive time to make up 108mS transmission time.


The DeviceID is an 8 bit value assigned to the remotely controlled device by the Manufacturer. For my TV it is 0x50.

The Command is an 8 bit value representing the requested command. The actual function assigned to the Command varies from manufacturer to manufacturer

For my TV the commands include;

     0x17 = Power

     0x15 = Volume Down

     0x12 = Volume Up


This was determined by observing the output waveforms on an oscilloscope.

It was also an opportunity to ensure that the output of the EFM matched the original remote.

From observation the specified timings were slightly different. The code was tuned to match it.


Sending the bits is easy. All that is done is the PWM output is turned on and off as desired using programmed combinations of;

    onModulation(8520); Delay(4150);   // Send Header

    onModulation(560);  Delay(450);    // Send '0'

    onModulation(560);  Delay(1527);   // Send '1'

to formulate the valid datagrams.


The provided parameters are in microseconds.

Ancilliary Energy Storage Unit

As mentioned at the end of Part 001 the EHSTG kit comes with a bank of capacitors can be configured as VSTORE for the LTC3108 TEG energy harvester or as an energy storage bank for the outputs of then energy harvesters (including the LTC3108).


web VSTORE.png


This capacitive bank is used to accumulate the energy as electric charge.

When configured to store the outputs to get longer running times its size can be increased in capacitance with the addition of some more capacitors but it does have a side effect.

The side effect is that it requires more energy to reach the operating voltage and thus may require more time for the energy harvesters to accumulate the necessary energy to reach the operating voltage threshold.


     V = Q/C


This also illustrates a second point of not all of the charge accessible by a device with a minimum operating voltage level because the output voltage is directly proportional to charge.

The full effect delay is only applicable when the bank is totally empty. This will occur at the very first attempt or an attempt after the bankt has emptied out due to energy leakage which usually over a prolonged time on inactivity.


Ideally this energy bank should;

  • Reach the operating voltage quickly to enable the connected device to commence operation.
  • Continue accumulating charge that is being harvested that is not being consumed whilst the connected device is in operation.
  • Not to commence operation until sufficient energy has been accumulated.


(BTW- the LTC3108 can do this to some degree.)


If we simply connect a 1 Farad capacitor to the inbuilt bank (15 x 100uF), its capacitance rises from .0015 Farads to 1.0015 Farads.

And assuming we are energy harvesting at a constant charge rate it will roughly take 667 (1.0015/.0015) times longer before the POWERGOOD signal is asserted to turn on from an empty state.


I ran a rough experiment to confirm this. I loaded the STK3700 with the default INTEMP application and measured how long it took the Solar energy harvester to start it

  • a. with just the inbuilt bank of capacitors (.0015F)
  • b. with a 1F capacitor added to it.


There's not such thing as an unsuccessful experiment but by results confirmed my findings.

With morning sunlight and

     With just the inbuilt bank of capacitors operation was pretty close to immediate.

     With the 1F capacitor added it took about a couple of minutes.


As for operation the light was removed,

     With just the inbuilt it ran for a few seconds.

     With the 1F capacitor added it ran for ages and gave up on monitoring it.


I exposed the unit to sunlight again and this time the unit started much quicker for both configurations.

The residual charge in the capacitors remained thus enabling it to reach its operating voltage much quicker.


For the IR remote control, the 1F capacitor addresses the energy accumulation and the Hand crank is used to accelerate its charging to an operational state and as an alternative energy source.


However this solution is not always feasible.

Particularly addressing the unusable accumulated energy from the abovementioned configuration.

To do this a DC-DC step up converter is required. This requires additional circuitry and introduces new energy losses.

I have a suitable solution that I used with in the Wireless Power Solution RoadTest where the design;

     a. Decides to use input power or reserve power

     b. Convert the voltage of the reserve power to the nominated voltage.


A brief of it is here. http://www.element14.com/community/groups/wireless-power-solution/blog/2012/12/09/its-alive-part-018

All that needs to change is some tuning to enable it to use energy harvested power rather than wireless power.


There are other feasible techniques.

Remember that V=Q/C so if we can reduce C (the capacitance) with out affecting Q (the stored charge) we can increase its voltage.

All that is needed is a circuit to detect the voltage and reconfigure the capacitance accordingly and the ramifications thereof.

One method is by having an array of capacitors and switching their connection configuration.

IDIOT - Intelligently Designed Internet Of Things.

Rather than just a single product I am submitting a family of products for the Energy Harvesting Solution To Go Challenge.

I've aptly named it the family the IDIOT to mean "Intelligently Designed Internet Of Things".


Why a family of products and not just one?

The reason why is because the Energy Solution To Go kit (EHSTG) and its parts are so versatile that the development and commercialisation of a single product would not have done it justice.

So many things can be made with just the EHSTG and a few additional parts its absolutely amazing!

Here is the list of additional parts I've used;

  • IR LED - The ability to remotely control appliances.
  • FRAM Module - The ability to give the product a non-volatile memory and resume where it left off.
  • e-Paper - The ability to create daylight readable non-volatile signage and displays.
  • NFC Energy Harvesting EEPROM - The ability to use obtain energy from NFC.
  • Super Capacitor - The ability to extend operation time.
  • Super Capacitor Intermediate Storage Module with auto power cutover - The ability to extend operation time and turn on quickly from harvested energy.
  • Buttons and Keypad Module- The ability to accept user input.
  • MIDI Interface Module made from an optcoupler and resistors


(Note: From heron EH = Energy Harvesting/Self powered, NFC = Near Field Communication)


With just the above parts, the IDIOT family currently includes;

     EH Infrared Remote Control and variations including automatic channel scan and intervalometer.

     EH Signage - many variations

     EH e-Reader

     NFC Signage

     NFC e-paper notepad including Smart Phone Page Dump

     EH MIDI Slave Unit

     Along with the usual Timers, Thermometers, DataLogger s


And with the addition of the appropriate low powered sensors and actutators;

     EH Safety Alarms

     EH Dataloggers

     EH Autonomous Control Units


A good example of a suitable lower powered sensor is the LMP91000. This directly connects to electrochemical sensors (such as CO sensors) and microprocessors using I2C and has an average power consumption of less than 10uA.



All of these products have great potential to be tuned, commercialised and be further developed into products such as;

     Energy Harvesting Sun Shades

     Energy Harvesting Tyre Pressure Gauge


The sky's the limit!


I won't have enough room in a single post so I will have to submit it in serveral parts also I've only got one EHSTG Kit so I have to disassemble it and reassemble it to demonstrate each IDIOT member.

The first IDIOT member described is the Energy Harvesting Infrared Remote Control.

It is not the world's most complex project but it is ideal for demonstrating and teaching embedded system and energy harvesting concepts and mechanisms.

The simplest version can be built and commercialised really quickly.


I first described this in Part 007 in this series of blogs.



Infrared Remote Control Unit

This product demonstrates how simple it is to construct a fully working and commercially viable Infrared Remote Control Unit from the EHSTG Kit.

For its development all that is required in addition to the EHSTG and IDE (Integrated Development Environment) is;

  • Infrared LED (IR LED)


That's it. Nothing else is required. Everything is provided in the EHSTG kit.

Energy Micro have even published a guide on its Lizard Lounge to assist with its development.



If more than two buttons are required you can add;

  • A keypad with some signal diodes and current limiting resistors.

The IR LED is used to communicate to the remote device. It does not require a current limiting resistor because the I/O ports on the EFM32 can drive up to 20mA and its source voltage is about 3.3V.

However there is no reason why you can't install a current limiting resistor if desired.

The IR LED selected depend upon the device to be controlled. In many cases a peak spectral wavelength 940nm is ideal or acceptable.

The IR LED should also have a suitable transmission angle. In many cases 30 degrees is acceptable.


The functional specification is simple.

  • Upon press of a button send out the desired remote control command.
  • The unit obtains power to operate from its exposure to ambient light and on demand hand cranked generator.

This means that no previous state memory nor resume on power up module is needed.

So how's it done?

A remote control is a part time use device. It spends most of its life asleep and only turns on for a brief moment when one of its buttons is pressed so there is plenty of time for accumulate energy from its surroundings.

It can accumulate power from solar cells like those used in an electronic calculator.

If the accumulated power is insufficent quick crank of its hand crank generator will get it up and going.


When activated the infrared LED is toggled on and off with a known command to the remotely controlled device and then automatically turns off again.

The control of the LED toggling is performed using two timers.

  • A timer for the carrier signal
  • A timer for the modulation of the carrier signal.

A timebase is required but no crystal or crystal oscillator is required because the EFM32 has its own energy efficient RC oscillators.

The frequency is software selectable and for this product 1MHz was selected.

The 1MHz base frequency is divided down by the timers to create the required timings.

The development of the prototype demonstrated that the inbuilt RC oscillators proved to be adequately stable for the application.


Timer0 in conjunction with an assigned I/O pin is used to generate constant carrier signal.

Timer1 in conjunction with an assigned I/O pin is used to create the desired on/off periods for the carrier pulses.


The IR LED is connected between the two assigned I/O pins.

The IR LED being a diode will only conduct and transmit when forward biased.

This means that IR transmission will occur if the assigned I/O pin for the carrier signal is a logical high (+V) and the assigned I/O pin for the modulation is a logical low (0V).


     When the modulating pin is a logical '1' and the carrier signal is a logical '0' the LED is OFF because the LED is reverse biased.

     When the modulating pin is a logical '1' and the carrier signal is a logical '1' the LED is OFF because the pins of the LED are at the same voltage.

     When the modulating pin is a logical '0' and the carrier signal is a logical '0' the LED is OFF because the pins of the LED are at the same voltage.

     It is only when the modulating pin is a logical '0' and the carrier signal is a logical '1' that the LED is ON because the LED is forward biased and current flows.


For the most basic model - the 2 user defined buttons on the STK3700 are used for user input.

  • PB0 is set to Volume Down
  • PB1 is set to Volume Up

These are configured as interrupt inputs to wake the EFM32.

When a button is pressed the selected Interrupt Service Routine (ISR) will commence.

The ISR;

  1. Transmits the assigned Remote command.
  2. Puts the EFM32 back to sleep.


Note: Notice that no detailed configuration information has been provided yet. This information will follow in a later section.


The million dollar question - How much energy does it require to operate?

The answer to that is not much.

The only energy consumption is driving the IR LED for about 70 milliseconds at 20mA (across 3.3 volts) plus the processing overhead and losses to do so.

If my calculations are correct this roughly equates to slightly more than:

     Joules = Power(in watts) x Time(in hours)

               = (3.3 x 0.020) x (0.070 / 3600)

               around 1.3 microJoules


This is achievable by a small dynamo or solar cell and has been proven by experimentation.



The next post will contain more detailed information about each element(14?) that has been described and a video of the showing the Remote working with my TV.

I would like to sum up all the work I have done in one post for those who did not follow this RoadTest and do not want to go through all the posts one by one.


Project description

The other night I was making diner in the kitchen and I saw a blinking red LED on my carbon monoxide detector, indicating that I need to replace batteries. That is when I realized that some energy harvesting technique should do the trick for me next time with a help of some hack. These types of alarms are usually either mains or battery operated. In stores you can also get double powered ones (battery as the buffer, secondary supply). I do not have any power jacks available next to the places where I put my detectors (basement, kitchen and bathroom) and long cords wouldn’t look nice, so I use battery ones. As for energy harvesting I cannot use solar charger in my basement or vibration energy in any of the places, but still I could employ some Peltier modules to get energy from temperature difference in all the places at home. Later on I did put new batteries in my detector and got distracted by other projects and forgot about this energy harvesting idea for some time. Luckily, I was going through some topics on Energy Micro forum and I saw the energy harvesting RoadTest link.


Now, I present to you the final demo project movie. Later on you can check description about my struggles with energy harvesting.


The beginnings

I got my energy harvesting kit and I starter to test it. Everything on the board worked great.


I wanted to check how much energy does a simple CO detector consume, so I cracked one open and saw its guts.


Additionally, I checked the energy consumption with a help of Energy Micro (now Silicon Labs) STK board. It has the energy debug module (AEM) and you can check the current draw in real time on your computer. If you are interested how to do that, please check one of my previous posts.


The average current consumption was about 500 uA. For standard mains supply that is almost nothing, but if you want the device to run on battery for couple of years or to be supplied from energy harvesting, you have to get your hands dirty and cut this consumption by at least 90%. And this is where the magic happens. I started to investigate from where I can get the free energy from temperature difference. My fists guess was: the walls. When you touch some wall you have a feeling that it is chill. But as it turned out it is just how you feel the temperature through your skin. In the matter of fact I checked some wall and ambient temperature and there was the difference, but only slight one.


I thought to myself: “but there is still the difference, maybe I can get at least some energy from this?”. As it turned out, I could … but only for short period of time. The thermal conductance between Peltier module was faster than the one inside the wall, so after some time the difference in temperature between the wall and ambient was practically none. I also investigated if I could bet something from a glass window, but it was also a dead end.



Then I tested the energy harvesting from hot water tap and that was it. I got satisfying results and I went with that solution. You have pipes with hot water, pretty much in all places where you need your CO detector: kitchen, bathroom, cellar, etc. If you are interested in precise data of this energy harvesting, please check this post.



The thing that was a little bit unexpected for me was that even after you turn off the tap, the pipe is still hot and you can harvest the energy – in that way, the heat in the water is not wasted. Check out the Peltier voltage timeplot after the tap was turned off.


Sensing unit

To sense carbon monoxide concentration, I took many sensors into consideration. The one I have chosen for my design is TGS 5042 from Figaro.


There are 3 main reasons that this sensor is perfect for my application:

  • This is an electrochemical sensor – it does not need power supply. It is filled with some chemicals which in reaction with carbon monoxide produce current and the sensor works as current source. Plus, other gases and temperature (especially home environment temperature range) has almost zero influence on it and the lifetime is minimum 7 years.
  • It does not need any fancy external chips and circuits. Carbon monoxide concentration is linear to the current value.
  • It is designed for battery operated systems. It has only two lead and there is no need to heat it up (5V) before reading the measurements. Additionally, the reaction time for the gas concentration is below 60 seconds, which is very important for people safety.


The datasheet suggests this measurement circuit (current-to-voltage converter):


I tested it and it works great, but … it requires external opamp with dual supply. With energy harvesting there is a problem with energy availability so with adding additional charge pump or other DC/DC (inverter) we would lose some vital energy. That is why I wanted to use the opamp which is already inside the EFM32 chip on the STK. The problem is that it is only single supply opamp. So, I proposed another measurement circuit:


The 1k resistor next to the sensor is for protection purposes. The datasheet says that the sensor should not be polarized with voltages above +/-10mV (when storing the sensor, datasheet suggests to short-circuit it). While my circuit is operational, there would be no problem, but I plan to turn off everything that I can, whenever I can to save power. That is why I have included this 1k resistor to protect the sensor (even in a high carbon monoxide concentration) when the internal opamp is disabled. I have used the opamp in non-inverting configuration (cause there is only one power supply and I do not want to make any external circuits for virtual ground) and that is why I had to invert the sensor leads. The sensor with STK is operational. The voltage to ppm conversion can be applied with the linear graph from the datasheet. The output voltage from the opamp takes form of: Vout = Isensor * R3 * ((R1 / R2) +1). It can be read with EFM32’s ADC. The gain is about 106 with the circuit I propose, so the 3V single supply amp can detect concentration far above 1000 ppm which is more than sufficient for home appliences.


I tested it and it worked great. Below, you can check the movie that shows the Voutput from the EFM32 opamp (non-inverting amplifier configuration), when the sensor is put inside the jar filled with CO. The first time the CO concentration was low because I put the paper towel inside just after it started to burn. The second time the Voutput equals the supply voltage because the CO concentration was above 1700ppm. 1V output is about 500ppm. After the first test when I took the sensor out, one lead disconnects so you can see that voltage goes off the scale, but the second time it is ok. You can see that in high CO concentrations the sensor’s response is very fast - couple of seconds (in datasheet max response is 60 sec. but for lower concentrations). When I opened the jar, the CO was quickly clearing out and the Voutput was dropping soon after.



Then I moved to developing the energy friendly code for the microcontroller. I finished writing and testing the code for my project. Previously, I measured the average current consumption of a simple, cheap CO detector to be around 500 uA (@3,3 V) – that is being consumed by the whole standby and sensing functionality. This is a way over what I can supply from the TEG when harvesting energy from hot water tap. That is why I used Energy Micro STK with EFM32 Giant Gecko on board to create my own CO detector device. Before you continue to read the rest of this post, try to guess what average current consumption I did manage to achieve. Later on you can compare your estimation with my score and that will give you the idea how low-power the EFM32 family really is. But let's start from the beginning.

The device uses Figaro TGS 5042 carbon monoxide sensor. The datasheet says that the max response for even small CO gas concentrations is around 60 sec. In large CO concentrations, for instance over 500 ppm, the sensor response time is only couple of seconds. So, the whole device should be in some sleep mode. And here starts the fun! The EFM32 chip's EM4 (Standby mode) comes very handy. In this mode - according to Energy Micro data - chip draws only 20 nA. But I needed to implement some extra functionality. The Giant Gecko comes with RTC and BURTC (BackUp RTC). BURTC can operate in EM4 and wake up the chip when time compare event occurs. Ultra Low Frequency Clock (internal - 2 kHz) can be used with the BURTC in order to use as little energy as possible. This clock is usually not exactly 2 kHz, so if you would like to use it in your application, you should calibrate it with the oscilloscope and check the temperature stability data in the datasheet to get the best possible time accuracy.

Having the BURTC to wake up the processor every 60 seconds to check the CO sensor response is one thing, but the CO detectors usually do have the TEST button. Thus, EFM32 Giant Gecko also provides the possibility to wake up the processor from EM4 with an external pin interrupt (apart from the reset pin) and this is exactly what I have implemented. To sum up: the device is in the most energy friendly mode EM4 for approximately 60 seconds or less, if one press the TEST button.

After a wake up, EFM32 checks the CO gas concentration and: if the concentration is higher than some threshold level (right how I set it on 35 ppm) or the wakeup is a result of the TEST button, the value in ppm is presented on LCD; if the TEST button was not pressed of the concentration is lower than the threshold, the result is not being displayed. Regardless of the case, the EFM32 goes into EM4 again. Below you can check two graphs, which represents the current consumption from the mentioned cases.



The average current consumption in the first case is around 2.4 uA and in the second case only around 400 nA. Is it even close to what you have guessed? In the next graph you can check the close up of current consumption between the wake up and going back to EM4 (case where the ppm value is being displayed). The whole action takes around 1.35 sec. The average current consumption in this time is around 80 uA.


80 uA is not so little for the energy harvesting power supply, but since this occurs only once every 60 seconds and takes 1.35 sec, it is bearable. Nevertheless, it could have been far more than 80 uA – even couple of mA. The reason why the value is so low is that some other energy friendly coding, functionality and other energy modes were implemented.The picture below presents the basic dataflow of the code.


After the wake up the reset cause is being checked. If the reset was not caused by any of the implemented EM4 wake up methods, in other words – the cause of the wake up is Power on Reset or the RESET pin – BURTC is being initialized to work on 2 kHz Ultra Low Frequency Clock in EM4 and to wake up after 60 seconds. Also, the GPIO Port F, Pin 2 is being configured as Pulled Input (filtered) in order to allow wake up with the TEST button. If you would like to use this feature in your project, make sure that you also have enabled GPIO pin mode retention in EM4. It will allow the chip to use this GPIO wake up feature and also to keep some GPIO pins you set, for example to hold high or low the CS pin of some chip (i.e. memory or accelerometer). Enabling this feature will cause higher current consumption in EM4, but you will save probably more energy than if you would leave the pins floating. In the end, the EM4 mode is configured and the chip goes into it.

However, if the wake up was caused by the BURTC interrupt of the TEST button, the BURTC peripheral is being updated and the measurement stage begins. The Opamp is being initialized in the non-inverting mode. Then, ADC (channel 2) is being initialized, the analog value is converted 5 times and the mean value is calculated. Next, this value is put into the equation to get the CO gas concentration in ppm. Then, ADC and Opamp are being disabled.

Right now, I would like to explain what I use for the ADC reference. The EFM32 can use couple of sources as a reference (check the reference manual). Usually, I use the supply voltage of the chip. However, when using energy harvesting converter and some storage (supercaps), the supply voltage can be unstable. In my case, when the water is turned off, the device would be supplied from the supercap and in time the voltage will drop. So, I have decided to use the internal EFM32 5 V reference source. But remember that this voltage is only available when the supply voltage of the chip is not less than 2.5 V. In my project, the 5 V reference still gives me the desired resolution.

  If the value of concentration is less than a 35 ppm threshold, the value is not being displayed. But, if it is 35 ppm and more or the wake up was caused by the TEST button, the RTC is being configured to count the duration of displaying the value in ppm on the LCD. The LCD driver is being initialized, the value is displayed and the chip goes into EM2 mode for the time of displaying to save energy. After some short period of time, the RTC wakes up the chip and the LCD driver is being disabled. Here is a tip for you. If you need to count time in EM3 mode, you can use the Low Energy Timer in EFM32 (with ULFRCO) instead of the RTC to save energy. My device have to stay in EM2, because of the LCD driver to I use RTC. I could also use Low Energy Timer in EM2 but it uses more current than RTC in this mode.


After this I had to modify the code to add a delay after the OPAMP is being turned on. There is a capacitor in feedback circuit to prevent glitches, so it needs time to charge and show correct output voltage. During this delay, uC goes into EM obviously. This change causes bigger current draw, but still, this happens only once a minute for a short period of time.

I know I can still go lower on the average current consumption by more tailoring the code (tweaking prescalers, checking the disassembly, not use API for EFM32, etc.), but this would not give me a significant drop, because for most of the time the chip is in EM4 and that is the lowest it can get. That is why I think of this code as a version 0.9. I have uploaded the source code for you to check and you can add how you can inform about crossing the concentration threshold (simple buzzer, UART transmission, RF, etc) if you would like to build this detector.


Final round

Since deadline was approaching fast, I did not have time to order the PCB. That is why I had to do it by myself in the old fashion iron way. Here are some pictures of schematic, board and the etching process.



2013-07-09 21.36.45.jpg




I soldered and tested my board and I must say – it works great! Here are some pictures of the whole thing: detector, harvester and STK with uC.



I did some energy tests. The output of the harvester chip has 0.1 F supercap. I used LTC3108-1, so the output is 3 V. As I mentioned, I use internal EFM32 5V reference, so the usable voltage for me is 2.5-3 V. Below, there is a graph of discharge process. It takes more than 2 h to drain the 0.1 F supercap from 3 to 2.5 V.


Additionally, I did some energy harvesting time test. The charging graph from 2.4 to 2.7 V is presented below.


To compare, the charge/discharge time ratio from 2.5 to 3 V is 1/3. I thought to myself I could be better, but I tested the device over a whole day where I was doing some house choirs: washing dishes, cleaning, cooking, plus two baths and I have to say that after a day the voltage was still 3 V and even some extra energy was saved in STORE capacitor – I used 1 F supercap.

My other observations:

  • If you use your hot water tap a lot during the day, the system works great. When not so often, bigger (or even couple) Peltier module and radiator may come handy.
  • When the output supercap and the STORE supercap are fully charged, the device can autonomously work for almost 1.5 day.
  • Be aware where you put the radiator. If it is right above the sink, the heat from hot water will influence the ambient temperature and TEG will not be as effective as it could be.
  • The stable 70 mV Peltier voltage shows really quick after you turn the water on, but the tap stays warm for at least couple/tens of minutes, so I noticed that it is more efficient to use the tap often, but for short periods.
  • As Victor (other RoadTest contestant) mentioned in one of his posts, there is a problem with starting the EFM32 because of the leakage current. The LTC comparator and FET is a solution, but I would like to use something else. Since the CO detector is a safety device it should have power supply all the time, even if the hot water is not used for some time. That is why I would like to use harvester with buffered power supply from a battery. I used this in one of my projects and it worked great. You just have to use another LTC (the one without -1 at the end), the 3 V battery and two Schottky diodes.


Final thoughts

  • Energy harvesting is hard, but very interesting.
  • You have to think about everything: low-energy component use, energy optimized analog circuits, energy saving oriented code in uC, low-power sensors, DC/DC converters, energy storage, energy harvesting technique, possibilities and restrains. If you miss even one of them, you will fail.
  • Energy harvesting is not for every design.
  • Make use of unique features and exploit the best way scenarios.
  • Think outside the box.


If you are interested in this sensor, please chech the source code files, Eagle schematic and board layout files attached to this post.







Like Victor, I have finished my movie showing off the project. At the end of the week I will try to sum up what I did and learned during this RoadTest. But right now with no further ado, I present to you the carbon monoxide detector project supplied by energy harvesting.



Energy Harvesting Solutions: egg timer from Tinkerer on Vimeo.


Hello All! This is my 'grande finale' post in the Energy Harvesting Solutions Roadtest Challenge! It's been a nice challenge, with a lot of technical, well, ehm... challenges!



First, I'd like to element14 for organizing this challenge. After that, I'd like to thank Wuerth both for the Energy Harvesting Solutions To Go kit, and for helping me to get a PCB in time, and of course Linear Technology (how do you get a converter started at 50mV?) and EnergyMicro (thanks for the great documentation, and your very clear goal of making each microjoule count). It's been really nice to have a go at energy harvesting with you!

Another thank you goes out to Compact and Gelmi. The 'challenge' started out with 7 elected participants, for whatever reasons it's only you guys that stuck to it until the end. Every time a new blog post came out I was full of anticipation what you had come up with this time. Thanks for the shared enthousiasm!


Energy Harvesting

At the start of this challenge, I was a bit overoptimistic on the possibilities of energy harvesting. I thought I could make a LED light out of the vibration of a bike, which wasn't possible because piezos give microwatts, not milliwatts. Then I thought of a submersible peltier harvester, where I had forgotten that a TEG element has a very low thermal resistance, and thus needs to be in a path of constant heat flow. When I had my prototype running I was very happy with the result. Getting that design on a self-designed PCB posed a new problem, that the amount of energy at the start of a harvesting process is quite low, and special precautions have to be taken to get the complete design going. All in all, designing a harvesting solution is not something that can be done in an afternoon while having a drink with your friends. On the other hand it's not that impossible either; now that I have got a working harvesting product, I can see how much energy is available from a pan with heated water (my application runs an hour after I've put the fire down). It makes me realize how much energy is wasted by throwing away boiling water, or showering. Will we -one day- have battery chargers  in our house that run off wasted energy? I don't know...

One thing I've learned is that when designing a harvesting application, you have to take a lot of factors into account. How much energy is available? How long is that energy available? With what efficiency can you harvest it? How long will it take to start up, and how fast will you drain energy you've harvested before? A complete product has to take into account both the power source, the power consumption, and the expected usage by the 'end-user'.

The products in this RoadTest Challenge help enormously in these designs; we've seen the efficient WE-EHPI transformers, the Linear converters (storing excess energy as backup as built-in feature for the LTC3108, and the LTC3105 that makes it possible to match the impedance of your converter to your source...) and the GiantGecko that has power saving in every peripheral in an architecture made for low power.

In my presentation I've mentioned that this design uses digital technology where analog couldn't have done it with less power. This is mostly due to the power of doing a complex calculation at a very high speed, and going into a deep sleep using almost zero energy after that. Possibly, the sensing part of an application could be done in analog electronics. But the lower the sample rate (i.e. the processor can stay 'off' longer), the better the microcontroller will compare. And that's only the sensing. With only a few milliwatt I've got an LCD running, and I'm doing exponential operations on floating points! Coming from a background where float operations take lots of milliseconds and microcontrollers use at least 10-20mA, I had great fun in seeing that this was possible at all.

To me, this is exciting technology. Especially now that energy storage is getting cheaper, remote sensing networks are being deployed more and more, and new materials are developed (electro-active polymers, better solar cells,...) this could take a flight. Let's hope that long-term visions on economy, sustainability and (consumer)electronics will gradually change the way we think about using and yielding energy.


We're getting ready for a future of harvesting!



Becoming Deranged

web deranged.jpg

In addition to the Expansion connector on its right hand side the STK3700 has perimeter peripheral and signal pins that can be used for connection.

To use these easily I soldered on some gold connector pins.


To enable the connection of both e-paper and Energy Harvesting modules the following actions were undertaken;

  • Solder header pins to perimeter connection pads of the STK3700
  • Relocate e-paper connections from Expansion header to the new header pins.


This sounds straightforward except for two hiccups;

  • Pin PC6 does not have a designated perimeter connection pin
  • Pin PC5 does not have a designated perimeter connection pin


Access to these pins is difficult. They just happen to be both on the bottom row of the expansion connector which is surface mounted thus is not accessible from the bottom side of the PCB.


The solution is to assign new pins which have been allocated peripheral pins that are free for use.

In addition to connection to the newly allocated pins the source code requires this information to be input into its Display_Hardware_GPIO.h header files.

The Busy and EPD_CS definitions were changed (PB10 and PB9 respectively) to their new home (PD14 and PD13).
The code was rebuilt and tested fine.


Keep the wiring together and to enable easy viewing of (STK3700) LCD I also moved the connection from pin PC0 which is at the bottom of the STK3700 to  PD15) and rebuilt and tested the code.

This also tested fine.


The freeing up of the expansion connector made it simpler to attach other peripherals to the project.

This picture shows how the Ferromagnetic RAM is connected to the expansion connector.

The Energy Harvesting board can still be connected using a jumper lead that connects the three GNDs, VMCU and PGOOD.

It is currently disconnected whilst I am performing the code development.

After the last time, I've added the following features / bugfixes to my project


  • Added button handling; one button to reset egg temperature (if inserting new eggs), the other to switch between showing water temperature and egg yolk temperature
    The button functionality already existed, but I had tho remap it to other pins, and add some wrapper functions
  • Added buzzer output (controlling the VOUT2 of the LTC3108). When the egg yolk is above (calculated) 85degrees celsius, three beeps are generated.
  • Removed a lot of deprecated code
  • I've added some more capacitors to VSTORE.In my application, a lot of energy is generated while heating up the pan. When the pan has heated up, not much energy is harvested anymore, also due to placement of the heatsink / radiator. More convection would have been possible when the generator is placed on the side of the pan (air would be flowing due to heat of the pan), but I didn't want to risk placing the radiator in the fire of my stove... The VSTORE pin can charge a capacitor bank when ample energy is provided, and this capacitor bank is drained when no input power is present. Increasing the amount of capacity on this pin will not deteriorate the startup time (it will just take longer to have enough 'spare energy' to power your converter)! For my application this is ideal; at the beginning I have ample of energy, that I want to use much longer than the heat under the water is on. With my 'solution' you can also save energy by using less fuel to cook your eggs!


Alternative take on getting the harvester going

With my hardware and software working (YEAH!) I decided to quench my thirst for better harvesting solutions to try a different approach on getting the harvester going. In my previous post (Building and debugging my harvester - Part 4) I found a way to start my board by switching on the non-harvesting part only after the 3V3 caps have been almost fully loaded. That is a working solution, but I thought I might give another option a try, and that was to use the VLDO output of the LTC3108 to power the microcontroller. This pin is, according to Linear, suitable for powering a microcontroller, and that would be a really nice approach; the EFM32 would run at a lower voltage, thus using less energy, I could power the LCD controller in the GiantGecko either from its internal boost converter or from the LTC3108, and I wouldn't have to make a comparator + FET patch. I thought it might work because the supply immediately starts charging the on-board capacitors, so there's no 'draining' of supplies, as I had with my original design (see application note AN0062 from Energy Micro for more backgrounds).


Unfortunately it didn't work. I had a spare PCB to populate, and on that PCB I built the harvester and the microcontroller. I powered the micro from the VLDO pin, which started rising immediately after I applied power, but at 0,8V the rising voltage slope stopped, and the output remained at that voltage... Too bad, again I can't get 'through' that point. But at least I've verified that design path! If an LT / EnergyMicro engineer would give some opinion on who is causing this threshold (converter or micro): I'm  all ears!


One working (with FET), one not (VLDO stopping at 0.8V)

What's next?

As you can see in the pictures I've already tested the device with the 'harvesting pan', and it works like a charm! I'll make a video, and show it here in the course of the week.


Happy harvesting!