Low range on 433Mhz RF link kit

I am using this http://www.seeedstudio.com/depot/433mhz-rf-link-kit-p-127.html to send a message over RF.

To get as high range as possible, I am powering the sender with 12V (Transmitor Input Voltage: 3-12V), but still it seems low and very unreliable.

Between the sender and receiver, there are two walls (made of wood and rockwool), and an airline of around 12 meters.

To improve the range I started trying to use wire as antennas for the sender, and came up with two wires with a length of 6cm was the best, but still it only completes less than 50% of the messages send.

For the receiver the picture says that an optional 10-15cm wire can be used, but there are already one on it (small rolled up), and it is glued to the board, so it will be a mess to replace it with another wire.
Managed to get a straight wire attached instead, improved the reception a bit, so now it is receiving around 50-60% of the messages.

Is the 12 meter range around what this set can do, or are there something that can be changed to improve it?

To send and receive the messages, I am using these:

Sending the messages through the Arduino's pin 3
Sender

#include <VirtualWire.h>
#undef int
#undef abs
#undef double
#undef float
#undef round

void setup()
{
  // Initialise the IO and ISR
  vw_set_ptt_inverted(true);               // Required for RF Link module
  vw_set_tx_pin(3);                        // pin 3 is used as the transmit data out into the TX Link module, change this to suit your needs.
}

void loop()
{
  rfSend("this is a test");
  delay(5000);
}


void rfSend(String message)
{
  char output[100];

  message.toCharArray(output, 99);

  vw_setup(2000);
  vw_send((uint8_t *)output, strlen(output));
  vw_wait_tx();                          // Wait for message to finish
  vw_setup(40);
}

Receiver is powered by the Arduino's 5V, and sending the received data to the Arduino's pin 2
Receiver

#include <VirtualWire.h>
#undef int
#undef abs
#undef double
#undef float
#undef round

#define rxPin 2


const int ledPin =  13;      // the number of the LED pin
int ledState = LOW;             // ledState used to set the LED
long onMillis = 0;        // will store last time LED was updated


void setup()
{
  Serial.begin(9600);
  pinMode(ledPin, OUTPUT); 

  // Initialise the IO and ISR
  vw_set_ptt_inverted(true);          // Required for RX Link Module
  vw_setup(2000);                     // Bits per sec
  vw_set_rx_pin(rxPin);               // We will be receiving on pin 2 ie the RX pin from the module connects to this pin.
  vw_rx_start();                      // Start the receiver
}

void loop()
{
  uint8_t buf[VW_MAX_MESSAGE_LEN];
  uint8_t buflen = VW_MAX_MESSAGE_LEN;

  if (vw_get_message(buf, &buflen))   // check to see if anything has been received
  {
    int i;
    // Message with a good checksum received.

    for (i = 0; i < buflen; i++)
    {
      Serial.print(buf[i]);          // the received data is stored in buffer
    }
    Serial.println(" ");
    digitalWrite(ledPin, HIGH);
    onMillis = millis();
  }

  if (millis() - onMillis > 100 && onMillis > 0)
  {
    onMillis = 0;
    digitalWrite(ledPin, LOW);
  }
}

The vw_setup(2000); should be the bitrate it transmits with (and the same they got in their example), isn't that way below 9600?

The 9600 should only be between the arduino and serial port on the computer.

The 433/434 MHz Rx/Tx sparkfun docs call for a 17cm antenna wire.
Where did 6 come from?

The length I am using right now is from testing. The length they say does no difference when I tested it.

Take this line out of your code
vw_set_ptt_inverted(true);

This part doesn't have ptt (push to talk).

On the transmit side, move this into void setup:
vw_setup(2000);

I don't know why you have this in there also after you transmitted the data, this changes the data rate again, take out out:
vw_setup(40);

Unlicensed transmitters are kinda puny by design. If your locations are fixed, you can use directional antennas to improve the gain.

Here is the infamous "Hawg Fence" antenna that will give you 10 to 11 dB gain for about $5. The design freq for our TV repeater of 427 MHz is plenty "close enough" for you to just use the dimensions given.


http://bsrg.org/aatn/stepbste.txt

If ya wanna get super picky, reduce all dimensions of the stub and driven element by about 1.4% to scale it, but thats really overkill.

With 10 dB of antenna gain on one end, whatever performance you used to get at range X you will now get at range 3X. Use this antenna on both ends and you will get the same performance at 10X range.

Good luck on your project!

Take this line out of your code
vw_set_ptt_inverted(true);

This part doesn't have ptt (push to talk).

On the transmit side, move this into void setup:
vw_setup(2000);

I don't know why you have this in there also after you transmitted the data, this changes the data rate again, take out out:
vw_setup(40);

vw_set_ptt_inverted is there, because it doesn't work without it

the vw_setup(2000); and vw_setup(40); is there because it is sending the data with 2000, but another sensor I use to get the temperature and humidity, is working at 40 only, so that is why I change to 2000, sending the message, then changing to 40.

So there are a reason to why I am doing it like that.

Who is "they"? Of course the length makes a difference. RF is not magic.

"They" is sparkfun, who was mentioned in the post I replied to. And I know that the length needs to be the right length, thats why I ended up at something else than they said, because I tried the length they said, and it did nothing, and I then started to experiment with the lengths instead.

Going to try experimenting with the rate when I get home after Christmas again

Ok, I can see the setting the transmit speeds, now that the game of 20 questions is being played and we find out you are transmitting to more than 1 receiver.

I still don't see how this line does anything:
vw_set_ptt_inverted(true);

Your transmitter does not have a PTT input pin. The virtualwire default pin for PTT is pin 10 - which you didn't change. What do you have it wired up to?

On the receive side, maybe I just didn't it, where is this stuff that goes in setup?

  // Initialise the Wireless Receiver IO and ISR
  // set Virtual Wire data input to Pin 9 from 11
  vw_set_rx_pin(9);  // found this in forum 25 Aug 09
  // set the Bits per sec 
  vw_setup(2000);
  // Start the receive PLL running
  vw_rx_start();

Ok, I can see the setting the transmit speeds, now that the game of 20 questions is being played and we find out you are transmitting to more than 1 receiver.

I don't know what game you are referring to, because I have never said anything about transmitting to more than one receiver, and I am also only transmitting to one...

I still don't see how this line does anything:
vw_set_ptt_inverted(true);

I don't know what it do either, but I know that if I remove it, nothing is received by the receiver.

What do you have it wired up to?

The arduino is connected to
Pin D3 - PWM fan control
Pin D2 - RPM counter
Pin A0 - http://www.seeedstudio.com/depot/electronic-brick-indoor-temp-humidity-sensor-p-683.html
Pin D2 - RF sender

On the receive side, maybe I just didn't it, where is this stuff that goes in setup?

Not sure what you mean, it is all there?

And there aren't any software problems either, it all works great on that part, only problem I got is that it isn't reliable transmitting when the distance is over 10 meters.

Slow it down to 1000 or even slower, incorporate a checksum in the data, over send the data more often than you require and reject the data at the receiving end that doesn't match the checksum.

Or at least thats the way I went when I hit similar prolems. The RF modules are primitive at the very best and you need to cut them a lot of slack.

The VirtualWire library already uses a checksum.

bld,
the code you listed is from v1.3 of the Library.

Please use the latest version (v1.5) and documentation from http://www.open.com.au/mikem/arduino
then 'cut & paste' the example code for Tx and Rx into your Tx and Rx Arduinos. The examples in v1.5 are much simpler.

Also, the VirtualWire library code uses certain pin assignments:

the

// The digital IO pin number of the press to talk, enables the transmitter hardware
static uint8_t vw_ptt_pin = 10;
static uint8_t vw_ptt_inverted = 0;

// The digital IO pin number of the receiver data
static uint8_t vw_rx_pin = 11;

// The digital IO pin number of the transmitter data
static uint8_t vw_tx_pin = 12;

Please be sure to use the same pins.

bld,
Read thru this sparkfun article as well. It talks about the need to embellish the transmission some to ensure good data is recovered.
http://winavr.scienceprog.com/example-avr-projects/running-tx433-and-rx433-rf-modules-with-avr-microcontrollers.html

The examples in v1.5 are much simpler.

I don't see how they can be simpler, the examples are exactly the same.

Please be sure to use the same pins.

Why? In the documentation (4.1 and 4.2) they show the functions to set the pins to what you want them to be, but the default is 11 to receive, and 12 to send.


Now using a 17cm wire at both the receiver and sender, but the result seems to be the same, I have also turned the speed down to 1000.

Right now it is only transmitting the values from the sensor and rpm from the fan to another arduino, which sends it to a computer to update the database. So for now, it is good enough, but wanted to use something like it for something else later, which requires more speed and to be more reliable, but guess I will have to find something else to do that.

Hi Gents,

I am a noobie, but am currently fiddling around with the RF Links and have noticed some things that are quite illuminating (to me at least). Maybe it might helpful to you.

I am using 434Mhz RF Links, and 17cm antennae where applicable. For data being sent over RF, I am sending about 10 lines of text of about 9 letters in each line:

EFFECT OF RF TRANSMISSION RATE

at 5cm separation between transmitter and receiver, no antennae for both transmitter and receiver.

2000 BPS: 30 % (the 10 lines of code totally correct)
4000 BPS: 40 %
5000 BPS: 60 %
6000 BPS: 40 %
6000 BPS: 20 %

EFFECT OF ANTENNAE

5000 bps rate selected as above.

Separation: 5cm
Receiver: No Antenna
Transmitter: No Antenna
Reliablity: 60 % (the 10 lines of code totally correct)

Separation: 50cm
Receiver: No Antenna
Transmitter: No Antenna
Reliablity: 30 %

Separation: 300cm (3m)
Receiver: No Antenna
Transmitter: No Antenna
Reliablity: not tested, but probably very low

Separation: 50cm
Receiver: With Antenna
Transmitter: No Antenna
Reliablity: 95 % (the 10 lines of code totally correct)

Separation: 50cm
Receiver: With Antenna
Transmitter: With Antenna
Reliablity: 0 % (the transmitter probably overwhelms the receiver)

Separation: 300cm
Receiver: With Antenna
Transmitter: No Antenna
Reliablity: 80 %

Separation: 300cm
Receiver: With Antenna
Transmitter: With Antenna
Reliablity: 95 %

Sorry I am not an engineer, so I can only make some rough guesses on what I am seeing:

  • Looks like the RF Bit Rate has to be chosen with the kind of code in the sketch? By this I mean that if the code is heavy the loop will take longer to run, so the loop cycle is longer. Whether a higher or lower bit rate is beneficial to my code I can't tell. I had to use trial and error.
  • The antenna has a BIG effect on the reliability of the communication. Unfortunately I again can't pin point specifics. It looks like a case by case basis for each transmitter / receiver pair?

Maybe a more RF savvy guy can shed more insight into this?

K in Sg

bld,
Is this correct?
"The arduino is connected to
Pin D3 - PWM fan control
Pin D2 - RPM counter
Pin A0 - http://www.seeedstudio.com/depot/electronic-brick-indoor-temp-humidity-sensor-p-...
Pin D2 - RF sender"

You have D2 listed twice - typo? Or you multipex the pin somehow, as an input for RPM counter and than an output for the RF sender?

Heh, wasn't home when I wrote it, and distracted at the same time...

The right pins are:
Pin D2 - RPM counter
Pin D3 - PWM fan control
Pin D4 - RF sender

Pin A0 - http://www.seeedstudio.com/depot/electronic-brick-indoor-temp-humidity-sensor-p-....

There doesn't appear to be any documentation for these modules - without knowing the output power and the RX sensitivity you can't expect much! I suspect the RX is very crude and unable to reject out of band signals - a tuned 1/4 wave antenna (17cm) for both TX and RX are going to help a lot - and make sure RX and TX have matching polarization.

In practice some experimentation with antenna length is needed to compensate for the device's impedance and the quality of the ground plane.

Also these cheap devices use crude On/Off keying and are very susceptible to interference. Frequency shift keying of one sort or another is superior.

Hi There,

(I have only skim read this post, so apologies if I have missed something)

I think that the problem here is most likely to do with encoding.

Sending data via RF is nothing like sending it down a wire (even when using radio modules) data leaves the RF module the wave is modulated with nice crisp clean square waves, then the wave is corupted but a million external factors before being received by the receiver, in many cases, the receiver is still able to identify the correct modulated data on the back of the wave and output it. However, as you extend the range of the link, this becomes increasingly difficult.

Becuase of the way most recievers work, using a data slicer, to identify 1's from 0's, they can fall victim to DC biasing. In order to help the link increase reliability you have to encode the data, there are a few ways of doing this, but my preference is Manchester Encoding.

On top of this problem the reciever need to syncronise to the transmitter to get the Baud rate, for this you need to send some preamble before your data packet.

The long and the short of it is, that you need some sort of inteligence between your end device and your reciever, and also between your node and the transmitter.

Have a look at RF Solutions website, you could use our RF600T chipsets either side of the TX/RX modules for this.

In not allowed to post links, however, you can check out our website for more info: google RF Solutions.

Good Luck

Suport @ RF Solutions