Sunday, October 28, 2012
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.
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.
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.
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.
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.
Friday, October 26, 2012
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.
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.
Saturday, October 06, 2012
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.
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.