Hello! I am a high school senior currently working on an electrical engineering project in which I modify the existing "invisible fence" pet containment system to shock the animal when exiting the yard but not when coming back in. Anyway, my first step is to create a model invisible fence system, and to do that I need to make a receiver/transmitter system. I'm using an Arduino Uno on OSX and 315 MHz RF Link receiver and transmitter from Spark Fun, and I have wired them according to this link https://www.sparkfun.com/datasheets/RF/KLP_Walkthrough.pdf from Spark Fun and am using that link's code, as well. I've noticed that when my transmitter is running, the "TX" light on the board lights up consistently, but when I run the receiver, the "TX" light (and not the "RX" light) lights up for a few seconds, and then neither light is on. Is this supposed to happen? I haven't been getting a connection, so I know something is wrong. Thank you!
The Rx & Tx lights only come on when there is serial comm's occurring.
From the Arduino code sample at the sparkfun link, the Tx would transmit pretty frequently, and the Rx would not if it was not receiving anything,
/*
* Simple Transmitter Code
* This code simply counts up to 255
* over and over
* (TX out of Arduino is Digital Pin 1)
*/
byte counter;
void setup(){
//2400 baud for the 434 model
Serial.begin(2400);
counter = 0;
}
void loop(){
//send out to transmitter
Serial.print(counter);
counter++;
delay(10);
}
/*
* Simple Receiver Code
* (TX out of Arduino is Digital Pin 1)
* (RX into Arduino is Digital Pin 0)
*/
int incomingByte = 0;
void setup(){
//2400 baud for the 434 model
Serial.begin(2400);
}
void loop(){
// read in values, debug to computer
if (Serial.available() > 0) {
incomingByte = Serial.read();
Serial.println(incomingByte, DEC);
}
incomingByte = 0;
}
Are you running the code on 2 different processors?
Do have antenna's on both?
I think 23cm for 315MHz units.
Could also bypass the Rf, connect Tx to Rx, Rx to Tx, Gnd to Gnd, confirm data is going across and being received, then go back to Rf.
I'm using two different processors, yes. I had been using antennas before, but only 12 cm. I just tried connecting the two directly and the same thing happened - TX light lit up on transmitter, TX light lit up for a few seconds on receiver, and still no message received on the receiving computer. Thank you for your help, by the way.
Sounds like a hardware issue then.
Write a simple echo test for the Rx micro:
byte inByte;
void setup(){
Serial.begin(2400);
}
void loop(){
if (Serial.available() >0){
inByte = Serial.read();
Serial.println(inByte);
}
}
Type something in serial monitor, enter, see if it gets spit back out.
Sorry, I just got back to school. Anyway, I ran the echo test on the receiver and put "testing" in the serial monitor but never got it back. Thanks for all your help, by the way.
Sounds like you have a hardware problem then. Bad cable, bad USB interface chip, something else interfering with D0/D1, ...
How were you able to program the Uno?
I just tried a suggestion from these comments and placed a 1 Ohm resistor between data out and ground. The receiver received the message one time, but most of the time it just shows this: 
The one time it worked, it showed a string of numbers for a second and then stopped receiving and placed characters like that after it. What does this mean and how do I fix it?
that looks like a baud rate issue,
the code has the setting at 2400, your serial monitor is showing 4800.
I changed the code to 4800 in the beginning, since the 315 mHz model takes 4800 bps. I went back and checked now just to be sure and everything has been 4800 on both the receiver and the transmitter.
On a hunch, I bypassed the RF Link again and ran the code directly to each other. I noticed that the serial monitor shows that the transmitter is working properly on either Arduino board or computer, but the receiver's serial monitor always shows the same garbled text as in the picture above. What does this mean?
ch20youk:
On a hunch, I bypassed the RF Link again and ran the code directly to each other.
i don't get what that means.
ch20youk:
I noticed that the serial monitor shows that the transmitter is working properly on either Arduino board or computer, but the receiver's serial monitor always shows the same garbled text as in the picture above. What does this mean?
i'm a newbie, so all i can guess is that you're still having a baud rate issue - is your Serial Monitor set to the same baud rate as what you set in the code with Serial.begin(xxxx) ?
Hi Guys,
If you connect the output of the sending device at TTL levels (approx 0V=0, 5V=1) then the connections are at levels, that are sustained no matter what the baud rate or the "on to off ratio". So you can check the logic of the data sent and received without the vagaries of the RF connection. Certainly worth doing. Adding the RF is lot harder.
The RF modules are generally provided with hi-gain receivers and can latch onto their tuned frequency, and produce a digital output, ie RF present = 1, RF absent =0. The problem though is how to discriminate between random fluctuations (ie general RF noise around us which they respond to randomly) and a strong local signal with real data in it. The answer is an Automatic Gain Control based on the fundamental frequency of the transmitter. If that frequency is strong enough the AGC dampens down the response of the Receiver and it only responds to the stronger pulses of the local signals, the digital output becomes a clean strong pulse stream. The Rx units do not have fancy level discriminators and rely on the signal to have equal parts above (ie =1) and below (ie =0) to have the average of the signal midway between on and off. If there are too many off's to on, then the average signal level will drift low, the AGC will follow it, and next thing data is being corrupted because it the Rx is not working at the mid-point.
Consequently transmitting simple ASCII based text which you appear to be doing is fraught with danger. You need to investigate a coding process called Manchester Encoding. This system can send streams of 1 and 0's indefinitely and in any combination and the average RF level between on and off is always equal, so the AGC remains centered in its most sensitive and accurate zone. Sending ASCII does not guarantee this balance, as a stream of 01000000 characters, will have quite a different average "on" level to 01111110 which is also a valid ASCII character.
The final bit of advice is to send a stream of header data that will have an equal RF on to off ratio, so sending ASCII 10101010 character say 10 times before sending the ASCII message would help to stabilise the AGC at the midpoint , and make any following data more likely to be decoded correctly. However you have to trap the incoming header data and determine where the "header" has ended and the true data begins. Sending ASCII 00000000 as the trigger, or synch character to look for, might do it. Obviously long sequences of ASCII based data in this format will be un-reliable as the AGC drifts off center.
Applying Manchester Encoding + Stabilising Header is really the way to go.
Cheers, Rob