Re: [Paparazzi-devel] Increasing PPM rate

[Stephen Dwyer]

Hello,

I think it is still a useful feature, so I would discourage
eliminating it. However, maybe it would be nice to have a command line
option (say, "-rc_max_rate" or something) that lets you set what the
maximum frame rate would be, so that it scales correctly. This way,
you can set the max rate to whatever you decide is appropriate, and
still see an indication if you get a drop in rate. The fine tuning
would also reduce nervousness about a half-orange r/c status when it
is actually working properly. I don't think this would be too hard to
implement.

Just a thought.

Thanks,
-Stephen Dwyer

On Wed, Jun 27, 2012 at 4:18 AM, Gareth Roberts
<address@hidden> wrote:
> Hi everyone,
>
> Thanks for your replies.
>
>
>> When using a ppm encoder that waits for all pulses to arrive you end up
>> with only the slower.
>
>
> That sounds about right, although I'm not using a ppm encoder - the TFR-4
> outputs ppm directly.
>
>
>> If that is the case, it would make sense if different
>> receivers had values less than 50(Hz) because some RC systems run with
>> a lower update rate. A good example is using Spektrum systems at 22ms
>> (~45Hz).
>
>
> If this is the case, this issue is only going to get worse going forward (as
> people switch to 2.4GHz based systems like Spektrum or FAAST).
> It just seems slightly disconcerting as I initially thought the GCS
> indicated frame decode errors.
> In my particular case, the receiver also outputs RSSI as a PWM signal, so I
> may try and do something with pwm_measure, and patch that into the GCS.
>
> Failing that, would it be worth removing this feature from the GCS?
> What are the use-cases for it? Does it provide a decent measure of signal
> quality for an FM PPM receiver?
>
> Cheers,
> Gareth
>
>
> On Wed, 27 Jun 2012 10:20:50 +0100, Christophe De Wagter
> <address@hidden> wrote:
>
>> Many digital receivers have a few fast channels and a few slow channels.
>> When using a ppm encoder that waits for all pulses to arrive you end up
>> with only the slower. The value you see in paparazzi is what you get.
>> Anything above 20 is good enough to fly. So no issue here. I'm not sure
>> you
>> can redefine the frame rate so the gcs is back green?
>> On Jun 27, 2012 4:55 AM, "Stephen Dwyer" <address@hidden> wrote:
>>
>>> Hello,
>>>
>>> I am not 100% sure, but I think the ppm_rate is the frequency at which
>>> ppm frames are received, based on the count of good ppm frames in 1
>>> second. If that is the case, it would make sense if different
>>> receivers had values less than 50(Hz) because some RC systems run with
>>> a lower update rate. A good example is using Spektrum systems at 22ms
>>> (~45Hz). I think some receivers have constant period and varying reset
>>> times, while others have constant resets and varying periods. For the
>>> ppm encoder, you can actually change these parameters, with the
>>> default being the reset period is constant but the total PPM frame
>>> period is varying, so it might change a bit.
>>>
>>> So, I don't think you can really expect it to be 50 every time, and
>>> having a different value is fine. Hope that clears things up a bit.
>>> Someone please correct me if I am wrong.
>>>
>>> Thanks,
>>> -Stephen Dwyer
>>>
>>> On Tue, Jun 26, 2012 at 7:44 PM, Chris Gough
>>> <address@hidden> wrote:
>>> > Hi Gareth,
>>> >
>>> > Me too, using "Cockpit SX -> IDP7 -> PPM encoder" (always has, right
>>> > back to the SVN days). It did cause me pause to wonder, but  I'm not
>>> > aware of it causing a problem.
>>> >
>>> > I never checked bcause I don't have a scope/logic analyser; is the PPM
>>> > signal actually a bit slow (or is it being under reported)?
>>> >
>>> > Chris Gough
>>> >
>>> > On Wed, Jun 27, 2012 at 9:45 AM, Gareth Roberts
>>> > <address@hidden> wrote:
>>> >> Hi all,
>>> >>
>>> >> I've got a radio conf file that seems to be working fine, except that
>>> the
>>> >> ppm_rate in messages is constantly around 47/48, rather than 50. It
>>> >> all
>>> >> seems to work fine, and I've flown with it quite a few times without
>>> issue.
>>> >>
>>> >> The file in question is
>>> >>
>>> https://github.com/blutack/paparazzi/blob/v3.9/conf/radios/FrSky_TFR4.xml
>>> >>
>>> >> I've searched both mailing list archives & code but can't figure out
>>> >> if
>>> this
>>> >> is an issue, and if so how to solve it?
>>> >> If anyone has any ideas, please let me know.
>>> >>
>>> >> Cheers,
>>> >> Gareth
>>> >>
>>> >> _______________________________________________
>>> >> Paparazzi-devel mailing list
>>> >> address@hidden
>>> >> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>>> >
>>> >
>>> >
>>> > --
>>> > .
>>> >
>>> > _______________________________________________
>>> > Paparazzi-devel mailing list
>>> > address@hidden
>>> > https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>>> >
>>>
>>> _______________________________________________
>>> Paparazzi-devel mailing list
>>> address@hidden
>>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>
>
> _______________________________________________
> Paparazzi-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>