Re: [Paparazzi-devel] Increasing PPM rate

[Chris Gough]

> 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.

Nice idea, or what about setting it in the radio xml?

Chris Gough

On Thu, Jun 28, 2012 at 3:42 AM, Stephen Dwyer <address@hidden> wrote:
> 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
>>
>
> _______________________________________________
> Paparazzi-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel



-- 
.