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 & ClipVarious AdaptersThis 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.
You need to be a member of diydrones to add comments!
I've now found a "solution" for this, but it will kick up the duty cycle above the allowed 10% (not a bad thing in everyones eyes).
I wrote a small program which just basically simulates sending servo position update packets via the XBee 868 to a receiver unit. What I tried out now is to simply reset the modem and wait for a small moment before retransmitting data, between every full update packet.
Of course this is not optimal, it should not reset so often etc, but I did it like this to test the theory with minimal work.
And it works like clockwork, but it does have a delay between payloads and thus is slower than it would be without the reset and delay. So I will work on an optimal transmit loop count between resets based on my payload, and anyone else could do the same.
To reset the modem connect a cable between the RST pin on the adafruit module and one of the digital pins on the Arduino/ArduPilot.
Then just simply add this:
in void setup()
pinMode(resetPin,OUTPUT);
digitalWrite(resetPin,HIGH);//set the RST pin high, low will reset the module
And then in the loop code with apropriate counter (you can find this out easily if you transmit a same size payload every time, otherwise make it low enough to be safe - otherwise use response ACK packet timeout to activate)
delay(TXdelay);//wait for data to transmit
digitalWrite(resetPin,LOW);//press reset
delay(RSTactiveDelay);//spec minimum is 100us to register
digitalWrite(resetPin,HIGH);//release
delay(RSTrecoverDelay);//wait for XBee to initialize
Of course you'll need to tune your variables for your particular application, and define them.
same.to - People like you!
LIFE IS ABOUT THE PEOPLE YOU MEET AND THE THINGS YOU CREATE WITH THEM. Find awesome people to share your trips, stays, and activities with!
Does any one know or writen custom/builtin Serial program code for 9Xtend?
Like
servo actions, motor, video streaming, Chat window. or file transfer ...
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.
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)
{
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.
I ve got the Pro868 myself... and i am more than disappointed.
Have you or anyone found a work around and operate it with a highter duty cycle beyond ETSI regulations? Think I might be going to sell this crap again...
Hi all. The implementation of the Xbee Pro 868 in my headtracking stuff with the Nunchuck is posted here. No video yet, though, but I'll add on soon.
It features some way to limit transmitted data to a minimum to keep duty cycle low.
I finally got mine, and ran some small tests last night.
I tried 50 bytes, 9600bps, 25mW tx on PC side, 300mW tx on loopback.. With rather poor results until I put my finger on the loopback chip (the PC side was not really warm) to test if it was hot.
3sec max after I put my finger on the chip it started pushing 100% link, and every packet went through :P.
I really think cooling should help them work better than without.
Has anyone used the RSSI pin on these devices yet? The reason I ask is because if the output of this pin drops whenever these devices require a reset due to this duty cycle problem then I'm thinking I could use this to disable my SSC which should switch the Ardupilot to RTL.
Replies
I wrote a small program which just basically simulates sending servo position update packets via the XBee 868 to a receiver unit. What I tried out now is to simply reset the modem and wait for a small moment before retransmitting data, between every full update packet.
Of course this is not optimal, it should not reset so often etc, but I did it like this to test the theory with minimal work.
And it works like clockwork, but it does have a delay between payloads and thus is slower than it would be without the reset and delay. So I will work on an optimal transmit loop count between resets based on my payload, and anyone else could do the same.
To reset the modem connect a cable between the RST pin on the adafruit module and one of the digital pins on the Arduino/ArduPilot.
Then just simply add this:
in void setup()
pinMode(resetPin,OUTPUT);
digitalWrite(resetPin,HIGH);//set the RST pin high, low will reset the module
And then in the loop code with apropriate counter (you can find this out easily if you transmit a same size payload every time, otherwise make it low enough to be safe - otherwise use response ACK packet timeout to activate)
delay(TXdelay);//wait for data to transmit
digitalWrite(resetPin,LOW);//press reset
delay(RSTactiveDelay);//spec minimum is 100us to register
digitalWrite(resetPin,HIGH);//release
delay(RSTrecoverDelay);//wait for XBee to initialize
Of course you'll need to tune your variables for your particular application, and define them.
Like
servo actions, motor, video streaming, Chat window. or file transfer ...
let me know.. Thanks, Mogly
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.
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();
}
Erwin
I ve got the Pro868 myself... and i am more than disappointed.
Have you or anyone found a work around and operate it with a highter duty cycle beyond ETSI regulations? Think I might be going to sell this crap again...
Jay
It features some way to limit transmitted data to a minimum to keep duty cycle low.
I tried 50 bytes, 9600bps, 25mW tx on PC side, 300mW tx on loopback.. With rather poor results until I put my finger on the loopback chip (the PC side was not really warm) to test if it was hot.
3sec max after I put my finger on the chip it started pushing 100% link, and every packet went through :P.
I really think cooling should help them work better than without.
Has there been any further tests/progress with these Xbee's?
-
1
-
2
-
3
-
4
of 4 Next