For a non-flying, not speed-sensitive project I want to use an Arduino microprocessor together with a 2.4GHz module (from a Turnigy 9x V2 and/or a Corona DSSS module). I've read up on quite a bit and it seems this should work easily enough. (Famous last words...) However, I've come across one potential obstacle: For my specific layout I cannot achieve the 20ms cycle time (50Hz frequency) of the PPM. I should be able to achieve 40ms.

My question: Which effect does this have on range (non-critical for me as 50m is more than enough), servo speed (somewhat important), servo strength (very important) and overall responsiveness of the radio (non-critical)?

I'm just starting out with this, so I have no idea what more specialised tools are available. I do have the Arduino Mega 1280.

I have 16 channels to transmit, spread over two 8-channel modules with 8-channel receivers. So, if I start one PPM pulse for module 1and then for module 2, I get a cycle time that is at best 40ms. I hoped that the receiver must be able to sustain one lost PPM signal without ill effect.Maybe if I alternate modules and set servo 1 on module 1, then servo 1 on module 2, then servo 2 on module 1 then servo 2 on module 2....This would be rather complicated as I need to set each channel's pulse both high and low, so if the two channels on the two modules overlap, this would mean a lot of "delay microseconds". I don't know (yet) how fast the Arduino can do this. Maybe it's not an issue at all and just a "few" lines of code...

The arduino should be fast enough, just googled 'arduino ppm generator' and got loads of hits, if all else fails you could use a second microcontroller or write a PPM library for processing two pulse streams at the same time

Yes, I found quite a few, too. But none of the sources I found do two separate PPM streams. A second MC would be a possibility, but mixing and flexibility will be better with one. Luckily, I found that I can directly access the digital out pins - so quickly that I indeed should be able to jump from one module to the other without affecting servo position. #phew#

Going back to my First Person Shooter days, even 250ms was playable once you got used to the slight lag. 250ms is still 4 updates a second, and with a FPS you needed much more twitchy accuracy that you do flying a plane, except maybe landing in gusty winds.

20-30ms is so fast that only the most advanced 3D heli pilot would ever notice the difference, and even he probably wouldn't.

I have heard back from Rafal (radioclone.org) that the 14 channel module simply has a longer pulse length and hence increased latency. He also said that most radios have latency of more than 20ms or 22ms. I have just checked the trainer port of my FC-16 and the time between pulse end and pulse start seems to be around 10ms.

To see the effect of the additional time between end and start on servo performance, I changed my Arduino code to vary the wait time between pulse end and pulse start. Shortest possible time due to computational constraints is around 4ms for a cycle time of around 20ms. The longest time I set it to was 4ms+100ms, giving a frequency of roughly 8Hz. This gave very choppy servo response, even when the stick was moved slowly. However, even my analogue servo was keeping its holding force very well. In fact, with my hand/fingers, I could not detect a reduction. One of the "digital" Hobbyking servos showed jittering at this low frequency. But at a wait time of 40ms on top of the 20ms pulse, I could only detect a _very_ slight lag of the analogue servo. I regard this as absolutely sufficient for my purpose of slow-moving land vehicles. I can make no recommendations for aerobatics or helicopters and also cannot take any responsibility if someone experiments with increased PPM latency and something bad happens...

The old 1mS-2mS pulse width and 20mS frame rates were chosen mainly because of the limited bandwidth available with the old AM/FM RC gear.

Now that we have 2.4GHz and microcontroller encoder/decoders, there's no reason why a much shorter pulse and frame could not be used -- hence those hi-pulse-rate tail rotor servos and gyros.

Of course with native 2.4GHz gear there is no PPM frame and pulses - just a set of numeric values that are transmitted so its a moot point.

I've been trying to lobby FrSky to make a "100% digital" version of their DIY system so that it can be installed into the 9X radio with reflashed software to deliver the channel data in numeric form. This would slash latency and (in theory) allow much better response and precision. It would make FrSky the *only* sensible upgrade option for the Turnigy 9X.

By doing this they could also introduce channel-grouping for those guys flying CCPM helis and the like and add auto model-load to the 2-way versions.