Von: Christophe De Wagter <address@hidden>
Gesendet: 15.07.2010 10:52:13
An: address@hidden
Betreff: Re: [Paparazzi-devel] Digi XBee Pro 868 issues
With the XBee868 modems I used the "iridium.xml" telemetry file which is about the minimal minimal version. I also commented out a few of the remaining hard-coded messages. You can check if you need to do this by making an empty telemetry file. If you still receive messages (other than the 1time boot etc) you should comment them out in the code.
The timing of the messages is quite important. I think the "airocom.xml" telemetry file shows how to make groups of bytes 4 times per second (message period + phase). For the XBee868 you should send maximum 2 packets per second.
The duty cycle stuff is measured with a resistor-capacitor charging slowly. The transmitter has a turn-on and turn-off delay, besides the protocol overhead. I think it is not an extremely precise measurement of the duty cycle so a safety margin is a good thing. So besides the amount of bytes, the amount of packets is also important. Probably, you also want to connect the reset wire to the autopilot "just in case"...
But once all that is solved... you can suddenly fly really VERY far, ...
If you update the xbee868.xml please send it back so I can commit it.
On Thu, Jul 15, 2010 at 12:18 AM,
<address@hidden> wrote:
Hi everyone
Sorry for warming up some off topic issue... i d appreciate your help now.
I cant get my Xbee Pro 868s to run properly. They suffer from the 10% duty cycle limitations for legal use in Europe.
Someone (think it was Christophe) wrote an xbee868.h telemetry file for a minimal set of data transmissions that apply to the rule of thumb of 2.4kbps *10% = 240bytes/s max. I read all the threads here plus the wiki and i was looking around e.g. the Digi support forum. Digi seems to add their overhead "payload" too and this could end up by 2/3 of the data. My conclusion so far: data should be limited to half of it - this means 120bytes/s.
Further I forced the transceivers to not do any retries, no broadcasts and a long packetization timeout (ATMT, ATRR, ATRO) to be more efficient.
Only to find out: the transfer would stop again reproducibly after 20mins or a bit later.
Now (guess it was Christophe, too) someone mentioned there is a set of pprz messages that are controlled by the xml file but others seem to be hard-coded like NAV, GPS, etc. which includes several files.
What is the right approach to it ?
Thanks for helping me out.
Thomas
@Gauthier, didnt you plan to test these 868s ?
_______________________________________________
Paparazzi-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/paparazzi-devel