OpenEnergyMonitor

If you have a meter like that, then enjoy it while you can.

Just don't tell anyone ...

Welcome to the weekly What-If series, also available via the Café wiki.

One useful task for wireless sensor nodes, is to be able to determine the state of the battery: is it full? is it nearly depleted? how much life is there left in them?

With a boost converter such as the AA Power Board, things are fairly easy because the battery voltage is below the supply voltage – just hook it up to an analog input pin, and use the built-in ADC with a call such as:

word millivolts = map(analogRead(0), 0, 1023, 0, 3300);

This assumes that the ATmega is running on a stable 3.3V supply, which acts as reference for the ADC.

If that isn’t the case, i.e. if the ATmega is running directly off 2 AA batteries or a coin cell, then the ADC cannot use the supply voltage as reference. Reading out VCC through the ADC will always return 1023, i.e. the maximum value, since its reference is also VCC – so this can not tell us anything about the absolute voltage level.

There’s a trick around this, as described in a previous post: measure a known voltage with the ADC and then deduce the reference voltage from it. As it so happens, the ATmega has a 1.1V “bandgap” voltage which is accurate enough for this purpose.

The third scenario is that we’re running off a voltage higher than 3.3V, and that the ATmega is powered by it through a voltage regulator, providing a stable 3.3V. So now, the ADC has a stable reference voltage, but we end up with a new problem: the voltage we want to measure is higher than 3.3V!

Let’s say we have a rechargeable 6V lead-acid battery and we want to get a warning before it runs down completely (which is very bad for battery life). So let’s assume we want to measure the voltage and trigger on that voltage dropping to 5.4V.

We can’t just hook up the battery voltage to an analog input pin, but we could use a voltage divider made up of two equal resistors. I used two 10 kΩ resistors and mounted them on a 6-pin header – very convenient for use with a JeeNode:

Now, only half the battery voltage will be present on the analog input pin (because both resistor values are the same in this example). So the battery voltage calculation now becomes a variant of the previous formula:

word millivolts = map(analogRead(0), 0, 1023, 0, 3300) * 2;

But there is a drawback with this approach: it draws some current, and it draws it all the time. In the case of 2x 10 kΩ resistors on a 6V battery, the current draw is (Ohm’s law kicking in!): 6 V / 20,000 Ω = 0.0003 A = 0.3 mA. On a lead-acid battery, that’s probably no problem at all, but on smaller batteries and when you’re trying to conserve as much energy as possible, 0.3 mA is huge!

Can we raise the resistor values and lower the current consumption of this voltage divider that way? Yes, but not indefinitely – more on that tomorrow…

The billing meter data is skewed since it's goes backwards when the Solar PV is generating more than we're using! It's an old analogue type, which are very much in their minority. It could be argued if one visualised the grid as a battery/energy store that it has met 57% of our needs. Or at least reduced our electricity based carbon footprint by 57%.

can this link with 'How to build an Arduino energy monitor - measuring mains voltage and current'
Here Link http://openenergymonitor.org/emon/buildingblocks/how-to-build-an-arduino-energy-monitor?page=8

The 57% figure is only valid if all of the generated energy has been used on site. On a sunny day, it is likely that much of the generated energy will have leaked away to the grid.

If you have data for your supply meter over the same period, then this will show how much of your consumed energy was purchased from the grid. The rest must have come from your own system and will be somewhat less than your total generation figure.

A PV Router can be used to divert any surplus power for some useful purpose on-site. If this diverted power is used to heat Domestic Hot Water, then there is likely to be a corresponding saving in the relevant utility bill.

What software do you used to create this graph?

The International System of Units, or SI from the French Système International is a wonderfully clever refinement of the original metric system.

Took me a while to get all this clear, but it really helps to understand electrical “units”:

• power says something about intensity: volts times amperes, the unit is watt
• energy says something about effort: power times duration, the unit is watt-second
• current says something about rate: charge per time unit, the unit is ampere
• charge says something about pressure: more charge raises volts, the unit is coulomb

Of course, some units get expressed differently – that’s just to scale things for practical use:

• a kilowatt (kW) is 1000 watts
• a watt-hour (Wh) is 3600 watt-seconds
• a kilowatt-hour (kWh) is 1000 watt-hour
• a milli-ampere (mA) is 1/1000 of an ampere
• a micro-coulomb (µC) is 1/1000000 of a coulomb

But there are several more useful equivalences:

• When a 1.5 V battery is specified as 2000 mAh (i.e. 2 Ah), then it can deliver 1.5 x 2 = 3 Wh of energy – why? because you can multiply and divide units just like you can with their quantities, so V x Ah = V x A x h = W x h = Wh
• Another unit of energy is the “joule” – which is just another name for watt-second. Or to put it differently: a watt is one joule per second, which shows that a watt is a rate.
• A joule is also tied to mechanical energy: one joule is one newton-meter, where the “newton” is the unit of force. A newton is what it takes to accelerate 1 kg of mass by 1 m/s2 (i.e. increase the velocity by 1 m/s in one second – are you still with me?).
• So the watt also represents a mechanical intensity (i.e. strength). Just like one horsepower, which is defined as 746 W, presumably the strength of a single horse…
• Got a car with a 100 Hp engine? It can generate 74.6 kW of power, i.e. accelerate a 1000 kg weight by 74.6 m/s2, which is ≈ 20 km/h speed increase every second, or in more popular terms: 0..100 km/h in 5 seconds (assuming no losses). But I digress…

The point is that all those SI units really make life easy. And they’re 100% logical…

On the 23rd November 2011 we have had a 2.9Kwp solar PV installed. 


We recently got our first payment from the UK's governments Feed In Tariff scheme. This has prompted me to take stock of how the system has been performing and how the data collected using the OpenEnergyMonitor energy monitoring system compares to the utility company's billing meter:
From the 23rd Nov 2011 - 23rd Nov 2012 the billing utility meter on the solar PV system has recorded a  generation of 2069 kWh. Over the same period we consumed 3588 Kwh, 57% of our electrical energy needs have been met by the solar PV. 
At this rate it looks like we're on track for the system to pay back in 7-8 years, maybe even less if we have some more sun in the next few years, fingers crossed! 
For the same time period the OpenEnergyMonitor monitoring system has recorded a generation of 2029 kWh, giving the energy monitor an accuracy of 98%! 
The monitoring system is a standard emonTx with an AC-AC adapter taking Real Power readings. 
One Year of PV GenerationKwh/d Electricity Consumption (orange) Overlaid with Generation (blue) 
When the system was installed the solar PV company estimated we would produce 2434 Kwh per year, we generated 15% less than this estimate. This could partly be attributed to the very poor summer we experienced in 2012.
This year is already looking promising, on the 2nd of May 2013 our system generated a record (for us) of 18.3 Kwh 1.9 times more than we consumed on that day (9.7 Kwh):

Record Generation on 2nd May 2013Fingers crossed for a sunny 2013 summer!

One more post about graphs in this little mini-series … have a look at this example:

Apart from some minor glitches, it’s in fact an accurate representation of the measurement data. Yet there’s something odd: some parts of the graph are more granular than others!

The reason for this is actually completely unrelated to the issues described yesterday.

What is happening is that the measurement is based on measuring the time between pulses in my pulse counters, which generate 2000 pulses per kWh. A single pulse represents 0.5 Wh of energy. So if we get one pulse per hour, then we know that the average consumption during that period was 0.5 W. And when we get one pulse per second, then the average (but near-instantaneous) power consumption over that second must have been 1800 W.

So the proper way to calculate the actual power consumption, is to use this formula:

power = 1,800,000 / time-since-last-pulse-in-milliseconds

Which is exactly how I’ve been measuring power for the past few years here at JeeLabs. The pulses represent energy consumption (i.e. kWh), whereas the time between pulses represents estimated actual power use (i.e. W).

This type of measurement has the nice benefit of being more accurate at lower power levels (because we then divide by a larger and relatively more accurate number of milliseconds).

But this is at the same time also somewhat of a drawback: at low power levels, pulses are not coming in very often. In fact, at 100 W, we can expect one pulse every 18 seconds. And that’s exactly what the above graph is showing: less frequent pulses at low power levels.

Still, the graph is absolutely correct: the shaded area corresponds exactly to the energy consumption (within the counter’s measurement tolerances, evidently). And line drawn as boundary at the top of the area represents the best estimate we have of instantaneous power consumption across the entire time period.

Odd, but accurate. This effect goes away once aggregated over longer period of time.

Yesterday’s post introduced the new graph style I’ve added to HouseMon. As mentioned, I am using step-style graphs for the power (i.e. Watt) based displays. Zooming in a bit on the one shown yesterday, we get:

There’s something really odd going on here, as can be seen in the blocky lines up until about 15:00. The blocks indicate that there are many missing data points in the measurement data (normally there should be several measurements per minute). But in itself these rectangular shapes are in fact very accurate: the area is Watt times duration, which is the amount of energy (usually expressed in Joules, Wh, or kWh).

So rectangles are in fact exactly right for graphing power levels: we want to represent each measurement as an area which matches the amount of energy used. If there are fewer measurements, the rectangles will be wider, but the area will still represent our best estimate of the energy consumption.

But not all is well – here’s a more detailed example:

The cursor in the screenshot indicates that the power usage is 100.1 W at 19:16:18. The problem is that the rectangle drawn is wrong: it should precede the cursor position, not follow it. Because the measurement is the result of sampling power and returning the cumulative power level at the end of that measurement period. So the rectangle which is 100.1 W high should really be drawn from 19:18:00 to 19:18:16, i.e. from the time of the previous measurement.

I have yet to find a graphing system which gets this right.

Tomorrow: another oddity, not in the graph, but related to how power is measured…

I’ve switched to the Dygraphs package in HouseMon (see the development branch). Here’s what it now looks like:

(click for the full-scale resolution images)

Several reasons to move away from Flotr2, actually – it supports more line-chart modes, it’s totally geared towards time-series data (no need to adjust/format anything), and it has splendid cursor and zooming support out of the box. Oh, and swipe support on tablets!

Zooming in both X and Y directions can be done by dragging the mouse inside the graph:

You’re looking at step-style line drawing, by the way. There are some quirks in this dataset which I need to figure out, but this is a much better representation for energy consumption than connecting dots by straight lines (or what would be even worse: bezier curves!).

Temperatures and other “non-rate” entities are better represented by interpolation:

BTW, it’s surprisingly tricky to graphically present measurement data – more tomorrow…

I have mentioned before, that I have purchased couple nRF24L01+ units from eBay for the stunning $3 with delivery included. I decided to make some cheap tests this time, so went for a veroboard prototype. I got two blank DIP version ATMega328‘s from eBay and flashed them with my 8Mhz optimized OptiBoot, the same one I use on the RFM2Pi boards. I glued a pinout sticker on top to easily identify the pins. The ATMega328 is running off the internal oscillator to keep components at the minimum and keep power consumption at its lowest possible. I drew what I wanted on a piece of paper:

It is very basic indeed, I wanted FTDI pinout, headers to the side to plug sensors and a 4×2 header for the nRF24L01+ board. It will run on couple AA batteries (requires voltage anywhere from 3.3V down to 1.8V); Here is how it came along:

I only built one so far, so I figured I could try the “Poor man’s 2.4Ghz scanner” sketch to make sure all works. And it surely did:

I changed my WiFi’s channel and the scanner immediately catches it. It also catches bluetooth and microwave oven interference. Useful to scan for free channels to use later when I have two of the nRF23L01+s talk to each other.

Next challenge is to find a decent library to use, there is at least 10 out there. I’d use one that supports interrupts to take advantage of low power features. (192)

Yesterday’s post was about how test equipment can differ not only in terms of hardware, but also the software/firmware that comes with it (anyone hacking on the Owons or Rigols yet to make the software more feature-full?).

Here’s another example, where I’m using just about all the bells and whistles of the Hameg HMO series scopes – not for the heck of it, but because it really can help gain more insight about the circuit being examined.

This is my second attempt at understanding what sort of start up currents need to be available for the new JeeNode Micro v3 to properly power up:

I’m applying a 0..2V power up ramp (yellow line) as power supply, using a 1 Hz sawtooth signal. This again simulates an energy harvesting setup where the power supply slowly ramps up (the real thing would actually rise far more slowly, i.e. when using a solar cell + supercap, for example). The current consumed by the JNµ v3 (blue line) is measured by measuring the voltage drop across a 10 Ω resistor – as usual.

The current consumption starts at about 0.85V and rises until the power supply reaches about 1.4V. At that point, the current consumption is about 77 µA. Then the ATtiny84A comes out of reset, enters a very brief high-current mode (much higher than the peak shown, but this is averaged out), and then goes into ultra low-power sleep mode. The sketch running on the JNµ is the latest power_down.ino, here in simplified form:

#include <JeeLib.h> void setup () { cli(); Sleepy::powerDown(); } void loop () {}

Note that since this is the new JNµ v3, the RFM12B module never even gets powered up, so there’s no need to initialise the radio and then put it in sleep mode.

The red line uses the Hameg’s advanced math features to perform digital filtering on top of the averaging already performed during acquisition: the averaging keeps the power-up spike visible (albeit distorted), at the cost of leaving some residual noise in the blue trace, while the IIR digital low-pass filter applied to that result then makes it possible to estimate the 77 µA current draw just before the ATtiny84A starts running.

Here’s the zoomed-in view, showing the interesting segment in even more detail:

The IIR filtering seen here is slightly different, with a little spike due to the following power-up spike, so the 86 µA reported here is slightly on the high side.

Note how the Hameg’s storage, high sensitivity, averaging, adjustable units display, variable vertical scale, math functions, on-screen measurements, on-screen cursors, and zooming all come together to produce a pretty informative screen shot of what is going on. Frankly, I wouldn’t know how to obtain this level of info in any other way.

So what’s all this fuss about measuring that 77 µA level?

Well, this is how much current the JNµ draws before it starts running its code. There’s nothing we can do to reduce this power consumption further until it reaches this point. In the case of energy harvesting, the supply – no matter how it’s generated – will have to be able to briefly deliver at least 77 µA to overcome the startup requirements. If it doesn’t, then the supply voltage (presumably a supercap or rechargeable battery) will never rise further, even though a JNµ can easily draw less than a tenth of that current once it has started up and goes into ultra-low power with brief occasional wake-ups to do the real work.

What I’m taking away from this, is that a solar energy setup will need to provide at least 0.1 mA somewhere during the day to get a JNµ started up. Once that happens, and as long as there is enough power to supply the average current needed, the node can then run at lower power levels. But whenever the supercap or battery runs out, another period with enough light is needed to generate that 0.1 mA again.

It all sounds ridiculously low, and in a way it is: 0.1 mA could be supplied for over two years by 3 AA batteries. The reason for going through all this trouble, is that I’d really like to find a way to run off indoor solar energy light levels. Even if it only works near a window, it would completely remove the need for batteries. It would allow me to just sprinkle such nodes where needed and collect data … forever.

Oscilloscopes are very complex instruments. The “front end” is all about being able to capture a huge range of signals at a huge rate of speeds. This is what lets you hook up the same probe to AC mains one day, and pick up millivolt signals another day, and to collect many minutes of data on a single screen vs displaying the shape of a multi-MHz wave. This isn’t just about capture, at least as important is the triggering part: how to decide what to pick up for display on the screen.

For low sampling rates, it’s very easy to use an ADC and just collect some data points – as shown in this older weblog post, even AC mains, although triggering can be an issue.

With the Xminilab presented recently, a lot of this has been solved in software, supporting a pretty impressive range of options, even for triggering. The Xminilab is particularly interesting because the full source code is available.

But for serious work, you’ll need an Owon or Rigol scope. These can sample at up to 1 Gsa/s, i.e. one billion samples per second. Truly, truly capable front-ends, able to handle very wide voltage and acquisition speed ranges.

The Hameg HMO2024 is more expensive, and many of its specs are not much better than the Owon (worse even, in some cases: a smaller display size and less sample memory).

The devil is in the details. Here’s a recent screen from the HMO2024 (borders cropped):

And here’s my first cut at acquiring the same info on the Owon (click for full size):

Let me add that I now have lots of experience with the Hameg, and only just started using the Owon, so there might be relevant features I’ve failed to set up in an optimal fashion.

A couple of quick observations:

• This is not a “typical” measurement setup: a very slow, low-amplitude signal is nothing like the usual measurements one would come across, with higher signal levels, and faster sampling rates. Then again, that’s part of the whole point of an oscilloscope: it’s so versatile that you end up using it in lots of situations!
• As you can see, the Owon has a lot more pixels to display a signal on, so I was able to increase the voltage sensitivity one notch to get more detail, and capture a bit longer.
• Some differences are obvious but not that important: the Owon provides less information on-screen about the current settings, and it does not use anti-aliasing for the traces (i.e. intensity variations to produce a fake “sharpening” effect of steep lines).

The two major differences are that: 1) the Hameg lets me apply additional digital signal processing to effectively reduce the random variations and smooth out the signal (this is done after capture, but before drawing things on-screen, i.e. all in software/firmware), and 2) the Hameg includes support for a “reference trace”, i.e. storing a previous trace in its built-in memory, and displaying it in white next to a new capture – to compare power consumption with and without WiFi, in this case.

Note that the Owon capture depth was set to 1,000 samples instead of the maximum 10 Msa, otherwise the screen would have shown a very wide red trace, almost completely swamping out the signal shown on screen. With this reduced setting, the current consumption is still fairly easy to estimate, despite the lack of low-pass filtering.

Is this a show-stopper for the Owon? Not really. It still gives a pretty good impression of the current consumption pattern during starup of the Carambola 2. If you really wanted to improve on this, you could insert an analog filter (a trivial RC filter with just 2 passive components would do). With a bit of extra work, I’m sure you can get at least as good a current consumption graph on the Owon.

The trade-off is (recurring) convenience and setup time vs. (up-front) equipment cost.

PS. The Rigol DS1052E does have a low-pass filter – every scope has different trade-offs!

PPS. For a great view into oscilloscope development over the past 5 years, see Dave Jones’ comparison video of the Rigol DS1052E and the new – phenomenal! – DS2000 series.

Welcome to the weekly What-If series, also available via the Café wiki.

Ok, you’re all excited, you’ve built some electronic circuit – either by assembling a kit, or all on a breadboard, or perhaps you’ve even go so far as to design and create a custom PCB.

Any non-trivial circuit will have polarised components on it, whether capacitors, diodes, transistors, regulators, or… the most common one in oh so many varieties: a “chip”, with 6..40 pins, or sometimes even more.

Mr. Murphy loves chips. Because sooner or later, you’ll connect one the wrong way around. Even if you know what you’re doing, sometimes the orientation marker on a chip is fairly hard to see, especially on the smaller SMD types.

So what happens if we put things in the wrong way around?

Obvious answer: it depends (on the chip).

Comforting answer: more often than not, nothing will happen, the thing will get hot, and it’ll still work fine once you fix the problem, i.e. turn the chip around and reconnect it.

The good news is that it’s not so easy to really damage most chips, with a few precautions:

• use a “weak” power supply, i.e. one which can’t put out to much current, as current leads to heat, and heat is usually the cause of component damage – a lab power supply with adjustable “current limiting” set to a low value is a very good idea
• keep your hands near the ON/OFF switch when powering up a circuit for the first time, keep your eyes open, and … use your nose: bad stuff due to heat often shows itself as smoke (by then, it’s often too late), and as components getting far too hot, and starting to smell a bit
• for low-voltage circuits, and this includes almost all digital circuits: place your fingers on several of the key components right after turning power on: if you sense anything getting hot, turn off the power – NOW!
• sensing heat is an excellent way to save a project from serious damage: we can easily tell if something heats up to 50 °C or more, yet most silicon-based chips will be able to heat up way beyond that before actually getting damaged (125..175 °C) – so as long as you turn the power off quickly enough, chances are that nothing really will break down, and chips and resistors will often start to smell – a useful warning sign!

Note that analog circuits tend to get damaged much more easily. Put a transistor the wrong way around, and it’ll probably go to never-never land the moment power is applied.

One reason digital chips are so resilient, is the fact that they are full of ESD diodes. These tend to be on each of the I/O pins of a chip, as protection against Electrostatic Discharge. Here’s what a typical I/O pin circuit on a digital chip looks like:

Nothing happens under normal conditions, since the diodes are all in blocking mode. When the I/O pin voltage rises above VCC or drops below GND, however, the diodes start to conduct, while trying to remove the charge, so that the voltage levels never reach values which might damage the sensitive oxide isolation (that’s the “O” in CMOS and MOSFET).

Now have a look at what happens when a chip gets powered up with bad voltages on two of the I/O pins (the light-blue parts are not conducting and can be ignored):

The way to look at this is that the pin(s) with the highest voltage will start feeding into the (internal) VCC connections, and the pins with the lowest voltage will start drawing current from the (internal) GND connections. Or, to put it a different way – some I/O pins will act as VCC and GND supply lines, albeit with some internal ESD diodes in between:

In this diagram, VCC and GND are fed from pins which were not intended as such!

As you can see, the diodes now start conducting as well, drawing a certain amount of current. If these currents are not higher than the diodes can handle (usually at least a few mA per diode), then the chip will act more or less like a short to the rest of the circuit. With a bit of luck, your power supply will decide to lower its output voltage and enter “current limiting” mode. The result: nothing works, but nothing truly dramatic happens either. It just gets hot and all the voltages end up being completely wrong.

Sooo… next time you power up your new project for the first time: stay alert, use your fingers, be ready to cut power, and… relax. If it doesn’t work right away (it hardly ever does!), you’ll usually have time to figure out the problems, fix them, and get going after all.

Note that there are no guarantees (things do occasionally break), but usually it’s fixable.

The Carambola 2 mentioned yesterday is based on a SoC design which uses amazingly little power – considering that it’s running a full Linux-based OpenWrt setup.

There are a couple of ways to measure power consumption. If all you’re after is the average power on idle, then all you need to do is insert a multimeter in the power supply line and set it in the appropriate milliamp range. Wait a minute or so for the system to start up, and you’ll see that the Carambola 2 draws about 72 mA @ 5V, i.e. roughly a third of a watt.

If you have a lab power supply, you can simply read the power consumption on its display.

But given an oscilloscope, it’s actually much more informative to see what the power consumption graph is, i.e. over time. This will show the startup power use and also allows seeing more detail, since these systems often periodically cycle through different activities.

The setup for “seeing” power consumption is always the same: just insert a small resistor in series with the “Device Under Test”, and measure the voltage drop over that resistor:

Except that in this case, we need to use a smaller resistor to keep the voltage drop within bounds. Given that the expected currents will be over 100 mA, a 100 Ω resistor would completely mess up the setup. I found a 0.1 Ω SMD resistor in my lab supplies, so that’s what I used – mounting it on a 2-pin header for convenience:

With 0.1 Ω, a 100 mA current produces a voltage of 10 mV. This should have a negligible effect on the power supplied to the Carambola 2 (a 1 Ω resistor should also work fine).

Here’s the result on the scope – white is the default setup, yellow is with WiFi enabled:

Sure takes all the guesswork out of what the power consumption is doing on startup, eh?

This has got to be one of the lowest-cost and simplest embedded Linux boards out there:

It’s the Carambola 2 by 8devices.com:

The 28 x 38 mm (!) bare board is €19 excl VAT and shipping, and the development bundle (as shown above) is €33. The latter has a Carambola2 permanently soldered onto it, with 2 Ethernet ports, a slave USB / console / power port, a USB host port, a WiFi chip antenna (which is no longer on the base board, unlike the original Carambola), and a switching power supply to generate 3.3V from the USB’s 5V.

The processor is a MIPS-based Atheros chip, and with 64 MB ram and 11 MB of available flash space, there is ample room to pre-populate this board with a lot of files and software.

The convenience of the development setup, is that it includes an FTDI chip, so it comes up as a USB serial connection – you just need to find out what port it’s on, connect to it at 115200 baud via a terminal utility such as “screen” on Mac or Linux, and you’ll be hacking around in OpenWrt Linux in no time.

Note that this setup is very different from a Raspberry Pi: MIPS ≠ ARM, for one. The RPi has a lot more performance and RAM, has hardware floating point, and is more like a complete (portable) computer with its HDMI video out port. The benefit of the Carambola 2 is its built-in WiFi, built-in flash, and its low power – more on that tomorrow.

I have a cheap USB to 3.3V TTL FTDI Cable that I bought on Ebay. It has been giving me some troubles ever since I got it, burned couple RFM12B modules along the way. I decided to hook it to my scope to see what is going on:

 

 

So the thing provides 5V on the power line, whilst the TTL levels are 3.3V. Yuck, why would they provide 5V on the power line??!! I have another one that is better quality and it provides both 3.3V TTL and 3.3V on the power line. The 5V effectively fried the RFM12B on the RFM2Pi board that I was trying to program within seconds..

Just a warning to you, measure before use

[EDIT]: Checking the cable datasheet reveals that these are meant to supply 5V on the VCC. So it was my mistake all along for not reading the datasheet, I have assumed all along that a 3.3V TTL cable would also supply 3.3V on the VCC, furthermore I had previously read here, that this is an unwanted mix-up. As I mention I do have another one, that has a jumper to chose between 3.3 and 5V TTL, that one does indeed also supply 3.3V and 5V respectively on the VCC. Again, a word of warning if you deal with 3.3V sensitive equipment and these cables.

  (110)

The weekend before last I went to Manchester to help Matt Fawcett and Jonathan Atkinson of Carbon coop with the EcoHome_Lab openenergymonitor energy monitor building workshop. I haven’t blogged about Carbon Co-op before so Id like to give a bit of an intro to who they are and why I think what they are doing is particularly exiting.

http://carbon.coopI first met Matt who is responsible for the monitoring at Carbon Coop at a Cleanwebuk event in London after initially exchanging a few emails. Matt explained that they are working on a retrofit programme to try to prove that it is possible to cut between 60-80% of energy demand from homes because this is what we need to save.

They want monitoring to be at the centre of everything they do, so that their members can see how minor changes impact energy usage as well as more major retrofit changes. They also want to monitor internal air quality as well as temperature for early identification of any problems with the insulation and airtightness measures. By monitoring humidity, CO2 as well as temperature Matt explained that its possible to isolate issues around damp/cooking etc from issues around ventilation.

They are really keen to use open source technology because that then gives them the freedom to configure the system as they need and then get at the data. They are keen advocates for open data and open source software and hardware in general and carry out their own work in an open way.

Since then Carbon Coop have installed 18 openenergymonitor energy monitors in houses across Manchester, held two energy monitor workshops including last weekends and are going forward with retrofitting 15 houses to between 60 and 80% carbon reduction.

Building monitors at the Carbon Coop EcoHomeLab workshop 19th-20th April What I really like about Carbon Coop is the way they are working on every part of the process: They start with the larger picture of what we need to do in terms of sustainable energy in housing and then go from there to work on an individual household basis, first carrying out a detailed whole house assessment based on the governments SAP (standard assessment procedure) to identify where most energy is being lost, which improvements would have the biggest effect and what to do first. They’re using the energy monitoring to provide feedback to households as described above. From there they go on to help households carry out work on their houses, from finding the best way to finance retrofit measures to working with architects and local tradespeople. Once the retrofit building works are complete they continue to monitor to ensure that the changes reach the predicted energy targets. They do all this using an open source approach, they are also a co-operative that is open for people to join. They are a really switched on group of people, carrying out their work in a thorough, thoughtful, evidence based way.

Every-time I go to visit them I come back inspired to develop things further. One of the highlights of the last visit was listening to Eleni Kalkantzi who works for URBED (Carbon Coop's technical partner) talk about the whole house assessment methodology and reports she, Charlie Baker and Marianne Heaslip have developed. A huge amount of work has clearly gone into these reports and the assessment method, they have an example report and report on the assessment method here:

See their example assessment here: http://carbon.coop/assessments/CC_EXAMPLE_ASSESSMENT2.pdf

Report on the assessment method: http://carbon.coop/assessments/URBED_ASSESSMENT_REPORT.pdf

They see the next step being to integrate monitoring data directly in to the SAP model on which their reporting is based to reduce the number of assumptions made. This is where the open source emoncms SAP model that we have been developing comes in but I will come back to that in another post.

I read an interesting post few months ago about a guy modding his motorcycle’s tail light so it is much more fancy. I had to try it out too I have couple ATTiny85s lying around so in couple hours I had it all set:

 
I was thinking of actually puting the board in the tail light (hence the LEDs), but quickly realized I wanted to keep the original one as it is a dual one and also lights the license plate. So instead I connected the board to the spoiler’s LEDs. See it in action:
 

(174)