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: 6793

Reply to This

Replies to This Discussion

You use the same Xbee 868? I did not find a solution. I posted a support ticket by Digi Online Support. The answer I got back is following, which did not convince me very much:

"Thank you for contacting Digi. The XBee-PRO 868 radio is limited to a 10% duty cycle. This means that you are unable to stream data across an 868 MHz product. To resolve you issue, I would recommend decreasing the amount of data being sent and enable hardware flow control."

I must admit I am not good at setting up my connections for CTS/RTS. I do not know if setting up both Xbee modules to CTS and RTS is sufficient, or if I have to setup my com ports to hardware flow control too? A link to some good practical tutorial about CTS/RTS would be nice.

For now, I try to go back to slower bauds rate (9600bds) and limited RF data transfer for long run testing. Just now, my python apps send/receive one 120byte sentence every 10 second. I'll leave it running overnight to see if it's still up and running in the morning. But such slow rate wouldn't be of any use in a ground station case! So I am a bit disappointed about my lack of tech knowledge to make this better, although I probably went through all Xbee forum threads looking for similar cases.

Please expose the specific problem you have and explain your setup, so we can still share some thoughts to go on.

I there is anybody on DIYdrones who has more experience at how to configure Xbee connections for sending simple telemetric data (including how to handle the software data transmission in the most efficient way), I thing we would both learn something positive out of it.

I especially wonder how to calculate the maximal transmission capacity based on the 10% duty cycle the Xbee Pro 868 have. For example, I wonder if closing and reopening the com port every few minutes could help resolve our issue. Well, too many questions and too few answers for now.

By the way, in my current experiment (RF transmission every 10 sec), it is still up and running after 20 minutes.
Hi again. I stood u this morning and the Xbee RF transmission is STILL ON after more than 8 hours! total transmitted data = 378kb without hanging.
I'll stop in an hour or so and increase the data rate by a factor 2 for a second test.

I just thought also: duty cycle depends on module temperature. When it reaches 60°Celsius, it stops until cooling down to take RF again, as I understood it. Has anyone tried to cool an Xbee down to increase transmission rates ? It means a setup with nice transmission rate during a winter flight could eventually be a messy or hanging RF transmission on a summer day ?!?
Hi Retro, I'll unbox mine today and try to replicate the problem you have to see what happens and let you know. what speed did it crash at? I don't remember reading anything about not being able to stream data when I read the datasheet on these before bying them, If this is the case they should have made that clear to people prior to purchase. Then again the fact you have run it for 8 hours is promising.
Hmm... There should be a way to test what the limit is on this, but it might be easyer to do PC->PC.
I do not think it should be a difference with the bps speed setting di per se, but rather with the amount of data being pushed through.
If one would set up a test to send a specific string at 10Hz over the XBee and then if this does not crash it increase the rate until it does - this should give an approx max transmission rate.
I still have to order mine - finally managed to find someone who could do it for me tomorrow. Will be checking this out once I get my modules.
@Reto: Do they get hot when they stop transmitting? Tried pointing a fan at them?
I'm thinking cooling in the airplane itself should not be a real issue, stick a piece of aluminium to the chip of the XBee and make sure it catches some airstream :-). I've been thinking of putting a cooling fan inside my UAV anyways as I expect quite a bit of heat from the multiple DC-DC converters, plus ESC and battery.
When it crashed, I was sending a 120 bytes string at a 1Hz rate at 9600 bauds from PC to PC ! it lasted 10 minutes or so.
As per Xbee 868 references, as long as the temperature of the chip is below 60°C, an one hour average duty cycle of 10% has to be respected. When the chip temp reaches 60°C, a ONE SECOND average duty cycle of 10% IS ENFORCED until temperature goes below threshold temperature.

Exerpts from the reference PDF:
BEGIN EXCERPTS
Duty Cycle
The duty cycle of this radio is 10% averaged over the period of 1 hour. Meaning, if the next
transmission will push the running average duty cycle over the 10% limit, the module will not
transmit until enough time has elapsed to stay under the duty cycle.
Because of heat restraints of the module, a 10% duty cycle over the period of 1 second will be
enforced after the measured temperature of the module rises above 60°C.

CTS flow control:
[...]
Note: It is recommended to monitor the CTS line because of the duty cycle. If the radio cannot
transmit because it will exceed the duty cycle, the UART buffer could be filled up with data and
trigger the CTS line to de-assert.
END EXCERPTS

Current average duty cycle reading:
Duty cycle can be read with API command: ATDC. It returns the percent used of the 10% duty cycle, i.e. if the average duty cycle is 2.5%, the result is 25.
As well, the temperature of the module can be read with ATTP. Result is in degrees Celsius.

In my test loop, I tried to integrate such command mode readings after every 10 loop iterations, trying to read the result in some vars for monitoring. But since I am a neewbie, the reading keeps empty, probably because of some delay missing. While in debuger, in Python command mode I can read the AT command results though. I'll try to tweak my code until I get something. But overall I know entering command mode periodically slows down transmission. Ideally, one should keep track of temp and/or duty cycle while staying in "transparent mode", using the DC result as a parameter for optimal RF transmission (for example slowing down Tx when DC result is reaching 100, increasing Tx when it is below 50 or so).

If anyone knows how to implement DC or TP reading while in "transparent mode", it would be perfect. I read something like that in a forum yesterday, but didn't bookmark... The guy could read RSSI WITHOUT going in command mode and estimated the distance between two Xbees based on RSSI results. This too could be interesting for our UAV purpose, for example having direct command from the ground and switching to AutoPilot or RTL when RSSI gets too bad for Xbee downlink and/or uplink. This in complement of GPS fixed distance threshold or as a nice RSSI variable threshold replacement.

But first, let's get those Duty Cycle readings done! thanks for all inputs.
@James: the Xbee transmission hung at 9600 bauds sending 120 bytes every second (1Hz). I had set up my GPS to 1 Hz and 9600 bauds for this test and it sends only RMC and GGA sentences to keep data flow minimal. I ran for 10-15 minutes before hanging.
Yes, I use the same Xbee Pro 868.
I have tried all bauds rates with the same problem and it runs only 5mins before it hangs.
And only the sender is hanging.
Could you try it with any bauds rate, but half data frequency. If it hangs, cut it in half once more. If not, increase by a half. Would be interesting keeping some experiment stats.
But I think the only way is to keep below duty cycle rate of 10% by reading actual average duty cycle and chip temperature.
Sorry t hear about the troubles you guys have been having.
I was going to buy one of these kits before the end of the month but i might hold out because of my zero experience and your experiences,
Nick
Here is what I found from that unavailable (?) post:
" Q:...so do i get that right i need to send +++ATWR but how often ? 1 once on setup or every second, minute ??
A: (Jack C)
What the ATWR command does is take the configuration you did with the AT commands & stores it in a piece of memory that doesn't get erased during power cycles. It only needs to be run once. From then on, no matter how many times you reset it, it always recalls the stored configuration from flash.

API mode is slower. You should forget about it & start flying.

One other thing. You're probably still in resend mode. You need to get out of resend mode & use broadcasting mode. If you fly in resend mode, whenever you lose contact or change batteries, the sender will buffer data until the receiver comes back. When contact is regained, the sender will transmit several seconds of buffered data & cause your trirotor to crash.

To enter broadcasting mode, use
ATMYFFFF
ATDLFFFF
ATWR
"
I understand your point, but I am sure once ours will be up and running, you'll probably regret not to have a pair handy. And as described before, the kit is very complete for that price.
Please excuse me i am misunderstanding what is being said, but is it actually technically possible to use these Xbees at 315mW transmitting NEMA sentances at 1+Hz without them locking?
Many thanks,
Nick

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

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service