I haven't tried software serial with an XBee, like I said only fairly recently has the library been upgraded to work with it. Paul Stoffregen certainly knows what he's about though.
Still, and this is not a comment on the latest XBee library (after all, I haven't even tried it), it may be more straightforward to use the hardware serial for the XBee and software serial for debugging messages. I'd definitely want the advantages of the hardware port for the more critical of the two purposes which is the XBee.
How recent is the SoftSerial library upgrade? Maybe it works better now than when I tried it.
Also, I've not seen any reason to use a library with XBee, as it works like a wire replacement.
Would the library have routines to help with OP's problem?
so that two devices (the PC and the XBee) aren't simultaneously trying to talk to the µC.
This is such a major gotcha that I fixed that problem by designing my own pcbs that:
(a) won't blow up the XBee modules, no matter what you do, and
(b) allow UART switchover between USB and XBee in 2-seconds.
oric_dan:
How recent is the SoftSerial library upgrade? Maybe it works better now than when I tried it.
Oct 2012, Release 0.4 (beta)
Also, I've not seen any reason to use a library with XBee, as it works like a wire replacement.
I was still thinking of API mode. The library is a huge help there, where mesh networking goes beyond the "wire replacement" concept.
Would the library have routines to help with OP's problem?
If API mode were employed, yes. He seems reluctant, though.
This is such a major gotcha that I fixed that problem by designing my own pcbs that:
(a) won't blow up the XBee modules, no matter what you do, and
(b) allow UART switchover between USB and XBee in 2-seconds.
Meh. Luckily I haven't managed to blow any up, but I would be interested to see your switchover technique.
oric_dan:
How recent is the SoftSerial library upgrade? Maybe it works better now than when I tried it.
Not sure. I was referring to the XBee library Release 0.4 (beta) Oct 2012, which adds support for software serial. I've used software serial a bit with a fair amount of success, not with XBees, but just doing things like debugging, driving serial displays, etc.
Also, I've not seen any reason to use a library with XBee, as it works like a wire replacement.
I was still thinking of API mode. The library is a huge help there, where mesh networking goes beyond the "wire replacement" concept.
Would the library have routines to help with OP's problem?
If API mode were employed, yes. He seems reluctant, though.
This is such a major gotcha that I fixed that problem by designing my own pcbs that:
(a) won't blow up the XBee modules, no matter what you do, and
(b) allow UART switchover between USB and XBee in 2-seconds.
Meh. Luckily I haven't managed to blow any up, but I would be interested to see your switchover technique.
This is such a major gotcha that I fixed that problem by designing my own pcbs that:
(a) won't blow up the XBee modules, no matter what you do, and
(b) allow UART switchover between USB and XBee in 2-seconds.
Given the number of poor designs out there, maybe you could make a little money selling these boards (shields?).
Jack and Paul, actually I probably overstated this a little bit [bad dog]. My so-called "switchover"
technique just involves 2 jumpers that go between Arduino Rx,Tx and the XBee Din,Dout pins
that can be inserted when the USB port is not connected, and vice versa. Basically, you cannot
accidentally cross-connect output lines.
Also, I use series-Rs in XBee "output" lines, so you don't blow the pins if you accidentally put 0V
or 5V on them, eg wire Arduino TX to XBee Dout - which a lot of those stupid shields can do
if you flip the switch to USB when the Arduino is still enabled [ie, not removed or held in reset].
It's trivial to do these things, you only need to think through the different gotcha scenarios.
Resistors are your best friends in the Arduino world. My pcbs also have series-Rs in "all" the I/O
lines too. I've been doing these sorts of things for over 10 years, and never blown a chip.
Also, because I use XBees so much, and wanted reliable comms, I just recently built a new
ATmega1284 pcb [related to all those long 1284 threads in the Microcontroller section] that
looks like the one in the picture, but has the 1284 chip with 2 h.w. UARTs, so all of these
problems with 1 UART disappear into the dust.
oric_dan:
Jack and Paul, actually I probably overstated this a little bit [bad dog]. My so-called "switchover"
technique just involves 2 jumpers that go between Arduino Rx,Tx and the XBee Din,Dout pins
that can be inserted when the USB port is not connected, and vice versa. Basically, you cannot
accidentally cross-connect output lines.
Also, I use series-Rs in XBee "output" lines, so you don't blow the pins if you accidentally put 0V
or 5V on them, eg wire Arduino TX to XBee Dout - which a lot of those stupid shields can do
if you flip the switch to USB when the Arduino is still enabled [ie, not removed or held in reset].
It's trivial to do these things, you only need to think through the different gotcha scenarios.
Resistors are your best friends in the Arduino world. My pcbs also have series-Rs in "all" the I/O
lines too. I've been doing these sorts of things for over 10 years, and never blown a chip.
Also, because I use XBees so much, and wanted reliable comms, I just recently built a new
ATmega1284 pcb [related to all those long 1284 threads in the Microcontroller section] that
looks like the one in the picture, but has the 1284 chip with 2 h.w. UARTs, so all of these
problems with 1 UART disappear into the dust.
Simple and effective, nothing wrong with that! I'm familiar with the series resistor idea and it's a good one, for some reason I haven't made a habit out of it but I should really try to use it more. I may also have to try a 1284 some day.
Khamey:
When +++ runs in my code will the XBee respond with OK in the serial monitor?
Yes, I think that was already mentioned a couple of times. BUT ... you should try this
all from the Terminal Emulator first. It's much easier to learn AT command mode
operation from there. Assuming you have the correct hardware to hook your XBee
directly to the PC USB port. It's MUCH easier to learn what's going on first, before
trying to do comms with Arduino code.
Type +++, get back OK.
Type ATDB, get back RSSI value - will probably be 0, if not in actual comms with another XBee.
Also,
Type ATCH, get back channel#.
Type ATMY, get back node address.
Type ATID, get back PAN ID number, on and on.
Okay so here is my setup the XBee is connected 5V to 5V, GND to GND, Tx of XBee to Rx of Arduino, and Rx of XBee to Tx of Arduino. Here is the portion of my code I am using to try and poll for the ATDB:
void loop()
{
pressed = digitalRead (button);
if (pressed == 1)
{
delay(1200);
Serial.print("+++");
delay(1200);
Serial.println("ATDB");
DB = Serial.read();
Serial.print(DB,HEX);
Serial.println("You Pressed The Button!");
}
The Serial Monitor Returns
+++ATDB
4FYou Pressed The Button!
K2B
It seem the number after the K is the actual value I want. Not sure.
This has already been not-advised previously in this thread, probably more than once,
and yet they still do it. It's amazing who these threads just seem to go around in circles.
JFTHOI, I decided to figure out what reading RSSI inside a program actually entails.
A lot of handshaking has to be done when in XBee command mode. It's actually a
nontrivial mess in the sense you have to wait "unknown" [at least for me] amounts of
time for the XBee to respond at each step before taking the next step. Therefore,
this sketch is full of delays at every point, whose values were chosen per what seemed
to work, but are probably not optimal. Therefore, comms turn-around time is slow,
but it does work.
/*
file: XBee_RSSI_test
revised: 03/01/13, orig 02/28/13.
Simple RSSI echo test. This program runs on the **remote** node,
and characters are entered on the keyboard at the host node.
Remote responses will be as follows: "rcvd: a s d f g RSSI: 3A ...done"
**** IMPORTANT NOTE ***
Uses 1 h.w. UART for both USB and XBee comms. Therefore,
on a UNO-type board, this sketch must be uploaded, then
the USB disconnected and the XBee connected to header
pins 0,1 (Rx,Tx). And vice versa.
NOTES:
1. see Important Note above.
2. in the RSSI check routine, various delays() are inserted
to give the XBee time to respond to commands, the delay()
values chosen are basically pure guesswork.
***********************************************************/
#define LEDpin 5 // this board uses D5 for the Led.
// data holding buffers.
#define ARYSZ1 32
#define ARYSZ2 32
int ch, datary1[ARYSZ1], datary2[ARYSZ2];
int dcnt1=0, dcnt2=0; // data_in counters.
int fGot_it=0; // received data flag.
#define BAUD 57600 // set to XBee module baudrate.
/**************************************/
void setup()
{
Serial.begin(BAUD);
pinMode(LEDpin, OUTPUT);
delay(5000); /// give XBee a chance to bootup.
Serial.println("Remote ready... enter chars at host");
delay(500);
}
/**************************************/
void loop()
{
// echo_test();
rssi_test();
}
/*
simple test to check the comm link.
- echos back rcvd chars.
******************************************************/
void echo_test()
{
if( Serial.available() > 0) {
digitalWrite(LEDpin, HIGH); // blink Led w/each receipt.
Serial.write( Serial.read() );
digitalWrite(LEDpin, LOW);
}
}
/*
wait for message from host, read RSSI value from
XBee, and send message+RSSI back to host.
******************************************************/
void rssi_test()
{
// receive.
while( Serial.available() > 0) {
digitalWrite(LEDpin, HIGH); // blink Led w/each receipt.
ch=Serial.read();
if( dcnt1 < ARYSZ1 ) datary1[dcnt1++]=ch;
// Serial.write(ch); // immediate echo.
delay(1);
fGot_it=1;
digitalWrite(LEDpin, LOW);
delay(250); // wait a bit for additional characters.
// this delay is artificially long to allow chars
// to be entered from the keyboard.
}
// once msg received, ask XBee for RSSI.
// - delays inserted to give XBee time to respond.
// - all delay lengths used here is pure guesswork.
if( fGot_it ) {
fGot_it=0;
delay(1000); // wait 1-sec after any XBee comms.
Serial.print("+++");
delay(2000);
// should change following to: look for "OK".
while( Serial.available() > 0) Serial.read(); // dump "OK", etc.
Serial.print("ATDB"); // ask for RSSI.
Serial.write(13); // send CR.
delay(10);
// check for XBee response.
while( Serial.available() > 0) {
ch=Serial.read();
if( dcnt2 < ARYSZ2 ) datary2[dcnt2++]=ch;
delay(10);
}
Serial.println("ATCN"); // leave command mode.
// Serial.write(13); // send CR.
delay(1000);
while( Serial.available() > 0) Serial.read(); // dump "OK", etc.
// now send back.
Serial.println("");
Serial.print("rcvd: ");
for( int i=0; i<dcnt1; i++) {
Serial.write( datary1[i] );
Serial.print(" ");
}
Serial.print(" RSSI: ");
for( int i=0; i<dcnt2; i++) Serial.write( datary2[i] );
Serial.print(" ...done ");
dcnt1=dcnt2=0;
}
}
Sorry if I haven't understood your advice not trying to talk to all three. I eventually just want 2 Arduinos and 2 XBees. I am using the computer mostly for debugging purposes. I will try the posted code. I really wasn't trying to be difficult or ignore your advice, but now I get what my problem is after the third time you've explained it haha. Now that I know the +++ is working and actually outputting readable commands I will slowly try and implement a signal strength indicator.
I will slowly try and implement a signal strength indicator.
And then you'll discover that it's mostly useless information. It is not going to tell you anything about distance.
You're probably right on this, maybe the most important info to be gleamed is if
you're close to the signal dropout point. RSSI will probably be very nonlinear falloff.
However, now that I went to the trouble to write the code, it might be interesting
to measure RSSI vs range, JFTHOI. I have tried so many different kinds of modules
now, might be interesting to compare them all.
Xbee = about 30 foot usable range.
nRF24L01+ = about 25 feet.
XBee Pro = 300 feet L.O.S.
RFM12 [1 mW, 433 Mhz] = about 120 feet -(frequency matters)
RSS is somewhat interesting to track, and it can give some indication of how a network is operating. I have several nodes that I chart RSS for. Because the first two charts below are very similar, I can conclude that the mesh networking is doing its thing and one node's traffic is being routed through the other (remembering RSS only reports the last hop). The third chart below is the furthest away and has a fairly weak, yet still reliable signal. Once it starts getting below -90dBm, it will become unreliable (dots will be missing on the chart). But it will also then use mesh networking to look for a better route. I don't have an example at present, but when this happens, there can be a striking change on the chart as what usually happens is that the last hop comes through a closer node, so the signal strength can improve significantly.
I'm curious why no one recommended just reading the signal strength from the packet? I"m new to xBee, building my first project. I don't quite understand what the modes are. I've been using my series 1 xBees directly instead of using the serial pins--mostly because it seems easier. I find the signal strength in the seventh byte of the packet, as shown in the xBee lab manual.
7E =start of transmission, a preset value (1 byte)
00 0C =a count of the following bytes in transmission (2 bytes)
83 =code for 16-bit module addressing, preset value (1 byte)
5678 =16-bit address (2 bytes)
3F =signal strength of wireless signal at receiver (1 byte)
00 =status byte (1 byte)
02 =number of samples (1 byte)
00 01 =Active-Signal Bytes identify active I/O pins (2 bytes)
00 01 =first of two samples for digital I/O pins (2 bytes)
00 01 =second of two samples for digital I/O pins (2 bytes)
6A =calculated checksum (1 byte), not included in byte count
Titus, Jonathan A (2012-07-02). The Hands-on XBEE Lab Manual: Experiments that Teach you XBEE Wirelesss Communications (Kindle Locations 729-740). Elsevier Science. Kindle Edition.
Cool, thanks for the input. First you have to be smart enough to know about that
[LOL], and then, how would you actually read what's in the packet, not having the
Titus manual here for reference?
