Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Cheap ebay RF modules made easy... (and fast!)

Status
Not open for further replies.

Mr RB

Well-Known Member
Hi, these crude carrier-only type RF modules can be bought very cheaply now from a number of online suppliers. (usually 433 MHz and 315 MHz modules).

I did some testing of the modules and show how to use them for simple USART comms between micro-micro or micro-PC USB.

I also tested the burst times and recover times etc, and tested transmitting a low frequency for people who might want to use these modules without microcontrollers.

**broken link removed**

This kind of thing comes up from time to time on the forum, and although there are quite a few online projects using these modules those projects are usually pretty sketchy, usually just a schematic and some code.

I've tested the modules a little bit more indepth, and hopefully this may be of use to others. :)

Also I show a simple new data protocol to get much higher speed data transfer (and more data reliability). Source code is provided for that in C.

The project can be seen here;
https://www.romanblack.com/RF/cheapRFmodules.htm
 
I don't know if it's just me; those modules are pretty noisy for my case, and I've been working on them for a while. I wonder whether these modules are the ones which received pretty poor reviews?

Hope to hear some clarification?

Cheers & thanks for the share.
Vizier87
 
One point which I disagree with - RB suggests Manchester coding isn't required - I would completely disagree.

He's gone to great efforts trying different frequencies etc. to find where pulse width corruption happens (which is my reasoning for saying NOT to use standard RS232), but ignores the fact that Manchester completely overcomes this. The reason for using Manchester isn't to "balance the ones and zeros" as RB suggests, but to avoid the unreliable pulse width problem - Manchester uses the transitions between levels to carry the data, and not the width of the pulses, hence it's use for IR or radio data transmission.

Likewise he refers to the 'garbage problem' with RS232 - this is easily cured by hardware inverting the serial data at each end, or not using the hardware USART's and inverting in software.
 
To Ian Rogers; Wow it made a sticky, thanks! :)

To Vizier87; Re these modules being "noisy" and getting poor reviews, that's probably the case. They are the simplest, cheapest, nastiest type of RF modules you can get. :)
They do have the benefit of great simplicity, but of course the problem is that there is no inbuilt error checking or re-transmission of bad packets etc. If you want those features you need to go to more expensive and more complex RF modules that have all the brainy stuff built in.

To Nigel Goodwin; I know you're an advocate of using Manchester and have a lot more experience there than I do, so did I get the Manchester thing wrong? I understand that a 0 bit is transmitted as 01, and 1 bit is sent as 10, with both bit halves of an equal width (period). My understanding of the software decoding is that the micro code tests during the middle of each bit half, so the two tests give a result of 01 from a bit that was 01?

If so, like USART serial the same problem exists; if the 1 bit is greatly reduced in width (especially with its leading edge being late) then the transmitted 01, sensed with 2 timed tests, might be received as 00.

If I read you right you are saying that the micro detects the transition in the middle of the 01 pair? How does it do that in a way that does not matter if that transition is in the wrong place? Do you have a simple diagram or something?

I'm quite happy to change my page and add your comments or corrections there. :)
 
I looked at these radios, then moved to the RFM12 which is also noisy. Now I am looking at the RFM22B which looks like it will require less programming to filter out noise. Has any one compared these?

I may go back to xbee.
 
I haven't seen "noise" issues at all apart from when the transmitted signal was very very low with a bad antenna. With the two whip antennas of 173mm length the signal was rock solid and there was no hint of any other signal present at the receiver (apart from the proper transmitted signal). And I was only using 5v for the transmitter, it allows up to 12v which would be a much higher signal strength again.

Do you know what the cause of the noise was?
 
The reason for using Manchester isn't to "balance the ones and zeros" as RB suggests, but to avoid the unreliable pulse width problem
You know both of you are right on this. Manchester does encode the signal such that the information resides on the transitions, and in the case of these particular receivers also serves the purpose of creating a signal which is not biased to one side or the other. In this particular case Manchester does both; and both of these serve to overcome one of the limitations of this receiver design. But you could also use PWM, or many other techniches to overcome the limitations. The beauty of Manchester is that it provides a "belt&suspenders" approach other solutions don't; the downside is that it does so at the expense of twice the bandwidth (so it reduces the possible throughput).

The key thing when using such modules is realy to "train" the receiver so the AGC has "settled" before the data is sent. And to understand that the data will be "modulating" the AGC; if you have too many consecutive highs , the AGC will trend one way and the duty cycle will favor one end (same thing goes with too many consecutive lows). So one should create a messaging protocol which fits the need. These type of modules are meant to short data transmissions. A typical protocol I use goes like this: JUNK-JUNK-JUNK-SYNC1-SYNC2-DATA1-DATA2-DATA3-DATA4-DATA5-CRC. The JUNK bytes are just equal 1's and 0's byte to "train" the AGC. The SYNC1 and SYNC2 are simple look-at-me bytes; the MCU will ignore any data unless it is preceeded by these two SYNC bytes. The DATA bytes ar obvious. And the CRC is a simple CRC8 to validate the message was received with no errors. The protocol is not perfect or error-free; but provides a reasonable means of protection.
 
If I read you right you are saying that the micro detects the transition in the middle of the 01 pair? How does it do that in a way that does not matter if that transition is in the wrong place? Do you have a simple diagram or something?

Essentially you avoid the 'variable width' problem by not sampling at specific times, you check for the transition within certain time constraints - so (for example) if the transmitted pulse widths are 10mS, then check from 5mS to 20mS for the transition - if it's outside those limits you know there's an error.

It's VERY easy to transmit, but considerably more difficult to receive.

It's pretty well universally used commercially, or similar kinds of coding - plain RS232 isn't normally used as it's too unreliable.
 
Thx RB!!

I have a possible app with a monitoring circuit that has to chirp out a 1 byte # if it detects an alarm condition. Now, these monitors are all within range of each other and there can be a couple dozen running.

It takes 8.3mS to zap out the identifying # of a sensor alarm then chances of a conflict between two transmitters are small. So each sensor zaps out it's byte three times....to ensure the rcvr wakes (wake byte 1, detects byte 2, confirms byte 3) and detects it.

If an alarm condition occurs on average once per 4 hours we have 1.7Million 8.3mS time slots open. With 24 transmitters -=> 1 in 28666 chance of a conflict. Alarm repeats every minute once activated. Estimate 5 mins b4 an alarm is handled.

Do u think I could use these RF comm. devices for this purpose reliably?
 
...
The key thing when using such modules is realy to "train" the receiver so the AGC has "settled" before the data is sent. And to understand that the data will be "modulating" the AGC; if you have too many consecutive highs , the AGC will trend one way and the duty cycle will favor one end (same thing goes with too many consecutive lows).
...

Hi Languer, you are right that some carrier needs to be sent to setup the gain, I used the term "preamble".

As for the duty cycle, I understand what you are saying about the hi/lo balance and how it would work with average voltage and a comparator etc, but the result I got from testing was very different.

The gain seemed to be set very quickly within about 2mS of carrier being present. That leads me to believe the gain is set on max signal strength peak, not average hi/lo signal strength.

Also, the duty was NOT dependent on any hi/lo balance! I expected something similar to what you said, that the duty would depend on that. But it did not, it seemed instead the gain is set on signal peaks, then anything below a peak is a 0. As a comparator model it would be like the comparator threshold was set JUST below the signal peaks.

The good point is that the transmitted hi/lo bit balance did not matter much at all.

NigelGoodwin said:
Essentially you avoid the 'variable width' problem by not sampling at specific times, you check for the transition within certain time constraints - so (for example) if the transmitted pulse widths are 10mS, then check from 5mS to 20mS for the transition - if it's outside those limits you know there's an error. ...

Thanks Nigel that makes sense. So you could sync the manchester to the end of the preamble HI bits, then check each following bit for a transition within a timed window. Possibly by taking many samples during that window, and getting the average comparing the first half of the window to the last half? That should be reliable and would not matter too much if the / edge transitions are delayed a bit from signal strength etc. Thank you for that. :)

For speed I still think it would not come close to the pulse period system as that pushes the hardware to the very limit of what it will reproduce.

To Mosiac; Your "transmit 3 times" system should work but in the time calcs you need to allow time for the preamble stuff to set the receiver gain, then you can send a data byte. Also, you will get conflicts so your data packet should include a checksum. If I understand you right there is nothing transmitting most of the time, so you can easily make the data packet bigger and more reliable with the checksum etc, and even transmit it more than 3 times.

I would put a random delay between transmissions too, so if two transmitters are triggered at the same time they won't be in sync overwriting each other on every transmission! :)
 
As for the duty cycle, I understand what you are saying about the hi/lo balance and how it would work with average voltage and a comparator etc, but the result I got from testing was very different.

I can't talk about your experiments or the relationship to what modules you used or not. But I can talk about "regenerative" receivers and AM receivers in general. The modules I've worked with follow that model, and you are correct in stating that the AGC does not directly track the ON/OFF balance; after all it is simply an RC with a diode (or at least you could model it that way) - that is to say it is a peak detector with some decay. What you should find if you dig deeper into the experiments is that the AGC should have a direct correlation to the signal strength. In simple terms, the farther the transmitter is from the receiver the more AGC the receiver will try to employ and vice-versa. Because the modules are really OOK modules they only employ two states - full strength or no strength (carrier present, carrier absent). For short burst, if the full strength signal is not changing, you've essentially captured the AGC and you are "free to roam about the country". Now that is usually all well and savvy for strong signals (i.e. transmitter and receiver are close to each other). But for weak signals, where the full strength carrier is say 10dBs above the noise (carrier absent condition), or where the signal is weak and varies quite a bit because signal propagation in air is a statistical measure and is affected by multitude of things (reflections, refractions, interference from nearby frequencies, etc); that AGC is going to move, and it will move a lot in some cases. And it is in these cases where things will go bad. It is in these cases where you won't be capturing the straight information. Unless you somehow make the best effort to capture that AGC. See I'm guessing from your experiments you are looking at nearly ideal situations. When I was playing with similar modules I looked at both the analog and digital outputs. And even though in some cases I could play for an hour or so without the digital output showing any noise, the analog output was all over the place - just not enough to trigger the digital output. If I keyed the garage door or car alarm, or some other consumer remote the story changed.

So all I am saying in this long-winded conversation is that what you're really doing by the pulse-period-time coding you created is increasing the reliability of your wireless link; which I'm afraid is ultimately affected by one thing, and one thing only - the AGC of the receiver. If you capture the AGC during your desired message you turn the statistical probability into an almost certainty; if you can't capture the AGC or can't keep it for the duration of the message then you're back to maybe it works and maybe it doesn't. It really boils down to that; that is the physics of the problem; and it is the achilles heel of many and all RF transmissions. AM, ASK, OOK, CP-CA; all these amplitude modulation schemes just suffer quite a bit more from it. But they are simple to understand, simple to build, and inexpensive.
 
I can't talk about your experiments or the relationship to what modules you used or not. But I can talk about "regenerative" receivers and AM receivers in general. The modules I've worked with follow that model, and you are correct in stating that the AGC does not directly track the ON/OFF balance; after all it is simply an RC with a diode (or at least you could model it that way) - that is to say it is a peak detector with some decay.
...

Excellent info, thank you for that and it's great to get some expert input. :) That "peak detector" gain control seems to match the results I was seeing.

... For short burst, if the full strength signal is not changing, you've essentially captured the AGC and you are "free to roam about the country". Now that is usually all well and savvy for strong signals (i.e. transmitter and receiver are close to each other). But for weak signals, where the full strength carrier is say 10dBs above the noise (carrier absent condition), or where the signal is weak and varies quite a bit because signal propagation in air is a statistical measure and is affected by multitude of things (reflections, refractions, interference from nearby frequencies, etc); that AGC is going to move, and it will move a lot in some cases. And it is in these cases where things will go bad. It is in these cases where you won't be capturing the straight information. Unless you somehow make the best effort to capture that AGC. See I'm guessing from your experiments you are looking at nearly ideal situations.
...

More good information, thanks. I'm not sure what qualifies as "nearly ideal situations" but my tests were what I thought to be a "reasonable use", from a few metres room to room through a wall, to the worst case tests of approx 20 metres through multiple house walls including an external brick wall. My antennas were nothing special (as you can see in the photo!) so I assumed this was fair for "reasonable use". It was better performance than commercial bluetooth modules I have, which won't do 20 metres through a brick wall. And remember too I was only transmitting at 5v, not the max power of 12v.

I understand if you pushed the distance to where the transmitted signal is barely above the noise level then it gets to the point of receiving noise as well as signal. I did not do a long distance test as that doesn't prove much about the modules but more about how noisy my neighbourhood is (for the exact reasons you mentioned) and honestly I'm too lazy to hook up some batteries and make a portable test unit to go walking down the street doing tests. ;)

To me the main use for hobby people with these cheapy modules would be simple "around the house" type sensors and devices. They are not really the right choice of modules for attempting long distance control, and there are lots of higher powered better modules for that.

... So all I am saying in this long-winded conversation is that what you're really doing by the pulse-period-time coding you created is increasing the reliability of your wireless link; which I'm afraid is ultimately affected by one thing, and one thing only - the AGC of the receiver. If you capture the AGC during your desired message you turn the statistical probability into an almost certainty; if you can't capture the AGC or can't keep it for the duration of the message then you're back to maybe it works and maybe it doesn't. It really boils down to that ...

I agree completely. For a simple system detecting a digital edge, the pulse period system should give higher reliability (and speed) than any other simple system. If you have a better system in mind, or if I'm just wrong about that then please speak up.

To go better than that would require a complex system and adding noise rejection, like frequency modulating the transmitter and DFT checking for the freq component present. ie; some complex system that can receive signal AND noise together and try to decode which parts are the real signal. But again that's not really a "typical hobby use" for these cheapy modules. :)
 
For a simple system detecting a digital edge, the pulse period system should give higher reliability (and speed) than any other simple system.

Actually the implementation you suggest is quite elegant, simple, and efficient. It provides a very good compromise between reliability and bandwidth requirements (and it is easy on the hardware and software - which in embedded applications is always important).

To me the key to using these type of modules is really establishing a simple protocol. I've seen some people trying to send "Temperature: 27_C"; as opposed to one byte with 27 and letting the receiver interpret the information. In such an example, the first user has to ensure 17 bytes are sent and received flawlessly, while the second user only has one byte to worry about. That just illustrates that in the two examples the necessary information is the same, yet the complexity of one vs the other is quite different.
 
Actually the implementation you suggest is quite elegant, simple, and efficient. It provides a very good compromise between reliability and bandwidth requirements (and it is easy on the hardware and software - which in embedded applications is always important).

Thanks. :) But I can't take the credit for it as the idea was just copied from some appliance InfraRed remote codes, which are designed to get around issues with poor signal causing reduced ON-pulse width.

The RF modules had the same problem so I just copied their solution.

To me the key to using these type of modules is really establishing a simple protocol. I've seen some people trying to send "Temperature: 27_C"; as opposed to one byte with 27 and letting the receiver interpret the information. In such an example, the first user has to ensure 17 bytes are sent and received flawlessly, while the second user only has one byte to worry about. That just illustrates that in the two examples the necessary information is the same, yet the complexity of one vs the other is quite different.

Absolutely! If you have suggestions for good packet protocol I'd love to hear it. Ian Rogers made this thread into a sticky so any expert suggestions you (or Nigel or anyone!) can provide will be permanent and help a lot of people.

Likewise if anyone wants me to test specific performance of these modules I will have them hanging around on the test bench for a while still, and can quickly write some code and test a feature or encoding pattern etc.
 
I made experiments with Linx TRM-xxx-LT modules, which are similar in functions to these ones. I wanted to make it work at a distance of about 700 feet (200+ m) with some walls and many trees in between. The spec sheet says 10,000 baud up to 3000 ft, but I only managed 1000 baud.

I found out that at short distances (within the house) you do not need to work hard to get good transmissions, but when you start increasing the distance, the quality of the transmitted signal becomes very important. If you don't employ an encoding method which sets average duty cycle close to 50% and also has narrow bandwidth, as, for example, Manchester encoding does, you only get noise at the receiving end.

Redundancy is very important too. When your device is sitting there, receiving day and night, just because it has so much time, it's quite possible that it may receive a valid message from pure noise. Happened to me even though I had 16-bit CRCs! To avoid such accidents, I had to severely restrict receiver criteria for data validity.
 
NorthGuy said:
Redundancy is very important too. When your device is sitting there, receiving day and night, just because it has so much time, it's quite possible that it may receive a valid message from pure noise. Happened to me even though I had 16-bit CRCs! To avoid such accidents, I had to severely restrict receiver criteria for data validity.


NorthGuy, I was looking through RB's code and realized it may be remotely possible for the Receiver side to interpret noise as a "valid" message, although the probability is low. You mentioned that it has happened to you in the past. How did you "severely restrict receiver criteria for data validity?
 
How did you "severely restrict receiver criteria for data validity?

I had allowance for noise. It was very generous at first, but then I figured out that noisy packets usually don't make it through anyway. I ended up doing continuous sampling while receiving a packet and aborting when even a single sample is inconsistent. I also lengthened the sync sequence to prevent false syncs. Hasn't received any false messages yet.

I haven't looked at the RB's code, so I cannot tell how/if this can be applied to it.
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top