Need a simple, one-way, wireless data transmission for your microcontroller projects? This article will show you how to interface and properly use a $14 RF Wireless Module from SparkFun.
This article was submitted by Brent Reamer as part of the “Hobby parts for articles” program. Write something of interest to electronic hobbyist and receive parts for your next project.
RF Wireless Link Interface and Usage
SparkFun Part #: WRL-00872
Information on Device:
- Receiver runs @ 5v
- Transmitter runs @ 3v up to 12v (higher voltage higher range)
- 2800bps (bits per second) data transmission rate
- 150m Range
- 434Mhz Frequency
- Can easily be interfaced with any uC with U(S)ART capabilities.
A Basic setup (software):
For this article I will be using this device with an Atmel AVR 8-bit Microcontroller, more specifically the atmega32 for the transmitter, and the PC’s serial port for receiver (RS232). Now all of you AVR Freaks out there know the atmega32 has an on-board USART, which is perfect for running this device!
First, lets talk about how U(S)ART must be setup to get this transmitter sending. For a clean USART you need an external clock source, the internal clock source on an AVR is not stable enough for clean sending. So with my ATMega I will be using a 3.6864 MHz external crystal. I went with this number for one reason, magic number (X.XXXXMhz) crystals are extremely USART friendly, were talking a 0% error rate, for USART you need at most a 2% error rate. Here are the USART settings I am using:
- 2800 Baud-rate (that’s 2800bps, which is perfect, that’s why it so easy to interface)
- 8 Data bits
- 1 Stop bits
- Handshaking none
This is also the same for the settings I’m using in my terminal application. I use br@ys but HyperTerminal should work fine.
That’s all it takes, once you got your USART ready and tested it with your PC and a level converter (I use a MAX232). Your good to go, lets setup the hardware.
A Basic setup (Hardware):
I will be sending data from my ATMega to my PC, so lets go over how to setup your UC as the transmitter. I will only be using 5v for this demonstration, but the setup is the same. Here is a simple schematic of the device and where the pins should be connected in comparison to my ATMega:
That’s all it takes, nothing special here at all. Now lets work on the PC side, this takes a level converter IC, I used a Maxim MAX232. Its really the same thing, just setup the receiver with the correct pins, setup the MAX232, and connect the PCs serial to max to receiver. I’m not going to go into setting up the MAX232, there is plenty of information on doing online, just do some searching.
Now time to start the testing. I set the ATMega to just count from 1 to 255 and send that number out ever few milliseconds. You may need to adjust your device if the data from the ATMega has errors. All the SparkFun modules I have bought, seemed to be pre-adjusted, but who knows, you may need to adjust yours. I will talk about this in the next section.
Now that you have your device all setup, the first thing I’m sure you will notice is the ‘junk’ you get when your transmitter is not receiving. RF is everywhere there is no stopping it, so no matter what you do junk will always be received, but when you transmit you over power that junk so you should get clean signals, depending on your distance and voltage.
So what do you do? How can you use this device when you are always getting junk? What if I wanted my PC to send data, or a microcontroller to microcontroller when there is junk always being sent?
With this device it is all about your receiver knowing what is junk and what is not, I do this by sending packets, I will explain below. Another thing to worry about with this device is almost every time, the first char sent will be junk when received (example sent “hello” you get “$ello”) this is easily fixed by sending a couple of NOP’s (0x00) before all transmissions. One last thing you can bet your life that some of your transmissions will be ‘gargled’ this can easily be fixed by using a checksum. I used CRC8, I will not go into the checksum, because this is a extremely common one, do some searching and you will find it. You will also need to send the same transmission at least I would say 3 times, so if the first one is gargled (crc does not match) just have your source skip that one and read the next until it gets a good one.
Here is the simple packet I use:
NUL NUL SOH SOT DATA …… DATA EM CRC ETB
0x00 0x00 0x01 0x02 0xXX …… 0xXX 0x19 0xXX 0x17
I use at least 2 NUL’s to protect against the first char being gargled. Then comes SOH which is ‘Start of Header’, after that a SOT; ‘Start of Text’. The data can be as long as you want it to be, then stops with a EM which is ‘End of Medium’. Checksum is next and finished with a ETB is ‘End of Transmission’.
I like this packet because it’s very simple to use with your source, just have your source wait until it receives a SOH and SOT command, then start collecting data. Does this until EM is reached; collect the checksum, compare and your done.
I included source code for two projects I made a while ago. The source code uses the RF link modules with the packet described above (No checksum though, never got around to adding it). This is test code but it includes the basics you will need to know.
Setting up USART for the wireless device
Out-Of-Range LED (when the devices are to far from each over to communicate a LED will turn on)
Both use a RTC crystal to control the out-of-range functions
Made with winAVR GCC in C
Get the source code here.
If anyone has any questions, please email me at firstname.lastname@example.org