433 Mhz Tx Rx Range Problem

Go To Last Post
34 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am using this module. It's cheap but atleast it should give 5m range indoor at 1000bps. But I am hardly getting 3m range on only 100bps.

 

I am using the VirtualWire library

I am using a 164mm straight wire antenna on both. 

Tx on 9V adapter

Rx on USB power

Speed 100bps

 

I think I am doing something wrong somewhere, these should give atleast 5m range indoors. Any suggestions? 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

First thing I'd check is, the correct operating voltage range for both modules.  Provide a link to the datasheet

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A quarter wavelength at 433MHz is 173.09mm.

 

 

Ross McKenzie ValuSoft Melbourne Australia

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Even a bit of wet string should get you past 5m. I'd also be suspicious of the cheapy modules - but i've not had an issue with them myself. I was playing with a high quality module recently and without an antenna it was lucky to get a metre - was handy for testing as there are a number of 433MHz sources at my house.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

valusoft wrote:
A quarter wavelength at 433MHz is 173.09mm.

That would be in a vacuum.

In the wire, the quarter wavelength would be shorter.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes Chuck. Agreed. But I always start at the theoretical "in vacuo" and then trim very little by very little. Doesn't everyone?

 

Ross McKenzie ValuSoft Melbourne Australia

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

yep..thats the way to swear in an antenna

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That's a big 10-4 good buddy!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I got no other sources of 433 Mhz in my house. But I am suspicious about two other things.

 

Firstly, I am using a non-regulated source of power for the transmitter, it is supplied by a 6V transformer through a bridge rectifier and a filter cap, it is getting to about 9V.

Secondly, the source for power of the Rx is USB, which is not completely 5V, it is about 0.2V less than that.

 

Are these factors responsible for the drastic decrease in range?

 

Here is a link to a datasheet of a module very similar to this.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Give more details about your TX setup and you RX setup. Which AVR for each? What clock source on each? What is your TX code? What is your RX code?

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

Can you re-attach the data sheets as PDF files, not as a zip?

 

Do you have an O'scope?

 

One needs to look closely at the V+ rating for each module, and at the baud rate for both of these modules.

 

The Tx and Rx are likely to have different V+ ratings.

 

If you try to run the data at too slow or too fast a baud rate, they will not work reliably.

 

It is "best" to connect your Transmitter micro DIRECTLY to the Receiver micro, WITHOUT the RF modules, first.

Connect the TxD to the RxD, and connect a common Ground connection between them.

Do NOT connect the V+ between the two micros, unless they are running on the same power supply.

This eliminates the RF link and lets you verify that your code is working properly.

When that works, then remove the direct, wired, connections, and add the RF modules.

 

Finally, note that the little, inexpensive, RF modules do work, but you have to do much of the work that is already done for you if you use Bluetooth, XBee, or other similar "smart" modules.

YOU have to locate the start of a data packet.

There is a lot of background RF noise, and the receiver will output a continuous stream of junk.

YOU have to monitor that stream and look for your data.

That is usually done by putting your data in a PACKET, and have a Start-of-Packet character.

You watch the incoming data stream until you see the SOP character, then you read the following data bytes.

YOU have to determine if the data bytes make up a valid packet, or if the SOP character was just a random junk character, followed by junk.

 

For example, (copied from another 433 MHz Thread):

 

A few more thoughts.
You did not mention the range you need, but presumably "not far" if you are using the small, inexpensive ($5) 433 MHz modules.

The antenna is the most important part of any RF system.

You need to packetize your data. Also, some of the units need a character or two to synch up. A simplistic packet to get you started with might be:

Sp Sp Sp < ID D1 D2 D3 D4 CS

where Sp is several junk (space, or whatever) characters to fire up the Tx and let the Rx synch on it.
< is Start of Packet. You watch for this in your Receiver code.
ID is ID byte for the Rx. It tells multiple receivers which one is to respond to the data. Unneeded if you have only two modules.
Dn = Data bytes
CS = Check Sum. Perhaps the 8 bit sum of the SOP, ID, and Data Bytes, ignoring carryout.

Read in the data and calculate the Check Sum. If it doesn't match the transmitted check sum then there is an error in the packet received, so discard the packet and watch for the next packet.

Send the packet three times for each desired packet transmission. This will increase the probability of it getting through.

The protocol can get much more complex. The Rx could send back an ACK (acknowlege) after receiving a packet. No Ack, the sender re-transmits the packet.

The Packets can contain a sequence number, (0, 1, 2, 3... increases by one with each packet. This can be used by the receiver to help know if it missed a packets.

Some recommend using Manchester encoding for the small $5 modules, but I've not found it to be necessary.

Using Bluetooth significantly increases the cost, but handles packetizing the data and retransmissions for you.

 

JC

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Finally, note that the little, inexpensive, RF modules do work, but you have to do much of the work that is already done for you if you use Bluetooth, XBee, or other similar "smart" modules.

YOU have to locate the start of a data packet.

There is a lot of background RF noise, and the receiver will output a continuous stream of junk.

YOU have to monitor that stream and look for your data.

That is usually done by putting your data in a PACKET, and have a Start-of-Packet character.

You watch the incoming data stream until you see the SOP character, then you read the following data bytes.

YOU have to determine if the data bytes make up a valid packet, or if the SOP character was just a random junk character, followed by junk

The VirtualWire library does all of that already.

 

However this:

Quote:
It is "best" to connect your Transmitter micro DIRECTLY to the Receiver micro, WITHOUT the RF modules, first.

Connect the TxD to the RxD, and connect a common Ground connection between them.

Do NOT connect the V+ between the two micros, unless they are running on the same power supply.

This eliminates the RF link and lets you verify that your code is working properly.

When that works, then remove the direct, wired, connections, and add the RF modules.

... is good advice!

 

I have achieved a range of over 100 metres at 4000 bps with similar 'cheap' radios, using only 1/4 wavelength non-impedance-matched 'wire' antennas.  If you're getting no more than 3 metres at 100 bps, something is seriously wrong.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here is the pdf for Tx.

Here is the pdf for Rx.

 

I am using Atmega8 on Tx side and Atmega16 on Rx side. Both are running on 8Mhz internal clock.

 

Here is the Tx Code:

#define F_CPU 8000000UL

#include <avr/io.h>
#include <util/delay.h>
#include <avr/interrupt.h>
#include "VirtualWire.h"

int main()
{
	DDRB |= 1<<1;
	PORTB |= 1<<1;
	
	vw_setup(500);
	
	char *msg;
	msg = "con";
	
    while(1)
    {
		vw_send((uint8_t *)msg, strlen(msg));
		vw_wait_tx();
		
		PORTB ^= 1<<1;
		
		_delay_ms(100);    
    }
}

Here is the Rx Code:

#define F_CPU 8000000UL

#include <avr/io.h>
#include <util/delay.h>
#include <avr/interrupt.h>
#include "VirtualWire.h"
//#include "USART.h"
//#include "millis.h"

void blink_led(void)
{
	PORTB ^= 1<<0;
}

int main(void)
{
	DDRB |= 1<<0;
	PORTB |= 1<<0;
	
	vw_setup(500);
	vw_rx_start();
	
	uint8_t buf[VW_MAX_MESSAGE_LEN];
	uint8_t buflen = VW_MAX_MESSAGE_LEN;
	
    while(1)
    {
        if (vw_get_message(buf, &buflen))
        {
			blink_led();
		}
    }
}

 

No I don't have a O'scope.

 

I did the test, the code was working properly. 

I increased the bps to 500 and put the Rx away from my laptop, the performance did increase a little but was still lagging. Though there is nothing to interfere with my laptop's wifi or my cellphone but I was still thinking about something that might.

 

I will make a separate power source for the Rx and test the range finally.

 

I found the idea of sending the same data 3 times to get it through. I will use it in the code later.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

1. wheres the antenna on that thing? I use cheapo RF transmitters and they all use a long wire antenna....

2. make sure you have a big cap on the power supply, radios often have high pulse current requirements, a few milli amps normally, but 100's of milli amps during transmit.

And if you can supply that current, it will definitely kill your range

Keith Vasilakes

Firmware engineer

Minnesota

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jimmy - you have an oscilloscope - the sound card in your laptop. Google soundcard oscilloscope. And see what you find.
Tx on 9V adapter - tell us more. You want the tx module on the same voltage as your AVR otherwise it wont modulate too well.

Last Edited: Mon. Jan 19, 2015 - 09:29 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think the power from the USB was creating problem. I gave power from a battery and it did well, range was >5m indoors.

 

Here is a snap from the Soundcard O'scope taking in the signal. 

Cool!!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Putting 9V on AVR I/O pins, running off 5V, (if that is what you are doing) could also be stressing things a bit.  Key word: level translators.

 

 

Last Edited: Tue. Jan 20, 2015 - 08:18 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
radios often have high pulse current requirements, a few milli amps normally, but 100's of milli amps during transmit.
Not these ones.  TX current @12V=57mA, @5V=20mA.   These are OOK transmitters (on-off-keying) [although the datasheet says ASK, OOK is a special case of ASK], so transmitting a '0' draws no current (quiescent current in the low uA), transmitting '1' draws rated current.

 

Quote:
Here is a snap from the Soundcard O'scope taking in the signal.
Is that from the TX, or the RX?  In any case it looks as expected.

 

Quote:
Putting 9V on AVR I/O pins, running off 5V, (if that is what you are doing) could also be stressing things a bit.
He's not doing that.  He's running the TX from 9V, but it has only an input.  He's running the RX from the same USB power driving the m16, so the RX output won't exceed the m16 rated I/O pin input voltage.

 

Quote:
Both are running on 8Mhz internal clock.
That might contribute to your problem as well.  The VirtualWire library provides a comms link that has more-or-less the same timing tolerance of normal serial link, about 2%.  The combined clock error between the m8 and m16 is +/-20%.  That's worst case.  Typical is closer to +/- 4%.  Have you calibrated (or at least measured) the real clock speed of each?  Bear in mind that the speed of the internal oscillator is both VCC- and temperature-dependent.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Sat. Jan 24, 2015 - 12:24 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 Have you calibrated (or at least measured) the real clock speed of each?

OMG! How to do that? 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JimutD wrote:

 Have you calibrated (or at least measured) the real clock speed of each?

OMG! How to do that? 

 

Write a small program to toggle a pin and measure its width with your PC oscilloscope. Load the same one on your second board and repeat. Compare... and report results.

 

Ross McKenzie ValuSoft Melbourne Australia

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The simplest solution is to use crystals.
Another solution is to use a encoding method like manchester that can tolerate large timing errors. RC5 uses this technique.

See - you do have an oscilloscope! I'd suggest you get a cheapy usb sound dongle. Zapping a $2 dongle is preferable to zapping your laptop. Also remember the input to the soundcard is ac coupled - that's why you see the baseline wander. Nevertheless, it is better than guessing.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, I was thinking about using crystals.K

I am using a sound dongle, but I was thinking weather the sound card can handle the 8MHz signal. Isn't it is limited to 22KHz?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jimmy - is your internet not working? When you Googled 'soundcard oscilloscope' was there no mention EVER of the maximum frequency? You can try 8MHz, but anything over 22kHz is not going to be a close representation of reality.

 

 

You could divide the 8MHz down to something less than 22kHz from both microcontrollers, then mix together the two signals and use the sound card to measure the difference. How to do? I see more Googling on your horizon.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Surely, you can obtain the ratio of the two 8MHz clocks by doing as I suggested above. The same nominal 1KHz toggling on a GPIO pin can be quantified with your PC oscilloscope accurately enough to recognise a 20% difference or even a 1% difference. If the 8MHz clocks are identical, so will be the two toggling frequencies.

 

Ross McKenzie ValuSoft Melbourne Australia

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok! I toggled a pin with a 1ms delay. I found a very very little difference, like somewhat about 3Hz. First one was about 507.99 and the second was about 503.04. Ratio is 1.0098. Timing difference is 19.37us.

 

Well, now its getting clear. I will use a crystal from now and lets see how things goes.

 

Thank you again.

 

One little question by the way, I replaced the m16 on the Rx with a m8 (I intended to do that form the beginning, but as I had got only one m8, I had to start with the m16). Anyways, mistakenly I bought 2 Atmega8L, can I run these on 16Mhz safely? With these code? 

I read some of the forums about it, these was debates going on, so it was not quite so clear.

 

My English sucks I know. crying Is it that bad? 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That's less than 1%.  Timing would not seem to be your issue, provided that you performed your measurements under the same conditions at which you are running your other code.  Remember, the internal oscillator is both temperature- and voltage-dependent.  The difference in frequency between running at 5 V and running at 3.3 V can be 6% or more.

 

Quote:
Firstly, I am using a non-regulated source of power for the transmitter, it is supplied by a 6V transformer through a bridge rectifier and a filter cap, it is getting to about 9V.
I assume you mean you are providing the radio with 9V, but the m8 driving it is getting power from a regulator.  If not... if in fact you are pushing 9V into your m8, I'd say it's time to toss it into the garbage.  I'd be very surprised it would have lasted this long.

 

Why were you trying to run at 100 bps?  Do you need it to be this slow?

 

These receivers have an AGC which sets gain based on the received power of the '1' bits.  Gain shoots up quickly with the absence of a received signal associated with the '0' bits.  At 100 bps, each bit time is 10 ms.  The VirtualWire protocol can have as many as 4 '0' bits or 4 '1' bits in a row, a total time of 40 ms at your chosen bit rate.  Depending on the radio, that's probably enough for the AGC to kick in and lower the SNR to the point that a packet fails.  You said you got better results at 500 bps.  Have you tried 1000 bps?  Higher?

 

 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Nooo, how can I give 9V to the MCU? It is ratted for 5.5V max. I was not doing that.

 

No, I haven't tried 1000bps or more after that. But I will give it a try and check the range.

I heard somewhere that decreasing bps increases range. My device is not speed sensitive, but range sensitive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am sure that you will have an easier life with regular NRF24L01 modules running at 3.3V

 

The printed antenna is going to be fairly well matched to the 2.4GHz waveband.

The chip can select different channels,   detect good packets of data, ...

 

Yes,   I am sure that 433MHz modules with matched antenna will give you longer range and better propagation.

 

I have some cheapo 433MHz modules somewhere.     I suppose that if I connect the correct antenna(s),   the <VirtualWire.h> library might give me a similar performance to the NRF24L01.

 

Of course the NRF works for TX and RX.     I would need to have a second TX/RX pair on a different 433MHz channel.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JimutD wrote:
Nooo, how can I give 9V to the MCU? It is ratted for 5.5V max. I was not doing that.
Just checking ;)

 

Nevertheless, it is still important that your frequency tests be conducted under the same conditions under which your devices will be operating.  If you test at 5V, but run at 3.3V, your test will not reflect reality.

 

Quote:
I heard somewhere that decreasing bps increases range.
Yes and no.  It depends upon many things.  For the simple radios you are using, there will be a 'sweet spot'.  Lower than that and the AGC which is meant to suppress noise may actually increase it.  Higher and the training preamble may not be long enough to settle the AGC before the actual packet comes along.  This would be worse at close range.  You can sometimes improve high-bitrate performance be increasing the length of the preamble, but VirtualWire provides no user-accessible means of doing this.  You have to edit the library.

 

While it may seem counter-intuitive lower bit rates may also increase the likelihood of an error since it takes longer to transmit and receive a packet.   VW uses 4-to-6 encoding, so every 4 payload bits are transmitted as 6 bits.  There's also a 1-byte packet length field and a 2-byte FCS field, each also encoded 4-to-6.  Your 4-byte message ("con\0") will actually be 7 bytes long, and will be encoded as 14 6-bit symbols, totalling 84 bits.  Add to that a 12-bit packet-start symbol, and the whole packet is 96 bits.  At 100 bps, the packet takes just under 1 second to transmit.  In a noisy environment where a bit error can come along every second or more, the likelihood of a packet getting through unharmed is low.  Combine that with the low-speed performance of the AGC mentioned above, and you see how bad it can get.

 

A note on your code:

int main(void)
{
	DDRB |= 1<<0;
	PORTB |= 1<<0;
	
	vw_setup(500);
	vw_rx_start();
	
	uint8_t buf[VW_MAX_MESSAGE_LEN];
	uint8_t buflen = VW_MAX_MESSAGE_LEN;
	
    while(1)
    {
        if (vw_get_message(buf, &buflen))
        {
			blink_led();
		}
    }
}

When vw_get_message() is called, it uses the value in buflen to determine how big a packet to allow.  When it returns to the caller, buflen will contain the actual length of the received packet.  If the packet was garbled, the packet length might not be what you expect it to be.  You must reset the value of buflen before each call to vw_get_message(), or calls subsequent to the one which returned the shortened (or lengthened) packet (good or not) will use this incorrect length.  The result could either be a buffer overrun, or 'bad' packets forever:

int main(void)
{
    DDRB |= 1<<0;
    PORTB |= 1<<0;
    
    vw_setup(500);
    vw_rx_start();
    
    uint8_t buf[VW_MAX_MESSAGE_LEN];
    uint8_t buflen;
    
    while(1)
    {
        buflen = sizeof(buf);
        if (vw_get_message(buf, &buflen))
        {
            blink_led();
        }
    }
}

 

Also, VW's vw_get_message() function uses the return code to tell you whether or not the packet was received without error.  Even if there was an error, the packet is still placed in buf.  As a means of troubleshooting your range issues, you can still examine that packet to see how badly mangled it is.  Your current receiver code merely blinks an LED to indicate successful reception of a packet.  You could rewrite your receiver code to print out the message to the USART and examine it in a terminal emulator on your computer.  In (partial) pseudocode:

    while(1)
    {
        buflen = sizeof(buf);
        if (vw_get_message(buf, &buflen))
        {
            // print "GOOD"
        }
        else {
            // print "BAD"
        }
        // print buf
    }

 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Mon. Jan 26, 2015 - 06:38 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I googled <VirtualWire.h> and apparently it has been superceded by <RadioHead.h> library.

 

Untested.  

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Good to know.  Looks like it combines all of his radio libraries (including RF22) into one.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

those super cheap on-off-keying (OOK), a form of Amplitude Shift Keying (ASK) make no sense to use except in a very high volume product where pennies count.

 

To make it more plug and play, go to a $5 FM/FSK module as below, and a free software stack for that radio that implements network addressing, retransmissions, etc. Expect 100-300m at modest data rates like 9600bps or so.  I use the RFM69H's at 125KHz bandwidth and a modulation index of 1.

 

http://www.anarduino.com/?cid=4

Or radio + AVR microprocessor + 16M serial flash + real time clock/calendar

http://www.anarduino.com/miniwir...

 

and the all important software protocol stack so you don't have to reinvent the wheel

http://www.airspayce.com/mikem/a...

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No, I haven't tried 1000bps or more after that. But I will give it a try and check the range.

I heard somewhere that decreasing bps increases range. My device is not speed sensitive, but range sensitive.

???

 

Are you using data sheets or designing by trial and error?

 

 

The manufacturer has already tested the RF modules and the data sheet tells you the baud rate range to use.

 

From above:

 

One needs to look closely at the V+ rating for each module, and at the baud rate for both of these modules.

 

The Tx and Rx are likely to have different V+ ratings.

 

If you try to run the data at too slow or too fast a baud rate, they will not work reliably.

 

 

JC 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks joeymorin for the great infos.

 

I increased the speed to 1000bps where each message will take 96ms to transmit, I am transmitting 3 of these consecutive messages for a reliable transfer. Where it will take 588ms ((96+100)*3) to transfer the 3 messages with a 100ms interval.

That was theoritically, but I found it took 716ms. If a error occurs every 1sec, I am still left with a 66% chance of getting the data correctly. It can be increased by increasing the number of messages sent at a time. 

 

And yes, I tested the frequencies under the same conditions of the MCUs.

 

those super cheap on-off-keying (OOK), a form of Amplitude Shift Keying (ASK) make no sense to use except in a very high volume product where pennies count.

Firstly the link that you provided is not available in my country. Secondly, I buy these cheap modules for 2$, the modules that you referred would cost me 10$ as I would have to buy two of those, so there goes 8$ savings. wink. Though it would had saved me from a lot of extra coding, but still. 

 

Are you using data sheets or designing by trial and error?

There are no perfect datasheet for these modules, they didn't even got any specific manufacturer.  In some of those many datasheets these was a min and max bps rating and it was 200 to 3000bps.