Detour II: A USB nRF24L01 Radio Modem

Article is currently incomplete and unfinished. Significant progress has been made on the firmware. Its tight on flash, needless to say. The massive bloat of Arduino libraries >= 1.0 makes Arduino >= 1.0 completely useless for development. As such, I've been forced to continue development with Arduino 022 libraries. Likely I'll wind up with some native AVR code, bypassing the Arduino libraries, simply to save space and increase efficiency. But more to come...

Creation Of A Detour
Now that I've decided to focus on nRF24L01 based radios and the driver is fairly feature complete, its time to look at a computer interface for these wonderful radios.

Having an easy to use computer interface for these radios will go a long way toward both making them more accessible as well as make it easier to debug and test application develop. Given the ease of development and inexpensive cost, I expect everyone using these wonderful radio modules will soon have a USB Radio Modem.

The intention is to create a small footprint radio modem which plugs directly into a USB port. Once connected, the modem looks like any other RS232 serial port on the computer. In order to maintain a small footprint, most Arduino solutions are simply too large a bulky. Not to mention their power draw is generally too high because of all the extra components on board. As such, we'll not be using an Arduino for this portion of the build. Rather, we are directly using an AVR uC plus a USB interface and our nRF24 radio module.

The Microcontroller
To find a uC for our project, we need to look one which has enough flash and enough pins to satisfy our physical and software requirements. After some modest testing, I estimated 8K flash is likely to be the minimum requirement for our software footprint.

Next we need to estimate the number of physical pins required for our project. We know we want at least RX, TX, RF24 IRQ, DTR, CTS, DCD, SS, MOSI, MISO, SCK, and LEDs on RX, TX, Power, and/or either an operational mode or DTR state. We know we want at least one hardware a(s)art on the uC. That makes for a minimum signal pin count of 14-I/O pins. When we add GND, power, reset, XTALx2, we have a minimal physical pin count of 19 pins. We also know we want to run at least 16Mhz because of the desired data rate of at least 1Mbps.

This means our minimal requirements are 8K flash and at least 19 pins. After some searching, it looks like the ATmega8-16PU will fit out requirements, including a hardware USART port; providing for RX/TX. But, flash and memory space is tight.

Since estimates indicate we're already tight on flash space, we know we won't have room for an Arduino bootloader. Basically we're looking at a AVR on strip or proto board, which means an inexpensive USBASP interface (or other) is also required for programming. Visiting ebay indicates these can be had very inexpensively for between $2.50 and $5.00. Given this purchase allows us to save so much space and opens the door for so many additional projects, its easily money well spent. I bought mine on ebay for $3.99, delivered to the door. That's hard to argue with considering its built around an ATmega8L, a 12Mhz crystal, and several LEDs. Plus it comes with the interface ribbon cable.

USB Interface
There are several different ways to create this project. One way is to use an AVR uC to directly drive the USB interface via one of several software based AVR-USB libraries. This is fairly inexpensive with a reasonably low component count. Cost for this project is likely to be roughly three to five dollars including the uC. From a frugal perspective it seems like a real win. The down side of the approach is that it requires some very non-Arduino programming which can be rather involved and complex, imposes significant processing overhead and consumes roughly 1.5K of flash of the uC. With the extra software footprint, I don't believe everything will fit on an ATmega8, would would increase the cost of this solution. Also, the associated software skill level is very non-Arduino friendly. This just doesn't sound like a good beginner's path. As such, I don't believe a software USB solution will work so long as an ATMega8 is the target.

An alternate path is to look at USB serial TTL interfaces readily available. Given we want this to look like a logical RS232 serial port and some plans directly depend on making use of some of RS232's signals, we can go shopping on ebay. Technically what we're shopping for are not RS232 ports. Just the same, we do want an interface which provides many of the logical signalling convention.

After shopping for various USB serial TTL interfaces, I quickly focused on the CP2102 variants. More specifically, I found some inexpensive CP2102 based boards which plug directly into a USB port and provide regulated 5v, 3.3v, RX, TX, GND, and CP2102 reset, all broken out to 90-degree pins. Also found are six additional RS232 signals (DTR, DSR, RTS, CTS, DCD, RI), plus two USB suspend signal lines (SPD, SPD/), broken out to through hole solder pads. I bought from hittime_hk on ebay. They were $2.88USD each, including shipping to the door. They look like the following and even come with a small, 5-pin ribbon cable.

The Plan: Pulling It Together
Okay, the plan is to use a CP2102 USB TTL interface board to provide power, ground, and various RS232 logical signals to my ATmega8-16PU microcontroller. The uC in turn will be connected to the nRF24L01(P), as several LEDs, a 16MHz crystal, and several capacitors. The RS232 TTL signals will also be connected to the uC. The Atmega8 is to be programmed via an USBASP interface and AVRdude.

The highest baud rate supported by the CP2102 is 1Mbps. According to the ATmega8 data sheet (page 153), when clocked at 16MHz, it supports an asynchronous 1Mbps data rate with zero errors. This makes it a perfect baud rate match. The catch is, out of the box, the CP2102 doesn't support 1Mbps without creating a baud rate alias. For this, we'll need to either use Silab's CP2102 software to create a baud rate alias or use the cp210x python utility available on Source Forge. After exploring this more, it turns out the python utilities does not support baud rate alias table updates. I've done some work to add this, but its currently a work in progress. So for now, its limited to 115,200 baud.

To allow for proper baud rates, the uC will be statically configured for 1,000,000 baud. On the computer, we will open the serial port at a baud rate of 230,400, which the CP2102 will alias to 1,000,000 Mbps. We pick this baud rate to alias because it provides an error of 3.5% when running the ATmega8 at 16Mhz. As such, its otherwise a poor data rate to use. Furthermore, 115,200 works well so worst case we'll keep that as our fall back and goto data rate until we can get the aliases programmed on the CP2102. Honestly, I'm not sure 16Mhz on the ATMega8 even provides enough headroom to cleanly communicate at 1,000,000 baud.

Since we're running the ATmega8 at 16Mhz, we'll be running this off of the 5v line provided from the CP2102 board.

RF'n Around
The nRF24L01 module is connected via a SPI interface and controlled via the RF24 library. By default, the RF24 library uses a clock divider of 4, which means the SPI interface, given a 16MHz crystal on the ATmega8, will run at 4Mhz. Since the fastest RF data supported by the module is 2Mbs, and our CP2102/AVR interface is limited at 1Mbps, this is plenty fast, even after accounting for all the extra SPI bus traffic used to obtain and configure state from the radio module.

To connect the radio, I'm using standard 0.1" headers, whereby the radio module will simply plug in. This allows for different radio modules to be interchangeably used without additional work. So please, make sure your pin-outs match those used by this project.

Its very important to remember the nRF24 modules require 3.3v and should never be connected to a 5v source. Since the CP2102 TTL module provides a nice 3.3v source, its a match made in heaven. Even better, the nRF24L01 is 5v TTL tolerant, which means, while the module itself must be powered at 3.3v, we can directly connect the data lines from our uC to the nRF24 module without any additional components.

Sleep'n Time
The last part of the puzzle is to make use of the CP2102's USB suspend lines. Most computers dramatically cut power to USB ports when they suspend. To be USB and battery friendly, we'll do the same thing. By monitoring at least one of these signals on our uC, we can both power down the nRF24L01(P) as well as put the uC into a sleep mode, allowing for significant power savings. The end result is we'll be very USB and laptop friendly.

The Modem
The magic of serial port modems is the ability to plug them in, open the associated serial (com) port, and start communicating with the device and/or endpoints connected on the other end of the line. This is exactly what we want here. While not connected through a phone line, we do want to allow for transparent communications with our endpoints.

In days gone by I've had no end of the famous Haye's 'AT' command interface for modems. Personally I'm not a fan. The are cryptic and terse and generally not human friendly anyways. Given the flash size constraints of our ATmega8, implementing a full 'AT' command set is likely to prove too large with little in return. So rather than implement an 'AT' command set, we're going to implement an even more primitive command set - and yes, it uses binary data. Sadly, using binary data makes configuration of the operating mode non-terminal program friendly. But, once configured, the intent it to make it terminal program RX compatible and very friendly. Basically plug in and go, assuming our remote nodes are know at configuration time.

Here's the functions we want to support:

• Set our local address. Think of this as our MAC or hardware address.
• Configure our RF24 channel or frequency.
• Configure the data rate mode of the RF24.
• Turn the RF24 receiver on/off.
• Power radio on/off.
• Configure dynamic or fixed length payloads.
• Configuring transparent operating mode of our modem.
• Configuring RF24 receiver pipeline address (0-5).
• Set Shockburst mode, timeouts, and retries.
• RF24 CRC, off, 1 or 2 bytes
• Store the modem configuration on EEPROM.
• Reset the uC + RF24 module; restarting with saved configuration.
• Scan a frequency

Command mode of the modem always follows DTR state. When DTR is high, the modem enters transparent mode. When DTR is low, the modem enters command mode.

Article is currently incomplete and unfinished. Significant progress has been made on the firmware. Its tight on flash, needless to say. The massive bloat of Arduino libraries >= 1.0 makes Arduino >= 1.0 completely useless for development. As such, I've been forced to continue development with Arduino 022 libraries. Likely I'll wind up with some native AVR code, bypassing the Arduino libraries, simply to save space and increase efficiency. But more to come...


References:
Atmel
ATmega8 Datasheet

Nordic Semiconductor
nRF24L01 Datasheet
nRF24L01+ Datasheet which also the same thing as the nRF24L01P.

Please note the nRF24L01 has been officially obsoleted by the nRF24L01+ variant; which is frequently referred to as the nRF24L01P. Quoting Nordic, "This product is not recommended for new designs. Nordic recommends its drop-in compatible nRF24L01+ or for a System-on-Chip solution the Nordic nRF24LE1 or nRF24LU1+."

Silabs
CP2102 Datasheet
CP2102 Baud Rate Support Datasheet
CP210x Programmer Software

The Arduino Learner's Project - Part II

The Rehash
In my previous blog post I explained the trials of simply starting the project and how I came about to creating my list of high level requirements. The requirements follow. As you can see, some have been crossed out since some purchases have been made.

• microcontroller (uC) with enough ports
• LCD for human interface
• keypad for human interface
• Real Time Clock (RTC)
• power supply (and transformer)
• wireless interface of some type
• method for controlling irrigation solenoids
• humidity & temperature sensor(s)
• moisture sensor(s)
• and eventually a nice case of some type

Since I already had purchased a 16x2 LCD arduino shield and picked my arduino (atmega2560), I had my first three items addressed. Remember, most LCD shields come with micro switches which serve as buttons, allowing for human interaction. And so these items are crossed off our list above.


Sprinkler Basics
Irrigation systems are broken into multiple zones. Each zone is sized based on the water pressure in an area. Each sprinkler head requires a fixed amount of pressure. So given a fixed amount of water pressure, each zone is broken into a given number of heads. Each zone, in turn, is controlled by a valve.

Basically the way a sprinkler controller works is by triggering a relay or triac to open or close a solenoid which opens or closes a valve. The valve in turn allows water to flow into the zone and out the sprinkler heads. Most residential solenoids require roughly 150-300mA of current while in operation. Because of water pressure constraints, normally no more than two valves (one zone) will be open at one time. By extension, no more than two solenoids need be active at one time. Though only one valve need actually be used, commonly two are used in conjunction with each other. The determining factor for one or two is based on your irrigation installation. Typically one solenoid is used per zone and optionally a master solenoid is used at the head of the system. So long as the irrigation system is running, the master value plus another for a specifically enabled zone, is active.

Some irrigation systems do no have a master valve. Others do. For some systems, the master valve is used to not only open a valve, but also to turn on a primary pump (e.g. well water) and/or boost water pump (low water pressure and/or over sized zones). Please keep in mind I'm speaking generalities here. I'm aware there are exceptions. Please verify your own installation requirements before assuming the details here are valid for you system.

As I'm using a relay board, my relay(s) holding current also needs to be added to the sum current required for operation. On my relay board, each relay requires 80mA while in operation. To keep two valves open requires a worst case of (300+300+80+80) 760mA of current. Once we add in the load for the uC, LCD display, radio interface, and inefficiency losses though our regulator, we'll be pretty close to our maximum of 1A. It may turn out I require a larger transformer, but for now, 1A (1000mA) remains my target. Worst case, I already have my eye on a refurbished 1.5A transformer for not a lot of bucks.


The Ultimate Power Source
There are many different directions to look at here but ultimately I decided to re-use the power supply of my existing sprinkler controller. This has the advantage in that it has the power required to directly drive the sprinkler solenoids without incurring additional cost.  This meant I still needed another power supply to drive the microcontroller (uC) side of things. The catch is the transformer's input is 120VAC and output is 1A@26.7VAC. I need 5VDC for my uC, display, and relays. So clearly I need to convert 26.7VAC to 5VDC.

After some asking around, most people pointed me at something like this, which provides for high efficiency switching regulation and minimal part count; which still requires several anti-ripple capacitors. After learning more about AC to DC conversion, I figured out its too small. This is because the peak-to-peak conversion will yield roughly 36VDC after basic rectification. What I really needed was something like this. Which means we just jumped from a $16.25 solution to a $26.50 solution, and I still needed my own front end circuitry to rectify AC into DC. That dog won't hunt as powering the device would become one of the single most expensive components of my build. Heresy I say, as it violates my frugal nature. And so I decided to keep looking. This is when I discovered devices based on the LM7805; switching regulators. That's more like it. After shipping its basically $10. Certainly looks like a good buy and it received a thumbs up from those who previously pointed me at the more expensive counterparts.

I then hit ebay and started looking for LM7805 based solutions. That's when I stumbled on LM2596 switching regulator based solutions. For cheap, roughly $3.00 or less, including shipping, you can get a variable output switching regulator. These typically accept up to 40VDC as input and can output up to 3A, so its perfect; even if I need to upgrade my transformer at a later date. Of course, this still requires rectification on the front end; but so did the higher priced solutions above. The disadvantage of this solution is that its larger. But even that is a little misleading as they all required several capacitors; two minimum, three recommended. The ebay solution has all that already included in its foot print.

If you need a tiny footprint, don't care about cost, or simply don't want to wait on the proverbial slow boat from China (or HK), I'm sure you'll be happy with one of the solutions above. If on the other hand, you're looking for a cheap solution, footprint doesn't matter, or delivery schedule isn't a first order concern, head to ebay. I guess time will tell if it turns out to be a frugal or foolish purchase. Having said that, I did find other frugal hobbyists who have found ample satisfaction with these low cost devices. That said, its not clear they are all equal.

Please note all of these solutions use a switching regulator for DC to DC regulation (often 85%-93% efficient). None of the above are linear regulators. For my project, this is very important as the conversion efficiency is typically much lower for the linear regulators (75%-85% efficient). In my case, would have also required a large heat sink to dissipate the heat from the inefficient conversion. Linear regulators do best when the voltage delta is small. In my case, the voltage difference is relatively very large, which results in a lot of current being converted to heat. Given my voltage spread is ~31 volts, and I only have 1A available on my transformer, and as you can see above we're already tight, I didn't consider it an acceptable loss.


Rectifying The Situation
The last part of our power source is a bridge rectifier. This is an incredibly simple circuit. It can be built with four diodes or as a single integrated package. Basically this converts the sinusoidal wave of AC input into a heavily rippled DC output.

Basically it converts the top sine wave...

...into the rippled DC wave at the bottom. I still have not decided if I'll use a bridge rectifier or make one out of diodes. In the short term I did go ahead and build a diode bridge and tested it. Super simple and easy to make. But having done so, it makes you realize how much of a foot print it requires so I certainly understand and appreciate the appeal of a smaller IC, which serves the same purpose. We'll see.

What we wind up with is a complete power supply for roughly $3.00USD, including some diodes for rectification and even some capacitors, should it turn out they are required.


The Driver
From what I've found and have been told, triacs are more commonly used for commercial controllers. But to keep things simple, I'm using a relay board, which is just a collection of relays on a board. In my case, the board is also optically isolated which means I don't need to worry about 26.7VAC ever jumping into my sensitive 5V circuitry. While triacs are typically lower current draw than relays, in my case, I believe a pre-built relay board just nicely simplifies things.

Relays do have a disadvantage beyond higher current draw, in that they are a mechanical device. As relays are an electromechanical device they do wear out with repeated use. But given the usage patterns associated with an irrigation system, I believe my choice of board will easily provide a lifetime of use. After all, if you water twice per day, three times per week, four months out of the year, you wind up with 96-cycles per year. Even if this is grossly under estimating, these relays should be good for hundreds of thousands of cycles so we should still have a lifetime of use. And even if one does fail, the relays are easy to find online and large enough for someone with bad eyes to replace them as needed.

Speaking for relay failures, should a relay fail in the open condition, since my system does have a master relay, I'm still protected. Basically my system will require the failure of two relays before I need worry about my yard becoming flooded, should it fail in the open position.


Episode Summary
So far we have selected our uC, user interface, and decided how we plan on powering everything. Next we'll start looking at our radio solution which turns into a tangent project in of itself.