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.