More Solar PV Tracking and Wireless Communications

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

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

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!

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

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

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

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

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

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

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?

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?

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

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

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......