SlugBee - Adding Zigbee Radio to a Slug

Introduction

Zigbee, formally IEEE 802.15.4, is another short-range radio standard that uses the 2.4 GHz "microwave oven" band, alongside wireless Ethernet and Bluetooth. Compared to these others, Zigbee is most suited for low-power applications involving simple microcontrollers, for example wireless sensing, home and industrial automation, and so on. Its basic parameters are a data rate of up to 250 kbits/s and a typical range of 50 m.

A small Linux box like the NSLU2 (aka Slug: 266 MHz XScale ARM processor, filesystem on a USB flash drive, takes about 5W, runs Debian GNU/Linux and other distributions) could be useful in a Zigbee deployment. For example, an always-on Slug could be responsible for logging data sent by remote sensors, and generating graphs on web pages, sending email alerts and so on. I decided to have a play.

Building a 2.4 GHz radio from the chips is a bit beyond my soldering ability, so I looked for modules and found five. They're all quite cheap.

• The EasyBee module from RF solutions is a single-chip module with a DIL footprint. It's simple, but the SPI interface would need some work to interface to a Slug. (SPI is like I2C.)
• Eazix have a few two-chip DIL modules where a microcontroller adds higher level of software. They have UART interfaces to the host, so could be connected to a Slug using a USB-to-Serial cable. Communication over the serial channel is mostly transparent (i.e. it's like a wireless serial cable) but uses modem-like "AT" commands to configure the module.
• The MaxStream XBee module is another two-chip DIL module with a UART interface. The serial channel can operate in a transparent mode but also has an API mode where data frames contain commands and data for the module to act on.
• DLP Design have a couple of modules. They both have an RF chip and a microcontroller, and one of them also has a USB interface via an on-board USB-to-Serial chip. The non-USB module has a 20-pin header (unfortunately not as easy to breadboard as a DIL footprint) with UART signals; it also makes a handful of the microcontroller's ADC inputs and digital I/Os available, so in some applications this module could be used as a sensor without an external processor. It offers exclusively an API mode over its serial interface.
• Jennic have a module featuring their own single-chip Zigbee solution. Their chip has a mysterious unnamed 32-bit RISC processor (I'm certain it's OpenRISC; why do they feel that they can't admit to using an open-source processor?) which comes with an 802.15.4 stack and optionally higher Zigbee levels. It has logic-level UART, I2C and SPI interfaces, but I think you would need to add some more code to the microcontroller to communicate with it using them. Breadboarding would be a challenge as it is a surface-mount module, and I can't find any online pricing.

I've used DLP's products before and they are readily available in the UK from FTDI in Glasgow. Since their modules also have the advantages of built-in USB at the host end and processor-less operation at the remote end, I bought a pair.

Using the DLP modules

Here's the USB end, mounted in a little box and ready to connect up to the Slug:

The RF chip is under the screening can on the right; it's tiny. The F-shaped PCB track to the right of the can is the aerial. Above the fixing post in the center is the microcontroller, and to the left of that the USB-to-Serial chip (an FT232) and an EEPROM for the USB configuration data.

The same microcontroller is used at both ends; it's a Freescale (aka Motorola) MC9S08GT60 and reading the microcontroller datasheet alongside the fairly brief DLP documentation is a good idea.

Here's the remote end. It needs a supply of between 2 and 3.4 V; I'm using 3.0 V. Because the 10x2 0.1-inch connector won't plug directly into my breadboard I built a small breakout board, also pictured:

Unfortunately after a few hours of testing the remote end blew itself up, and now behaves like a 5 Ohm resistor across the power supply. I can only guess that either I gave it a static zap, or maybe my bench power supply fried it. I am being extra-careful with the replacement.

The breakout board performs various useful functions:

• It provides a 2.5 V reference voltage for the microcontroller's ADC, using an LM336 reference diode (top right).
• It has 0.1 uF capacitors on the module's ADC inputs. These inputs are not the ideal high-impedence low-capacitance inputs you might hope for; you either need a source impedence of less than 10 kOhms, or a capacitor of at least 0.1 uF.
• It has a pot (bottom left) connected to ADC input 0, for testing.
• It has a link (bottom right) connected to the input that controls the module's periodic wakeup mode, described below.

When plugged in to the Slug the host board appears as a USB serial device, using the FTDI kernel module. Unlike my other Slug FTDI projects where I've bypassed this module and accessed the chip using libftdi, in this case I am treating it as a serial port. The protocol uses a simple packet format with packet length, destination and source node IDs, a one-byte command and a variable-size payload. IDs are 16-bit, so you can have up to 65536 nodes in your network. Packet flow is as follows:

• Some packets are recognised by the host end, for example "set transmit power level", and send a response back over the USB. Other packets are sent over the radio channel to the remote module.
• Of the packets that reach the remote module, some are recognised and responded to by it; for example, "read ADC input".
• Packets that are not recognised by the remote module are sent to its serial interface (which I have not yet used).

Packet transmission is unreliable, so application code needs to cope with failures and retry as appropriate.

I wrote some simple C++ code to send and receive these packets; you can get the source using Subversion or browse online at http://svn.chezphil.org/slugbee/trunk/. It's available under the terms of the GNU GPL. Here's an example using my "slugbee" utility:

$ ./slugbee 
Usage: slugbee <port> <destination> <command> [args...]
  commands are:  ping
                 measureenergy
                 setupadc <channel> <state>
                 readadc  <channel>
                 setiopindir <pin> <1=out, 0=in>
                 readiopin <pin>
                 writeiopin <pin> <val>
                 readeeprom <addr>
                 writeeeprom <addr> <data>
$ ./slugbee /dev/ttyUSB0 2 readadc 1
Sending packet: source: 1  destination: 2  command: ae  data: 1 
Got packet: source: 2  destination: 0  command: ca  data: 0 0

Having got this far I needed something real to apply it to, and decided to monitor the power output from my solar panel.

Solar Monitoring

I have a small solar panel fixed to the wall of my house for experimental purposes, and have been curious to know how its practical power output compares to the nominal 4.8 Watts that its box claims. So I kludged together the awful mess pictured below:

Here is what it does:

• Power comes from 6 V of alkaline batteries on the left. Yes, I know I ought to be harnessing the solar power; maybe later.
• Top left, on a small board a linear regulator provides 3 V for the radio module. Maybe a switch-mode regulator would be more efficient, but at the very low currents that we're talking about here the dominant factor is the quiescent current: an LM317 linear regulator needs about 1.5 mA, while an LM2675 switcher needs about 2.5 mA. The best solution would be to power the module directly from a 3 V battery.
• The radio module is bottm left.
• Bottom right a power darlington (with heatsink) and a power resistor provide a dummy load for the solar panel. An 11 V zenner and 220 Ohm resistor in series with the transistor's base make it behave something like a 12 V battery being charged by the panel. The power resistor is also used to sense the current that is flowing.
• Top, right of center, a power transistor controlled by the radio module switches the power to the rest of the circuit on and off. Except when readings are being taken the analogue circuitry takes no current.
• Top right a MAX681 voltage converter chip (hidden under 4 electrolytics) generates about +/- 10 V from the 6 V battery input; this powers the remaining circuitry.
• A pair of op-amps buffer the sensed panel voltage and the voltage across the 10 Ohm current sense resistor. This is only needed because the op-amp tolerates input voltages being present when its power is off, while the next chip apparently doesn't.
• An AD633 analogue multiplier multiplies the panel voltage by the current. This is suitably scaled and fed to one of the radio module's ADC inputs.
• The voltage-current product is also fed to the digital meter module on the right hand side. One op-amp, two pots and the majority of the resistors are needed to provide this module with a suitable input and reference voltage.

If I didn't want the panel meter I could have made it all a lot simpler by separately measuring the current and voltage and multiplying them in software. I actually have another reason for wanting to compute the analogue power: I want to upgrade to a maximum power point tracker, rather than the dumb load that I have at present, and that will need the power as one of its inputs.

Periodic Logging

One of the best features of the DLP module is that it can be programmed to go into a very low power sleep mode, taking less than 35 uA, and to wake up periodically. This mode is enabled by the jumper on the bottom right of the breakout board. The wake-up interval is programmable. On wake-up it sends a broadcast packet which my Slug logger software waits for.

On receipt of the broadcast packet, the logger sends commands to:

• Turn on the power to the analogue circuitry.
• Wait a short time for the analogue to stablise.
• Read the ADC.
• Power-off the analogue circuitry.
• Go to sleep.

The results are sent to a PostgreSQL database on my webserver (a virtual machine). With the logged results in a database you can do all sorts of dynamic reporting and analysis: you can see some basic graphs on the Solar Log page. The graphs are generated with Ploticus. The source code for the logger can also be found at the address given above.

Do get in touch if you would like to know any more about this project, or if you think I can help with your low-power remote logging and control applications.

© 1998 - 2021