background to this project is the desire to eliminate wall switches for
lights, and to deal with a situation where a power switchboard would be
difficult to access. The idea is to use a remote control unit to send
commands to a master power switch unit. While the project may appear to
be simple, it is presented here as a means of describing the use of the
HopeRF modules RFM01 and RFM02 that provide a one way FSK RF datalink
in the 434MHz band.
specifications and overall design choices are:
12 digit keypad allowing 10
power lines to be switched, with 2
commands for general use (such as "all power off").
RF link operating in the 434 MHz band (mainly because of ready
access to low cost RF modules).
remote unit is built into a handheld case with 3V battery and
keypad, and uses a 20 pin DIP ATTiny2313 microcontroller
interfacing with a HopeRF RFM02 transmitter module. The
pin AVRs have
insufficient pins. The unit must be able to run at very low power
while not in use.
master unit uses an ATMega48 microcontroller with a
set of 8 electromechanical relays, and interfaces with a HopeRF
RFM01 receiver module.
unit has been in operation for nearly three years and has proven
reliable except that the base station can hang after a short brownout
that doesn't allow a proper reset to occur. A solution to this
would be to use a better external reset circuit. The original
alkaline batteries are still in use in the handsets. All documentation for code and gEDA PCB is available on GitHub. This can be downloaded in zip format.
modules are challenging to use, particularly as it is difficult to
debug the system in a small lab if RF communication has not been
established. Fortunately some developers who used these modules
have generously made their work available (see
giving a base from which to begin.
Hope RF module series consists of:
RFM01, a receiver module possibly based on a chip from Silicon
Labs Inc, namely the IA4320 Universal ISM Band FSK Receiver;
RFM02 transmitter is possibly based on the IA4221 Universal ISM
Band FSK Transmitter;
the RFM12, a transceiver module, is possibly based on the IA4421
Universal ISM Band FSK Transceiver.
for the underlying
readily available on the Internet and should be downloaded since they are
significantly better than the HopeRF versions published as RF01,
RF02 and RF12. Some code for the RF12 has been published by Tomasz
bla Fortuna and Aleksander Mielczarek and possibly others. Code
for the RF01 and RF02, which was critical in being able to complete this project in a reasonable time, has
been published by Wilhelm
Krüg. There is also a good deal of forum discussion, code and tutorials for the
RFM12 transceiver. The RFM01 and RFM02 Rx/Tx pair is not commonly
used and there is little supplementary information available.
microcontroller interface is SPI which is supported in hardware on
most of the AVR microcontrollers. However the RFM01 and
particularly the RFM02 modules do not conform strictly to the SPI
standard. For this reason it is necessary
to ignore the hardware support in the AVRs and use "bit
banging" to operate the SPI interface. This is offensive to
one's aesthetic appreciation of these microcontrollers, but it
simplifies the programming. It also frees up the hardware SPI port
for firmware updating.
overall approach to developing the system was as follows:
the circuit to the point of connecting up the microcontroller for
firmware programming, then to the SPI connection to the RF
the SPI interface using a CRO to verify operation. For the RFM02
transmitter there is very little that comes back from the module.
A status read command may return some information but generally
it's all zeros. The RFM01 receiver returns a more interesting set
of status information. The best test is to set the clock output
on the module (which on power-up is 1MHz) to 10MHz and verify
that it has changed.
up the RFM02 transmitter with parameters that have been
successfully used. The one's I used were those published by
Wilhelm Krüg. Verify that data transmitted over the SPI
interface to the transmitter module looks correct (see below).
Set it to transmit some data in rapid sequence.
up the RFM01 receiver in the same way. The FFIT output and nIRQ
will trigger when the FIFO has reached its preprogrammed limit,
and this can be used to trigger a CRO. This will show if data is
being received in sympathy with the data transmitted. Due to the
asynchronous clocks at both ends it's more difficult to check the
actual received data with a CRO, so some other way needs to be
devised, such as RS232 transmission to a PC or toggling spare
commands sent to the modules are 8 or 16 bit words and use the standard
SPI format. The RFM02 transmitter paces its own transmission of data
bit by bit according to the data rate set in the module. There are two
modes for this. I used the mode in which Tx data is sent over the SPI
interface (which avoids using an extra port). This effectively breaks
the SPI standard so that the SPI features of the microcontroller cannot
be used. To start a data transmission a specific 8 bit command 0xC6 is
sent, but the nSEL line is not lifted at the end of this command as is
normally done to finish off a command. The module then takes over using
nIRQ to signal when each data bit is to be provided. The datasheets are
quite confusing about this process. When the command 0xC6 has been
completed, nIRQ drops to indicate that the first databit is to be
presented on the SDI line. When the bit period has ended, nIRQ rises
for 1.6 microseconds to signal that the next bit is to be presented.
The module transmits the first bit over the RF interface during this
subsequent period. This continues as long as is desired, and is
terminated when the nSEL line is raised by the microcontroller. The
nIRQ is meant to be used as an interrupt to the microcontroller,
circuits (receiver, switch, and transmitter) are reasonably straightforward. The receiver PCB includes a serial to RS232 converter and options to use the Hope RFM12 transceiver module but this is not used in this application. Apart from power
connections, only the SPI lines and nIRQ on the RF modules are
needed. The SDO line doesn't exist on the RFM02 transmitter and status is read
through the nIRQ line. The AVRs have their own internal clock so
the clock output on the modules isn't needed (this turns off when
the module sleeps, which we don't want to happen in this
application). The nIRQ interrupt was also not used as the application is very simple. Only the keypad
interrupt was used to wake the remote unit microcontroller from a
power-down sleep state.
quarter wave whip aerial for the 434MHz band is only about 170mm
long which is simple enough for the receiver. It was still too
long for the handheld remote unit, so a bottom loaded whip was
used and stretched along the length of the case (a loop aerial
wasn't chosen due to its sensitivity to detuning in a hand-held unit). The aerial
434MHz, using wire gauge 0.025" (US wire gauge 22), and with a length
of 0.125m (0.403ft) requires a 0.04uH inductor for a bottom loaded
aerial. A coil 6 turns (0.2" long for 22 gauge wire) and 0.1" diameter
should be adequate. This was wound over a small resistor acting as a
former. This was all very approximate, but the modules have a built in
automatic tuning mechanism which attempts to overcome inaccuracies and
other detuning effects (up to a point). Ironically a longer wire
wrapped around inside the case and without the inductor gave better
RFM modules all have a DIL header with 2mm spacing rather than the more
commonly available 0.1 inch spacing. Rather than attempt to solder
wires to the pins, it is possible (just) to bend the pins to fit onto a
prototyping circuit board with 0.1 inch spaced holes. This gave a solid
anchor for the module on the board. The PCB of course doesn't have this
problem and sockets are available.
keypad circuit for the remote unit uses the design described in
Atmel's application note AVR240: "4 x 4 Keypad - Wake-up on
Keypress". This needs only three 1N914 diodes to provide an
interrupt line to wake the microprocessor from power-down sleep.
The program given here uses INT1 but INT0 could also have been
Remote Unit Firmware
See the Doxygen
documentation. The main
program focuses around a sleep command which is executed when no
key is detected as being pressed on the keypad. Both the module
and the microcontroller are put into power-down sleep which
theoretically pulls about 3 microamps of current, mostly drawn by
the RFM02 module. The measured value was 50 microamps, but this
was at the lower limit of accuracy of the meter. When a keypad
interrupt wakes up the microcontroller, a debounce process waits
for the keypress to stabilize, and a single byte of data is
transmitted representing the numerical keypress value. The program
loops waiting for the key to be released. The data is transmitted
continually while the key is held down.
the data transmission, the writeDataCMD() function starts off the
process by sending the 0xC6 command to the module, and returns
with nSEL still held low. The writeByteTx(n) function paces the
transmission of a byte of data by monitoring the nIRQ line. The
program sends a series of 0xAA bytes for receiver synchronization,
followed by a 2DD4 synchron word needed by the receiver to
indicate the start of the message. Any number of data bytes can
then be sent. The stopDataTx() function lifts the nSEL line to
terminate the transmission, and powers down the module
transmitter. Small timing errors can cause the power-down command to be interpreted as part of the data so there must be a small delay inserted between the last data bit and the power-down command.
Master Unit Firmware
documentation. The program
continually checks for received data, which is indicated by the
FFIT (FIFO trigger) bit in the status word. The FIFO is set to
trigger at 8 bits to allow a single byte to be received. As each
byte is received it is checked for validity and one of 12 counting
bins is incremented. When the number of valid words received
reaches 10, the bins are examined to find the one with the most
number of counts. This provides a simple estimation in the
presence of possible corrupted data.
a valid command has been established the corresponding port is
toggled to allow power switching on or off. A lock is set to
prevent further received data causing the switch to toggle
spuriously. A delay of about 2 seconds, during which no valid data
must be received, is required before the lock is lifted and
further commands may be received.
RF02 receives data by extending the status command beyond the 16
status bits. When the 16 status bits have been read, the first bit
in the FIFO is presented. Further SCK pulses will present
subsequent data bits until the 8 FIFO bits have been read out. The
readDataByte() function reads the status bits and checks the first
bit to determine if FFIT is set. If so, it reads out the 8 data
bits and returns these with the first 8 status bits. Otherwise the
full status word is returned.
the master unit will remain idle for very long time periods, it is
preferable to use the nIRQ pulse to wake up the microcontroller
from a power down sleep when the FIFO is triggered. Once the 2
second delay has been completed, the microcontroller can be
returned to sleep mode. The RFM01 module draws about 10mA. It
doesn't have a sleep command, but all internal circuit blocks
could be turned off, reducing the current drain to about 0.3
microamp. This could be done for short periods of time as the
transmitter continues to transmit the same data as long as the key
is pressed, giving the Rx time to wakeup and receive the signal.
system using the RFM01 and RFM02 modules and ATMega8 by
and RFM02 libraries for Arduino.
on the RFM12 transceiver.
Code and tips for using the RFM12 and RFM12B transceiver
modules by Aleksander Mielczarek.
and advice for the RF12 transceiver Tomasz bla Fortuna.
Library for RFM12B on Arduino.
Original prototype of the receiver board using PMOS switches.
version of the receiver board including the PMOS MOSFET switch and an
converter. The RF module on the left can be either a receiver or
transceiver module with jumpers set appropriately. This board is
intended to double as a bidirectional wireless communications link.
The transmitter board and case.