Xbee Pro long range made affordable until end of February 2009

Looking for telemetry transmission hardware, I came across following offer made by Digi (ex-MaxStream):

XBee-PRO 868 OEM Development Kit w/ 2 XBee-PRO modules


Apparently, the kit is available for a promotional price of only 99 USD until end of February 2009.

The package contains following:
(1) XBee-PRO 868 w/ RPSMA Connector
(1) XBee-PRO 868 w/ Wire Whip antenna
(1) RS-232 Development Boards
(1) USB Development Board
(1) RS-232 serial Cable
(1) USB Cable
(1) 868 MHz RPSMA Antenna
(1) Power Adapter
(1) 9V Battery & Clip
Various Adapters

This 868 MHz short range device has software selectable transmission power (1 mW (0 dBm) to 315 mW (+25 dBm)).
RF data rate is 24 Kbps (10% of duty cycle).
Incredible Outdoor/RF Line-of-Sight Range up to 25 miles (40 km) with dipole antenna.
Serial data rate of 1.2 Kbps to 230.4 Kbps.
It needs 3.0 – 3.6 VDC power supply and transmitter burns 500 mA typical at 3.3V (800 mA max), receiver only 65 mA typical.

Apparently, for the moment it is ETSI approved for Europe (without special license), but no FCC approval yet for the US.

I think of it as a must have... Can't wait for the Swiss reseller to send me my quote to confirm my order.

More infos on Digi web site.

Views: 6804

Reply to This

Replies to This Discussion

In the meantime I've also got two of this XBee-PRO 868 for my ArduPilots and I think it should be simple to bypass this duty cycle behaviour: asserting a RESET or cycling the power to the module resets also the duty cycle counter. Of course it's necessary to find a free IO on the Ardupilot and to add some lines of code to do this RESET before the cycle counter is overflowing but it should be a possible solution.

Erwin
Has anyone successfully used the PWM signal from pin 6 doe measure the RSSI. I have attempted with the code below, but have not perfected the results. Maybe one of you know something that I have missed...

P.S. The relevant code is in bold, all the rest of the code also does work once the RSSI stuff is commented out.

Thanks,

Zach Long
striker0010@gmail.com


#include
#include "Message.h"

int greenLedPin = 11;
int redLedPin =10;
long connectionSpeed = 9600;
Message incomming;
Message outgoing;
long R_status=0;
long G_status = 0;
int tmp;
int RSSI =0;
/*
* This is the callback function that is called whenever the data is updated.
*/
void dataUpdate(SerializationData *data)
{
RSSI = pulseIn(9,HIGH);
outgoing.setTitle("signal_r");
outgoing.setData(RSSI);
SimpleSerialization.write(&outgoing);
delay(10);

if(strcmp(((Message *)data)->getTitle(),"red_Set") ==0)
{
if (((Message *)data)->getData() == 1)
{
digitalWrite(redLedPin, HIGH);
R_status = 1;
}
else
{
digitalWrite(redLedPin, LOW);
R_status = 0;
}
// outgoing.setTitle("red_Status");
// outgoing.setData(R_status);
}
else if (strcmp(((Message *)data)->getTitle(),"green_Set") ==0)
{

if (((Message *)data)->getData() == 1)
{
digitalWrite(greenLedPin, HIGH);
G_status = 1;
}
else
{
digitalWrite(greenLedPin, LOW);
G_status = 0;
}


}
}

void setup()
{
Serial.begin(9600);
digitalWrite(13,HIGH);
Serial.print("+++");
delay(1100);
//Serial.println("ATRE");
//Serial.println("ATD0 2");
//Serial.println("ATD5 2");
Serial.println("ATRP 40");
Serial.println("ATWR");
Serial.println("ATCN");
delay(2000);

digitalWrite(13,LOW);
pinMode(0,INPUT);
pinMode(5,INPUT);
pinMode(9,INPUT);
pinMode(greenLedPin, OUTPUT);
pinMode(redLedPin, OUTPUT);
incomming.setUpdateCallback(&dataUpdate);
SimpleSerialization.begin(connectionSpeed);
SimpleSerialization.addDeserializableData(&incomming);
attachInterrupt(0, readSer, CHANGE);
}

void loop() {
//digitalWrite(13,HIGH);
outgoing.setTitle("green_volt");
tmp = analogRead(5);
//delay(1);
outgoing.setData(tmp);
SimpleSerialization.write(&outgoing);
delay(10);
outgoing.setTitle("red_volt");
tmp = analogRead(0);
//delay(1);
outgoing.setData(tmp);
SimpleSerialization.write(&outgoing);
delay(10);
//digitalWrite(13,LOW);
}

void readSer()
{
SimpleSerialization.processInput();
}
I know this is an old discussion now but to anyone using it for info I thought I would just add my findings. Cooling them makes a big difference to the run time at higher power levels. I'm running mine at 300mW on both sides @ 9600bps and have attached a small heat sink to the module on the EZ* which is mounted near the tail. The base unit has a larger heat sink and fan. both are cold to the touch and have run for 2 hours today so far dropping only 3 packets. 9600 bps is enough for me but I could not get anywhere near that runtime before cooling them.
Good news, James. Since I use Xbee for pan&tilt I had to shift to the Pro 60mW fro its throughput. But it's good news for later long range use with lesser data in the stream.
Did you experiment range with the 300mW setting yet ?
Hi Reto, I haven't as yet. today was just making sure I keep them working for a decent amount of time at 300 mW without a reset and getting the boards assembled ready to take out on the next fine day. I'm hoping range won't be too much of a problem and have attached a +12db 900MHz Yagi antenna to the base unit Xbee in the hope it will improve signal strength slightly. Hopefully all I need to do now is attend to the Video feed but with the receiver on 2.4Ghz thats proving to be a problem as well.
James, please keep us posted on how it goes :). I am still working on my XBee 868 Rx idea thing, but have not come around to it until now. (So many projects, so little time).
I was thinking of initially using an arduino plugged into the guts of an old Tx and then to XBee 868 as the transmitter, and then similar setup on the receiver end, but using openservo's over i2c.
Going to have some prototype of this made soon if my resonators arrive some day.
I think I did find one of the causes for my issues when using 300mW transmit. The 5v-3v3 I was using from adafruit was limited to ~250mA output on 3v3 :P. Will test with 1.5A 3v3 when my prototypes are done.
I finally did some more testing with this with quite surprising results:
1mw loopback test, 4800bps, standard X-CTU test string, 3365packets went through until it hit a wall. Resetting only one or the other XBee did not suffice, both had to be reset.
100mw loopback test, otherwise same thing with settings, tried with both firmware 1025 and 1027 and both stop at exacly 3465packets, same issue there, resetting one does not solve the issue, resetting both does....
I am testing 300mw now, and there seems to be no difference at all here, same 100% link until it drops...
Has anyone else encountered these same (exact??!) numbers?
I am thinking this should either way not be hard to overcome seeing that the unit works again after reset without cooling it or anything, so I think I'll stick some code in the arduino to do this for me every so often...
Anyways surface temp on the units stays within ~45 degrees give or take a few so the heat should not be the issue.
Does any one know or writen custom/builtin Serial program code for 9Xtend?
Like
servo actions, motor, video streaming, Chat window. or file transfer ...

let me know.. Thanks, Mogly
How long did these run before stopping during your tests (I was never very good at maths)? I'm also thinking the same about placing some kind of monitoring program to watch over the xbee and reset on the chance it hangs but I'm undecided if I should do it based on time period or byte count. Either way it would be a seperate chip watching the tx and rx lines of the Xbee. .
James,
I did some more tests with different amounts of data being sent, all tests at 300mW Tx power.
1 byte had almost 6000 sucsessfull packets, for a total amount of data about 5.8kb
Then I tried with 128bytes of data and 1550 packets went through for a total of 194kb

So the issue seems to relate more to the amount of packets/strings being sent rather than the amount of bytes in total.

I did not measure the time it took, but it varied a lot depending on the amount of data, I'd say the 128 byte run took the longest, and the one byte run the shortest, but this is estimated :).

I am thinking of doing this by having a kind of "I'm alive" sent by the remote device every second or so, and if this it not received by the ground side then reset the ground side modem, and similarly if the remote side does not receive data for about a half second then reset the modem.

I will start more in depth testing once I get my arduinos working properly with the XBee's and then I will test if this works. I have also been thinking of how to best easily determine and report link quality, and my idea would be to use a kind of running number check of the packet, as this relates more to the real world function of the link than signal strength alone.
So in other words for example a byte at the end of the command string with a number simply counting from 0 to 9 and then around again, this way the remote side knows directly if a single packet did not reach it, and can report this back to ground. The ground arduino would then turn on a warning LED or something like this.
I think the number check at the end of the string would be a good plan. My GCS software sends 5 bytes of servo data every 100ms and receives 39 bytes of telemetry every 400ms (gps data is stripped to minimum values, voltage and accelerometer data added) so I would be interested to see how long it takes to lock up as I gave up testing after 2 hours of 32 bytes on loopback using similar timings. I know these timings are slow but for me I think its fast enough to be able to use these modules but time will tell.
I turned something up on digi forums:
"
The 10% duty cycle exists in order to comply with ETSI European Telecommunications Standard for 868 MHz. In compliance with the law, emmitters cannot transmit for more than 6 minutes total in each hour. If you transmit for 6 minutes continuously then the radio could only receive (not transmit) for the next 54 minutes. This duty cycle is not based on temperature.

The register is cleared upon a power cycle of the radio. "

So this would indicate it would have to do with the duty cycle being checked over an HOUR?!?!
This must be the single dumbest duty cycle limit I have ever heard of...
But I did some single side testing and it is indeed the Tx modem wich is locking up. If I blast data one way only I have the same 100% link until it hits the wall, but this time only powercycling the Tx modem made it work again.
I also tried sending the same payload with more delay between the packets, but the lockup came at the exact same amount of data.
But indeed every test session I have done has been less than an hour, I didn't think they were going to recover on their own .
So now I am going to test wether it is really true that they recover after an hour or not.

But in theory this also means that it would be possible although not really legal to use more than 10% duty cycle by resetting the modem before the limit is reached.
I think I have to try to device a way to measure how long it takes for the unit to come back online after reset..

Reply to Discussion

RSS

Groups

Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service