Frsky problem.

[RCModelReviews]

The only way to reduce this jitter is to increase the rate at which the data is sent -- but then you do have to consider that increasing the data rate will increase the temporal density of the signal - to the disadvantage of all users of the band.

One advantage is that the new FrSky stuff is field-upgradable so there may be an update to reduce the jitter effect.

I'll be talking to FrSky over the next few days to see what can be done but as MrSneezy says, it's just not an issue in the air. I fly 3D with huge control-surfaces and 50-degree+ throws but have never encountered any observable effects from the jitter. Ultimately -- when you command the servo to move to a position -- it goes there. The only problem is that instead of taking two equal steps of (say) 3 degrees, it might take 1 step of 2 degrees and another of 4 degrees -- producing the "jerky" movement that you can see. And, as you've observed, with very slow movement or very quick movement, the effect is not apparent.

But stay tuned... I'll have a chat with Eva.

[mr.sneezy]

"temporal density of the signal" LOL Bruce.
If you don't watch 'Big Bang Theory' on TV then you should be !

Sneezy.

[RCModelReviews]

I don't watch much TV (life's already too short) but I have caught a couple of episodes of that series and love it.

Haven't caught the reference to temporal density though

[mr.sneezy]

No, it's just sounds so Sheldon

Cheers,
Leonard

[Allan Warner]

You may be interested to read the other observations on the GiantCod forum http://www.giantcod.co.uk/forum/viewtop ... &sk=t&sd=a

[RCModelReviews]

Yes, interesting stuff indeed. I'm pursuing my own line of investigation.

Strangely (luckily?) enough, none of the servos (digital or analog) I'm actually using in my models show this effect.

[jet760]

Hi All
I Installed the frsky system in my eflite ultra stick with standard jr sevos and jr mini servos with no problems, I have tries a number of jr servos and they seem to work fine

[mr.sneezy]

That thread on GiantCod is very interesting. I wonder if Allan can pass on a question to Bodmer for me (I'm on too many forums already). I'd like Bodmer to repeat the graphical test with a Spektum DSM2 setup for us and post it up to see. Id like to see what the wave shape looks like in comparison to FrSky.

Other random thoughts after reading that thread, to be taken lightly...
My Futaba 8U's (AKA FF8) both out put a very accurate 22.2mS frame (as in both the same period). I think from old conversations with FrSky, Corona and FlyDream, they used Futaba gear mostly while prototyping. This may have lead to some rash assumptions... Why not, I did too. I thought that 50Hz rate or 20mS frames was the 'standard'. I was caught out by it with FlyDream modules when I made my PPM sweep generator (used for range tests), I found that it would not work with them till I slightly increased the frame rate to closer match Futabas.

I measured my FrSky Two-Way RX servo frame period as well tonight, and I get 18.1mS. Slightly less than the Futaba frame rate of 22.2mS. More servo pulses out per second than PPM frames in.

Could it be also that the FrSky module is just taking too long in sending a frame and also decoding the telemetry, and missing the next sync pulse on these short frame handsets ?
Given the module is also decoding the telemetry data and sending it to the comm port, it could be that it's fairly busy right after sending a frame and runs out of time on the handsets with fast frame rates. The result of missing the sync pulse would be dropping a full frame(and resending the previous one perhaps).

Maybe FrSky's engineering people need to add some debug traps into their TX module code to see if it's dropping any incoming PPM frames ?

Question.
How would you counter this theoretical problem ?
Faster RF frames, say 10mS (and 20mS servo pulse periods at the TX) ?

Syncing the TX module with the incoming PPM frame rate and RF frames also ?
That one might be hard, as I think the RF rate cannot be changed once the system is designed. The spread spectrum system demands very precise timing at both the TX and RX.

Digital filtering at the RX ?
Delay the servo pulse output by a couple of frames and look at the slew rates of them and smooth it out. Good, but that means 20-40mS latency, and just as many modelers will not like that as this issue.

So how did Spektrum, Futaba and other sort this out ? High latency ?

More questions than answers, but I'm good at that
Martin

[RCModelReviews]

I've noticed that Futaba's FASST has a degree of jitter on its servo pulses too -- but not quite as much as the FrSky.

In a native 2.4GHz system it would be possible to sync the data rate to the RF section so that (in theory) there would be no jitter at all.

I also wonder if perhaps the reason that Hitec's A9/AFHSSis quoted as having high latency is because they're attempting to mitigate the jitter issue associated with FHSS by buffering a frame and thus being always 1 frame behind.

Right now I'm looking at the *huge* steps forward we're all going to see when we can ditch the module-based concept and go native 2.4GHz. Having a PPM datastream in the transmitter of a 2.4GHz system is really clunky -- the data should be delivered to the RF section as binary values anyway.

[Bodmer]

For Mr Sneezy:

DX5e plot of PPM output:

AR500 Rx output

DX5e PPM plot.jpg (83.72 KiB) Viewed 16010 times

This is a clean plot but you must expect this as the Tx and Rx frame rates are probably synchronised or the data is transported to the Rx digitally and the Rx then synthesises the frames perfectly.

For comparison here is the FrSky 2 way Rx output with a ~18ms frame input period:

Frsky 2 way Rx with ~18ms frame period at handset

PPM log 2.jpg (157.66 KiB) Viewed 16010 times

That one has bad jumps around frames 40 and 85 that causes a fast servo to hesitate rather than slew smoothly.

The FrSky 2 way Rx performs much better with a 22ms frame period:

FrSky 2 way Rx with 22ms frame period at handset

log 3.jpg (78.78 KiB) Viewed 16010 times

Still a little jitter but only one of my servos seemed to notice it. This is as you would expect for a system that does not have matched frame rates.

The plots are created by wiggling the sticks by hand so the overall shape of the waveform is not the thing to look at, it is the discontinuities that are the issue here. I seem to have been able to generate a rather nice "Sine" waveform for the Spektrum test but that is not what you need to look for!

This jitter effect may only be present in the FrSky two way system, the one I have is designed for a Futaba and as I am using it as a "hack" module I guess I have no right to complain really. It does the job for me well enough with the 22ms frame period and I would not have noticed the jitter had I not tested the unit with a 15ms and 18ms frame periods.

ATB,
Bodmer