Go Down

Topic: How to measure XBee signal strength? (Read 32341 times) previous topic - next topic

PaulS

Quote
The Serial Monitor on the XBee now returns
+++ <delay> ATDB
OK(first hex character)<delay>(second hex character)

any reason for the second delay?and why OK shows up all at once with the first hex character?

The Values I am getting are +- 2 hex digits so if I get 2D in XCTU i might get 2F in the Arduino Monitor

I think that you are discovering the joys of trying to talk to the XBee AND the PC on the same serial port. That is not advised.

oric_dan

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.

oric_dan

#32
Mar 01, 2013, 09:45 pm Last Edit: Mar 01, 2013, 09:49 pm by oric_dan Reason: 1
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.
Code: [Select]
/*
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;
 }
}

Khamey

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.

PaulS

Quote
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.

oric_dan


Quote
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)

JChristensen

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.



oric_dan

Jack, did you ever actually try plotting RSSI versus distance?

ponobill

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.

oric_dan

Quote
just reading the signal strength from the packet?

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?

ponobill

Trust me, I'm stumbling around here. Took me forever to get a servo to respond to a pot. The Lab Manual is pretty useful, but it's dense. I only go a few pages at a time. Parsing apart the analog data is especially nasty.

JChristensen


Jack, did you ever actually try plotting RSSI versus distance?


I did some experiments which consisted of walking around the house with a module with a readout showing RSS. I didn't go so far as to chart it or even actually try to correlate it to distance. There is of course some general relationship, but as has been discussed here numerous times, it's not good enough to actually determine distance from. Orientation, movement, intervening objects, etc., all have significant effects.

The first chart I posted above is a good example of this. Note how the first half of the chart shows a consistent -70dBm and then it deteriorates and shows more variation. My concentrator unit is in my office, and when I'm in there working, there is a lot more EMI due to computers, fluorescent lights with electronic ballasts, etc. About half way through that chart is where I fired everything up, none of the XBees actually moved or anything like that. Nighttime is also obvious on the charts, when the house is quiet and most appliances, etc. are shut down.

JChristensen

#42
Mar 02, 2013, 01:55 pm Last Edit: Mar 02, 2013, 02:03 pm by Jack Christensen Reason: 1

I'm curious why no one recommended just reading the signal strength from the packet?


Because we're masochists here and we want to do it the hard way in transparent mode :D

BTW the frame you showed is a Series 1 API frame; the OP is using Series 2 modules, which do not include RSS in the API frames. It takes a separate interaction (reply #6 above) to read RSS. Still miles easier and faster in API mode.

</rant> ;)


Quote
just reading the signal strength from the packet?

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?


It's all in the product manual as well, Series 1 or Series 2.


Trust me, I'm stumbling around here. Took me forever to get a servo to respond to a pot. The Lab Manual is pretty useful, but it's dense. I only go a few pages at a time. Parsing apart the analog data is especially nasty.


Are you aware of this library? Makes things quite a bit easier.

oric_dan

Quote
I did some experiments which consisted of walking around the house with a module with a readout showing RSS. I didn't go so far as to chart it or even actually try to correlate it to distance.
.....

Thanks, good info there.

Khamey

My advisor was happy with the way I have got the RSS in transparent mode. Basically I got it done with some time to spare. I have another school project that will take all my time up, but after that I will tackle API mode. Your help has been greatly appreciated! Without some pointers I don't think I would have gotten as far as I did. No it isn't pretty or smooth, but it works which was all i needed for the grade. Also to whoever said I was trying to get some distance measurement out of this misread or I mistyped. I really just wanted the signal strength without any relation to distance.

Go Up