Categories
Resources
-
Feeds
- Forum
- SparkFun IRC Channel
- BatchPCB
- Open Circuits
- Ponoko - Your Personal Factory
- Jobs @ SparkFun
- Sell Your Widget on SparkFun
- Become a SparkFun Distributor
- Take the SparkFun Quiz
Currency
US Dollar 
Canadian Dollar Feedback
Home Product Categories General WRL-10532
RF Link Receiver - 4800bps (434MHz)
sku: WRL-10532
Description: These wireless receivers work with our 434MHz transmitters. They can easily fit into a breadboard and work well with microcontrollers to create a very simple wireless data link. Since these are only receivers, they will only work communicating data one-way, you would need two pairs (of different frequencies) to act as a transmitter/receiver pair.
Note: These modules are indiscriminate and will receive a fair amount of noise. Both the transmitter and receiver work at common frequencies and don't have IDs. Therefore, a method of filtering this noise and pairing transmitter and receiver will be necessary. The example code below shows such an example for basic operation. Please refer to the example code and links below for ways to accomplish a robust wireless data link.
Features:
- 434 MHz
- 500ft range (given perfect conditions)
- 4800bps data rate
- 5V supply voltage
Documents:
Pricing
images are 
Related Products3 related
-
WRL-10535
RF Link Transmitter - 315MHz -
WRL-10534
RF Link Transmitter - 434MHz -
WRL-10533
RF Link Receiver - 4800bps (315MHz)
Comments 24 comments
Can one receiver get data from multiple transmitters (WRL-10534) if some sort of an address byte is assigned to a transmitted piece of data?
So glad this is back.
RF Link Receiver – 4800bps (434MHz)…. Since these are only -transmitters-.. /receivers.
Please feel free to delete this post.
Dunno if this is on purpose or not, but the example code is missing the closing */ on “TRANSMITTER CODE” and “RECEIVER CODE” which effectively comments the entire thing out so you don’t get any syntax highlighting/etc.
Think this will work with the TI Chronos?
No, the TI Chronos uses a different wireless protocol.
ah good thing the deal ran out. I tend to see more cons to buying a product when I can’t have it :P
if its used in railway track fault identification applicable possibilities is there?
You get what you pay for holds true for this little gem. Thinking that an xbee would be overkill to transmit a 4 byte message, I decided to try this product. I purchased one of each flavor. Both 315 and 433 Mhz radios produce nothing more than a continous stream of noise that no amount of software, checksums and programming can reliably filter out. I am lucky to get 1 good 4 byte message out of 20 transmits.
I have this. At first it was unusable. After I figured out some tricks, I got it to work pretty well.
It would be nice if Sparkfun had Datasheets for the product they actually ship. The one they sent me does not match the link above. It doesn’t even match the picture.
I bought a couple of these, and both seem to have a constant stream of output coming from both. With no input to the transmitter (even with it not powered) I still get a steady stream of bit flips out of each one on the receivers. I’ve double checked the wiring to each (all Vcc and Gnd present) and still cannot find where the issue is. Has anyone else seen the same issue?…
Yes I have the exact same issue as you sadly :(
These are extremely basic transmitters and receivers, and thus you cannot just put digital or serial data in one end and have it come out the other. The signal you put in (and get out) must be modulated; that is, it needs to change state (low to high, or high to low) at least every 30ms, or the receiver will not be able lock onto the signal. When there is no valid TX data, the RX will output noise, so the TX modulation must be constant, even when there’s no actual data being passed. (And ideally the modulation should be balanced (equal time high and low), see line code for more information, Manchester encoding is a popular choice.)
See the links above for examples on how to work with these parts; they’re an inexpensive and effective solution if you’re willing to do the work that more expensive parts do for you.
Mike, thanks for the quick response!…and that’s super great information to have about how the transmitter receiver pair operates. Unfortunately, knowing that now complicates my project a bit, but not a brick wall. Now, is that info also somewhere in the documents linked above for the receiver that I was completely blind to?…well, I suppose if not, it’s here now. Thanks again!
All of the linked examples use modulation to some extent, but you’re right that this requirement is buried in radio theory to the point of obscurity (sorry about that!)
One way to get these working is to constantly send a character across (0xAA is a good choice since in binary it is “10101010” and thus has lots of transitions), and ignore that character at the receiving end. Then you can slip in other characters that are your “real” data as you have it. (You could even check for the 0xAA and use it to prove that a link is actually established). Hope this helps, good luck!
I guess I have the approximately opposite problem from n0mad. I see no activity on my receiver’s data pin — ever. The transmitter and receiver are wired correctly and I am using only example code at this point. It appears that the transmitter (as far as I can tell) is spitting out data right beside the receiver. In desperation, I tried “tuning” the receiver but there was no change. Very frustrating. Does anyone have any ideas how I can debug this? Is there any way to find out if the transmitter is actually transmitting (when one does not see anything on the receiver)?
Double-check your power and data lines (right voltage, right pins), and if that doesn’t help, contact us at techsupport@sparkfun.com and we’ll be happy to help you out.
I have been using these to build a remote robot. The transmitter and reciver are controlled with two Arduino UNOs. I have a test where it reads a message transmitted from the transmitter(WRL-10534
) and prints it on the screen. I have that part working somewhat perfectly. When a motor is attached(anywhere, even on 5V and gnd pins) the data gets completly messed up, no usable information. Does anyone know how I could fix this?
Anyone has the Eagle library for this?
Also, I see a lot of people having trouble with the transmission. I used these in a project and I’m planning to use them again in another, and that’s because of the HT12-E HT12-D pair of Enconder and Decoders (that also appear in these devices Datasheet).With the IC pair they worked perfectly, the only drawback is that if you are really worried about hardware, you’ll have to use a 18 pin IC.
Could I send a one-bit (on/off) signal without encoding, virtualWire? Basically, without a uC. I just want an LED to turn on connected to the receiver when a button is pressed on the transmitter. Is this possible?
Use an HT12E (encoder) and HT12D (decoder) or similar ICs no need for uC.
Testing here, it seems that the receiver outputs a high (lit LED) by default, goes low when the transmitter sends low, and then drifts back up to high after a second or two. No chips, only buttons/resistors/LED. I read somewhere that this receiver adjusts input gain until it gets something, which might explain the drifting high.
http://mbed.org/users/4180_1/notebook/ir-and-rf-remote-controls/ has a code example for mbed sending characters from the matching transmitter to this receiver.