Replies to This Discussion

Permalink Reply by James Turner on August 15, 2009 at 12:24pm

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.

• ▶ Reply

Permalink Reply by Noth666 on August 17, 2009 at 10:56am

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.

• ▶ Reply

Permalink Reply by Philippe on October 19, 2010 at 7:59am

Which adapter board are you currently using? I am concerned about the maximum current.

Is the XtreamBee board any better than the Adafruit?

• ▶ Reply

Permalink Reply by Reto on March 29, 2009 at 9:48pm

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.

• ▶ Reply

Permalink Reply by JayK on May 19, 2009 at 3:16pm

Reto,

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

• ▶ Reply

Permalink Reply by helitron on June 10, 2009 at 5:42am

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

• ▶ Reply

Permalink Reply by Zachary Long on June 11, 2009 at 12:14pm

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();
}

• ▶ Reply

Permalink Reply by Noth666 on August 18, 2009 at 11:51am

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.

• ▶ Reply

Permalink Reply by James Turner on August 18, 2009 at 3:20pm

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

• ▶ Reply

Permalink Reply by Noth666 on August 19, 2009 at 12:34am

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.

• ▶ Reply

Permalink Reply by James Turner on August 19, 2009 at 1:09pm

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.

• ▶ Reply

Permalink Reply by Noth666 on August 19, 2009 at 11:59pm

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

• ‹ Previous
• 1
• …
• 6
• 7
• 8
• 9
• Next ›
• Page