RFM69CW Power Consumption

Following on from my post on RFM12B power consumption here's the same measurements for the RFM69CW (see RFM69CW intro blog post).

Current consumption was measured in the same way as explained in the RFM12B post back in July 2013. Voltage drop was measured across 10R current shunt resistor.

A fully populated emonTx V3.4 with a 433Mhz RFM69CW running discrete sampling code with a single CT connected was used in the test. The V3.4 was powered directly with 3.3V DC from bench PSU.

emonTx V3.4 with RFM69CW Test Setup

Test setup illustration

Test Bench
Please excuse my photos of the scope traces rather than screen captures, for some reason the USB socket on the scope did not seem to be working today :-(

Full sample and RFM69CW transmit trace capture

When an AC-AC adapter is not connected the emonTx goes to sleep in between readings. The above current trace shows the ATmega328 waking up for 295ms to sample from one CT channel the spike at the end is the RFM69CW transmitting. The trace below is a zoomed in capture of the RFM69CW transmission and LED. 

RFM69CW transmission current consumption 
The current trace above shows the RFM69CW transmission: 33mA @ 3.3V (109mW) for 4ms. The current spike at the end (up to 39mA) is the emonTx LED. In this test the emonTx was running the standard discrete sampling firmware transmitting a JeeLib packet structure with six integers. Since we were only sampling from one CT four out of the five integers will be zero. 

This equates to a 15 bytes payload plus 9 byte overhead @ 48kb/s. See JeeLib packet structure

In comparison I measured the RFM12B to consume 25.5mA @ 3.3V (84.2mW) for 3ms.

My measurements pretty much agree with the datasheets, here's a comparison table compiled by Low Power Labs:

Even though the RFM69CW does consume more power while it's transmitting it does have a lower sleep consumption than the RFM12B. This increased transmission power should result in an increased transmission range.

I've started a forum thread for discussion:

Introducing RFM69Pi V3 Raspberry Pi Expansion Board

RFM69Pi on Raspberry Pi B+, also compatible with Raspberry Pi Model B and Pi2

RFM69Pi - just like RFM12Pi but with upgraded radio and more I/O available

The RFM69Pi is a minor update to the popular RFM12Pi Raspberry Pi Expansion board. It adds support for the RFM69CW RF module as well as breaking out as much I/O as possible from the ATmega328 to open up the options for greater connectivity and compatibility. The RFM69Pi was developed with help and inspiration from Nanode RF designer Ken Boak, together we are working on a relay heating controller board using the RFM69Pi. 

The RFM69CW is backward compatible with RFM12B, see blog post introducing the module. From an end user's perspective there should be no difference when using the RFM69Pi over the RF12Pi apart from a new input called RSSI (Received Signal Strength Indication) appearing in Emoncms. 

You must be running the latest pre-build SD card image emonSD-26-02-15.img (now shipping) or emonHub must be updated manually to the latest Development branch version to enabled auto detection of the faster baud rate used by the RFM69Pi (38400 as opposed to 9600 on the RFM12Pi), and RSSI value handling. 

If you're running pre-built SD card image emonSD-13-08-14.img or earlier then emonHub can be updated by running:

$ sudo service emonhub stop

$ cd emonhub

$ git pull 

$ sudo service emonhub start 

check log for errors 

$ tail /var/log/emonhub/emonhub.log

The RFM69Pi is now shipping from our online shop

RFM69Pi Technical Docs Wiki Page:

Open-Source Hardware Design:

RFM69Pi Default Firmware:

An open source hourly zero carbon energy system model

I've been doing some work recently with Philip James from the Centre for Alternative Technology on developing a set of open source zero carbon energy system models based on ZeroCarbonBritain that visualise in a javascript based web page application how energy demand can be supplied by a variable renewable energy supply using a mix of storage technologies. You can create your own scenarios, choosing how much wind, solar, storage technologies etc are used.

Its still work in progress but the models we have built so far are now online and can be explored here:

The source code is all available there too as well as the original ZeroCarbonBritain spreadsheet model:

Visualising hourly surplus and shortfall:

Visualising battery, hydrogen, synthetic liquid and gas store levels:

This builds partly on findings and questions raised from our earlier work on the Snowdonia household energy study: here;

The aim will be to extend that analysis to look at the amount of renewable energy and energy storage required to supply the energy demand after implementing measures like building insulation/retrofit, heatpumps and electric transport.

I find it very interesting looking at how all of these different elements can come together to create a zero carbon energy system, to understand better the relevance of different solutions. With a framework like this it becomes more possible to put ideas like smart electric car charging or excess pv diversion to immersion heaters and battery stores in context, to get a better idea of actually how much effect different solutions can have.

Pre-built heatpump dashboards

I've been experimenting with the idea of a pre-built heatpump dashboard - a bit like the myelectric module for home energy monitoring.

The initial concept is up on under the Extras > heatpump tab. The heatpump fan turns in relation to power input a bit like the winderful windturbine.

Configuration is by naming convention at the moment, the dashboard looks automatically for feeds named or containing the words: heatpump_power, heatpump_kwh, heatpump_flow_temp, heatpump_return_temp, ambient_temp and room_temp, using these if present.


Next I plan to extend this for heatpump monitors that also monitor either flow rate or heat output in order to show COP information including a daily power input/ heat output bar graph below the heatpump graphic.

I've been doing this work with John Cantor who is using the OpenEnergyMonitor system for heatpump monitoring.

The source code for this can be found here if youd like to try it on your own install, just drop the folder heatpump into your emoncms modules directory:

Introducing emonTx V3.4

Now shipping later this week in the shop is an updated version to the emonTx V3. This is a relatively minor update feature and form factor wise, most users probably won't notice the difference. However when hardware is involved, no update is a minor update!

emonTx V3.4 is now available from the OpenEnergyMonitor Shop

The main changes  are under the hood; the ATmega328 Arduino compatible microprocessor is now is now laid down directly on the PCB. This will help with manufacture and give us a few extra I/O to pay with that were inaccessible on RFu328 module that we used on the original emonTx V3.2. The changes also bring us back in line with JeenNode hardware (IRQ and INT connections) which allow us to use the latest RF12 JeeLib library to support the RFM69CW (see separate post).

emonTx V3.4 Installed

emonTx V3.4 - production units will have battery holder fitted - omitted for photo to show components


New features on emonTx V3.4 over V3 shown in bold:
  • Measure AC Apparent Power, AC Real power* and AC RMS voltage*
  • 3 x single-phase CT current sensor inputs (100A / 24KW @ 240V max)
  • 1 x high sensitivity single-phase CT current sensor input channel (18.8A / 4.5KW @ 240V max)
  • 1 x RJ45 input for connecting DS18B20 temperature sensors
  • Single AC-AC adapter can power the unit and provide AC voltage measurement
  • An on-board 3x AA battery option with remote monitoring of battery voltage
  • Terminal block access to power rails, digital and analogue I/O and IRQ port for connecting pulse counting sensor / DS18B20 temperature / Aux sensors
  • DIP switch selection of RF node ID and 240V/110V AC adapter selection, see #DIP Switch Config
  • SMA antenna included as standard 
*when AC-AC voltage adapter is connected

emonTx as part of the OpenEnergyMonitor system
The emonTx V3.4 uses an edge SMA connector with an SMA antenna included as standard. We have standardised on 433Mhz (see forum post). The emonTx V3.4 supports and will eventually ship with the new RFM69CW module, this module is backwards compatible with RFM12B. However due to sourcing and lead time issues we have had to use RFM12B on the first batch of 500 units of emonTx V3.4 (now in the shop). When the RFM69CW is used a RSSI (Received Signal Strength Indicator) will appear in emoncms giving indication of signal strength. 

emonTx V3.4 with RFM69CW and edge SMA connector 
The emonTx V3.4 has the addition of an RJ45 socket to allow ease of connecting multiple DS18B20 temperature sensors. Screened RJ45 cabling (Ethernet) is commonly available as well as RJ45 splitters and extenders. This makes a quick and easy way to wire up a house / heat-pump etc for temperature monitoring. Power, GND, IRQ, ADC and PWM I/O's are also available through the RJ45 connector, see wiki for pinout and technical details.

Note: the RJ45 connection is not Ethernet, TCP network switches and routers should not be used 

RJ45 connector used with RJ45 terminal breakout for connection of multiple encapsulated DS18B20 temperature sensors, DS18B20 temperature sensors are also available wired directly on RJ45 connector

DS18B20 Temperature Sensor on RJ45

Certification & Environmental

The emonTx V3.4 is EMC compliant, CE certified. 

The unit is manufactured and assembled in the UK using lead free processes, with RoHS and conflict material free components. The enclosure is made in the UK using recyclable aluminium and recycled acrylic plastic is used for the front and rear fascia. 


Kettle vs Blanket

One of the things I love about monitoring energy is that it can be used to answer questions and inform decisions.

In my household we have recently purchased an electric blanket, I had always associated such items as an indulgent luxury! However at this time of year the temperature in our bedroom is often only just about in double figures (old property with poor heating and frugal use) necessitating a seemingly moderate luxury of a hot water bottle to warm the bed up a little.   

I assumed using the new electric blanket would result in an increase in our power consumption, however the energy monitor proved me wrong! 

Having the electric blanket on for 30min used about 0.1KWh while boiling 1L of hot water to fill at hot water bottle used about 0.16KWh of energy, 60% more! Also the electric blanket does a much better job of warming the bed then the hot water bottle, after 30min it was almost uncomfortably hot even with an ambient temperature in the room of 11 degrees! 

200W Electric Blanket on for about 30 min

Kettle heating 1L of water to boiling

Introducing RFM69CW

For sometime now the Hope RF RFM12B module has been our RF module of choice. This module was chosen for it's low cost, decent performance and importantly for us, an active development community. On the software side we use the excellent JeeLabs JeeLib RF12 Arduino library.

About a year ago Hope RF announced the RFM12B to be 'EOL' (End-of-Life), there has been a degree of confusion as to what exactly this means; currently manufacture of the module is still taking place and supply is still easily available. However, we acknowledged that the time had arrived to look for alternatives since Hope RF no longer offers support or recommends the RFM12B for new products. 

An obvious alternative that was explored by JeeLabs  is the Hope RF RFM69CW module, it uses SEMTEC designed silicon (as opposed to Silicon Labs in the RFM12B). It's pin-compatible with the RFM12B. Using the updated JeeLib driver the RFM69CW is be backwards compatible with RFM12B helping users of RFM12B to make a smooth transition. Thanks to JCW from JeeLabs and LowPower Labs for the work on developing the RFM69CW Arduino library. We have been working with JeeLabs to source modules and test the driver software.    


I will let JeeLabs/DigitalSmarties introduce the module 

"The recently announced RFM69CW radio module by HopeRF is a compact, powerful radio transceiver module for swapping data packets in the 868 MHz ISM band, using standard and enhanced FSK modulation. Great for sub-compact designs; just 4mm of mounted height from using an SMD precision crystal.

Though consuming a similar level of power, the RFM69CW receiver section can decode fainter signals than the classic RFM12B. The transmitter section *maximum* output power is +13dBm, considerably higher than the +5dBm of the RFM12B. The current drain at these (adjustable) higher power settings is correspondingly higher. With the better receiver sensitivity, many applications will not need to use the higher transmit power settings, potentially saving on battery life.

Comparing like-with-like, pairs of modules will generally have greater range and/or better penetration of walls/ceiling than when using pairs of the classic RFM12B.

The physical module is compatible with the PCB footprint on all current JeeNodes and JeeLinks. For details of the fast-evolving level of software support, see this Forum topic.

Control is via a fast SPI bus with reduced MPU loading. The recommended power supply range of 1.8 < Vdd < 3.6 V can squeeze almost the last energy out of depleting batteries without needing a boost converter."

Comparison tabled compiled by

Early next year we will start transitioning to the RFM69CW, end-users should not notice a difference apart from a new input on the emoncms Inputs page 'RSSI' (Received Signal Strength Indicator), see below.

To simplify manufacture and module sourcing we will be standardising on 433Mhz, we will make available no-RF versions of units for users who wish to solder on their own 868Mhz modules. See forum thread

RFM69CW on the emonTx V3.4 

For early adopters we have limited numbers of RFM12Pi Raspberry Pi Expansion with RFM69CW module in the shop. Using the latest emonHub software (currently in 'Testing' branch) using the RFM12Pi with RFM69CW on a Raspberry Pi should be seamless, emonHub automatically detects the higher baud rate requirement of the RFM12Pi with RFM69CW (56700 as opposed to 9600 with RFM12B RFM12Pi) sets baud accordingly and starts posting RSSI (received signal strength indication) to emoncms.
RFM69CW on the RFM12Pi on Raspberry Pi Model B+

Example RSSI value from emonTH in emoncms

The RSSI readings are very useful as they give a quantitative means of comparing RF performance which should help when deciding on the positioning of units during install and developing better antenna setups.

RSSI readings from nodes setup in my house (mix of RFM12B and RFM69CW) 

RFM69CW on the upcoming emonPi Raspberry Pi Energy Monitoring Shield (due for launch in the new year) 

For more info on the RFM69CW see Building Block Overview Page:

Research Project Call for Participants

In collaboration with Corina Sas from Lancaster University we would like to to evaluate members' experience of building, setting up and using our monitors and how these impact on people's understanding of energy consumption and household practices. The larger aim is to to explore how energy monitoring technologies could be better designed to support sustainable practices.

A team of researchers for Lancaster will run this study consisting of interviews lasting around 1 hrs. For this, a researcher will visit you in your home at your convenience, or if you live further away from Lancaster/Manchester, then Skype interviews can be arranged. As a thank you will be offer you an organic veg box.

The plan is to complete the study by end of the year. If you are interested and able to help, please contact the researcher with your available dates: Dr Corina Sas at [email protected]

Thanks a lot for your support.

Please post any questions to forum thread:

Snowdonia household energy study, exploring zero carbon solutions

A couple of years ago Glyn and I and a friend of ours Bethan Gritten carried out an energy study with a local organisation called EcoBro of 17 households in Snowdonia, North Wales including our own.

We looked at the energy used by each household for electric, heating and transport and what the effect would be of applying the solutions outlined in both ZeroCarbonBritain and Sustainable energy without the hot air, visualising the result using David MacKay's energy stack graphics.

I've been looking again at this work recently as I find it a really useful and tangible way of looking at the energy problem and I've taken the opportunity to improve the energy stack graphic visualisation and put it up online here:

Dynamic visualisation:

The code for it is open source and on github here:

Here's a brief run through of what you can see:

Current Energy Use
This first graphic shows each households current energy use and where that energy is used:

24% of the energy used by the households come from renewable sources, whether biomass or 100% green electricity tariffs. The wide range of total energy use per household is quite interesting, using the dynamic tool you can explore the contribution of occupancy and floor area. You can also look at C02 and energy cost per household.

Solutions for reaching 100% sustainable energy for household electric, heating and transport.

In both the ZeroCarbonBritain report and David MacKay's Sustainable Energy without the hot air, building retrofit (insulation and air-tightness), heatpumps and electric vehicles form the cornerstone's of both significantly reducing the amount of energy we need to provide the same amount of comfort/utility and making it possible to power the remaining energy demand from electricity generated by sustainable energy.

The following graphics show's what the effect would be if each household in the study applied these measures:

1) All households switch current electric consumption to a 100% Green Electricity tariff:

2) 100% green electric powered heatpumps, Biomass and electric cooking instead of oil, gas and coal. For heatpumps it assumes replacing existing heat input with a heatpump with a COP of 3.0. See step 5 for a very basic application of building performance retrofit work.

Heatpumps form the cornerstone of supplying the remaining heat demand after retrofit in both Zero Carbon Britain and David MacKay's sustainable energy without the hot air. The performance of a heatpump is highly dependent of course on being designed, installed and controlled correctly.

3) Switch all petrol and diesel cars to electric cars powered by renewable electricity (Assuming mileage stays constant and an electric car performance of 4.0 Miles/kWh)

The ZeroCarbonBritain report from CAT suggests a reduction in the number of miles driven through a combination of increased use of pubic transport, walking, biking and better planning of where we live in relation to work/activities in addition to a switch to electric vehicles which are both more efficient than petrol and diesel cars and can be powered by renewable electricity.

4) Electric trains instead of planes:

In order to achieve the last 15% and still enjoy travelling long distances we would need a switch from flights to electric train journey's, the model here just assumes that the number of flight miles are replaced with electric train miles powered by renewable electricity and that the destination is reachable by train.

5) At least 120 kWh/m2.year primary energy for space heating and home electric.

Improving the thermal performance of buildings by adding insulation and improving the air-tightness should be one of the first measures applied and considered before or at the same time as any heating system changes as in step 2 above. The implementation of applying retrofit measures in the energy stack visualisation model here is only to set a maximum primary energy use requirement rather than to explore what's possible on a house by house basis which would give a better picture of the potential savings from retrofit work.

Powering Up with Renewable Energy

The ZeroCarbonBritain report goes into a lot of detail on how the remaining energy demand after applying power down measures can be supplied by renewable energy and also the need for storage technologies to manage the intermittent nature of a fully renewable energy supply. We didnt look into this as part of our study but it would be interesting to explore it in more detail in the future to answer questions such as: what scale of community energy projects such as community wind, solar and hydro should we be thinking of if we are to supply our energy demands after applying power down measures? and how much should we be thinking about energy storage in a more local context?

There's a lot of things that could be improved about the study. Rather than applying back of the envelope calculations on the effects of applying the various solutions to each house it would be better to look at each house in detail, carrying out a full detailed Carbon Coop home energy assessment for each house on how energy demand can be reduced by up to 70% through retrofit work.

Related links

OpenEnergyMonitor page on Sustainable Energy:

The ZeroCarbonBritain report:
Alice Hooker-Stroud, Centre for Alternative Technology, ‘Zero Carbon Britain (Energy)’

Sustainable energy without the hot air

Carbon Coop
Charlie Baker's talk about carbon coop and 80% retrofit at the radical emissions reduction conference

Where next?
I would be interested to hear any thoughts on how to develop this work further, where it should go next. Feel free to email me if you have any ideas or would like to discuss: trystanlea at

Testing KiCad PCB

We are always a fan of using open-source software wherever possible. A few years ago I briefly attempted to use open-source KiCad and gEDA PCB CAD software but found them very limiting, clumsy and buggy.

Recently there have been a raft of shiny looking browser based PCB design tools such as Circuit Maker and Upverter, these look very interesting; the online collaborative development opportunities are obvious and linking into the OctoPart's live component pricing, standard part library and BOM management tools could be a big time saver at the manufacturing stage. Maybe online tools will be the future, however I am a little reserved about having designs locked into a closed online platform.

In particular I have been keeping a close eye on KiCad developments after I heard CERN had got involved in the development. I was very impressed watching this video showing the newly developed KiCad intelligent semi-auto router in action:

I think it's time I gave KiCad another try! Today I managed to install KiCad and put together the RFM12Pi schematic and layout the board. Here's my experience:

I wanted the latest build to get the shiny new features, so I installed the development branch by adding the PPA to Ubuntu:

I installed KiCad build dated 16th July on 32-bit Ubuntu 14.04

I found I needed to add the line "export KIGITHUB="";" to my ~/.profile file to get rid of cannot find github footprint errors when running CvPCB (the program in KiCad which links the schematic parts to PCB footprints)

I followed the fantastic video tutorials from Contextual Electronics to help me get started.

1. KiCad Schematic Editor, net list must be manually exported to move to the next setp

2. Linking schematic parts to PCB footprints

3. Board layout the new interactive router was great (see video above)
New router options

Update: the finished Kicad RFM2Pi V2.7 design is up on github:

Obviously we have considerable lock-in to EAGLE PCB with our historic designs and learning a new software tool is always going to be a slow and slightly frustrating process, however I'm quite impressed that after about 5hrs I think I'm got the hang of basic KiCad functions. I will seriously consider using KiCad for new designs in the future. I think the increased effort will be worthwhile to enable us to be using a fully open-source bit of design software to design open-hardware, what do you think?

Thinks I liked about KiCad:
  • Interactive router, very impressed with this. Big time saver
  • More intuitive setup of default track widths and net classes 
  • How net and pin names are displayed in the layout editor 
  • How schematic symbols and PCB footprints are handled as separate entities, more intuitive than Eagle IMHO  
Thinks I miss moving from Eagle:
  • Have a live link between schematic and PCB, KiCad requires exporting and re-importing a new netlist each time there is a change in schematic
  • There are more ready made parts in Eagle libraries then there are KiCad part libraries, but I'm sure this will change. 
  • Being able to highlight all tracks on a particular net by selecting a wire on the schematic (maybe I've just not found this feature yet in KiCad?)