More thoughts on Boiler Hacking

I've set up a 4 channel thermistor sensor adjacent to my boiler and have been logging the temperatures of flow, return, outside and inside temperature for the last few days. I've taken advantage of the pretty cold weather to get an overall assessment of how the boiler performs under various conditions.

At the weekend the house was cold so I measured the time taken for the boiler to get the house back up to temperature. Now that it's hovering around the set point on the thermostat, I'm monitoring how long the boiler cycle periods are, and see if I can reduce the cycling by direct manipulation of the water temperature control pot.

I've also discovered a subtlety about my Drayton Digistat wireless thermostat. In order to save battery life, it restricts the sending of messages to every 4 minutes. So if the thermistor in the thermostat reaches temperature, the boiler off command is only sent when the next message is scheduled. The timing of these messages is probably derived from a 1 second interrupt from a real time clock routine running of a 32kHz watch crystal. The effect of this is that the boiler appears to turn on and off, exactly synchronised to the seconds counter of my PC clock - i.e. all on and off activity appears to be when it's 32 seconds past the minute.

The Worcester Bosh Greenstar boiler, has a 2 minute start up sequence. If the boiler is cycling on and off every 20 minutes, it means that it goes through 3 start-ups per hour. If it is possible to reduce the number of start-ups and the cycling, then some of the wasteful start-up period would be removed and the heating would be more efficient.

It would also be advantageous to introduce some hysteresis into the thermostat control. Although the set point might be 19C, the user is not going to notice if you turn the boiler off at 20.0C and back on again at 18.0C. The boiler will have a longer runtime, and less time will be spent repeatedly reheating the pipes and radiators.

As far as controlling the boiler, it should be possible to use an RC servo to turn the pot on the front panel. The temperature control should be turned to maximum for a rapid warm-up, and then backed off once the property is up to temperature.

By way of some figures. Yesterday morning was about 1C outside. When the boiler came on at 4:30am it took 3hrs 30 mins to raise the room temperature by 3 degrees, and in the process used 46kWH of gas (£1.50 worth) and the room was still chilly. The boiler was restarted at 1pm and then only used a further 130kWh to keep the temperature maintained for the next 18 hours.

Towards the Hackable Boiler?

This post is the result of some discussions I had last Thursday at the Homecamp Christmas Party, with Paul Tanner and Mark regarding the feasibility of hacking the home heating system (in a safe, benign kind of way) to see if it is possible to make it better featured and return improved efficiency over the existing time of day and thermostat type controls that almost every central heating boiler employs.



Whilst a lot of people are now monitoring home electricity consumption - because it's cheap and easy to do, I thought I'd take on the challenge of monitoring my gas consumption and to try and link it in with a thermal model of this 1905 brick-built house.

Home heating is becoming increasingly expensive, and will continue to become more-so as we get even shorter of natural gas reserves. What I want to do here is analyse my domestic heating system to see if there are scopes for big savings. My electricity consumption is already fairly low - so there may well be an better opportunity in focussing on gas.

I have suspected for some time that it is more efficient to leave the heating on 24/7 at a low heat in an old house like this, and get the thermal mass of the brickwork thoroughly warmed through. It was now a good opportunity to try and prove that theory. I now have some temperature sensors and know enough Arduino code to be dangerous, and with the snow lying around outside, now was a good weekend to get some data to try to prove the point.

The first thing to assess was the availabilty of suitable inputs and monitoring points on the boiler to allow it to be monitored and controlled. Most boilers have a simple on/off control that is wired out to the timeswitch and thermostat. The timeswitch brings it on at a certain time of day, it keeps heating the rooms until the set point on the thermostat is reached, and the thermostat turns it off. Simple on/off control.

About 10 years ago, boilers started to get a little more sophisticated, - they had to, in order to cope with the control demands of the condensing mode heat exchanger. Boilers now have thermistors to monitor the flow and return temperatures and a variable speed fan and modulating gas valve, to ensure that the boiler can react to sudden demands and always combust the gas at the best air/fuel mixture. When your burner, rated at 24kW is only the size of a 5 litre paint can - you have to be fairly much in control of the air/fuel mix. Additionally you need to turn the power down such that the water returned to the boiler after heating the radiators is sufficiently cool enough to condense the water vapour in flue gases, and thus recuperate the heat of vapourisation/condensation. This is how condensing boilers manage to achieve efficiencies of about 90% when running correctly in their condensing mode.

So firstly a quick monitor of the boiler flow and return temperatures. I had some pipe clip thermistors from Rapid Electronics, which I attached to the flow and return pipes. As it's close to freezing this weekend, and the boiler is on almost 24/7 right now - it's a good time to observe the heating cycle. The plot below shows flow and return temperatures over a 3 hour period. The boiler had been struggling to get the living room much above 17C, so the first thing to do was see what the respective temperatures were before and after I turned up the water temperature control knob on the front of the boiler.

The traces are the raw count output from the thermistor ADC channels - but for the purpose of understanding, just divide by 1000 to get approximate water temperatures in degress C.

First I let the temperatures stabilise for about 50 minutes before turning up the heat control on the boiler. The red trace (the flow), shows a near immediate rise, as the boiler adjusts its combustion power to increase the flow temperature. The blue trace is the return water temperature that has circulated around the radiators and underfloor heating and its response to more heat, was a more sluggish response. This is because it takes time to heat up all those rads and pipework to their new elevated temperatures and this is characterised by the rounded, almost exponential rise in the blue trace in response to a near instantaneous step change in the red.

After the traces had stabilised at their new levels, I then decided to turn on a radiator in the front room that had previously been shut off. This corresponds to an increase in heat demand or thermal load, and quite expectedly, the return water temperature fell by a few degrees as the cold water in the dead rad, was now circulated back to the boiler. What I hadn't fully appreciated was the accompanying drop in boiler flow temperature - as I thought that the boiler would quickly modulate it's power output up to match the increased thermal load. Instead it was the flow temperature that showed a slow rise back up to the 51000 asymptote. Finally I decided to go for another boost in the heat control and this is shown by the final step up in the red trace, with the accompanying slower exponential rise in the blue trace.

So what can we learn from this chart.

1. The flow temperature is controlled so that it runs at a few degrees hotter than the return temperature.
2. The boiler responds rapidly to demand changes made on the control knob on the front panel of the boiler.
3. There is an appreciable thermal lag associated with having to raise the temperature of the pipework and rads up to the new temperature.
4. A sudden change in thermal load such as a cold rad being turned on (or a zone valve or DHW valve) will cause the boiler flow temperature to drop and slowly climb back to the original level.
5. For a given position of the front panel water temperature control, and a given circulation pump speed, the boiler can only produce a certain heat output. If the house is losing heat to the outside (on a cold day), the boiler might not be capable of reaching the room temperature as demanded by the thermostat - unless you turn the wick up a bit, by manual intervention on the heat control. This was proven over the last couple of days when the boiler struggled to get the living room above 17C.

Other Observations - made over the last few years whilst messing with the heating controls.

1. Older houses leak heat very easily. The amount of heat needed to keep them at a constant comfortable temperature, is directly proportional to the temperature difference between the outside temperature and the temperature you set the thermometer to.
2. it has taken the boiler about 2 hours to get the living room up to temperature (19C) and this was only as a result of turning up the heat control. The boiler has now entered a kind of cycling mode, where it ticks on and off about every 10 minutes. This is bad, because it gives the water in the pipework a chance to cool down, and the boiler has a 4 minute start up sequence. This is the boiler equivalent of stop-start driving in traffic - wasteful in fuel. So it must be possible to hack into the boiler heat control potentiometer so that it can be set exactly at the right setting to balance the thermal load and heat loss from the house - so the boiler doesn't keep cycling.

In the case of my house, where I have nearly 10 years of gas readings, I have found the constant of proportionality to be about 6kWh of gas consumption per day, for every degree difference. So if I set the thermostat in the living room to 19C, and its averaging 9C outside, the boiler will consume approximately 60kWh of gas in a 24 hour period.

If like over the last few days it's close to freezing outside, the temperature difference is closer to 20C, and so you will consume more like 120kWh per day in order to keep the house at the same comfortable temperature.
2. Somewhat contrary to expectations, I believe that in an older property that it is better to leave the heat on low 24/7 as this uses less gas than trying to heat the house for a few hours in the morning and at night.

So the next thing to do is to capture some data of room temperature and outside temperature and tie this in with the boiler behaviour. This will need another couple of thermistors wiring into my sensor board - and probably a move to using the Arduino as the sensing and control platform - mainly because its easier to try things out quickly than having to edit PIC assembly code.

Future Requirements.

I'm currently using a little PIC16F88 to read the two thermistors and send the readings plus a time stamp out to the PC using an FTDI serial lead. I built the PIC board onto some stripboard a few years ago as it was intended to be a wireless temperature sensor, so it has a Telecontrolli RT4 433MHz transmitter module on it and a couple of connectors to add thermistors and radio control servos - as I thought I would be using this board to open and close radiator valves. It's a handy little board, which predates any of my Arduino stuff by 5 years.

So in order to progress further with this investigation there are some extra things needed. I already have the flow and return sensors logging on a second by second basis. I now need to extend this to include a room temperature sensor in the living room and an outside air temperature sensor. This could easily be done with the Arduino, which could probably be embedded inside the control box area of the boiler, in such a way to share the boiler's low voltage DC supply. A protoshield would include the interfaces for the 4 thermocouples, an on/off relay for firing the boiler on and off and an analogue PWM voltage output to over-ride the heat control potentiometer. If I include 433MHz wireless Tx and Rx modules on the protoshield, I can get wireless temperature data out of the boiler and use the receiver to intercept the boiler on/off signals from the Drayton Digistat wireless thermostat - but I suspect that will shortly will be redundant. A USB socket on the bottom of the boiler will allow me acess to data output and to re-hack the Arduino code as new ideas arise.

According to the digital thermometer outside, it's currently -2.7C out there - so no wonder the heating has been struggling these last couple of days.

I can probably extend my little PIC board to read another couple of thermistor channels, so that the serial output of this board can be read by hyperterminal and graphed in XL - as how I have been doing it so far. However it would be good to get more practice in on C programming the Arduino, and this sort of project is ideally suited to it.

There is also the question of hacking into the water temperature control pot on the boiler. Recent boilers use either an analogue voltage control (0 - 10V) or an open protocol called Open Therm (OT) to allow them to be controlled remotely from other systems or devices. I suspect that I will first use an Arduino to generate an optically isolated PWM signal, which drives the potentiometer input.

Simple Displays and Homecamp

As part of a quick hack for the homecamp Christmas party competition, I put a few (42) different coloured LEDs onto a bit of stripboard - in the shape of a Christmas Tree. The LEDs were clustered into groups so that different parts of the tree could be individually driven.


As it was a 2 hour mega-rush-hack my addressing scheme wasn't the best thought out, but I did have the means to light up each of the tree branches individually, light up the star on top, plus the pot and stem as separate items. Having wired it up to the digital outputs of a spare Arduino and hacked a few lines of code to animate it, I was struck by the simplicity of it and the effective way that it could be used to convey simple information. It certainly comes alive after dark, with the previously almost invisible pea green LEDs contributing to the effect. These were a bit of a mistake - but I didnt have enough of the brighter blue-green ones and even connected in series it shows how efficient the blue-green ones are by comparison.

The green branches could be used in a sort of bargraph manner to show rising temperature for example, or as it was a Homecamp party, using the segments to show trends of energy usage would make a very appropriate application for it.

This sort of display is very easy to drive from a few lines of code, and is ideal for applications where numerical information is unnecessary. If this was a room thermometer or thermostat, for example, which progressively lit up over the temperature range 16 to 24C, a quick glance at it would be sufficient to tell you whether the room was on the cool side, just right or over heated. The nature of the display is that it's easily visible at the 3 to 4m range, which is good for most peoples room dimensions - and it doesn't mean you have to get up and peer at some tiny LCD thermometer digits to get an idea of room temperature. LEDs are cheap and easy to use - the whole thing could be built for under a pound, add a microcontroller, and possibly my micropower 433MHz transeceiver - and you have a wireless visual thermometer which can measure the room temperature and chirp out boiler on and boiler off commands to the 433MHz thermostat.

With a knowledge of the current cost protocol, it could be used to display household power usage - possibly rewarding you by lighting the star on the top of the tree when you are an "energy star".

Other uses are as an annunciator device to inform you that some event has happened - such as a distant relative logging into a chat program for example, or as a visual reminder, that something needs doing.

Whilst christmas trees may be seasonal this week - they will be somewhat forgotten about in a couple of weeks, but the concept of using a brightly animated LED display to convey trends or events is a lasting one.

A very short clip of the tree, with simple flashing firmware is on youtube:

http://www.youtube.com/watch?v=GeUvDwwX3-U

Wake Up Boo! -The 50uA Super Regenerative Transceiver

For the last few posts I've been looking at low cost wireless links and how you can hack them at home.

You might want to look at the previous posts, Take Control, Radio Days and Radio Gaga.

I first got started about 10 years ago working with 433MHz short range wireless devices for reading gas meters.
50uA operational current from a 1.5V Cell

Right now I'm designing a low cost transceiver which will allow any microcontroller to communicate with its neighbours but using a minimum of current from the battery - allowing smart sensors to last autonomously on small batteries for years, or to make use of solar cells or other energy harvesting techniques.

Here's my prototype low power transceiver built on a small breadboard. It's based around a Telecontrolli RT4 transmitter module on the left, a 74HCT14 CMOS Schmitt inverter in the centre and about 20 other components. The FTDI serial cable providing output to the laptop is on the top right.

The aim of this project is to develop a very low cost and low power wireless transceiver which can be used for short range smart wireless sensor networks. The cost of the transceiver could be as low as US$ 1.00 with volume production.

What's New

Following on from some of last week's ideas, I decided to make a couple of changes to the receiver. I've also managed to get the power consumption right down to just 50uA and the ability to run on a single alkaline cell. I've also had a few thoughts about using this design as a wake up receiver - hence the title of this post.

I've also got the circuit of this receiver captured in Eagle CAD and I am working on a board design - approximately 25mm square. If you want to share the circuit, please leave me a comment.

Changes From Previous Design

Previously I had been controlling the RF transistor in the super-regenerative stage by pulling down on it's emitter. This required an NPN transistor to turn the RF stage on and off.

It then occurred to me that rather than going in through the emitter, as per the Bolling and McEwan patents, the obvious way to control the RF transistor was via the base connection. This was even simpler - a direct connection to the data input pin on the Tx module, which connects through a resistor and capacitor filter stage and then onto the base of the transistor.

Thus I could eliminate the extra NPN switching transistor and simplify the circuit considerably. The advantage of this change, means that the receiver can now be made from an unmodified Telecontrolli RT4 module - further simplifying the amateur construction.

Even Lower Power Operation

I then decided to see if the receiver worked at lower battery voltages. Previously I had being using 3V, but I wanted to see how the receiver performed at 2V. After a bit of fiddling I can confirm that the receiver will still receive and decode 1200 baud data from a test transmitter located 10m (and 2 brick walls and a floor) away at 2V drawing just 98uA from the battery. I had achieved my first personal goal - the sub-100uA receiver, and one that would work in conjunction with a microcontroller running on 1.8V.

Not content with 100uA, I decided to find out what the lowest battery voltage was that would allow the super-regenerative process to occur- to determine just how low can you take the collector voltage on the Telecontrolli module before it just stops oscillating. With a fairly exhausted AA Duracell, I found that the lower operating voltage for the RF stage is just 1.2V. Any lower that this and the oscillator just won't start up.

A typical AA alkaline cell such as Duracell is 2700mAh capacity. With the receiver budget down at 100uA, this would mean about 3 years operating life on a single cell.

The bulk of the operating current is consumed by the RF oscillator. With a 100 ohm resistor in the supply rail to the Tx module I found that nearly 45uA was used by the RF front end, and only 5uA in the rest of the receiver circuitry. 45uA at 1.2V defines the lower operating point of the Colpitts oscillator, and this would be the fundamental limit to how low power this design could be made. Below 50uA, the receiver is getting to the point where it is no longer a useful receiver.

However, by lowering the baudrate of the signal, which means more energy per bit, it would mean that the receiver could be operated at a reduced voltage as a wake up receiver, waking the microcontroller, which then applies some more volts to the power rail, allowing it to become a fully functioning 1200 baud receiver.

A 300 baud signal would be suitable to detect in the wake up receiver. The filter capacitors needed for 1200 baud operation and 300 baud operation are likely to vary in value by a factor of 4. The correct capacitor needed for wake-up and normal operation could be selected using a pin on the microcontroller. I've now got the receiver running at 48uA and successfully receiving and decoding 300 baud packets.
Scope for Improvement

The scope trace shows the output from the second transistor running on a 1.3V cell at 300baud. You can clearly see the 1kHz nominal quench frequency superimposed on the 300 baud data. A better filter stage could be used to remove some of this making the signal easier to slice. With a bit of care and a suitable schmidt inverter it is possible to slice this data at the correct level and retrieve clean, square edged data. This raw signal is approximately 400mV peak to peak.

In each of these experiments I used my standard test transmitter which consists of another Telecontrolli RT4 transmitter module powered from a 4.5V battery and data pin driven by a PIC microcontroller. In order to make the tests representative of the real world, the test transmitter is located in the front room of the house and I work at the back - a signal path of 10m plus two brick walls.

Another thing I noticed whilst working at low supply voltages is that the relaxation oscillator slows down to about 1kHz, about 100uS on and 900uS off.

I tried sending a 1024Hz squarewave modulated RF signal from another test transmitter, and found that the output of the receiver was a squarewave signal equal to the beat frequency, between the relaxation oscillator and the 1024Hz test signal. This might prove a suitable means of causing a wake up. By choosing a wakeup signal that produces a strong beat frequency the resultant could be rectified, detected and used to wake up the micro.


Please leave a comment if you want to share any of this design or have any suggestions. I'd like to start a competition to see who can come up with the lowers power super-regenerative receiver. McEwan suggests that 1uA is possible - but I'm yet to be convinced.

Radio Gaga

For a few years I have been interested in short range wireless for smart sensor networks.

The two things that really interest me are firstly, a very low power receiver which could work on a few tens of microwatts of power - so would last significantly extend lifetime whilst running on a modest battery - e.g. 2 x AA Duracell.

Secondly a really cheap way of making a transceiver in such a way that transmit and receive functions share common parts thus leading to substantial savings in component cost and bill of materials.

Given these two goals, I set about my quest - a SAW Micropower Transceiver.

After some experimentation and breadboarding, I believe I have a simple design which could with some further development achieve these joint goals. The circuit is intended for smart sensor applications, which need to have a transmit capability, but their functionality could be greatly enhanced if they had a receive function too - especially if the incremental cost of providing the receiver is very low.

Working with such low power levels means that baud rates have to be low. The SAW resonator has a maximum switching frequency of about 4kHz so this limits the practical baud rate of these devices to say 2400baud - a standard baud rate that is easy to work and debug using a terminal programme. At 2400 baud, a typical 16 byte packet takes 66mS to transmit, which for domestic sensors for thermostats and appliance control is perfectly acceptable.

Working at even lower baudrates would allow even less power consumption in the receiver. The receiver could say fall back into a low power idle mode - where it can receive say a 300 baud wake up signal, which wakes the micro and reconfigures the receiver for 1200baud or 2400baud reception.

However, as is so often the case with electronics, it is a law of diminishing returns. You might have a great receiver that draws 350uA at 4V, but with 120uA at 2V it very much lacks in sensitivity - a lesson I learned by experience.

A US patent by Thomas McEwan was my first inspiration for a micropower super-regenerative receiver, but initial attempts to get this to work were something of a failure. However another trawl of patents turned up a few more interesting ideas. The result is a combination of techniques selected from the various patents.

A SAW Stabilised Transceiver

Dr. Eddie Insam describes in his Wireless World article how the super regenerative detector is very close in configuration to a Colpitts oscillator - which is used at the heart of most SAW stabilised transmitter circuits.

http://www.eix.co.uk/Articles/Radio/Welcome.htm

He suggests that you could start with a SAW based transmitter and convert it into a super- regenerative receiver. This is effectively what I have managed to achieve.

What sparked things off this week was a US patent for a SAW resonator stabilised super-regenerative receiver by Harold Bolling III, who worked for RF Monolithics - a US manufacturer of SAW devices

http://www.freepatentsonline.com/5751197.html

This uses a single port SAW resonator - just like the type used on most SAW based transmitter modules - such as the Telecontrolli ones I use.

I had previously failed to convert a SAW resonator based transmitter into a super-regenerative receiver - but this patent was the spark of information I needed. A simple modification to a standard transmitter module, and by driving it in and out of regeneration using an external PIC microcontroller, you get a passable super regenerative receiver.

Bolling's patent used a dual comparator and a quad op-amp in an elaborate timing and filter circuit for signal recovery - but as I could not get that part of the circuit to work properly, I ditched the ICs and decided to hack it with a couple of discrete transistors. This leads to a significant cost saving in components.

I have put this together on a breadboard, see top photo, and have a demonstrable receiver that initially used about 350uA at 3V controlled by a PIC. I have subsequently reduced this current to about 100uA.

When constructed from surface mount components, the whole design fits onto a board about 25mm square.

The range is pretty good for a super-regenerative receiver - at least 10m through two single brick walls - adequate enough for indoor devices such as room thermostats and remote switching of electrical appliances.

A simple I/O change from the PIC and the receiver reverts back to a standard 433MHz SAW stabilised transmitter.

The standard Telecontrolli Tx module uses 11 components, a typical super-regenerative Rx uses about 30. In my design, I take the standard Tx module, add a further 18 parts, which includes the PIC micro, a schottky detector diode and two NPN transistors and I get a complete 433MHz transceiver - costing under a pound to implement.

How it Works

At its simplest a super-regenerative receiver is an RF oscillator - usually based around a single RF transistor which is driven in and out of oscillation by an external quench signal which is normally between 10kHz and 200kHz. As the RF oscillator starts up, it exhibits considerable gain, and is very sensitive to any external RF which is coupled into the oscillator from an antenna circuit. If there is RF present, the oscillator will show a marked decrease in start-up time, or conversely it will use less supply current to reach a given level of oscillation - because some of the energy to achieve oscillation is supplied from the received RF signal.

In my implementation a PIC is used to generate an external quenching signal which is used to drive the Colpitts oscillator in and out of oscillation. This is a low duty cycle negative going pulsed waveform. In the first iteration this was a repetative rectangular waveform of approximately 10uS low and 90uS high. (This was subsequently improved to 16uS low and 354uS high - saving a lot of drive current). The quench frequency needs to be at least twice the baud rate of the serial data - as this is a sampled data system, both Messers Nyquist and Shannon need too be kept happy.

This pulse waveform is applied to the emitter of the RF transistor on the Tx module. The result is that the SAW stabilised Colpitts oscillator starts up and begins to increase its amplitude of oscillation exponentially. The output of the oscillator is capacitively coupled into the schottky detector diode, and it is given a light forward bias using a 10M ohm pull-up resistor. The schottky diode detects and rectifies the RF and this produces a series of negative going exponential pulses - of amplitude in sympathy to the detected RF. If there is a source of in-band RF energy, coupled via the antenna, into the Colpitts oscillator, then this RF will speed up the start up time of the oscillator, and the detector will reach full detection amplitude quicker but also be considerably slower to return to its quiescent state if RF is present.

This results in completely different pulse shapes emerging from the detector, depending on whether RF is present or not. From the change to the pulse shape, we get a change in the charge in the filter capacitor and from this we can amplify and recover the demodulated data. This detected pulse waveform is smoothed by a 2.2nF capacitor to reduce the level of the high frequency quench signal, the resultant being the demodulated AM data with an amplitude of between 10 and 50mV - see photos. This signal is then capacitively coupled into the base of the first external transistor via a 2.2uF electrolytic capacitor, where it is amplified to about. The NPN transistor is set up for a gain of about 25, with a 1M collector resistor and a 10M base biassing resistor to the collector. The output of this first transistor has data pulses about 500mV in amplitude and these are passed onto the second transistor to be squared up and brought up to logic level.

The lower scope trace shows the output from the detector when there is no RF present. The upper trace is the detector output when RF is present - a large change in pulse area. Timebase is 5uS and scope sensitivity is 50mV per division.

These traces are a little confusing because they are upside-down - an increase in detector output results in a lower level trace - i.e. things are inverted. By way of explanation - On the lower trace, when the pulse turns on the RF oscillator, the detector output rapidly falls, this is probably because the transmitter emits a pulse of broadband RF when it's first switched on. The oscillator then settles down to steady output shown by the exponential rise, which then levels out. However the oscillator is then turned off again by the rising pulse, shown by the short vertical section and overshoot at the end of the 12uS pulse. On the upper trace, the oscillator starts to stabilise, but is hit by a sudden input of external RF from the antenna circuit. This causes it to start to oscillate with greater amplitude than before, and this is characterised by the change in direction of the trace, becoming an exponential increase in detector output. Then the pulse turns the oscillator off, but the received RF still continues to produce detector output as the oscillator slowly ramps down to its quiescent state - which takes several tens of microseconds - upper trace. Thus the detector output has a much greater area corresponding to a significant change in voltage - this can easily be recovered with a simple RC filter circuit built into the first transistor stage.


Having an on board receiver will allow a smart sensor to receive configuration updates from the master hub, or receive and re-transmit message packets from other sensors. Additionally you could use a wireless bootloader and transmit firmware updates to the sensor via the wireless link.

Update 5/12/2009 - I later revisited the pulse generator timings, and settled on a low time of 16uS and a high time of 354uS, reducing the draw of the receiver circuit to just 170uA. It also allowed me to clock the PIC at just 500kHz - also reducing the power budget significantly. A means is needed to run the pulse generator autonomously of the PIC - such as a 74HC4017 decoded decade counter, clocked from the PIC's 32kHz watch crystal oscillator, or the internal PIC oscillator brought out to an I/O pin.

So, to sum up:

1. A super-regenerative (SR) receiver with an external quenching circuit, which turns on the RF oscillator for a short duty cycle of about 1:24 thus running on very low current. Less than 200uA for a 1200baud receiver running on a 3V supply.
2. A SR receiver that is made substantially from a SAW stabilised transmitter circuit, and at it's simplest, includes a 2 transistor signal recovery chain.
3. A SR receiver which uses a lightly forward biassed schottky barrier diode as a signal detector
4. A SR receiver which can be switched from receive mode to transmit mode by altering the logic levels on certain circuit nodes using the I/O pins of a microcontroller.
5. A SR receiver which can be implemented with sub-200uA current draw - opening up the possibilities of improved battery life.
6. A transceiver circuit which can be implemented in under 30 surface mount components on about 1" x 1" of pcb area
7. A transceiver that can be built in volume for under 1 US$
8. The SR functionality is almost "free" if a SAW transmitter is already used in the design.
9. A transceiver design that will form part of an open hardware smart sensor design.
10. A low data rate transceiver intended primarily for short range devices, smart sensor networks, control of domestic equipment and general use in the home.
11. A transceiver that can be modified to work in the various unlicensed bands, eg 315, 433, 868MHz.
12. A transceiver circuit which could be modified to incorporate a micro-power wake up circuit, using a voltage multiplier circuit formed from schottky diodes.
13. A transceiver that uses a voltage stabilised micropower relaxation oscillator to provide its pulse train.
14. A transceiver that uses micropower amplifiers made from CMOS inverters operating in their linear region as part of the signal recovery channel.

Power Management

In this version, the bulk of the 170uA is consumed by the Colpitts oscillator working on a 1:23 duty cycle. The PIC takes 550uA just driving the pulse stream - so a lower power method of producing the pulse stream is needed - possibly a 4017 decade counter running off the PICs 32kHz clock.

However, a better method is to use a single Picogate schmitt inverter, running as relaxation oscillator. With this oscillator taking just 20uA at 2.0V power supply - the prospect of a 100uA superregenerative receiver looks achievable. However - note that as the supply current is reduced, there will be a reduction in gain and sensitivity. It's all a case of tailoring the receiver performance to suit a given application.

The the two signal recovery transistors take just 20uA, but could be replaced with a single Picogate CMOS inverter, run in its linear region - see McEwan's patent. This provides high gain at very low power levels at only a small price premium over the two transistor solution.

McEwan's patent US 5630216 can be found here:

http://v3.espacenet.com/publicationDetails/biblio?DB=EPODOC&adjacent=true&locale=en_EP&FT=D&date=19970513&CC=US&NR=5630216A&KC=A

Whilst the PIC is in low power sleep mode, the receiver could be run as an even lower power wake-up receiver. The output amplifier/transistors could be used to amplify the output of the schottky RF diode voltage multiplier circuit. The wake up circuit would respond to a low datarate packet added to the beginning of the packet sequence, and this would interrupt the microcontroller out of sleep mode and enter the normal super-regenerative receive mode.

See Fig 3. here for details of 5 stage voltage multiplier circuit for receiver wake up design.

http://www.mobnets.rwth-aachen.de/fileadmin/templates/images/PublicationPdfs/2008/RTWAC-PIMRC-2008.pdf

Extensions to the Basic Design

The basic receiver has been built on a small prototyping breadboard using a Telecontrolli transmitter module as the starting point. This keeps all of the RF circuitry in one compact module with a good groundplane. The original design used just 15 components plus the PIC. Whilst the original used the PIC to generate the pulse train, this was to power hungry and so a low power alternative has been found. Some additional components have been added to make a more reliable design.

A 74HC14 Schmitt inverter has been arranged as a relaxation oscillator, to provide the train of pulses to energise the receiver. To get this inverter to run on minimal power a stabilised 1.2V power supply has been fashioned from three diodes in series fed from the battery rail with a 220K resistor in series and a suitable reservoir capacitor. The pulse output is fed into an NPN transistor and this pulls on the emitter of the RF transistor in the Tx module. This oscillator uses less that 8uA when running. The timing resistors have been chose to give an on time of about 20 to 30uS and an offtime of about 380uS. The total pulse train should not exceed 415uS - if you want to successfully demodulate 1200 baud. The relaxation oscillator is very voltage sensitive, so it is imperative that it is run from a diode stabilised supply - so that performance does not change radically with battery voltage.

Taking a hint from McEwan's micropower amplifier built from a 74HC04 inverter, I incorporate this as a pre-amplifier which follows the schottky RF detector diode. Whilst it is possible to provide sufficient gain after the diode detector from just two NPN transistor stages in series, as was achieved on the prototype, the preamp gives much better performance when working with weaker signals. As per McEwans patent notes this preamp runs on a stabilised 1.0V supply and draws literally a couple of microamps.

The signal recovery chain then consists of a series of three NPN transistor stages, the first to re-invert the output from the pre-amp, and the following two to provide filtering and data slicing so that the output of the receiver is compatible with 3V logic inputs on the microcontroller.

These additional features can be very economically implemented using Picogates - single CMOS gates in SOT23/5 surface mount packages.

Getting the receiver to work reliably on breadboard has been a little tricky - but as this was just to prove the concept, I can now move to a pcb design.

I have commenced a pcb layout of the transceiver using Eagle CAD, which appears to be a popular choice amongst the hobbyist community - thus making the design more readily available to those who wish to tinker. The complete transceiver fits into 25mm x25mm which makes for a very compact design if you include a surface mount PIC or AVR.

Further Ideas.

This prototype uses a pulse train to switch the emitter of the RF transistor thus driving the Colpitts oscillator into oscillation. It is probably equally viable to apply the pulse train to the base input of the RF transistor, which saves a little complexity and modification to the Tx module.

If you can accept a lower baudrate, the power consumption can be much reduced by reducing the frequency of the pulse train. This is done by increasing the off time. At 600 baud, we could afford to be on for 30uS and off for 800uS - initial experiments showed that you could get the RF front-end consumption down to50 to 60uA.

The signal recovery chain could be implemented in McEwan style, micropower amplifier stages using CMOS inverters. However you get just as many NPN transistors for the cost of a hex inverter IC.

McEwan's design used a pulse shaping network to drive the emitter of the RF transistor with a train of negative going exponential pulses. This had the advantage that it drove quite high currents into the emitter just enough to kick it into oscillation. He also claimed to be able to run the RF transistor with about 220K of resistance in the collector - forcing the RF oscillator also to work at very low current levels. I have not yet had any success with such a lightly biassed RF stage.

Radio Days

Some Thoughts about Low Cost Wireless Networks

This is the first of a few posts looking at short range wireless devices. I've experimented with these for a few years and believe that there is a requirement for a really low cost transceiver which allows smart sensors to communicate with each other. In the first of these posts I will look at simple super-regenerative receivers which I have encountered already by pulling apart devices such as wireless doorbells. These can be quickly re-purposed by adding your own microcontroller, which is what I did with the Lidl remote control socket.

Compared to WiFi and other 2.4GHz systems the 433MHz link is cheap and tacky, but it serves its purpose adequately. It offers a very low cost means for devices to get small amounts of data across a wireless link. It is used often in wireless doorbells, remote control systems and burglar alarm systems.

The Lidl remote socket used an example of a super-regenerative receiver and my transmitter pcb uses a SAW stabilised single transistor amplitude modulated (On/Off keyed) transmitter from Telecontrolli. The link runs at a pedestrian 1200 baud - it's best to always pick a standard baudrate to make it easy to debug with hyperterminal. 1200 baud is perfectly adequate for sending a few relay commands and temperature readings around the house.

Super-regenerative receivers are designed to be very cheap - but they can lack in sensitivity. They use a technique discovered in the 1920s by Edwin Armstrong, when manufacturers wanted a cheap wireless that only used one valve. Here's some Wikipedia info for those interested in early super-regenerative sets

http://en.wikipedia.org/wiki/Regenerative_circuit

Today this has translated into one active RF transistor but the principle is the same. A super-regenerative receiver is small and cheap to make often using less than 30 components.

The transistor is configured to be a 433MHz RF oscillator and is biassed up so that it is just on the point of oscillation. It is swept through this oscillation point using a lower frequency of a few tens of kHz. Any incoming RF signal will add to the RF transistors desire to oscillate, and this appears as a change in collector current. An op amp or a chain of 3 cascaded transistors is usually used to detect this change in current, and turn it into a logic level pulse which follows the detected signal exactly. The result is a signal that you can feed into a micros input pin and begin to decode the serial bits.

The super-regenerative receiver has at its heart an RF oscillator. In the 1920s super regen receivers could re-radiate and produce a lot of interference picked up by neighbouring sets. This might be seen as a disadvantage - but its not a million miles from what you need to automatically transmit a packet of serial data. In fact some cheap super-regens emit so much RF carrier that they can cause other signals to be blocked. When not receiving, this RF oscillator could be re-purposed to be a low power transmitter. In theory you could have a whole 433MHz transceiver costing about $1 to implement. This would be a really scungy transciever with only about 10m of range - but if you are using it in a network with other sensors which can retransmit messages, then in theory you could bounce your packet across a series of nodes and thus get to the gateway as a series of short range hops.

Super-regen designs are compact. With only one or two active components and 25 or so passives, they can fit onto a board the size of a postage stamp. They can also work at very low power - just a few microamps. There's a great patent for a super-regen by Thomas E. McEwan for a receiver that works down to 1 volt supply and 1uA of current

http://www.freepatentsonline.com/5630216.html

This makes it ideal for battery powered sensors which have to work for years from a single cell - or power harvest, from mechanical vibrations for example.

I had a go at copying the McEwan design - it worked to a point and had a range of about 3m when using a standard doorbell push as the transmitter. I suspect that it was working more as a crystal set than a super-regen though.

There is an renaissance in Super-regen designs as they can be implemented in silicon within the actual chip. This makes them ideal for say 2.4GHz bands where the antennas a much smaller. Such devices could be used as RF transponders for RF ID devices. They could possibly even harvest their operating power from the RF energy they receive - stored in a super-capacitor.

Super regenerative receivers are used in wireless doorbells, thermometers, remote control toys and other short range wireless gadgets. The photos show a commercial Laipac super-regenerative module and two doorbells - one in discrete through-hole components and the other in surface mount. These discrete designs will work at currents down to about 300uA.

The Laipac design is documented on the web and uses 2 transistors and an LM358 op-amp comparator device. The older doorbell achieves the receiver in just 3 transistors, and the newer doorbell does it with four. All low cost super-regens generally use a fixed capacitor and slugcore-tuneable inductor to get close to the required frequency. The inductor is clearly visible as the red plastic component on the back of the Laipac design.

Super regenerative receivers are also very easy to hack - in fact I first hacked one from a wireless doorbell I bought in Wilkinsons for under a fiver. You just have to find the serial output data - which is easy if you have a scope, or at a pinch a logic probe. Just connect this to your micro and start coding.

There's a well informed article about super regenerative receivers by Dr. Eddy Insam - well worth a read if you want to pursue them further

http://www.eix.co.uk/Articles/Radio/Welcome.htm

Eddie Insam talks about combining a super regen detector with a SAW stabilised transmitter device to make a cheap transponder or transceiver, but gives no detail away. He also mentions hacking a SAW stabilised transmitter module to make it into the heart of a super-regenerative receiver - tricky, but do-able, he says - I wish he would share some of that detail.

Over the next couple of posts I will share some of my recent findings.

Take Control

For some time I've wanted to tinker around with using the internet as a means of monitoring and control.

There's an appreciation that the growth in internet applications will likely be for internet connected devices - The Internet of Things, Web 2.0, or in sci-fi speak "The Rise of the Machines". Whilst not quite in Terminator league, I thought I'd get an internet dev board from Microchip and see what I could cook up.

The first step was to connect it up to a low power wireless transmitter, so that it could extend the scope of its control, beyond the confines of its own pcb.

I'm fascinated by minimalist solutions, and also hacking old gadgets to improve their performance or functionality. I like the idea of a network of very low cost wireless sensors scattered around the house, such as temperature sensors in every room linked to motorised radiator valves - all of which can be monitored and controlled remotely via the internet.

The key thing is that the sensors can talk to each other - regardless of the type of microcontroller make or model. So they need a standard serial communications protocol that they all can generate and decode. This protocol needs to have a low overhead to run on the smallest of micros with limited on chip resources and simple to hack and debug - more on this later.

I've coined the term "CheaperNet" to describe this network of low cost sensors, and so to get me started, I first needed a low cost candidate to be the first CheaperNet application.

There's a Homecamp Christmas party coming up soon, with talk of internet connected Chrismas lights - so I thought I'd hack together an internet controlled mains switch by way of a demo for a "show and tell" session to illustrate some of the virtues of CheaperNet.

This involves several stages of connectivity. Firstly using the PIC dev board which hosts a micro web server, using the free Microchip TCP/IP stack and the HTTP2 sever application that comes with it. This board acts as a kind of hub/gateway device onto the CheaperNet, and then radiating out from this hub is a a 433MHz wireless link to individual sensors. The first of these being the remote controlled mains socket. Plenty opportunities for a good hardware and firmware hack.

As stated, the PICDEM.Net dev board acts as a micro webserver. This is an almost "out of the box" solution requiring very little configuration to get you connected. The harder step would be to hack it to control a wireless link to a remote control socket which turns the electrical load on using a relay. Fortunately the PICDEM board has some LED outputs which can be turned on and off from the net, so if I could sense one of these I/O pins changing state and generate a wireless message to turn the remote relay on, it would be a simple enough hack.

The PICDEM board is a stupidly big board for what it does. All you really need is the £5 PIC in the middle and the ethernet connector. The little board below could also be dumped if you drive the 433MHz wireless transmitter straight off the I/O of the larger PIC.

The idea being that I can display my live electricity consumption in one browser window, and at the same time click on a button in another browser window that activates the Internet Socket turning something on - so that you can see almost immediately the effect on the live power trace.


A bit geekish perhaps - but worth a challenge. Good way to turn the Christmas lights on at the forthcoming Homecamp party.

The first thing to do was to salvage the old unreliable remote control socket that I purchased as a set of 4 from Lidls a few years ago.

These consist of a 433MHz super-regenerative receiver, a microcontroller and a mains relay all packaged in a plug in plastic case. Unfortunately, these suffer from any old 433MHz interference will cause them to turn on, or off, because of a very poor wireless protocol, which is readily confused by any other wireless devices nearby.

The solution was to implement a simple wireless protocol called SNAP at each end of the wireless link, and bodge a new microcontroller into the spare space in the plastic case. Probably the closest thing this cheapo Lidl switch has had to a brain transplant!

The existing Lidl microcontroller is dumped and replaced with one a little less stupid. The Lidl decoder was very prone to falsely switching when some other 433MHz transmissions - like the neighbours door bell started transmitting. I'm using a PIC16F88, solely because a have a few of them lying around the workroom and I have the beginnings of the SNAP wireless protocol already used on a past project


So after a few hours on Friday, I got the wireless protocol to work, and a few hours today got the unit together with new brain and a suitable wireless interface on my micro webserver dev board and voila I now have a desk lamp that can turned on and off from anywhere on the planet - or perhaps beyond.

This is a SnapRat board - just a PIC16F88 with a 433MHz wireless transmitter. I designed these a few years ago to make a solar powered wireless compost heap temperature monitor - definitely a world's first.

When you click on the 8th LED button on the web page, the micro on PICDEM board raises on of it's I/O pins (to light a real LED) I use the SnapRat board to monitor this and send a "relay-on" message to the receiver and PIC inside the remote socket. This turns the relay on - at a distance of about 20m indoors.

Some of the detail.

The PIC micro web server uses the Microchip TCP/IP stack. There are several dev boards which run this stack - such as those from Olimex or Celeritous.

I use a PIC16F88 to run the wireless protocol at both ends. The protocol is called SNAP (Scaleable Network Address Protocol) and details can be found on the High Tech Horizons site www.hth.com/snap/

I use a PIC implementation that is based on the published code by CASTRICINI & MARINANGELI - originally written for a PIC16F84. (See the HTH site). The whole protocol fits into about 850 words of ROM including the serial transmit and receive bit banging routines, error handling etc.

SNAP was designed to be a minimalist protocol to run on small micros. There are versions of it for BASIC Stamps and AVRs. Someone has bound to have hacked it onto an Arduino - if not - please would someone rise to this challenge.

If you want to see my firmware - leave me a comment.

Using an Arduino to monitor gas consumption

Energy monitoring is something I have been involved in for ten years - both professionally and "socially".

First a Historical Note - this formed the basis of my "off the cuff" talk, "Gas c.1999" at Homecamp 09.

Back in 1998, whilst working for a telecommunications equipment company we needed to develop a low cost gas datalogger for automatic meter reading (AMR) applications. It needed to read gas meter pulse counts from a Schlumberger meter and transfer them via short range wireless and good old fashioned PSTN telephone modem to a remote PC based server.

The wireless transmitter had to have a battery life of 10 years, running from an AA sized lithium thionyl chloride cell, and the low data-rate modem had to be self powered from the telephone line. That, plus the need to store gas meter readings every 6 minutes for 16 months made it quite a design challenge. Oh - and it has to be intrinsically safe to use in the hazardous zone around gas meter installations.

A two part product that featured a short range radio, a telephone network connection and had to meet the requirements of Ex intrinsically safe equipment meant that dealing with the various approval bodies was a major part of this product and not the actual engineering itself.

Technically the project was a success. Fine resolution gas meter data automatically retrieved from a number of trial sites. But at £40 a unit, it wasn't the low cost the utilities wanted - when they were only paying £5 a year for their small contract army of meter readers. The project was shelved in late 1999 - conveniently on my workshop shelf.

So now we have "Gas c. 2009" - the subject of a possible future Homecamp off the cuff presentation.

In the intervening decade, things have changed somewhat. Low power radio gadgets are now commonplace, and low cost energy monitors have been available for a few years now. (Electrisave, Owl, Wattson, CurrentCost etc). PSTN modems are well and truly a thing of the past, as broadband has all but taken over as the means of getting data out from low cost sensors.

In addition to these technical changes, several cultural changes have occurred in the last decade. Thanks to the efforts of a group of pioneering computer scientists working for IBM, Hursley - it's now cool to monitor your home energy usage , and the Homecamp unconferences have shown that I'm not the only one with an interest in energy monitoring - (and I thought that I was the only geek in the village. Of course it is a global village now - with a lot more residents).

Counting pulses from a gas meter became a whole lot easier when some meter manufacturers started to provide an opto-reflective silvered zero on the least significant digit of the register. Prior to this, there was a little red rotary pointer which was almost impossible to detect reliably via optical means - unless you were lucky enough to have a Schlumberger meter which came already fitted with an RJ11 connector and a reed-switch providing a "volts free" pulse output.

Technically, Transco, the gas transport company own everything up to and including your meter. If you want to measure the pulse output, they would provide a "Chatterbox" - a Ex certified relay box, which echoed the pulsed on to your own equipment. It was powered by 4 alkaline D cells. Transco would charge you a fixed cost of about £500 to come and install this unit. This proved an obvious deterrent for all but the most determined energy monitoring enthusiasts. This issue needs to be addressed if we are to make much headway in monitoring gas consumption. Nobody wants to pay £500 for a clunky old relay box that cost £20 to make. What is needed is a low cost, Ex certified, universal pulsecounter, which anyone can fit and geta pulse count from. Wireless seems the obvious choice - an opto sensor that sticks to the front face of the register and a self contained 433MHz transmitter running of a lithium cell. Essentially fit and forget.

The turning point for me came in November 2004, when my gas utility replaced my old meter with an Actaris, "pulse ready" meter. This had the opto-reflective silvered zero, ready provisioned to accept a photo reflective sensor. Sometime in Winter 2004, I put one of these together on a small scrap of veroboard, and then wrote a pulse counter routine in PIC assembler. However, come the spring, and a new extension to the house, and the whole project was forgotten and the pulse sensor lost.

So a couple of weeks ago - I decided to make another. I still had some of the photo-reflective IR sensors left. This time the coding would be a whole lot easier. In the intervening 5 years, I had learnt just sufficient C code to be dangerous - prompted by the arrival of the ubiquitous Arduino. The timing was right an announcement of a forthcoming Homecamp in about a month, meant that I had to pull my finger out and get hacking.

Here's the photo-sensor on a small scrap of veroboard - pushed onto a couple of locating pegs conveniently provided by Actaris.

The 4 wires are 5V supply, LED supply, photo transistor output and ground. I use an additional NPN transistor to buffer the voltage output and give me a bit more gain and sensitivity. Connect this into an Arduino ADC input and start sensing digits.

So the first thing I did was write a simple ADC routine which prints the ADC value to the serial port once per second so that I could see what was coming out of the sensor. This I captured in hyperterminal (aargh) and plotted out in XL - shown below. From this I could see that there was a very characteristic voltage pulse produced when the zero went past the sensor - but additionally all of the other digits had their own signature too - so with a bit of coding I could sense to the nearest litre.

A few lines of Arduino code, I had the pulse counter running, outputting the pulse count every second along with an (approximate) H:M:S timestamp. Having let this run overnight and during the time that the boiler fires for the water heating and central heating I had 60,000 readings which could be chopped into manageable chunks and graphed in XL. However this is such a tedious way of processing data so I thought I'd try something a bit more sophisticated.

I'd had recently acquired a CurrentCost CC128, and subsequently had been using Dale Lane's CurrentCost GUI for capturing the output of the CC. Why not write a sketch for the Arduino that mimics the CC XML data format, and then squirt this into Dale's GUI? Excellent idea and about 30 minutes of hacking the XML as a serias of serial print statements (thanks to CurrentCost for making their XML output format freely available on the Web) I soon had the Arduino interloping as a gas monitoring CurrentCost.

Individually, Pulse counts can be unspeakably dull. It's only when you get two of them, which are different, and separated by a suitable time period, that they become remotely interesting. If you take a reading at the same time each day, for example, and subtract them, then you get your daily consumption. If you shorten the sampling period from 24 hours to 1 hour, you can get a much finer resolution of when your boiler fires and how much it uses. You then extend this a bit further and start taking readings every 6 minutes and the picture becomes a lot more interesting. With 6 minute resolution you can see when the gas is being used, and by logging room temperature and external temperatures on other channels, you can start to see how quickly your house warms up, for a given outside temperature as a function of the gas you burn. Every house will have it's own thermal lag characteristic and once you optimise for this you will start to use it to your advantage and make reductions to your gas consumption - well that's the plan.

Real time boiler logging is a useful tool for diagnosing the defects of an existing system. In 2005 I made the poor choice of buying a 24kW condensing boiler. Had I bought a 12kW, it would have been more than adequate for my property and spend less time idling and modulating down to a lower power output. As with over powerful, fuel guzzling V8 cars - big is not always best.

Here's the first plot I got from Dale Lane's GUI showing the boiler modulating down as the return water temperature starts to heat up. The horizontal scale is 20 minutes and the vertical scale is from 8kW to 20kW.

Each pulse on my meter is the passing of 10 litres of gas. Gas is about 39MJ/m3 so by dividing 390,000 by the time between consecutive pulses, you get the instantaneous boiler power in kilowatts. Flat out, it takes about 16 seconds between pulses for my boiler - so I can deduce that it's consuming gas at about 24.4kW

Possible extensions: I have a couple of 10K pipe clip thermistors I got from Rapid Electronics. I'll use some of the spare Arduino ADC inputs to measure these and the internal and external temperatures.

I use a 433MHz Drayton Digistat to control the boiler. Having already cracked the "boiler on " and "boiler off" wireless packets using a PIC, I can get the Arduino to control the boiler.

Write a 3 term PID controller to control the boiler temperature - one that avoids massive overshoot, and consequent waste of gas.

I'm also currently hacking a "cheapernet gateway". This is an attempt at a very low cost ethernet gateway not dissimilar to an Arduino ethernet shield which will allow low cost wireless sensors to connect to the net and provide the means for realtime, live energy monitoring. Real time means once per second data (OPS) with a 2 second delay caused by the interweb thingy.

It's a while since I last updated this blog, but I have been working towards a more sustainable household.

This month I completed the installation of a wood fired stove with back boiler - returning a solid fuel heatsource to a previously abandonned fireplace.

The stove provides heat for the living-room - the most often occupied room, and heat from the boiler is conveyed upstairs to warm the bedrooms and the hot water tank.

The stoves burns about 1kg of well seasoned wood per hour, so a good armful of logs will keep it going all evening. We have been fortunate enough to obtain several tonnes of firewood from a fallen oak tree which should keep us going for a while.

The woodstove and boiler is a self contained system and needs no electricity to operate, unlike the gas boiler which needs power for it's control board, ignition, fan and circulation pump.

Once lit, it gets the room comfortable within about 20 minutes, and needs no more than adding a couple of logs per hour to mantain it.

It's just another element in my design for household sustainability. The cost of gas can go through the roof, and the electricty can go off but we will still be cosy in winter. The installation was designed to allow the stove to contribute to the existing central heating system, yet operate independently if necessary.

The cost of the complete system, including a stainless steel liner for the chimney, plumbing, plus a new stone hearth and brick fire surround was about £1600.