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.