Re: [Paparazzi-devel] using

[limaiem imed]

Hi,

Well I updated the modems Firmwares to ensure having 0 re-try and then I used the light telemetry file and I get 53 minutes of continue wireless telemetry link ! This is really good.

Now I will try to add more information to the telemetry file I do not need 53 minutes since my flights last 30 minutes. 

Thanks again Christophe for your help !

Imed LIMAIEM
address@hidden

On Sun, Sep 18, 2011 at 11:06 AM, Christophe De Wagter <address@hidden> wrote:

Thank you for the testing. 

a few details:

1) baudrate has no influence, only the amount of bytes. Aerial rate is 24kbps = 2400 bytes/sec x 10% duty cycle = 240bytes absolute theoretical max. Protocol seems to send 50 bytes at a time, so sending 1 by 1 byte = 50x overhead. Grouping packages seems more efficient. (paparazzi default is to just spread them evenly). [see xml below]. Protocol overhead or "efficiency" is more like 50% so max is 100-150 bytes/sec.

2) make absolutely sure you disabled the re-try (could give 10x overhead) and broadcast (=usually 3x transmitting)

3) several modules send data neglecting telemetry. so if you use some of these it will increase your datarate. check using messages view. With the xml below you should get groups of messages every 3 seconds. Anything in between or faster is still hardcoded and will eat your bandwidth. 

4) the phase in the telemetry.xml can be used to put messages together or just apart. The same phase will group messages. 

Here is a new telemetry without the very large actuator and command messages and even lower datarate. 

<?xml version="1.0"?>

<!DOCTYPE telemetry SYSTEM "telemetry.dtd">

<telemetry>

  <process name="Ap">

    <mode name="default">

      <message name="ESTIMATOR"      period="3." phase="0."/>

      <message name="NAVIGATION"     period="3." phase="0."/>

      <message name="GPS"     period="3." phase="0."/>

      <message name="ATTITUDE"       period="6." phase="0"/>

      <message name="DL_VALUE"       period="3." phase="0"/>

      <message name="WP_MOVED"       period="6." phase="3"/>

      <message name="DESIRED"        period="6." phase="0"/>

      <message name="SEGMENT"        period="6." phase="0"/>

      <message name="CIRCLE"         period="6." phase="0"/>

      <message name="SURVEY"         period="6." phase="0"/>

      <message name="PPRZ_MODE"      period="12." phase="0"/>

      <message name="BAT"            period="12." phase="0"/>

      <message name="ALIVE"          period="18." phase="0"/>

      <message name="CALIBRATION"    period="18." phase="0"/>

      <message name="DOWNLINK"       period="18." phase="0"/>

      <message name="GPS_SOL"        period="18." phase="0"/>

      <message name="NAVIGATION_REF" period="18." phase="0"/>

    </mode>

  </process>

  <process name="Fbw">

    <mode name="default">

      <message name="FBW_STATUS"     period="18." phase="0"/>

    </mode>

  </process>

</telemetry>

On Sunday, September 18, 2011, limaiem imed wrote:

Well 

with Iridium.xml, I got nearly 12 minutes at 57600Baud

what do you mean by regrouping them per second ? should I modify period to (let's say 5 for all the signals ?)

Regards,

<?xml version="1.0"?>

<!DOCTYPE telemetry SYSTEM "telemetry.dtd">

<telemetry>

  <process name="Ap">

    <mode name="default">

      <message name="ESTIMATOR"      period="2." phase="0."/>

      <message name="NAVIGATION"     period="2." phase="0."/>

      <message name="GPS"     period="2." phase="0."/>

      <message name="ATTITUDE"       period="4." phase="1"/>

      <message name="DL_VALUE"       period="4." phase="3"/>

      <message name="WP_MOVED"       period="4." phase="3"/>

      <message name="DESIRED"        period="8." phase="1"/>

      <!-- Only one of the following is active at the same time: give them same time stamp -->

      <message name="SEGMENT"        period="8." phase="5"/>

      <message name="CIRCLE"         period="8." phase="5"/>

      <message name="SURVEY"         period="8." phase="5"/>

      <message name="ALIVE"          period="16." phase="1"/>

      <message name="BAT"            period="16." phase="1"/>

      <message name="CALIBRATION"    period="16." phase="1"/>

      <message name="DOWNLINK"       period="16." phase="5"/>

      <message name="GPS_SOL"        period="16." phase="5"/>

      <message name="NAVIGATION_REF" period="16." phase="9"/>

      <message name="PPRZ_MODE"      period="16." phase="9"/>

    </mode>

  </process>

  <process name="Fbw">

    <mode name="default">

      <message name="FBW_STATUS"     period="16." phase="13"/>

      <message name="COMMANDS"       period="16." phase="13"/>

      <message name="ACTUATORS"      period="16." phase="13"/>

    </mode>

  </process>

</telemetry>

Imed LIMAIEM
address@hidden

On Thu, Sep 15, 2011 at 9:09 PM, Christophe De Wagter <address@hidden> wrote:

You have to send less than 150 bytes per second to stay below the legal limit of 10% dutycycle. And those need to be grouped per second since not grouped causes overhead. Then they will work 60 min per hour. Have you tried iridium.xml?

On Sep 14, 2011 12:15 AM, "Luke Ionno" <address@hidden> wrote:
> Hi!
>
>
>
> I've actually done just what you're talking about (a switching circuit) for
> the telemetry modem. I used a MOSFET, with the gate attached to the AUX pin
> on the TWOG, which allowed the telemetry to be switched off (not on,
> obviously) via the GCS, by calling a flight-plan block. (I used a flight
> plan stage timer to bring it back on after a set time.) In your case,
> though, I think the easiest solution would be to connect the MOSFET gate to
> a dedicated PIC chip (or similar, a SMT version would be idea) programmed to
> take the gate pin low for a second or two every 5 minutes, to avoid having
> to tie the timer into the actual Paparazzi flight plan.
>
>
>
> Be aware that people have reported problems with powering XBees up with data
> on the serial line in, though I've never experienced this personally.
> (Apparently it can brick the XBee, requiring a reviving procedure to bring
> it back to life.)
>
>
>
> Hope this helps!
>
>
>
> ~Luke
>
>
>
> From: paparazzi-devel-bounces+nsknews=address@hidden
> [mailto:paparazzi-devel-bounces+nsknews=address@hidden] On Behalf Of
> limaiem imed
> Sent: Tuesday, September 13, 2011 5:44 PM
> To: address@hidden
> Subject: [Paparazzi-devel] using
>
>
>
> Hi all,
>
> Who is using the Xbee 868 pro modules on paparazzi set-up and getting
> satisfying flying durations ?
>
> Well, actually I am using those modules with minimal data link configuration
> files to fly a delta plane and I am getting 6 minutes data link time. This
> is not enough ...
>
> I would like to know if it is technically possible to reset the XBee module
> each 5 minutes. I mean is it possible to ask the processor of paparazzi to
> turn off the power in the pins that are feeding the Xbee module ?
>
> Otherwise, could we imagine a small electronic devise that perform resetting
> task ?
>
> Anyway, those modules are really useless unless we can find a solution to
> the duty cycle issue !
>
> Anyone can suggest me other modules ? (in the paparazzi wik,i there are a
> lot of information about telecommunication devise but are they up to date ?)
>
> Thank you for your help
>
>
> Imed LIMAIEM
> address@hidden
>

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

--
-Christophe 


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