A Brief History of Nanode

                            The first Nanode on a prototyping board controls an RGB lamp

Nanode was conceived back in the summer of 2010, when I returned from a trip to Shenzhen, China. I was between jobs, and had a bit of time on my hands for tinkering with some new product ideas.

Nanode arose out of the need to find a cheaper way of connecting simple open source hardware, such as Arduino to the internet, so that Arduino could be used for a range of sensing and control applications.  

The combination of an Arduino and a low cost ethernet shield came to approximately £35, and from a quick glance at the Arduino and the ethershield showed that not only could the circuit design be produced on one pcb, but produced at considerably lower cost. So with the breadboarded prototype working, I set about producing a pcb version, which using conventional through-hole components and DIL ICs, could be sold as a kit and assembled by anyone with basic soldering skills.

It was anticipated that the kits could be sold for about £20, and so ten prototypes were made to test out the pcb layout.  These first ten Nanode prototype pcbs were produced and sent out to friends and enthusiasts for beta testing and application development.

                                           A pair of Nanode Prototypes - April 2011
                                           
From the outset, Nanode was offered as a DIY kit consisting of the pcb, the ICs and some 50 other  components. Assembly was fairly straightforward - and an online pictorial build guide was produced to make the assembly process as simple as possible - even for those who had had little or no previous soldering experience.

During the summer months of 2011, 550 Nanode kits were produced in the UK on green pcbs and sold out by the end of August. In September, 500 new red pcbs arrived from China changing the appearance of Nanode somewhat.

                                 The popular Nanode 5 on a red pcb. September 2011

Following a review of the design in the Autumn of 2011, it was clear that the addition of a wireless transceiver link would considerably enhance the capabilities of the device. With a RF module onboard, Nanode could "talk" to other hardware devices such as smart sensors, extending the control and monitoring range to several tens of metres from the ethernet router.  RF range tests showed a useful range of better than 125m.

The pcb was updated at the end of October 2011, so that Nanode could benefit from an RFM12 RF transceiver, and thus be compatible with JeeNodes from Jeelabs. In addition to the RF module, an extra 3V3 regulator, a miniUSB socket for power and an extra green LED were added.  There were spare locations on the board to which a 32K SRAM, a real time clock and a microSD card could be added to the underside of the pcb.

                                        Nanode RF on an early prototype green pcb.

Following the success of the first prototype above 500 Nanode RF units were produced in China on a distinctive blue pcb.

The last of these Nanode RF kits sold out at the end of October 2012. So from the humble kit beginnings and just 18 months, almost 2000 Nanodes have been produced so far, with production and kitting happening in the UK, USA and China.

                                     500 Nanode RF kits were produced on blue pcb.

Clearly a replacement to the Nanode RF was needed, and this is where our friends at Wicked Device of Ithaca NY, stepped in.

Wicked Device had become Nanode distributors in the USA, and in 2011 had produced their own versions of the kit and pcb.

Following the requirement for a low cost ethernet gateway product for the Air Quality Egg project,  Dirk Swart and Vic Aprea at Wicked Device redesigned the Nanode RF so that it utilised surface mount components, and could be mass produced on a pick and place machine. So it's my pleasure to introduce the new Nanode Gateway, the first of the Nanode SMT units, which is being produced at Wicked Device's premises in upstate New York. These units will be available through the Nanode Shop from early November.

The new Nanode Gateway produced by Wicked Device provides a platform for the creative development of web connected devices, and with the use of low power RF, extends this connectivity well beyond the reach of normal WiFi devices.

Nanode Gateway uses low power 433MHz or 868MHz wireless to form a bidirectional link between the internet and remote sensors.  Within the home and garden environment the Gateway has a range exceeding 100m. It is available with or without a radio module, which can easily be added later.

The Nanode Gateway allows you to connect sensor networks – for example environmental or weather sensors, to the internet for web based data logging and visualisation. The bidirectional wireless link allows the remote control of devices using relays or actuators providing the means for web controlled home automation.

Now it is possible to connect sensors all around your home and garden back to the internet, and control external devices using a web browser interface.

• Combines Ethernet and low power 433MHz or 868MHz wireless connectivity on an Arduino compatible platform.

• Provides a gateway for low power wireless devices to connect to the internet – with a range exceeding 100m.

• Wireless link allows monitoring and control of remote sensors and devices

• Open Source Hardware and Open Wireless Protocol used throughout.

• ATmega328 microcontroller programmed using Arduino IDE

• Supports up to 30 slave sensors or devices

• Low cost, and expandable using Arduino like shields

• Used in the Air Quality Egg and Open Energy Monitor Projects

• A building block of the Internet of Things

• Manufactured in the USA by Wicked Device.

Nanode on a breadboard - an exercise in minimalism

                                                        Nanode on a breadboard

The original Nanode was conceived as an exercise in minimalism, starting with the question "What is the least hardware needed to allow an electronic device to interact with the internet".

In the summer of 2010, I experimented with a simple design built onto a prototyping breadboard, and a few months later, in the spring of 2011, this crude prototype matured into the first pcb version of Nanode.

Yesterday, I had a bit of a tidy up around my work room, and I came across the original breadboard Nanode, so for a bit of a challenge, and some hindsight, I wondered if I could make the design even simpler.

At a very basic level, the Nanode consists of an Atmel AVR microcontroller and a Microchip ethernet controller. This combination was originally selected because they are both available in DIL packages and are thus easy to prototype with on a breadboard. Added to these ICs are the ethernet connector or magjack, a couple of crystals and a handful of passive components.

The ENC28J60 ethernet controller is a 3V3 device, and by running the micro at 3V3, the design can be significantly simplified.  With the micro running at 16MHz, the design draws about 165mA at 3V3.

Four connections are needed between the ENC28J60, which make up the SPI bus.  These are the MOSI and MISO data lines, the serial clock SCK and a chip select line.  Additionally the ENC28J60 should be reset from a common reset line shared with the microcontroller.

With this connection between the microcontroller and the ethernet controller, the micro has 6 analogue input lines and 8 digital I/O lines available for the user's application.

The ATmega328, ENC28J60 and ethernet magjack breakout board are all available from CoolComponents if you wish to build something similar at minimum cost.


Software Functionality

The key to the functionality of the Nanode is it's ability to operate as a simple web client, connected via the internet and communicate with a cloud based server.

As a bare minimum, the Nanode should be able to post a packet of data to the server application,  and request a packet of data back.  The outward going packet would usually contain data from analogue sensors and the return packet often contains command and control data.

In this context the server application is likened to a mailbox, where mail between two parties can be transferred via a suitable secure box, maintained by a third party.

In the case of Nanode, we are using a server application provides by the likes of emonCMS or Cosm, where in addition to simple handling of data, the server also runs data visualisation, arithmetical processing and data manipulation applications.  Having all this processing grunt available in the server, means that the code running on the microcontroller can be minimal.

As a simple example, I have the Nanode measuring outside and room temperatures using low cost thermistors connected to the analogue input channels. These temperature readings are posted up to emonCMS where the data can be graphed and visualised.

The digital output lines are connected to six LEDs, four of which also have a simple R-2R resistor ladder network connected, which makes a simple digital to analogue converter. This could be used for driving an analogue output - such as varying the brightness of an LED lamp.

Upgrading a Nanode to a ATmega1284 microcontroller

One of the problems encountered with Nanode, or Arduino is that sooner or later you come up against the physical limitations of the ATmega328.

With 32K of flash and 2K of RAM, the '328 is great for small projects - but when you start to do anything that uses a lot of RAM - such as lots of string handling, the 2K limit is quickly exhausted - and strange things start to happen in your code.

So this week, my challenge was to familiarise myself with the ATmega1284, and assess whether it might be a suitable upgrade for some of my projects.

Earlier in the week, I looked at using the real time clock and SD card on the Nanode RF to make a 4 channel real time datalogger, and it was whilst developing this code, that the RAM limitations of the '328 really started to cause problems.

Fortunately, there is a fairly simple upgrade to the '328, and this is the ATmega1284P.  In a 40 pin DIP package it makes prototyping on breadboard easy, and with 16K of RAM, and 128K of flash it gives plenty of space for developing larger applications.

In addition to the extra RAM and Flash, it also has two more analogue input lines, a second UART, an extra INT pin, an option for a 32KHz crystal and 8 more I/O lines.

The I/O ports are arranged almost symmetrically around the 40 pin DIP, making the circuit layout very straightforward.  For reference, the ATmega1284P summary datasheet is here.

An ATmega1284 on a breadboard

The first thing to do was to build a minimum system on a breadboard consisting of the microcontroller, the 16MHz crystal, the reset circuit and a FTDI programming connector.

Above is the simple breadboard layout, with the crystal, 22pF capacitors and reset circuit at the bottom centre of the picture and the FTDI compatible programming connector at the top right of the breadboard.  This is the simplest possible circuit configuration (using 16MHz external crystal and remote RESET), and it leaves all the other remaining pins as I/O.

To begin to use this microcontroller, it first has to be bootloaded with an Arduino IDE compatible bootloader, and the files which describe it's registers and physical pinout have to be incorporated into the Arduino IDE.  To do this, I followed Maniacbug's excellent tutorial, and it wasn't long before I was up and running simply Blinky code on the ATmega1284.

The almost symmetrical layout of the I/O ports makes of a logical arrangement of functions.  There are four 8-bit ports Port A, Port B, Port C, and Port D. Unlike the ATmega328, there is no need to devote port pins to the 16MHz crystal or reset pin - so all 32 lines are available - compared to just 20 on the '328.   Additionally, there are 8 analogue input pins on Port A, and these do not share the I2C functions - as on the '328, so if you need more analogue inputs and I2C, the '1284 offers an extra bonus.

To make the '1284 compatible with the Arduino IDE, it needs to have it's physical port pins mapped  to the Arduino pin numbering system.  There are many unique ways in which this could be done, but I personally would prefer to have a pin-mapping that is similar to the Arduino '328 - so the likes of RX, TX, INT0, INT1 are given their familiar Dig 0, Dig 1, Dig 2 Dig 3 numbering, and the SPI bus appears on the familiar Dig 10 - Dig 13 pins. This way you can remember what is where  - without having to tie your mind in mental knots trying to port sketches and libraries from the '328 to the '1284.

The Ports

Port A is the analogue input port.  It appears on pins 40 down to 33 on the IC, with the related (and  useful) AREF, GND and AVCC on the adjacent pins 32,31 and 30.  It makes sense to bring all of these analogue pins out to a common connector. The order of A0 - A7 may appear in reverse to the Arduino user.  This is not a problem as the pin mapping file can be used to reverse the order in which these pins are named. Unline the 10-bit ADC in the '328 - this ADC has an input stage with selectable gain of x1, x10 and x200, and can be used both single- ended or differentially. The high gain stage makes direct reading of thermocouples a possibility.

Pins 1 to 8 of the package are home to Port B, the upper half  B4 - B7  has the hardware SPI lines present.  As Nanode uses three SPI connected devices on board, it would be neat to cluster the chip select lines for these devices on the same port - so provisionally allocating Port B0 - Port B5 as CS lines seems sensible.

Port D is located on pins 14 to 21 of the package.  It has our familiar pin functions like RX, TX INT0 and INT1, as well as four consecutive PWM pins on Port D4 - Port D7. If six pwm lines are required - for example driving 3 phase bridge circuits, there are a further pair of pwm channels on Port B3 and B4. There is a second UART available on Port D2 and Port D3 - if the INT0 and INT1 functions are not needed.

Port C runs along pins 22 to 29.  First are the I2C pins SCL and SDA on package pins 22 and 23.  These are useful for reading devices such as the real time clock on the Nanode.  The ATmega1284P is also provided with a JTAG port on pins 24 to 27.  If JTAG programming/debug is not needed, then these form a useful additional 4 general purpose I/O lines - but if you need JTAG, be careful what hardware you connect to them, which may interfere with the JTAG operation.  You may have to disable the JTAG function in the fuse settings if you want these lines for general use.

The ATmega1284P has a second on chip oscillator - designed to work with a 32768Hz watch crystal - or other 32KHz input.  These crystal pins are on pins 28 and 29.  If you use a watch crystal to implement an RTC - it is possible to wake the microcontroller from sleep at regular intervals, whilst otherwise keeping it in low power mode.

In addition to the rich peripheral set accessed by the ports, the ATmega1284P also has an additional 16 bit timer, and 4K of E2 non-volatile memory.

Connecting it up to a Nanode.

Having made up the simple breadboard, it was time to connect it up to a Nanode.

Most of the Nanode ICs are connected to the microcontroller using the SPI bus, and so the MOSI, MISO, SCK and any chip select lines would be needed.  The RTC clock/calendar IC on the Nanode uses the I2C bus, so SCL and SDA would be needed too. Finally the Nanode board would need to be powered, and provide a reset so +5V, 0V and RESET were wired back to the breadboard.

During tests it was found that the ATmega1284 would run at 3V3, but not program successfully at 3V3. It was therefore decided to run the '1284 at 5V, and use potential divider resistors on all the output lines between the '1284 and the Nanode RF board where almost all of the hardware runs on a 3V3 supply i.e. the ENC28J60, the RFM12 and the SDcard.

Dividers were thus needed on MOSI, SCK, and the three chip selects ENC28J60_CS, RFM12_CS and SDcard_CS.  The RTC connected to the I2C bus is 5V tolerant and so no divider was needed.

In the top photograph, the lower breadboard made from clear plastic has these potential divider resistors  - and some diagnostic LEDs.  The Nanode Rf with the '328 microcontroller removed is on the right.

The next blog post in this series will have links to code developed to run the Nanode RF using the ATmega1284.

Casting the net further

About 3 years ago, whilst working for a central London energy monitor company, a co-worker asked me whether it would be possible to come up with a device which would allow her to switch off electrical equipment in her home remotely using the internet. I thought about the problem for a while and finally cobbled together a solution that used a Microchip  dev.Net board, a repurposed wireless remote socket and a couple of PIC microcontrollers.

It was a real lash up, but it proved the point that the internet could be usefully used to remotely control simple devices - provided that it could extend it's capabilities beyond the router and the CAT 5 cable, using a low power wireless link. With wireless, it is possible to set up a zone of connectivity around the ethernet to wireless gateway, and any wireless compatible device brought into this zone would benefit from 2 way connectivity to the net.

This proved to be a powerful technique, and the advent of affordable open source hardware based around the ATmega328 microcontroller and the RFM12 low power transceiver allowed users to experiment with wireless sensor networks for remote sensing and home automation. The great thing is that this hardware is now available from a variety of sources, and shares RF compatibility - allowing you to mix and match devices from various supplers.

Further experimentation in the Autumn of 2009, led to the desire to produce an affordable internet gateway, and some work was done using hacked about energy monitors and the ethernet equipped Microchip PIC 18F67J60. Our out of hours development work led to "once per second"  power readings being sent up to a web based visualisation system in December 2009. Some of these ideas ultimately went on to be incorporated into the Nanode project during its design phase in March 2011.

This summer, I have spent the last 6 weeks visiting a variety of weekend events, including OggCamp 2012 in Liverpool, EMFCamp in Milton Keynes, the Brighton Mini Makerfaire and just theis last weekend OSHCamp in Hebden Bridge, Yorkshire.  Seldom a weekend at home it has been a good opportunity to catch up with the open hardware scene - and realise that the whole world has gone Raspberry Pi mad.

It was in the open fields of EMFCamp that I decided to do a range check on the RFM12 wireless transceiver. Using a couple of devices fitted with 868MHz  modules, I was able to wander around the campsite with my laptop and prove that the open field range of the RFM12 was better that 250m.  In a built up suburban enviroonment this translates to about half this distance - a similar test done in my street got me 130m from home before packet reception became unreliable.

The emonCMS server has become a central part of the remote control and monitoring system. It allows data  from sensors to be datalogged and visualised, whilst at the same time permitting commands and data to be sent back to control wireless nodes.

If we think of a node as a microcontroller with a RFM12 attached, there could be a standard set-up page on the server  which allows you to define the pin functions and allocate those to various input devices - analogue and pulse sensors, and output devices, such as relays, pwm drives etc.

It is our intention to publish the command structure - we are still looking at the best way to send both commands and data back to individually addressed wireless nodes.

There is also the issue of privacy/security.  It's good to be able to see other people's public feeds, but if my gas boiler is connected to a relay on a wireless node, it would be foolish and unsafe to give everyone access to that device.

One way of handling this is with the use of apikeys that are generated when you first register an account on the server.  

The simplest node could just be an Arduino with RFM12 shield or JeeNode, or even a stripboard Arduino with an RFM12 module mounted. Nathan Chantrell cleverly shows how to do this in his blog post

http://nathan.chantrell.net/20111229/temptx-v2-wireless-temperature-sensor-module/ 

Nathan has gone on to produce similar designs with the ATtiny - if you want minimalism, and the ATmega1284 - if you want more I/O and much more RAM.  For most people, the ATmega328 is a good compromise, offering 6 analogue inputs and 7 digital I/O, once the RFM12 has been connected to the SPI bus and interrupt line.

The introduction of the new surface mount, ready assembled Nanode RF, this Autumn, will allow easier access to the project for those who don't wish to solder a kit, and with the Sketchgarden remote bootloader and emonCMS server, it should be even easier for people to get up and running quickly.

There is now Nanode compatible hardware from JeeLabs, OpenEnergyMonitor and just recently harizanov.com - with a very small ATtiny based node http://harizanov.com/2012/09/super-funky/

With a lot of people purchasing Raspberry Pi's, it seems logical to use this device as a local server running a version of emonCMS, and already some experimental RFM12 boards have been made that plug into the PI's   I/O connector.

http://harizanov.com/2012/09/interfacing-funky-to-raspberry-pi/

We believe that the combination of simple open source hardware based on 8 bit microcontrollers fitted with a low power wireless link is a powerful tool for extending the internet into the field of remote control and monitoring.  Nanode is committed to continue to produce low cost hardware to develop this further.

Ultimately we should like to see Nanode gateway products priced between £20 and £25, and simple ATtiny based wireless sensing nodes starting at around £10.  Continued use of DIL and through-hole designs suitable for the DIY/home assemby market, will be complemented by ready assembled SMT devices.

Using Nanode RF and emonCMS for Remote Control and Monitoring

For the last couple of years I have been looking at simple low cost methods of measuring analogue data - such as that from temperature or humidity sensors placed around the house and getting that data up to a cloud based server for datalogging and visualisation.

With the introduction of the Nanode RF last September, and working cooperatively with Trystan Lea and Glyn Hudson of openenergymonitor.org, we have managed to send data from a variety of wireless sensors to   their emonCMS server.  Trystan and Glyn developed this platform mainly for logging and visualising electricity data - both consumption and generation from PV,  but the versatile open source server can be applied to a wide variety of monitoring and control tasks.

A typical system consists of one or more wireless sensors, which collect analogue or pulse data and send this  wirelessly to the Nanode RF - which acts as a basestation.  Nanode RF runs a multinode sketch, which allows it to receive data from any wireless sensors that are in range.  These sensors have a node ID from 1 to 30 and can be arranged into different groups.  Provided that the sensors don't all try to transmit at once, and a certain time randomness should be included into their transmission slots, the Nanode RF receivers their individual data and posts it up to the emonCMS platform - where it can be manipulated, graphed and visualised.

As well as electricity data, emonCMS has been used for heat-pump monitoring and bee hive temperature monitoring.

Now a little documented feature of emonCMS is that the last posted value of a feed can be requested by the Nanode RF. This feed value can generally be a 16-bit integer - for easy interpretation by the Nanode, and with suitable decoding can be used to control the hardware either on the Nanode RF, or any of the wireless nodes connected to it.

It is a relatively simple matter to create a web dashboard which contains switches and rotary controls - allowing different parameters to be sent to the Nanode RF, or any of it's connected nodes.  A simple example would be a RGB LED lamp, connected to pwm pins on the Nanode controlled remotely from sliders or knobs on the dashboard.

Trystan's code for reading a feed value is here on GitHub. - example g in the Guide.

An extension to this is to get the Nanode RF to send the feed value as an RF packet out to the wireless nodes. A simple hack was done using one of Trystan's graphical LCD display units which feature a pair of bicolour LEDS.  Sending a feed value of 0,1,2 or 3 allows you to remotely control the colour of the LEDs from the server - and because we are using the RFM12 - the distance between the base station and the wireless node can be quite large - better than 200m in open field conditions or 100m or so in a built up street.

If you want to experiment with this you just need to put the following line of text into your browser's URL window

http://emoncms.org/api/post?apikey=8795903a6c0611123007be8abef16e60&json=power:1

By changing the value of power from 0 to 3, this causes the colour of the  LEDs on my emonGLCD to change.  You can send me feedback on Twitter @monsonite - I'm going to get a proper control dashboard set out, but for the moment it proves the point.

More complex controls, for individually accessing the I/O pins of remote RF nodes could readily be devised, allowing each such node to be accessed from it's Node ID.  The read apikey ensures that your feeds are safe and cannot be tampered with - without having the apikey, the correct password and username.

This system makes it very simple to incorporate the monitoring and logging of room temperatures - from RF nodes - including WiNode, JeeNode - and the new very small, ATTiny84A based Funky,  another RFM12B compatible node. At the same time, relay outputs connected to these nodes could be used to turn on central heating, open or close radiator valves, or switch on or off electrical appliances - all from the web accessible platform - using laptop or even an app running on a smart phone.

In the 18 months that Nanode has been around, it has gone from strength to strength, and is now appearing in various compatible versions from new suppliers. The latest is the Micro IoT Gateway from Harizanov.com. This will make a great RF gateway, but just needs a RFM12 fitted to make it compatible with Nanode, Openenergymonitor and JeeNodes.

Watch out for an important announcement regarding an exciting Nanode new product towards the end of next week.

Building an end to end wireless sensor network

Building Wireless Sensing Networks - using Open Hardware.

Over the last couple of days, I have been busy setting up a wireless sensor network as part of the preparations in readiness for a web controlled central heating and energy monitor system.

The various hardware modules are all open source designs - and I chose to use a mix and match approach to the system which was put together using hardware from a variety of vendors.  Compatible devices were used from JeeLabs, Openenergymonitor and Nanode Ltd.

If you haven't looked recently, there are now new offerings of ethernet gateways, wireless sensor nodes and open data services from a number of providers - the smart wireless sensor arena is starting to get interesting.

Here's a brief description of what is needed. A fuller report will appear in a later post.

There are four main parts to the system:

1.   The Wireless Node or WiNode. Supplied by Nanode Ltd.

This is the system's analogue sensor, with 4 channels of 10 bit ADC.  WiNode can interface to a range of analogue inputs, such as thermistors for temperature sensing, current sensors or optoreflective sensors for detecting motion or occupancy  or even reading the dial on the gas meter. Additionally there are 4 channels of high current pwm driver which can be used to control relays, solenoids, dc motors etc. WiNode can be powered from a 5V USB type supply, or from a 9V-12V unregulated dc supply. Typically WiNode reads its analogue inputs every 5 to 10 seconds and sends that data wirelessly to the display and the ethernet gateway.

Whilst WiNodes can be bought from Nanode Ltd - for around £30, there are other compatible sensors such as the JeeNode available from JeeLabs and emonTX - an electricity monitor available from Openenergymonitor.  The JeeNode was the first device to combine the ATmega328 and the RFM12B - and  through Jean-Claude Wippler's RFM12 code library, wireless communication between devices has been made very simple to implement.  The JeeNode is the "barebones" wireless node - and this is reflected in the price - just 18.50 Euros - from the Jeelabs Shop.

Alternativley, if you are feeling keen, the basic microcontroller and RF module used on WiNode can be hand assembled on stripboard for about £10.  Here Nathan Chantrell shows  temperature sensors based on both the ATmega328 and a temperature sensing node based on the ATtiny. 

2. The second part of the system is the Ethernet Gateway. This is supplied by Nanode Ltd - and is known as the Nanode RF.

The gateway combines the microcontroller and wireless transceiver with an ethernet controller - in this case the ENC28J60.  The on board micro runs a simple client, which receives the data packets from the sensor nodes, and pushes them up to the web based server.

As well as pushing data up to the server, the Nanode RF makes the occasional request for server time. Once it receives the packet containing server time - it makes it available to the emonGLCD so that real time can be displayed. The time packet could be sent to all nodes in the system to synchronise their time - as WiNode has an on-board real time clock, which could be occasionally be reset to server time.

The basestation is supplied by openenergymonitor as emonBase, or you can buy it directly from Nanode Ltd as the Nanode RF for about £30.

3. The third part of the system is a local graphic LCD display from openenergymonitor.org.

This display allows you to monitor the wireless data from the sensors, and also can be used as a user interface. It has it's own temperature and light sensors, and two Red/Green LEDS which can be used to indicate physical conditions - such as too hot, too cold - or for energy monitoring applications high load and low load. In addition, the display has 3 user configurable push buttons - which can be used for screen and menu item selection.

Whilst primarily a display module, the emonGLCD also sends regular temperature readings up to the server, and also has it's on screen clock regularly updated by time requests to the server.

This display is obtainable from openenergymonitor.org as a DIY kit, emonGLCD for approximately £50.

4. The final piece of the "end to end" system is the cloud based application software running on a web server.  This program receives the raw data from the Ethernet Gateway, and allows it to be processed and visualised by the remote server. The very nice chaps at Openenergymonitor have written a very comprehensive server, data logger, visualiser, and analysis package called emonCMS.

Here is a screenshot from Nathan Chantrell - who has been using emonCMS for energy and temperature monitoring.

It just takes a few minutes to log in to emonCMS, obtain an api key and start to record and graph data from the sensor network. emonCMS was originally intended for energy monitoring, but it is versatile enough to manage a range of different data feed types and has a wide variety of data manipulation, graphing, visualisation and dashboard controls.

Building Blocks for Wireless Sensor Networks

"Smart wireless sensor networks will bring about improvements to the quality of life, allow greater interaction  with everyday systems and lead to energy savings and better efficiency". Well - that sounds like quite a tall order, but if you care to look back over the last five or six years, and have witnessed the rapid growth in this area of technology, you will surely agree that wireless technology is now thoroughly embedded in many aspects of our daily lives.

What has brought about this quiet revolution has been the availability of low cost wireless hardware and innovative design. Wireless technology has very much become an area of innovation within the open source community, and the availability of low cost open hardware for experimentation has greatly assisted in putting smart sensors into the hands of the amateur enthusiast, hacker or maker.

One of the most innovative proponents of low cost wireless hardware undoubtedly is Jean Claude Wippler of JeeLabs. Over the last 4 years, jcw has blogged tirelessly about wireless networks, physical computing and ultra low power sensor networks. Not only has jcw had new and fresh material almost o a daily basis, but this material has been a living lab-book of all his experimentation and product development. jcw returns to his blog at the start of September after his summer break - and if you haven't got him on your list of "must read" now would be a good time to start.

jcw's main innovation was to come up with the combination of a low cost microcontroller grafter to an equally low cost wireless transceiver module.  By making the microcontroller the same as the one used by the Arduino community and writing a code library to support the wireless operation , this ensured a rapid and large uptake by the DIY market.   However, through the JeeLabs shop, this hardware was made available at less than 20 Euros, putting it well within the budget of the hacker and maker community.

Not only has jcw produced a fine platform on which to base wireless sensor designs, but he also single handedly has developed almost every possible add-on widget to enhance the basic sensor.  The JeeLabs shop is an Aladin's cave of low cost pcbs and kits - both in conventional through hole construction and in size reduced SMT format.

JeeLabs has inspired others to contribute to the community, and there are a number of open hardware designs based around the JeeNode core.  Energy monitors, internet gateways, sensor/actuators, tiny format sensors, graphic displays have all arisen from the original work by jcw.

For all the reasons above, I would like to show my respect and appreciation for all the work done by jcw in furthering the open hardware community.

A Small Success 

For anyone working with open hardware, there is always that great feeling when stuff comes together - and just works.

The latest example, is my recently acquired emonGLCD from openenergymonitor - as it's name suggests, a graphical LCD.  This display however has at it's heart an ATmega328 microcontroller connected to the ubiquitous RFM12B wireless transceiver - so it's an Arduino compatible wireless graphical display. How cool is that?

Well, actually, it's very cool, because the GLCD can provide a big, bold display of wireless sensor data, and it can also communicate with a web connected basestation and display text, data, messages -  even graphs from the internet.

So this evening's task was to build up the GLCD kit and get it to display data from my WiNode wireless sensor.

The build to just under an hour, and about another half hour to gather together all the various code libraries scattered around the web to breathe life into it and get a working display.  Assembly was very easy - assisted with the excellent pictorial and video build guide.

A few modifications to the emonTx (energy monitor) code - so that it worked correctly on the WiNode hardware, was all that it took to get the system up and running.

Tomorrow I will endeavour to get the emonBase  (aka Nanode RF)  to communicate with the system  and get some of the sensor data up to a remote server.

Central Heating  - Revisited

One of the areas in which wireless sensor networks have already made a visible impact, is that of energy monitoring, and there are numerous commercial products available for electricity monitoring, as well as some from the open hardware community.

However, whilst an electricity monitor may help you to shave your electricity bill by a few pounds a year - the area in which smart sensors could really make a difference is in the control of the domestic central heating system.

Here in the UK, where natural gas prices are always on the rise, and we are more reliant on overseas gas, almost every UK gas heated property is using a heating control system that fundamentally has not changed in effectiveness since the 1960s.  Most homes are still reliant on a time clock, a poorly located bi-metal thermostat and a couple of motorised valves - at the helm of controlling their greatest energy consuming appliance - the gas central heating boiler.

There are several key places where wireless sensors - and actuators could make an impact on the average domestic heating system.

Firstly - a better thermostat - one that is actually located in the room you wish to control the temperature of! So many houses had their thermostats located in the hallway - that draughty wasted space between the front door and the stairs. With a wireless thermostat, you have one which can be located in the room you are sitting in, and if the thermostat is a display unit like GLCD - then you can have instant feedback on the room temperature.

Radiators located in unoccupied rooms should be shut off, or at least to a minimum, when the room is not occupied. Clearly we don't want the risk of the room being freezing, but if the radiator is fitted with a thermostatic valve, we have the means of individually controlling when that radiator comes on, and to what temperature it heats the room.

By monitoring one a room by room basis, how the house responds to changes in external temperature it should be possible to construct a model of how much heat is needed to keep the various living areas comfortable.

Now that we are approaching the end of August, and with the "heating season" only about a month away, the aim is to put in place and prove, the main elements of an end to end web based smart heating control system.  By better informing the occupants, and finer control of the boiler and radiators, a saving of energy should be possible.

The WiNodes will be used for room temperature and water temperature sensing - and the high current pwm outputs can be used to drive power resistors - used to close down thermostatic radiator valves when not needed. The GLCD will be the user interface - located in the living room, - easy to get at, simple, intuitive and not buried at the back of some airing cupboard.

Gas Meter Monitoring

If you can measure it - you can control it

Most of us haven't got a clue of how much gas we use in a typical day - and how this can vary wildly with outside temperature.

With simple monitoring it is possible to obtain fine grained reading of the gas meter consumption.  I am fortunate that my meter has a reflective patch in the centre of the end zero digit - so I can use an opto reflective sensor to monitor when a unit of 10 litres of gas has been consumed.

With a better knowledge of when gas is being consumed, and how this relates to central heating, water heating and cooking activities will allow these activities to be better co-ordinated with lifestyles. For example if hot water is needed for a morning shower, then this tank heat up period should be incorporated into the morning heating period - when the boiler is already up to temperature and can take the extra load of the hot water coil, without loss of efficiency.

If a bath is required in the evening - then the heating controller should have a bath button - which heats the tank sufficiently for the bath or baths to be taken - and informs the user of when the bath will be ready.

WiNode - a technical summary

WiNode is the first standalone wireless sensor device from Nanode Ltd.  It is aimed at wireless sensing and control applications, and has a number of features not found on other devices. WiNode can form part of smart wireless sensor networks and be used in conjunction with a Wireless - Ethernet gateway such as Nanode RF.

Main Features

ATmega328 with RFM12B wireless transceiver operating at 433MHz or 868MHz

Motor driver IC for driving 2 dc motors, 4 relays or even a loudspeaker. Accessible via screw terminals.

4 general purpose analogue inputs with voltage scaling networks. Accessible via screw terminals.

Could be used for current transformers or opto-reflective pulse counters (gas meter).

microSD card – for datalogging or file storage. Can be used to store audio files for playback via loudspeaker.

32K battery backed SRAM – retains data during a power outage

Real Time Clock and Calendar with alarm wake-up function

At the core of Winode is the combination of the Atmel ATmega328 microcontroller and the Hope RF RFM12B wireless module. This is a tried and tested pair, used in designs by JeeLabs and Open Energy Monitor.  The code library to support the RFM12 is that written for the Jeenode – so ensuring 100% compatibility.

The new WiNode 4.0 design corrects a number of shortfalls in the earlier version and offers a compact yet versatile platform for wireless sensor application development.

WiNode is built on a compact 58mm x 66mm (2.3” x 2.6”) pcb, and retains the Arduino style shield connectors, allowing expansion by means of Arduino shields. However 100% compatibility cannot be guaranteed as WiNode uses several of the digital I/O pins for its own purposes. However for those wishing to add circuitry to WiNode, a prototyping shield on extended pin headers works well.

WiNode offers several additional hardware functions, not generally found on other Arduino-like platforms. These offer a range of functions considered to be useful to typical wireless sensor, actuator and control applications.

External Connections

Along the right hand edge of the pcb is a strip of 10 screw terminals.  This is where most of the interfacing to sensors and actuators would be made using simple wired connections.  These screw terminals offer four analogue inputs and four high current (2A max) motor or relay drivers.

Motor Drives

The WiNode has an on-board dual H-bridge motor driver – which can be driven with PWM for driving inductive loads such as motors relays, solenoids and even loudspeakers for audio applications.  Up to four relays, two reversing small dc motors or one stepper motor can be connected to these outputs.  The motor drive outputs are marked M1 – M4 on the underside of the pcb.  The motor drive channels are Digital 5, Digital 6, Digital 10 and Digital 11 – however restrictions apply on D 10 and D11 when accessing devices on the SPI bus.

Relays and solenoids can be driven, allowing the possibility of using WiNode for applications such as a wireless central heating controller, garden irrigation system, or solar PV monitoring system.  The dc motor outputs, used in conjunction with analogue inputs would allow WiNode to form the basis of a two-axis PV tracking controller – using dc motors for drive and potentiometers to read off the position.

Analogue Inputs

The analogue inputs are fitted with 10K input resistors, and a choice of potential divider resistor array.  Using the 4K7 array provided allows voltages up to 10.32V to be measured – or almost exactly 10mV per ADC count.  Fitting a 3.3K resistor array allows up to 13.3V to be read – making WiNode compatible with 12V battery systems.  The choice of this resistor array is left to the individual user, if the array is omitted, the analogue inputs will have a full scale of 3.3V – as WiNode operates at 3V3. The analogue input terminals are marked AI0 – AI3 on the underside of the pcb.  Analogue inputs AI0 and  AI1 have 160Hz low pass filters fitted (10K and 100nF) to reduce noise and transients. These may be omitted if not needed or if fast ADC sampling is required.

Power Supply

The screw terminals also provide connection to the power supply. This allows a dc supply of up to 12V to be connected.  If operating at 12V, the 7805 voltage regulator should be fitted with a heatsink – as should the 754410 motor driver IC. The external voltage input is marked Vin and 0V on the underside of the pcb.

If an unregulated external dc power supply is not desired, WiNode may be powered from a nominal 5V supply (eg USB) via pins 1 (0V) and 3 (+5V) of the 6 pin FTDI header. This supply is further regulated down to 3V3 to power the whole pcb – so WiNode could be powered from a small solar panel with a nominal 5V  250mA output.

Real Time Clock

WiNode is fitted with a Microchip MCP79411 real time clock/calendar.  This is a small 8 pin surface mount package soldered to the underside of the pcb.   The MCP79411 also contains an EEprom area where non volatile data such as Node ID, MAC address etc could be stored.  The MCP79411 also has an “alarm” output which can be used to generate a wake up interrupt or regular square wave output – interrupting the microcontroller on Digital input 3.  The WiNode pcb also allows a DIP version of the Dallas/Maxim DS1307 RTC to be fitted as an alternative to the MCP79411.  The RTC is battery backed by a 0.22F supercapacitor.

32K External SRAM

This is a static RAM connected to the microcontroller via the SPI bus.  It can be chip selected using Digital output 8.  The supercapacitor provides battery backup for this device.  The SRAM can be used for applications requiring temporary storage of moderate amounts of data, such as an audio sampling buffer (4 seconds of audio at 8kHz sampling frequency), or for short term datalogging.  The SRAM can also be used for program storage if the WiNode is programmed using Arduino TinyBASIC. Library routines to make the most of this external SRAM are currently under development.

Micro SD card

For applications requiring datalogging, or accessing files, a microSD socket has been included on the underside of the pcb.  One recent application of WiNode was as a programmable sound generator, where audio files were stored in the SD card, and played back through a loudspeaker, driven by one half of the motor driver H-bridge IC. If this option is desired, then additional 10uF electrolytic capacitors and 1 ohm resistors should be fitted to provide low pass filtering of the audio output.

Unfortunately, due to hardware restrictions, motor output 3 is not available when writing data to the SD card.

Summary of I/O Usage on WiNode 4

Dig 0  Serial Rx  to FTDI header

Dig 1  Serial Tx  to FTDI header

Dig 2  Interrupt from RFM12 wireless transceiver

Dig 3  Interrupt from RTC square wave or alarm wakeup

Dig 4  microSD chip select

Dig 5  PWM_2 output (M2) from motor drive IC

Dig 6  PWM_1 output (M1) from motor drive IC  - Green LED

Dig 7  Enable line for motor drive IC – held normally low to inhibit drive.

Dig 8  Chip select line for 32K SRAM

Dig 9  Unused

Dig 10  Chip select line for RFM12B wireless transceiver – also motor PWM_4 (M4)

Dig 11  MOSI signal for SPI bus  – also motor PWM_3  (M3)

Dig 12  MISO signal for SPI bus

Dig 13  SCLK signal for SPI bus

AN0   Analogue input 0 (filtered)

AN1   Analogue input 1 (filtered)

AN2   Analogue input 2

AN3   Analogue input 3

AN4   I2C data (SDA) for Real Time Clock

AN5   I2C clock (SCL) for Real Time Clock

Wireless Sensor Networks - a review of devices

Photo:  the emonGLCD by openenergymonitor.org

The second part of a post reviewing what is available to the hobbyist in terms of open source hardware for wireless sensing networks.  This time I look at a series of kits that are compatible with the JeeNode from JeeLabs.

One of the key design challenges with any modern electronic device is the age-old problem of how do you get the power in and the data out?  A bi-directional low power wireless link solves the second of these problems, and innovative use of low power electronics, rechargeable batteries and possibly a tiny solar PV panel solves the first.

So with a low power microcontroller and a short range wireless transceiver you have the basis of a smart wireless node – which can be used for a variety of sensing on control applications.  The ability for it to communicate with web connected devices – via the wireless to Ethernet bridge opens up a vast number of possibilities for remote sensing and control. With the availability of open data services – such as Open Energy Monitor and Cosm, there is an easy route to get sensor data up to Cloud based servers from where it can be processed, graphed or mapped using appropriate data manipulation tools.

Having decided in principle upon a simple Ethernet to Wireless bridge, then comes the task of supporting a range of diverse wireless nodes. Range tests have shown that the RFM12 has a useful range of 100m in the household environment, opening up a whole host of possibilities for wireless energy monitoring, central heating control, solar pV monitoring or other wireless gadgets that just need to get a few bytes of data up to a central server.

Through suppliers such as JeeLabs, Open Energy Monitor, Wicked Device and Nanode Ltd there are starting to become available a wide range of compatible wireless devices aimed at low cost wireless sensing and control applications. These devices all use the RFM12 library code as developed by JeeLabs for the JeeNode, and generally devices from different vendors may be mixed and matched.

A short summary of some of the devices.

JeeNode

The original wireless node by Jean Claude Wippler of JeeLabs.  A simple combination of an ATmega328 microcontroller and RFM12B wireless transceiver on a small pcb.  JeeNode utilises the concept of 4 identical ports into which a wide variety of functional modules can be plugged to extend the basic system.  For full details see the comprehensive JeeLabs site.

emonTx

A development of the basic JeeNode, designed specifically for electricity monitoring applications.  It has 3 current transformer interfaces, and voltage, pulse and temperature inputs. emonTx forms the basis of the Open Energy Monitor – see OEM website for more information.  

emonGLCD

One  useful kit, is the emonGLCD wireless graphical display from Open Energy Monitor. This consists of a 128 x 64 pixel graphic LCD with an ATmega328 and the Hope RFM12 wireless transceiver. Whilst originally designed to display data from the energy monitor, the GLCD may be used to display any data – either that generated locally, or generated from a web based application.  The versatile GLCD has three user push buttons “Up”, “Down” and “Enter” allowing the user to select items or parameters from a menu an modify them, or select particular modes. My first intended application for the GLCD is as a user interface for a smart central heating controller.

In addition to the user push buttons, the GLCD has a LED backlight, a bicolour LED to show for example the status, and a LDR light sensor.  The LDR may be used to determine whether it is day or night, or whether the room lights are on – suggesting that the room is occupied.  To complete the usefulness of the device, an on board 18B20 temperature sensor allows the room temperature to be measured, allowing the GLCD to be used immediately for smart thermostat applications.  As with all the wireless devices offered by Open Energy Monitor, the GLCD is firmware compatible with JeeNodes, Nanode RF and WiNode.

WiNode

WiNode is the first standalone wireless sensor device from Nanode Ltd.  It is aimed at wireless sensing and control applications, and has a number of features not found on other devices.

1.  Motor driver IC for driving 2 motors, 4 relays or even a loudspeaker. Accessible via screw terminals.

2.  4 general purpose analogue inputs with voltage scaling networks. Accessible via screw terminals. Could be used for current transformers or opto-reflective pulse counters (gas meter)

3.  microSD card – for datalogging or file storage. Can be used to store audio files for playback via loudspeaker

4.  32K battery backed SRAM – retain data during a power outage

5.  Real Time Clock and Calendar with alarm wake-up function.

Air Quality Egg - by Wicked Device

This is a new development this year from our friends at Wicked Device and Sensemakers/Cosm.

Photo: Wicked Device.

On the right is the new Nanode RF SMT - by Wicked Device.  This is a much updated and improved version of the Nanode RF manufactured almost exclusively using SMT components.  The Nanode RF includes a 433MHz low power wireless transceiver and ENC28J60 ethernet controller.  Plug in headers allow Arduino type shields to be added to extend the system.

On the left is a stripped down Nanode RF - fitted with the Air Quality Egg sensor shield - a series of plug in gas sensors to allow measurements of typical air pollutants to me measured and sent up to a open data server - provide by Cosm.

Building Bridges

The advantage of having 2 weeks off to relax in a Somerset farm holiday cottage is that I now have time for blogging and new design work. The downside is that there is no internet at the cottage - so I am forced to come down to the village pub every lunchtime to deal with emails and online activities. The burden of this chore is lightened by the selection of good ales at the Horse and Jockey, Binegar, Somerset.

One of the key components in any smart sensor network is the bridge or gateway that allows the sensors to reliably exchange their data packets with the internet. The bridge needs to be robust and reliable in operation to make sure that packets are communicated efficiently with the remote server, and as such the bridge needs to run a tight service routine, and not get distracted by servicing local I/O.

Having made this realisation, it has become evident that a new Nanode device is required, one that acts solely as an Ethernet to RF bridge.  Nanode took the early decision to use the RFM12 wireless transceiver for all sensor communications – thus retaining firmware compatibility with Jeenodes, the Open Energy Monitor and the Air Quality Egg projects.

So following Oggcamp, and a discussion with Trystan of OEM, the idea of a dedicated Nanode RF Bridge was conceived, and this has now been added to the fold of Nanode designs. It is based on Nanode RF, but strips off all the unnecessary functionality, leaving just a bare bones Ethernet to RFM12 interface consisting of just 35 components.  The functionality can be reduced in general terms to the Magjack, the Ethernet controller, the microcontroller and the wireless module. Since there is no desire to interface with local I/O, there is no need to retain Arduino shield compatibility, and so the pcb can be shrunk down to just 42mm x 72 mm – giving a considerable reduction in PCB costs. A 26 pin (2 x 13 pin) connector at one end of the board allows I/O, serial port, ICSP to be accessed – but when used as a dedicated bridge, this is less likely to be used.

The ATmega328, as used in almost all Arduino compatible devices is restricted by just 2K of SRAM.  This limits the maximum number of wireless devices that the Bridge can effectively service.  If we allocate just 1K of RAM on the Bridge to service say 32 wireless devices, then each device has an entitlement of just 32 bytes for its “outbox”- the data packets being posted up to the server.

As well as node to Bridge communications, there will be applications that require node to node exchanges.  For example a node acting as a room thermostat may need to have its data acted upon by the heating control system, without going through the remote server.  Additionally, any wireless graphical display will want to monitor local nodes, and display data from them, as well as data that has been sent back from the server. Managing these local communications requires a fair degree of sophistication within the firmware.  

By removing the unnecessary hardware, the design is considerably simplified and cost reduced. In fact the Bridge has an intended selling price of just £20, which allows bundling with a WiNode and a programming cable for £50.

Oggcamp 12 - The open movement goes from strength to strength

Oggcamp12 is the fourth meetup of the Oggcamp unconference, this time held in Liverpool at the John Moore University School of Design.

Trystan Lea of Open Energy Monitor and I, travelled there together from Trystan’s house in rural Snowdonia, where I had overnighted after driving up from London.

Liverpool and the North West has a strong tech community, as anyone coming up from the South East will soon learn and appreciate. Trystan and I had previously attended the Liverpool BarCamp held last November at doesLiverpool, so it was good to meet up with old and new friends, from the Merseyside tech community.

As an event, Oggcamp12 was sold out, with 400 or so people packing the main auditorium for the opening talk.  Following on from the unconference format, there were two additional presentation rooms for parallel sessions, and new for this year, an open hardware jam gathering on the third floor.

Each year, Oggcamp attracts new followers and new presentations, and it was good to see the extent and mix of the talks being offered.  For anyone attending Oggcamp each year, it is a great opportunity to meet up with friends from previous gatherings, and catch up on what is happening generally in the open community. It’s not just Linux and open software, over the 4 years it has spread out to include open hardware, the Maker community, and a platform for presenting some of the wider thinkings of the open tech community.

There is so much going on at Oggcamp, so everbody comes away from Oggcamp with their own ideas and memories of what they saw and did.  I found it particularly difficult to choose between some of the excellent talks running in the parallel sessions, and so probably missed a lot of good material – including Stephen Fry’s video link-up presentation – doh! However, I did get to see most of Alan O’Donohoe’s (@teknoteacher) most inspirational talk on getting kids to code in schools, and a fascinating talk on the workings of the Enigma Machine.

The official hotel for Oggcamp was the Adelphi near Lime St. Station, but I missed out on the special deal and ended up in a satisfactory B&B in a very run-down neighbourhood to the north of the city centre.  A £5 cab ride to the city centre on the Saturday night, allowed us to pig-out on pizza before going on to the Adelphi for the evening of entertainment.  It was held in a large function room in the basement of the Adelphi, whilst at least 2 or 3 weddings were happening a floor above in the main hotel spaces.  You can tell a good scouse wedding – when at least 2 cop vans and an ambulance turn up at 11pm.  Musical entertainment was by @methoddan and his band, and this invoked some wonderful freestyle dancing, amongst the otherwise reticent geek community.  My only gripe about the evening was that the beer was either off, or crap (Tetley’s Extra) and the bar staff were a bit sullen. I stuck to bottled Bulmers cider all evening, apart from the point when I accidently ordered a Tetley’s, thinking “how bad can it be...?”

Sunday proceedings started around 11am, and having rather ignored the hardware workshop on the Saturday, I thought I’d better make the most of it on Sunday. Last year, the hardware consisted of just 3 offerings, myself with Nanode, some guys with a 3D printer and another lonely hardware guy.  This year about a dozen different organisations pitched up, and we had offerings including Textile repurposing and computer controlled embroidery,  doesLiverpool with Bubbilino, 3D printing, Raspberry Pi, Howduino with breadboard Arduinos and Fignition – a DIY Forth computer kit based on the ATmega328.

My contribution this year was a talk on the Saturday afternoon about the Nanode project plus some examples of projects where Nanode had been used in the last year – including the Malet St Gardens Sound Sculpture by Public Interventions, and the Air Quality Egg.

This was followed up on Sunday with a hardware workshop session where I built up one of the new WiNode kits, as used in the Malet St arts project, proved the wireless range from the 3^rd floor workshop to the far corner of the JMU grounds (about 100m), and rigged up a Sharp motion and distance sensor so that those readings could be sent up to the Open Energy Monitor server.

OggCamp has become an annual phenomenon, and is growing from strength to strength. It offers an informal  forum for the open tech community, allowing community networking, presentations and entertainment all washed down with lots of beer and music.  Oggcamp doesn’t take itself too seriously, it’s just a bit of fun for those who don’t get out much.

Thanks to all the Oggcamp organising committee, and the Crew for all their hard work over the last 12 months, and this weekend, for putting on such an inspiring event. – see you all in 2013!