Sending Data Using Cheap RF Modules

Wireless is easier today than ever, with many standards to choose from. But you don’t need anything elaborate if you simply want to cut the cord. A few years back, [Roman Black] experimented with the cheap RF modules you can find on auction sites and from surplus electronics vendors for only a few dollars, and wrote up his findings. They’re well worth a look.

These modules have pins for power and antenna, transmit input (TX) for the transmitter, and receiver output (RX) for the receiver. All the TX does is turn the carrier on and off and the RX output reports the carrier status. [Roman] first used 50% duty cycle square waves to characterize how well the RX followed the TX. Below 1 kHz the match was good. At higher frequencies the RX couldn’t maintain the 50% carrier on. He found that sending 1200 bps from a USART just worked under good conditions — resulting in 83 bytes per second.

Changing up to a long-short, pulse-period protocol, where a 1 and 0 are sent for 150 and 100 usec respectively, got him much better results. He maxed out at a throughput of around 800 bytes per second.

This is an interesting experiment which shows that the protocol used on the media, in this case simple continuous wave RF, has a large effect on the transmission of data. [Roman] attained distances of 20 meters through walls which is a good distance with cheap hardware. Are there even better protocols out there?

38 thoughts on “Sending Data Using Cheap RF Modules

  1. I did some experimenting with these modules back before the ESP8266 came out but never quite got the results I wanted. Meanwhile with the ESP8266 being its own hotspot I can hit it with a smartphone or another ESP8266 from 300 feet away and no need to worry about the protocol or error correction. And the ESP8266 is cheaper. Only downside is it draws more power. But these RF modules aren’t real low power either, and they are much harder to work with.

    1. I picked up some to use for an art project I was the hardware and software person for. Got them in an order of a bunch of things from Sparkfun. While testing I could get great results, but once I took them to the install venue I got constant noise and static. Had zero throughput from half the distance. Couldn’t change the venue, so we switched to Bluetooth.

    2. ESP is cheaper? I bought 10 pairs for ~$3 from my venerable Chinese provider before the ESP was available. Of course 9 of them are still sitting around in a box =)

    3. From my home I can usually see 4 or 5 SSIDs using a typical cellphone or laptop without an external WiFi antenna. Of course with an antenna that number goes way up. Anyway.. is that typical? Or is it more than average? I don’t know. What I do know is that every WiFi device that I have ever tried works very poorly in my home. They are constantly up and down, connected one minute, dropped the next.

      Built in 1992 my house is pretty much the same as any new construction, drywall with 2×4 supports. It’s not like I am in an old house with drywall cut with local sand that was high in metal content or anything like that. And yet.. WiFi devices are always blinking in and out. Maybe there is some other kind of signal on those same frequencies in my neighborhood? I don’t know…

      Anyway… I’m far more interested in wired solutions for sesile devices and non-wifi rf solutions for battery operated portables. It makes me a little sad that ESP8266 seems to be stealing the show! Even the ‘Arduino meetup group’ at our local makerspace that started out talking about building stuff with NRF chips keeps talking about switching over to ESPs. I’m not sure how long I will stick around if that happens.

    4. yea i managed to remote control some servos with these, they are finicky. you need to throw on some manchester coding. that by itself halves your throughput from the rated value. then on top of that the usual ~25% protocol overhead. very low level modules.

      then moved on to nordic nrf24l01+ modules and they were somewhat better. you can actually move some serious data, in theory. initially used the mirf library but have not had much luck using it on the 32bit arduinos, so pretty much need to learn new libraries just to get it to do what it used to.

      esp8266 is pretty good, easy to set up, easy to use. its only issue is that it relies on serial which i think is a huge bottleneck. of course the serial interface is what makes it easy to use, so i guess its a good tradeoff. of course i went and got a no frills modules that doesn’t have enough gpio to run the show on its own.

      1. The esp8266 can be used standalone, and doesn’t necessarily have to act as a module. By not using a secondary microcontroller, you can eliminate the need for the serial port “bridge” entirely. I recommend getting a version of the esp8266 with plenty/all of the available GPIO pins broken out for easy access.

        I need to try the nrf24l01+ modules again. First ones I received were clones, and weren’t reliable. They seemed decent though, and a better option when full-blown wifi isn’t necessary or appropriate.

        The cheapy RF modules from this article that I’ve tried were pretty terrible. Not really worth the effort, compared to other options. Even the price isn’t great, considering the usability and performance of these modules.

  2. These two work well even with HT12E and HT12D IC’s.
    I was trying to obtain HT640 and HT648’s as the other 2 were only supporting 4 bits, but couldn’t find them for reasons.

    Also, this pair was good 10 years back. Since the time nrf24l01+ came into market, it took their spot on my circuits. Cheaper and more robust.

  3. A USART transmitting over a bit-banged wireless link?

    You crazy?

    What does BER mean to you?

    Also, stop with the shortcuts. I realize HAD loves JIT learning but really, read the Radio IC’s datasheets. See that bit slicer / AGC in the receiver? Know what it needs? sync time.

    Let’s start with the basics:

    Manchester encoding:
    This one is microchip centric, but the benefits of Manchester Encoding over a USART that is timing critical are very clear.

    http://ww1.microchip.com/downloads/en/AppNotes/01470A.pdf

    One could also do this with any microcontroller that has a comparator that can feed a hardware timer input to measure pulse widths rising or falling.

    So pulse widths that are too short or too long get rejected in your receiver interrupt routine and, the clock timing synchronization is built in since every data bit 1 or 0 consists of a level transition.

    Once you receive 8 bits, you pack them into a byte (convert from manchester to ‘1’s and ‘0’s) and signal to your main program that a new byte was received.

    So that’s the protocol’s lower layer.

    Next you need to define your data header:
    You might want to have:

    [Sync chars] [time gap] [start] [destination address] [source address] [message length] [data 1] [data n] [CRC] [end]

    This way you can have multiple addressable nodes rather than just a point to point serial link.

    You will need an escape character and you will need to escape the [sync], [start] and [end]

    You only parse your data after the end byte is received, the length matches the actual message length received, and the CRC check passes.

    I would be surprised if Arduino or whatever doesn’t already have a library that does something like this, or exactly this.

    1. LOL, or you could, yahknow, have a protocol consisting of nothing more than 8 bits of data between two devices that already have UARTs, and save a shitton of effort.

    2. In 433MHz and other very congested bands it is useful to keep the packet size very short, as that minimizes the chances of collision.

      I’ve myself used a format of where packet start byte is just a constant value and data is fixed length. Then I just transmit the packet many times, and on reception end wait for atleast 3 packets with same content until I accept it.

      1. Effect:
        “In 433MHz and other very congested bands”

        Cause:
        “Then I just transmit the packet many times, and on reception end wait for atleast 3 packets with same content until I accept it.”

    3. If only there was some part or module that does all that work of encoding data, adding some form of error-checking like CRC, transmitting it and optionally retransmitting it if it gets mangled? And if it was as cheap as one dollar, that would be great thing. If it was two-way too and had decent range, it would be epic. It sounds like hacker’s dream. Can it really exist? Or be available in sets of 5-10 with free shipping for less than dollar per module? Let’s call this mythical part, superior to your hand-crafted encoding routine a nRF24L01+ module. Oh, wait, it’s not mythical…

  4. Roman’s results make more sense if you talk about detection threshold rather than variable gain. These inexpensive receivers don’t have any type of variable gain. They work by shifting the DC offset of the demodulated signal so it is centered around the threshold of a voltage comparator. On the RWS-371 receiver you can see this directly on the “linear out” pin. At the start of the training signal, the signal is completely above the Vcc/2. The signal can be seen to drift down as time passes until it is centered around Vcc/2. It is that signal that goes to the comparator to generate the “digital” signal out.

    It’s a pretty slick design since, regardless of the RF signal level, as long as the data has a duty cycle near 50%, the the quietest part of the received signal will be centered around the comparator threshold. The purpose of the training signal is to “charge” a low speed integrator putting the signal at its optimal level before the data is received.

  5. I have messed with these a lot, both AM and FM and never got them to have anything like the range of commercial items that use them no matter how much effort I put into the antennas. One thing I did find is that removing the NRZ from the input signal made it a lot more reliable and it is pretty easy to implement in a PIC.

  6. These things suck butt. The filtering and AGC is next to useless, getting anything meaningful out of them requires either being close or doing a ton of SW filtering and FEC.

    NRF modules are less then $1 even in single digit quantities, while doing all the protocol for you.
    If you want to have hands-on learning about wireless protocols, you can play with the dumb modules. If you actually want to transmit data and not pull your hair out about it, use an NRF module (or ESP8266 module and toss the micro).

  7. I programmed a Manchester protocol (in C for SDCC compiler) using PIC microcontrollers. The transmitting side is a small 8-pin PIC12F675 and receiving end is PIC16F628A. As they all say, transmitting is simple, receiving difficult. Be sure to put in many sanity checks on receiving end to drop out of interrupt as soon as the signal stops making sense: i) min and max baud rate that is allowed; ii) measuring the exact baud rate; iii) min and max length of synchronization header; etc.

    The example is here: https://github.com/marti184/PIC433
    It is definitely not perfect and the program is very un-library like, but that hopefully makes it simple to understand and modify for own purposes.

    Also important is the antenna. The simplest is 1/4-wave monopole, for which a lot of knowledge is available. Just make sure to have a good ground plane. More difficult is 1/2-wave dipole, which I’ve described at the github page.

    With this setup at a very noisy environment (receiver next to UPS, Raspberry and Wifi router) and through several walls I got communication at needed 30m of range, with the transmitter being at 9V. Probably 12V would be much more reliable.

  8. I discovered that those modules work, but 433 MHz is so filled with other transmissions that it was very difficult to get my own data accross. Link was occupied by other devices 80% of the time.

  9. This article is very useful for reading before using these modules. Roman describes problems that everyone will experience, the key is to how to deal with AGC, and the answer is preamble. It would be useful to add some sort of CRC check, but for predefined long sequences it can be skipped. For example you want to control 4 relays, use 4 random 32bit numbers, and if you do preamble check correctly it can work pretty reliable. Many cheap eBay remote-receiver combos with this modules work very fine, without any false positives, so it’s possible.

  10. these “dumb” modules do serve a useful purpose. When you are trying to integrate with existing products that use them you need to be able to decode the propriety signal and/or generate it. NRF is great but only when you control both the transmit and receive ends and the protocol between them.

  11. I honestly thought these worked fairly well, even when just using USART. Case in point, I turned a solar lamp into a soil moisture meter (still need to finish refining/calibrating the sensor part of it). Just to bash it together for a proof of concept, I used USART with a Picaxe at the meter and an Arduino at the receiving end. I’d send two bytes of preamble ( a value of d170 for each byte) to give the receiver a chance to dial in the gain and then send three bytes of data (sender ID, raw ADC value and battery voltage) with a fourth byte as a checksum.

    Even using a relatively flawed summed-checksum, I still got reliable data about 95% of the time at a range of over 30 feet…. not too bad in my opinion. Ultimately I need to due something like a CRC checksum, but the proof of concept worked for my application so I’m not sure I’ll ever bother doing it the correct way. Not that libraries aren’t there for the Arduino, but I’d have to bash something together for the Picaxe.

    1. Addendum: If I recall right, I was sending at 1200 or 2400 baud. Lowering down to 600 actually seemed to make things worse with USART, opening it up to a greater chance of interference.

      1. This is consistent with my experience. They’re not great radio modules but they can be made to work.

        Roman’s trick with the bit-length encoding gets any signal to be roughly on-off balanced, which is what Manchester encoding would get you. So that’s a win.

        The other great use for them, because you can feed them arbitrary modulation, is in controlling those radio wall-plugs.

        1. Yeah, I thought that the use of VPW (variable-pulse-width) was rather clever. As far as the transmitting end I think VPW or Manchester would have similar difficulty in implementation although if you were to use timed interrupts to handle the bit toggling and timing, I think VPW would require half the “clock” speed? IE, VPW requires one interrupt per bit while Manchester requires two.

          On the receiving end I think it’d be a bit of a wash.

  12. I first used these things several years ago when I was starting out with picaxes. I think I sent a few 0x55 bytes (alternating 0s and 1s) to get the receiver primed, then sent a few bytes of data at 300 baud. With some 1/4 wave wire antennas they could get 100m line of sight, or throughout the house. I used them for a solar powered robot that had a light sensor outside reporting the maximum light level available (a hacked up solar garden light with a pickaxe, tx, and LDR), and the robot would drive around the house looking for light levels about that bright to charge itself back up.

    The only problem with those picaxes were the serial input command blocked until something happened, so every single iteration of the main loop had to wait for data from the remote sensor. Not the best design I know but it worked!

  13. I’ve got two of these, both connected to a Digispark using VirtualWire. One is on the inside of my garage door and uses a mercury switch to turn on when the door opens. The other is connected to my outside back light that comes on if somebody is there. Each sends a short message every 10 seconds while they are on. Inside I have an Arduino Nano that will beep for at least 30 seconds if it receives the signal. Now I can never leave my garage door open and I will know if somebody is in my yard at night.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.