China Shenzhen Electronic Market & HopeRF Factory Visit

For the past two weeks I have been travelling out to the South of China from the UK via overland travel. I have always wanted to visit China but could not bring myself to justify the carbon impact of flying*. My journey took me from the UK to Moscow via European trains then the Trans Siberian Railway across Russia and Mongolia to China. It was a fantastic adventure, we broke up the travel by stopping off in various locations on route. I have posted a couple of blog posts on my personal blog accounting the journey.

Even though at OpenEnergyMonitor we do most of our manufacturing and assembly locally in the UK there are many components that are only possible to source in China e.g CT sensors, power adapters and RF modules. In fact most electronic components originate in some way from a factory in China. Even though we do our SMT assembly and PCB fabrication in the UK we still rely heavily on Chinese manufacturing. For heavy items like power adapters and CT sensors we purchase in bulk (pallet load) and ship via ocean freight rather than air cargo to reduce carbon footprint.

I wanted to visit China to experience the culture and see for myself the working conditions in the factories that supply some of the components we use. No doubt attempting to trace back every factory and company in a supply chain for a complex items such as electronic components is a big task, something large corporation (think Apple and Samsung) have struggled with. We have all heard the horror stories of overworked and under-age employees in Chinese electronic factories.

My epic train ride to China rolled me into the North of China and Beijing first. After being a tourist for a day and visiting the very 'great' Great Wall of China I took a fast train down to Shenzhen. This train was seriously impressive, cruising at a smooth 307 Km/hr. I was glued to the window watching countryside and cities larger than London that I had not heard of fly by. I was aware that China is home to many, many people however this was really evident looking out the window watching huge cities and row upon row of skyscrapers flash by. In every town town and city it seemed many more tower blocks were in the process of being built, there is no doubt that China is undergoing an economic boom. After 8hrs of fast train blur we arrived in Shenzhen, nicknamed together with it's neighbouring city Guangzhou as the ‘factory of the world’; it's almost certain that the laptop/tablet/phone you are using to read this was made in factories in these cities.

During my time in Shenzhen I visited the world's largest electronic component market and the HopeRF factory where the RFM12B and RFM69CW RF modules that we use are designed and manufactured. I didn't manage to visit the factory where our CT sensors are manufactured since this factory was located in the north of China, however I did post up some photos I was sent from inside the factory a while back.

Electronic component market in downtown Shenzhen (I'm pictured with the seller of encapsulated DS18B20 temperature sensors that we stock)

Visiting the electronics market in downtown Shenzhen was a fantastically crazy experience. It was amazing to see all types of components carefully organised under the glass counters. There is something satisfyingly tactile about being able to hold different types of connectors and switches to compare quality and dimensions and chat to the seller about the pros, cons and cost of each item. Assuming you could speak Mandarin shopping for components here would be a far more social experience than an online parametric search tool! Obviously prices for these components are significantly cheaper than in the West.

Before I started working in electronic manufacture I assumed (like I think many people do) that most electronic manufacture is performed by robots. This is mainly true for pick-and-place assembly, however there are many more manufacturing steps which require significant human effort such as thru-hole soldering, testing and final assembly.

I am happy to report that the HopeRF I visited was clean, air conditioned and all employees were at least the minimum age, paid at least the minimum wage and worked 8am - 6pm with a 2hr lunch / siesta break. Overtime is common but employees are paid accordingly. All employees I met seems happy, although I did happen to arrive just as they were leaving on their lunch break! On the wall in the corridor there was a notice board with photos showing various company employee group outings including activities such as hill walking, running, swimming and group dinners. I also noticed an employee suggestion box.

Hope RF Factory Visit

I did get a chance to speak to an engineer at Hope RF who is involved in the design of new modules. As I had presumed the RFM69CW using a more standard IC package is much more suited to reflow soldering and less susceptible to humidity ingression than the older RFM12B design that often used a 'black blob' IC package. Second photo down on the left shows a naked RFM12B before receiving it's 'blob' dressing! Interestingly I learned (and witnessed!) that each and every single module is hand tested before leaving the factory. Modules that fail the test are debugged by hand. I was told that they have no plans to halt manufacture of the older RFM12B modules as long as there is demand.

HopeRF factory in Shenzhen where RF modules are designed, manufactured & tested.

* Travelling via train emits 80-90% less carbon then flying [Source:].

The international 'safe' level of emissions per person is around 2T/yr to contain global temperature changes at or below 2 deg C which will 'hopefully' keep runway climate change and subsequent rise in sea levels at bay. Return fight from London to Málaga will emit 2/3T of carbon per person

6.5T to Auckland Australia or 2T to New York. [Source: Only Planet, Ed Gillespie 2014]

Using emonPi Offline: How to setup a WIFI Hotspot on an emonPi

This guide details how to setup a WIFI Hotspot using the Edimax USB WIFI adapter on an EmonPi or EmonBase to make it possible to connect directly to an EmonPi from a tablet or computer without the need for a router or internet connection.

The guide is based on Dave Conroy's guide here but also covers setting up a DHCP server rather than ethernet to WIFI bridge.

There are 3 pieces of software that need to be installed to get this to work:
  • hostapd – WIFI Hotspot
  • edimax version of hostapd
  • isc-dhcp-server – DHCP Server
1) Install dhcp server 

sudo apt-get install isc-dhcp-server 

2) Install Edimax version of hostapd

Either use precompiled binary or compile yourself:

Pre-compiled (update: does not seem to work with wheezy, use self compile see below)
sudo mv /usr/sbin/hostapd /usr/sbin/hostapd.bak
sudo mv hostapd /usr/sbin/hostapd.edimax
sudo ln -sf /usr/sbin/hostapd.edimax /usr/sbin/hostapd
sudo chown root.root /usr/sbin/hostapd
sudo chmod 755 /usr/sbin/hostapd

Compile yourself (recommended for wheezy, tested March16)

sudo apt-get install libnl-genl-3-dev libnl-3-dev
git clone
cd hostapd-rtl8188/hostapd
sudo make
sudo make install 

3) Configure /etc/network/interfaces

Open the network interfaces file to edit:

sudo nano /etc/network/interfaces

Replace content with:

auto lo
iface lo inet loopback

auto eth0
allow-hotplug eth0
iface eth0 inet manual

#allow-hotplug wlan0
#iface wlan0 inet manual
#    wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

iface wlan0 inet static

allow-hotplug eth1
iface eth1 inet dhcp

If required add bridge to bridge eth0 to wlan0 - although it's better to use NAT iptables forwarding since then we can still access pi via ssh (see below)

auto br0
iface br0 inet dhcp
bridge_ports eth0 wlan0
pre-up ifconfig eth0 up
pre-up ifconfig wlan0 up
pre-up brctl addbr br0
pre-up brctl addif br0 eth0
post-down ifconfig wlan0 down
post-down ifconfig eth0 down
post-down brctl delif br0 eth0
post-down brctl delbr br0

4) Configure /etc/hostapd/hostapd.conf
Open hostapd config file with:

sudo nano /etc/hostapd/hostapd.conf

Add the following lines to hostapd.conf (set SSID and password of your choice)





Manual start to test everything is working, you should see a Wifi network called 'emonPi':

$ sudo hostapd -dd /etc/hostapd/hostapd.conf

5) Configure /etc/default/hostapd

sudo nano /etc/default/hostapd



6) Configure /etc/dhcp/dhcpd.conf
Open dhcpd config file:

sudo nano /etc/dhcp/dhcpd.conf

Add the following to the end of the file:

lease-file-name "/home/pi/data/dhcpd.leases";
subnet netmask {
        option broadcast-address;
        option routers;
        default-lease-time 600;
        max-lease-time 7200;
        option domain-name "local";
        option domain-name-servers,;

comment out #option domain-name "";

#option domain-name-servers,;



7) Configure /etc/default/isc-dhcp-server

sudo nano /etc/default/isc-dhcp-server 

Remove the comment from DHCPD_CONF, DHCPD_PID and then set the INTERFACES to "wlan0" (including ""), see example below:

# Defaults for isc-dhcp-server initscript
# sourced by /etc/init.d/isc-dhcp-server
# installed at /etc/default/isc-dhcp-server by the maintainer scripts
# This is a POSIX shell fragment

# Path to dhcpd's config file (default: /etc/dhcp/dhcpd.conf).

# Path to dhcpd's PID file (default: /var/run/

# Additional options to start dhcpd with.
#       Don't use options -cf or -pf here; use DHCPD_CONF/ DHCPD_PID instead

# On what interfaces should the DHCP server (dhcpd) serve DHCP requests?
#       Separate multiple interfaces with spaces, e.g. "eth0 eth1".

8.) Setup NAT forwarding to bridge eth0 the wlan0 while still allowing us to access the Pi via SSH (pure network bridge does not)

To set this up automatically on boot, edit the file /etc/sysctl.conf and add the following line to the bottom of the file:


Second, to enable NAT in the kernel, run the following commands:

sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
sudo iptables -A FORWARD -i eth0 -o wlan0 -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A FORWARD -i wlan0 -o eth0 -j ACCEPT

If bride is also required to eth1 (for 3G dongle) add:
sudo iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
sudo iptables -A FORWARD -i eth1 -o wlan0 -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A FORWARD -i wlan0 -o eth1 -j ACCEPT

sudo sh -c "iptables-save > /etc/iptables.ipv4.nat"

Now edit the file /etc/network/interfaces and add the following line to the bottom of the file:

up iptables-restore < /etc/iptables.ipv4.nat # This did not work for me I had to add entry to rc.local (see below)

8) Edit /etc/rc.local

sudo nano /etc/rc.local

Add before exit 0 the following lines to tell the wlan interface to use ip address and then start the isc-dhcp-server:

sudo iptables-restore < /etc/iptables.ipv4.nat
sudo ifconfig wlan0

sudo service isc-dhcp-server restart
sudo iptables-restore < /etc/iptables.ipv4.nat

9) Start services at boot

sudo update-rc.d isc-dhcp-server defaults
sudo update-rc.d hostapd defaults

Thats it restart your emonpi/emonbase to finish and then connect to network emonPi with password: raspberry

11) Add a Real Time Clock (RTC)
When running an emonPi in offline mode we recommend adding a hardware RTC to ensure the system time is always correct. See emonPi Wiki:

Hardware RTC

Useful blogs, guides and forum threads that I used to work out how to set up the above:

Pulse counting with the RFM69PI and RaspberryPi EmonBase basestation

The latest version of the RFMPi Adapter board made much of the spare digital and analog IO available for use directly on the RFMPi adapter board. D3 is one of the digital inputs available and can have an interrupt attached (INT 1) which makes it useful for pulse counting.

By connecting a optical pulse sensor directly to the rfm69pi adapter board this can make a relatively low cost solution for internet connected pulse counting (or local logging to emoncms running on the raspberrypi).


1) The RJ45 connector on the optical pulse counter needs to be removed and individual wires exposed. Connect the red wire to 3.3V, the black wire to GND and the blue wire to D3:

2) To use the rfm69pi adapter with pulse counting the pulse counting firmware needs to be uploaded to the rfm69pi adapter board, the steps to upload this firmware are:
  1. SSH into your raspberrypi running the standard OpenEnergyMonitor image.
  2. Place raspberrypi in write mode:
    $ rpi-rw
  3. Stop emonhub:
    $ sudo service emonhub stop
  4. Pull in latest changes to RFM2Pi git directory:
    $ cd RFM2Pi
    $ git pull
  5. Upload pulse counting firmware:
    $ avrdude -v -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 38400 -U flash:w:/home/pi/RFM2Pi/firmware/dev/RFM69CW_RF12_Demo_ATmega328_Pulse/RFM69CW_RF12_Demo_ATmega328_Pulse.cpp.hex
  6. Start emonhub:
    $ sudo service emonhub start
Next login to the local emoncms installation on the raspberrypi and navigate to the emonhub.conf editor. Add the following node definition in the nodes section of emonhub.conf:

    nodename = rfmpi_pulse
    firmware = RFM69CW_RF12_Demo_ATmega328_Pulse
    hardware = rfm69pi
       names = power,count
       datacodes = h,L
       scales = 1,1
       units = W,Wh 

The pulse count is accumulated on the rfm69pi until the rfm69pi is reset either by an outage or by turning off and on the power.

To record the total accumulated pulse count in emoncms use the wh_accumulator input process which detects resets continuing the total pulse count accumulation from the last value before the reset.

At Watt Cost? A review of the emonPi Raspberry Pi based energy monitor

At Watt Cost ?

A review of the emonPi, a Raspberry Pi based energy monitoring system developed by OpenEnergyMonitor, by Lionel Smith :

Measurement is the first step that leads to control and eventually to improvement. If you can’t measure something, you can’t understand it. If you can’t understand it, you can’t control it. If you can’t control it, you can’t improve it.”
― H. James Harrington
Do we know how much electricity can be saved by using low energy lighting such as LED's or how much electricity is saved by turning off lighting when not in use?
Finding out how much electricity is being used by one or all of your appliances, is the first step in being able to cut down on consumption, and in doing so spend less on electricity. It goes without saying that reducing your consumption equates to doing your bit towards creating a sustainable world.
Glyn Hudson, Trystan Lea and the rest of the team at have developed some monitoring technology to help us understand and optimise our energy consumption and generation. This allows us to approach the problem of energy consumption in a logical and informed way.
The Raspberry Pi isn't great at measuring analogue voltages, so various Arduino based measurement boards have been developed which process and digitise the inputs and transfer them to the Pi.
In early 2014 an idea was born to create a shield which plugged directly onto a Raspberry Pi to make a single unit energy monitoring solution, primarily aimed at domestic users. A whole bunch of discussions and a fair amount of blood, sweat and tears culminated in a Kickstarter campaign which raised £24,723 to help bring the project to life
This piece of kit is dubbed the emonPi, which is a Raspberry Pi based, open-source, web-connected, energy & environmental monitor. This unit gives you the ability to measure home energy, solar PV, heatpump generation and temperature.
Everything on the site is fully open-source, which means you are free to tinker and improve to suit your needs. There is a very active community so help is readily available.
Aside from the obvious current and voltage values, temperature and humidity can also be measured by adding the appropriate nodes. All this information is then formatted on the Pi and either stored locally or uploaded via an Internet connection to a hosted application called EmonCMS.
Once you've built up some data, various visualisations can be applied to create some really informative graphs.

Emoncms MyElectric and SolarPV Dashboards
The emonPi is available in both kit form or as a complete unit. Complete units are housed in a professional looking case sourced from Lincoln Binns. Even if you can’t resist the urge to experiment and order your system in kit form, it is highly recommended that you order the aluminium case to house the finished unit in. Aside from protecting everything inside, the case really gives the unit a polished, professional look.
Inside the case you will find a standard Raspberry Pi 2, the GPIO serial connected Arduino measurement shield and an I2C connected 2 x 16-character display.
Emonpibare (1).png
The unit contains built in 433Mhz low power RF which is used for communicating with its external nodes. These nodes can be used to add additional power readings (emonTx) or remote temperature and humidity (emonTH) .
Fire up the system with a LAN cable plugged in and the on board display conveniently displays its IP address. Punch that into your favourite browser ( on a PC in the same LAN ) and you get to the login page. Once logged in, you are able to setup the WiFi if you have added an external USB WiFi adapter.
The built in 16 x 2 display will also confirm the status of connected devices. In order to measure temperature, an optional DS18B20 temperature sensor needs to be connected. The emonPi can talk to multiple (up to 6) of these sensors as they are individually addressable.
Power can be measured using a clip-on CT current sensor and a 9VAC reference supply. You can cheat and omit the 9VAC supply input resulting in the AC voltage being fixed in the software, but then you are not reading true Real Power or Power Factor, so this is not recommended. If measuring solar PV two clip-on CT sensors are required and the 9VAC voltage input is essential as it's required to tell the unit if you generating or consuming power. The second CT can be used to isolate a particular load and see how much that draws. As an example CT 1 could be measuring the total of your house while CT 2 could tell you how much just your water heater or stove uses.
Another method to measure power is to use an optical pulse counter sensor that picks up the LED flashes generated by most modern electricity and gas meters.
Being able to visualise the power used by your appliances gives a whole new insight into the power needed to run them. The author used the system to evaluate the claims made by the supplier of a hot water boiler control unit that only allows the boiler to heat the water 3 times a day based on your predicted usage. Using the emonPi and Emoncms system it was easy to see exactly how much saving was achieved after installing the control unit.
The emonPi is a fantastic piece of kit and well worth having if you would like to contribute towards a greener future.

Weblinks for more information:

Safety Warning: Interfacing with mains voltages can be potentially lethal. If you are not competent, or not sure of what you are doing rather seek the assistance of a qualified professional.

Optical pulse counting with the EmonTH

In addition to temperature and humidity sensing the EmonTH has a digital input (with interrupt) that can be used for pulse counting.

This can be used for wired pulse counting or with the Optical LED pulse sensor.

To use the Optical LED Pulse sensor the easiest way is to remove the RJ45 connector and then strip back the black sheathing to reveal the red (3.3V power), black (GND) and blue (pulse) wires.

Connect the red wire to the 3.3V terminal, the black wire to the GND terminal and the blue wire to the terminal labelled D3 (top) or IRQ1/D3 Pulse Counting (bottom of the board).

There are two firmware examples available for the EmonTH for pulse counting, the first is for Pulse counting in addition to DHT22 Temperature + Humidity sensing or DS18B20 temperature sensing:

The second is for pulse counting only if the temperature and humidity sensing is not needed:

To upload these firmware examples you will need the Arduino IDE and libraries installed and a USB to serial programmer to upload the firmware to the EmonTH.

The pulse count is accumulated on the EmonTH until the EmonTH is reset either by an outage or by turning off and on the power.

To record the total accumulated pulse count in emoncms use the wh_accumulator input process which detects resets continuing the total pulse count accumulation from the last value before the reset.

3CH WiFi Relay Control Board

We have recently started stocking in the shop a Three Channel WiFi Relay / Thermostat Board designed by our friend Martin Harizanov.

The board has been well designed to physically separate high voltage AC mains from the low voltage logic. The board has an optional power supply to enable the board to be powered directly from 100-240V AC. A wall-mountable plastic enclosure is included. 

The board can be used to control a heating / AC / humidifier via local control loop from on-board sensor. The unit can be programmed with a schedule and or manually controlled via web UI via WIFI. Sensor data and relay status can be posted to Emoncms for logging and graphing. 

NOTE: The board connects to and controls high voltage, knowledge and attention is required when installing to prevent electrical shock.


The relay board is a open software/hardware multi-purpose relay board based on the ESP8266 WiFi SoC. It can control up to three AC or DC loads over the Internet using web UI or MQTT.

  • Powerd direct from 230V AC via isolated on-board PSU (optional extra) or 5V DC via micro USB
  • Built-in web server with mobile device friendly UI and HTTP API to control the relays
  • Thermostat function with weekly scheduling
  • Manual relay control via the UI
  • NTP for network time and scheduling functionality
  • Web server settings, including HTTP port and basic HTTP authentication setup
  • Broadcast relay/sensor data using HTTP GET to services like ThingSpeak or Emoncms
    • Integration with ThingSpeak for charting/analytics visualization
  • Temperature sensor support (one of them, not both at the same time) - (optional extra)
    • DS18B20 one-wire temperature: supports multiple sensors
    • DHT22 (AM2302) Humidity & Temperature


The relay board can now be purchased direct from our shop:

Documentation & Set-up: 

Full technical details and set-up guide are available on Martin's Wiki:

Overview demo of the board in action by Paul Reed: 

Posting status & sensor readings to Emoncms

Understanding zero carbon energy systems: Energy storage (part 1)

The last zero carbon energy model example in the series investigating the matching between different energy demands and a variable renewable supply reached 89% supply/demand matching with a mixture of solar and wind supply, traditional electricity demand, space heating with heatpumps, electric vehicles with smart charging and two small stores one 7 kWh li-ion store and one 10 kWh heatstore.

Blog post: Open source hourly zero carbon energy model, combining traditional electric, heating and electric vehicle demand.

How do we achieve that final 10% of supply/demand matching? Is it possible to just scale up the li-ion storage or do we need something else? What is the nature of that final unmet demand and the final storage requirement?

One of the good things about having the model written as a program rather than spreadsheet is that its really easy to run the model iteratively for different input values, you can quickly go through hundreds of model runs. You don’t need to manually run the model for each value.

The following graph shows how the percentage of supply/demand matching increases as the storage size increases. The python source code for the model used to produce this can be found here:

In order to capture all of the storage requirement in this analysis the heatstore was removed from the last model and the EV charging was set to a constant charge profile rather than smart charging. This configuration achieves 78.3% supply/demand matching with no storage, an unmet electricity demand of 13,628 kWh over 10 years out of a total of 62,771 kWh.

% Supply/demand matching vs storage size in kWh:
We can see clearly that the degree of supply/demand matching increases very quickly as we add the first kWh's of storage but then the gains taper off quickly requiring orders of magnitude more storage to reach the final 5%.

The first 10% of supply/demand matching, bringing us up to 90% needs around 25 kWh of storage. The next 5% up to 95% requires an additional 120 kWh of storage. The final 5% requires 1536 kWh.

Note: see added section below for calculations of total storage capacity required if the oversupply is 20% or 30% instead of the 4% here.

The first 1.5% of the storage capacity provides 50% of the required supply/demand matching gain.

Its interesting to look at what the use of the 1680 kWh store looks like across the 10 year model period:
The store is used most over winter, where electricity demand is highest due to heatpump space heating. We can see that the winters of 2010 and 2011 where particularly cold and that the extent of the storage requirement in this model is largely driven by these successive harsh winters and a less strong summer. If the modelling had only considered 2002 to 2010 we might have under specified the storage amount needed by half which highlights the importance of modelling over as many years as possible.

Utilisation, cycling

We can see roughly that the full extent of the store is only used once in 10 years and is largely needed to cover just 3.5 months at the start of 2011. Even if the store was half its size it would only be used fully 3 times in 10 years. The extend to which the store is cycled is an important consideration in store choice, both from the perspective of wear and financial payback.

The following graph charts annual cycle requirements vs storage size, highlighting how most of the storage requirement is cycled very infrequently. A 25 kWh store delivers the equivalent charge/discharge energy of 30 full cycles a year, 100% depth of discharge (DOD). The next 120 kWh would only be cycled 7.3 times a year. A 625 kWh store would only be cycled twice in a year and the full 1680 kWh store only 0.8 times a year.

Cycles per year vs store size:
The above gives us an initial degree of insight into the nature of the storage requirements and how reaching the final 10% of supply/demand matching requires magnitude more storage than the first 10%.

Its important to note that the results above are for a model based on uk climate and weather, it would be worth repeating this kind of modelling for warmer countries where air conditioning that matched solar pv generation was a large component of demand rather than winter heating.

The next blog post will look at some of the different storage technologies available and how they are suitable for different segments of the overall storage requirement.

Reducing storage requirements by oversupply 
Following the conversation with Dominic Zapman here, I decided to re-run the model with a higher degree of oversupply - nearer the oversupply level used by ZeroCarbonBritain. The results above are for an oversupply of 4% with 65391 kWh supplied over 10 years for a demand of 62771 kWh. A 1680 kWh store is 27% of the annual demand.

If we re-run the model with an oversupply of 20%, 100% supply/demand matching is reached with a 676 kWh store, 11% of annual demand.

If the oversupply is 30%, the storage requirement is reduced to 484 kWh, 8% of annual demand.

The ZeroCarbonBritain model exports 165 TWh out of the 738 TWh generated which is an oversupply of 22%. A further 180 TWh is used to generate synthetic fuels including power to gas methane storage. A high percentage of this demand will also be oversupply. The long term power to gas storage capacity in ZCB is 60 TWh, delivering on average 14 TWh/year of backup supply covering about 402 TWh of final demand excluding exports. Delivered backup is 3.5% of final demand.

New MyElectric Emoncms app, realtime power graph and energy totals


The MyElectric app has long been needing some work so that it both provides more useful information and also reports the daily kwh data correctly for different timezones and when the app is used as an always on display and the day changes.

There is now a new version available that adds a real-time power graph as well as totals for the week, month, year and all time and the daily kwh bar graph as before.

To generate the kWh per day graph this version focuses on supporting feeds either created with the "power to kWh" processor or "Wh accumulator" processor rather than the "power to kWh/d" processor and average power feeds. Trying to support each one was leading to quite a lot of bugs in addition to more fundamental issues with time zones present with the power to Kwh/d daily feed approach.

The "power to kWh" and "Wh accumulator" processors are both fully supported on the emonPi and emonBase running the low-write image. There's more on how this accumulating watt hour or kWh approach works here: Development: Calculating Wh totals on the emontx

I now have the new MyElectric app running alongside the MySolarPV app in my home and I'm really quite pleased with the results. The totals at the bottom and average kWh per day for each period gives me most of what data to see at a glance how my electricity consumption is fairing and having this information available on a wall mounted tablet really makes all the difference compared with having to login to emoncms on my computer to see the data.

I would like to make it easier to switch in between the different apps, a side swipe would be really nice. I would also like to look into a way to make it possible to download apps from an app repository from within emoncms itself so that new apps could be added without them having to be in the app repository on github, there's quite a bit of work needed to get there thought.

Adding a RTC to the emonPi

The emonPi updates its internal linux time from NTP when connected to the internet. However if the emonPi is to be used on an offline network or for an application when accurate timestamp is essential then a hardware Real Time Clock (RTC) can easily be added to the Pi's GPIO. We have tested using a DS3231 based RTC module. This RTC module communicates with the emonPi via I2C, it can be easily connected as follows by soldering a four-pin header onto the emonPi aux GPIO pins:

emonPi with hardware RTC module added

DS3231 based RTC module

I2C bus scan showing LCD & RTC

Full install guide can be found on the wiki:

What is the embodied energy of a microcontroller?

Continuing with the investigation into the embodied energy that it takes to make an energy monitor, I thought I would explore in a little more detail the embodied energy of the microcontroller which is often associated with the most energy intensive aspect of electronics manufacture.

As I mentioned before I wouldn’t put a large amount of confidence in the accuracy of the figures below, computer chips are incredibly complex things that take a large number of manufacturing processes to make and I have found it hard to find open detailed information on energy requirements of these. The calculations below are based on the datasets that I could find including the EU ecodesign dataset which I'm told is one of the higher quality freely available sources. But I could not find much detail on how the figures where derived to know what it does and does not include and the breakdown of energy use in its manufacture.

The idea here is more to get an initial set of numbers that could be improved upon in the future. My motivation for looking into this started by being inspired by howies and patagonia's efforts on footprint and supply chain analysis, partly by reading sustainable energy without the hot air that identifies industry as being a significant part of overall energy use and also after reading the article here about 'the monster footprint of digital technology'.

The following starts by looking at the available datasets and then investigates deriving figures for the embodied energy of a chip by calculation of the actual semiconductor volume contained which compares well for the small IC embodied energy value.

1) Datasets

EU Ecodesign methodology
The EU ecodesign methodology downloadable here provides embodied energy values for a variety of electronic component categories, it provides two embodied energy values for IC's (integrated circuits) these are:

Large IC                        8021.88 MJ/kg
Small IC                        1786.73 MJ/kg

MJ/kg: 1,000,000 Joules per kg

The question is what constitutes a small or large IC? Dimensions? processing power? and there is a large difference between both of these values!

Another paper that lists sources for embodied energy values including the EU ecodesign dataset is this paper on the embodied energy of an offgrid light: It lists two other useful values:

Semiconductor Grade Si             35000 MJ/kg, Taiariol et al. 2001
EPROM Chip (M27C1001, 0.36 W IC)   12.5 MJ/chip,  Taiariol et al. 2001

Jean Claude Wippler of JeeLabs did an interesting post a couple of years ago on what is inside an ATmega8 chip. The Silicon part was extracted by dissolving the outer casing with sulphuric and nitric acid.

The size of the semiconductor part inside the ATmega8 is 2855 x 2795 um, less than 3x3mm:

Is it possible to estimate the embodied energy of a microcontroller by working out the embodied energy of the silicon part and the casing part separately? and how would the figure compare with the embodied energy values given for a small and large IC in the EU ecodesign dataset?

To find the embodied energy of the silicon part we need to first work out the weight of that part. To do this we will need the density and thickness of the silicon wafer. The thickness of a silicon wafer can be anywhere between 275um and 926um.

Density of silicon: 2.3290 g.cm3

2855 x 2795 um x 275 um = 0.00219 cm3 x 2.329 g.m3 = 0.0051 g
2855 x 2795 um x 625 um = 0.00499 cm3 x 2.329 g.m3 = 0.0116 g
2855 x 2795 um x 926 um = 0.00739 cm3 x 2.329 g.m3 = 0.0172 g

The embodied energy of silicon grade Si is around 35000 MJ/kg, 35 MJ/g

0.0051 g x 35MJ/g = 0.178 MJ = 0.049 kWh
0.0116 g x 35 MJ/g = 0.406 MJ = 0.113 kWh
0.0172 g x 35 MJ/g = 0.602 MJ = 0.167 kWh

The weight of a SMT Atmega 328 is 0.14375g:

Large IC: 8021.88 MJ/kg = 1.153 MJ = 0.320 kWh
Small IC: 1786.73 MJ/kg = 0.257 MJ = 0.071 kWh

The EPROM Chip (M27C1001, 0.36 W IC) example is 12.5 MJ/chip = 3.47 kWh
Which is between 10 and 50x the large/small IC estimates and 20 to 70x the wafer only estimates.

The large IC is between 2x and 6x the wafer only and small IC is between 0.5x to 1.5x the wafer only estimate.

The weight of the silicon part of the chip for the ATmega8 should be between 3.5% to 12% of the total chip weight.

The rest of the weight is metal and plastic. Copper has an embodied energy of between 38MJ/kg and 142MJ/kg depending on manufacturing process and plastic is anywhere between 80-120MJ/kg. If we assume a copper/plastic mix of around 100MJ/kg as a rough estimate.

This would then contribute an additional 0.0132 MJ = 0.0037 kWh which would only increase the embodied energy of the chip by around 2-7%.

Our estimate therefore for the embodied energy of the small microcontroller is between 0.053 kWh and 0.171 kWh, mid range of 0.117 kWh for 625um wafer which compares well with the small IC estimate of 0.071 kWh (it is of the right magnitude). We would expect a certain amount of assembly energy for combining the plastic, copper and semiconductor parts which is not included when taking a constituent parts approach which will likely add a little more to the total.

Package type?

Calculating the embodied energy this way brings up an important question about the package type of the IC, I.e how much plastic and connector metal surrounds the semiconductor core. If the size of the semiconductor inside a through-hole and SMT version of a ATmega328 is the same then surely a total weight based measure is not a good guide for the embodied energy. Given that over 90% the embodied energy is associated with 3.5 - 12% of the weight.

RaspberryPi chips
The ATmega8 or ATmega328 is not a particularly powerful chip, the emonpi also uses a RaspberryPi which has three chips on board.

Its not clear what the volumes of the semiconductors inside these chips are. But given their small size and relatively large processing power lets assume for an initial calculation that the size of the package is very close to the size of the semiconductor. If the wafer thickness is 625um then the embodied energy of the chips can be estimated as:

Broadcom        14 x 14 mm x 625um = ~2.8 kWh
Elpida          12 x 12 mm x 625um = ~2.0 kWh
Smst            8.7 x 8.7 mm x 625um = ~1.1 kWh

These estimates which cover a quad core 900Mhz + 1GB ram computer are much larger than the ATmega8 estimate as we would expect but are still significantly lower than the embodied energy figure given for the 32MB 2g memory chip referenced in the article on the the monster footprint of digital technology of 20 kWh - while delivering much more functionality, almost a full computer!

Are these figures accurate? are the underlying datasets accurate for modern processors? Does it mean that newer miniaturised technology with the ability to pack much more computing power inside the same volume of semiconductor has resulted in a significant reduction in the embodied energy for equivalent amounts of computing digital technology functionality? These are all significant guesses at the moment and it would be really interesting and useful to see more open data available on the embodied energy of newer technology. It would be good to see greater interest from the manufacturers of these chips in calculating and giving information on the embodied energy of their products, making data available on this would really help with understanding this question about the impact of technology.