How to set up 16ch Tx with er9x!

[Kilrah]

I did another test, and come to some worrying conclusion about the PPM out of FrSky stuff. What I said about 8 channels at 100% not fitting in the 18ms frame is really serious. It's usually considered that the sync pulse of a PPM signal should be at least about 4.5ms. With that 18ms frame, this gets violated anytime all channels are at an average of +30%. At 8x 100% the sync pulse is 2ms, which is actually a valid channel. Expect unpredictable results from the model that takes this as input...

Setting the radio to put out 4CH or 6CH PPM is NOT a workaround, there the PPM signal on the receiver starts acting weird when channels have too low a value.

Who's got contacts at FrSky again? They really need to change that receiver framerate to something longer, to something like the standard 22ms.

[MikeB]

I'm not sure the is a problem with 8 channels. Remember the Tx module takes in the PPM data stream, but does not transmit that directly to the receiver (as happened with35/72mHz). The Tx encode this and sends it encoded very fast to the receiver. The reciever than takes this data, and reconstructs the individual servo pulses. Because of this, the receiver does not need to generate a sync pulse, so just chooses a frame rate for the servo pulses. Many of the FrSky receivers have an option to drive digital servos where they send out the pulses twice as fst (every 9 mS).

Mike.

[Kilrah]

I am talking of the receivers that have PPM out (D8RSP, D4FR, D4RII), typically used to transmit all channels on a single wire to multicopter boards, OSDs or such.
They generate a PPM signal with a fixed frame length of 18ms, like for the servos, whatever the PPM is set to on the transmitter. Those 18ms are too short for 8 channels (8x 2ms = 16ms, only leaves 2ms for the sync pulse that could therefore be mistaken for a channel, and we're not even talking of extended limits), and the devices that PPM signal is fed to will just lose sync if channel positions are too high. This could really cause crashes.

[MikeB]

OK, got it, I don't have any of those receivers.

Mike.

[kaos]

He he, see how complicated /confusing this can be. Now let's (you not me ) clarify this a little more.
What happen if we use 2 Flysky RF Module (stock)? or one Flysky one Frysky? or 2 Frysky modules? From what I read so far. two Frysky would be a problem. what about the 1st option and 2nd option? either module as master or slave?

[gohsthb]

The only problem comes if you are using the ppm out on the receiver. Otherwise the receiver is outputting the servo pulses normally.
-Gohst

[MrLyntonius]

Hi Guys, i thought i would let you know i have successfully done this!!! i now have 16 channels sending to my plane!!! OH YEAH!
i am using the standard Turnigy TX and a FRSKY TX that i built into the remote, i am picking up the training ports ppm signal and routing it to the FRSKY TX,
HOWEVER i have found something that i did not expect...
i read earlier in the forum

"If you select PPM, you may choose whether to send 4, 6 or 8 channels out, this applies to PPM16, the first 4 or 6 or 8 channels will go to the Tx module, and the NEXT 8 channels will go to the trainer port. So if you select PPM16, 6 channels, channels 1 to 6 got to the Tx module, and 7 to 14 go to the trainer port.
With PPM16 the trainer port is just being used to provide a connection to the second PPM signal, it is not being used for the trainer function."

Perhaps i have miss understood what Mike has said,
but i found if i use
Protocol: PPM
channels: 8ch

and configure 16 channels in the Mixes, - i get all 16... 8 channels out the Standard TX and the other 8 Out of the Trainer Port TX....

i fiddled around for a few hours tonight and this is the only way i got it to work...
that said i also downloaded the latest Firmware and EEPe ,

im too tired to remember if i tried all the Protocol option after i downloaded the new software,
anyway

PPM - 8CH - 16Mixes = Happy

I can now control each control surface and gyro independently.

Lynton

[Kilrah]

OK, so does anybody have a contact at FrSky, or shall I contact them myself? That's really something that should be addressed.

[MikeB]

MrL: What you describe is what I would expect if you selected PPM16, PPM should only give the normal 8 channels, and the trainer port should be input for tr5ainer operation.

Mike.

[schlie]

... Pretty much expected, as FrSky receivers enforce a too short 18ms frame rate in their receivers (PPM pretty much already can't hold 8 channels that are all at 100% at the same time).

Unless the receiver is capable of recognizing an abridged form of frame-sync encoded in <= 2ms.

If so, FrSky may be willing to provide details; as their transmitter appears to communicate exclusively via PCM to its receiver, although receiving a PPM data stream from the radio; so it may be capable of recognizing some non-traditional abridged form of frame-sync pulse cycle, and thereby allow a frame to be encoded in less time than an otherwise expected; as could easily be done if they allowed a shorter than typical inter-channel low period to signal the beginning of the frame-sync cycle (for example 100us low + >=100us high until ready to begin the next frame; and if not presently, as the firmware in their modules can be updated, it may be possible for them to add such a feature, if an 18ms frame time is important to them.)

[Kilrah]

The problem is not in the communication between the FrSky TX and RX. It's strictly on the FrSky RX's PPM output. The device to which you'd connect it (multicopter board, autopilot,...) expects a standard PPM frame synced through a "long" idle pulse (exactly how long would depend on the actual device, but certainly longer than the 2ms that can happen currently). So the FrSky RX has to provide one to be of any use, and not create its own variation...

[schlie]

The problem is not in the communication between the FrSky TX and RX. It's strictly on the FrSky RX's PPM output. ...

Yes, I shouldn't have commented on something I only partially read, as the thread was clear enough.

However, if the FrSky receiver is generating PPM frames every 18ms; I'd have to assume this is also the rate they're being transmitted (actually likely at a slightly greater rate, as then upon receiving a corrupted frame, the receiver could generate a proxy using the prior frame's data to guarantee a minimum 18ms update rate.)

Thereby, as the transmitter (unless I misunderstand FrSky's product description) receives PPM encoded data, which it measures and then re-encodes as PCM data for transmission to the receiver; if the 9x similarly can't communicate a full frame of PPM data within the same 18ms period, the transmitter best case, will be forced to either send a partially updated data set to the transmitter every 18ms, or waits until after it receiving the whole frame, thereby forcing the receiver to generate a proxy in the absence of receiving an update; or worst case, the transmitter gets itself confused and does who knows what, possibly resulting in the receiver receiving and then doing who knows what.

(Of course, if all 8 individual PWM servo output channels continue to be updated correctly with correct values when the 18ms frame budget is exceed, it implies that at least there isn't a critical issue on the transmitter/9x end regarding frame rate timing budget overrun, and that it's likely isolated to receiver being placed in the position of having to generate more than 18ms of PPM data within 18ms of time; being a losing proposition.)

[Kilrah]

Yep, that's another problem. Their choice of 18ms makes little sense as no 8-channel PPM transmitter will ever refresh the module's input that fast. So there will always be increased latency due to the input and output never being in sync. They should rather choose something like 22ms, longer than the "standard" (8x2)+4.5 8-channel PPM frame, or even better automatically sync to the radio's framerate.

My guess is that they tried to do well by choosing a fast refresh rate to say they are quicker than others, without realising that it makes them actually slower. Let's say the radio sends frame A at 21ms length, FrSky transmits after 18ms. Then the radio sends frame B from 21ms to 42ms, but as FrSky transmits again at 36ms, FrSky will transmit before receiving the last channels from the radio. These will have to wait the next transmission. So there's a lag, which additionally jitters as the 2 windows slide with regard to each other.

Just for fun, I set my 9x to 18ms frame rate, to see where the DJT would stop responding. It unlocks when the sync pulse becomes shorter than about 3.8ms.

[MikeB]

Some of the FrSky receivers have a'digital servo' option that outputs servo pulses every 9mS. Also, while monitoring the current on the ersky9x board, with a DJT connected, I noticed the current dropped for about a mS every 9mS. So I'm going to guess the DJT sends data to the receiver every 9mS, probably the latest converted PPM pulse.
There have been reports of some servos not operating very smoothly with FrSky, this is likely to be the phasing between the PPM and the Tx to Rx transmission. I did a test sending only 6 channels with a 18mS frame rate, and felt the servos were smoother.

We also have PXX protocol (if you update the firmware in your DJT). that can send to whole 8 channels to the DJT in less than 9mS.

Mike.

[Kilrah]

Yep, PXX will be nice. However I'd rather wait for it to reach the "stable" state both from *9X and from FrSky before playing with it

[schlie]

... Just for fun, I set my 9x to 18ms frame rate, to see where the DJT would stop responding. It unlocks when the sync pulse becomes shorter than about 3.8ms. ...

Although not a complete solution, it certainly wouldn't hurt if FrSky could reduce that a bit, as every little bit helps; as something smaller like 2.5ms could still support extended 6ms-2.4ms PPM channels, while providing 1.3ms more breathing room (presuming their PCM encoding scheme can actually support its encoding; as if for example they've chosen to use 11bit channels having a fixed precision of 0.5us, then the maximum range they could even encode would be -/+511us, regardless of the PPM channel pulse width sent to it; on the other hand if they've chosen 1us encoding resolution, then they presumably could support -/+1023 maximum range ~(0.5ms-2.5ms).

Their literature mentions 11bit (3072 resolution) which seems impossible, so I don't know what they mean; not to mention they seem to have re-specified their telemetry async serial protocol to use the same character to denote both the beginning and end of data frames, which seems to needlessly introduce an ambiguity, and is wasteful for frames having deterministic lengths, but that's a different subject.

(And yes, I too believe it would be best if the FrSky receiver derived it's update frequency from the transmitter, however also believe absent the receipt of a valid frame, the receiver should generate its own, so the servo's are guaranteed some minimum update rate, as I understand may be required to maintain the static holding torque of analog servos?)

(And as yet another aside; upon inquiry, FrSky has confirmed they're working on supporting bi-directional serial communication with their receivers, so in addition to the transmission of traditional servo data, a desire for the 9x to define and send messages to the remote transceiver may arise.)

[MikeB]

From the PXX info we have, FrSky say the PPM ranges from 800*1.5(1200) to 2200*1.5(3300), so it looks like they cover a range of 1400uS using a count of 2100 (2048 would be 11 bit). Their resolution seems to be 0.666uS.
The receiver probably always generates 18mS so it can easily switch to failsafe.
Their telemetry protocol follows asynchronous HDLC protocol, a defined 'standard'.

Mike.

[Kilrah]

It's interesting, so I just compiled myself an open9x with riduculously extended extended throws to check. The DJT will take anything on the low side i.e 100us in this case as it's the minimum separation pulse length in open9x (that's "-270%") to 2550us on the high side ("+206%"). Those are correctly replicated on all servo ports. Then things start to get ugly and overflow, interestingly CH1 and CH2 seem to take a it more than the next ones

[schlie]

From the PXX info we have, FrSky say the PPM ranges from 800*1.5(1200) to 2200*1.5(3300), so it looks like they cover a range of 1400uS using a count of 2100 (2048 would be 11 bit). Their resolution seems to be 0.666uS.
The receiver probably always generates 18mS so it can easily switch to failsafe.
Their telemetry protocol follows asynchronous HDLC protocol, a defined 'standard'.

HDLC is a bit-synchronious variable length framing protocol; FrSky seems to have defined an HDLC-like byte-synchronous deterministic length framing protocol. Typically the only protocols which require end-of-frame delimiters are those which have otherwise indeterminable lengths and agnostically processed by lower level protocol stacks prior to being passed higher; as all FrSky frames seem to have deterministic lengths as a function of the their frame identifier field immediately following the start-of-frame-flag, an end-of-frame-flag becomes redundant, as the length of the expected frame was already implicitly defined.

With respect to FrSky encoding given "800*1.5(1200) to 2200*1.5(3300)", it appears they use 12bits per channel to encode a channel pulse-width at a 2/3us/unit timing resolution, and thereby also support the specification of delays as great as 2730us (4095*0.66_us) although likely well beyond any reasonable need, although they could use it to specify their sync-pulse as a virtual channel value having a large minimal width in this way. In any case, if 2200us was chosen to the largest possible channel pulse width needing to be encoded, anything longer such as 2300ms could be defined as the minimum width of a legitimate frame-sync, and thereby FrSky could define their transmitter fames as being as small as 8*2200+2300 = 19,900us, which then if adding a further 100us of margin to allow the receiver to generate it's own update if not receiving a valid frame from the transmitter, it may guarantee a 20ms minimum update period and while supporting a 140% extended PPM servo channels without risk of timing overrun.

[schlie]

It's interesting, so I just compiled myself an open9x with riduculously extended extended throws to check. The DJT will take anything on the low side i.e 100us in this case as it's the minimum separation pulse length in open9x (that's "-270%") to 2550us on the high side ("+206%"). Those are correctly replicated on all servo ports. Then things start to get ugly and overflow, interestingly CH1 and CH2 seem to take a it more than the next ones

As the channel data appears to be encoded as a pulse width, not a variance about some center; a 12bits encoded value with a precision of 2500us/4000units (0.625us/unit) would enable the encoding of widths ranging from some-min-separator-us - 2559us.

(Also yielding the 3072 precision claimed by FrSky, when encoding pulse widths varying between 540us-2460us.)

[MikeB]

I've used sync. HDLC in the past. PXX also is synchronous, and uses HDLC with bit stuffing and CRC, its quite possible this is what FrSky actually send to the Rx.
Have a check here http://en.wikipedia.org/wiki/High-Level ... nk_Control for a reference to HDLC over async.

Mike.

[schlie]

I've used sync. HDLC in the past. PXX also is synchronous, and uses HDLC with bit stuffing and CRC, its quite possible this is what FrSky actually send to the Rx.
Have a check here http://en.wikipedia.org/wiki/High-Level ... nk_Control for a reference to HDLC over async.

My only concern is regarding link efficiency, as unlike lower level framing protocols which must be capable of supporting arbitrarily large encapsulated data frames, there is very limited bandwidth likely to be available for telemetry and/or more arbitrary communication, which by their nature tend to be fairly small packets so every byte available for data vs protocol overhead may be considered precious; and thereby simply noticed that as FrSky had already defined a frame identifier which implicitly defined the number of bytes to follow (discounting any needing be striped, if stuffed), an end-of-frame isn't strictly necessary (although would be if needing to support arbitrary width higher level protocols). But acknowledge that if this overhead isn't carried through to whatever physical protocol they use when encapsulating the same data over their channel hopping scheme, it may not be of much consequence.

However if a single 0x7E flag character may be used to both end a preceding, and begin an immediately following frame; in effect dropping the then redundant end-of-frame flag (as would always be the case for an async channel, as the first byte following any such flag will always be the first byte of a following frame, unlike a sync channel, where an arbitrary number of bits may arrive synchronously, but not part of any frame, and which was not evident from their sparse documentation; I withdraw my concern, as it would then have been effectively addressed.

[Kilrah]

(Also yielding the 3072 precision claimed by FrSky, if capable of encoding pulses varying between 540us-2460us.)

To me we're looking waaay too far - Historically "1024" meant 1us resolution, "2048" meant 0.5us resolution... IMO the only thing FrSky try to imply in their literature by mentioning "3072" is that their pulse timers run at 3MHz, thus with 1/3rd of an us resolution. Then they're fed with appropriate data in whatever way (they say ">11 bit", so that means nothing in terms of the actual encoding sent through RF...)

[schlie]

(Also yielding the 3072 precision claimed by FrSky, if capable of encoding pulses varying between 540us-2460us.)

To me we're looking waaay too far - Historically "1024" meant 1us resolution, "2048" meant 0.5us resolution... IMO the only thing FrSky try to imply in their literature by mentioning "3072" is that their pulse timers run at 3MHz, thus with 1/3rd of an us resolution. Then they're fed with appropriate data in whatever way (they say ">11 bit", so that means nothing in terms of the actual encoding sent through RF...)

A 0.3us timing resolution would require 13bits of data precision to encode the effective pulse width 0-2500us range you measured earlier?

(Although I don't know what FrSky means by 11bits 3076 resolution; if as you suspect, it would imply the channel data is encoded in 11bits @ 1.25us/unit, measured by a 4 cycle/unit (0.3125) clock, to be capable of encoding the pulse width range you measured.

But will effectively loose about half its measured precision if/when rounded to be stored as the nearest 11bit value, being no more precise than -/+0.625us.)

However my gut feel is they use 12bits @ 2/3us/unit (or about, possibly measured with a 2x clock, then rounded), which would provide a timing resolution of 3076 to encode a ~2050us pulse width (encoded as a the value 3075).

[Kilrah]

Yep.
To me the "Resolution: 3072 (>11bit)" is only a marketing term that means there are 3072 steps in the standard servo range that is considered as 1024us for practical purposes, i.e. 3 steps per us, and "better than the competition who use 11bit and 2048 steps", and is unrelated to the actual encoding used to trasmit data. It's just mentioned that way as it's how other manufacturers have been advertising their resolutions in the past.

But as mentioned in another thread, with a PPM source it's probably worse due to aliasing, if the 9x outputs at 0.5us resolution and Frsky samples at 0.33us there's always an imprecision. Not that any of it matters as no servo will be capable of seeing the difference before a long long time anyway

Someone will have to tap a logic analyzer between the STM32 and the CC2500 at some point

[Kilrah]

Have a look here:
viewtopic.php?f=52&t=667

[Kilrah]

I did another test, and come to some worrying conclusion about the PPM out of FrSky stuff. What I said about 8 channels at 100% not fitting in the 18ms frame is really serious. It's usually considered that the sync pulse of a PPM signal should be at least about 4.5ms. With that 18ms frame, this gets violated anytime all channels are at an average of +30%. At 8x 100% the sync pulse is 2ms, which is actually a valid channel. Expect unpredictable results from the model that takes this as input...

Who's got contacts at FrSky again? They really need to change that receiver framerate to something longer, to something like the standard 22ms.

OK, I've just sent an e-mail to FrSky. In the meantime, if anyone uses the PPM output on FrSky receivers, set your 9x to output only 6 channels if you want to be safe.

[GrootWitbaas]

I have seen this myself using ppm on Naze32 with 8ch ...however if you reduce the 100% to something like 75% it will work, but still this is a concern for me. I have posted somewhere else about his, now I know where the fault is.

Note to self ...need to move that post to here where it belongs ...

[Kilrah]

Oh yes, I remember that... hadn't yet noticed the problem back then! Certainly explains it...
The actual allowable percentage would depend on the actual device you're driving with the PPM. Some would certainly tolerate a smaller sync pulse than others.

Here are the screenshots I sent along with the explanation:

[donjuanzx9]

Limited by only the 9x software unlimited channels with this receiver.
FrSky TFR8 SB 8ch 2.4Ghz S.BUS Receiver FASST Compatible.