Go Down

Topic: RF Transmitter and Receiver WRL-10535 and WRL-10533 (Read 9247 times) previous topic - next topic

steven6282

Ok, so I ordered some of these from sparkfun to play around with for my project:

http://www.sparkfun.com/products/10535
http://www.sparkfun.com/products/10533

And I don't get it.  Using the VirtualWire.h library and using the examples given by them as well as examples on sparkfun and examples on the web, I can't get the receiver to receive anything at all.

Based on a lot of what I read, I was expecting to get a lot of garbage signals if anything, but I'm not receiving a single thing.  I ordered 5 transmitters and 2 receivers to test out with, and I've tried all 5 transmitters, and both receivers to no avail.

I'm pretty sure I got everything wired correctly, just doesn't make any sense.

On the receiver, I have both Vdd pins going to 5 volt, all 3 grounds going to ground.  I've got a piece of wire connected to the anteanna, and the Data Out pin going to digital pin 11 on my arduino uno (this is supposed to be the default rx pin).

For the transmitter I have Vcc going to the 5 volt, ground to ground, and Data In going to Pin 12 (supposed to be the tx pin).

I've tried every variation of the wiring that I can think of including other digital pins, swapping the rx and tx connections around, and nothing seems to work.

Is it possible that I got 2 bad receiver units from sparkfun?  Like I said I was expecting to receive a lot of garbage if anything.  I don't know if there is anyway for me to test the receivers or the transmitters to make sure they are even working correctly.

Magnets wouldn't damage anything on these would they?  Because I also ordered some rare earth magnets from sparkfun and they were all packaged in one box together.

Anyone have any suggestions?

mauried

Theses types of Transmitters and Receivers are extremely simple Amplitude Modulated devices, where the data simply turns
a Radio Frequency Carrier on and off.
They operate on a frequency that is shared by many other household devices.
To transmit data reliably with them you need some smarts at the Transmitting end and also at the Receiver end.
Firstly, you need to Manchester Code the data that you want to transmit, and you also need to transmit preamble sequences
of alternating 1s and 0s, and start flags  before you start sending your data.
You also need some kind of CRC error checking.
The code in the receiver must be designed to look for the preamble sequences and the start flags and then has to decode the manchester encoded
data, and finally make sure the data is intact by computing the CRC against what is sent.

To understand what manchester coding is about this is a good article.
http://www.atmel.com/Images/doc9164.pdf

Its not hard to do , but if you want something that does all the hard work for you then
look at using Xbee Wireless modules.




steven6282

All that is great and all, but if it is in fact receiving a bunch of garbage signals, should I not be getting them on the receiver?

I'm getting absolutely zilch, nada, 0, on the receiver.  Not so much as a garbage receive, or something that I actually tried transmitting.

I even tried plugging the receiver output pin into the serial rx and the rx light never even turns on leading me to believe it's never even sending a signal to the arduino.

I'm not interested in getting into any extravagant code atm to make sure the data being received is the data the transmitter sent, all I want to do right now is actually see the receiver receive something, anything!

mauried

How are you receiving the data.
Are you using a usart in the controller.
If so, the broadband noise simply causes buffer overruns and the usart will lock up and produce nothing.
You have to check for buffer overruns , and then clear the usart buffers when they occurr.

steven6282

#4
Jul 10, 2012, 05:06 pm Last Edit: Jul 10, 2012, 05:11 pm by steven6282 Reason: 1

How are you receiving the data.
Are you using a usart in the controller.
If so, the broadband noise simply causes buffer overruns and the usart will lock up and produce nothing.
You have to check for buffer overruns , and then clear the usart buffers when they occurr.



As I said, I've tried using a digital pin through VirtualWire and using it's rx receiving functions as well as plugging it directly into the rx of the arduino board.  At which time I also attempted using Serial.read to get any data from it that might be coming in.  In both cases there is absolutely nothing.

By the way, I think the VirtualWire library already handles error checking and such on transmissions that are sent and received through it.  Possibly even some form of this manchester code you are talking about.  Every single example I can find using the VirtualWire library shows it working with simply the library, no other extra code or preambles or anything of the sort.

I really think my receivers simply aren't working, but I don't know how to find out.  If it were overloading the uart buffer then I should be getting some kind of signal on the output pin of the receiver but I'm not.  I hooked a multimeter to it and I'm not getting a single blip in voltage or anything.  And if the receivers aren't working, I have no way to figure out if the transmitters are working or not as well.

EDIT:
And yes when I attempted to use the rx pin directly I set Serial to run in 4800 bps mode since that is what the transmitter and receiver are rated at.

CrossRoads

I have the 434 MHz version of these working in a remote control with Virtual wire, have not seen what you are seeing.

You have them running on separate Arduino's, yes? I have not seen anyone successfully use Tx and Rx on the same Arduino.

With 2 Arduino's, try connecting the Tx out to the Rx in, see if you can even get data going that way.  If not, then VirtualWire is not running.
My remote was built under -0021, I have not tried VirtualWire under 1.0 or 1.0.1.

The receiver code is smart - if properly encoded data does not come across, it will not be passed along as output data.
Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.

CrossRoads

Virtualwire does not use the UARTs - its more like smart software serial.
Data rate should not be higher than 2000 and messages sent under 27 bytes (or 37? check virtualwire document) due to time needed for message encoding/checking.
Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.

perhof


Virtualwire does not use the UARTs - its more like smart software serial.
Data rate should not be higher than 2000 and messages sent under 27 bytes (or 37? check virtualwire document) due to time needed for message encoding/checking.


I agree. Keep it down to 2000 bps and limit the chunks of data you're sending to a few bytes to begin with. 27 bytes is the maximum length.
I'm using similar models running at 434MHz all the time and they've never caused me any problems at that speed.

As CrossRoads said earlier, encoding and error checking and everything is done within the library so garbled data will never show up on the receiving end.
You will only see data that has passed CRC check

I'd say that you don't need to add an antenna at all if you just want to test them at short range.
For longer ranges you should get a wire of a more precise length and not "just a wire". You could use quarter, half or even full wavelength if space permits.

What version of VirtualWire are you using?
I'm using version the latest version which is 1.9 with Arduino 1.0. Get it at http://www.open.com.au/mikem/arduino

steven6282

#8
Jul 10, 2012, 07:59 pm Last Edit: Jul 10, 2012, 08:01 pm by steven6282 Reason: 1
Yes I'm using two arduinos, and initially I did try a speed of 2000 as that is what the example projects use.  But even the examples at 4 inches apart with and without a wire plugged into the antenna give me nothing.  Just trying to send the message "hello" from the example transmitter file :(  I am using VirtualWire 1.9 with arduino 1.0.1

One of my arduinos is an arduino uno, the other is a mega 2560.

I've even tried reversing the RX and TX pins (both in pins 0 and 1 actual rx / tx pins, as well as pins 11 and 12 the default VirtualWire rx and tx pins) in case I had them backwards in my head, to no avail.

This is quite a bit frustrating as all the examples I've read using these and virtual wire showing it as simply pluging it in and starting to send and receive messages with the virtualwire library.  I wish there was some way I could confirm that either my receivers or transmitters were faulty so that I could contact sparkfun to see about getting them exchanged or something.

I bought some transceivers to play around with as well: http://www.sparkfun.com/products/9582  hopefully they will not be as complicated at getting setup.  I'm just dreading having to wire the things since they are surface mount boards and I think their connections are closer than the standard bread board pitch so can't just solder some pins to it.  They also use more power than I'd like since the units with the transmitters are going to be run off batteries, that is why I was trying to get the RF transmitter / receiver working first.

CrossRoads

" I wish there was some way I could confirm that either my receivers or transmitters were faulty so that I could contact sparkfun to see about getting them exchanged or something."

Did you try connecting Tx pin to Rx pin (Tx Arduino 11 to Rx Arduino 12, or maybe the other way around), bypassing the RF modules?
That will confirm Virtualwire is working.

Also, make sure you take out the PTT references. These modules do not use PTT (Press to Talk):

4.3 vw_set_ptt_pin
extern void vw_set_ptt_pin(uint8_t pin);
Set the digital IO pin to use to enable the transmitter (press to talk). Defaults to 10. Not
all transmitters require PTT. The DR3100 does, but the TX-B1 does not.

Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.

perhof

I realize you've already checked the comments at Sparkfun since you posted a question there yesterday :)
By the comments it looks like these particular modules are very sensitive to interference. I don't know if 315MHz is worse than 434MHz.
I've heard of wireless alarms and other equipment that more or less jam these open frequencies.
Maybe you could try your modules at another location to see if you have a problem in your area?

I've been using this type of modules for remotes and wireless sensors and I never had a problem: http://www.ebay.co.uk/itm/433MHz-RF-transmitter-and-receiver-link-kit-/261055772748
You can miss a packet of data once in a while but it usually works very well.
I open a garage door from within a car about 60 meters from the garage. Receiver and it's wire antenna is placed inside the garage.

Docedison

First I would plig them into the same breadboard, about 15 20 Cm Apart supply 5V and ground to the appropriate pins on tx and rx modules and put a pull up (4K7 should work fine) on the receiver and a pull down on the transmitter data output. Then I would then put some kind of indicator on the rx output module a DMM should work... There isn't enough current available to light an LED... and monitor the rx output pin while pulling up the TX data line... use a 470R resistor to pull the TX data line up to +5V. If it fails there are three possibilities 1. They aren't tx/rx modules (That would be no surprise from Sparkfun...) 2. the TX and RX modules aren't on the same frequency (there are 3 or 4 separate frequencies around 433 Mhz) again Sparkfun... or 3 the modules aren't any good. However for 3 TX's and 2 RX's to all fail completely in the same manner kinda beggars the imagination. My thinking so far is that ??hopefully? they are on the same frequency and that the receiver has an Open Drain/collector type of output and it isn't really hooked up properly. I've used hundreds of those modules for remote data collection, device controller/programmer applications and all but a small handful worked out of the box, the failed ones were all due to poor assembly and lack of inspection prior to sale. I later ?advanced to making my own devices and If I Never see another MPSH10 It will be too soon. I had an assembly line at my place of employment and all errors made were of the monday morning or "Wrong time of the month" type of errors... All but one batch. I designed the transmitter inductor (Coil) on the PCB and my printed circuit house and I had a great relationship... on one run of boards the PCB guys didn't have any .020 1/4 oz copper laminate (FR4) but he did have a bunch of left over Duriod 5880 Stock and he used it to make my transmitter boards. 5880 material has a very different dielectric constant... like about 2 - 2.5 and the FR4 is about 4.3 - 4.9 my 433 mhz transmitters were in fact working... @ ~550 Mhz... I really came to dislike production electronics...

Doc
--> WA7EMS <--
"The solution of every problem is another problem." -Johann Wolfgang von Goethe
I do answer technical questions PM'd to me with whatever is in my clipboard

Docedison

I bought a couple of pairs of 433 modules from Electrodragon ($1.90/pair rx/tx) and they are functioning well as temp monitors for my little greenhouse in the garage... Very Well @ 50 meters. I like buying things that just work... without a major production to find out "How to Make them Work"

Doc
--> WA7EMS <--
"The solution of every problem is another problem." -Johann Wolfgang von Goethe
I do answer technical questions PM'd to me with whatever is in my clipboard

steven6282

#13
Jul 11, 2012, 01:06 am Last Edit: Jul 11, 2012, 01:12 am by steven6282 Reason: 1
Ok, now I am thoroughly confused.

I tried plugging the tx pin (virtual wire tx not the serial tx) from the 2560 into the rx pin (virtual wire rx not the serial rx), and it's sporadic at best.  This is completely eliminating the transmitter and receiver.  Sometimes vw_have_message will return true, but then vw_get_message doesn't actually get anything.  Then ever once in a while it will print out that it got something, and it looks like the hex is the correct hex for hello, but it's not getting it everytime.  Over a hard wire connection that just doesn't make any sense.

This is the code I'm testing with right now:

Transmitter:
Code: [Select]

#include <VirtualWire.h>

void setup()
{
   Serial.begin(9600);  // Debugging only
   Serial.println("setup");

   // Initialise the IO and ISR
   //vw_set_ptt_inverted(true); // Required for DR3100
   vw_setup(2000); // Bits per sec
}

void loop()
{
   const char *msg = "hello";

   digitalWrite(13, true); // Flash a light to show transmitting
   vw_send((uint8_t *)msg, strlen(msg));
   vw_wait_tx(); // Wait until the whole message is gone
   digitalWrite(13, false);
   delay(200);
}


receiver:
Code: [Select]

#include <VirtualWire.h>

void setup()
{
   Serial.begin(9600);  // Debugging only
   Serial.println("setup");

   //vw_set_ptt_inverted(true); // Required for DR3100
   // Initialise the IO and ISR
   vw_set_rx_pin(2);
   vw_setup(2000);
   vw_rx_start();       // Start the receiver PLL running
}

void loop()
{
   //Serial.println("waiting....");
   //vw_wait_rx();
   uint8_t buf[VW_MAX_MESSAGE_LEN];
   uint8_t buflen = VW_MAX_MESSAGE_LEN;

   if (vw_have_message()) Serial.println("Have a message");
   if (vw_get_message(buf, &buflen)) // Non-blocking
   {
int i;

       digitalWrite(13, true); // Flash a light to show received good message
// Message with a good checksum received, dump it.
Serial.print("Got: ");

for (i = 0; i < buflen; i++)
{
   Serial.print(buf[i], HEX);
   Serial.print(" ");
}
Serial.println("");
  }
}



....*sigh*

EDIT:
Ok... all of my problems may have something to do with power levels.  I've been using a 9volt battery to power the transmit arduino (2560).  Everything seemed to be working fine with it the led blinked and everything so I didn't think anything of it.  But out of desperation I changed batteries, and suddenly with the hardwire every single message is going through.  So maybe the battery was to weak and it wasn't sending a strong enough signal down the wire?  I'm going to try again with a wall wart plug later when I get time to put one together to see if I can get the actual transmitter to work off that.

steven6282

#14
Jul 11, 2012, 02:05 am Last Edit: Jul 11, 2012, 02:36 am by steven6282 Reason: 1
Thanks for all the help guys.  Looks like my problem was simply power issues all along.  Plugged a wall wart into the 2560 with the tranmitter hooked up, the uno into my computers USB with the receiver hooked up and walla, hello in hex is coming through.

Stupid batteries =p  That does not bode well for me planning to use batteries in the devices that will be doing the transmitting!

EDIT:

Well it's mostly working.  Even with a 13cm piece of wire plugged into them for an antenna I can't separate them more than a couple inches without loosing all the data.

Guess that is a sign that I have a lot of interference in this area or something.

Go Up