Re: Re: [Paparazzi-devel] Xbee 868 uplink

[Volker Cordes]

Roman, Gautier,

thanks for your answers.

I did not do any further testing due to lack of time, unfortunately. But I carefully read the user manual again and found the following:

Digi says the duty cycle is ETSI compliant and limited it to 10%, amortized for 1 hour. This means signals are filtered in sth like an RC-circuit and integrated to some voltage where 50% low and 50% high cycles of 3V3 add up to e.g. half the voltage resulting in 1.15 V. Or just call it bandwidth usage.
The duty cycle value itself can be accessed via the DC command which results in 0..0x64 = 0-100%.
"50" would be 50% of 10% max duty cycle, that´s 5%.
It´s similar to Aerocomm but they do not limit it and actually let the OEM care for ETSI compliance.

This is not done over a 1 hour period, instead they average 1/10 of an hour (here we are with nearly 6 mins). Digi built this into their firmware which lets the device stop transmission and purge packets (default). See above, other transceiver brands do not limit this and let the OEM take care for it.

There currently is no (documented) means to reset the duty cycle register, whatsoever. Though it seems obvious from Jeremy´s report that a normal reset clears the duty cycle value.


My urgent question: is it appropriate to continuously software reset an autopilot in flight ???
We need to find out about the secret command to reset the duty cycle register !

Furthermore, consider low RF data rate with 24kbps which actually is a throughput of 2,4kbps, according to the data sheet. I think this reflects the duty cycle limitations and could well be lifted on a higher level.

Guess you guys already found all this out...



regards
volker

-------- Original-Nachricht --------
Datum: Tue, 19 May 2009 16:04:03 -0700
Von: Roman Krashanitsa <address@hidden>
An: address@hidden
Betreff: Re: Re: [Paparazzi-devel] Xbee 868 uplink

I can second on this based on my experience with Aerocomm. You can look at my Aerocomm files in paparazzi trunk.

 

What Aerocomm guys do is there is a special procedure to flush the outgoing buffer and tell tranceiver to send the data. 1. data is being sent if there is a delay of certain duration (user configurable); 2. if you issue a special command. 3. if buffer is full

 

I would assume that Xbee guys do something similar behind the scenes.

Jeremy's problem looks strangely similar to the things I encountered while working on Aerocomm module.

 

I will dig in and do some research on this.

 

Roman

2009/5/19 Volker Cordes <address@hidden>

Jeremy

Any progress with it?

the diydrones folks discussed it, too
http://diydrones.ning.com/forum/topics/xbee-pro-long-range-made?page=4&commentId=705844%3AComment%3A61605&x=1#705844Comment61605


regards
volker








Hi,
This morning, I tried a 19200bps datalink instead of a 57600bps one.
19200 is under the RF bandwidth of the Xbee which is 24kbps.
It didn't solve my problem. I always have difficulty to send data to the aircraft.
The downlink frame uses about 30ms every 100ms of the RF link. So the RF link is not saturated by the downlink.

Is there any software flow control for the uplink in the paparazzi uart code, which sends data until it has been recorded, or which waits for a downlink frame end to send uplink data?

Jeremy

--
Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a

_______________________________________________
Paparazzi-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/paparazzi-devel

--
Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-aktionspreis/?ac=OM.AD.PD003K11308T4569a