The Big Dig - Water Main Replacement

Today, just 3 days before Christmas, and with snow on the ground, Sutton Water Company are busy replacing the water main to my property plus that of my 3 neighbours.

The houses were built in 1905, and at that time it was standard practice to share a water connection between houses - especially if they were pairs of semi-detached properties. So it came to pass that four properties were all connected to the one section of lead pipe - and after 105 years in the ground, that lead pipe was leaking like a seive.

Back in July, during leakage testing, an excessive flow was detected on our shared main, and since the old lead main is no longer accessible as it passes under driveways, patios and modern extensions, the only effective measure is to replace the shared main with a separate modern plastic main and meter for each property.

The crew from the water company turned up at 8am on Tuesday and started to dig a couple of trenches, one near the pavement and one close to where the main would enter the property. Using a pneumatic mole, a duct was bored through the soft clay soil to connect the two trenches - a distance of some 15 metres. However because of very cold conditions yesterday, the Mole froze up in the bore, and had to be retrieved by digging a third hole, just 2m short of the pavement excavation. With one bore in place the blue water pipe was threaded through and the Mole set up again to put a second bore through for my neighbour's pipe.

Today the gang have got extra help from another 3 crews, judging by the 4 large vans in the street. The main runs down the road on the opposite side of the street, and so 4 separate access pits will have to be dug on each side of the street, and individual plastic connections tee'd into the original main. A lot of digging in temperatures that are barely above freezing.


Thursday morning, and Day 3 of the Big Dig. Two gangs from Clancy Docwra accompanied by another private contractor who's turned up with another compressor. About 11:15am, the water company arrived to assist with the pipe connections. It should not go unmentioned that replacing the water mains to 4 adjacent properties is no small undertaking, and made particularly gruelling in such bitterly cold weather. Whilst to the homeowner, the pipe from the pavement to their kitchen might at first appear a major task, this is actually only one small part of the job, and the connections to the water main on the opposite side of the street each with two access trenches is by far the bulk of the work.

Inside the house, in the kitchen extension, the dishwasher was removed to gain access, and a 32mm hole drilled downwards and outwards through the kitchen wall, such that the drill emerged in the small connection pit outside the kitchen window. This is a busy area in the kitchen with heating pipes, hot and cold water pipes and cables all laid in a ductspace that runs around the external wall of the kitchen. It's now a case of connecting up to the incoming main to ensure that the kitchen, bathroom and toilet, and the rising main to the tank in the loft are all connected to the new supply. The plumbing in this house dates back in various phases back to 1905, and much of it is no longer accessible, having been laid under the concrete floor of the kitchen and the 1950's bathroom extension. Once everything is working properly from the new main and no leaks detected, the old lead and copper connection can be isolated and left in the ground as a bit of ancient history.

I must say I am very impressed with the teams that have worked outside in miserable conditions, and temperatures barely above freezing. Sutton and East Surrey Water who did the work within the boundary of the properties and Clancy Docwra who undertook the excavations and connections to the main in the street. Whilst £900 is quite a large sum to find just before Christmas for replacing a main, when you look at the effort involved with up to 6 people on site for 3 days, it is clear that it is justified when you see the effort and comittment involved.

Smarter Heating - Ideas for Low Cost Zoning and Weather Compensation

In the last post I began do describe some of the desirable features of an upgraded heating controller. Here's a recap:

1. Smart Relay unit retrofits in place of existing time controller - no changes to mains wiring
2. Uses a hand held combined display and programmer/thermostat connected via wireless link

The hand held display/thermostat allow the thermostat to be located in whichever room you spend most of your time in. In most homes this would be the living room for the evenings, but if you work from home, you may choose to have the thermostat in your work room or home-office during the day. Portability means flexability. If you are wanting to reduce fuel bills by partial heating of a property, best that you focus the heat and the temperature control into the room that you are most likely to be occupying, and let the thermostatic radiator valves prevent excessive temperature in other rooms.

Regardless of where you choose to site your thermostat it will communicate via a wireless link to the relay unit which controls the central heating and hot water circuits. As a display unit it will offer you real time display of your energy usage (similar to an electricity monitor) and also an efficiency indicator and an indication of mean outside temperature.

Low Cost Zone Heating.

Back around 2005, I discovered that you could use a small amount of heat applied to the wax cartridge of a thermostatic radiator valve, which would cause the wax to expand and shut off the valve. I experimented first with power resistors and then power transistors and found that approximately 1W of dissipated power would completely close a thermostatic valve in 15 to 20 minutes. It would therefore be possible to have a controllable resistance fitted to each radiator's thermostatic valve and shut down individual radiators when they were not needed. It would only take about 10W of electrical power to shut off 8 radiators and this could be done as a low voltage (24V) signal distributed along cable, such as telephone extension leads. When the boiler is not running, the valve control resistors would not have to be energised, allowing further economy.

For this to work well, the controller would have to pre-anticipate when it was due to turn the boiler on, and open the valves some minutes in advance. It would make sense to use a long boiler on time and off-time, so that the latency of opening the valves is insignificant compared to the boiler on times. A longer boiler on-time could be achieved by turning down the boiler water temperature, so that it heats more slowly. This would also have the benefit that the return water would be close to 50C so that the boiler works in condensing mode most of the time. Additionally by increasing the hysteresis from say 0.2 to 0.4C would double the boiler on time. In an ideal world, the boiler would run continuously at what ever kW output was needed to maintain the set temp, however this may be difficult to achieve with a 24kW boiler in a property that really only needs a 12kW unit.

The boiler output temperature will be a function of circulation pump speed. By dropping the circulation pump to the lowest speed, the boiler will lower its output accordingly. This can however be counter-productive, as some tests proved. A combination of low pump speed and low water temperature means that the radiator barely gives out enough heat to satisfy the room temperature demand of the thermostat, so the boiler runs for very extended periods at low power. Ironically this can lead to the use of more gas, than if it were allowed to run for say 30 minutes and then coast, until the lower hysteresis level of the thermostat.

Building on the above idea, another control strategy might be to have a fixed on period of say 30 minutes, allowing the temperature to rise, if necessary, above the upper hysteresis point and then turn the boiler off until the room temperature fallss below the lower hysteresis point. A small amount of temperature overshoot will not be noticed, and this strategy will lead to a decent length of on time and a longer off time.

Weather Compensation

This is usually performed with readings from an external temperature sensor, which allows the output of the boiler to be controlled in response to outside temperatures. For example, in cold weather, it might be desirable to bring the boiler on for longer if certain temperature conditions are required by a certain time. Similarly, in a property with high thermal mass, the boiler could be turned off earlier, for example in the late evening, if it is known that the night is milder and heat loss will be reduced.

With the Christmas break plus daily cold weather, I hope to code up some of these ideas on my Arduino mega based heating controller, and try them out.

Smarter Heating - Some Results

Previously I stated that for an older property, there was the heat required to warm the house up, plus the heat to maintain a given set point temperature. Over this weekend which has been bitterly cold I have had the opportunity to do some datalogging and put some figures on to this.

First, here's the warmup from nominal 17C to nominal 19C on Sunday morning. This took 4 hours and used 50kWh of gas. In each of the following plots the x-axis is the time in minutes.

At the same time the outside temperature was rising from about -4 to about -1C - but more importantly to the controller, was the difference between inside and outside temperature - the Delta temp. As you can see the delta temp was between 20 and 21.5 C for all of the warm up period.

By 10am the room had come up to temperature and the controller enters the second phase - main room temperature at a comfortable 19C +/_ 0.2C.













The next set of 3 plots shows the detail from 10am Sunday to 10am Monday. This was the coldest night so far with temperatures down to -9.3C! Note how the delta reaches a maximum of 29. In real terms this means that the heating has to work about 50% harder, than if delta is about 20 - and thus use a lot more gas.






Below is the plot of the room temperature, once the system had stabilised, holding the room at 19C +/- 0.2C. Each little sawtooth is the effect of the boiler coming on at 18.8C and heating the room up to 19.2C - this maintaining an average temperature of 19C.

The Icy Blast

Unusually cold weather this winter arriving earlier than expected has once again focussed the mind (well mine anyway) on the subject of efficient home heating.

The nights of 17th and 18th December were without doubt the coldest nights so far this winter with suburban Surrey temperatures dropping to -6C.

As I write this we are experiencing a second wave of Arctic winds bringing temperatures down well below zero, large flakes of snow settling on an already frozen ground. More chaos due on the roads and airports, just 3 weeks after the first blast of winter that caused widescale disruption to transport and infrastructure.

In Britain we have the awkward situation that we do not get severe winters each year, so little is done in advance to prepare us for wintery weather. Much of our older housing stock was built with very poor insulation, and the time has come to upgrade the older houses with measures such as draught-proofing, adequate loft insulation, double glazing, more efficient condensing gas boilers and ultimately whole house external insulation.

External Insulation

Now whilst it may be possible to reduce heating gas consumption by 25%, in an older property with no cavity with a suitable thickness of external insulation, the cost of this upgrade will run to appproaching £10,000. With a current gas consumption of just £500 per year, a saving of £125 per year and with an 80 year payback time make the expense of external insulation seem barely worthwhile. However, the price of gas has trebled in the last decade, and if it continues to follow this trend, or just double with each decade, it brings the payback to a more realistic 35 years. It is questionable whether one would benefit from that level of expenditure, and there may be cheaper and more cost effective means to achieve the same effect.

A Cheaper Option

Over the last few weeks of wintery weather, my day to day gas consumption has been around 110kWh, costing around £3.50 per day. Now suppose that across the heating season, you could achieve a 10% reduction in gas usage through a smarter control system, well that would save about £50 on the annual bill, or possibly up to £100 for some larger users. It could paypack within 2 years.

The average central heating controller is a very simple timeswitch, used in conjunction with an often poorly sited thermostat. It is a technology which has hardly changed for 30 years, and is certainly not best suited to today's lifestyle. With modern microcontrollers and better temperature sensing it should be possible to gain overall better control of the heating system and a higher degree of comfort for lower gas consumption. This was the motivation behind the Navitrino Heating Controller.

The S-Plan wiring schematic for central heating uses two motorised valves connected in series with the room stat and tank stat respectively. When the valves have reached their closed position the circulation pump and boiler are energised.

Many houses have this simple heating plan. The time controller often uses an industry standard backplate, making upgrading the controller relatively simple.

Modelling the System

Firstly it is important to gain a knowledge of the existing heating characteristics of the house. These will depend on type of construction, outside temperature, prevailing wind, and whether intercommunicating doors are left open or closed. For example, one night last week, the boiler stayed on for an unnecessary two and a half hours, solely because the door between the living room and the hall had been left ajar. As my boiler is generally running on average for one hour in every three, that extra 2.5 hours represented a significant extra gas usage. However, for a given outside temperature, a certain amount of heat will be required to maintain the principal rooms at the comfort temperature.

Older houses, without cavity walls need more heat than better insulated ones. You have 2 layers of brick to warm up before the house feels warm, and considerably more heatloss through the solid walls. Older houses were often fitted with open chimneys and sash windows and these too lead to extra draughts and heat losses. For any given house, there will be a certain amount of heat needed to bring it up to temperature, and then another rate of heating to maintain constant temperature determined by the difference between external and internal temperatures. This difference between internal and external temperature may vary widely in cold weather, and it is not unusual for an older house to use twice as much heating fuel on a very cold day compared to a milder day just to maintain a constant room temperature.

The effects of weather can be fairly predictable, for example a cold day in 2010, may follow a very similar temperature pattern to a cold day in 2009, and a knowledge of past temperature profiles could be used to optimise the response of the heating controller to any particular day's weather. The temperature profile of a day could be characterised by just the maximum and minimum temperatures, the average temperature, or a series of readings taken at regular intervals throughout the day and night. The daytime temperature is also reasonably predictable, in that it will generally rise after sunrise and fall after dusk, and the rate of change of temperature lies between certain credible limits in terms of degrees change per hour. Knowing the rate and direction of outside temperature changes would allow a controller to predict where it needs to be in order to maintain comfortable conditions indoors, without burning gas unnecessarily.

A controller could be given a model of a typical winter's day, expressed in likely temperatures, chosen from a short list of typical types. There might only be only a dozen different day models required, to match the temperature profiles of every day between September and April. If these day models are characterised by average temperature, and sorted in order of descending and rising again temperatures, then if you have just experienced a day which matches model type 8, for example, the next day is most likely to be another 8, or a colder 7, or a warmer 9. The controller should be able to anticipate from night time temperatures, taken in the early hours of the morning, say 4am, what the following day is likely to be, and then take the necessary action to ensure that the interior of the house is kept comfortable. If say by 8am, the outside temperature has sufficiently warmed, then the controller may decide that it should be following a warmer profile.

Interfacing to existing systems.

In order to achieve general acceptability, a new heating controller should be easily retro-fitted to an existing system, without the needs for an electrician, plumber or heating engineer - it should be self-installable "Plug & Play" and utilise existing wiring, pumps and valves.

Fortunately, most standard timer based central heating controllers use a common wiring backplate, which allows one controller to be swapped out with a new one or indeed one from a different manufacturer.

This backplate usually has 6 connections, including live and neutral supply connections, and separate outputs for selecting central heating on and hot water on. If heating is demanded because we are in a heating on period, a relay switches live to the heating switched live, and depending on whether the thermostat is closed (demand) this live then energises the heating motorised valve. When this valve has fully opened, a microswitch is activated which then energises the circulation pump and the boiler. Similarly, if hot water is demanded, subject to the position of the tank-stat, the hot water motorised valve is closed and the boiler and pump energised.

So the existing controller could be replaced quite simply with a microcontroller and a couple of mains SPDT relays. Often the central heating programmer is fitted in the most awkward of positions, such as the airing cupboard, where the pump and valves and cylinder are located. This is generally inconvenient and a better solution would be to have a combined programmer and thermostat, which is battery powered and portable and which can be placed within the room where the greatest degree of comfort is needed – such as the living room.

Using wireless technology, this control unit could readily communicate with the boiler control unit to schedule the heating and hot water as required, whilst additionally acting as a display device for showing heating trends, gas usage and offering functions such as hot water and heating boost. This central display would communicate with room temperature and outside temperature sensors, and possibly wireless controlled thermostatic radiator valves, to make a fully integrated zone heating control system.

Some of the work done by Jean-Claude Wippler of JeeLabs on his JeeNode might be of direct relevance such as the JeeLabs RoomNode which was designed with the aim of measuring temperature, humidity, light levels and occupancy via PIR using a simple wireless sensor. Such a sensor network using low cost wireless technology which could be extended at a later date to include other compatible sensors and actuators.

Homecamp3, Heating and Disruptive Technologies

Monday 13th December was Homecamp3, held at the Centre for Creative Collaboration, in Acton Road, near to King's Cross station.

For a Monday afternoon/evening event it was fairly well attended with about 40 to 50 present. Many of these were Homecamp regulars, plus a few new faces.

The evening consisted of several interesting presentations on energy, cleantech and interconnectivity, with plenty of beer, wine and pizza which gave the event an informal, social atmosphere.

After James Governor's excellent opening address, first up was Gavin Stark founder of AMEE who described how AMEE were now codifying nearly a million different variables around the world.

Andy Piper, of IBM, Hursley, spoke about MQTT as a means of achieving interconnectivity between physical computing devices, and quoted some examples developed by Andy Stanford Clark, who unfortunately could not attend.

Usman Haque and Ben Pirt of Pachube presented an update on the new features included in the recently released new Pachube API.

Georgina Voss of Tinker London described the first phase Homesense Project - making Arduino technology available to real families and households with the intention of incubating new projects in home energy efficiency and lifestyle change.

Unfortunately, the 8pm deadline for closure of the venue came around all too quickly, and so we quickly re-charged on pizza and retired to the local Queen's Head pub. Regrettably there was not enough time to hear all of the presentations and get around to talking to all the attendees, hopefully Homecamp4 will be a full day event, and less pressurised for time.

Thanks must go to Mike Beardmore @mikethebee and his wife, who organised the venue and were perfect hosts. Additionally to James Governor's firms Redmonk/Greenmonk who sponsored the pizza and drinks.

All in all it was an excellent evening, and just what was needed during these dark days in the run up to Christmas. Hopefully it will have sustained the momentum of the Homecamp movement and given attendees something to think about over the Christmas break.

One of the people I did get to chat to was Simon Daniels, CEO of Moixa Technology

Simon described his low voltage dc household power distribution system. The concept is based on the premise that more and more of our household energy consumption is low voltage dc needed for an ever increasing variety of low wattage electronic devices which fundamentally run on dc, such as consumer electronics and LED lighting. Low voltage dc can efficiently be distributed on a household scale using existing wiring, with surprisingly low cable losses. This eliminates the needs for lossy ac to dc adaptors, and produces a power system which is efficient and compatible with home scale renewable energy devices.

Simon describes how a small window sill mounted pV solar panel, could be installed to many properties, such as flats, where access to the roof is not available, and at a price of £1K to 3k making it more affordable than a full rooftop solar installation. The dc from the solar panel would recharge a lithium battery system and provide sufficient power for the dc distribution system. A small solar panel of perhaps 200W could provide sufficient power to offset between 5% and 15% of the domestic bill.

For this technology to gain momentum, the large manufacturers of electronic goods and appliances need to collaborate on standards for dc supply, cabling and standby switching. A generic dc cable, for example based on a USB cable but with an additional pair of high current contacts to supply the variable voltage dc power. A process similar to USB enumeration would allow the device or appliance to be recognised by a central power controller, and supplied with the correct voltage. The standby modes of many devices, such as microwave ovens, are particularly inefficient, as they need to use 50Hz transformers to provide small amounts of dc power to run the timer or clock functions. By adopting a hybrid system of a dc cable for standby mode and control and a conventional ac connection for high wattage loads, would minimise the standby load to a few tens of mW plus offer the possibility of dynamic demand control. A washing machine with a timed standby mode could be automatically scheduled to run during a time of low grid usage, or the washing heating cycle paused and restarted, on the event of a sudden large demand on the grid.

Moixa will be running field trials in the Spring.

The Moixa technology is an example of a range of disruptive technologies which will ultimately change the way in which we use and pay for energy. Industry analysts have coined the term "Electricity 2.0" to describe the outcome of these changes. When combined with other systems such as smart metering, demand based tarrifing and dynamic demand control of appliances, the package could add up to significant energy savings within the household. Every kWh of electricity saved in the home is 2kWh off the nation's gas bill and more importantly less CO2 and waste heat into the atmosphere.

By introducing an energy storage element into the grid, possibly in the form of wide scale roll-out of Moixa's dc battery system, will allow consumption to be time-shifted out of peak time, and greatly assist in load balancing. Improved load balancing will permit the wider use of intermittent generation technologies such as solar and windpower, plus reducing the wasteful start-stop cycling of conventional generation plant.

With the recent and persistent cold weather, the annual subject of home heating and fuel efficiency has once again come to mind. In the next post I will describe some recent musings.

Stay Warm.

Navitrino goes MEGA

For some time I have been developing a central heating controller as the first application under the Navitrino banner.

Whilst it's never going to be the smartest or neatest heating controller, the knowledge gained in doing this relatively straight forward project will boost my experience of programming embedded hardware in C, and give me a whole set of new devices to play with, such as an SD card interfaced using the SPI bus, real time clocks, one-wire devices, ethernet controller interfacing and writing to modern displays such as those found in mobile phones. Navitrino is essentiallly a navigation exercise through the world of modern consumer electronic devices.

One of the problems I have found, is that it it is difficult to develop new code, whilst your one and only Arduino is busy runing a central heating controller. Obviously the solution was to get another Arduino - but it would be a shame not to take the opportunity to go for a massive hardware upgrade - which meant buying an Arduino Mega.

The Mega has been widely copied in China, and a look on TaoBao.com - the Chinese equivalent of Ebay, turned up loads of examples, including bare boards and other interesting shields. Whilst you can buy a Mega for as little as £17 from Hong Kong, I decided that I couldn't wait 3 weeks, so in a rash move, splashed some cash to CoolComponents and bought a brand new Mega 2560.

The Mega 2560 is the latest offering from the Arduino stable - and it is an Italian born throroughbred. It uses the Atmel ATmega2560 processor which is a 100 pin quad flatpack - bristling with I/O. No more would I be restricted to the 19 I/Os on the standard Arduino - now I would have 3 extra comm-ports, 10 more analogue inputs, 32 additional digital I/O lines plus the I2C port brought out to its own connector.

In terms of memory, the ATmega2560 has 256K of flash, 8K of RAM and 4K of E2. That should be more than enough for the largest of projects. The Mega 2560 is still quite costly - in fact you could buy two Chinese import Mega 1280's for the same price. Once the Navitrino application code is stable - I expect that it will fit into 128K - so the cheaper Mega 1280 will be the preferred option as the starting platform.

I've also bought the Nokia 3310 LCD shield from NuElectronics, which at £10 is good value for money. It can be set up as a 5 line x 16 character display, but can also display bitmaps and larger font texts. Andrew Lindsay has written an improved library to give better graphic functions and fonts compared to that supplied by NuElectronics. The Nokia shield also has a 5 axis miniature joystick with a tact switch action. This is connected to a resistor divider chain such that it produces an analogue value for each of the 5 axes.

I have modified the shield so that the reset switch can be used as a "hot water boost" button. This was done simply by removing the reset pin from the shield, clipping off the remaining plastic header which held the reset pin, and connecting a resistor from the exposed "reset" pad to the adjacent via which connects to the end of R14. I used a couple of 0603 resistors (8K2, 3K9 in series) but a 12K 1206 would fit. Pressing the reset button then generates an analogue value - just like the other switches on the joystick. For my choice of resistors it gave an analogue value of 916.


I also modified the board so that the power LED can be driven from digital output 2. In this way the LED on the shield can be driven independently from code to signal when the water is hot - flashing when the water is heating and staying on full time when the water has exceeded the 45C comfort temperature. These two new features allow the Nokia 3310 shield to form the basis of a simple user interface for the central heating controller.


The plan is to use the mega initiallly to develop a user/programming interface based on the Nokia 3310 shield and then the mega will eventually become the master or hub device with the ethernet connection which talks to a number of slaves. I'm also interested in seeing how the Mega can be adapted to present a series of identical ports - just like JeeNodes so that any device can be plugged into any port.

I've also bought some DS18B20 temperature sensors which I'm going to use to extend my temperature sensing network to allow four more rooms of the house to be monitored. It's an important addition to the basic controller - and there is a lot of interest in using one-wire sensors which use considerably less I/O pins than the equivalent thermistors.

Navitrino Heating Controller - Update

As an update to the status of my Navitrino heating controller project.

A flurry of hardware bodging and C coding activity this weekend has now got the 4 channel relay board fully operational. The relays control the central heating, hot water and the various pumps and valves in the system.

The relay board will be housed in a plastic cased "wiring centre" - either Honeywell or Danfoss - available for about £10 and located in the airing cupboard next to the existing controller where it is close to the pumps, valves and tankstats.

The HW and CH relays will be wired in parallel with the existing controller. This allow the existing controller to continue to be used whilst development progresses - so that hot water boost can be used.

The relay board just needs a 3 wire serial link back to the main controller so that it can receive the various relay-on commands. Ultimately this link could be wireless and would appear to be an ideal use for a pair of JeeNodes - a good way of getting to learn about the JeeNode project.

The main controller will remain in my work room until development has finished, but a display slave can be situated in the living room, so that anyone can access the "normal" thermostat controls from downstairs and without a degree in computing science/electronic engineering.

The aim is to progress to the point where the heating controller can standalone without the laptop running. There's nothing more frustrating to find that Windows automatic updates has shut down your application at 3:18am, whilst you were in the middle of a long datalogging run. This embarrassment will shortly be fixed with the Navitrino logging directly to SDcard, with no more need for a permanent connection to the laptop.

The code is progressing well, I can now handle heating decisions made on time of day and day of week. For example, at weekends the controller automatically sets the room temperature a little higher during the day, and doesn't start heating till 7:30am, rather than 5am on a workday. Virtually any set of rules and exceptions can be programmed in - it's just a case of deciding which ones are actually useful.

Testing has now ceased for the evening - as a result of an uncontrolled heatsource being ignited in the living room.

Time to sit by the woodstove and watch TV.

Jeepers!

JeeLabs and JeeNodes

The Arduino community spawns some interesting derivatives. One such device is the humble JeeNode from JeeLabs. JeeLabs is the company founded by seemingly tireless innovator Jean-Claude Wippler.

http://jeelabs.org/intro/

The JeeNode is a long thin pcb with an ATmega328 down the middle and a Hope RF RF12 transceiver at one end. It is loosely inspired by the RBBB (really bare bones board). The originals were made entirely from conventional components for easy DIY assembly.

I have known about these little ATmega328 and wireless tranceiver boards for some time now. However, I hadn't realised how much stuff this guy had done in the last 2 years.

His main innovation was to fit the low cost transceiver (£5) to every board - so wireless comms is central to the design. Secondly he arranges the I/O in four identical "ports" which carry one analogue I/O, one digital I/O, common interrupt, power and ground. As all ports are identical, any of his peripherals can plug into any port. To me, this seems a really neat way of arranging hardware, making it modular and expandable.

Just browsing through his hardware blog, he writes about something new almost every day, producing dozens of innovative little devices. I presume he has a software blog too !

http://jeelabs.org/category/hardware/

Lots of good stuff, well thought out and implemented - and almost all of it compatible with Arduino.

Whilst for compactness, he uses the 6 pin 2.54mm SIL header on his boards, he also expands these out to a 6 pin RJ11 connector, so that he can connect things up easily with very low cost telephone extension cables - about £1 for a 5m double ended cable.

Mindstorms

I was recently reminded of this connection method when I saw the Lego Mindstorms kit at an exhibition in London earlier this week. Mindstorms now consits of a vast number of sensors and motor devices, all of which are easy plug-compatible with the NXT controller. The NXT "brick" controller is quite a sophisticated device with an ARM 7 as the main processor and an ATmega as the I/O controller. It has 4 identicalI/O ports A-D and 3 motor ports which provide PWM power control of motors and tacho position and speed feedback. Wow! hasn't Lego grown up in the last few years - the height of sophistication in my early days was an electric Lego trainset.

So, the JeeNode identical port design is a great way to get a standard interface to hardware devices, and the wireless comms is a well considered addition. The RF12 module can run at any of the sub-1GHz standard ISM bands, and has a range and data bandwidth ideally suited to this application.

JeeMax?

So what if you built one of these around an Arduino Mega? (ATmega1280 or 2560) 16 identical ports with some I/O left over. As RJ11 sockets are only about 13mm wide, with 8 down each side, the board need only be about the size of an existing Mega. (108 x 54mm).

With each connector carrying AIO, DIO, power, ground, INT and unregulated power (eg 12V) a whole variety of different sensors or devices could be plugged in. Devices could be simple - such as a thermistor or PT100, or smart - such as microcontrollers or memory devices. Devices could be fitted with a very low cost 8 pin ATtiny, which gives them a unique identity, and allows the hub to identify their function - a bit like USB ennumeration, but simpler.

Using a larger pin-count micro on the device, would allow multiple channel sensors to be plugged into a single port - for example Trystan Lea's 12 channel pulse counter, or an 8 channel temperature sensor, or a 4 channel relay board. This would easily allow you to expand up to a large amount of I/O on a system.

Once the hub device has identified what devices are plugged in, it should be a much simpler task to build up a custom application around those devices.

Of course the JeeNode design brings wireless communications for remote nodes, but you still have to get power to these nodes. Wireless can struggle in older buidings with very thick walls or a lot of internal metalwork. Sometimes wired systems have advantages too.

Bodgineering!

Here's a really useful relay board fitted with four 10A mains relays. I bought cheaply a few years ago thinking that it might be useful. The only problem was that it used a PIC16F886 and a weird serial protocol to control the relays and the rest of the I/O.

How about transforming it into a Arduino Relay Slave - just what the Navitrino central heating controller needs?

A quick check of the PIC16F886 data sheet confirmed that the reset, power and clock oscillator pins of the PIC were nearly all in the same position as on the ATmega328 - as used in the Arduino. Those that weren't, could readily be bodged.

The only changes needed were that pin 19 on this board is grounded - no problem if I make D13 an input, and pin 22 - an output to an unused darlington driver, would have to be made OV to keep the ATmega happy.

The board has a 12V dc input, a 5V regulator and a MAX232 serial chip. In addition to the four relays, there are four further outputs driven by the same ULN2803 octal darlington driver IC, plus four opto-isolated inputs. All inputs and outputs have LED indicators fitted to show their status.

The first job was to trace all the connections and work out what I/O was connected to the relevant pins on the Arduino

Pin 1 Reset
Pin 2 RXD I1.0
Pin 3 TXD I1.1
Pin 4 Digital 2 Relay 0
Pin 5 Digital 3 Input I1.2
Pin 6 Digital 4 Opto-Input I0.3
Pin 7 +5V Input I1.3
Pin 8 0V 0V
Pin 9 OSC1 Osc1
Pin 10 OSC2 Osc2
Pin 11 Digital 5 Relay 3
Pin 12 Digital 6 Opto Input 0.2
Pin 13 Digital 7 OP 1.3
Pin 14 Digital 8 to connector J5
Pin 15 Digital 9 to connector J5
Pin 16 Digital 10 to connector J5
Pin 17 Digital 11 Serial Output (MAX232)
Pin 18 Digital 12 Serial Input (MAX232)
Pin 19 Digital 13 0V
Pin 20 AVcc +5V
Pin 21 Aref
Pin 22 0V OP 1.2
Pin 23 AN0/ Dig 14 OP 1.1
Pin 24 AN1/ Dig 15 Relay 1
Pin 25 AN2/ Dig 16 OP1.0
Pin 26 AN3/ Dig 17 Relay 2
Pin 27 AN4/ Dig 18 Opto-Input 0.0
Pin 28 AN5/ Dig 19 Opto-Input 0.1

Once I was sure that the wiring was OK, I replaced the resonator with a 16MHz crystal and fitted one wire link to correctly feed 5V to pin 7. I then made up a 4 wire cable with a header that would fit my FTDI programming cable. With this all done, I powered up the board without the ATmega fitted and confirmed that my power and ground arrangements were good.

I wrote a short test sketch to set up the I/O with the correct pin functions and to produce a slow sequence of turning the reays on and off. I programmed this into an ATmega on another known working board and then swapped the IC into my relay board - remarkably it all works fine! I have subsequently reprogrammed the ATmega in-situ with the FTDI cable and all is well.

That's the underlying beauty of Arduino, you take a bootloaded ATmega328, add a crystal and connect power and ground and very quickly you have a common I/O platform for rapid prototyping of your latest hardware project.

For a couple of hours work - I now have a working relay slave board, onto which I can develop some code. The board will be used to drive the central heating, hot water and pump functions which require mains relays to operate. A simple seria slave link as developed for my "serial command interpreter" back in August will allow this board to be driven from the main Navitrino master - or possibly remotely via the internet using the Etherduino.

Who said bodging was all bad?

Coding up the Controller

A brief catch-up.....

Since late June I have been developing a series of applications for domestic energy monitoring and control based on the popular Arduino open source platform. These applications come under the general banner of "Navitrino" which is an open source project to develop low cost hardware for performing energy control and monitoring tasks within the home.

Navitrino has so far been limited to Arduinos and its clones, because they are cheap, available and easily programmed, but with the portability of C code and the introduction of interesting new ARM based hardware like the mbed, there is no reason why Navitrino can't ultimately be ported to different platforms. For the moment the Arduino is perfectly adequate to develop applicatons and the various sensing and communication techniques which make up the Navitrino project.

To recap, what's been developed and discussed in earlier posts, Navitrino is a low cost, real time monitoring and control application currently running on Arduino hardware. The project has been aimed at DIY domestic energy monitoring and applications such as solar water heating control, central heating control, electricity and gas monitoring and solar pV monitoring.

Whilst I am focussing on gas central heating control - because of my particular circumstances, Trystan, Suneil and Glyn at openernergymonitor.org have been developing electricity monitoring, solar heating and pV monitoring and other temperature monitoring applications. To allow synergy between our work, we have chosen a common platform to work with, and regularly communicate to work on new ideas together. Other partners from Europe have joined up with openenergymonitor to contribute some of their own open source energy related developments.

Progress on Navitrino Central Heating Controller Application.

Meanwhile, I have been slowly improving my Navitrino central heating controller code - once I managed to get a functioning real time clock running last weekend. Now that the basics of the controller are working under the RTOS task scheduling framework, adding new rules and exceptions and making various control decisions is relatively easy.

From a control perspective, I split the day into 3 parts: day, evening and night. This allows specific temperature regimes based on the occupancy of the house. For example, during the weekday day period, we are generally at work so I have the controller keep the house at 17C, so that it doesn't get too cool and then take ages to warm up. At weekends the house is more likely to be occupied, and the comfortable temperature is required at around 7:30am rather than 5:30am.

For the evening period, the controller reads the setting from a potentiometer - which allows you to set the evening temperature at whatever you feel comfortable - I set it for about 19C. The evening period starts at 5pm, so the house is fairly warm for when I get home from work.

If we choose to light the woodstove in the evening, the living room heats up and the thermostat function of the controller makes sure that the boiler is kept off.

At night - after about 12 midnight, the controller allows the house to cool back to 17C, and then it holds it within +/- 0.2C of 17C - so that it only uses a little gas on the coldest nights.

There are already a couple of exceptions programmed into this scheme. As Elaine works from home on Thursdays and Fridays, I use the "day of the week" variable from the RTC to detect if we are Thurs, Fri, Sat or Sun and increase the day period temperature to 18C - which is a more comfortable daytime temperature for when the house is occupied.

Additionally I have introduced some hysteresis into the temperature decision making, so that when we reach 17C for example, the boiler doesn't keep switching on and off as we hover each side of 17.00C. I allow a band of 0.2C either side of the set temp before the boiler switches, so it will come on at 16.8C and off at 17.2C. This gives a longer burn time for the boiler and allows the pipes to heat up properly. It's overall less wasteful on gas than having the boiler constantly stop-starting.

I've also got the water temperature sensing working - so it advises you on the LCD to "Wait" if the water has not yet reached the minimum temperature for a comfortable bath/shower. Once up to temperature - it advises you that the water is hot.

This weekend I hope to wire in the two relays that correctly select either hot water and/or central heating so that it correctly controls the valves and will allow me to schedule hot water only for my 6:00am weekday showers, and get the hot water "boost" button to work correctly. If the heating is going to come on regularly during the night it may well be worthwhile selecting the Hot Water option to come on whilst the boiler is running, to top up the temperature of the hot water tank, rather than turning the boiler on specially to re-heat the water.

Additionally I want to see whether sensing the outside temperature at 4am can help improve the decision making in order to get the house up to temperature on time on the colder mornings. On Thursday it was below freezing until 4am, and suddenly with a depression coming over, the outside temperature shot up to 8C by 6am. These sorts of overnight sudden changes in temperature are not easy to predict - especially when the room temerature sensor is effectively isolated from outside changes by the lag of the thermal mass of the building.

The next job will be to have a look at the 1-wire code so that I can extend the sensor network to include more temperature sensors and pulse counters. Additionally I hope to get the code debugged to allow the SDcard for datalogging this weekend.

Keeping Track of Time

The Navitrino controller has been running the heating system for over two weeks now and logging the internal and external temperatures. However, with it doing a full-time logging job, there has been little opportunity to take it off line and develop the firmware further.

I have a simple milliseconds timer to update the hours minutes and seconds, and unfortunately this has been running a bit fast. I really need to incorporate the real time clock code and make use of the DS1302 real time clock chip fitted to the NuElectonics shield.

Earlier this week I came across a simple task scheduler to run on the ATmega/Arduino - developed by Daniel Bradberry, and documented in his blog

Yesterday, using a spare DIY Arduino clone, I had a go implementing his simple task scheduler .

It was simply a matter of installing his "Timer" library and adapting his example sketch to suit.
In his header file Timer.h you need to change this line of code to get the required task-tick time

#define INTERRUPT_INTERVAL 200

(this interval is then used in one place in the file Timer.cpp)

At the moment his second tick lasts something like 1.63 seconds, so I reduced the 200 above to 122 to make it much closer to 1 second. Unfortunately with the Timer 2 inside the ATmega, clocked at 16MHz, its not easy to get a very accurate second with the divide ratios available - closest you can get is 999.4mS which gains about 2 seconds per hour - but for most task timing it's fine.

His library allows you to set up a series of "once only" or repetetive tasks - with up to 10 independent timers scheduling them.

I set up tasks t_sec, t_15 and t_60 which kick off every second, 15 seconds and minute.

I have now re-jigged my central heating control/datalogger program so that it is controlled by the task scheduler.

The code looks a bit like this:

t_sec() {

// these are tasks you want to do every second eg update the time hh:mm:ss registers


task_1();

task_2();

etc


}


t_60() {

// these are tasks you want to do every minute

task_3();

task_4();

etc


}

If this partial re-write is successful, the next thing will be to add in the code for the SDcard datalogging, 1-wire and the RTC. However, these tasks will be much easier to implement now that I have the task-scheduler working.

More Navitrino Progress

My "Navitrino" heating controller has worked well over the last week or so, taking room temperature and outside temperature readings every minute and logging them to a terminal program running on my spare laptop.

Fortunately the weather has been fairly mild, and the heating system didn't have to come on at all - apart for heating the hot water tank for 20 minutes each day. My wife, Elaine survived with just the wood stove in the evenings, although the controller was set to switch on the boiler, should the temperature drop below 17C at any time.

I'm now going to try to draw up a specification for the Navitrino hardware, based on my experiences over the last few weeks. This is not an exhaustive list - just a few points on the "wish list" which can later be compiled into a more detailed specification.

1. Navitrino requires as a bare minimum, the configuration of ATmega328, SDcard and Dallas DS1302 RTC - as supplied on the NuElectronics SD/Sensor Shield. There may be a requirement for a link between Digital 5 and Digital 10 to standardise the SDcard with the SD library code. For more I/O intensive applications, the Nuelectronics sensor shield could be fitted to a cheap Arduino Mega. Megas are now available from Hong Kong for £17 - plus £7 postage!

2. Navitrino should run primarily as a RTC driven datalogger, with data logged to SDcard and echoed to the main serial port - for logging/graphing with KST.

3. The RTC is used as a task scheduler, with tasks scheduled for time of day, day of week etc. I have found some information on Daniel Bradberry's blog for an improved RTOS task scheduler library. This will be useful for setting up tasks such as heating on and off periods.

4. Sensors and I/O should have a means to be defined in terms of device type and channel. The physical I/O should be mapped into registers in RAM (ints and long variables in C) , with a regular task used to update the state of the I/O from the registers (for outputs) and vice-versa for inputs. There will need to be I/O handler routines - for example to read all the ADCs several times, and average each of them into a 16 bit unsigned int register. Similarly for 1 wire devices, these are read and the data passed into suitable registers for temperatures, ADCs and pulse counters. If a bank of relays or LEDs were driven from a serial shift register, there should be an equivalent register in RAM which holds the state of all the relay/LED lines.

5. There should be an easy way to set up new tasks and new I/O devices/channels. Perhaps some sort of configuraton editing program which runs on a laptop and downloads the updated configuration to the internal 1024 bytes of EEPROM on the ATmega. Alternatively it might be possible to read the configuration from a file on the SDcard. 1024 bytes might not sound a lot - but if a byte can represent a high level task or an I/O device, and timed schedules (start time, duration) can be fitted into 7 or 8 bytes then quite complex programs should be possible.

6. There should be provision to have a second serial channel, using simple serial, to drive a remote LCD display (like the one I used on the Disciple slave) and to receive button presses from a simple keypad - although the buttons could be read with a 1 wire device or even a spare ADC channel.

7. Perhaps "Navitrino" should be defined as more of a software process running on Arduino hardware, to act as a framework which allows sensors and tasks to be easily implemented.

I thought that the combination of Arduino plus NuElectronics sensor shield as being the minimum hardware configuration on which to host the Navitrino system. For anyone wanting to follow this project - this is a cheap and easy combination to purchase and put together. It is also the minimum hardware which will do standalone realtime datalogging - without the need for external PC support.

There would be applications where RTC and SDcard would not be needed - because realtime is provided by internet and data storage would be external/online.

So the problem then becomes how do you accommodate vastly different hardware configurations within the same basic system. How do you make it easy to add extra hardware, where it's needed, such as ethernet connectivity - yet keeping a common programming model for the unit?

So I think Navitrino should focus more on how to specify tasks and sensors within the software, and develop it as a common software framework which is easy to upgrade - adding more tasks or sensors as and when they are required.

Heating Older Houses

As some will be aware I am in the process of monitoring my domestic heating system, with the intention of developing a heating controller that offers better performance than the existing timer/thermostat one that is fitted.

The Navitrino has now been running for a few days, logging the outside temperature, the living room temperature and controlling the boiler so as to keep the living room temperature between comfortable limits.

The graphs show the variation in inside and outside temperatures over 31st October and 1st of November. On the 31st we had the woodstove blazing - not a very controllable heatsource - thus the peak of 24C and the slow cooling back down to 18C over a period of 16 hours. During this time outside temperatures were fairly mild - between 6 and 12C.

I believe that the thermal demands are unique to each property, which coupled with widely different lifestyles and levels of occupancy mean that there is no "one size fits all" solution to domestic heating control.

I have already written some control software, to control the heating, and found it convenient to split the day up into 3 time periods - loosely called Day, Evening and Night corresponding to periods of occupation and activity. For example in the evening when the living room is normally occupied, 20C is a comfortable temperature, whilst during the day 19C may be more appropriate. At night time, when the livingroom is unoccupied it may be acceptable to relax the temperature requirement to 17C, which allows more economical use of gas, but allows for a relatively quick warm-up.

The first stage is to monitor the thermal profile of the house, and the boiler behaviour and gas usage, for different external temperatures and generate a simple model of the thermal behaviour of the property.

My house has solid 9" walls and 4" internal brick walls. The living room has a large chimney breast which also retains a fair amount of heat.

What I hope to establish is a series of warm-up times, based on a given starting room temperature and setpoint versus the outside temperature.

Once the thermal mass of the room has been warmed up, the house will take much less heating power to keep it at the comfortable temperature.

For example, yesterday lunchtime between 12 and 1pm, it took 27kWh of gas to raise the room temperature from 17C to 20C. Once warmed up, the 20C room temperature could be maintained for the rest of the day and overnight with just 3kW heat (57kWh energy). During this time, the outside temperature varied between 12C and 9C - so not particularly cold.

The intention is to repeat these measurements for a range of outside temperatures. What is likely is that the 1 hour/ 27kWh "boost" heat will become longer in duration and use more kWh as the outside temperature falls.

I should mention that the heating system at the moment consists of 3 room radiators - with TRV, a bathroom towel radiator and 25m2 of underfloor heating. This heats the living room, kitchen, bathrom, my work room and 1 bedroom on TRV set to low. These rooms we consider to be the core of the house, leaving hall, and unused spare bedroom not directly heated.

Gas Meters Revisited!

In the last couple of days I have run a multicore cable from my work room at the back of the house to the gas meter which is under the stairs.

After two days of frustration caused by noisy optical sensors and false triggering, I decided to use one of my newly acquired Hall effect sensors as used on the Lister spark ignition circuit.

I have used a Hall effect sensor Farnell 178-4735

http://www.farnell.com/datasheets/621734.pdf )

clipped exactly in the same place as the optoreflective switch.

The Hall sensor is mounted so that the face with writing on it, which is triggered by a passing North pole is pointing towards the least significant digit wheel.

This wheel contains the magnet, roughly in the same position as the silver reflective zero digit.

The hall sensor will work from 3V or 5V systems and needs a 10K pull-up resistor because it is open-collector.

As the magnet passes, the open collector output goes cleanly to 0V. Many of my problems with the optical sensor was due to signal bounce and noise pick-up. This inexpensive Hall sensor seems to have cured all that.

To connect up you will need a 3 way cable, or if running a long distance - something like screened microphone cable would be suitable.

I'm still testing to make sure that my pulse bounce and false counting problems have gone away - it's interrupt code on the Arduino, so needs careful debugging to make sure its working correctly.

This gas logging ( and central heating control and monitoring) is all part of the work that I am doing on the Open source Navitrino project.

Navitrino Progress

Introduction.
Navitrino is a modular open source project intended for monitoring and controlling domestic energy usage.

Navitrino is an experimental platform, compatible with low cost Arduino hardware, which can be customised to meet the requirements of the individual's home energy installation. Navitrino can be assembled from off the shelf Arduino hardware, and programmed readily using the Arduino IDE.

Today's domestic energy systems are becoming more sophisticated with the addition of solar water heating, solar pV, heat-pumps and the like. Navitrino has been designed to monitor the key parameters of the system, make decisions based on usage, lifestyle and climate conditions and intelligently co-ordinate the various energy sources.

Navitrino was conceived with the following uses in mind:

1. Solar Water Heating Controller - simple control with circulation pump relay
2. Central Heating / woodburner controller - determines best usage of hot water
3. Electricity Monitor - whole house electricity consumption
4. Gas consumption monitor - pulse counter on optical or magnetic sensor on gas meter
5. Battery management system pV / battery charge controller/datalogger for wind or solar pV
6. Gasifier controller
7. CHP controller - engine start/stop, rpm, voltage monitor etc
8. General purpose control tasks
9. Temperature, climate and weather monitoring and datalogging
10. General purpose energy monitor for performing home energy surveys

Navitrino as a concept was intended to be as flexible as possible, so if a new bit of equipment or technique comes available, Navitrino can be extended and updated to cater for the upgraded system.

Navitrino is based on a nework of interconnected nodes. Whilst one device might be controlling solar and domestic water heating, another device may be used to monitor and log the household electricity and gas usage. Devices can share data with one another using a simple serial data format which is compatible with both wired and wireless networks.

Navitrino uses low cost, off the shelf, open source Arduino hardware as the basis of the project.
The Freeduino and accompanying sensor shield from NuElectronics, which has real time clock and SDcard interface provides the hardware.

Alternatively, if the final intention is to incorporate a Zigbee wireless network the "Stalker" board from Seeeduino Labs in Hong Kong also makes a ready to run platform.

Central Heating Controller.

During the summer months I have been slowly getting together all the necessary elements of the Navitrino project; sourcing the hardware, building up the sensors and writing some rudimentary code routines to exercise the hardware.

As we have now officially entered the UK heating season, one of the first projects for Navitrino is to monitor and control my central heating system.

I have mentioned this in an earlier post about using a DIY controller to monitor and control the home central heating system. Now is the time to put these ideas into action.

The task is fairly simple, the controller will monitor the living room temperature using a thermistor temperature sensor, and turn the central heating boiler on and off in order to maintain the living room temperature at a level as set by a rotary potentiometer.

In addition to the room temerature probe and the set-point control, the Navitrino also monitors outside temperature, the hot water tank temperature (2 places) and a light sensor placed in the living room. The idea of the light sensor is that it can be used to determine the living room occupancy - when the lights are switched off at bedtime, the heating will either shut down or revert to a lower temperature setting.

The controller also incorporates an interrupt driven pulse counter, which allows it to count pulse data from a gas or electricity meter - so that home energy consumption can be monitored. I am particularly interested in gas consumption and being able to relate it to central heating usage and outside temperatures.

Over the last few days, the prototype Navitrino has been controlling the central heating, datalogging temperatures and counting pulses from the gas meter.

Originally, I used an opto reflective sensor to detect the "silvered zero" passing by on the least significant digit wheel of the gas meter index. Whilst this initially showed promise, I found that the rising and falling edges of the pulses were prone to "bounce" which caused false triggering of the pulse counter. I have subsequently replaced the opto-sensor with a Hall Effect magnetic sensor - because the same reflective zero also contains a small magnet, intended to trigger Hall sensors or reed relays.

Arduinoids - The Rise of the Machines

Back in July I was contacted by Nikki of fizzPop Hackspace in Birmingham about making very low cost Arduino clones on stripboard. I hadn't really given it much thought until I realised how easy it would be to make an Arduino compatible device on stripboard (or breadboard) for something less than a fiver!

I've tried to standardise the design, to make use of the ATmega328 pin-out - which lends itself for an efficient layout.
Here's a couple of recent boards - one is a controller for a spark ignition system, and the other is a general purpose layout - just the Arduino in the corner of a vast expanse of prototyping board.

Below is the prototype spark ignition controller. It is based on the Atmel ATmega328 microcontroller and uses the standard FTDI USB to serial cable as a means of programming it.

The schematic is here: Lister_spark_IC.pdf

The following I/O pins were used

Pin 2 Serial Rx Input from PC

Pin 3 Serial Tx Output to PC

Pin 4 Digital Input from Hall Effect sensor (Arduino Digital Input 2)

Pin 14 Digital Output to trigger power transistor (Arduino Digital Output 8).

Pin 19 Digital OUtput to Drive LED (Arduino Digital Output 13).

The board is clocked with a 16MHz crystal to retain compatability with Arduino. The firmware is developed as normal using the Arduino IDE.

The board has a 5V regulator, a rotary pot to delay the spark and a blue LED to flash in time with the firing of the power transistor. The TIP122 transistor is mounted on a small heatsink. Connections to +12V battery, ground and the low tension to the ignition coil are provided on 1/4" automotive spade terminals. The 6 way cable exiting to the top left is an FTDI USB to serial cable. This provides +5V for testing and the serial interface for programming the board and getting rpm and ignition delay data back to the laptop.

The 3 pin Hall sensor plugs into the pin-socket just below the FTDI cable header - it has the same pin order as the Honeywell sensor +5V, 0V and signal out. For testing the sensor device can be plugged straight into this connector, and later extended with a 3 way cable.

The board measures 3" x 4.5" and there is space below the heatsink to take additional circuitry. You will need bit of stripboard at least 28 holes by 32 tracks to copy this layout.

Only 4 of the I/O pins are being used in this application, leaving the remainder for other future use.

One possibility is to add a further pair of TIP122 transistors, so that this board could form the basis of the spark controller for the 3 cylinder Kubota engine. If additional TIP122 transistors are added, they need to be isolated from each other if used on a common heatsink.

From the top the spade connectors are +12V, battery ground and coil output.

As a general point, the pin-out of the Arduino (see below) and ATmega328 maps very easily onto breadboard or stripboard. This means that small Arduino compatible projects like this can be made on stripboard or even breadboard at a fraction of the cost of buying the real Arduino and building a board onto it.

Buildtime was approximately 5 hours - but that included a lot of thinking time to get the component positioning sensible. To copy this board would take a couple of hours.

The second board is built along similar lines. At first it's just a microcontroller in the top corner of the board.

Here's the Partslist for the simple Arduino clone

1 ATmega328 microcontroller
1 28 0.3" pin DIL socket
1 7805 5V voltage regulator
1 16MHz HC49-4 crystal
2 10K resistors
2 330R resistors
1 1K resistor
2 22pF ceramic capacitors
4 100nF ceramic capacitors
2 22uF 16V electrolytc capacitors
1 1N4001 diode
1 LED - to show that life exists!
1 Stripboard at least 28 holes x 20 strips
1 6 pin 0.1" header
1 optional reset switch
Additional 5 and 6 pin 0.1" SIL sockets for connecting external I/O
single core hook-up wire - 4 colours used

1 FTDI cable for programming (optional) (ATmega328 can be programmed on Arduino board and swapped across).

The following additional parts were used on the spark ignition controller project.

1 10K rotary pot or trimmer pot
1 Hall sensor (Honeywell SS441R)
1 neodymium disc magnet
1 M3 (or equiv) bolt and nut for fixing heatsink
1 3 pin 0.1" socket
3 0.25" pcb spade connectors
1 TIP122 darlington power transistor
1 Heatsink

Datalogging & file storage with OpenLog

OpenLog is a an open source datalogger developed by Nathan Seidle of Spark Fun Electronics.

It consists of an ATmega328 microcontroller interfaced to a SDcard or microSD card. It retains a high degree of compatability with Arduino hardware - and indeed, early prototypes were developed by adding a shield with an SD card socket to an Arduino.

OpenLog is a serial datalogger. It does exactly what it says on the tin, and records all serial data that it sees on it's serial Rx pin. It is compatible with FAT16 and latterly FAT32, and so can work with SD cards up to 2Gbyte and 16Gbyte respectively.

It has a fairly simple set of commands which allow you to read, write and append the files on the card, plus traditional DOS-like commands for changing directory, deleting files etc.

As part of the Arduino Slave Network project, I thought it would be neat to port OpenLog to a suitable serial slave, and have it act as a central fileserver for the rest of the network. As the slaves are somewhat limited in their RAM resource, and cannot hold much data locally, having a central storage facility will be an asset to the system.

In this way, slaves with sensors connected could record perhaps a hour's worth of data and then write it out to the communications network, where it could be loaded into the RAM buffer on the Master or Hub unit - but more importantly stored as a CSV file on the OpenLog slave.

With this in mind the first task was to make an OpenLog and get it working. I have a NuElectronics "Sensor" shield, which has an SDcard socket and a Dallas RTC on board. Most of the I/O lines on the NuElectronics board were directly compatible with those in the OpenLog design, apart for the chip select line, which is on Digital 5, rather than Digital 10 on OpenLog - which used D 5 for running a status LED.

The quick solution was to modify the OpenLog code to move the status LED down to Digital 2, and then set the pin mode of Digital 5 to be an input. I then hooked a wire jumper from Digital 10 to Digital 5 - so that D10 still selected the SD card, and D5 remained a high impedance input.
To test OpenLog, you need a terminal emulator programme. Microsoft no longer include a terminal with their bundled software, so you have to find one that works. I eventually chose Tera Term 4.67 which seems to work well. I had no success with Termite or the Arduino Terminal window - neither of which appear to send CRTL z correctly.

OpenLog Storage Control.

To access data from the Slave RAM, there will have to be a command from the Master which requests the slave to write a block of data. The Master can also be used to create the filenames for the slave data to be stored and put the OpenLog into append mode at the right time to receive the slave data.

Suppose we want to create a file called temperature1.csv to accept temperature data from Slave 1.

The Master will have created this filename using the new command:

new temperature1.txt

Then before the request to the slave for data, it should issue an append command:

append temperature1.txt

Followed by the command to slave 1 to send its RAM contents eg. write out the first 1024 16bit integers from RAM:

w,1,0,1023

The slave will then write these as comma separated integer variables finishing with a ? to inform the Master that it has finished the command process. The Master then needs to send the escape sequence to the OpenLog so that the logging to temperature1.csv is closed.

The escape sequence could always be incorporated into the end of the data issued by the slave - this would then need no intervention from the Master to close the appended file.

Applying the Slaves

The Arduino Slave is designed to be simple to make and very low cost. Just an ATmega328 microcontroller, a 16MHz crystal and a reset circuit. In addition a 74AHC125 tristate buffer is used to control access to the serial network and ack as a buffer and line driver. One digital output line is needed to control the tristate buffer - leaving all of the remaining I/O lines for the Slave application.

The primary function of the slaves is for remote distributed monitoring and control tasks. Slaves are used to monitor changes in physical quantities - such as temperature and then perform some related control task. If the role of the slave is merely for monitoring a changing quantity - such as gas meter pulse counting, then the Slave acts as a small part of a multi-channel datalogger.

The Slaves are intended to run semi-autonomously. For example if a Slave is running a room temperature monitoring and control application, it is expected to do this without regular updates from the hub. It will continue to maintain the temperature set point and control the radiator valve accordingly until it receives an update to the set point form the Hub.

RAM resources on the '328 microcontroller are limited to 2K, of which about 1.5K will be allocated as a buffer to allow the slave to record up to 1 hour of data, and then feed this forward to the hub in the form of a CSV file sent across the network. Central to this store and feedforward mechanism working is the implementation of the OpenLog opensource datalogger on the Hub. A slave could take temperature readings every 6 seconds for an hour, package them up into a CSV file and then output them to the network in about 5 seconds at 9600 baud - in the time between taking consecutive temperature readings.

The datastreams will be organised as channels. A channel is a series of sampled readings taken from a time variant physical variable - for example "living room temperature", "electricity instantaneous power", "solar panel power output". A channel can be named, logged and then passed up to the Hub or laptop for subsequent further processing, graphing or display.

Towards the Networked Home

In the last few weeks I have been putting together the various tools I will need to make a distributed Home Monitoring Network. Previous posts have discussed most of the basics of this project, here I thought I'd summarise the project and what we are going to do with it over the next few months.

In essence, the network consists of several Arduino Slaves, all connected together on a simple wired serial network and communicating with a Master "Hub" device.

I'm doing this in conjunction with my friends at OpenEnergy with the intention of providing a demonstration system of what can be achieved with low cost hardware and a simple wired network. We are making the most use of open source hardware and software, and by keeping the system simple, we hope that it will be of interest to others. Later on, we might extend it to include some wireless nodes, but for now we want to keep the costs and complexity down.

Central to every node on our network is a small microcontroller board, based on the ATmega328 microcontroller, and firmware produced using the Arduino IDE. Keeping things compatible with Arduino hardware and firmware will ensure that others can try out our methods with minimum of fuss. At a bare minimum, our network could be used to connect an Arduino board to a laptop, so that it can be individually controlled over a few metres of cable by simple serial commands typed into a serial terminal emulator.

To extend the system beyond 1 board, some simple additional hardware is needed to ensure that only one Arduino Slave can access the network at a time. This involves fitting a 74AHC125 quad tristate buffer to each slave, such that only one will drive the network at a time. This device costs about 20p and is easy to add to an existing Arduino. The 74AHC125 and a 4 way screw terminal connector could be fitted to a protoshield board.

I've been programming my bootloader into new ATmega328 chips using another Arduino as a programmer, and in this way it keeps the cost of the Slave down. The basic Slave can be built for less than £5 which means that having several slaves on a network is still inexpensive.

Slaves send and receive data at 9600baud as simple comma separated variable (CSV) commands. The command set is compact, relatively easy to remember and can be typed from a serial terminal programme. The use of a CSV command means that commands can be readily interpreted using simple command interpreter code, and a low overall overhead to the application sketch. Additional commands are easy to write and can be added as the application needs them. Further details of the command set and application sketches will appear in a later post.

So with the basics of a wired network in place, it's time to start applying it to a real household application. In Snowdonia we worked on a monitoring and control system for a small solar pV installation, but at a planning meeting at the start of the weekend we discussed all the applications which could easily be handled with such a monitoring and control network. Here's a few suggestions in a non-exhaustive list for domestic and renewable energy applications:

1. Room by room, central heating controller
2. Gas consumption monitor
3. Whole house electricity monitor
4. Solar water heating controller
5. Solar Photovoltaic controller
6. Wind turbine controller
7. Battery Bank Management System
8. Generator controller
9. CHP controller
10. Greenhouse monitor/plant irrigation system