RSSI, 900mhz Vs 2.4ghz Xbees

I have this little bit of code written for a copter telemetry system and find that it works really well, however, I did notice that the RSSI strength works very well with the 2.4ghz Xbee Pro radios and not well at all with the 900mhz Pro radios. The 2.4s range from 100% to about 20% before completely dropping out and gets weaker as I walk farther from the transmitting radio. The 900s tend to hang about 46% (with the antennas within inches of each other) instead of 100% and the signal does not show that it gets all that much weak as I walk away. I get about 700ft away and the signal will begin to flicker between 46-35% and then drops.

Does anyone know what the difference is between the two radios and the way that they transmit RSSI?

Thanks

Here is the code:

#include <TextFinder.h>
#include "PCD8544.h"

TextFinder finder(Serial);

const int NUMBER_OF_FIELDS = 24; // how many comma-separated fields we expect
int fieldIndex = 0; // the current field being received
float values[NUMBER_OF_FIELDS]; // array holding values for all the fields

//Adafruit Pin out. Sparkfun may be different
// pin 7 - (SCLK) 
// pin 6 - (DIN)
// pin 5 - (D/C)
// pin 4 - (CS)
// pin 3 - (RST)
PCD8544 nokia = PCD8544(7, 6, 5, 4, 3);

float batPix = 0; //Pixel for battery graphics
int rssiPix = 0; //Pixel for battery graphics
float deltaV = 0; //Used for the battery graphic
int craftHeading = 0;
int craftAlt = 0;
float craftBattery = 0;
int rssiDur = 0;
int rssiPercent;

void setup()
{
Serial.begin(57600); // Initialize serial port to send and receive at 57600 baud

pinMode(19, INPUT); //Xbee RSSI pin

  nokia.init();
  nokia.setContrast(45);
}

void loop()
{
Serial.print('x');  

Serial.print('s');  

nokia.clear(); //clearing LCD

for(fieldIndex = 0; fieldIndex < 24; fieldIndex ++)
{
values[fieldIndex] = finder.getFloat(); // get a numeric value
}

Serial.print('x');

//Assigning craft values based on array index numbers

  craftHeading = (values[3] * 57.17); //57.17 is to convert 0-6 to 0-359*
  craftAlt = (values[4] * 3.28084); //3.28084 to convert to feet
  craftBattery = values[22] + 0.28; //0.28 is a battery correction factor for the AQ32 wacky battery VD
  rssiDur = pulseIn(19, HIGH, 100);
  rssiPercent = 100 * rssiDur / 64; 
if(rssiDur < 1){ // If the PWM = 100%, there is no duration (rssiDur = 0us)
  rssiPercent = 100; // so we use an if statement to override the false 0% reading
}

fieldIndex = 0; // ready to start over

//Graphic Math

deltaV = craftBattery - 10.0;
batPix = constrain(deltaV*13.75, 0, 33);
rssiPix = map(rssiPercent, 0, 100, 0, 33);

//--------------------------------------

nokia.setCursor(4, 0);
nokia.print("HDG");
nokia.setCursor(34, 0);
nokia.print("ALT");
nokia.setCursor(63, 0);
nokia.print("MDE");
nokia.drawline(25, 0, 25, 48, BLACK);
nokia.drawline(58, 0, 58, 48, BLACK);
nokia.drawline(0, 17, 84, 17, BLACK);
nokia.drawline(0, 27, 84, 27, BLACK);
nokia.drawline(0, 37, 84, 37, BLACK);
nokia.setCursor(4, 9);
nokia.print(craftHeading);
nokia.setCursor(34, 9);
nokia.print(craftAlt);
nokia.setCursor(0, 19);
nokia.print("BATT");
nokia.setCursor(60, 19);
nokia.print(craftBattery);
nokia.setCursor(0, 29);
nokia.print("RSSI");
nokia.setCursor(60, 29);
nokia.print(rssiPercent);
//nokia.setCursor(0, 39);
//nokia.print("ATAL");
//nokia.setCursor(30, 39);
//nokia.print("BTAL");
//nokia.setCursor(60, 39);
//nokia.print("XTRA");

nokia.fillrect(25, 19, batPix, 7, 1);
nokia.fillrect(25, 29, rssiPix, 7, 1);

if(values[23]>=1.0){
  nokia.setCursor(63, 9);
  nokia.print("ATT");
  }
  else{
  nokia.setCursor(63, 9);
  nokia.print("RTE");
  }

nokia.display();

}

It is common about RSSI function between 900mHZ and 2.4GHz.
2.4Gs has more attenuation than 900s. In the same condition, rf line-in-sight range of 900sis 3 times of 2.4Gs.

RSSI is not a very accurate measurement, and the results will not be directly related to
distance, from my experience. Especially at 2.4 Ghz, you get a lot more problems with
reflections, blockage by objects, etc. I recently measured RSSI versus distance with 2
RFM22 transceivers operating at 434 Mhz, and the values jumped all over the place.

Forbelaw is right in that you'll get much more range at 900 Mhz [and lower] than at 2.4
Ghz. I found the XBee Pros with 1/4 wave whip antenna good to about 300ft, and the
RFM22 at 434 Mhz, with whip antenna and 50mW power, went to about 700ft with
high datarates.

Thanks for the information guys but I'm not sure if my answer is hidden in there or not.

I still don't know the reason why the resolution of the RSSI signal on the 900 mhz Xbee is so poor.

As I tried to say, I think you can't expect RSSI values to be especially meaningful. Here
are readings I took using my 433-Mhz RFM22s a couple of weeks ago. The host unit sent
out a packet every 5-sec, while I carried the remote unit down the street, basically LOS.
The remote unit would receive the packet and re-transmit back to the host. The host
then displayed the received packet info, along with the RSSI value for that reception.

I got approx 700ft down the street before the remote stopped receiving packets, then I
turned around and walked back. The host lost the echoed packets somewhat before 700ft.

The debug msgs are shown for the first couple of packets sent, then I've edited
out everything but the received info. As you can see, the RSSI values jump all over
the place. I've also attached the RSSI conversion curve below.

TX transponder...
TX power(6.2,12.5,25,50,100mW -> 3..7): 6
sending: 000 tx_sponder
rxd: 000 tx_sponder ...rssi=242


TX transponder...
TX power(6.2,12.5,25,50,100mW -> 3..7): 6
sending: 001 tx_sponder
rxd: 001 tx_sponder ...rssi=87


rxd: 002 tx_sponder ...rssi=212
rxd: 003 tx_sponder ...rssi=200
rxd: 004 tx_sponder ...rssi=199
rxd: 005 tx_sponder ...rssi=208
rxd: 006 tx_sponder ...rssi=206
rxd: 007 tx_sponder ...rssi=172
rxd: 008 tx_sponder ...rssi=158
rxd: 009 tx_sponder ...rssi=151
rxd: 010 tx_sponder ...rssi=87
rxd: 011 tx_sponder ...rssi=147
rxd: 012 tx_sponder ...rssi=136
rxd: 013 tx_sponder ...rssi=136
rxd: 014 tx_sponder ...rssi=106
rxd: 015 tx_sponder ...rssi=136
rxd: 016 tx_sponder ...rssi=121
rxd: 017 tx_sponder ...rssi=107
rxd: 018 tx_sponder ...rssi=130
rxd: 019 tx_sponder ...rssi=73

no echo
rxd: 021 tx_sponder ...rssi=78
rxd: 022 tx_sponder ...rssi=107
no echo
no echo
no echo
rxd: 026 tx_sponder ...rssi=113
no echo
no echo
no echo
no echo
no echo
no echo
no echo
no echo
no echo
no echo
no echo
no echo
no echo
no echo
no echo
no echo
no echo
no echo
no echo
no echo
rxd: 048 tx_sponder ...rssi=110
no echo
rxd: 050 tx_sponder ...rssi=72
rxd: 051 tx_sponder ...rssi=122
rxd: 052 tx_sponder ...rssi=141
rxd: 053 tx_sponder ...rssi=131
rxd: 054 tx_sponder ...rssi=61
rxd: 055 tx_sponder ...rssi=133
rxd: 056 tx_sponder ...rssi=112
rxd: 057 tx_sponder ...rssi=107
rxd: 058 tx_sponder ...rssi=132
rxd: 059 tx_sponder ...rssi=161
rxd: 060 tx_sponder ...rssi=183
rxd: 061 tx_sponder ...rssi=173
rxd: 062 tx_sponder ...rssi=118
rxd: 063 tx_sponder ...rssi=211
rxd: 064 tx_sponder ...rssi=193
rxd: 065 tx_sponder ...rssi=231
rxd: 066 tx_sponder ...rssi=238

Not really to do with the OP but the oric_dan problem sounds familiar.

I was getting fluctuating RSSIs from my RFM22bs when using the library from RF22: RF22 library for Arduino.

I have detailed my findings and solution at Redirecting to Google Groups

But in summary, the rssi reading should be taken when the ipreaval(valid preamble
detected) flag is set. That is you need to read the rssi after ipreaval. I have been getting consistent rssi values since sticking to this rule.

lemming, thanks for the link. Now that the RSSI values are more consistent,
how can you use that info?

I feel like everyone is getting very hung up on range vs RSSI... Why does the RSSI signal have to be associated with a units? Why can't it just a rough indicator of signal strength as I believe it was intended to be...

RobDrizzle:
I feel like everyone is getting very hung up on range vs RSSI... Why does the RSSI signal have to be associated with a units? Why can't it just a rough indicator of signal strength as I believe it was intended to be...

Yes, and one now wonders that the purpose of this whole thread was. ???
RSSI gives you a rough indicator, don't worry too much about it, end of story.

The whole point of this thread, which I believe is still remains unanwsered, is why does the 900 mhz have zero RSSI resolution (making it even useless as a "rough" indication) when the 2.4 ghz has fantastic RSSI resolution?

Now that the RSSI values are more consistent,
how can you use that info?

As mentioned, the values do not correlate to any standard unit. In the RFM22Bs it is a value from 0 to 255 with 255 indicating perfect reception. From experience I have found that once this value drops down to around 60, there are going to be dropouts. Thats all I use it for. (I am getting about 1.6 to 1.8 kilometers before this occurs.)

is why does the 900 mhz have zero RSSI resolution (making it even useless as a "rough" indication) when the 2.4 ghz has fantastic RSSI resolution?

This could be due to a couple of things that are hard to tell without seeing the setup. Check that you have the correct antenna and short cable length from ant to xbee. I have only used the Atmel/Meshnetics zigbees but I know with them it is important that you read the RSSI after receiving a packet from the other zigbee. Check whether this is so in your case.
I would be interested to know what antenna you are using. I thought that the 900 Pro should be getting better than 700 ft. Are you using line-of-site for these tests? Reflections and EMF noise may also affect your readings.