Sustainable Suburbia

A £10 Tiny Basic Computer you can build yourself

2011-12-27T10:47:00.008Z

Back in August 2010, I came up with the idea of a DIY Arduino built from a few components and an AT mega built on stripboard for about £10.

Just take an ATmega328 pre-programmed with the Arduino bootloader (from CoolComponents, Farnell etc) and build it onto a small scrap of stripboard about 50mm square, with a 16MHz crystal, a few capacitors, resistors and a 6 way header strip to accept a programming cable - and for about £10 you have a little Arduino compatible computer on which you can run real control programs.

If you then load Arduino Tiny Basic onto the microcontroller, you have a device that you can program in a very simple programming language - direct from a serial terminal program, and use it to flash LEDs, make light chaser displays, make analogue sensor readings and a whole load of other stuff - just with a few lines of Basic code.

Tiny Basic is a very simple to learn language and is ideal to teach newcomers the fundamentals of computing. This make it ideal for youngsters and students who perhaps have had no experience of real computer programming.

In this minimal form, the ATmega328 has 12 digital output lines and 6 analogue inputs - plus the two signal used to support the serial terminal interface.

I hope to release a very low cost pcb and kit of parts for this in the New Year - allowing anyone to make a £10 computer.

Happy New Year

More Tiny Basic - the plot thickens

2011-12-25T09:42:00.004Z

Since finding Tiny Basic for the Arduino yesterday - by the powers of Twitter and being well connected to some very clever programming pals - we now have the digital and analogue input and outputs working - thanks @ceejay for adding this functionality.

So its now possible to flash LEDs from a simple basic program - so there is now temptation to write a Christmas lights chaser routine with a handful of LEDs and a few lines of code.

I have started a Tiny Basic Wiki page for anybody to put up their contributions, updates and improvements.

What I love about an interpreted language like Basic - is that you don't have to go through the edit-recompile-upload process - you can change your code as quick as you can type a new line and type run. This means that it is very quick to change variables, like loop parameters, delays, threshold values - without having to spend 3 minute going through the previous cycle.

This immediacy of changing how your application work with a change to a single line of code is what really appeals - it makes programming a lot more fun. And this could be very important if you are 7 years old with the attention span of a goldfish.

Tiny Basic running on the Nanode or Arduino is proving to be very quick. I think my generation that grew up with 8 bit home computers, had the attitude that Basic was slow - and perhaps it was on a machine clocked at 4MHz or under - where the cpu was doing a lot of other stuff at the same time. This cut down version of Tiny Basic is lightening quick on a 16MHz ATmega328.

I noted a few benchmarks whilst running the serial terminal interface at 115200 baud:

1 million FOR - NEXT loops in 45 seconds
10,000 10 -bit ADC reads and printed in 7 seconds, 4 seconds if you don't print them.

The plan is now to start a Wiki page so that others can contribute to the Tiny Basic project, add new functionality and extend the usefulness.

On the Nanode we now have a rich set of peripherals and interfaces. Making use of the micro SD card as a solid state drive for loading and saving programs is an obvious choice. Some better editing features would make code entry simpler - and of course having interactive coding via a web browser is a goal for the near future.

Happy Christmas

Ken

Tiny Basic running on Nanode - Christmas Challenge

2011-12-24T08:25:00.005Z

This is something I have wanted to do for some time - run an interpreted Tiny Basic on the Nanode - so that newcomers can program it quickly and easily.

This would make Nanode a lot more accessible to novice programmers - and could have an important role to play in helping to teach kids the basics of programming and computer science - just like we learned 30 years ago - on simple 8 bit machines running basic.

A Nanode as a web connected platform sells for just £25, or fully built, tested and expanded to include micro SD card, Realtime Clock and wireless transceiver for just £40. (That happens to be what I paid for a ZX81 kit in 1983).

The latest Nanode really is evolving into a small computer system, with it's 32K SRAM and the micro SD card. There should be the means to run programs out of these memory devices, and use the SD card like a hard disk for file storage and retrieval - and tasks such as datalogging.

The first task was to find a program which can be used like an operating system - in order to tie all the various hardware functions and libraries together.

Tiny Basic hails from 1976, when the Homebrew Computer Club of Menlo Park - in Silicon Valley were looking around for a simple and compact interpreted language that would run on their homemade Altair 8800 machines - and did not want to pay the young entrepreneur William Gates $150 for his version of basic. So a challenge went out to the members to write their own - and several did, the most notable was Tom Pittman.

http://www.ittybittycomputers.com/IttyBitty/TinyBasic/index.htm .

Tom's original code has been adapted for many different platforms over the years - some written in native assembly language and some ported to C - so that it might be platform independent.

I recently was made aware of an assembly language version that compiled on an AVR (eg ATmega328) into under 4K - but modifying this code was going to be a little to intense for most people - so I was delighted to see that Mike Field had taken the generic C version and updated it so that it can run on an Arduino - or Nanode - without modification. Mike's working port of Tiny Basic - written in C, compiles into just under 7.8K on a standard Arduino. If you crank the baudrate up to 115200 - it is surprisingly quick at executing.

http://ec2-122-248-210-243.ap-southeast-1.compute.amazonaws.com/mediawiki/index.php/Arduino_Basic

As it's written in C, and uses simple tables of tokens or keywords, it is easily extendable to write new keywords and functions which exercise the Nanode hardware. Additionally there is plenty program space left - about 22K, into which the various library functions for ethernet, SD card, RTC, MAC and SRAM may be added.

Whilst it currently executes code from internal RAM, this could probably be redirected to the external 32K SRAM - into which we can TFTP a simple basic program listing - or access the SD card - which we can use as a local repository or "juke box" of our favourite sketches.

Extending this Tiny Basic and including the common Arduino libraries to form an Nanode operating system (NanOS ?)will be an interesting but achievable task.

The Tiny Basic plus all the nex=cessary hardware libraries fit into just 13K of program space leaving 17K for language extensions and application code. The breakthrough will be to get the SRAM and the SD working as a program application memory and solid state disk.

With the Tiny Basic is a means to list the program, so that lines of code can easily be edited with a terminal program. - or probably a whole file loaded using a file transfer program such as Hyperterminal or whatever.

A simple text editor could also be used to edit and manipulate html text, stored on SD or SRAM - so that web pages could be locally edited and then displayed on a browser.

The Tiny Basic is certainly fast enough to be usable, especially with the baudrate at 57600 - I did 10,000 iteration loops of

10 For A = 0 to 9999
20 Print "My Name is Joe"
30 Next A

In just 30 seconds - anyone who remembers the early 1980s machines like the Spectrum will appreciate this is several times quicker.

It should be straight forward to get the Nanode (Arduino) I/O pins accessible from basic keywords - perhaps something like defining each pin as a keyword
to set Digital 4 High. As there are only 20 I/O pins on a ATmega - it's not going to take much program space to code them up. eg

10 Let D4 = 1 // Set Dig 4 High
20 Let A = AN1 // Get input from Analogue 1

Lots of simple hacking fun for the Christmas holiday - and if you are old enough to remember the Spectrum - this should be like child's play again.

So here's the challenge - download Arduino Tiny Basic from here

http://ec2-122-248-210-243.ap-southeast-1.compute.amazonaws.com/mediawiki/index.php/Arduino_Basic

add in the various Nanode hardware libraries: Ethercard, wire, SD, NanodeMAC, RTC, Ports , RF12

And the best Nanode/WiNode Tiny Basic hack by New Year - wins a pair of fully expanded Winodes - or a pre-assembled Nanode XRF and a WiNode. - worth £60.

Happy Hacking Chrismas

Ken

BTW The new Nanode website www.nanode.biz will be fully operational in the New Year. Check it out to see our greatly extended range of Nanode and WiNode products.

Testing Nanode RF - 4 simple test sketches

2011-12-03T11:25:00.007Z

Nanode RF should be tested in simple steps.

Before you fit the RFM12B module and Magjack, fit the ATmega328 and the 74HCT125 ICs and apply power via the programming cable.

The red led should wink at approximately 1 second intervals.

Ian Chilton has subsequently made these test sketches available on Github - because code does not travel well in these blogs - getting corrupted by the formatting codes.

https://github.com/ichilton/nanode-code/tree/master/test_rfm12b

https://github.com/ichilton/mcp7941x_arduino/blob/master/examples/RTC/RTC.pde

Now cut and paste the following italicised code into a new sketch and check that you can load it. On reset the Red and Green LEDs will flash alternately. This Blinky sketch shows that the ATmega is running and that the upload process is working.

Include below are the LED test, the RF send test, the RF receive test and the Realtime Clock test.

The RFM12 module and 82mm antenna should be soldered in place after you have run the LED test. Make sure you fit the 74HCT125 - because the /INT line from the wireless module passes through this buffer.

Building blocks for the Internet of Things.

2011-12-03T08:25:00.011Z

Open Source Hardware Building Blocks - Lego for the Internet of Things.

Nanode RF - A Web Connected "Arduino Like" Board with Wireless Connectivity for £30

Three years ago exactly, I first got interested in web connected devices. I bought a £100 dev-kit from Microchip, loaded a few examples, but frankly found the technology poorly documented and with a very steep learning curve, I admit I made very little progress.

Undaunted, I took a new job in central London, met a whole host of people with similar interests, through HomeCamp, Pachube, London Hackspace and Minibar and was inspired to develop some of my own ideas into commercial products.

The idea of being able to connect bits of hardware - like sticking Lego blocks together - had a huge appeal. The open source Arduino was trailblazing ahead with a low cost platform and gaining a huge momentum of users and developers. It seemed sensible to produce a compatible platform which is built on the foundations of the Arduino project but adds a whole bunch of new network connectivity functions. Thus was born Nanode - Arduino's well connected cousin.

This week sees the launch of two new product offerings in the Nanode family.

Nanode RF is a much updated Nanode which includes a low power wireless transceiver module - allowing it to communicate with similar networked devices - whilst retaining web connectivity.

Nanode RF also has a real time clock/calendar which can be used to wake up the board at certain times to perform given tasks.

The 32K x 8 static RAM, provides a useful buffer space for storing larger web packets, and also provides a means of upgrading the Nanode RF firmware via the web using a TFTP server.

On the underside of the pcb is a micro SD card socket. This allows a huge amount of external storage - can be used like a disk drive, for holding a repertoire of web pages or as a store for vast quantities of datalogged information.

Nanode RF has conventional Arduino shield connectors, and like Arduino provides a variety of analogue, digital and PWM I/O Pins.

Like the Nanode 5 predecessor - Nanode RF uses predominantly through-hole construction, and may be built form a kit, with a simple pictorial assembly guide and basic soldering skills.

Nanode RF can also be purchased as a fully built and tested board - the Nanode RFX is a maxxed out board with all options fitted.

To complement the Nanode RF - who's role is that of an ethernet connected gateway or basestation, we also introduce a low cost sensor/actuator node: WiNode is a low cost wireless node aimed at networked wireless control, monitoring and actuation applications.

WiNode is also available as a kit, and retains much of the functionality of Nanode RF, but without the ethernet connection.

WiNode - A Wireless Network Sensor Actuator board - based on Arduino technology.

WiNode has four analogue inputs - buffered for voltages of up to 18V, and four high current (2A) digital outputs. These signals are accessed through the easy to connect screw terminals.

The high current outputs may be used for speed control of 2 dc motors, or high current loads such as relays or high brightness LED lighting. The 4 outputs can also be used to drive a single stepper motor.

WiNode also features the familiar Arduino shield connectors, allowing a variety of expansion hardware to be added.

WiNode has the 32K x 8 SRAM, the real time clock/calendar for task scheduling, and when fully populated will accept the micro SD connector for stand alone datalogging applications.

Unlike Arduino, the Nanode and WiNode products do not have the serial programming IC on board. Instead we have produced a customised budget programming adaptor. This allows automatic programming of Nanode products using the Arduino IDE software environment.

Nanode and WiNode products can be purchased online. We currently accept orders by PayPal.

Check out our www.nanode.eu website

Kits:

Nanode 5 - the original - discounted stocks - a few still remaining £19.25 +£0.75 P&P
Nanode Classic £25 - RF module not included - but can be added later (£5.99 Maplins)
Nanode RF £30
Nanode RFX £40 - fully built and tested board

Basic WiNode - from £25

Pre-Asembled and tested:

Nanode RFX - fully assembled and tested £40
Nanode USB programming lead £5.

For more details, contact me, Ken Boak at nanodenanode at gmail dot com

Nanode products are fully Open Source and ethically produced by Arbour Wood Limited - by a collaborative team of friends based in the UK, New York and Shenzhen, China.

Teaching Kids to Code and Build

2011-11-30T18:37:00.032Z

Britain will drift into the Digital Doldrums if we can't excite a whole new generation of kids to get involved with learning the skills of computer programming and making - which we learned in our bedrooms back in the early 80's with our Sinclair Spectrums and BBC Micros.

I built my first computer from a kit, when I should have been revising for my A Levels, and I made a Turtle robot in the Easter holidays before the exams. What seemed normal for a geeky 17 year-old back then, when there wasn't the easy access to low cost technology, meant that you had to go out and make your own. What I learnt in the last few summers of my schooldays set me up for life as an electronics design engineer.Nanode RF - an Arduino Compatible Clone with Ethernet and low power wireless connectivity for £30

Now in my mid-40s, I am one of a generation of technology professionals who learned their craft on simple 8-bit machines - often in the late nights and early mornings - with school the next day. However, lack of sleep to a 17 year old is the last thing on your mind when you are programming a new game, or in my case a floor-roaming robot controlled by a ZX81 and half a kilo of NiCad batteries.

In the last few months, I have been alerted to the fact that some of my contemporaries are now forming a movement to campaign for a return to the teaching of real computer science in schools, as the years of the very much lesser ICT has left students bored and disinterested.

David Braben, Emma Mulqueeny and Dr. Sue Black - to name but a few, are most vociferous in this field. David is spearheading Raspberry-Pi, a £15 computer to excite youngsters in learning real programming. Emma is running a campaign to get Parliament to reintroduce computer science in schools, and Sue has just announced the goto Foundation - described as

Making computer science more meaningful to the public, generating public excitement in the creation of software, and helping to build a tech savvy workforce

More strength to their bows, I say, and in these depressing times we live in, it good to see people take on a challenge like they have and really pick it up and run with it.

So, ask not what your country can do for you - but what you can do for your country? What can I offer, as a hardware engineer?

Well in the last 8 months I have released a couple of low cost 8-bit computing platforms, based on the ever-popular Arduino, but take Arduino into the realms of web and wireless network connectivity.

However, these are going against the Arduino grain - in that you actually assemble the board yourself from a kit of components. Not only do you gain the important learning experience of building a real electronic device, you get to handle and fit real components - and you learn to solder. Within a couple of hours you have built your own, fully functional web connected computer! An then you learn how to program it - taking your first steps in embedded computing.

Over 1600 Nanode kits have been sold, and there have been very few failures. Part of this high success rate is a very easy to follow pictorial build guide - which bypasses the more traditional methods of component identification and placement, and makes the assembly process as easy as following a series of detailed pictures. Follow the pics and you won't go wrong.

Nanode was conceived in a hotel room in China in June of 2010 as the lowest cost Arduino like board which could connect to the internet - a simple pcb with all through hole construction which can be made by anyone with the most rudimentary soldering experience.

Within 8 months, we had the first prototypes ready, and now 6 months into commercial sales, we have sold 1600 of the original Nanode.

December 6th marks the arrival of a completely updated version: Nanode RF. The same basic philosophy of a low cost board with ethernet connectivity - but now with low power wireless as well.

Nanode RF can form the gateway between the ethernet and remote wireless devices offering up exciting possibilities of wireless connected sensors and even robots - controlled remotely from a web browser.

To give Nanode RF a paired device to talk to- so we have created our own compatible wireless device - WiNode.

WiNode - Compatible with Nanode RF for building low power wireless networks - from £15. Two channel motor speed controller opens up wireless controlled robot applications .

WiNode is essentially an Arduino with a low cost wireless transceiver attached. But we have thrown in some analogue sensor channels, a two channel bi-directional driver circuit for controlling dc motors or relays and fitted it out with easy to use screw terminals.

But best of all - the basic WiNode will only cost you £15 - when bought in pairs. I remember that my first ZX81 kit cost me £39.99 in the early 1980s - so WiNode at 2 for £30, is clearly a good buy.

Solderpad.com is a repository for open source hardware designs - here's how they sum up Nanode and WiNode:

Brainchild of monsonite and developed in conjunction with London Hackspace, the Nanode is an open source Arduino-like board that has in-built web connectivity.

It is supplied as a kit of through-hole components, that can be assembled by following a pictorial build guide.

Nanode starts with a kit of parts - within a couple of hours you have built your own web connected computer.

In supplying the Nanode as a kit, it not only keeps costs down but provides a sense of achievement for hobbyists and experimenters that are new to electronics. Use of through-hole components means that assembly, and repair, is within the grasp of those without experience of working with surface-mount technology (SMT).

Projects such as Open Energy Monitor have employed Nanode extended with wireless capabilities, to act as a wired-wireless bridge or hub for remote wireless devices. A common Internet of Things (IoT) use case for Nanode, this has led to the development of the Nanode RF- a variant that can directly accommodate an RFM12B wireless module, with additional features that include a microSD card socket, real-time clock (RTC) and SRAM.

The WiNode is the third member of the Nanode family and is intended to be used as an end node in a wireless network. It employs the same RFM12B module as the Nanode RF, but drops support for Ethernet in favour of enhanced I/O capabilities. In addition to acting as a remote sensor and actuator control node, it can also serve as a shield to a classic Nanode, thereby extending it with support for wireless, a RTC and increased I/O capability.

All three are fully Arduino-compatible and make use of the same IDE and libraries etc. However, to keep costs down a USB controller has been omitted and programming requires use of a USB to serial adaptor cable. Traditionally this would be a FTDI cable - costing nearly as much WiNode. But a chance find on Taobao - the Chinese equivalent of Ebay, and Nanode now has it's own customised programming lead for just £5. Only one cable is required for programming - regardless of how many Nanodes you have.

The Nanode project philosophy:

Creating useful open source hardware building blocks - at the lowest possible price - that people have a need for. Through the Power of Making - electronics becomes accessible again to education and enthusiasts.

Contact nanodenanode at gmail dot com for more details of the Nanode products, pricing and availabilty.

A Weekend of WiNode

2011-11-27T20:58:00.008Z

Another busy weekend of kitting and photographing WiNode in readiness for a public launch in December.

WiNode is essentially an Arduino compatible, low power wireless node, with applications in wireless remote sensing and actuation.

Winode is compatible with Arduino shields, so you could add a Nokia 3310 LCD shield and make a compact wireless graphical display.

In addition to the RF module - a Hope RF RFM12B, WiNode also comes with an industry standard 8 pin footprint real time clock, a dual H-bridge for driving motors and relays at up to 2A and a 32K SRAM for extended data storage. A micro SD card socket turns WiNode into a low cost wireless datalogger.

We have now made up the first 20 WiNode kits - and these are being offered on a first come - first served basis over the next few days. As they are a brand new product - we are offering an incentive of a free real time clock OR motor drive option for the first 20 kits. Later into December we will be kitting a batch of about 150 WiNodes - so there will be volume available well before Christmas.

WiNode can be used as a shield for either Nanode or Arduino. In this configuration we provide a minimum kit of parts which allows RF connectivity to be added to Nanode or Arduino.

From next week we will have a new website with online store - but in advance here are our product offerings.

Contact us at nanodenanode at gmail dot com - and get your Nanode purchases using Paypal.

Nanode 5 - the original and cheapest! Hurry while stocks last £20.00

Nanode Classic - an updated Nanode 5 - upgradeable to Nanode RF £25.00

Nanode RF - the latest Nanode offering with RF transceiver module on board £30.00

Nanode RFX - a fully extended Nanode RF with realtime clock and micro SD card £40.00

WiNode Backpack - a shield for Nanode 5 or Arduino to give it low power RF £12.00

Winode Min - With SRAM and ATmega on board - a standalone node £25.00

Winode Max - a maxxed out Winode with RTC, motor driver and micro SD £30.00

USB Adaptor - a customised Nanode programming adaptor for all the above £5.00

All product prices exclude UK postage - typically £0.75 per pcb. For EU convert these prices at £1 = 1.175 euros and please add 2.50 euros for airmail postage.

Discounts available for volume purchases.

WiNode - the versatile Wireless Node

2011-11-25T12:11:00.015Z

WiNode is the latest addition to the Nanode family, and it can be used in several ways to complement the existing family members.

It can be used as a standalone wireless node for sensor and actuator applications - or it can be fitted to an existing Nanode 5 - to provide low power wireless connectivity and other functionality.

Starting at just £12, you get a pcb, the wireless transceiver, a few resistors and connectors to make a wireless shield for either Nanode or Arduino.

With the RF transceiver and SRAM fitted, the WiNode acts as a very low cost RF shield for Nanode - upgrading it's specification to that of Nanode RF.

This RF upgrade path is being offered to all existing Nanode 5 users - for just £12. For those that want to "roll their own" this entry level kit provides the lowest cost route to RF experimentation, and you can always upgrade to a full WiNode by sourcing the other components elsewhere (ATmega, crystal etc).

Here's a partly built up WiNode mounted on top of a standard Nanode - as a backpack or in Arduino parlance - a shield.

WiNode provides the RF transceiver, the 32Kx 8 SRAM - and if fully populated, the real time clock, micro SD socket and the 2A driver IC for motors and relays.

As a standalone node - WiNode makes the perfect partner for the Nanode RF, or an upgraded Nanode 5.

As with all of the Nanode family of products - you can now obtain them online and direct from the manufacturers.

From next week we will have a new website with online store - but in advance here are our product offerings.

Contact us at nanodenanode at gmail dot com - and get your Nanode purchases using Paypal.

Nanode 5 - the original and cheapest! Hurry while stocks last £20.00
Nanode Classic - an updated Nanode 5 - upgradeable to Nanode RF £25.00
Nanode RF - the latest Nanode member with RF transceiver module on board £30.00
Nanode RFX - a fully extended Nanode RF with realtime clock and micro SD card £40.00
WiNode Backpack - a shield for Nanode 5 or Arduino to give it low power RF £12.00
Winode Min - With SRAM and ATmega on board - a standalone node £25.00
Winode Max - a maxxed out Winode with RTC, power drive and micro SD £30.00
USB Adaptor - a customised Nanode programming adaptor for all the above £5.00

All product prices exclude UK postage - but typically £0.75 per board

Discounts available for volume purchases.

WiNode Works!

2011-11-18T19:56:00.006Z

The first of the WiNode pcbs arrived on Thursday, and an idle half hour at Barcamp Liverpool, saw the board built up sufficiently to perform some basic tests.

Just to recap, WiNode can either operate as a standalone wireless node - or as a smart wireless shield for Nanode/Arduino.

WiNode is essentially a minimal Arduino, grafted to an RFM12B transceiver module - and in this respect it is similar to the JeeNode - and can be used with JeeNode applications. However it offers the following additional functionality:

1. micro SD card socket to provide massive datastorage capacity.
2. L293 (or equivalent) dual H-bridge - for driving motors or relays.
3. Real Time Clock with wake up alarm feature
4. I/O brought out to 3.5mm screw terminals.

Once the reverse protection diode was fitted, the board sprung into life - with the familiar Blinky sketch - but in true Nanode style with the LED on Pin 6.

The new Nanode programming cable worked perfectly - auto resetting the board correctly.

More news later - Barcamp Liverpool has been a marvelous gathering - and it's not even end of Day 1 yet.

UK Utilities - Your letter, was only the start of it....

2011-11-13T07:57:00.011Z

"Dear Mr. Boak

We've checked your GAS account as it's important that we make sure your monthly payments are enough to cover your energy costs. Based on what we expect you to use before your next annual review date, we recommend that your current monthly Direct Debit amount be increased to £101.00. Here's how we've worked it out........."

It is hard to put into words the deep contempt and loathing I have for the UK Utility Companies -

Never before have these faceless corporations owned by untouchables, run by ruthless management and staffed by the wholly incompetent - had so much freedom to run roughshod over their customer base - the gullible.

This current protest about their business methods was initiated earlier this week by a letter from Southern Electric, the opening paragraph above, suggesting that it was my responsibility to ensure that I was paying sufficient funds by monthly direct debit to cover the cost of gas that I will use over the current heating season.

I currently had been paying £80 per month, up from £70 in July, and they suggested that it would be prudent on my part to increase these payments by 26.25% to £101 per month, so that the extra £21 would cover their predicted balance on my bill of £165.20 - next July at the time of my next review.

Now there's not much that gets past me regarding my domestic gas consumption. I have daily records of consumption going back 11 years, which show that the average consumption over the last 5 years, showing that my annual consumption has not exceeded 19,000 kWh and has averaged at 16600kWh.

So why is it that Southern Electric suddenly want to effectively charge me for 29,283 kWh for the next 12 months - when clearly my existing payments have been more than enough to cover past and current gas costs - including the latest increases? Is my property overnight going to see a 75% increase in gas consumption - I think not.

So I thought I'd look into why Southern Electric think I owe them more money. I got online and checked my last gas bill - dated 22nd July 2011.

Based on an estimated meter reading (10991) you owe us £55.66.

Now I was on holiday in late July when the bill arrived, and so did not query this estimate, nor the accompanying letter which said that they were going to raise my monthly payments from £70 to £80 - based on this shortfall.

However, the actual meter reading on July 22nd, just before I left on holiday, was 10263.

Based on this actual reading - and instead of their stated 16524 kWh bill - I had actually only used 8418 kWh - and had they bothered to read my meter, my bill would have been over £200 in credit!!

So lack of one real meter reading in the summer, and they increase my payments from £70 to £80, and now they wish to increase to £101! Based on what - Corporatee greed - one would have to assume?

Perhaps if they just looked at my account they would see that I am now £254.34 in credit - which at my usual winter consumption rate - based on 5 years of experience, will last me all of November, all of December and two weeks into January before I owe them a penny!

Now fortunately, I have more than a passing interest in domestic energy, I know how to convert meter readings to express both electricity and gas quantities in kWh - so I'm generally pretty street wise about what's going on in my home energy consumption.

However, if I was elderly, frail or a pensioner on limited means, the approach that Southern Electric has taken with me would scare the living daylights out of them - monthly payments increasing from £70 to £80 to £101 in just 5 months - and threatening me that I will be £165 in debt to them next July unless I pay up.

This is outlandish behaviour on the part of Southern Electric, and clearly their usage and tariff prediction systems are not fit for purpose. If through a single badly estimated meter reading they get my bill so, so wrong - what chance have they got of getting anything else right?

They are running rough-shod over their customer base, using them as a cash-cow to hedge against rising fuel costs. If Southern Electric are playing this fiddle - then you can assume that it's rife across the whole of the 6 monopolies.

These operation malpractices need national exposure - where the fuck is OFGEM and WTF are they doing about it?

If you agree with the sentiments aired in this blog post - I suggest you tweet it widely - so we can bring this scandalous behaviour of the UK Energy Utility companies to the public arena.

It's New - and It's Blue - The New Nanode RF

2011-11-09T12:38:00.010Z

First example of Nanode RF - built up in Shenzhen, China, by Toby Yu. 13/11/2011. Some boards will be part assembled like this in China, in a small workshop, bringing employment to 4 engineers. These boards will be sold locally and also exported to the western countries.

In readiness for sales commencing in early December - here's the new Nanode RF pcb - hot off the line - manufactured in China.

As you can see - we are entering a blue phase. The board is immediately identifiable with the large footprint in the bottom left hand corner to accept the wireless RFM12B module, and the H logo is now perforated with an 8 pin DIL socket - to accept the new plug in expansion SRAM.

Other than that, changes are few :-

1. Additional green LED indicator
2. Three extra resistors
3. Extra 3V3 regulator
4. mini USB socket for powering

On the underside of the pcb there are a few extra features:-

1. The footprint for the micros SD card - on the bottom right hand edge.
2. A 8 pin soic footprint to take another memory device (SRAM, FRAM, Flash) as an alternative to the micro SD card.
3. A real time clock and calendar chip, with accompanying super-capacitor and 32kHz crystal - underneath the ATmega328.

Nanode RF and WiNode - a perfect pairing

2011-11-07T11:49:00.019Z

Nanode RF - just like Nanode but with a wireless transceiver on board.

1. RFM12B wireless transceiver.

2. Real Time clock with wake - up alarm

3. micro SD card for data-logging

4. Battery backed 32K x 8 SRAM for across ethernet/across air program transfer and storage

5. Accepts standard Arduino shields

Available from December 1st - starting at £30. (RTC, micro SD card socket £5 extra)

WiNode - a wireless node to complement Nanode RF basestation.

1. RFM12B wireless transceiver.

2. Real Time clock with wake - up alarm

3. micro SD card for data-logging

4. Battery backed 32K x 8 SRAM for across air program transfer and storage

5. High current drive outputs for motors or relays - 2A max

6. 16V tolerant analogue inputs

7. Simple to use screw terminal connections

8 Use it stand alone or as a smart-shield for Nanode 5 , or Arduino

9. Fits plastic case with 2 x AA battery compartment from Farnell .

Available from December 1st - Starting at £17.50 (micro SD card socket, RTC and motor driver IC £7.50 extra).

Both these boards are programmed with the new custom programming adaptor and lead - available for £5.

New Nanode Programming Lead

2011-10-31T18:52:00.007Z

We got thoroughly fed up paying £13 plus VAT for a Chinese rip-off of a FTDI lead.

So if you can't beat 'em, feck 'em - and we got our own custom USB to serial programming lead made.

It uses the SiLabs device, but it's pin-out is the same as the 5V FTDI lead. It uses RTS for auto-reset of the Nanode.

We think they are great value at a fiver each.

Nanode RF - what it's all about

2011-10-25T08:20:00.010+01:00

Since 2005 there has been a huge growth in popularity of small microcontroller boards amongst the hobby-tech community.

This growth has largely been fuelled by the open source Arduino - a simple board, originally produced to help teach students about physical computing. There is an excellent article from Wired Magazine documenting the meteoric rise of this product and the team behind it.

The Arduino hardware is little more than a low cost microcontroller, on a credit card sized pcb, with the necessary support circuits around it to allow it to be programmed from a laptop via a USB cable. There is nothing really innovative in this - but it is the software package that is downloaded from the web and supports Arduino that is the real power of this little processor.

The Arduino IDE (integrated design environment) is a set of open source software tools which allow you to easily write new programs to run on the microcontroller - and perfform a variety of tasks - such as sense the analogue world, generate pretty displays from LEDs or control model toys and robots. In fact the uses for Arduino are virtually unbounded - and a huge wealth of new applications are being generated by the Arduino enthusiasts around the world.

The wonderful thing about open source hardware is that it has the momentum of a community behind it - and from the original Arduino, there have been hundreds of spin-off products, all based on the basic Arduino design implementation and software - and as Arduino evolves, so do all the products following it.

Nanode RF is one such product based on the Arduino design. It shares the same choice of microcontroller, and so is software compatible with the Arduino IDE - but it adds a few more features which greatly increases the functional capabilities.

1. It adds an ethernet interface allowing Nanode to connect to the internet and send and receive data to and from the web.

2. It has an on-board wireless transceiver, which allows it to communicate at distances of several tens of metres with other gadgets fitted with a compatible wireless transceiver.

3. It has a serial port which connects to a laptop through a programming cable which allows new programs to be written to the device

4. It has extra memory in the form of RAM and a removable microSD card

5. A real time clock chip ensures that tasks can be scheduled to happen at specific times and dates.

Primarily, Nanode RF can act as a bridge between the internet and remote wireless devices - perhaps best illustrated with an example.

I have a greenhouse in my garden about 50m from the house, and I wish to monitor the temperature, sunlight intensity, soil moisture and CO2 levels to make sure I have the best growing conditions for my tomato plants. If necesary, I wish to open or close the roof vent, or draw some blinds or activate an automatic watering system - to keep the growing conditions optimum. And moreover - I want to do these things, remotely from my office - about 30 miles away, or indeed from anywhere in the world.

Within the greenhouse we have one device fitted with temperature, humidity, soil moisture light and CO2 sensors - plus some actuators or relays to start and stop the pump of the watering system and open and close the vent and roof-blinds. This specialised version of Nanode is called the remote node. It may be one of several similar devices all of which are monitoring things around the home and garden. A weather-station might be another suitable application, or domestic energy monitoring, or the control and monitoring of your solar heating panels and central heating system for the winter months. These tasks are all within the capabilities of Nanode RF.

So each remote node can send and receive data wirelessly to a central basestation. Think of this as being like a portable DECT handset which can communicate with a fixed basestation which is plugged into the telephone line.

However with Nanode RF we are not commmunicating speech - but simple short packets of data pertaining to whatever is being monitored. These are conveyed back to the Nanode RF basestation, which has an internet connection. TheNanode RF can then transfer this data to web based applications that can be accessed anywhere through a web browser - on a laptop, smartphone or whatever.

Data can travel in either direction - so if you want to remotely start your automatic watering system, a click on a browser button initiates a command which is passed to the Nanode RF basestation. It then broadcasts a message to the remote node and that starts up the irrigation system.

Remote nodes may also send data to one another - rather like using the intercom function on a DECT handset. Some nodes may be fitted with liquid crystal graphic displays - so that they can locally display information that is being generated, or even data that has been sourced elsewhere and conveyed via the web and a wireless link. One such display has been produced by Open Energy Monitor - and is used to display domestic energy consumption.

Latest Update on Nanode RF

2011-10-24T09:14:00.028+01:00

Here at Nanode HQ, we have been busy working on some new prototype designs which will come to market in the next couple of months. We're very excided about these new products because they incorporate low power wireless connectivity - and more importantly are compatible with other open hardware devices - produced by some of our friends in the Open Hardware community. Soon we will have lots of low power wireless devices talking together - with a whole bunch of new applications. Here's an update on the first of our new offerings.

Nanode RF is the first of the new products in the Nanode series - and addresses the need for a bi-directional wireless link on the Nanode board. The London Olympics is not the only thing happening in 2012, Nanode RF hits the streets in the New Year.

Nanode RF retains the DIY kit construction technique, popularised in Nanode 5. This makes the project accessible to the likes of schools, colleges, makers and enthusiasts - in fact anyone who can do basic soldering. And being a kit, we continue our emphasis on learning through making, and make a product that can be modified, hacked or re-purposed - according to your needs.

Whilst other hardware suppliers are reducing costs by offering only surface mount products, we are sticking to our philosphy of having something you can build yourself - and repair yourself cheaply - if you happen to fry your microcontroller! That's not to say we refuse to work with surface mount parts - we just like to use them only where necessary - and leave the bulk of these first Nanode designs in traditional through hole components.

Nanode RF uses the RFM12B FSK transceiver module, which is readily available to the hobbyist market from companies such as Sparkfun, Maplin, Farnell etc - and used extensively by the open source design company JeeLabs. You can now incorporate Nanode into wireless sensor networks, and use it to convey your wireless sensor data up to the internet applications - such as Pachube. We are fully compatible with JeeNodes - so with Nanode RF you can incorporate internet connectivity into your existing JeeNode application.

Nanode RF has been developed together with Open Energy Monitor and Wicked Device. OEM have incorporated Nanode RF into their open source emonTx/emonCMS open Energy monitoring system.

When we first started using the RFM12B modules on Nanode 5 for the emonTx basestation, we were fitting them into an expansion connector - using the JeeLabs RFM12B breakout board. This was OK for a few dozen- but it soon became clear that we had to integrate the wireless transceiver module onto the Nanode board. Nanode RF integrates this RF transceiver functionality and adds greater functionality to sensor networks.

Nanode RF is going to be accompanied in a couple of weeks by it's own smart wireless node - Wi-Node. Nanode RF can act as the web connected basestation, commanding and monitoring a network of Wi-Nodes.

At the same time, we took the opportunity to add a few bells and whistles - not all of which need to be fitted for some applications. The idea is that the user can build the basic kit - which only has six more component parts than the standard Nanode, and then add the more complex parts - only if they are needed.

In this way we keep the cost of the basic kit down to below £30 - so you are not paying for functionality you might never use. The cost of the entry level Nanode RF is pitched to be the same as a regular Nanode, plus the cost of the wireless module - if you had to go out and source one yourself.

The extra functions also use up more I/O lines - so if you need the I/O you might have to skip some of the options.

The board has provision for the following options - and we are evaluating these over the next few weeks.

1. Real Time Clock, Alarm and Calendar - uses the Microchip MCP79410 series IC. Has 64 bytes of battery backer RAM and a unique MAC address (79411/12 only). As well as providing real time - this IC can be programmed to wake the Nanode from sleep at regular intervals or at given times. The MCP79410 plus 32kHz crysal can be found at Farnell for 94p plus VAT.

2. Micro SD card socket. Ideal for application where you want to permanently log a lot of data, or you want to serve web pages. You could use the micro SD with a datalogging application such as OpenLog. You can also use the micro SD to hold your Bitlash scripts. The socket is a little fiddly to solder - but a lot easier if you take its metal can off first - see below. Socket is available from Cool Components in the UK for £2.54 +VAT

3. 32K x 8 SRAM. This has now been given it's own 8 pin DIL socket. It's used for bootloading new sketches into the Nanode from the web. Find it at Farnell for £1.23 plus VAT.

4. We are also producing a new low cost programming cable for Nanode. Samples will soon be arriving from China - see photo below. It's likely that we will bundle this cable in with all new Nanode kits at a bargain price, where the customer requests it.

A Minimum Build - The Versatile PCB allows you to add just what you need - In this case just the ATmega328 plus the RFM12B module - for effectively a wireless connected Arduino.

If you just want a wireless sensor board or real-time wireless datalogger, with the familiar Arduino shield connectors - you might consider building up a Nanode RF - but without the ethernet controller and magjack. This combination will be available as an option for around £20.
Here we've added the NuElectronics Nokia 3310 LCD shield to a minimum build Nanode RF - effectively giving a wireless LCD.

Like the current Nanode product - we offer a discount for volume purchases - especially for schools and other educational establishments.

Here are some of the latest photos of Nanode RF.

The RFM12B wireless module and mini USB connector have been fitted.

Here's the microSD socket. This is not easy to solder - unless you take the metal can off carefully first, solder the contacts, then replace the can and solder it in place.
The general view of the underside - still have to add the MCP79410 Real Time Clock and 32.768KHz crystal.
Close-up of the RFM12 module in place - with the antenna soldered .

Here's the general topside view of Nanode RF.

New Arrivals in Project Nanode

2011-10-22T10:14:00.009+01:00

It's just a week since I was laying out two new Nanode pcbs - and the first of them has just been delivered.

Here's the new Nanode RF - almost built but without the RFM12B module soldered yet - because someone forgot to bring them back from work!

It has already run Blink and the Pachube Analogue Sensor Sketch - so I have confidence that the ethernet operation is just as it should be.

Note the new green LED added and the smaller footprint of a mini B USB socket - yet to be added.

The RFM12B module sits in the bottom left corner next to the voltage regulator - yet to be added - after the RFM12B is in place.

A group of four boards showing the topside and underside.

Underside of the pcb showing several new components - notably the micro SD socket and the Real Time clock and crystal underneath the ATmega microcontroller.

Above - the topside of the pcb shows one or two new component footprints - most notably the pads for the surface mount RFM12B module in the bottom left corner. The Hackerspace logo now accepts an 8 pin DIL socket for an optonal expansion memory device.

Here is the new prototype Nanode RF - just like Nanode 5, but with lots of new features:

1. A Hope RF RFM12B transceiver for 2 way communications with other boards.
2. A microSD card for general datalogging storage, storing applications and webpages
3. A realtime clock IC with alarm function which also holds a unique ID - or MAC address
4. 3V3 operation - but retains 5V compatibilty for use with Arduino shields.
5. An 8 pin socket (under the H logo) to allow you to add non volatile RAM for program download
6. An 8 pin SOIC footprint to accept an alternative memory device - instead of micro SD card
7. mini B USB connector for powering at 5V
8. Four - better spaced mounting holes.
9. Fully sealed vias for better soldering - less chance of solder shorts
10.Improved screenprint for better identification of connections.
11. Extra LED - for monitoring RF activity - or whatever.
12 Super capacitor for maintaining SRAM and RTC non-volatility.

Nanode RF has been produced in association with Megni/Open Energy Monitor - and the first sampled will be deployed as basestations for their EmonTx wireless energy monitor and wireless graphic LCD product.

Nanode RF, although debuting this week at the OSHcamp and Homecamp4 will not be on general sale or volume production until the New Year. This will allow time to port firmware across to these boards and develop applications.

It is anticipated that Nanode RF will be available in 2012 for about £30 - depending on the hardware options fitted.

Open Systems - Events in the UK

2011-10-22T07:35:00.005+01:00

It's not often that I manage to blog before an event - but the next week sees some great get-togethers for the Open Systems community in the UK.

The first of the events is the one day open source hardware camp OSHcamp on Thursday 27th. This will be held at the Centre for Creative Collaborations C4CC which is 5 minutes walk from Kings Cross station. There are still tickets left - visit Eventbrite for full details.

The second noteworthy event takes place over next weekend - and is the fourth annual meeting of the Homecamp Community - HomeCamp4. This is also being hosted at C4CC, and will take the form of an unconference, with presentations, demonstrations and workshop/hack sessions. The theme this year is "Hack the House" - with the aim of illustrating how everyday gadgets, systems and appliances can be repurposed or improved with the aim of better efficiency, better usability or new functionality. Last few tickets remaining are also on Eventbrite. This is now a FREE event - thanks to a generous sponsorship from AMEE.

Homecamp aims to bring together proponents of open systems - whether software, hardware or data, in an opportunity for them to share their ideas within the wider community. Saturday 29th will primarily be a presentations day, starting with several key speakers in the morning and then opening the discussion to the floor and offering the opportunity to present or demonstrate in a series of themed break-out sessions. Likely themes will be open systems - including the interaction of hardware and software, and the use of simple, smart open systems around the home to provide better energy efficiency, greater comfort or convenience.

Presentations already confirmed include:

Moixa Technology - a renewables powered - domestic low voltage power supply system

Pachube - Cloud based open data hosting

Megni - an open source energy monitoring system

Project Nanode - Low Cost, Open Hardware for Monitoring and Control

AMEE - an update on platforms and applications for Environmental Intelligence

If you would like to do a short pitch or presentation - please add yourself to the Homecamp4 page on Lanyrd.

Sunday will be more of a hands-on hacking and mash-up day, with the aim of installing an open energy monitoring system at C4CC, and showing how that energy data can be passed via the cloud and used in several interactive applications to improve efficiency and comfort. It will outline the ways in which open hardware and software interact with web hosted open data platforms to create a full end to end open energy monitoring system. If you want to gain hands on experience of home energy hacking - then Sunday will be a must.

If you are working on anything that is easily demonstrated - please bring it along - there will be an opportunity to show and tell.

If you are into Open Hardware, you may wish to have a look at Solderpad - a repository for the design files of open source hardware designs. Solderpad was created by Paul Downey and Andrew Back - who are leading lights in the UK open hardware community and organisers of the Open Source Hardware Users Group - OSHUG - which has regular monthly meet-ups in central London.

Wi-Node, Open Hardware ramblings - and the Nanode with Two Brains

2011-10-19T13:17:00.023+01:00

Our lives are full of wireless gadgets these days - so with the advent of low cost wireless transceiver modules from Hope RF - I decided to add another wireless gizmo to the list - and so Wi-Node was conceived.

Wi-Node is the starting point for building wireless connected projects- in the same way that Nanode is a dev-kit for internet connected devices. Wi-Node has been produced in the same style as Nanode - as a through-hole kit, with minimal use of surface mount devices, such that most people who have done a little basic soldering and electronic assembly can put one together.

Wi-Node follows hot on the heels of Nanode, and it took some while to ponder the various options, and feature set to produce a device that would be useful in a wide variety of different applications.

It's got the familiar Arduino shield connectors, and a socketed ATmega328. Then there's the wireless transceiver - an RFM12B from Hope RF. In addition there are further options, including a micro SD card for datalogging, a real time clock, a SRAM with battery or super-capacitor non-volatile back-up and a motor driver IC - so you can drive dc motors, relays and steppers straight off the one board.

A couple of things quickly became apparent, the existing Nanode really needs a shield or "backpack" which provides additional functionality and features. The idea of the first Nanode "backpack" was announced a few months ago, and then sat on the back burner, whilst I attended various conferences and makerfaires promoting Nanode.

My social calendar - and Nanode's for that matter - was fully booked all summer, and well into October. What with keeping up with the kitting of large batches of Nanodes to meet the sales demand - my spare time was fairly tight.

However, last weekend, I managed to spend the whole weekend with my CAD application - and managed to rattle out a couple of new designs - one of which is Wi-Node, and the other is under wraps for at least another week or so until the pcbs arrive and have been tested.

The revelation came to me when I was looking at a Minuino - a half sized Arduino clone board, by Spikenzie Labs - which was handed out as a promotion in the goodies-bag at the Open Hardware Summit in New York - in mid September.

Minuino was about as minimum as an Arduino can get - the ATmega processor, a crystal, a LED a few caps and a reset switch - very similar in content to the RBBB or the stripboard Arduinos I built a couple of years ago. Add the ubiquitous FTDI header for programming and you have a very low cost 'duino.

Whilst pondering the minimal nature of Minuino, I happened to sit it - as a shield - on top of a Nanode I had in my bits- box. It then occurred to me that if I built up the Minuino, fitted it with a processor and stacked it on top of a Nanode - which had its processor removed from the socket - then the processor in the Minuino would effectively drive the Nanode from the "top deck" as it were.

It then followed on from this idea, that the shield or backpack could be designed around any processor one wished, for example, a larger ATmega, and ARM or a PIC - and this would effectively be a processor upgrade for the humble Nanode. The much maligned (and misaligned) set of shield connectors effectively becomes the system expansion bus - and all you have done is add a new cpu card. I'm probably showing my age now - but it is important to reflect back upon earlier days, and realise that all Arduino is, is a homebrew computer with a different bus.

But why stop at Nanode? - any of the older Arduinos where the processor is socketed, could have a new processor grafted in - and the remainder of the Arduino board, just becomes a power supply and serial communications platform. In some cases this might appear to be a fairly pointless exercise, unless your platform happens to be a Nanode, and you want to use it as a Internet connection to the transplanted processor.

So thus was born the idea of the "Smart Shield" - where the shield has its own processor and hardware goodies on board - which when added to an existing Nanode - with it's processor popped - becomes a serious upgrade for the Nanode and a major boost in functionality.

It was here that I was reminded of the cult college film Steve Martin's "The Man with Two Brains" - effectively what I am proposing is the equivalent of a "Cranial Screwtop" for Nanode - if you don't know what that is - watch the film - or google it.

Moving on. What would you want to add to the Nanode to improve its functionality (and don't all shout a Wiznet W5100)?

I conducted a straw poll of the Nanode Users on IRC, and the top four answers were:

1. Wireless Connectivity - with a Jeenodes compatible RFM12B transceiver
2. SD card for datalogging storage
3. Real Time Clock with battery backup
4. Some high current drivers - for motors relays etc - with easy screw terminal connections

So with a little help from my friends, I have added all of these around a ATmega328 , and crammed it all onto a 55 x 64 mm pcb (plotted above) - which looks remakably like a shield - or - backpack - or whatever.

But wait a minute - if you pop this backpack off of the Nanode, you now have a standalone wireless node, which can be deployed in its own right, anywhere around the home or garden, and communicate back to the Nanode, and so up to the web. And so thus Wi-Node was born - a dual purpose board that can act as either a shield or a standalone device.

So here's some specifics on Wi-Node

It has the following features:
1. ATmega microcontroller 16MHz
2. 868MHz wireless transceiver Hope RF RFM12B (433MHz or 915MHz as options)
3. 32K x 8 nonvolatile SRAM with super capacitor for non volatile backup
4. Real Time Clock with super capacitor non volatile backup - using the cool Microchip MCP79411 - which contains a unique ID - i.e. MAC address
5. Micro SD card for datalogging
6. 4 analogue/digital inputs – tolerant to 15V
7. 4 high current drive outputs – 600mA for motors, relays steppers etc
8. Analogue inputs and digital drives brought out to 3.5mm pitch screw terminals
9. Serial interface/expansion/programming port
10. Battery operation where needed 3 x AA 3.6V 1100mAh
11. 62 x 23 x 103 mm case
12. 5V Solar power option
13. Compatible with Nanode, Arduino and shields

Points 7 and 11 are probably worth a little more explanation.

The Wi-Node has been laid out to take a L293D - which is a popular dual H-bridge power driver IC - as used in the Adafruit motor shield. However, if you look at its pinouts, it is possible to fit four economical N-FETS in its place - if you only want 4 channels of low-side drive for relays etc. If you want full direction and speed control of two motors, or one stepper - then you fit the slightly more expensive L293D.

The point is - you have that option. Wi-Node is going to be released as a low cost pcb, with various build options to suit the individual application requirements. If you are building a wireless heating controller, you probably just fit FETs for driving relays. If you want to build wireless controlled robots - the dual H bridge is likely to be the best option.

Wi-Node is pitched at the intermediate builder who wants to try their own creative ideas around wireless and Nanode - but without having to produce one's own custom pcb.

There will be a basic kit of parts, plus a set of options. Wi-Node was designed to fit into an off the shelf plastic case - and this will be offered separately as an option. Other options include

1. RFM12B - with or without, and choose your own frequency from 433MHZ, 868MHz and 915MHz.
2. Realtime clock IC and super capacitor
3. SRAM IC and super capacitor
4. H Bridge driver
5. Power mosfets
6. micro SD card option
7. Plastic case
8. Pluggable screw terminals
9. Serial programmer adaptor cable

All of these options use standard components from a variety of mainstream suppliers - such as Sparkfun and Newark in the US, and Cool Components and Farnell in the UK. So if you want to buy a basic kit first then expand later at your own pace - then that's easy to do.

Wi-Node will be available towards the end of November, priced around £20 for the basic kit, and options costing between £2 and £5.50 each.

As you effectively need two Wi-Nodes to talk to each other - one as a shield on the basestation, and the other as a remote node - there will be a special bundles offer of a node and shield pair for £30.

Ethical Open Hardware - a new business model

2011-10-09T13:26:00.002+01:00

Having been a freelance hardware design engineer since 2005, I needed a company to channel myendeavours, and so founded Arbour Wood Ltd. in 2007,

I have had 25 years of hardware design, including super fast video processing at BBC Research Department in the early 1990s, to large volume consumer electronics and telecom devices manufactured in southern China.

I traveled extensively between China and the USA, working to insane production schedules, In the spring of 2005, I decided to pause for breath, to reassess my career, and find a more sane way of working, yet building on my skills, network of colleagues and experiences, to find a different way of working, at a time when the world was flat out with globalisation.

Arbour Wood designs simple products that hopefully others will find useful, which will help us to lead lower impact lives and improve our domestic energy efficiency. A combination of simple, low cost microelectronics and smart application software, will allow us to automate, monitor and control systems within the home, leading to better usage and reduced energy consumption.

I was introduced to open hardware early in 2009, by Trystan Lea of Open Energy Monitor, and quickly realised that this was an alternative business model which very much suited the fledgling Arbour Wood. Working in co-operation with other designers, programmers and enthusiasts, Arbour Wood has road-mapped a range of open source products, which will challenge the perceived standards for consumer technology, and redefine the envelope of electronic manufacturing.

Writing in the week that Steve Jobs, co-founder of Apple, passed away - reminded me of an interview Steve made in the late 1990s where he said that he and Woz (Steve Wozniak) only founded Apple in 1976 to make cool stuff. i.e. home computers, that he could sell to his friends. Forty years later, that is very much the philosopy of Arbour Wood.

Nanode was conceived late in 2009, when I realised that there was a need for a very low cost means of connecting devices to the internet. At that time the cheapest solution was an Arduino and an ethernet shield which would cost perhaps £40. Ken took the key components from that combination, stripped the design to a minimum and set a ceiling price of £20 - effectively halving cost of the previous solution.

In today's world, where much of our everyday consumer technology, such as smart phones and tablets are manufactured in vast factories in Southern China, it is easy to lose track of the technology, and we are rapidly approaching a situation where the key to designing these and future products lies in the minds of a few dozen engineers. The open hardware movement hopes to re-address this situation, and produce designs which are not only freely copyable , but designed in a way where they can be manufactured anywhere in the world, and bring new employment opportunities to developing communities. Nanode was designed with this in mind, and uses through-hole components allowing it to be built with simple handtools, by practically anyone who has had a basic course in soldering.

Nanode was developed in association with the London Hackspace, and it is through the hackerspace movement, that Arbour Wood believes that it can distribute its products and designs. In early October, Mitch Altman and Bilal Ghalib traveled to Cairo to help establish a hackerspace there. Several Nanode kits were donated to the Africa Makerfaire in Cairo - thus introducing the visitors to a product that they can build themselves. With Mitch's "Soldering is Easy" course - translated to many languages, on offer at the MakerFaire - the local enthusiasts are now well prepared to build Nanodes and related devices.

The next product underway from the Arbour Wood design studio, is a wireless sensor and actuator board - compatible with Nanode and capable of switching a number of relays and motors and interfacing to a wide range of sensor hardware.

Cash Machine Fraud - Coming to a Branch Near You - Update

2011-09-09T11:05:00.014+01:00

Here's a cautionary tale about the everyday risks of cash machine fraud. Hopefully we can all be a bit more vigilent following my unfortunate experiences.

I was defrauded early in the morning of 8th September at the Barclays Branch in Lingfield, Surrey.

I work in Crowborough as an electronics engineer - but live in Redhill. The cash machine at Barclays in Lingfield is conveniently on my route to work - so I often stop there before 7am to get some cash.

I pulled up at Barclays in Lingfield at almost 6:50 yesterday morning with the intention of getting £30 out and a mini-statement. Lingfield was quiet at that time, unusually no cars parked in the bays outside the bank. There was no sign of anyone around.

I put my card in as normal, keyed in my pin and selected Mini statement. This was printed out, and I checked my balance. I then selected the cash withdrawal option and keyed in £40 - as the tenners had run out.

The machine whirred and several times tried to return my card - beeping to remind me to take the card - which was thoroughly stuck inside the machine. After about 30 seconds, the machine brought up a screen saying that the machine was temporarily out of order - sorry for any inconvenience. I had a close look at the card slot and around the frame of the machine, didn't see anything out of the ordinary, and left in my car in a huff, wondering when Barclays would open and how and when I could get my card back - as I still had no cash.

I decided to go to the Crowborough Branch of Barclays, as I do most of my daytime transactions there and I am known to the staff. They would recognise me as a regular customer and be able to contact the Lingfield Branch on my behalf to arrange the card to be removed from the machine so that I could pick it up later.

I still was not suspecting ATM Fraud.

My Personal Banker at Crowborough Barclays, contacted the staff at Lingfield, only to be told that my card was not inside the machine - and I had visions of it being spat out when the next customer came along after me.

We then checked my balance, and found that within 15 minutes of me losing my card to the machine it had been used 3 times at the nearby HSBC cash machine at Lingfield Garage, and a total of £750 removed from my account - the maximum available in a day on that type of card.

I then called Barclays Fraud Division and went through a process of questions and form filling so that they would put an immediate stop on my card and could commence a fraud investigation.

I must add that by 10am, my account had been re-credited with the full £750 - courtesy of the Fraud Dept. At least that part was quick, efficient and helped to keep stress levels to a minimum.

It transpired that I was the next unwitting victim to a classic ATM fraud using a device known as a Lebanese Loop - but with a high-tech twist. It is a loop of thin plastic material inserted into the card slot of the ATM which prevents your card from being ejected by the machine, or being transferred into the card bin where it would be safely retained for the bank staff to find. The Lebanese Loop effectively leaves your card in limbo land, not safely in the secure card bin, but in the card slot - where only the thieves know how to retrieve it. In effect it is perfect device to hold your card safely within the cardslot until the fraudsters can come along and extract it. To the untrained, the device is virtually undetectable.

So they had my card - all they needed was my pin. Because it was so quiet at 7am in Lingfield - I was not considering taking any special precautions to obscure my pin. This is where this scam make the most of high-tech devices, including camera phones, wireless webcams and other everday consumer imaging devices. I believe that this was captured using a wireless video camera, placed somewhere on the ATM - or in the case of Lingfield - possibly above me - under the eaves of the overhanging roof.

Yesterday afternoon on the way home I returned to the ATM to look for any suspicious signs. I found what appeared to be the residue of double sided sticky tape on the frame of the ATM - probably where they secured the camera - disguised as part of the machine facia.

I spoke to a couple of locals - including a lady who's husband had the same experience at 10am on Wednesday night, at Barclays, Lingfield, - 9 hours before I was targeted. He lost £200 from his account - taken later from the HSBC in East Grinstead. The card was found nearby - dumped when it would no longer cough up cash. These crooks are local to Lingfield and East Grinstead or accessing the county rural towns via good links to the M25.

Subsequently I have advised the staff in the local newsagents to be vigilent about dubious characters hanging around in the very early morning and to warn their customers about the risks of using the ATM without looking for strange devices or protecting your PIN.

I also visited the Lingfield filling station to enquire whether their ATM was covered by the forecourt CCTV - as this is where the thieves went to access my account.

I have passed this information above to the Surrey Police. I'm out of my depth here - and don't wish to get further involved with highly organised, motivated, possibly violent crims. Leave it to the professionals.

I feel that this ATM crime is more widespread than the local banks would wish to have us believe. Targetting ATMs in the early morning and after dark gives the gangs maximum cover -and maximum opportunity to disappear - before the loss is reported.

Banks - how about a 24 hour hotline with the number on the front of the ATM - to advise you immediately what to do and who to call.

Or bring up an "ATM Crime Hotline" screen if the machine suspects it has gone into lockdown as a result of card mechanism tampering. You call thatnumber on the screen and get an immediate stop put on your card.

How about a special screen that allows you to cancel your card there and then if it gets retained - or at least put a temporary block on it so that it's worthless to the thieves?

None of the above is difficult and it would save a lot of grief, manpower and billions lost each year to ATM fraud.

I tweeted my experience to a couple of good friends who have 15,000 followers between them. This is the fastest way to warn people about this particular scam.

I'd like to thank the staff in the Crowborough Branch of Barclays for their support and assistance during this unsettling experience.

Update 1

This morning I called again at the Lingfield Barclays ATM - and the machine was again in "lock down". There is a high probability that the gang struck again earlier today and there are more innocent victims of this high-tech organised crime. It's time that the banks came clean about the extent of this, and issued clear warnings to their customers to be extra vigilent around outdoors cash machines.

Update 2

Those greedy and surprisingly stupid criminals left their camera device attached to the same ATM this morning. Surrey Police were called and the device handed over to the law.

They will now be looking at local garage forecourt CCTV footage from September 8th, to see if they see the criminals, or their vehicle, when they used my card at 07:03 am.

They may be smart and efficient at the Lebanese loop - but they forget that when tey cash in on your account they leave a timestamped trail of where they are. Sooner or later they will be caught on CCTV.

Having had a week in New York with no cash card has sharpened my focus on nailing those scumbags.

Born in the USA

2011-09-08T19:10:00.014+01:00

Here's the first of the new Nanodes to be built entirely in the USA. This is the handywork of Dirk Swart and Victor Aprea - collectively known as Wicked Device

Dirk and Vic contacted me in early July about a collaborative venture - and 8 weeks on, here is the first of 550 to be produced entirely on US soil.

A few subtle changes:

1. Vias are fully solder resisted - no more soldering shorts, and easier to read component placement text.
2. Better legend on 3V3 regulator to indicate insertion direction.
3. A DC jack will actually fit in the footprint location - slots rather than holes.

This is one of the collective benefits of open source hardware. As more people get actively involved, the early mistakes get rectified and the design slowly becomes more refined.

Apart from those mods - it's a good ol' Nanode 5.

In the last few weeks I have been busy, with others, helping to promote the Nanode Project. A very successful presentation at the London Hackspace on September 1st, together with Usman Haque of Pachube, we updated a packed room about the open hardware/open data business model.

We then had the Brighton Mini Maker Faire on Saturday 3rd September - which was very well attended and helped a lot to introduce Nanode to potential customers. Aided by Sam Carlisle and Matt Gaffen, our modest stand sold 35 Nanodes in something under 4 hours.

Meanwhile, in China, the first of the 500 new red pcbs was being tested at the Shenzhen Hackerspace "ChaiHuo" by my friends Toby Yu and Long Li. The first board assembled worked perfectly and is now been used to monitor the temperature of the Hackerspace beer fridge - and post the results up to Pachube.

Additionally this week, a batch of 200 Nanodes were being assembled in a factory in Shenzhen, and 50 have been shipped over to New York, in time for the Open Hardware Summit on 15th Sept and the following Maker Faire on 17th and 18th September. Here is one of the Chinese assembled Nanodes.

In other news this week, SK Pang Electronics has produces a very attractive custom laser-cut acrylic case for the Nanode
Here's a brief assembly Guide.

So September has started to be a busy month for Nanode - with activity going on in 3 centres globally.

If you wish to buy a Nanode - the following distributors now stock them.

Earthshine Electronics

SK Pang Electronics

Wicked Device In USA and Canada and South America

Or you may buy them directly from me using Paypal at ken dot boak at gmail dot com.

If you buy them direct, a significant percentage of proceeds are re-invested directly in furthering the Nanode Project, and go towards our policy of ethical manufacture, fair wages and supporting start-up satellite businesses both in China and the UK.

Nanode - An Open Hardware Success Story

2011-08-28T10:15:00.003+01:00

Big ideas have to start somewhere small - and that was exactly how Nanode started.

In early July 2010, having spent a month in southern China, and temporarily out of a job, I started to rummage some of the ideas I'd had - whilst couped up in a Chinese hotel bedroom for 29 days.

This blog post of 13th July seals the date on which I first mention putting the ethernet controller and the AVR micro on the same board as I had clearly been studying the Tuxgraphic's ethernet webserver. So the idea was launched and what was to become Nanode, was conceived.

Nanode was originally built on a breadboard and then demonstrated at the first of our Snowdon build sessions over Bank Holiday August 2010.

A lot has happened in the intervening year, the breadboarded prototype unimaginatively called Ethernet Arduino, finally appeared towards the end of March, on a neat pcb and renamed Nanode.

In the last 5 months, 552 Nanode boards have been manufactured, and over 500 sold, worldwide.

As I write, there are now 550 new boards being manufactured in the USA by Wicked Device, and a further 500 being produced in Shenzhen, Southern China.

By the middle of September, over a 1000 new Nanodes will be available at the time of the Open Hardware Summit and New York City MakerFaire.

The first 550 Nanodes have been a "kitchen tabletop operation", which clearly has to shift a couple of gears to become capable of supplying Nanodes in quantities of perhaps 1000 per month. Fortunately I have teamed up with some old friends in Hong Kong and Shenzhen who will manage the manufacturing operation.

Additionally, I now have a small, but expanding network of resellers, who will handle the day to day sales and distribution.

So it was timely that I had opportunity to present a summary of the Nanode Project at OggCamp over 13th and 14th of August. Here's the video Nanonde - an Open Hardware Success Story.

Nanode Applications Weekend and Gas Revisited - yet Again

2011-08-10T15:00:00.017+01:00

As the Nanode project approaches the anniversary of its conception, and arguably just 4 months since birth, it was felt that it was time to get a few people together to talk about recent developments and applications.

The central London location of the Centre for Creative Collaborations (C4CC) was chosen as it is well equipped, easy to get to from Kings Cross and a good size - able to host between 30 or 40 delegates.

Saturday was well attended with about 30 present, and we covered a wide range of applications including energy monitoring, remote online bootloading of sketches, and recent developments with Pachube.

Glyn Hudson has done an excellent blog post about the event here - so there is no need to repeat in detail what he has covered.

The get-together brought many like minds into the forum, and it was not too long before we were discussing the use of open source hardware for wireless monitoring of electricity and gas consumption.

In the last few months Trystan Lea and Glyn Hudson of oem (openenergymonitor.org) have made huge progress on their open hardware energy monitoring system. They presented and demonstrated their open source energy monitoring system as an "end to end" solution - and this represents the first real, potentially commercial application for the Nanode as a web connectivity and data distribution device.

Glyn has developed a neat wireless sensor node, the EmonTx, based on Jeenodes and this is used as their electricity monitoring front end. The wireless packets are then sent to a Nanode fitted with a RFM12 transceiver board and thence up to the net.

Trystan has developed the server application including all the database, graphing and visualisation software. This application software is of exceptional quality and in my opinion exceeds that of some or most commercial energy monitoring packages. The point is however, it is open source, freely distributed and available for others to build upon.

So now we have the basis of a really good open source energy monitoring system - and its now time to start thinking about the "elephant in the room" - domestic gas consumption savings.

There are already a couple of commercial gas monitoring devices available - the Ewgegco does electricity, water and gas - hence the name, and the rather naff sounding Saveometer.

Conveniently Saveometer have provided this guide to compatible gas meters - so if you have one of these you are in luck.

The gas meter sensor uses a simple reed switch, activated by a small magnet fitted into the least significant dial. Reed switches create a fair bit of contact bounce, and tend not to work particularly well at very low currents (contacts need "wetting" current). So I have knocked up a very low power Hall sensor which I believe will be cheaper and more reliable in the long run.

Meeting ATEX requirements will be difficult, but I suspect that if I completely encapsulate the sensor in potting compound and meet the current and voltage limitations - then it will be fine from a technical point of view.

The EmonTx wireless sensor developed by openenergymonitor.org is based on the Jeenode circuit, but with additional analogue circuitry allowing the easy plugging in of current transformers, voltage sensors, pulse count sources and one wire temperature (or other) sensors.

As gas consumption and heating monitoring needs a pulse counter channel and temperature sensors, the EmonTx is readily adapted to this role. One proposal with EmonTx is to bring the four JeeNode ports out to external connectors - such that any sensor could be plugged into any port.

The use of a 4 pole 3.5mm jack connector would allow digital, anlogue, power and ground signal to be brought on each port. There are not many common sensors which could not be interfaced with this combination of signals, even if the sensor had its own tiny microcontroller onboard to create a serial data stream. This is the approach taken by Eric Ward with his "Half Bee" sensors which use an 8 pin PIC to provide a common emulated one wire interface for pulse counters, temperature sensors and 2 channel ADCs.

The 3.5mm jack is a compact connector and easily passed through walls, ceilings and flooring with an 9mm drilled hole.

Low cost, 5 metre pre-wired cable assemblies with a 4 pole 3.5mm jack are available here from Farnell.

Nanode Goes Global

2011-07-18T15:48:00.012+01:00

Nanode has started to go from strength to strength. More than 250 Nanodes have been shipped since June 1st - and the trend appears to be increasing.

It's now getting beyond a "kitchen table top" operation.

Following a busy weekend kitting, 34 Nanodes were sent out in the post today, with another 30 to go to a UK customer later in the week.

As well as the familiar European countries, today's clutch included Hong Kong, Shenzhen China, South Australia, Canada, USA, Latvia and Czech Republic.

In another development the first of the new red pcbs from China are almost here.

OggCamp - Nanode's 2nd Outing

2011-07-15T19:11:00.002+01:00

Nanode is going from strength to strength. In fact there's barely a weekend between now and October that there's not something Nanodey going on.

Here's the line up so far:

July 16th/17th Massive Nanode Kitting Session 100+ kits

July 23rd - 30th Week at a secret location to design new Nanode product(s)

August 6th/7th Nanode Applications and Programming weekend workshop

August 13th/14th Nanode at OggCamp

August 20th - Weekend off for a birthday barbeque postponed from 14th

August 27th - 4 day build session in Snowdonia

Sept 3rd - Brighton Mini Maker Faire - Nanode demonstrations and sales

Sept 10th - 18th - New York for Open Hardware Summit and NYC Maker Faire

Sept 24th/25th - nothing planned yet

October 27th 1 Day Open Source Hardware Camp - hosted by OSHUG at C4CC Acton St. London

WIZnet Team on European Tour - Open Hardware

2011-07-09T08:30:00.002+01:00

WIZnet dev team hoping to meet Open Hardware Groups in Europe

Hi,

Yesterday afternoon/evening in London I met up with Jinbuhm Kim, and June-Woo Ryu who are the R&D Director and General Manager working at WIZnet.

They had contacted Glyn Hudson and Trystan Lea at openenergy, and not realised that they were based in North Wales - some 400km from London. So I stepped in, and met them for discussions at the London Hackspace and gave them a tour of its facilities and later met up with Ben Pirt, CTO at Pachube.

They are at the start of a major European tour, which will take them to most European cities/countries, including Brussels, Amsterdam and later on Sweden, Germany, Spain and Italy returning to Seoul on August 12th.

Jimbuhm and June are very supportive of open hardware and would like to meet open hardware groups or individuals on an informal basis for discussion about incorporating their ethernet and wifi products into open hardware.

Wiznet have some exciting new ethernet and wifi solutions suitable for incorporating into open hardware shields and modules. They have dev kits in the Arduino shield format. We discussed the idea of a Smart ethernet module with ATmega328 based on the Arduino Nano format, which would be a great platform for OH and IoT developments.

This weekend they travel to Brussels and then onto Amsterdam, but from that point I am not sure of their exact itinerary.

If you would like to meet them please contact Jimbuhm via email

jbkim at wiznet dot co dot kr

Little Fox

2011-07-01T13:26:00.002+01:00

Nanode 5 Arrives!

2011-06-02T17:57:00.004+01:00

After nearly 3 months of work, the first batch of Nanode 5 boards arrived yesterday.

I spent an hour in the evening building one up and 3 hours documenting the build process. You can see that here:

http://wiki.hackspace.org.uk/wiki/Building_a_Nanode

In the meantime - as I have a lot of kits to make up, here's a couple of photos of Nanode 5.

More news after the Nanode Weekend at the London Hackspace.

Converging Threads

2011-05-29T17:31:00.011+01:00

Friday May 27th.

The Nanode project is at last starting to gel, with a whole lot of separate threads coming together.

On Friday I met for lunch with Mike McRoberts to discuss the possibility of a commercial version of Nanode.

Later in the afternoon, I was joined at the London Hackspace by Andrew Lindsay, who is the leading light in maintaining and developing a library of routines to exercise the ENC28J60 - the particular Ethernet controller that we use on the Nanode.

Andrew demonstrated his latest code example of DHCP. This allows the Nanode to automatically be assigned an IP address which dramatically simplifies the connection to the router.

Andrew put together an example which involves an RGB LED being controlled by a dashboard app running on Pachube. The code was loaded onto the Nanode board and then it was plugged into the network router at the London Hackspace. Within a few seconds the Nanode had performed a DHCP request and had a IP address handed down to it. Andrrew loaded up his simple dashboard application with Pachube and soon he was controlling the colour of the RGB lamp completely remotely - see photo.

Andrews example is described in detail on his Blog here.

Whilst at the LHS we got talking with Martin Dittus, a regular member about how it would be really great to have a simple interpreted language running on the Nanode, so that users could set up their own scripts and modify how the Nanode is used for particular applications. The example I gave was similar to the old interpreted Basics, from the early home computers. Nanode has basically the same resources as those early computers - so why not a Basic like command shell.

Minutes later, Martin had a link to a project called bitlash, an interpreted language written specially for this sort of application and running on the standard Arduino. Bitlash takes about 14K of the Nanode program space, leaving about 16K for the ethernet and wireless functionality. Fortunately, bitlash is a true, serial command interpreter, and bitlash functions and scripts can be stored in EEprom or external memory, or provided across any serial link - which in Nanode's case would be a serial terminal window, or telnet running in a browser.

Bitlash has it's own API which allows the user's C program to interact with bitlash. After a few quick trial examples - I was reasonably convinced that bitlash running on Nanode would be almost ideal for our applications.

And so with two of the key elements of the Nanode project coming together we set of to "MiniBar" - a networking evening in Shoreditch.

Saturday May 28th

A bit of a foggy head after a lot of free Magners at MiniBar last night. Day spent loading Andrew's new EtherShield library into Arduino 0021 and looking at a version of Tiny Basic which runs in under 4K on the AVR.

Sunday May 28th.

The response for Nanode has been phenomenal and the batch of 100 initial version 5 boards have now been sold via the London Hackspace. A second batch of 25 has now been ordered to maintain a small stock.

Been looking more into Bitlash - this is a dream sent from heaven. It's exactly what the Nanode project needs to get commands and scripts over the web, wireless and other interfaces, via serial or telnet session. Here's what the Bitlash Wiki says:

The Bitlash embedded interpreter that runs in about 14k of memory on an Atmel AVR processor. It works nicely with Arduino to make a development and prototyping tool for those situations where you need to bang some bits on the Arduino but writing a sketch in C is premature. It's very convenient for bringing up and debugging new hardware.

The Bitlash command language is very similar to Arduino C and includes a large repertiore of the familiar Arduino C functions so you can hack your hardware from the serial command line or even over the internet via telnet.

You can store commands as functions in EEPROM and autostart them at bootup, making the automation and maintenance of small applications very easy.

A Bitlash enthusiast in the US is now storing and running bitlash scripts and functions from SD/MMC card. See here:

This language is so cool and opens so many doors for small products like Nanode. Time to stop blogging and get blashing!

Curious that an anagram of bitlash is HiBlast and so is Shit Lab - depending on how its going.

RAM and MAC

2011-05-21T21:32:00.007+01:00

Today I have been working on a couple of the newer features of Nanode 5 - namely the SPI SRAM and the MAC chip.

As part of the improvements over Nanode 2, it was decided to make provision for an SPI memory device - surface mounted to the underside of the pcb. This device could be SRAM, EEPROM, data flash or FRAM - the choice would be left up to the user.

Personally, I have chosen SRAM for this first board, as it is cheap and easy to use and I am using similar devices on a project at work.

However the 23K256 SRAM has a maximum voltage of 3.6V and the Nanode is 5V, in order to maintain compatibility with the Arduino. However this compatibility issue is starting to cause problems, and so I decided to reconfigure the board so that everything is powered from 3V3. I had also just received a new batch of MCP1702 250mA 3V3 regulators, so it was a good opportunity to test the board running on one of these regulators. More and more hardware seems to be going down to lower voltages in order to save power, so it is fitting that Nanode should follow suit.

Once the 3V3 rail was up and tested, it was time to solder on the tiny 23K256 SRAM chip - and the even tinier 11AA02 MAC device - which just looks like a SOT23 transistor. Above are the two devices soldered to the board underside. The thin green wire is a temporary modification to power everything at 3V3. The SRAM is fairly central, and the tiny MAC chips is to the south west of the SRAM.

Later on, I modified some example code in order to test the SRAM. It takes about 4 seconds to write to the whole 32K bytes. This isn't very fast - but quick enough for Nanode and the sort of HTML serving tasks likely to be encountered.

I was hoping to work on the MAC chip which uses a unique 1 wire protocol called UNI/O and only needs one dataline to communicate with the microcontroller. Unfortunatelythe Microchip server which serves their data sheets and application notes is on maintenance today and the code examples are not accessible. Tomorrow , I'm of to the London Hackspace with Sam Carlisle and Matt Gaffen, so I should have an opportunity to get the Nanode reading its unique MAC address.

Talking about Nanode - at OxHack. Sunday May 15th.

2011-05-16T21:30:00.014+01:00

The one thing I like about Nanode is that it gets you out of the house. A chance Tweet from Oleg Lavrosky from OxHack, suggesting that I join them in Oxford on Sunday seemed a much better option than messing about in the garden.

Having packed my "hack-pack", grabbed my laptop, I bundled them into the Golf and set off around the M25 and up the M40 to meet up with Oleg and his friends in Cowley.

The irony was, that driving 75 miles to Oxford on a sunny Sunday morning is actually quicker and a lot less stressful than trying to cover the 20 miles from my house to the London Hackspace in Shoreditch by public transport.

I arrived in Cowley after an hour and a quarter, but for a variety of reasons, none especially important at this moment, it was about 4 hours before the hacking began in earnest.

By 2pm we were fed and watered at the fantastic Atomic Burger restaurant in the Cowley Road, I even managed to trade a couple of JeeNodes bare boards in exchange for my lunch, with Oleg's Hacker Pal, Ben.

We then headed around the corner to the offices of "White October" - a web design house with co-working space for startups.

Oleg was joined by half a dozen friends and fellow hackers, so I put the LCD projector together on a suitable stand and offered to run through the Nanode presentation, I had prepare for the Pachube Hackathon - about 5 weeks earlier.

You can see it here on Youtube - in 2 parts.

Part 1

Part 2

So instead of spending the day on Nanode documentation and in the garden, I was out promoting Nanode to one of the "up and coming" hackspaces.

Monday 16th May

Back to work with a usual 7:15am start at my desk. Today I had to get the Nanode boards ordered and make a start ordering the components for the proposed 100 off batch build for the weekend of June 4th and 5th.

Nanode in A Box - a self-fund - self-build model

The whole ethos surrounding Nanode is that of accessibility. From the outset it was designed with ease of building in mind - with the use of through hole components and DIL IC packages, it can be built by anyone with basic soldering experience. I have put together a step-by step guide on an earlier blog post.

Whilst the concept of open source software has been around for several years, it was probably the Arduino Project which effectively extended this thinking to the hardware arena. Software is easily downloadable and easily shared, but with hardware you actually have to make something. This process is simplified by the fact that pcb designs share a common file format know as Gerbers, and these are readily accepted by pcb manufacturers so that boards can be made readily. Many PCB manufacturers are offering low cost services for the amateur constructor.

With Nanode, I have chosen to upload the pcb Gerbers to Thingiverse - a repository for electronic designs.

You can find the files here.

The pcb ordering process could not be simpler. Some board fabrication houses have a complete online service on Ebay allowing you to use PayPal for your purchase and buy several of the pcbs at a discounted rate. One such service is Spirit Circuits which will produce a batch of 20 Nanode pcbs for approximately £40 via Ebay when you email them the zipped gerber files for Nanode 5.

You can then download a shopping list or Bill of Materials (BOM) of the electronic components complete with the part numbers for popular component vendors. If you pool purchasing for 20 sets of components, you can build Nanode for under £20 each.

Two weeks later you get 20 Nanode boards back from the pcb manufacturer, and you can then run a weekend workshop showing your fellow hackspace members how to put it together and connect it up to the net and run some apps. Any spare Nanode you have left you can sell and put towards Hackspace funds or use to fund the next batch of 20 units.

Nanode is currently spreading exponentially. I started by building one on a breadboard last August. In March I produced 10 on pcbs and in June there will be a further batch of 100. If it takes off, and continuies to grow at this rate, the whole of the world's global manufacturing output could be committed to producing nothing but Nanodes by April 2014 ;-)

Fortunately, this is unlikely to happen, but hopefully Nanode will evolve into a platform with similar popularity and offshoot projects in the way Arduino has developed.

Nanode 5 - The Heat is On

2011-05-14T14:51:00.004+01:00

The last week has been a fever-pitch of activity getting the Nanode pcb ready for volume production.

With at least 80 pcbs having been pre-sold to friends, associates and members of the London Hackspace, it looks like we will have to prepare for a somewhat larger batch.

Nanode is entirely open source, so anyone can take the zipped gerber files from Thingiverse and have a board or a small batch of boards made up by a pcb fabrication company. Alternatively if you start with the Nanode schematic, you can modify it to produce your own custom variant and re-purpose that for some alternative application. provided that all Nanode derivatives remain in the public domain, the spirit of Open Hardware is not breached.

Nanode 5 follows on from Nanode 2j, just 5 weeks later. In this time we have added a lot more functionality and hope that we have made a product that will address most peoples needs. Addition of a unique MAC ID, a serial memory device and a simple interface to a low cost wireless transceiver will greatly extend the capability of the original design.

A Week In the Life....

2011-05-14T09:23:00.008+01:00

This week, mostly, I have been soldering......

It's been a busy week, with 2 new arrivals - Nanode 5 and a new DSP microcontroller board I am developing for work.

Sunday 8th May

Make hopefully final changes to Nanode 5 pcb schemeatic and layout. Send off to Roger Light so that he can add the London Hackspace logo onto the correct layer and give it a check over.

More tinkering with my solar heating controller code, and get a chance in the evening to cut the grass, which was way overdue because of my week trip to Wales.

Monday 9th May.

Receive files back from Roger, but notice that there are one or two areas of the screen print layer which could be improved. I edit just this layer and recompile the design to produce a zip file containing all the Gerber files and drill file needed for manufacture.

Tuesday 10th May

I contact Spirit Circuits in Hampshire to get a quote, and apply to have a free "Naked" pcb done as a trial sample to prove the design. The naked pcb is basically a low cost advertising device for Spitit Circuits, where they produce your board for free in 48 hours in the middle of a larger board which contains their latest ad-campaign messages. I send off the gerbers and get an email in the afternoon to say that my naked sample will be with me on the 12th.

Travel up to the Gypsy Moth pub near Greenwich Pier. Have an enjoyable evening of strawberry "Fruili" beers wit my nephew Adam and his college mates who were celebrating his 21st birthday. Get home a little worse for wear, having rushed across town on the DLR through Docklands and tube to Victoria to catch the 23:37 home to Redhill.

Wednesday 11th May.

First of the DSP/microcontroller boards arrives at work. I spend the morning building up the board and have it flashing LEDs by the afternoon. I had to order some thin solder (26 gauge) and some surface mount flux in order to make a reasonable job of the SMT assembly. Finished the day wishing that a) I still had the eyesight I had when I was 30 and b) wish I was a more competent C programmer.

Thursday 12th May

Complete the SMT build of the DSP board at work and continue testing. Arrive home to find that Naked Nanode has arrived! Too much eyestrain to start building it tonight - will do it tomorrow after work.

Informed the London Hackspace of a proposed "Nanode Weekend" for 4th and 5th of June. This will be the official launch of the Nanode, which will include a distribution of the kits, a DIY build session (with experts on hand) and a full day of instruction about the Nanode programming and Apps. If we get 10 people who can solder, I intend to set up a short production line, so that we can build lots of boards to a high standard in a relatively short time.

Friday 13th May.

Not a good start. For some reason the USB JTAG emulator I use to load code into the DSP packs up - after I unplugged it from the board. I spend 2 hours rebooting machine, re-loading drivers etc, only to find on the manufacturers website that this is a known issue, and it happens when you plug another FTDI serial device into the PC. If the JTAG, which uses the FTDI chip is removed, priority goes to the 2nd device and that stops the JTAG from being recognised. I spent half a morning dealing with this totally crap issue, which is so typical of the computer industry releasing badly thought through products.

As a consequence my 1pm Friday finish was delayed to 16:45pm, but I did get a lot more debugging done without the interruptions of phone and co-workers. I also sent off for an Ebay batch of Nanode boards, where you get a square foot of boards for £37. This works out at about £2 per pcb. These will be ready about May 30th.

Friday evening 6pm - time to start building up the Nanode 5 board and test it. Because of the lack of solder resist layer you need to be very careful soldering - as it is way too easy to get shorts between adjacent tracks and pads. By 7:30pm the board was running code on the ATmega and printing out readings to the serial window. A brief interruption to go for a pub meal with Elaine, and then back to debugging Nanode 5.

Unfortunately, the only 3V3 voltage regulator I could find was a very old Holtek 7533. These are only good for 100mA - which is really not enough to run the ENC28J60 ethernet controller chip. As a result the 3V3 rail sags to about 2.9V which is not enough for ethernet comms. I adopt a trick of using 3V3 "jump leads" from another Nanode board, and the ethernet springs to life - first with a successful response to a ping and then serving a full webpage.

Saturday 14th May

Intend to document some of the week's proceedings and work with the guys developing the Nanode application software so that its ready for the Nanode launch in three weekend's time.

Sunday 15th May

I expect I will be resting or pottering in the garden - as I am sure the grass will need cutting again.

Nanode 5 - Progress Update

2011-05-08T10:58:00.009+01:00

A bit of an early start this morning as my cat woke me at about 4:30am. By 4:50 I was up and starting to finalise the Nanode 5 pcb layout.

Nanode 5 will be the first commercially released version and it has undegone significant improvements since Nanode 2 - the first prototype board.

The Nanode development team has gained a lot of experience in the last month since the prototype was first shown at the Pachube Hackathon. We have taken the opportunity of these last 4 weeks to update the design and make sure that it meets all the expectations, and we have crammed in some new features.

Following our recent build session in Snowdonia it was decided that from the outset, Nanode 5 should make more use of wireless and be easily configured as an ethernet to wireless bridge. We have decided to take full advantage of a low cost wireless transceiver module by Jee Labs.

So I have updated the circuit and connectors slightly so that the Jee Labs RFM12B transceiver breakout board will plug directly into one of the Nanode expansion connectors. This board is available for about £11 as a full kit or £4 for a bare pcb from Jee Labs shop. With this board, the Nanode 5 functions just like the JeeNode with ethernet, so we can make use of all of the applications firmware already developed by Jean-Claude Wippler at Jee Labs.

One of the limitations of the ATmega328 processor is the 2k of RAM. This can be partially overcome by fitting an external memory device. The SPI bus lends itself to communicating with such devices with a low pin-count interface. On the bottom of the Version 5 Nanode board we have included a footprint which will accept an 8 pin SPI memory device. This can be SRAM, FRAM or EEPROM/Flash and accept devices up to 256Kx8. Extending the memory of the Nanode will be useful for many applications. The device can be purchased for about £2.

Nanode also has a footprint to accept a unique ID MAC chip produced by Microchip. This contains a 48bit unique identity plus 2k bits of EEPROM memory which can be used for storing the Nanode configuration etc. This device is 38p from Farnell.

As a result of the aim to have full compatibility between JeeNode and Nanode, we have had to move some of the SPI chip select lines around. Here is a quick list of the main I/O pin functions:

Digital 0 Serial Receive
Digital 1 Serial Transmit
Digital 2 Interrupt for RFM12 wireless and ENC28J60 ethernet controller
Digital 3 Interupt for Vusb - virtual USB
Digital 4 Virtual USB data pin. Servo control output, Display output with software serial
Digital 5 Used by Nokia 3310 LCD shield
Digital 6 /TXEN - enables the transmit line to local serial bus. LED indicator
Digital 7 Data input/output for MAC chip

Digital 8 Chip Select output for ENC28J60 ethernet controller chip
Digital 9 Chip Select output for SPI memory chip
Digital 10 Chip Select output for RFM12B wireless tranceiver module
Digital 11 SPI MOSI
Digital 12 SPI MISO
Digital 13 SPI SCLK

In addition to the above signals, the expansion connector also has +5V, 0V and +3V3 to allow the RFM12 module to plug straight in. Digital 8 and digital 9 have been removed from this connector as they are used internally by the ENC28J60 and the SPI SRAM as chip selects. They do however still appear on the Arduino shield connectors as standard.

As you can see a fully populated Nanode with ethernet, wireless, SPI memory and a MAC chip is going to be pretty much maxxed out in terms of available I/O. However a wireless only node, or serial node will have a lot more I/O available for the users sensor application - essentially 6 or 7 digital lines and 6 analogue inputs.

Of course a Nanode pcb can be partly populated with just the ATmega328, crystal and reset circuit and used as a very low cost Arduino clone. This could be a very cost effective way to get a load of work-alikes.

One of the projects whilst in Snowdonia was to develop a low cost single axis solar PV tracker. This uses a single radio control servo to angle a small PV panel directly towards the sun and record the power produced. Nanode 5 has a 3 pin connector which will directly take an R/C servo which is controlled by Digital 4.

Here's a short video showing the tracker working. Following a reset, the servo turns the panel to face east and then it searches in 10 degree steps for the solar power maxima. After completing the 180 degree search it returns to the maxima position - about 39 seconds into this clip. Once a minute (at about 1min 05), it then tracks east by 5 degrees and performs a 1 degree incremental sweep for 10 degrees to see if it can find a better maxima.

We have developed a fair bit of code for Nanode and this is now up on GitHub

The updated pcb artwork is very nearly completed and after checking this weekend will be released to Spirit Electronics so that a batch of 100 bare boards can be manufactured. This will take approximately 2 weeks - so we expect to have Nanode pcbs available for assembly about 23/5/2011.

Arduinos, Agents and Mailboxes

2011-05-07T09:35:00.017+01:00

Today I look at some hardware ideas - on a quest for a Universal Programming Platform. It's probably the programming equivalent of the Holy Grail, but there has to be an easy way to switch between broadly compatible platforms depending on application.

Physical Computing Platforms are all the rage now - The "open source poster child" Arduino has a popular following, and is ideal for small monitoring and control tasks. The Arduino Mega takes over for more I/O intensive jobs, and if you want something with raw power the mbed offers ARM M3 Cortex power at a sub-£50 price.

Arduinos - Everywhere

Right now, there seems to be Arduinos everywhere, at home, at work in the office and in my shed. I guess I'm partly to blame, having introduced them into my life in winter 2009 - and they seem to be breeding.

The Arduino is an almost perfect tool for small monitoring and control tasks. It's small, cheap and readily available. If you need one in a hurry you can build something on stripboard in under and hour costing less that £5. This is the approach I take for most of my rush-jobs. Recently I have invested in some professionally made pcbs for the Nanode - an Arduino compatible board with the advantage of internet connectivity.

Since last October there has been an Arduino Mega controlling and monitoring my central heating, and logging my gas usage.

Two weeks ago I started work on a solar thermal heating controller, based on a DIY stripboard version of Arduino. I hope to be revisiting that controller this weekend and updating the control algorithm - as soon as we have some sunshine I can test it!

Last weekend at the Snowdonbuild 2 session, I put together a simple solar PV tracking system and used my ethernet connected Nanode to send solar PV data up to the internet, where it was displayed on the openenergymonitor EmonCMS server.

This week at work, I have been debugging a powerful white LED driver board which will be used as a "sun simulator" for a PV educational instrument we are developing. It should come as no surprise that I have an Arduino controlling the brightness of the LED arrays, and another Arduino (Nano) measuring the output of the PV module under test.

As I said, Arduino is almost the perfect prototyping tool. It's the first thing I reach for these days when I have an idea I wish to try out. Years ago, I used to use Microchip PICs, but not knowing C at that time meant that progress was slow and painful. In the last couple of years I have learned sufficient C to be able to make good headway on the Arduino, and this new skill has allowed me to program other processors. C is virtually a universal programming language, and provided that you have the compiler tools, you can switch from one micro to another with surprising ease.

More Grunt?

Given a highly portable, almost universal programming language - how about a similar "universal" hardware device which means that applications can easily be ported from one system to another? The Arduino comes close to this for small applications, and if you need more memory and I/O pins you can always reach for an Arduino Mega 2560.

But what if you need a lot more processing power for applications such as audio or video processing or realtime control of advanced dc motors. What about an "Arduino" with an ARM processor or even a DSP at its core. The ARM is widely used in mobiles and PDAs. An estimate is that 98% of all mobiles produced use at least one ARM device.

The ARM M3 Cortex as used on the Mbed rapid prototyping board is also gaining momentum. How do you main compatibility with such a wide range of new processors without throwing away all your investment in code?

Connecting Stuff

One of the things I've been working on recently is a universal instrumentation and control board. It takes a USB feed in at one end, and expands this out to a whole range of ports which appear on a easy to use 2 x 30 pin DIL header. I'm developing a couple of educational instruments at the moment which need a variety of control signals, and I decided to base each instrument around the same control board.

The hardware has to be rugged enough to survive the abuse likely when used by undergraduates, so all the I/O ports are buffered and the analogue input feature current limiting resistors and zener overvoltage protection diodes.

The board uses a Cypress 8051 derivative to provide the USB interface (this is for historical legacy and compatibility reasons) and then has a second microcontroller to act as the main "grunt".

The processor I've chosen is a blisteringly quick 32-bit floating point DSP , the 28335, from Texas Instruments. This comes on a little plug in daughter board or "control card" which fits into a DIMM (memory) socket. Texas have released a number of their DSP devices on this same plug in format - so you can pick and choose a processor to suit your application - from 16 bit fixed point to 32-bit 150MHz floating point.

I've chosen to hedge my bets and make either the Arduino, or Arduino Mega as one of the processor options. By putting down a series of headers on the board in the right pattern, an Arduino, Mega or even an ethernet connected Nanode can be plugged in.

The interesting thing that led me to this course of action was that the Texas DSP presented some general purpose I/O lines which were almost identical in function to those on the Arduino Mega - i.e. 16 ADCs, 12 or 14 PWMs and about 30 other digital I/O lines. It occurred to me that with the portability of programming in C, it shouldn't matter whether you are dealing with a Mega2560 or a 28335 DSP - it's just a block of programmable hardware. The common hardware model continues as the DSP offers 3 serial UARTs, an I2C and an SPI port - all of which are found on the Mega 2560.

Mailbox Communications

To get all this lot to work I have devised a dual port memory scheme so that a PC via USB can access a common block of memory into which a register model of the instrumentation controller has been configured. The memory is actually a 32K x 8 serial SPI SRAM. Whilst not the fastest device, it has the advantage of a low pin-count needed to access it, and by using a TTL buffer it was fairly straight forward to implement a dual port access system. The 8051 USB processor did not come with an SPI port, but the SPI protocol is simple enough to program by bit-banging a couple of I/O pins - so can be implemented on virtually any micro.

The proposed way it will work, is that the main processor (the DSP) will run a main instrumentation loop, which involves taking readings from its ADC channels and processing them, it then stores the processed results at certain reserved locations within the shared SPI SRAM. After posting these results, it relinquishes control of the access to the SRAM, by raising an I/O pin. The 8051 micro can then access the RAM, grab the results and send them up to the PC for processing and display.

In the same manner, data from the PC can be loaded into the SRAM, and each cycle of the main loop, the DSP checks the SRAM for this data, and if necessary updates the state of its I/O lines or changes the PWM values or whatever. Its a simple generic method which allows two unrelated systems to communicate with each other by way of a "mailbox" implemented in shared SPI SRAM. The PC doesn't really have to know anything about the DSP - just where to collect the data and where to post data to drive its I/O. The whole I/O and peripherals of the DSP are effectively memory mapped to specific locations within the SRAM.

Now when we decide we don't want to use the DSP, but have come across a new processor such as an ARM or whatever, we just plug that in, and have a small routine running on it which implements the register model and the mailbox system. The PC would be none the wiser, as far as it's concerned it's just talking to the same processor.

This is analagous of how spies and agents communicate with each other using a mailbox or drop box. The agents don't know each other, for security reasons this is essential - all they know is to leave messages at a given location and check back at regular intervals for a reply.

The 32K x 8 SRAM can be allocated in whatever way suits the application. The access registers to the I/O will probably all fit on a single 256 byte page, leaving loads of room for expansion. Large arrays of sampled data from the instrument and monitoring processes could be written to certain pages of SRAM and picked up a page at a time by the PC.

A similar dual port memory scheme has been implemented using EEPROM. This allows the PC to download the application program into the EEPROM and a routine within the DSP allows it to boot from this EEPROM and so pick up the new firmware. The hardware to drive the SPI SRAM and EEPROM and implement the access control is just a couple of 74HC244 octal buffers.

Reinventing the Wheel

2011-05-04T20:20:00.031+01:00

It's a case of what goes around, comes around.

This post takes a retrospective look at some minimalist computing solutions which have been historically significant over the last 45 years, - effectively - my lifetime.

It's a quick look back at the last four decades of computer development, highlighting a few significant events, and how they have become intricately woven together to influence the modern world.

Can we take a lesson from earlier times to make interaction with modern systems, more intuitive and easier for newcomers to learn "real" computer programming.

Mid 1960's

Around about the same time as I was conceived (late '64), MIT labs and Raytheon Inc, were contracted to come up with a digital control and guidance computer that would be used throughout the Apollo moon-shot program. Thus was born the Apollo Guidance Computer or AGC

The AGC was assembled from approximately 5600 individual logic gates - a brief specification was given as follows:

Word Length: 15 bits plus parity.
Fixed Memory Registers: 36864 Words.
Erasable Memory Registers: 2048 Words.
Number of Normal Instructions: 34.
Number of Involuntary instructions (Increment, interrupt, etc.): 10.
Number of Interface Circuits: 227.
Memory Cycle time: 11.7 microseconds.
Addition Time: 23.4 microseconds.
Multiplication Time: 46.8 microseconds.
Number of Logic Gates: 5,600 (2,800 packages)
Volume: 0.97 cubic feet.
Weight: 70 pounds.
Power Consumption: 55 watts.
The AGC was used in conjunction with a display/keyboard unit or DSKY which weighed a further 17.5 lbs.

Despite its basic specification, the AGC was used on Apollo missions right up until 1972, including the first successful moon-landing of 22nd July 1969. If you want to get an impression of the AGC it is well documented on Wikipedia, including this rather superb replica.

The 1970's

Approximately 6 years after the first moon landing mission, a young programmer, Paul Allen was on his own important mission. On a flight to Albuquerque, New Mexico, he was to meet and deliver a roll of paper tape to MITS, makers of the new Altair 8800 microcomputer system.

The tape contained a BASIC interpreter program, written by Allen and his business partner, William Gates, and it was the first real job for their fledgling company Micro Soft.

Allen even had to write a paper tape reader routine in 8080 machine code whilst on the plane, as in the rush to get the job done, he had forgotten to include the necessary paper tape loader routines to get the code into the new Altair machine. The original implementation fitted into just 4K of program memory, but was later expanded to 8K so as to include extra functions including trigonometric maths. This was the first implementation of a usable high level language on a hobbyist microcomputer, and the outcome of that meeting was to change the computing world for ever. Paul Allen and Bill Gates went on to deliver variants of BASIC for most of the early 8 bit microprocessor families, and their company grew into global giant Microsoft.

Paul Allen had a vast experience of mainframes and effectively devised an 8080 emulator to run on a PDP- 10. It was with this software tool, that the young Bill Gates wrote much of the original 8080 BASIC interpreter, and delivered it working to the client at MITS without ever having seen an 8080 system! Gates was certainly a smart kid. The same mainframe emulator was used to produce BASIC interpreters for most of the popular 8 bit micros.

A few years later, as far as I recall, in the summer of '79, microcomputers eventually arrived in the UK. My school had an early Research Machines 380Z (A CP/M Z80 machine) with a cassette interface and very little else. Software was lacking, but there was a BASIC interpreter and a few games written in BASIC. One was the numerical game "lunar lander" which had been around on programmable calculators for a couple of years - where you had to try and landd the lunar module, or crash and burn on the moon's surface through lack of fuel. Later a copy of Space Invaders written in Z80 machine code turned up from somewhere. It was just like the arcade game and very popular. A particularly geeky mate of mine taught himself Z80 machine code, aged 14 - so that he could manipulate and hack the variables within the space invaders programme to his advantage. However, I hadn't a clue what machine code was, and so I wasn't to write my first bytes of raw Z80 hex for another 2 or 3 years.

The 1980's

In 1981 a far-sighted teacher brought a ZX81 into the classroom, and I learnt to program (badly) in BASIC. As a sixth-former I ran an after school computer club for a couple of years in my spare time, and generally found many similar excuses to flunk my A levels.

The photo on the right shows the corroded remains of my ZX81 built from a kit in the spring of '83. I fitted a 2K RAM and a much bigger heatsink. It was put in a custom case and used to control a Turtle robot. It ran for about 20 minutes at a time from C-size rechargeable NiCads. Sadly it has been in a damp trunk for the best part of 25 years - so perhaps not looking in the best of health. I dug this out tonight, dusted it down, and perhaps one day I will clean it up and get it running - though I notice the ROM chip is long since gone.

The ZX81 was a fairly minimalist machine, consisting of the Z80A clocked at 3.58MHz, a custom ULA (uncommitted logic array) from Ferranti, the 8K BASIC ROM and either a pair of 2102 512 byte RAM chips or a 1Kx8. I fitted a newly affordable 6116 2Kx8 and gave myself a machine with 5 times the previous codespace (768 bytes of the original 1024 were used by the display leaving a barely adequate 256). At university, a friend and I made a FM wireless link between two ZX81 machines from a FM "bug", and were able to transfer programs from one machine to the other over the FM link using the quirky audio cassette interface.

During Live Aid in July '85, I remember I spent the day in front of small small black and white portable TV set, watching the bands whilst hand wiring a prototype Z80 control card - a 4MHz Z80 maxxed out with ROM, RAM, 8255 Ports, PIO, SIO, CTC and keyboard interface.

With 6 chips on the board it was about 4" x 5" and a mass of bus wiring - my own personal homage to early computer construction! A picture of the Z80 control card is below. It was built to run an electronic synthesizer project - so has 5, 8 bit ports, a keyboard scanner and a Z80-SIO and Z80-CTC to provide MIDI serial and counter-timer functions. It is striking to think that this is a very much slower equivalent of the likes of the Arduino MEGA.

Hardware certainly was hard 25 years ago - I remember it took me most of a week to design, build, wire and debug that board. I hand coded a monitor ROM from a version I had cribbed from another Z80 machine which allowed hexadecimal program entry and text output to a terminal.

The hand-wired "verowire" prototype is shown below, showing the pink wiring held in place by nylon combs. Just wiring 3 x 40 pin and 3 x 28 pin chip sockets took a lot of connecting up. I guess it might still run code if I apply power! The white socket on the bottom was to allow me to plug it into an early development system called a Multitech "Micro Professor" MPF-1B a Taiwanese built Z80 micro trainer that I bought in Edinburgh in the spring of 1984. Multitech Industrial Corporation later became Acer - another historical link. The MPF-1B is actually still available from Flite Electronics - 27 years after I bought mine!

The 1990's

What began in the mid 70's with the introduction of the 8080 - the first real microprocessor IC, heralded a succession of cheaper and more powerful micros from all the main IC manufacturers. Fuelled by the PC industry, we saw hardware, clock speeds and memory increasing yearly with every new generation of Intel x86 processor. It's hard to believe that we take clock speeds in the low gigahertz, RAM memory in gigabytes and hard drive capacities in terabytes for granted these days.

At the same time that PCs were developing there were rapid developments in embedded microcontrollers. In the 90's I worked with 68000, 8051, Z8, PIC and TMS320 DSPs. We had entered the era of system on a chip, where microprocessor core, program memory, RAM and I/O peripherals were reduced down to a single IC. The rather clunky Z80 board I built in 1985 could be replaced with a single 40 pin IC runing at about 10 times the clock speed of the earlier design. Microcontrollers were given a massive boost with reprogrammable Flash memory for program storage, and on-chip analogue to digital converters and simple PWM allowed a certain amount of analogue processing to be done. I recall in the late 1990's developing a single chip telephone modem device based on a low cost PIC, where all DTMF and modem tones were synthesized and decoded in firmware.

Into the 2000's

Some 30 years after Paul Allen's world changing business deal, some clever guys, Massimo Banzi and David Cuartielles at the Interaction Design Institute, Ivrea, Italy, put together a simple microcontroller board and introduced the world to the Arduino and the world of open source hardware and software. The Arduino core development team now consists of Massimo Banzi, David Cuartielles, Tom Igoe, Gianluca Martino, David Mellis and Nicholas Zambetti.

Ironically, the ATmega AVR microcontroller which runs the Arduino is almost identical in specification to the AGC, the Altair and the ZX81. A small board costing around $15 has the same potential processing power as the AGC which cost $15 million back in 1965. The ATmega328 which runs the Arduino is a mere $2 to $3. How far we have come in 40 years!

2010 and Beyond

So this retrospective post is by way of considering whether we can re-purpose some of the methods and techniques devised by early computer engineers to make their machines useful with a minimum of resources?

The reason that these particular machines and events have special meaning, is not only that they have been milestones in the personal computing industry, but they also mark major milestones in my own life. I recall being woken up at 4am on July 22nd 1969 to watch grainy pictures on a black and white TV set, of Neil Armstrong's decent from the LEM onto the lunar surface.

The other connection between them, is that the specification of the computers involved was roughly the same in terms of memory and speed of operation - there really is not a lot of difference in processing power between the AGC, the Altair 8800 and the ZX81 - just 15 years and about 70lbs in weight.

So this got me thinking about these early machines, how they were programmed and what could be done with them. The Altair and the ZX81 shared a BASIC interpreter, numerous BASIC dialects arose out of public domain code originally developed by Dartmouth College in 1965, and written for a GE 225 mainframe.

If Paul Allen managed to shoehorn a workable BASIC interpreter into 4K of code back in '75, how about doing the same thing for the 32K program space on the ATmega328. Back in 2008, an AVR enthusiast Klaxon44, wrote a BASIC interpreter in C and successfully ported it to the ATmega128. Capable of some 50,000 empty loops per second, it wasn't lightning fast, but good enough to run interpreted commands from the serial link. Had the BASIC interpreter been coded directly into AVR machine code, and not in a round-about way involving compiled C, it would have been many times faster.

To anyone who grew up with the early home micros, the ability to edit programs on the fly, and type commands directly at the keyboard which would be executed immediately was a neat way of program interaction. Klaxon44's version allows direct manipulation of the ports, so you can write to the I/O directly for testing hardware such as LEDs and sensors directly.

We've come a long way, even since my early coding days on the ZX81. We now have self programming flash memory, and SPI devices which only need four signal connections to connect them. SD cards and wireless modules allow easy storage of large quantities of data and allow simple communication between processors. Imagine a simple BASIC interpreter running on an Arduino which could be used to introduce school kids to the basics of programming and controlling electronics with simple keywords, - without having to first learn embedded C!

BASIC is no substitute for C, but it is certainly easier to lhttp://www.blogger.com/img/blank.gifearn, debug and is more forgiving than C with it's finicky syntax and over-zealous use of punctuation marks and various types of http://www.blogger.com/img/blank.gifbrackets.

I don't want to re-invent the wheel, but is there not a case for a easier way to interact with and program embedded microcontrollers?

AS I write this, it seems that there is a new kid on the block - Raspberry Pi a tiny linux ARM based computer expected to sell for under $25.

A video of the Raspberry Pi and founder David Braben appears on the BBC on May 5th 2011.

Could this be the future of minimalist, easy to program, real computers?

JeeNodes Arrive!

2011-05-03T13:42:00.005+01:00

The JeeNode kits I ordered just before Easter have turned up.

I ordered 2 JeeNode kits and 4 bare pcbs, which I will make up as and when I need them.

During the Snowdonbuild, we used JeeNode extensively to act as a wireless "shield" to complement Nanode.

Jean Claude Wippler at JeeLabs has written some neat code to allow a JeeNode to run the Microchip ENC28J60 ethernet controller. This is the same one we use on Nanode, which makes it fairly straightforward to get code to run on both systems.

JeeNodes use the RFM12 wireless modules from Hope RF. These are available very cheaply as "Alpha" wireless modules from suppliers such as Maplin in the UK.

In the next week I hope to duplicate some of the developments from the Snowdonbuild and get my JeeNodes transferring data from my solar water heating system back to an internet connected Nanode.

The JeeNode kit is very easy to build. It took me under an hour to build the first pair, pause for a ham baguette and then test out the RFM12 Demo sketch which comes preprogrammed into the ATmega328. I have not yet fitted the port connectors - because I have yet to decide whether I want these to plug into a breadboard or some sort of a connector on the Nanode.
The success of running the 16MHz JeeNode at 3.3V makes me wonder whether I should run the Nanode at 3V3 to reduce power consumption significantly and to simplify some aspects of the design.

#Snowdonbuild - Final Day

2011-05-02T08:43:00.010+01:00

Day 6 of #snowdonbuild - a unique collaborative project in open hardware and open software, held in rural Snowdonia.

The remote farmhouse in Snowdonia, which has been Snowdonbuild HQ for the last 6 days.

Most of the team, Bethan, Sam, Glyn, (PV Panels) Matt, Trystan, Suneil - and Ken behind the camera.

So we've nearly come to the end of the build session - and judging by the lack of bodies at 8:30am - it seems that last night might have been a late one!

Today is the day that we pull all the project threads together and put together a full system and documentation.

The "Bothy" extension to the farmhouse, which forms the accommodation and lab areas.

The team prepare to line-up for a final mug-shot by the solar PV panels.

Over the last few days we have built a solar PV monitoring system and used the Nanode to control a simple solar tracker.

Making full use of the popular wireless JeeNodes, Glyn and Trystan have incorporated the JeeNode wireless functionality into the Nanode, and also devised ways of configuring the Nanode from a web browser.

Sam has been looking at the server side of things, and found ways of making very efficient web pages from minimal amounts of served HTML.

Matt has been working on various drawings and artwork, which will be used on the new Nanode and openenergy websites, and throughout the documentation pages. Here's an example of a Nanode graphic that Matt has produced to help illustrate some of the Nanode documentation. As an attention to detail - the resistor colour codes are actually correct - Nice one Matt!

Suneil has built up a veroboard version of the solar PV measuring circuit, so that it can be plugged directly into the Nanode to make a simple demonstration board which anyone can copy.

And on the last day, I was mainly responsible for lunch - a real feast of porkchops and sausage casseroled in Strongbow Cider and Chardonnay - with mountains of potatoes and gravy.

Back Row. Suneil Tagore, Ken Boak, Matt Gaffen, Sam Carlisle.

Front Row Trystan Lea, Glyn Hudson (Photo: Bethan)

In all, we had six developers working on collaborative openenergy and Nanode hardware and software projects for the best part of five full days, and two half days. At times the development work continued to 5am (Sam holds the endurance record) and restarted at 7:30am.

The outcome of the exercise is a strong development team with a wide variety of skills and expertise - who have proven that they can work together efficiently on exciting open source energy projects. I hope that the Snowdonbuild 2 is the first of many such collaborations.

Nanode Serves Solar Monitoring Data

2011-05-01T15:03:00.011+01:00

Day 5 of #snowdonbuild - a 6 day collaborative Open Hardware and Open Software hack session.

To further develop Nanode and Open Energy Monitoring Applications - held at a remote farmhouse cottage in rural Snowdonia.

After a morning of intensive hacking here in Snowdonia, the Nanode solar monitoring system serves its first web page with solar data.

As a reminder of the set-up we have here, there is a small 1W solar panel mounted on a wooden frame with a single axis solar tracking system driven by a standard size radio controlled servo.

One Nanode controls the solar tracking algorithm, and is powered from a solar charged 3.6V NiMH battery and super capacitor. The solar generated power, and the serial communications is connected back to the lab area using a 15mm length of telephone extension cable - this was mainly for convenience, as neither my LCD digital scope, used for measurements, nor my laptop screens are particularly visible outside in the sunshine.

The serial output from the measuring Nanode, is connected to the serial input of a Jeenodes wireless module. Glyn has written a small interpreter programme to run on the Jeenode, which takes the 5 fields of comma separated integer data relating to solar voltage, current, wattage, tracking angle and temperature, and converts them into a byte packet format which the JeeNode uses for over air transmission.

The data is received by a RFM12 module connected to a master Nanode, which is in turn connected to the internet. A byte packet decode scheme, takes the off-air data and reconstructs it into the 5 measured arguments.

The Nanode then serves these data fields up to the web, so that they can be viewed by any browser.

The solar data is also served up to the EmonCMS graphing server for long term storage, we have added the graphing capability which is generated by the EmonCMS energy monitoring system server and it is from this server that the graphical data is served.

The bandwidth and update frequency of the Nanode means that it is best used for serving small packets of numerical data, and not data intensive images.

Because we just handle integers at the moment the voltage is actually 5.32V and the temperature is 21.9C.

We've had the solar tracker running since early this morning logging the solar data to file. Although this is a very small scale system it can be easily extended to monitor full size solar installations.

More Solar PV Tracking and Wireless Communications

2011-04-30T16:53:00.016+01:00

Day 4 of #Snowdonbuild.

For the last couple of days we have been working on a simple project which illustrates the capability of the Nanode network applications node and attempts to put together a complete end to end demonstration.

We have chosen a small scale solar PV module monitoring system - which we first started on at the Pachube Hackathon back on April 8th/9th. We are now combining the solar energy monitoring and automated sun tracking with a wireless link and using a Nanode to get the data back to the openenergymonitor EmonCMS webserver.

The day started early with the development of the sun tracking algorithm. I decided to use a quick search method by incrementing the tracking servo position by 10 degrees searching for the maximum solar input. Once this maximum was found, the servo was returned to this position, and every minute a fine search of +/-5 degrees either side of the maximum was searched 1 degree at a time to find a new maxima.

Part of the problem was powering the unit and booting from cold when the panel first starts to get sun in the morning. I'm part way to a solution using a super capacitor (5.5V 1F) to hold sufficient charge from the panel, to allow the Arduino/Nanode to do a clean boot, and angle the panel into the sun.

To help us with this, we know that the sun always appears at roughly the same position in the morning, so at dusk we return to this position, in readiness for the next day.

Included on the rig is a 3.6V NiMH battery pack made up from 3 x AAA cells. The intention is that this acts as an energy store/buffer and holds sufficient charge to keep the Nanode running from day to day. I have not looked in detail at the energy budget/balance - as the main thrust of this project was to produce a simple solar tracker demonstrator with energy output monitoring which illustrates the control and monitoring capabilities of the Nanode.

Another potential problem is that the servo gobbles power to maintain position. A quick fix would be to use a PNP transistor in the +ve supply to the servo, and turn this off from a digital I/O line when the servo is not being updated. The friction in the reduction gear train should be sufficient to hold a lightweight solar panel in place.

Whilst I was sorting out the powering and tracking algorithms, Glyn Hudson was writing some code to get the solar tracking and power data out via a Jeenodes wireless link and from there up to the openenergymonitor EMONCMS web server.

My tracker produces a simple comma separated serial string, and Glyn wrote a Jeenodes transmitter programme, which receives this serial string, converts it into the packet format used by Jeenodes and sends it across the wireless link.

At the other end, a Nanode with a Jeenode wireless module acts as the receiver - decoding the over-air packets and converting them back into integer type data for pushing up to the EmonCMS web server.

Glyn has made a short YouTube of the Solar Tracker
showing it perform it's quick scan of the sky to get the approximate sun position.

SnowdonBuild 2 - Six Days in the Hills

2011-04-29T17:57:00.014+01:00

Take six techie developers and put them in a remote Welsh farmhouse for almost a week, with laptops, broadband and piles of hardware to play about with.

Add in a mix of communaly cooked wholesome food, a few crates of ale, and the Snowdonian landscape on their doorstep - and what do you get? SnowdonBuild 2 of course!

The next few blog posts will show you.

As a recap:

SnowdonBuild 1 was over the August Bank Holiday of 2010. It involved local lads Trystan Lea and Glyn Hudson, joined by Suneil Tagore from Cardiff and myself.

This year with the incredibly generous Easter/Royal Wedding break, it was decide to repeat the event - over 6 days, with a couple of new recruits, Sam Carlisle and Matt Gaffen, who came up with me from the London area.

The Mission

The aim of Snowdonbuild 2 was to produce a web-based open energy monitoring system, using low cost wireless and wired sensors and adapt it to monitor and control renewable energy systems such as solar PV and solar thermal.

Trystan, Glyn and Suneil had already developed a system based on Arduino for their openenergymonitor project, and one of the aims of the build session was to further this development to incorporate some new hardware and to improve the web based monitoring.

We have used JeeNodes, Nanodes and Arduinos as the starting point of the hardware. Much of the preliminary work was getting these similar platforms to be compatible from a hardware perspective. This has involved a small change to the Nanode circuitry to make the selection of the ethernet controller compatible with that of JeeNodes. As a side point, the JeeNode ethernet implementation uses clever interaction between ethernet controller and wireless module, allowing them to share the microcontroller interrupt line.

OpenEnergyMonitor is an open source energy monitoring system originally based on Arduino hardware. Approximately 2 years into the project it has become apparent that the Arduino is not the ideal candidate and two new hardware platforms have been developed to better match the requirements of energy monitoring sensor networks.

The first of these is Glyn Hudson's EmonTX, which is a small, battery powered wireless sensor node, based on Arduino and Jeenodes but with the addition of connectors which allow the direct connection of current transformers (CTs), pulse counters and one-wire temperature sensors. With EmonTX, it is very easy to set up a wireless electricity monitoring system.

The second new piece of hardware was my Nanode board. This is essentially an Arduino look-alike which is network connected. At its simplest it provides a simple gateway to the internet for low cost sensor devices. It can be used with a mix of wired and wireless devices to provide the basis of remote sensing, monitoring and control projects.

Over the next few days we would develop extensions to the existing systems and try out new ideas and code - as well as have a relaxing week in the Snowdon hills.

Simple Solar Tracker - Cat Not Included

2011-04-29T17:57:00.005+01:00

Day three of the #SnowdonBuild.

Another sunny day in North Wales, and having got the solar monitor working it was decided to have a go at a low tech solar tracker.

I particularly liked the single axis ones, where the axis of rotation is centrally down the long axis of the panel. This gives the added advantage of a steeper angle at dawn and dusk when the sun is low in the sky.

The rotating axle was made from bits and bobs lying around. It was an old length of IC tube, with a pen barrel pushed in at the top end, and a cheap screwdriver pushed in at the lower end. The pen barrel was hot-melt glued to a servo arm.

The frame work was made from two pieces of scrap wood, one notched to receive the the body of the servo and hold it in place. The screwdriver was similar to a "jeweler's screwdriver" which has a rotating end section which makes a simple bearing.

Driving the servo with the Nanode was simple - the Arduino servo library makes it very simple to set the servo to any angle between 0 degrees and 180 degrees.

The Nanode can either scan the PV angle for maximum power and then increment the angle by a few degrees per hour, to keep the maximum power output. Alternatively it can follow a pre-described tracking path of several degrees per hour, altering the angle by one degree approximately every 4 minutes.

The output mW of the solar panel was logged by the Nanode and sent up to Pachube for graphing. This simple 1W solar module model gives an example of what could be scaled up to suit a larger system.

Easter Hack - An Arduino Solar Thermal Controller - in 3 days!

2011-04-25T18:46:00.021+01:00

With the longer sunshine hours and warm temperatures, it's time to take my solar water heating out of winter hibernation and improve its control system. After some experience of making an Arduino Mega 2560 based central heating controller, it seemed a good idea to extend some of the ideas to include control of the solar panel. Central heating is generally in use from October through to April, and solar water heating for the remaining months. It seemed sensible to ultimately incorporate solar heating control into the central heating system and get the most from the control and monitoring system.

As part of my aim to use low-cost web connected sensors to measure the contribution of renewable energy systems to the UK domestic energy mix, using a solar thermal panel as a potential first candidate seemed a good idea.

My task for the Easter weekend was to come up with an Arduino based solar controller and use it to collect solar and temperature data and pass this up to the internet using my Nanode low cost Network Node and a web-data service such as Pachube.

It had to measure the inlet and outlet temperatures of the solar panel, the flow rate and control the speed of the pump motor. It also monitors the quantity of solar heat into the water by measuring the flowrate of the circulated water.

Here's my array of 20 evacuated solar water heating tubes. They are mounted on my south west facing shed roof. There is a small 1W solar panel mounted to the upper right of the frame, which can power the Arduino circuitry and also give a good indication of the strength of the incident sun.

This photo was taken about 6pm - just when the sun was leaving the panel.

It is in sunlight from 10am to 6pm, and produces useful thermal output from about 10:30am. Not bad for late April.

The output of the solar thermal array is linked back to my hot water cylinder with about 25m of insulated microbore tubing, and the water is pumped with a 12V dc pump.

Here's my DIY Arduino built on stripboard. It's a bare minimum configuration, just ATmega328, 16MHz crystal and reset circuit with a FTDI cable connection to the laptop programme it and log the solar and temperature data. A 5V linear voltage regulator allows the board to be powered from a wide range of supplies, eventually a small PV panel will be used to power the system during daylight hours.

The dc pump motor speed control is a PWM signal to an IRF640 Mosfet. It is on the bottom right of the case mounted to a heatsink.

The board is mounted inside a Danfoss central heating "wiring centre" case. It's a convenient case with screw terminal connectors.

This photo shows the dc pump (Totton Pumps) and the water flow sensor (UCC from Farnell/RS).

The pump motor is 12Vdc max 4 amps and I use an IRF640 power mosfet with PWM drive to control the speed of the dc pump motor. The Mosfet has to be mounted on a heatsink as it definitely runs on the warm side.

The flow sensor provides a square wave output of frequency proportional to the flowrate. I use an interrupt driven routine averaged over 4 seconds to determine the water flow rate.

Temperature sensors are 10K thermistors. I use a pipe-clip type available from Rapid Electronics (26-7470). These are fitted to the inlet to the panel and the water outlet. I calculate the temperature difference between outlet and inlet, and also the flow rate of the water through the panel.

Multiplying the temperature difference by the flowrate gives a figure which is proportional to the instantaneous power output of the solar thermal panel.

A Wireless Home Energy Monitor to Accompany Nanode

2011-04-17T20:20:00.011+01:00

One of the first projects after the Nanode has to be a wireless shield in order to allow Nanode to talk to wireless sensor networks.

In the last couple of years there have been an increasing range of cheap wireless modules available to the hobbyist.

As well as 2.4GHz Xbee and Bluetooth offerings, sub-1GHz is better for in-building propagation. Additionally, if you only want to pass a few bytes between sensing nodes, Xbee and Bluetooth are expensive overkill. Passing a few bytes between nodes is exactly what we want to do with the Nanode, and so a low cost wireless solution working at below 1GHz was sought.

Hope RF produce some nice cheap transceivers that work below 1GHz - and programmable to any of the ISM bands 315MHz, 433MHz, 868MHz and 915MHz. They are available in the UK from Maplin, at just £5.99 for a transceiver.

I had previously experimented with short range wireless, using low cost on-off keyed (OOK) modules. I'd even adapted the SNAP protocol from HiTech Horizons to work across the wireless link, but it was all coded up in PIC assembly code and it was difficult to maintain.

The arrival of the cheap Hope RF modules, and the "Arduino like" JeeNode, meant that progress with with simple wireless networks has been very much accelerated.

JeeNodes are the brainchild idea of Jean-Claude Wippler, a very talented multi-discipline engineer from the Netherlands. J-C had the idea of grafting a RFM12 wireless module on to a BareBones Arduino to make a simple wireless node. The second innovation was to arrange the I/O lines of the AVR into 4 identical ports. Each port consisted of a digital line, an analogue line, power, ground and an interrupt. With this standard interface, any add-on device could be plugged into any port. J-C has also written a comprehensive library to support this port structure.

Glyn Hudson at openenergymonitor.org shared a new design with me for a wireless energy monitor, which he had designed to be compatible with the JeeNode, and with this inspiration I decided to modify it to make it compatible with the Nanode.

Glyn had taken the JeeNode idea of 4 separate ports and an RFM12B wireless transceiver and added the extra hadware needed to do electricity monitoring, temperature measurement and pulse counting - for example from a gas meter.

I decided that the JeeNodes port layout was a good innovation, but if it also had Arduino shield connectors, it could turn a conventional Arduino into a Jeenodes compatible device - as well as all the home energy monitoring interfaces.

So what has been conceived is a bit of a hybrid.

It's a JeeNode wireless shield for an Arduino.
It's a standalone wireless home energy montor.
Its a wireless shield for Nanode
It's a home energy monitoring shield for an Arduino.

Some basic design features:
1. Hope RF RFM12B sub 1GHz transceiver
2. Compatible with Jeenodes firmware
3. Jeenodes "Ports" supported
4. programming via FTDI cable or Vusb port
5. One Wire sensor support - up to 8 DS1802 temperature sensors etc.
6. Connects to one current transformer (CT) and one voltage reference input
7. One interrupt driven pulse counter - for gas meter pulses
8. Supports Nanode local serial bus.
9. Driver for 2 relays or 2 serial slave boards - for central heating/solar hot water control
10 Can be used a basic shield or standalone unit.

With these basic features in mind, I set about laying out a wireless home energy monitoring shield which could also work as a stand-alone wireless node.

Nanode 101

2011-04-12T19:48:00.005+01:00

Introduction

Nanode is a low cost sensor node intended for web connectivity applications.

Officially, Nanode stands for Network Applications Node - unofficially it could be described as a Networked Arduino Node.

Nanode shares a lot in common with Arduino, and can be programmed using the Arduino IDE.

Nanode has been cost engineered to under £20 in order to make it attractive to the hobbyist.

Connectivity

Nanode has two separate network connections, firstly an Ethernet connection to access the Internet, and secondly a wired serial bus, which allows several Nanodes to be connected together in a Master/Slave heirarchy using low cost telephone cable.

I/O Capability

Nanode is based on the Arduino and offers a subset of the Arduino I/O.

Up to six uncommitted analogue input channels and up to six digital I/O lines are available.

Analogue inputs can be reconfigured as digital I/O if needed. The remaining Arduino I/O is used internally by the Nanode for running the Ethernet controller, handling the serial bus and USB communications and so cannot be guaranteed to be available for user applications.

Arduino Shields

Nanode accepts Arduino shields, as per the Nokia 3310 display shield shown above. A range of shields in anticipated to cover the essentials of a wide range of applications.

Pachube

Nanode works with Pachube to enable it to communicate with other web applications.

Nanode for Renewable Energy Crowd-Sourcing

2011-04-11T09:28:00.003+01:00

How much renewable energy is being produced at any time in the UK? How does a PV array in Surrey compare with a similar sized one in Scotland? Is it currently sunny in Belfast? What is the current windspeed and direction in Welshpool?

These, and other questions could be answered using Nanode based sensors, fitted to renewable energy installations distributed around the country. The low cost of the Nanode makes renewable monitoring very affordable. Even on a £400 solar water heating system, the monitoring and control system, if based around Nanode would be just 10% of the outlay.

At the Pachube Hackathon we connected 3 Nanodes together using Pachube, so that we could monitor the output of a small solar panel plus the outside temperature. This was a small scale version of a real world app for the Nanode.

We believe that this will be a very important application for Nanode, acting as a domestic renewable energy monitor. It could, for example log all of the utility consumptions - water, gas and electricity, plus any renewables you may have installed, such as photovoltaics, solar hot water or wind power.

With a large population of Nanodes monitoring domestic energy consumption or renewable production, using statistical crowd-sourcing analysis of the data, important information regarding the state of the countries energy consumption and renewable production could be made available to the public domain. Nanode users could participate in a competetive game, trying to lower overall utility consumption, whilst maximising their renewable generation

A snap-shot of photovoltaic production in the UK, on a sunny afternoon, could be available to all, in virtual real-time. The low cost of the Nanode will stimulate these types of application. Additionally, on the back of the utility and renewables monitoring, the Nanodes could provide smart central heating or solar water heating control, triggered from an iPhone app, for example. Indirectly, Nanodes would provide weather data - which could be gleaned from the solar output figures. A Nanode could be interfaced to a low cost weather station kit, to give windspeed, wind direction, outside temperature, humidity etc.

In our small scale Hack, one Nanode acted as the sensing device (a slave) producing solar volts, milliamps and temperature readings every few seconds. It was connected via 15m of telephone extension cable to another Nanode which had the ethernet connection to get that data up to the net using Pachube as the host. A third net connected Nanode, subscribing to the Pachube feed was then used to work a servo actuator and a RGB lamp as visualisation devices.

Pachube Hackathon - Nanode's first Outing

2011-04-10T14:20:00.022+01:00

I've just got back from the 24 hour London Pachube Internet of Things Hackathon. We converged on Peter Street, in London's Soho district, for #pachubehack- a global event to coincide with International Internet of Things Day (April 9th 2011). Sister events were happening in Eindhoven, Linz, Zurich, Seoul, New York City and Lancaster. (Next year will be bigger better and everywhere).

The event was held in a large airy basement/boilerroom of a Victorian school. Now converted to a media studio. A small courtyard gave a handy area to get some fresh air or chat with friends over a beer.

Here's "Waving Kitty" - a £5 Lucky Cat, bought in Chinatown on Friday afternoon just before the Pachube Hackathon. Waving Kitty now has a Twitter account and responds to Tweets and Pachube Feeds in just the way a robot-hacked Lucky Cat would. Great hack - by Paulo Ricca and Frieder Ganz.

A small patch of sun outside a Soho basement - just enough to try out our Solar Nanode Hack. A Nanode device monitors solar power from a small PV panel. Imagine if every PV array in the country had low cost monitoring like this? £20 is not a lot to pay to know what is going on. Close up of "Breadboard Friendly" Nanode measuring solar volts and milliamps. Supercapacitor, white LED array form the load. Three thermistors give outside temperature readings.. 11th Hour activity in "Nanode Corner". Matt, Luke and Oleg sort out the app whilst Sam, with back to camera in corner tries to sort out Ken's code!

I gave my Nanode presentation at 3pm and informally throughout the session - including at 1am to NYC. I then hit the "Z-plane" for a few hours.

We hacked 3 Nanodes to complete a sensor chain - from PV and temperature sensors, back to a Master Nanode, and then up to Pachube. A subscribing Nanode completed the presentation with an RGB LED orb and a servo-pointer-thingy (servo with coffee stirrer attached) to allow the data feed to be visualised.

Trystan Lea of Openenergymonitor.org had a Nanode connected to an electricity monitor and also a temperature sensor on his hot water tank

Michael Doherty - overall winner in London, catches up with some Zeds after hacking all night!

At 1pm we had presentations from all the hack teams. Outright winner was Michael Doherty who hacked alll night and then slept until lunch time, but received a GPRS modem from Arkessa- well done Michael.

Prizes also to the team that did a RFID bookshelf, and "Rogue Commuter" with some great ideas on how to give everyday objects a personality - so that it can help your daily battle against the dark forces of Southern Railways (or any other thieving rail operator you choose to vent your spume against).

This was a great event, with lots of great talent and ideas, some of which I still struggle to understand.

Well done to all the Pachubehackers who took part around the globe. We can only look forward to the next event in 6 months time.

Pachube Internet of Things Hackathon - Final Preparation

2011-04-07T18:26:00.002+01:00

With less than 20 hours before the Pachube IoT Hackathon begins, I am starting to get stuff ready to take.

I've been asked to do a presentation about the Nanode, for 3 minutes, and also run a 1 hour "surgery".

I've emailed the presentation to the groups in Lancaster, NYC, Eindhoven and Zurich - with Seoul and Linz still to do.

I'm bringing 4 of the prototype Nanodes, plus the original breadboarded unit. In addition an Arduino plus ethernet shield which will emulate the Nanode.

There are already six Nanodes out in the wide world, given to friends and colleagues who are beta testing them, or have contributed to the project.

We already have on Nanode which is monitoring electricity usage in a house in North Wales and putting this up to this Pachube Feed

The plan is to distribute 4 Nanodes to the teams at the London Hackathon, sit back, relax and let them dream up some really good apps.

I'm bringing a few RGB lamps which we can use as ambient orb displays, plus a servo-pointer-thingy which makes a good large scale analogue meter. I also home to have some big LED 5x7 matrix displays which we can hack in some shape or form.

Nanode has consumed most of my free time of the last 3 weeks - so it will be good to let others take the lead.

Nano Tweets - It's an Enigma

2011-04-05T12:02:00.005+01:00

Minimalist communications between microcontrollers both solves and creates some specific problems.

For example, how do you decode a message and know what context it was written in, what meaning it conveys and having got the decoded arguments, what do you do with them?

Some protocols put the arguments in specific places in the packet, for example, start of packet header, source address, destination address, number of bytes, payload and checksum etc would be placed in the packet in a given sequence. The microcontroller just needs to find the start of the packet header and work its way through the various fields.

An example of this is the simple format is the free and open SNAP (scalable network application protocol) devised some years ago by Swedish home automation company High Tech Horizons.

Another example is to use a mark-up language, such as XML, to convey the context of the various data fields. The CurrentCost CC128 Energy Monitor uses this approach, but the packets tend to be fairly verbose, which is fine if you have a PC, lots of RAM as a packet buffer and high level language with which to parse the packet. This is not often the case with a $3 microcontroller.

How could you convey context to a small packet of data, without having a massive overhead of extra data? In effect strike a balance between SNAP which is context free and relies solely on the order of the data fields in the packet and XML whre everything is spelt out for you with lots of additional text strings.

The answer lay nicely in the cipher machines and code breaking techniques of WW2.

In the 1940's the Enigma machine was used to encryt and decrypt messages so that they could be sent between German Command and various outposts. The Enigma machine had been sold throughout the 1930's as a secure messaging machine for businesses.

The key to the Enigma machine were three (and later four) alphabetical code wheels. The user was instructed what particular codewheels to fit, and in what order. The code wheels were then turned so that a particular letter was visible to the operator.

Once this was done correctly, all characters in and out of the Enigma machine would be correctly encrypted/decrypted.

Remembering this gave me a flash of inspiration. How do you come up with very short messages, which are character efficient but allow a wide variety of different tasks to be actioned?

The answer is to use a method analogous to fitting different code wheels. And these "codewheels" convey the context. You would only need to send the "codewheel" byte once, and from that point everyone who's listening, knows what you are on about.

For example sending Context 55, would tell all your subscribers that they should look up from ROM that Context 55 is for a 6 channel temperature sensor, and so that all subsequent messages contain temperature data in centigrade to one decimal place.

For simplicity, lets assume that single alpha characters A,B,C initiate certain action routines. In order that the Nanode performs the correct action for the application, it first has to be instructed which code wheel or rather book of actions it should be using.

By instructing a subscribing Nanode to use a different set of action routines, would be a very quick way of changing its application or context.

There would be a default set of routines to which all respond in the same manner, and a series of command primitives or directives based on punctuation characters like @ and #.

The first character of any nano-tweet message would either be an alpha character to signify an action routine, or a punctuation character to define a primitive command or the context of the remainder of the message.

Nano-Tweets?

2011-04-05T08:54:00.008+01:00

Last August I blogged about an idea I had for an equivalent of Twitter, but for short messaging between resource limited microcontrollers.

With a little bit of thought, this could become a very simple means for smart sensor nodes or simple devices to communicate via the Internet of Things.

I had already experimented with simple CSV serial command strings to control an instrument I was developing, which used an Arduino. Typing commands in the serial window, sent data to the serial port of the Arduino, which was then decoded and used to invoke certain action routines to control various functions. This worked well, used a human readable (memorable) set of alphabetical and numeric commands, and used very little firmware overhead to write a simple command interpreter. Easy enough for even my C-skills to cope.

The command interpreter was as rudimentary as a series of switch/case statements that if you receive character "a" do this action, "b" do another action and so on.

So I had character "a" controlling signal amplitude, "b" for setting the brightness of the LEDs, "s" for setting the position (angle) of a R/C servo, and so on.

s,90 would move the servo to its 90 degree position - it really was that simple!

About the same time, I was getting interested in remote sensors and home automation. It dawned on me that my messages were identical to a Pachube CSV feed, and that Pachube could easily be used without modification to get data from one microcontroller to another.

The whole thing would be set up as a Publisher/Subscriber messaging model.

The message would consist of a few characters of data or arguments, separated by commas, which would be broadcast from one device to many subscribers using a Pachube CSV feed as a data exchange mechanism. All of the hard work was done by the Pachube API.

With the advent of low cost hardware, in the form of the Nanode, the need for this message format is now growing, and it is hoped that some ideas can be discussed and tried at the Pachube Internet of Things Hackathon at the end of this week.

For one thing, the messages need to be short, just a few bytes of data to convey the minimum of information necessary to convey sensor readings or command data. In the case of wanting to directly control a remote device, the remote device needs to be alerted that the message is intended for it.

In a similar fashion to Twitter, use of the @ character could be used to indicate that a message is aimed at a particular node. Conveying context in the message could be done purely by the order of the arguments, or by preceding a particular argument with a special character.

Again, borrowing from Twitter, the hash symbol # could be used to precede an argument, to convey that the argument is a particular subject. An example of this might be two Nanodes controlling some sort of central heating system. Let's assume that the relay to control the boiler is controlled by digital output 8. Using #8 could be used from the sending Nanode to signify that it is refering to an object on "number 8" and the next byte could be used to define what state it should be in. This would be a good way to convey 8 bit PWM commands to particular pins of a given Nanode.

The sort of operation we wish to perform on a microcontroller involve the setting and reading of port lines, reading and writing to memory or registers, outputing PWM, making ADC measurements and timing pulses. Additionally we may have a list of high level action routines pre-programmed into the Nanode, which we just want to invoke, on receipt of a certain command. Nano-tweets could be devised to be non-machine specific - a bit like the register based Firmata protocol. A simple command interpreter, written for a given microcontroller, would be all that was needed to handle nano-tweeting. Moving to a different micro would be simple.

For debugging purposes, it may be beneficial if these Nano-Tweets are semi-human readable - so the use of memorable characters or punctuation marks will be useful in achieving clarity of meaning.

Nano-tweets consisting of comma separated arguments can be transmitted down various kinds of network, wired, wireless or ethernet. A nano-tweet originated by a web connected Nanode, published up to Pachube could be echoed by a remote Nanode down it's local serial bus and used to control slave Nanodes connected to that bus.

Over the next few weeks, I need to define the nano-tweet protocol, and write a generic nano-tweet command interpreter, which can be applie dto many different applications.

Pachube - Social Networking for Nanodes?

2011-04-04T22:18:00.005+01:00

For a few days I have had the Nanode prototypes running code and transferring data via Pachube.

Nanode uses the Pachube API with simple CSV data, so that any message or command packet which can be coded into a few bytes of CSV can be broadcast from the publishing Nanode to many subscribing Nanodes. This is effectively Tweeting for low cost, resource limited microcontrollers.

A Nanode, fitted with sensors can send a message out through Pachube, and expect its subscribers (followers?) to receive and act upon it within 5 to 10 seconds.

In the same way that Twitter is not for the verbose - Nanode communications need to be short and to the point. About 5 bytes and a checksum is optimum. Those bytes can contain sending address, destination address and command bytes. Could a micro-tweet be social networking for microcontrollers, and central to the Internet of Things?

More Applications on the Nanode - RGB LED lamp

2011-04-03T19:24:00.008+01:00

Today I have been sorting out some application code for the Pachube Hackathon, and have got a simple RGB LED lamp to be controlled from one Nanode instructed from another Nanode via Pachube. I see the passing of data from one Nanode to another via Pachube as a fundamental application, and today's tests proved what it can do, and some of its limitations.

As you may know, Pachube can handle comma separated variables (CSV) as one of its low level data exchange formats in its API. Simple, resource limited microcontrollers can readily produce CSV data using print statements and manipulate the data within them using string functions and string ennumeration such as the atoi (ASCII to Integer) function.

First some background. Last summer, I had the task of designing a test harness interface for a light-box I was building at work. Conveniently I was controlling the ultra-bright white LEDs in the light box with an Arduino Nano, so it was a useful exercise to come up with a simple serial protocol and command interpreter, written for the Arduino which could be used on other projects.

I wanted a semi-human readable format, so commands would start with an alphabetic character to make them easy to remember, followed by a short series of numerical parameters. For example, to control the brightness of the lamps you would use B (for brightness) followed by the value desired: B,100 would set the brightness to 100, from a maximum of 255. It was then and easy extension to modify thes commands to include more parameters - for example a RGB LED lamp might have the command L,55,130,75 - L for LEDs, and 55,130 and 75 being the valuse for the R,G and B PWM channels.

Having stumbled on this simple serial command method, it occurred to me that it could be passed down any serial communication channel, but more excitingly, Pachube could pass this command data by way of one of its feeds from one web connected node to another, and thus the project which was to become the Nanode was born.

As stated above, I use a very simple serial protocol, and have two terminal windows open, one for the Publisher (Putter) and the other for the Subscriber (Getter). Typing r128 in the Putter window, sends a command up to Pachube, and shortly afterwards the command appears in the Getter window and the red led changes to mid brightness.

A concatenated commamd of l, 255,0,255 is interpreted as l for lamp, and 255,0,255 turns red and blue full on and green off - resulting in a nice glowing mauve.

In terms of overall command latency, i.e. the time taken from entering the command to the Nanode at the far end acting upon it the mean time is about 5 or 6 seconds. Once the Publishing Nanode has set the post to Pachube, the lamp controlling Nanode responds in about 3 seconds. It's not lightening quick, but some control tasks, such as central heating or remote appliance switching don't need to be lightning fast. Fast enough to control relays and actuators.

The sample code for the Pachube Putter and Getter is available from my Thingiverse site.

Preparing for Posting

2011-04-01T15:49:00.005+01:00

Having rushed the first pair of Nanodes through on Wednesday and proved that they work together, I have been putting some further documentation on the London Hackspace Wiki page.

I'm a very infrequent visitor to the Hackspace, now living and working some distance from central London, and so I have offered the Hackspace "first bite" at the Nanode, as an open source design which will benefit their members, allow them to develop new applications given a boost of very low cost hardware. There will be a special "Hackspace" branded board, bearing the distinctive Hackspace logo and a construction and use workshop session planned to coincide with the arrival of the first batch of Nanode boards bearing the Hackspace Logo.

The new "Hackspace" Nanode features one or two corrections and updates over the first prototypes.

It has an easy to connect 4 way screw terminal block on the left to connect 12V power, ground and the wired local network. Boards can be connected together easily with 4 way telephone cable on a bus that supplies both communications and power for the applications.

The reset switch is now either a vertical or horizontal type and located at the edge of the board for easy accessability when a shield is fitted. Likewise for the LED, now on the board edge.

The biggest upgrade is to include provision for Virtual USB or Vusb. This is a USB transceiver which runs in firmware on the ATmega328, and means that the Nanode can be programmed and communicate with a PC without having the need of the FTDI cable. I have implemented it the same as the Metaboard, thus making it compatible with their programming software drivers which can be installed as part of the Arduino programming environment (IDE).

The first of the Hackspace Boards will be available in early May - if all goes to plan.

Meanwhile, on the first 10 samples, I have been busy preparing kits of parts for some Beta testers of the Nanode. Hopefully these boards will be shipped this weekend. These first boards will go to friends and associates who have assisted with the project, and best placed to do something special with the newborn Nanodes.

Two will go to my friends at Openenergymonitor, a further two to Andrew Lindsay who wrote the improved ENC28J60 Ethernet library for the Arduino, two to John Crouchley of Nottinghack who assisted me with the Pachube Getter code, and two for Stephen Blomley and Samuel Carlisle - members of the London Hackspace who wish to take it on as a collaborative project. That just leaves two for me, which I hope to demonstrate at the end of next week at the Pachube Internet of Things 24 hour Hackathon. Just 166 hours off......

I have done some costing of the Nanode, and by choosing Cool Components, Rapid Electronics and Spirit Electronics for the PCBs its possible to build a batch of 10 Nanodes for £18 each (and that includes VAT and shipping). This low cost should appeal to Hackspaces, Colleges and amateur enthusiasts alike.

I have also adopted Thingiverse as a repository for all the build and construction files for the Nanode. As it is a work in progress, there are likely be a number of changes in the next few weeks. Remember to check for regular updates. Already there have been a couple of corrections around the ethernet magjack connector and the power supply connection.

So now its back to kitting, three 10 resistors, check, four 51 ohm resistors, check and so on......

Applications for the Nanode

2011-03-30T12:16:00.003+01:00

Having now built up the first pair of Nanode boards it's time to test them out and then start to develop applications.

The first thing on the list is to test the basic ethernet connection, and ensure that the boards can communcate with Pachube, which I am using as a brokerage service to broker messages and data between Nanodes.
As described in a prevous post, one Nanode will publish data up to a Pachube feed, and the other Nanode will subscribe to that feed at regular intervals, and print out the data to the serial port.
Here are the two boards each connected to a network port. The orange and brown wires between the boards is so that they can share the 5V power from the FTDI cable.

The upper board is the Publisher (Putter) and the lower board is the Subscriber (Getter). Every few seconds the Putter sends a new packet of data up to Pachube feed 8729, and at regular intervals the Getter subscribes to this feed to retrieve the data. In this case the data is a simple comma separated list of 6 arguments, which could be six readings from the ADCs on the Putter device, or a numerical command to which the Getter will respond.

Nanode 5 - Just Make It!

2011-03-29T21:55:00.026+01:00

Nanode is a very low cost internet connected microcontroller board - compatible with the Arduino programming environment. It allows applications for internet remote monitoring and control to be developed on a familiar low cost platform, such as web servers and clients or for data exchange and control using services such as Pachube.

You can keep updated on the Nanode Project at the official website and also on the Hackerspaces Wiki.

The EagleCAD schematic and board file have been uploaded to my Thingiverse account. Here's how to build a Nanode - takes about 90 minutes.

Follow the Pictorial Guide on the London Hackspace Wiki for full instruction of the Build Sequence.

Nanode - It's a Bit Small Isn't It?

2011-03-29T20:05:00.009+01:00

Here's the first of the prototype Nanodes built up, tested and working. The Nanode can be used with a variety of Arduino shields, but you may have to use extended stackable headers like these from Cool Components to give extra clearance between the shield and the Magjack. Using the local serial bus, it is possible to connect Nanodes together using 4 way telephone cable in a Master/Slave Network. It is likely that the Master device will be the one with the internet connection, and the slaves are used for specialist tasks such as pulse counting, electricity monitoring, controlling relays, measuring temperatures etc. In this case, you might wish to create a simple user interface on the Master device, possibly by fitting a display, such as the NuElectronics Nokia 3310 shield as shown below.

Nanode - Just Make It!

Pachube Internet of Things Hackathon

2011-03-29T14:37:00.006+01:00

Just 9 days to go until Pachube hosts the first global Internet of Things Hackathon - a 24 hour event commencing in London and with sister events happening in several different countries.

In preparation for the event, to provide suitable web connected microcontroller hardware - I am putting together a small batch of Nanodes - a low cost target board designed for Internet of Things sensor applications and built to be compatible with Arduino technology.

For under £20, the Nanode offers a platform to develop intelligent sensor network node applications, capable of communicating via the Internet and Pachube or locally with other nodes on a low cost wired serial network. It can act as a web server, a web client or communicate with other web connected Nanodes using a publisher/subscriber messaging protocol.

Nanodes can also be connected together using a simple "multidrop" serial bus - made from low cost telephone extension cable. This carries power and data and allows Nanodes to be distributed around the home for tasks such as home heating control, home automation and energy (electricity and gas) monitoring.

Slave Nanodes can be cheaper still, by not fitting the ethernet components, yet still communicate with a master device connected to the internet.

Last summer, a pair of early prototype Nanodes successfully communicated with each other using Pachube as a publisher/subscriber service for short messages. A message left on the Pachube feed by one Nanode, would be picked up by a second Nanode which subscribed to that feed, decoded and used to perform some local action - such as switching a relay or changing colour on a RGB LED lamp.

For the example of the RGB LED, the publisher would send a short message consisting of comma separated arguments to Pachube b,1,255,255,255 This would be interpreted by the subscribing Nanode as a command to set the brightness (b) of the red, green and blue PWM channels of the LED (number 1) to full brightness (255) resulting in a white colour.

The publishing Nanode might have a temperature sensor connected to one of its analogue inputs, and change the arguments of the brightness command according to the temperature. Any Nanode subscribing to this feed, and equipped with the RGB LED would change the colour space accordingly in response to temperature.

This is a trivial example of how two Nanodes can communicate via Pachube. The publisher pushes the message, with no regard to whether it is received or acted upon. It might be possible to use a second Pachube feed as a "back-channel" to allow the publisher to be informed if the message has been received and acted upon.

At the Hackathon it is hoped that we have 5 pairs of Nanodes distributed around the country at various sister events - Nottingham Hackspace, OpenEnergyMonitor.org, North Wales, London Hackspace, Thatcham and at Pachube's own event.

Anyone with an Arduino and NuElectronics Ethernet Shield, could participate with nearly the same firmware. Following that, the intention is to make a batch of 100 boards and offer them at discount to interested parties. Bare boards will be offered at £5, and complete kits for under £20.

Pubbers & Subbers, Putters & Getters, Movers & Shakers - and Purple Hearts!

2011-03-26T14:40:00.005Z

Sometimes the best made plans fall apart - due to circumstances beyond one's control. As a result of missing the postman at 8:13 this morning, my component order has gone back to the Royal Mail depot - and not retrievable until 7am on Monday morning - doh. Time to get a louder doorbell!

That rather put a kybosh on any new hardware developments this weekend. Instead, I thought I'd dust down some of the hardware I developed for the prototype ethernet node back in August last year and get re-aquainted with firmware which allows it to communicate via Pachube.

The first Arduino/Ethernet node was built on breadboard from 3 ICs (Atmega328, ENC28J60 and 74HC125) and about 35 other components. With a little care, the design will fit on a single standard, 63 strip breadboard, and cost about £12 in components to make. The Nanode is just a compact PCB version of the original prototype, designed with through hole components to make it easy to build at home.

Firstly, I thought I'd look back over the simple Publisher/Subscriber code I wrote for the prototype Nanodes about 8 months ago and have a go at getting the breadboard ethernet hardware running again - see above.

The strategy is based on the simple model that one ethernet connected device publishes a string of data to a Pachube feed, and that multiple nodes can subscribe to that feed and make use of the data.

The simplest Pachube feed is a comma separated array of values (CSV), so the publishing device - the "Putter" has to put out a CSV string of arguments, and the subscribing device, the "Getter" has to be able to subscribe to the given Pachube feed and get the CSV data into a form where it can do something with it.

I have dusted down the "Etherduino" breadboarded ethernet connected Arduino ( see August 2010 posts for details) - and this is acting as my "Getter". A standard Arduino and ethernet shield is acting as the "Putter".

The first test is to ensure that a simple message of say 6 comma separated arguments can be passed seemlessly from putter to getter. So far, so good - my getter is printing out the serial CSV string to my monitoring serial port every few seconds. Now to come up with an interesting demonstration application which involves some moving and shaking.

Back at Homecamp in April 2009, I showed a very simple use of a radio control servo with a coffee-stirrer glued to the servo arm, which was used as a large scale analogue meter. The Arduino can drive the arm to any angle from 0-180 degrees, and use the coffee-stirrer pointer to point to any chosen value on an A4 sized graphic. The great thing about servos is that they buzz when they move, and this attracts one's attention to the fact that something is changing.

Another easy hack is the use of low cost LED lamps to make colour changing "ambient orbs" to visualise a physical parameter - such as temperature or electricty consumption. A recent sale at Homebase and I bought 4 lamps for £10, including Heart, Orb, Cube and Star. From chilly blue to toasty red orange, and optimum green when the room temeperature is at its best.

A combination of the servo and RGB LED "ambient orbs" might be a good set of visual demos for the forthcoming Pachube Hackathon.

Nanode - A Net Applications Node

2011-03-19T15:06:00.022Z

Nanode - a £20 Network Applications Node for remote sensing projects.

Having worked with Arduinos for a couple of years, I was keen to extend the functionality and scope of the basic Arduino to include the ability to be networked with other Arduinos or devices via the internet or a local serial network - as the communication to the Arduino is fundamentally serial.
The opportunity came with the low cost NuElectronics Ethernet Shield, which provided an ENC28J60 ethernet controller and a Magjack for about £12, however by the time you had added an Arduino (and 20% VAT), the cost was approaching £40. The simplicity of the hardware was such that I reckonned that there must be a much cheaper way of getting internet connectivity - and thus the Nanode was conceived.

Combining an Arduino microcontroller and ethernet controller onto a single small board for developing networked sensor applications at minimal cost seemed an attractive proposition reducing the cost of net connectivity for microcontrollers by a factor of 2 - to an affordable £20!
The Nanode takes the standard ATmega328 microcontroller - as used in all the standard Arduinos, and combines it on a single board with an ENC28J60 ethernet controller and Magjack.

This was not the first time this had been done, Tuxgraphics produced the first one about 5 years ago as detailed in this article, and there was a very capable design on Instructables a couple of years ago. Indeed, almost all of the firmware for the ENC28J60/ATmega combination is derived from the original Tuxgraphics code.

So Nanode is not new, it owes its heritage to at least two previous designs, but it does introduce some new features which I hope will bring it more into the Arduino playground. Unlike previous designs it presents its I/O in a form which is compatible with Arduino shields, but also enhances the I/O capability with additional connectors - making the I/O more accessible when a shield is fitted and allows the device to be plugged directly into a breadboard and still access all of the power and I/O.

So after the initial idea was hatched, I had to make a prototype. I'd had a bit of prior experience breadboarding ethernet, so last August I combined the Microchip ENC28J60 ethernet controller and the ATmega328 and 74HC125 tristate buffer on a breadboard to prove the design. The combination of the 3 ICs and the Magjack on its breadboard friendly breakout board (from Cool Components) was a neat fit on the standard size breadboard. Cool Components source most of the key components, allowing the design to be built on a breadboard for about £12. A later post will describe the breadboard construction in detail - for those brave enough to follow this route.

So the Nanode, provides ethernet connectivity to what is essentially a standard Arduino and allows access to most of the original I/O lines for the control and sensor applications. To summarise you have 6 analogue inputs, 8 digital I/O lines and a serial port remaining after driving the ethernet controller. With this you can sense analogue variables such as temperature, pressure or energy consumption such as electricity or gas, and have the ability to control relays, displays or actuators using the digital I/O. The Nanode takes the serial interconnection one stage further and using some of the spare 74HC125 buffers implements a "multidrop" serial network - allowing Nanodes to be connected together on a local serial network, which provides communications and power.

Having built the first one up on breadboard, as a minimalist proof of concept, I got it working to the point where I could send messages or control packets to another network connected Arduino and NuElectronics Ethernet shield, using Pachube to transfer data between the nodes. Then I got distracted by other things and the "Etherduino" - the early construct name for the Nanode, got put to one side for 6 months.
It was on hearing that Pachube are hosting an Internet of Things Hackathon in London on April 8th/9th which encouraged me to revisit the design with the aim of having it ready for the Hackathon. The breadboard ethernet Arduino is now Nanode - a Network Applications Node. (Or Networked Arduino Node - for those in the Arduino camp).

Timing of the Hackathon was perfect, allowing me 2 weeks to finish my design and get some boards made. I also had wanted for some months, a general purpose DIY Arduino compatible board, which could be made more cheaply than commercial units. With the features of more friendlier I/O connections and had the means to be networked to other nodes on a serial bus, the Nanode seemed the ideal entry point into Net Connectivity for under £20.

Above: First Prototype Nanode Runs Pachube Client Code. Blue LED shows Ethernet data activty.

This new board was the opportunity to address some of the points on my wish list. There were several design points which I wanted to take into consideration and resolve:

1. Must be easy to build by anyone who can solder - so 2 layer PCB design (EagleCAD) using conventional and readily available through hole components. Board is 72.4mm 58.4mm (2.85" x 2.3") - marginally bigger than Arduino, to account for additional I/O connectors.

2. Low Cost - hence the use of the Microchip ENC28J60 ethernet controller.

3. Compatible with standard Arduino shields - matching connector pitch - warts and all!

4. More flexible I/O arrangement. I have fitted additional connectors on 0.1" pitch which allow compatibility with breadboards and stripboard. All of the standard I/O pins and power from the ATmega328 are available along one edge of the pcb, which simplifies plugging this board into breadboard or 0.1" stripboard. They also allow the I/O headers to be accessed even with a shield fitted. An extra connector in the top left corner brings up the analogue inputs and 5V power - so all of the ATmega I/O and power can be accessed from a single edge of the board with a SIL header pins - handy for one sided connection of everything to a breadboard.

5. Spare tristate buffers in the 74HCT125 allows several Nanodes to be interconnected on a serial bus, controlled by a master unit which is connected to the internet. This feature was developed last August and found that we could get 9600baud serial data down 300m of cable. Simple 4 way telephone cable can be used to string these nodes together.

6. With the ENC28J60 and Magjack omitted, the device becomes a simple serial node - at £5 lower cost.

7. Extra I/O connector allows direct plug-in of R/C servo or Moderndevices LCD display on 3 wire bus.

8. Serial accessed via FTDI cable or similar USB to Serial adaptor.

9. Tall headers will be used to increase the clearance between the shield and the Magjack connector - which is 3mm taller than the USB socket usually found on the Arduino.

10. Programmed through the Arduino IDE (or AVTdude) with access to the standard AVRISP 6 pin header.

BOM (Most specialist items from Cool Components in South London)

ATMega328P-PU - DIP version Cool Components £2.81

Microchip ENC28J60-I/SP - DIP version Cool Components £1.99

74AHC125D tristate quad buffer

3mm LED

1N4004 Diode

7805 Regulator

78L33 Regulator

16 MHz HC49-4H Crystal

25 MHz HC49-4H Crystal

51R 0.25W 1% resistor x 4

270R 0.25W 5% resistor x 5

2K 0.25W 1% resistor x 1

330R 0.25W 1% resistor x 1

10K 0.25W 5% resistor x 3

Ferrite inductor

18pF ceramic cap x 4

100nF ceramic cap x 4

10uF 16V electrolytic cap x 3

28 pin 0.3" DIL socket x 2

RJ45 MagJack £1.99 CoolComponents recommended

36 pin 0.1" SIL header x2

Small Tact switch Cool Components £0.28

ATmega Nanode PCB - that's me!

I have sent off to have batch of 10 boards made up in time for the Hackathon. If anyone would like the EagleCAD files, or purchase a pcb - please drop me a comment.

The Big Dig - Water Main Replacement

2010-12-22T10:39:00.016Z

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

2010-12-20T14:19:00.009Z

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

2010-12-20T12:25:00.015Z

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

2010-12-18T17:39:00.007Z

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

2010-12-17T08:31:00.005Z

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

2010-11-20T12:22:00.017Z

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

2010-11-14T19:24:00.002Z

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!

2010-11-13T17:05:00.002Z

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!

2010-11-12T19:25:00.012Z

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

2010-11-11T18:56:00.013Z

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

2010-11-04T13:55:00.003Z

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

2010-11-02T13:12:00.003Z

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

2010-10-23T12:46:00.010+01:00

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!

2010-10-22T19:19:00.002+01:00

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

2010-10-17T12:18:00.019+01:00

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

2010-10-06T21:23:00.013+01:00

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

2010-09-07T07:45:00.010+01:00

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

2010-09-06T08:39:00.008+01:00

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

2010-09-05T13:01:00.006+01:00

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

Bootloading Arduinos

2010-09-05T11:58:00.006+01:00

What I really love about the Arduino is that it is so accessible and comes with all the utilities to make it work. For example, it takes just minutes for a Newcomer to connect up an Arduino and flash a LED. I think this accessability and ease of use across all the main platforms is one of it's key attractions - and something that other vendors of microcontroller kit have failed to appeciate or capitalise upon.

Once you gain more experience of programming, you can choose to move away from the "safety net" offered by the Arduino IDE, and use the GCC compiler and AVRdude tools directly. However for most simple applications there is no problem just using the Arduino flavour of the C language - provided you don't want to do anything too fast or clever.

One of the nice features is the ability to use an Arduino to program the bootloader into a new IC. Whilst pre-loaded chips are available from a number of suppliers - they charge a premium for these - and if you are making a lot of Arduino based devices - it's much cheaper to program your own - using the easy to use "Burn Bootloader" tool that comes as standard with the Arduino IDE. We used this for the first time on the Snowdonia Mega-Hack Session and found it to be quick and reliable.

Using this utility, I programmed up 10 ATmega328 ICs with the Arduino bootloader in under 30 minutes, and for a cost of about £3.30 per chip (includes VAT and postage from CoolComponents). This saved me approximately £2.90 per chip! CoolComponents are located near Clapham Junction Station and have keen prices on ATmega328s and have a very quick turnaround - 24hrs.

To make use of this Arduino ISP facility, you either have to have 2 Arduino boards, or 1 Arduino and a small breadboard. I used the breadboard method as described in the Arduino Tutorial: Using the Arduino as an ISP

In order to make this device, you need to make up a clock crystal and reset circuit for a ATmega328 on a small breadboard and connect up the Vcc and Gnd pins. Then you use the existing Arduino board and connect Digitals 10 - 13 across to your target '328. This brings across MOSI, MISO, SCK and Digital 10 which is used to reset the target processor. You also need a feed of +5V and 0V from the Arduino board to power your target.

David A. Mellis's programming application also uses 3 other port lines for driving LED indicators. Digital 7 flashes to show that programming is underway, Digital 8 will light up an LED if there is an error and Digital 9 is a Heartbeat to show that the ISP application is running. You don't have to fit these LEDs - but if you are doing this for the first time, it's a good confidence booster that all is well.

During programming the Rx and Tx LEDs on the Arduino board flash rapidly as the serial data is sent from the PC. The LED on digital 13 also flashes quite quickly. At the end of the programming session, the target microcontroller is reset and starts to execute a LED flashing routine on digital 13 - which shows up as a faint slow flash on the programming Arduino LED. This confirms that the bootloader has been programmed and that it is running code. This is a neat feature, as when it comes to use these bootloaded ICs in DIY Arduinos, the LED flashing code will still be present to tell you that the processor is running.

The picture above shows my bootloading breadboard - not the tidiest of layouts, but works fine. There are just 6 wires to connect across from the Arduino, or 7 if you want the Error LED. The breadboard has a 16MHz crystal, two 22pF loading capacitors and a 10K resistor on the reset line. If you are actively building DIY Arduino hardware, you will have all these components to hand anyway!

Now that I'm boodloading my own mega328 chips I think that the cost of a DIY Arduino Slave has dropped to about £4.50 a unit.

Solar Stuff

2010-09-04T18:09:00.002+01:00

Micro-inverters from Enphase Energy

A small inverter fitted directly to the back of the solar pV panel - one per panel.

Performs Maximum Power Point Tracking (MPPT) on a panel by panel basis, leading to higher overall system efficiency and compensating for panels that might be partially shaded.

Enphase also do a neat little display which shows you solar panel and room thermostat data. It would certainly be a good idea to be able to monitor all your household energy systems from a common display. These devices communicate via Powerline Carrier (PLC).

Perhaps it would be possible to "roll your own" display using the 2.8" colour touch screen shield from NuElectronics.

Autumn Almanac

2010-09-04T11:14:00.004+01:00

It's been a short week what with the Bank Holiday Monday, and my new employer's policy of closing the firm at lunchtime on Fridays. With us rapidly moving into the Autumnal month of September, here's a round-up of some of the things I have been inspired with this week.

New Toys.

I've been tinkering with a new Texas Instruments DSP dev-board at work, which will become part of a dc motor control system. I first used TI DSPs back in the late 1980s with the TMS320 series, and wow have they come on in performance since then.

The dev-board is based around their "Delfino" DSP which is a 32bit floating point DSP capable of 150MHz clock speeds. It has 512K of program space, 68K of RAM and 64 general purpose I/O pins - 18 of which can be PWM for driving power stages. It also has 16, 12 bit ADC inputs, which can be run in two banks of 8, for making simultaneous measurements - such as voltage and current, for calculating instantaneous power.

The Delfino is mounted on a small strip of PCB known as a "control card", which brings out 100 pins in a common footprint. This makes it easy to swap control cards for any of the DSPs in the TI range, and ensure functional pin compatability - a neat idea. It removes the user from the difficulties of handling 176 pin ball grid arrays (BGAs), and it means that you can develop your application on one of the larger parts and then move down to a smaller, more cost effective part, later, when the code is finalised.

Putting the processing elements onto a common footprint is a great way of taming what would otherwise be a difficult technology. The raw technology is grouped into a series of manageable ports or interfaces, and the user is presented with a simplified programming model.

On a simpler level, - this is exactly what the Arduino does. It simplifies the microcontroller's interfaces into a series of easily understood pin functions, and presents an extra programming layer into the code which divorces the new user from the complexities of manipulating I/O at a register level. This makes the technology much more accessible to the new user, but at the expense of a speed reduction in I/O operations - compared to direct I/O register manipulation.

When the User becomes more experienced in programming, then the "stabilisers" can be removed. Learning to programme an Arduino in C will hopefully produce a whole new generation of embedded programmers - who have the confidence to get "down and dirty" to the hardware level. This is something that has perhaps been lacking in recent years, as coders generally develop applications in high level languages on sophisticated platforms such as laptops and mobile phones.

Networked Arduinos

A week after the Snowdonia Mega-Hack session, the dust is starting to settle on the networked Arduino project. Trystan has been developing firmware so that he can use the networked slave as part of his solar photovoltaic monitoring system. This was chosen as an example application as something that would illustrate the capabilities of the network slave as a means of monitoring pV panel volts, amps and watts and controlling a battery charging system.

The low cost serially connected slave would make an ideal candidate for a battery monitoring system (BMS). Using optically isolated serial comms, one slave could be applied to each 12V battery, in a larger battery bank or an electric vehicle battery. The low power requirements of each slave would allow it to be powered from the battery it was monitoring - with its I/O referenced to the 0V terminal of each battery.

Data Logging.

Another neat application which has come to light is the OpenLog Data Logger This is an ATmega328 interfaced to a 2Gbyte SD card. It has a simple serial interface, and it just sits an logs all the serial data it sees on its RxI pin. The source code and schematics are all open source, allowing this application to be easily incorporated into some home-made hardware.

One idea would be to use it to record "both sides" of the data on the Arduino serial network. The slaves could be interrogated at regular intervals for stored data, which they transmit to the network, and the OpenLog stores this data away to flash in a large text file. OpenLog comes with a small but neat collection of commands allowing data to be retrieved, files to be appended and erased. This seems like an easy method to get data from the slaves into permanent storage, from where it can be accessed by laptop, sent via ethernet to the web, or whatever.

2Gbytes is a huge amount of storage. Even sending continuous data at 9600baud, it would take more than 25 days to fill the SD card.

Central Storage and Real Time

The Arduino slaves are lacking in vast amounts of local storage. There is 2K of RAM on the ATmega328 microcontroller, and if just over half of that was available for data storage, it could hold about 600, 16 bit readings. Using a store and feed-forward method, the slave could hold say an hour's worth of instantaneous power readings, taken at 6 second intervals and then send the whole file up to the central storage. At 9600baud, this data transfer would take about 4 seconds - easy enough to do once every hour between taking sensor readings.

The problems of limited storage have been with us for much of the last 60 years of computing. Certainly until the late 1980s, memory was an expensive resource, and computer engineers found ways of connecting many users to the one central mainframe and sharing its memory resources between several users.

This is exactly the same situation we have with our network of distributed Arduino slaves - albeit on a very much smaller scale. We have to find a clever way of sharing central resources, such as file storage, realtime clock and ethernet connection between the slaves. By storing the slave data in RAM and then forwarding it to the central SDcard at regular intervals would provide a sensible compromise to storing data, without over-complicating the slaves with their own additional storage. The feed forward model could also be applied to the Master device - collecting data from the slaves storing in SD card and then forwarding this data to a laptop, or web connected server. This would give the Arduino network a degree of autonomy and not reliant on having a PC permanently switched on to service the data.

The NuElectronics Sensor Shield comes with RTC and SDcard for data storage. With a bit of juggling it should be possible to implement the OpenLog firmware onto this shield. The RTC timestamp could be distributed as a CSV packet across the wired network at regular intervals - so that slaves could synchronise their local time to the realtime.

CurrentCost Channels and Pachube Feeds.

One idea, starting to "bubble to the surface" is the concept of having a number of data channels which can be monitored. This is something which the CurrentCost energy monitors have implemented, where originally they had a separate channel for the energy monitored on each of the three phases of an electricity supply. The LCD display would allow basic channel information to be viewed.

The concept was extended to allow data from Individual Applance Monitors (IAMs), to present the energy used by an appliance such as washing machine or fridge to be given their own channel. The CC128 display unit was given a capacity of 10 channels, with the user being able to step between them using a button on the front panel. This approach allows other sensors to be added later to enhance a sensing network - and with the Current Cost DevBoard, enthusiasts can add their own sensors, linking back to the CC128 via their proprietry wireless link. Thanks to @jtonline and @yellowpark for letting me know about the CurrentCost Technical Blog. -in which Chris Dalby, a developer at CurrentCost introduces some of their technology to the Homecamp/Hacker community.

Incidently - for those interested in wireless networks, JeeLabs has introduced a kit for a wireless JeeNode. Its based on the ubiquitous ATmega328 and a wireless transceiver module. It presents 4 identical "ports" to which various sensors or devices can be attached. It's all open source and based on Arduino technology. At 17.50 Euros it seems good value for money, and the wireless module used is the same one which CurrentCost use, which to the experienced coder should open up some possibilites for integrating the two systems.

So if we consider any source of data, such as electricity instantaneous power, or room temperature, or solar panel output could be expressed as a data channel. The CurrentCost display allows basic monitoring of channels using its restricted LCD, but this could be extended to an application running on an O2 Joggler display or a laptop etc. With an application running on a laptop, iPhone or via the web, would give enhanced monitoring options such as historical graphing, comparing channels or using them for further processing or other applications such as Pachube - where several physical channels are combined together as a Pachube feed.

Monitoring your Heating System

2010-09-03T09:36:00.002+01:00

A couple of months back, I had some ideas about Smarter Heating Controls - with the weather turning Autumnal, it's time to start thinking about these ideas again.

Here are a few tips and gizmos to help you put together a DIY boiler and heating monitor

Pipe Clip Thermistor Temperature sensors from Rapid Electronics

The Arduino code needed to linearise a thermistor and display it in degerees C

Wireless actuators for thermostatic radiator valves from Conrad Electronics

Low-cost pulse output water flow meter froom SeeedStudio Depot - these are otherwise stupidly expensive in the UK. Easily read using a pulse input on the Arduino.