Low-power wireless communication options

I've written a number of blog posts about wireless communications, primarily 315/433Mhz ASK/OOK modules and 2.4Ghz GFSK modules.  In this article I'll analyze the pros and cons of each.

UHF ASK/OOK modules

ASK modules are the simplest type of communication modules, both in their interface and in their radio coding.  Single-pin operation allows them to be used with a single GPIO pin, or even with a UART.  The 315 and 433Mhz bands can be received by inexpensive RTL-SDR dongles, making antenna testing relatively easy.  At 78c for a pair of modules, they are a very inexpensive option for wireless communications for embedded systems.  The bands are popular for low-bandwidth keyless entry systems, so fob transmitters are widely available for 315 and 433 Mhz.

For a given power output budget, 315Mhz communications has the best range since free-space loss increases with frequency.  Using 433Mhz means about 3dB more attenuation than 315, and 2.5Ghz has about 15dB more attenuation than 433.  The 315 and 433Mhz bands can be used for low-power control and intermittent data in the US and Canada, but in the UK it looks like only the 433Mhz band is available.  Due to the simple radio encoding involving the presence or absence of a carrier frequency, sensitivity is over 100dB.  Superheterodyne receivers have a sensitivity in the -107 to -111 dB range, while super-regenerative receivers have a sensitivity in the -103 to -106 dB range.

The inexpensive super-regenerative receivers may need tuning, though this can be avoided by using the more expensive superheterodyne receivers which use a crystal for a frequency reference.  High-level protocol requirements such CRC or addressing must be handled in software, although libraries such as VirtualWire can greatly simplify this task.

Although the specs on most transmitters indicate an input power requirement between 3.5 and 12V, the modules I have tested will work on lower voltages.  I tested a 433Mhz transmitter module powered by 2xAA NiMH providing 2.6V.  At that voltage, the transmit power was about 9dB lower than when it is powered at 5V.

As David Cook explains in his LoFi project, it is feasible to use CR2032 coin cells to power projects using these modules.  Depending on the MCU power consumption and the frequency of data transmission, even 5 years of operation on a single coin cell is possible.

2.4Ghz modules

I've written a few blog posts before about 2.4Ghz modules, both Nordic's nRF24l01 and Semitek's SE8R01.  The nRF chip has lower power consumption of 13.5mA in receive mode, than the Semitek module which consumes 19.5mA.  Either module can still be powered from a CR2032 coin cell.  When using a 50-100uF capacitor as recommended by TI, capacitor leakage can add to battery drain, so use a higher voltage capacitor, such as 16 or even 50V as these will have lower leakage.

Nordic's chip has lower power consumption, you might not get a real nRF chip when you purchase a module.  Besides higher power consumption, some clones are not compatible with the genuine nRF this can range from completely unable to communicate with nRF modules like the SE8R01, or simply inability to work with the dynamic payload length feature.  With SE8R01 modules selling for only 41c in small quantity, if you don't require compatibility with the genuine nRF protocol, and aren't planning to try bit-banging bluetooth low energy, then these seem to be the best choice.  One other reason to go with genuine nRF modules (if you can find them for a reasonable price) is for range.  At 250kbps, the nRF has a receiver sensitivity of  -94 dBm.  The SE8R01 doesn't have a 250kbps mode, and at both 500kbps and 1mbps the receiver sensitivity is -86 dBm.

Although the power consumption of 2.4Ghz modules is similar to UHF ASK/OOK modules, the higher data rate permits lower average power.  Take for example an periodic transmission consisting of a total of 10 bytes: 1 sync, 3 address, 4 payload data, and 2 CRC bytes.  At 250kbps the radio would be transmitting for only 320uS and needs to be powered another 130uS for tx settling time, making the total less than half a millisecond.  An ASK/OOK module transmitting at 9600kbps would have the radio powered for a little over 8ms.  For a periodic transmission every 10 seconds, and with sleep power consumption of 4uA, the ASK module would consume an average of 21uA, compared to just 5uA for the nRF module.

Conclusion

For low-speed uni-directional data, a UHF ASK/OOK module will work fine, and is the simplest solution.  For reliable bi-directional communication, or for high bandwidth 2.4Ghz modules are the best choice.

PL2303HX 3.3V power output

I've recently read comments about pl2303 USB-TTL serial modules stating that their power output is too low for modules like the esp8266.  Although I've written about the modules before, I didn't check the power output on them.  The datasheet indicates a maximum 3.3V output of 150mA, but it may output more (or less) than that before dropping below 3V.

For testing I tried two different modules.  With no load, one output 3.35V and the other was 3.34V.  With a 13Ohm load, both dropped to 3.15V, which computes to an output current of 242mA.  With a 242mA current causing a 0.2V drop, the output resistance of the regulator is approximately 0.83 Ohms.  This means if you want to push it to its limit, it should be able to output around 420mA before it drops below 3.0V.  Pretty good for modules that sell for under $1 including shipping.

picobootSTK500: an Arduino compatible atmega bootloader in 216 bytes

picoboot was the first bootloader I wrote.  Although it hasn't been beat for size, the fact that it uses a proprietary protocol is a big drawback.  I soon found out that despite Avrdude being open source, there is no open and public process for contributing to it.  So I published a version of avrdude with picoboot support, but since I had emailed Joerg with my patches instead of posting to the avrdude mailing list, support for picoboot in the official avrdude release was not going to happen.

With Arduino Pro Mini boards available from China for only $2, there is no longer a significant cost advantage of using individual DIP AVR MCUs.  Many of these boards come with the stock Arduino bootloader, which is 2KB.  Optiboot was what I flashed to my pro mini boards to replace the stock bootloader.  Since optiboot doesn't wait long after reset for a flash download, and my PL-2303hx USB-TTL modules don't break out the DTR line, I developed a zero-wire auto-reset for the boards.  But since I couldn't get my patch added to avrdude, it would be hard for other people to use it.

My solution was to write a tiny bootloader that, like Optiboot, is compatible with the Arduino bootloader already supported by avrdude.  Like picoboot, I decided to write it in AVR assembler.  Optiboot is small enough to fit into the 512-byte minimum boot size of a mega328, but too big for the 256-byte minimum bootsize of a mega168.  Another design goal was for the bootloader to wait indefinitely, to avoid having to juggle the timing of pressing the reset button and uploading code to flash.  I didn't want to use the watchdog reset the way Optiboot does, since it makes it impossible for application code to detect a watchdog reset.  Lastly, if space allowed, I wanted to support eeprom writing (Optiboot only supports flash writes).

After a few months of on-and-off development, I have a working release.  There's no eeprom write support yet, but at 216 bytes of code, I still have 40 bytes to use for eeprom support and still have it fit in 256 bytes.  Besides being the smallest arduino-compatible bootloader, it has a unique reset-handling functionality.  Pressing the reset button once will go into bootloader mode, waiting with the LED dimly lit.  Pressing the reset button a second time will do a normal reset.  Due to delayed re-enabling of the read-while-write (RWW) section, it should be slightly faster than Optiboot.  Like my original picoboot bootloader, a basic blink program is included with picobootSTK500.

I have included two pre-built versions in the repository; one for the mega328 and another for the mega168.  I only have mega328's for testing, so I'd appreciate someone with a mega168 testing it out and dropping a note in the comments.  Lastly I'd like to thank Optiboot maintainer Bill Westfield for his help.  He is one of those pleasant programmers where his abilities exceed his ego - something I may yet achieve in the future. :-)

USB interfacing for AVR microcontrollers

Since the release of V-USB, dozens of projects have been made that allow an AVR to communicate over USB.  USB data signals are supposed to be in the range of 2.8 to 3.6V, so there are two recommended ways to have an AVR output the correct voltage.  One is to supply the AVR with 3.3V power, and the other is to use 5V power but clip the USB data signal using zener diodes.  Most implementations of V-USB, like USBasp, use the zener diodes.  I'll explain why using a 3.3V supply should be the preferred method.

Pictured above is a capture of D- line on a chinese USBasp, showing one of the 1kHz SE0 idle pulses.  The idle voltage is close to the 2.8V limit because this particular USBasp uses a 2.2K pullup resistor to +5V.  Using a 1.5K pullup as is recommended on the V-USB site puts it closer to 3.2V, which is the high voltage level from the host.

To determine how the signal is read by the AVR, we can look at the ATmega8A input threshold graphs at section 28.8 of the datasheet.

The graph indicates with a 5V supply, any voltage over 2.65V will be read as a logic "1".  The next graph in the datasheet shows any voltage below 2.4V will be read as a logic "0".  Since signals from the host transition between 0 and 3.2V and not 5V, the AVR will interpret low signals as being longer than high signals.  With a fall time of about 115ns, the signal will drop to 2.4V (logic low) in about 29ns.  With a rise time of about 100ns, the signal will rise above 2.65V from 0V in about 83ns.  At 1.5mbps, both high and low bits should last 667ns, but instead a low bit will last 721ns and a high bit will last only 612ns.  This 18% difference in bit times reduces the margin of error V-USB has to work with.

With a 3.3V supply voltage to the AVR, the low signal will last almost 670ns, and the high will last a little more than 663ns, for a timing difference of just under 1%.  Besides significantly improving signal timing, using a 3.3V supply simplifies the USB interface circuit.  Obviously the zener diodes are no longer needed.  Additionally, the 68Ohm resistors which limit the current from the AVR through the zener diodes, are no longer necessary either.

An alternative to using a 3.3V regulator, which is described on the V-USB site, is to use 2 diodes in series to provide a drop of about 1.6V.  My preference is to use a medium-power red LED like the BR5379K, which doubles as a power LED.  At 5mA, the current draw of an ATmega8A running at 12Mhz and 3.6V, the BR5379K has a voltage drop of about 1.65V.  It has a maximum current of 50mA; more than enough to drive something like a nRF24l01+ module in addition to the AVR.

Cheap ODBII bluetooth readers

A couple months ago I bought a ODBII bluetooth reader off Aliexpress for $5.   The product photos showed a mini reader (white), but what I received was a larger black one.  The size wasn't a problem, but the indicator LEDs face down when plugged into a Hyundai Elantra.  The glow of the power light is still visible, so it is still possible to tell it is powered up.

Along with the module, I received a CD with PC software.  Instead of using a laptop, I decided to use Torque Lite on my android phone.  It was a quick install, and after I paired with the ODB interface (code 1234), Torque Light automatically detected it.  If the banner ads in the app bother you, just turn off wifi to stop them from appearing.  Torque Light lets you modify the display, positioning dials and digital gauges as desired.

Torque lets you view and clear fault codes, and as seen in the screen shot above, will show things like acceleration if you phone has an accelerometer.  You can also display speed from your phone's GPS and compare it to the speed reported over ODBII.  The voltage reading might be off slightly; I read 14.42V with my multi-meter vs the 14.5V reported over ODBII.

If you do any amount of work with cars, $5 for a ODBII reader is well worth the money.

Reconditioning NiCd batteries

NiCd batteries are still commonly used in power tools.  When compared to lithium-ion batteries, cost isn't the only reason to prefer NiCd.  A common problem with nickle-based batteries is a drastically reduced number of cycles when they are not properly maintained.

Since I first got my cordless drill (a 14.4V Makita) many years ago, I would keep one battery pack in the drill and one in the charger.  This way I'd always have a fully-charged battery ready to go when I needed it.   Although I'd only use my drill a couple times a month, they'd loose most of their capacity after a few years and need replacing.  Instead of the 500-1000 cycles they're supposed to get, I was getting less than 100 cycles out of them.

My first searches of ways to recondition batteries lead me to blogs and youtube videos of people zapping batteries with high voltage, even using DC welders.  While this might temporarily remove dendrites, it will not restore them to anywhere near their original capacity.

Earlier this year, I found an article on Battery University - How to Restore Nickel-based Batteries.  It explains in great detail how Cadex battery analyzers work, and how they significantly improve the number of cycles obtained from battery packs.  However Cadex battery analyzers cost hundreds to thousands of dollars, too much to spend compared to less than a hundred dollars every few years for a new set of batteries.

The first thing I decided to do is stop keeping a battery on the charger at all times.  NiCd batteries are best stored with a minimal charge.  This would help get more cycles out of new batteries, but it wouldn't recondition my more than year old batteries that were giving me less than half their new capacity.

To exercise the battery packs, I needed to discharge them at 1C until they reached 1V/cell.  For my 14.4V 1.3Ah packs, this means a 1.3A discharge to 12V.  When my packs were discharged, they still had an open-circuit voltage of around 15.5V - a sign of high internal resistance.  A 15 to 20 Ohm, 20W power resistor would be ideal, but I didn't have one on hand.  Rather than order one and wait for it to arrive, I searched through my junk and found an old car speaker with a DC resistance of 13 Ohms; close enough to what I needed.  With a couple of alligator clips I had made a virtually free battery exerciser.

To recondition, I needed to do a "slow discharge" to 0.4V/cell, without a clear definition of "slow discharge".  I think around 0.05C should count as a slow discharge, so a 1W 220 Ohm resistor would be ideal.  I have a red LED with a 1.2K resistor that I use for breadboard projects, so I decided to use that.  I'm not sure if even slower discharge is tangibly better, but it should be at least as good as 0.05C.  And with the LED dimming as the battery pack discharges, I could avoid frequent checking of the voltage with my multi-meter.

The first exercise cycle on each pack took a little more than an hour, and the recondition cycle took 10-12 hours.  After one exercise/recondition cycle I didn't notice much of an improvement.  Three full exercise and recondition cycles seems to have nearly doubled the battery capacity.  Today when I took a dead battery from the drill I tested the open-circuit voltage and it was only 11V.  This means the exercise and recondition cycles have significantly reduced the internal resistance, and since the voltage is already below 1V/cell, I don't have to do the exercise cycle before re-charging it.

SE8R01 2.4Ghz wireless modules

I recently purchased what were advertised as nRF24l01+ modules.  The modules don't have any silk screen marking the pinout, so the first problem was figuring it out.  After a bit of searching I found the pinout for nRF SMD modules, which is the same as the modules with the 8-pin connector except Vcc and Gnd is swapped:

1. Vcc (1.8-3.6V)
2. Gnd
3. CE
4. CSN
5. SCK
6. MOSI
7. MISO
8. IRQ

The next problem was coming up with a way to hook them up to a breadboard.  The castellated pads use a half-pitch (1.27mm) spacing, so you can't solder on standard pin headers and plug the module into a breadboard.  My solution was to solder 24AWG wire from an ethernet cable to the castellations, and in turn plug those wires into a breadboard.

My initial testing of these modules indicated they did not use Nordic nRF24l01+ chips, or chips that are compatible such as the Beken BK2423 or the SiLabs Si24R1.  The most obvious indication that these are not nRF modules iss that the default pipe0 address (register 0A) is 46 20 88 41 70 instead of E7 E7 E7 E7 E7.  They also respond to the bank switch command (0x50, 0x53), which is not supported by the Nordic chip.  I sent a message to the vendor asking for a data sheet, and while I waited I tried to figure out what chip the modules use.

Besides Beken and SiLabs, Hoperf makes a compatible module called the RFM70.  The RFM70 modules have a pinout that starts with Gnd, and they have the same default pipe0 address as the nRF.  The only other chip I could find that is similar to the nRF24l01 was the NST LT8900 or LT8901.  The datasheets for the NST chips didn't match with the register values from my modules.

Surprisingly, less than 24 hours after messaging the seller, I received an attachment containing a datasheet for the Semitek SE8R01.  My initial thought that these would inter-operate with nRF modules simply by changing the pipe0 address was disrupted by the discovery that these modules use a slightly different packet format.  Section 7.3 of the datasheet shows a 2-byte guard after the address field, just like bluetooth EDR uses where it switches from GFSK to DPSK.

If these modules use DPSK after the guard byte, then there is no way they will communicate with genuine nRF modules.  Another less significant source of incompatibility is that these modules don't have a 250kbps mode; instead it has a 500kbps mode along with the 1 and 2-mbps modes.  The 250kbps mode on the nRF24l01+ modules is good for extended range, since it has 9 dBm better sensitivity than 1mbps (-94 vs -85 dBm).  The SE8R01 datasheet indicates -86 dBm sensitivity at both 1mbps and 500kbps, so there would seem to be little reason to use the 500kbps mode.

One benefit to these modules is that they have a received power report in register 09, something the nRF modules don't have.  Although the datasheet documents the bank switch command, and how the currently active bank is reported in the status register 0E, there is no documentation of the bank 1 registers.

I also tested the modules to see if they will support packet sizes over 32 bytes.  The chip seems to accept a payload length of up to 255 bytes, but the read Rx payload command only gives 32 bytes before looping back and repeating the first byte in the payload.

Power

The SE8R01 supports up to 4 dBm of output power, which should allow for better range than the nRF chip which tops out at 0 dBm.  To set the output power to 4 dBm, section 6.5 of the datasheet says to set PA_PWR[3:0] in the RF_SETUP register to 1111.  Power consumption for the Semitek chip at 0 dBm output power is 18.5mA - much worse than the 11.3mA consumed by the nRF chip at 0 dBm output.  The higher power consumption will make it much harder to power these modules with a CR2032 coin cell, since many cheap coin cells start dropping voltage when current output passes 10mA.

Conclusion

At a price of $6 for 10, the SE8R01 modules are 25% cheaper than nRF24l01+ modules selling for $8 for 10.  With nothing more than a couple minor tweaks, they can be controlled using existing nRF24l01 code libraries.  They do not inter-operate with nRF modules, and consume significantly more power, and likely have no better range than is available using the nRF 250kbps mode.  So while the lower price may make them attractive to a volume manufacturer, as a hacker I prefer to stick with the genuine nRF modules.