just a quick question: I tried to get wireless communication going with two arduinos and this dude: http://www.sparkfun.com/products/8945 and it’s mate, with input from a potentiometer. Here is my code:
/*
* Simple Transmitter Code
* This code simply counts up to 255
* over and over
* (TX out of Arduino is Digital Pin 1)
*/
byte counter;
int potpin = 0; // analog pin used to connect the potentiometer
int val; // variable to read the value from the analog pin
void setup(){
//2400 baud for the 434 model
Serial.begin(2400);
counter = 0;
}
void loop(){
val = analogRead(potpin); // reads the value of the potentiometer (value between 0 and 1023)
val = map(val, 0, 1023, 0, 179); // scale it to use it with the servo (value between 0 and 180)
counter = byte(val);
//send out to transmitter
Serial.println(val, DEC);
counter++;
delay(10);
}
reciever:
/*
* 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;
}
the two are only exerts, they are not supposed to match line for line, but even so, it is clear to see that what comes out the end is pure gobldy gook… here is the tutorial I used: http://www.sparkfun.com/datasheets/RF/K … hrough.pdf
is this normal? I can’t quite believe the wireless link is -this- bad… am I just in an area of high interferance? also, the transmitter is powered with only 5V… the two devices are ~1 ft appart, 1 ft from this computer.
Since there’s no protocol stack running here, you probably want to implement some kind of parity across your link to make sure the data is coming across correct.
First; yes, the link can be that bad. This is an ultra-simple receiver. no protocol, packets, error correction, etc.
Second; make sure your receive has an antenna.
To make the communications more robust, consider sending two sequential (back-to-back) characters. The first one is a LAM (look-at-me) qualifier, and the second one is the one you want. You will not look at the second character until the first character is received and accepted (matched against the LAM).
For example (pseudo-code, LAM->0x81):
***TX***
(1)send LAM
(2)send VAL
***RX***
(1)receive CHAR
(2)If CHAR == LAM Then receive next CHAR, and print
(3)Else goto (1)
A better option; send three sequential characters. First is LAM, next is the one you want, third is checksum or crc. You do not “accept” the second character unless it is preceded by the LAM, and followed by the checksum/crc.
Save yourself some hassle and check out if [VirtualWire supports this particular module–it’s a great library that handles the special needs of these types of modules well.
I used these modules in an RC car for a senior design project a few years back.
My memory is a little fuzzy as to the details why, so forgive me for not backing up my claims… But I recall coming across some documentation stating that these modules require (or work best) with fairly neutral disparity (equal number of 1’s and 0’s being transmitted).
Bandwidth wasn’t a huge concern in my application (which is why i chose these), so I simply transmitted the desired byte of data followed by its inverse. On the receiving end I compared them to verify everything was transmitted properly.
This is the quick and dirty method that worked reliably with these modules, I’m sure there are more efficient ways of encoding the data, but I never got into optimization.
