Knock on Wood

The observant amongst you will notice that most of my posts are named after song titles. This one is no exception. I have just returned from a week long odyssey to All Power Labs in Berkeley in Northern California to learn all about running engines on wood.

All Power Labs is based at "The Shipyard", a kind of creative artists community workspace, based in a couple of industrial units at the south end of Berkeley. They have a well equipped metal machining workshop with big machine tools and a metal fabrication shop. The artists share the facilities and develop great mechanical art projects such as the "Neverwas Haul" (pictured above) which attend festivals such as "Burning Man". Anyway the Shipyard is a very cool place - and I was lucky enough to hang out there for a week, and sofa surf.

Wood can be converted to a flammable gas, by a process known as wood gasification. The woodgas is then used to fuel a converted internal combustion engine. The technology to do this has been around for over 100 years and it was extensively used for running vehicles during WW2 - as documented in the recent book "Wartime Woodburners".

The aim of my trip was to learn how to make the technology work - so I could then set up a similar system in my Energy Shed and derive most of my household heat and electricity from waste woodchips.

So I flew out to San Francisco and crossed the bay to Berkeley - home of All Power Labs (APL) and the GEK gasifier. GEK is shorthand for Gasifier Experimenter's Kit.

APL is the brainchild of Jim Mason, a self taught gasification guru. When the city of Berkeley authorities tried to evict the artists from the Shipyard, they cut the power supply. Jim and his colleagues took the Shipyard offgrid with solar and diesel power and so they could remain operational.

Looking for an alternative to expensive diesel powered generation, Jim and his team re-discovered old studies on wood gasification and so the GEK was developed.

Over the weekend of 19th to 21st February I attended the Gasification Workshop, with 60 other delegates from all over the world. The workshop was hands on experience in working with the GEK gasifier, and other system components.

The fuel for wood gasification is just chipped wood. This drum load was made in a few minutes by running some old pallet planks through a wood-chipper. This sort of material can be obtained from tree surgeons who make so much they can't get rid of it quick enough.

During the course of the weekend we converted a Lister type diesel engine to spark ignition so that it could be run directly on woodgas. The conversion consisted of fitting a long reach spark plug in place of the diesel injector and devising a spark ignition circuit. A new pair of copper head gaskets were made using the CNC plasma cutter, and these were used to lower the compression ratio down to about 13:1.

The ignition circuit was made from an Arduino and a car ignition coil. A Hall effect sensor was used to detect a magnet on the flywheel, placed a few degrees before top dead centre. The Arduino was used to create the correct timing delay and fire off a darlington power transistor with a multi-burst spark.

A friend in Michigan had made a special wood-gas carburettor, which allows the air and the wood-gas to be mixed in the correct ratio. This fitted right on to the air-intake of the Lister engine.

By the Sunday evening we had the Lister running - in fact amazingly it ran first time without major adjustment.

There's a couple of Youtubes showing the conversion. In the first one, I explain to a small group of people what we are going to do and the second one, shows the engine running.

http://www.youtube.com/watch?v=lXPn5Nov9Fg

http://www.youtube.com/watch?v=kXX2GBHoeuo&feature=related

Keep the home fires burning

Freshly emancipated from my job in the city, I have reverted into suburban Victorian mode.

The 3 hours not spent battling with commuter trains are now either spent asleep or doing something useful.

This year we have had the addition of a wood burning stove and backbolier in our living room. This helps keep the core of the house cosy and offsets the amount of gas that we use. However, it must be stated that keeping a woodstove stocked with wood can become a distraction to other activities, more a labour of love.

Whilst man has been using wood to keep warm for millennia, there is a certain amount of skill needed to use it efficiently. Open fires are notoriously inefficient, and even some stoves have much to be desired. In the 21st Century, new wood based fuels are becoming available, and some of the mechanical handling associated with wood fuels can be automated. For the moment, I'm happy and contented to lie on the heath rug and gaze into the embers. Here's a few notes on how I keep this one burning.

Whilst you can just go out an buy a load of logs from numerous local log merchants, the quality is often dubious and you will need somewhere dry to keep them whilst they continue to dry out. Logs are often supplied quite chunky - meaning that further splitting is needed to make them more manageable for the woodstove -- despite its 18" log-length.

Another source of wood is from waste constructional timber. There are many loft conversions going on in this area, and I happened upon a load of roof timbers which were being skipped in the next road - so I offered to liberate them for nothing. These are generally older than 40 years - and so are not contaminated with pressure treatment or wood preservative.

Having cut the longer lengths into 6' pieces, so that they would fit in the back of the van, I hauled a van load back around the corner. These timbers are a nominal 5"x2" but when they are sawn the size is actually about 47 x122mm. They are probably Douglas Fir, and are very dry - so split easily with a hand axe. They are however full of roofing nails and felt tacks - so have to be handled a little carefully with leather faced riggers gloves.

After getting them home, they need to be chop-sawn into a suitable size for the stove. My chop saw has an end stop at 250mm - so this determined the average sawn length. Each 6' timber was sawn into roughly 7 pieces, carefully checking the path of the blade for nails and tacks before committing to the cut.

Once cut, the 10" lengths are split with a hand axe into two, generally unequal parts. These "halves" will burn rapidly and release their heat quickly. For a slower burn, whole pieces are used.

Eight of these 6 foot timbers will provide enough wood for two 12 hour burns. If we are both home, and the weather is cold, we light the stove in the early afternoon and keep it fired until past midnight.

The process of cutting up and splitting the roof timbers takes on average 30 minutes including the time to get out the chop saw, carry the timbers to the cutting area and tidy up afterwards.

The box on the left contains 30 of the 10" pieces and weighs 22kg. This gives the wood an average density of 511g/litre, and I have seen these pieces vary in mass from 500 to 800g.

The calorific value of woodfuel is approximately 4kWh/kg so the box represents about 88kWh of energy. Unfortunately, a basic cast iron woodstove is not a particularly efficient converter of wood into heat - so roughly half of this energy will reach the occupants in the room, the rest will be lost up the chimney. This is however about twice as good as an open fire.

Wood can vary in moisture content, depending on how it has been stored, and different species have different calorific values and burn rates. Better stoves do exist, but what is needed is a change in the technology in order to get the most out of wood. This is where wood gasification comes in.

Wood gasification is the conversion of woody biomass into a mixture of flammable gases, which can be burnt at optimum efficiency in a modified stove or burner. Woodgas primarily consists of carbon monoxide CO and hydrogen H2, with small amounts of CO2, methane and half of the mixture consists of the inert nitrogen from the atmosphere. Woodgas varies in calorific value from between one eighth to one sixth that of natural gas. Wood gas can be used as an engine fuel for riunning vehicles, generators and other machinery. In principle, it should be possible to run a whole household heated and powered from woodgas. Well that's the plan.

Next week I travel to Berkeley, California to learn all about wood gasification and how to build wood gasifiers. There is a project planned to convert a Lister diesel engine to run on wood gas using a spark ignition conversion - so that's what I'm hoping to do, learn how it's done and bring the technology home.

An Arduino's Not Just For Christmas - but for all in 2010

I've been playing around with Arduino's for just over a year, having discovered them whilst researching low cost computing tools.

How can a little microcontroller board like this become a life changing device?

The Arduino is a classic case of something which exceeds the sum of its parts. On one level, it's just a cheap, 8 bit micro built on a board with some I/O and an accompanying programming environment. On an other level it's a unique tool which brings open source computing and programming skills to many different communities and professions.

A low cost computing device, plus the backing of a huge online community has helped develop an open source product rapidly turning it into a successful phenomenon.

Online communities, and social networking groups are actively bringing people together who share common interests and have brought about changes in the way we work and the way we interact with other people and organisations.

In the last year I have become a member of three or more online communities, who all use Arduinos to perform various tasks. The Homecamp Community are interested in changing the way we use energy in the home by way of increased awareness of our consumption. They also have an interest in re-purposing (hacking) consumer goods to give them modified functionality, or just for fun.

Through some of my Homecamp friends, I was introduced to the London Hackspace at an Open Source Hardware conference in early December. The guys from the Hackspace also use Arduinos, and are involved with other OpenSource projects such as the MakerBot. Last week, for one of their monthly meetings in London, arranged a beginners session for the Arduino at the Trampery - a "Co-Working" open office in Shoreditch.

In just over an hour, you learn how to blink an LED, use the Arduino to control the brightness of the LED, interface to a switch and control a process with an input from a potentiometer. The workshop was practical and hands-on, and avoided over-complicated lessons in the C programming language. These can come later for those who want to take it further.

Working, by necessity, in central London, comes the advantage that you are never too far from meetings at social get togethers. This was something I had failed to appreciate in the 20 years or so I desperately shyed away from London commuting. I now take the attitude that if i must travel up to London on a daily basis, I might as well make the most of the evenings up there, avoid the evening commuter rush and meet a few new people.

In addition, I use the Arduino at work as a development and prototyping aid, because its quick cheap and simple to get something up and running. Whilst I am not a natural programmer, I do amaze myself how quickly and with very little effort you can develop applications on this device. It's handy because of it's portability. Just plug into your laptop, wherever you might be, hot-desking or on the train, and you can spend a little time developing.

So, crystal-balling, for 2010, what new direction will this open accessible physical computing take us in?

Already the Arduino community are extending their programming environment and hardware to make larger more powerful microcontrollers available. A whole new community of non-programmers is being introduced to the C programming language and its unique ease of portability. The Arduino is being extended with Ethernet and web connectivity, and interfaced to mass memory and USB devices. Wireless connectivity through Zigbee, Bluetooth and other standard are making Arduinos portable and no-longer tied to the back of a laptop. The basic Arduino with web-connectivity can form the core of a monitoring and control system that can be accessed from a browser anywhere in the world, and from a variety of platforms, - soon you will be able to check your household electricity or gas consumption from an Iphone app. Arduinos are already tweeting information around the net. For the techie, the Arduino has laid the groundwork towards the £10 internet-enabled computing device is likely to appear sometime this year, in a form that can be built into many innovative products.

The Arduino or its successor- which I'll call Arduino 2.0 or Webduino, once coupled with web connectivity, brings firstly to the technical community, and later to the wider consumer market the enabling technology of microcontroller with always-on web communications. This combination of control and remote communications will find its way into many products and environments - and give further fanning of the flames to Web 2.0 - the Internet of Things.

On a larger scale, key companies in Shoreditch's "Silicon Roundabout" phenomenon, clustered around the Old St. tube, have recognised the usefulness of the Arduino and at least two are using it as part of their business. These organisations are getting together with other groups and offering starter courses and evening workshops - to bring the technology out to a wider audience.

So the humble Arduino, combined with social networking groups, new communications methods and the occasional meet-up in town can bring a whole new dimension to the life of the technical-curious.

Links to topics mentioned above

Open Source Hardware
Pachube
Homecamp
London Hackspace
The Trampery
Arduino
Tinker.it
Silicon Roundabout
Internet of Things (Wikipedia)

Here Comes the Rain Again!

Finally, after a month of cold, sub-zero snow and icy weather - we are now back to a state of liquid water.

Whilst in the south east, the thaw really started at the beginning of the week, Wednesday caught a lot of people out. Who would have known that just 1 or 2cm of fine powdery snow would cause disproportionate chaos on the roads and rail network.

I walked down to the station at 6am, in time to catch the 6:13 to Victoria. It was still snowing, and the combination of fine powder snow and the third rail electrical pick-up system used on the Southern trains, made for a commuting disaster area.

A layer of compressed snow was building up between the pick-up shoe and the conductor live rail. When the train tries to pull off, all you get is arcing and the traction computer goes into restart. After 3 false starts and loads of intense white arcing we finally got moving at 06:45.

However, because we were the first train north out of Redhill, we had 3 trains loads of customers on board - and it was breathing room only. To make matters worse, the train was only 4 carriages.

After a very uncomfortable 45 minutes on board - I got to London Bridge, where fortunately I almost immediately caught a South Eastern Train to Charing Cross. Fortunately because of my early start, I avoided much of the ensuing chaos as rush hour approached.

By the late evening the network was running well. I got a 23:12 out of London Bridge, and a 23:30 from East Croydon back to Redhill. I had had visions that I might be sleeping on the sofa at work, if 'd failed to get home that night.

By Thursday the big thaw was on, and by Friday most of the snow melted from Monson Road. I can now actually see my garden again for the first time in 10 days.

//rant on

The Council now have absolutely no excuse left why they cannot empty my bin.

Lessons need to be learned about how to cope in this unusual weather. Councils should be mandated to store 4 weeks of salt, every year. Schools should not shut at the first sign of a few snowflakes - on health and safety grounds. What do the kids do when it's snowy? Run around in the snow, chuck snowballs and go sledging. It's a lesson in life that we just have to chill out in snowy conditions, apply some common sense and just get on with it.

I suggest we withhold our Council Tax for the period of December and January - they certainly have done nothing to deserve it. No schools, minimum road gritting and bins that have festered since mid-December.

//rant_off

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.