In this note I explain how to use the modules for establishing a communication with a remote temperature sensor and displaying its readings on a computer screen. The used temperature sensor is the one that is built into the microcontroller (μC) MSP430F2553. The supplied custom code is very small and simple and can be used in various wireless projects.
The radio modules A110LR09x are based on Texas Instruments CC110L transceiver chip, which is capable to work in the 315/433/868/915 MHz bands depending on the passive elements. The radio module already has all needed elements on board including a 27-MHz crystal. The module having the suffix A in its specification is equipped with integrated PCB antenna, while the one with C suffix utilizes an external antenna through a U.FL connector. The dimensions of the larger module with antenna on board is only 9×16×2 mm.
Anaren also manufactures AIR BoosterPack wireless transceiver extension kits for use with the Texas Instruments MSP-EXP430G2 LaunchPad development kit. The BoosterPack kit includes 2 boards with mounted A110LR09A radio module with integrated antenna and operates in the European 868-870MHz and US 902-928MHz ISM bands. For my experiments I purchased one BoosterPack kit and also purchased separately two LaunchPad kits. This note explains how to to set up the modules for a Peer-2-Peer (P2P) communication. The BoosterPack and LaunchPad modules are designed to be connected together in a sandwich-like manner. The right image shows how the radio module A110LR09A is connected to the MSP430F2553 microcontroller from the LaunchPad kit. Both BoosterPack+LaunchPad sets have identical schematics but differ in the microcontroller code. One of the pairs is intended for transmitting the data, while the other one is for receiving the data and communication with a computer.
| BoosterPack | Schematic | |
So, what is expected from a battery-powered radio module working with, say, temperature sensor? Besides of reliable communication, probably one of the most important parameters is low power consumption. However, in the transmit mode with maximum output power +11 dbm the module draws about 34 mA. The current consumption in the receive mode is approximately 15 mA. It becomes apparent that no reasonable battery would last long if the module is on for considerable periods of time. Therefore, to save the power one should keep the module in a power down mode (with 200 nA current consumption) as long as possible and turn it on for a short time only. As it is well known, to establish a reliable radio communication one needs special protocols involving packet acknowledgments and packet re-transmittions. I will show how to organize a simplest P2P communication that does not involve packet acknowledgments. In many cases this approach can lead to acceptable results in terms of reliability and provides a smallest power consumption on the transmitter site, which is our main concern here. In general, the transceiver CC110L is supported by TI's Open Source protocol stack SimpliciTI, and Anaren offers an adoption of this protocol to A110LR09x radio modules. After really long time of digging their codes and analyzing their work with LaunchPad's in-circuit debugger I realized that for my application it would be much simpler to encode everything from scratch.
Therefore, in my case the transmitter is turned on for a very short time of sending a single package to a permanently on base station. The base station is supposed to be powered from mains or a rechargeable battery, so the power consumption is not that critical. The A110LR09A supports several modulation modes and bit rates up to 500 kbps. The higher bit rate leads to a shorter transmission time, hence to a lower average power consumption. However, higher bit rate affects the receiver sensitivity, so we need a compromise. I choose 100 kpbs speed and 2-FSK (BFSK) modulation. This way the transmitting time of a packet with an 8-bytes payload is about 1.5 msec, including the transmission of preamble, sync word, and two CRC bytes. In case of packet transmission period of 5 sec, the average power consumption is about 10 μA, so the 2xAAA batteries powering the transmitter should last for several years. The low current consumption makes it possible to power the transmitter even from solar cells.
The radio module A110LR09A provides hardware implementation of MAC+PHY layers and hardware support for packet handling. The module configuration consists of setting the values for its 47 internal registers. In order to simplify configuration of these registers, TI developed a freely distributed system SmartRF Studio. The Studio provides a graphical interface and allows to test various configuration settings. It connects directly to the CC110L chip via a SPI interface and CC Debugger, available from TI's EStore. The left image below shows the main SmartRF Studio window in action. The transmitter is programmed for sending test packets. The negative numbers in the last column of the bottom window is the signal RSSI level. The transmitting spectrum was controller with TI MSP-SA430-SUB1GHZ spectrum analyzer. The right image shows the spectrum of our module configuration when the transmitter sends the preamble bits. For a compliance with FCC/IC regulations I use 902.299 carrier frequency and other module parameters recommended by Anaren. The two peaks on the oscillogram correspond to the frequencies of transmitting zeros and ones in the 2-FSK modulation, and the vertical line in the middle between them marks the carrier frequency.
| SmartRF Studio | Spectrum | |
As it is mentioned above, the A110LR09A radio module provides hardware support for packet handling. The typical packet structure, borrowed from CC110L data-sheet, is shown below. The packet starts with two areas composed by the transmitter automatically: the preamble and the sync word. Without diving into details I just mention that the sync word is software configurable and could be used for packet selection. After those two fields the packet must include one byte with packet length which should not exceed the transmitter FIFO size (64 bytes). The field following the packet length is the (optional) receiver address. This address can be used for automatic packet drop by a mismatch between the receiver ID and the field value. This option can be disabled, in which case including the address into the packet is not required. Of course, longer receiver/transmitter addresses can be used as a part of packet payload. The payload completes with two CRC bytes that the transmitter and the receiver compute automatically. The option of transmitting CRC can be disabled in configuration. However, a mismatch between the transmitted and received CRC can be used for automatic packet drop from FIFO. This option can also be disabled in the configuration. Here I very briefly mentioned just a few configuration options. For more details the readers are forwarded to the CC110L data-sheet available from the ti.com website.
As it follows from the schematic, besides the SPI interface pins the A110LR09A radio module also has two control pins GDO2 and GDO0. In the supplied software those pins are configured for interrupt requests cased by state changes of the FSM controlling the module. Most of the time the module spends in the power-down mode, from which it is awakened by falling edges on the CS pin. The internal module FSM has 22 states. Simplified sequence of module operations by transmitting a packet is as follows. After waking up from sleep the module starts its crystal oscillator and the PLL system for generating the carrier frequency and other frequencies. This process takes about 150 μsec, after which the pin GDO2 is driven low and the module enters the IDLE state. Only then the module is ready for SPI communication and can be moved into the transmit or receive state or accept loading data into the TX FIFO. In our code we just load the data. Due to a configuration setting the module performs frequency calibration prior every packet transmission, which takes about 750 μsec. As soon as the transmission of the preamble and the sync word is completed, the signal at pin GDO0 becomes logic one and an interrupt is requested. The ISR serving this interrupt configures the microcontroller for waiting a falling edge on this pin, which signals to completion of transmitting of the entire packet and the CRC bytes. After that the module automatically enters the IDLE state, from which it is sent by software to the power-down state with ultra-low power consumption.
The information part length of our packets is 8 bytes including the length byte. Right after the packet length the receiver ID (0x11) is included. The receiver is set to drop the packet by a mismatch of this field with 0x11. The next packet field is the transmitter ID (0xAA), which is not used in the current software version. It is reserved for receiving the data from multiple sensors in the future. The next byte is the packet number which is increased by sender modulo 256. This byte is currently not used and is reserved for a possible extension of the software for sending acknowledgments. The last 4 bytes carry the information from sensors. The first two of them are used for sending the temperature, while the last two ones are for humidity (not used in the supplied software).
Therefore, the code structure is as follows. After the ports initialization the code sets the oscillator frequency (8 MHz), tunes eUSCI_B0 module for SPI with 4 MHz, tunes the ADC for the temperature measurements with built-in temp sensor. Finally, Timer_A0 is configured for providing a μC wake-up event every 5 seconds for measuring the temperature and sending it out. This Timer is clocked from VLO at 12 KHz which can work in μC LPM3 sleep mode. In this mode the circuit draws about 0.6 μA. The current consumption was measured at VCC contacts of jumper set J3 (for the measurement the corresponding jumper must be temporarily removed).
The supplied μC code "sensor.s43" is written in assembly language and is intended for compilation with IAR Embedded Workbench, Kickstart edition. The project can be loaded into the IDE by clicking on file sensor.eww. Note that one should remove both J5 jumpers on LaunchPad (shown in the bottom green circle below). These jumpers connect μC pins with LEDs on board, but the same pins are used for communication with the radio module. Position of jumpers J3 shown in the upper green circle for the sender board is not important.
| Jumpers |
The LaunchPad board is equipped with USB-UART converter which creates a virtual COM port upon inserting the USB plug into the computer (provided that the LaunchPad driver is installed). One can connect RX and TX lines of the COM port to the μC by using software or hardware UART. We use hardware UART, so the jumpers J3 should be placed in HW UART position, as it is shown in the top circle above. Also, make sure to open both J5 jumpers as on the transmitter board by a similar reason.
Furthermore, if you use Windows7, you will need to download a terminal program. I recommend Parallax Serial Terminal that can be freely downloaded from the parallax.com web site. Its screenshot is shown below. One should check the option "Wrap text to Pane". Another good choice for a terminal program is Putty. In this case one should check the option "Implicit LF in every CR" in its Terminal settings. Each of these programs consists of a single file and requires no any special installation. Just load the file on your Desktop and you are ready to go. In order to connect the terminal program with LaunchPad, one should configure it for using the LaunchPad virtual COM port that Windows opened. This COM port number can be obtained from Windows Device Manager. Moreover, the terminal program must be configured for COM port speed 9600 bps with 8N1 options (8-bit data with one stop bit and no parity checking). Upon loading the project "hub" into the μC and starting it, every 5 seconds a new line in the terminal window will appear (it is assumed that the transmitter on the other BoosterPack board is on).
The first column here is the sender ID (0xAA in our code), the next one is the packet# (in HEX), the 3-rd one if the packet CRC status, the 4-th one is the temperature at the transmitter location, and the last one is the received signal RSSI level. Note that the built-in temperature sensor has noticeable parameters dispersion and must be calibrated for exact temperature measurements.
The supplied receiver code "hub.s43" is also written in assembly language for IAR Embedded Workbench. It starts with μC ports initialization and setting the oscillator frequency for 8 MHz, configuring eUSCI_B0 for SPI mode and eUSCI_A0 for UART mode, and loading 47 configuration bytes into the radio module. After that the program enters an endless loop. In each iteration of this loop it receives a packet, extracts its data, and outputs a new line to the terminal window.
Packages are received in Receive_Packet method of the code. This method starts with placing the radio module into the RX mode. Then it waits for an interrupt from the GDO0 pin. Rising edge on this pin appears upon receiving the preamble bytes, while following falling edge signals on the entire packet reception. The radio module then enters the IDLE state due to the configuration settings. Note that the specified behavior of the GDO0 pin will be the same also by automatic packet drop from FIFO. In this case the RX FIFO would be empty and should not be read. To avoid this problem the program first reads the RXBYTES register of the radio module which contains the number of bytes in the RX FIFO. Only if this number is not zero the program copies the packet from FIFO and composes a new line in the terminal window.
In our experiments we established communication with transmitter and receiver being about 100m apart.
Last modified:Mon, Jan 23, 2023.
