Re: [Paparazzi-devel] Increasing PPM rate

[Gautier Hattenberger]

Hi all,

For ppm receivers, the only measure of quality that we can make is to 
count the number of valid frames during the last second to evaluate the 
frame rate of the ppm signal. The RC signal is considered "lost" after 
half a second of no valid frames, and "really lost" or ("none" on the 
GCS) after 1s.

Only the text (ok, lost, none) tells you if the radio signal is valid or 
not from the AP point of view. The green/orange gauge is a rough 
indication of the signal quality that can tell you if you have some 
jamming, ECM issues or if you are about to loose the link due to distance.

The maximum frame rate is more linked to the receiver than the radio and 
can be different between aircraft. So it should go in the airframe file 
in a GCS section.

For newer numeric receiver that can provide rssi, feel free to make a 
driver for it and fill the frame_rate field of the radio_control 
structure with it, it is indeed the best solution.

Gautier

Le 28/06/2012 01:18, Chris Gough a écrit :
> > 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