New FrSkyX protocol

I wasn't clear enough The mixer code is working as it should for the mixes in wild.ini. What needs to be changed is the sources for the page 2 mixes for channels 1 and 2. For channel 1 change the source from CH2 to !ELE. In channel 2 change from CH1 to AIL. This will give the behavior needed for elevons, though you may need to change the channel inverts if I didn't translate correctly for your aircraft.

The behavior in wild.ini is like an analog SR latch . When the AIL/ELE stick inputs are changed in a way that AIL+CH2 = CH1 becomes equal to !(ELE+CH1)=CH2 the feedback switches direction and drives CH1 and CH2 to opposite endpoints.

Using outputs as a mixer source is useful in many cases. Maybe we could warn if it's programmed on the channels typically used for control surfaces.

I think this is what you want. (tried 3 online drawing tools and this is still easier)

Oh, ok.

Edit: -> Deleted my Post ( wrong thinking from me)

I was at the wrong way ( i used the Ch mix at 2nd Page to enable the Trim Buttons for booth Servos ) , but now it works with the !ELE as you described it for me ! ( Trim enable at 2nd mix to get working Trims)
Now i have to Pay You a green ? Beer
Thumbs up for hexfet

Jitter Problem.
I done a new Bind with X8r and used Simple for Ele and Ail , here the servos are near noise free. Then i was going to Complex and Mix with your Info ( Ail to Ele and Ele to !Ail ) and the the noise is coming up

Edit2:
I testet Flysky and Frsky D8 again( on 3 TX, 2X 7e and one 8s) with the new Mix from You to verify the Jitter Test . All Protocols on all 3 TX have a little Noise , with Latest Nightly and Latest FrskyX ( it looks and sounds the same)
only the FrskyX Protocol does it more, the ticking sounds twice as fast and it drains more Batt.
now my Brain is smoking

greetings Alex

No more green beer until next St. Patrick's Day! Could use a good bock right now

Not sure about the small jitter. It may just be the noise on the sticks as Arakon suggests, especially since the same behavior is in the nightly build. The Frsky protocols transmit 12 bits per channel and Flysky 16 so a small stick movement will result in a different value being sent to the rx.

Is the connection to the servos digital all the way, or converted to pwm at some point?
Does the jitter happen when the sticks are just centered and untouched?
Does FrskyX still tick twice as fast if you set the channels to 12? If you've set less than 9 then channels 1-8 are sent at twice the 16 channel rate.
The protocol sends a mid-channel value on channels higher than the configured number of channels. Do you see jitter on those channels (e..g. channels 13-16)?

Hello,

1. All Servos connected direct to the Channel of the RX.
2. Jitter comes on Center and on all other Stick Pos. only on Max PWM it stay still
3. and 4. i test later

Used my cheap oscilloscope, Memory Programm attached, all Data with the same Memory Programm -> Ch1 and Ch2 Complex, 3 to 7 Simple ( 3 Throttle without Spring, no Center Pos.) :

RX X8R ( 12 Ch and 8 Ch the same Numbers)
Ch Hz ms
1 55,6 +-1 1,31 +-1
2 55,6 +-1 1,62 +-0
3 55,6 +-1 1,52 +-1
4 55,1 +-1 1,50 +-1
5-7 same as 4

RX D8R ( 8 ch)
Ch Hz ms
1 55,6 +-1 1,35 +-1
2 55,6 +-1 1,60 +-1
3 55,6 +-1 1,50 +-1
4 55,6 +-1 1,50 +-0
5-7 same as 4


Rx Flysky ( 8 Ch )
Ch Hz ms
1 51,1 +-1 1,28 +-1
2 51,1 +-1 1,58 +-0
3 51,1 +-1 1,48 +-1
4 51,1 +-1 1,46 +-1
5-7 same as 4


-> The refresh rate at Frsky and FrskyX looks a bit high it is 55,6 Hz, may be here the litte more noise ? and 51,1 at Flysky a litte less noise ? can it be changed for testing it ?
-> with the Data the more noise from FrskyX comp. to Frsky can not be seen, only some +- Numbers are different (+-1 represent a jumping from ,X to ,X+1 ).

Point 3 and 4 i Test Later and adding it to this Answer.

Edit:
3. Ticking Sound does not change on changing Channel Numbers
4. Channel 13 to 16 does not have any PWM Impulse

-> i think my oscilloscope is to slow for the ms ( PWM Pulse), so i used my Servotester with the Number Display.

RX X8R (12 Ch)
Ch PWM
1 1398 +-5
2 1561 +-4
3 1498 +-3
4 1496 +-2
5 1499 +-0
6 1499 +-0
7 1499 +-0

the Numbers are changing very fast, so it can be some error at the +- Numbers. But i think the tendency is right from big jitter on Channel 1 to low jitter on channel 4. Channel 1 and 2 are Complex Mix ( Stick), Channel 3 and 4 Simple ( Stick ). It is my newest Flying Wing Programm
All Tests with the same Memory Programm
greetings Alex

I have tested 7e d764a03 build plus the 19/3 nightly build and I am getting the same jitter issue only when I am using mixing.
Only happens when the stick scale is high (SW B2) and can be replicated very easily by moving the ELE/AIL stick to full deflection then letting the stick go to spring back to centre. Can get it to do it virtually every time and it still happens if I slowly move the sticks until they reach full deflection.

Looks to me like is it process induced oscillation.

I had some time today to test with my devo 10 and not exactly sure what I'm seeing. Sometimes bouncing of +/- 1 us looking at ppm output. Will have time to hook up a receiver later this week.

It does seem to be much reduced if the curve is set to fixed, no matter what the scale is set to. If you can please check with a fixed curve to set the channel value and see if the effect is less for you. It may just be variation in the ADC readings.

+/- 1us..I don't believe this is a serious discussion when you have ADC pots readings.What impact may have in actual flight a small noise variation like that.
If +/- 1 us is considered jitters I should abandon this hobby.

Hello,

Test the ADC Error.

I done the Test with a new Model Memory, all 4 Stick Channel are Simple and i found some interesting Things

1. The Jitter is variable , i goes from around 2 to 4 Numbers .
2. If i use the Trimm to get to a even Number (1500) for better impression of the jumping, the Jitter changes some time from 1 to 4 Numbers -> Calculation Error from Core of Deviation, or no or to low Filter for Output to RX
3. If i poke the Stick a litte bit and let it sit center again , the Jitter changes form 1 to 4 Numbers -> ADC Converter Filter wrong, to soft ?
4. it looks like it is a bit Run Time dependent -> ADC or Calculation Error ( missing Filter, to soft Filter )

my 2 ct.
@ midelic
Yes You are right, +-1 is not bad.
1-2 is sometimes a little Noise
3 you can see and hear it on good Digital Servos
4 You can see and hear it on Analog Servos

3 and 4 strain the RX Batt to much and heats the Servos up ,dependent on Servotype ( most normal Digital Servos without passiv cooling are getting warm and killing the Motor Brushes over time )

---

I feel thad the Deviation is very direct on the Stick, sometime i think it is a bit to direct. Here is a litte Variable (following the Stick Position) Dead Spot better for the Use or making a User adjustable Dead Spot.
I think some RX are a litte to Intelligent on prediction of the Stick movement, they try to Run faster to the Stick Position with calculating a virtual Endpoint
-> You move from 1 to 15 % Stick fast then the RX try to Speed up the Servo with a Calculated Endpoint at 30 % to Speed up the Servo, then it reads the real Endpoint and stops it to not overshoot ( like the Start and Stop Ramp on CNC Machines Controller )

Its hard to describe in English Words
-> I think the X Series RX Software is a bit to harsh with the Calculation on the Devention TX Software

may be im Wrong and the Source of the Jitter comes from Other Source. Its only my 2 Ct.

Hi,
what is the repository and branch to test this out? I have devo 7e with cc2500 (and others), and some X4R-SB receivers.

I'm expecting X9D+ in some weeks to arrive, but I like 7e form factor, like one wrote it's baby-taranis

Its here:
www.deviationtx.com/downloads-new/catego...xfet-protocol-frskyx

Alexandro wrote: Hello,

---

cut----
Its hard to describe in English Words
-> I think the X Series RX Software is a bit to harsh with the Calculation on the Devention TX Software

may be im Wrong and the Source of the Jitter comes from Other Source. Its only my 2 Ct.

I think you neglect the electro mechanical part.
If you use the trims, only the value for this reading gets shifted and not the spot on the pots.
E.g with the D8 protocol its a difference whether I am using my Devo or the old Futaba with the DFT and its
mechanical trimming to get the rc mids for my flight controller.
It is more easy to find a sweet spot with less jitter using sub trim and the mechanical.

Alexandro wrote: Its here:
www.deviationtx.com/downloads-new/catego...xfet-protocol-frskyx

Thanks, though repository would be much nicer as I'd need to merge this with some of my private changes.

Mr_W wrote: Thanks, though repository would be much nicer as I'd need to merge this with some of my private changes.

bitbucket.org/hexfet/deviation/branch/protocol_frskyx

My misstake, sorry.

I also did a test today with a x8r recveiver, servo's to all channel exept 3 (=power).
I tested with a 7e and a 8s.
with the 8s i had no problems.
with the 7e the servo, connected to the sticks, move in steps with delay. I guess this is the jitter of wich others talk about.

Tom

Same test with Devo 10. Also no problems.

Tom

I still think the jitter comes directly from the analog pots of the sticks.
If I press the sticks all the way to one side, so they can not move, there's no jitter. If I leave throttle at max or min, no jitter. Move the stick just a bit, I get jitter.
None of the switches show any jitter at all, since they're digital.
I see this exact same behavior on a D4R-II via PPM. I also see a decent amount of jitter using a DHJ module (original frsky).
On a Spektrum receiver with SBUS, I see less jitter, but it's there nontheless and behaves the same.. sticks at extremes, no jitter.

So my guess is either:

1) The Frsky protocols don't use any smoothing for analog pot jitter on the Devo side of things.
2) The receivers themselves have different ways of handling the signal. Frsky probably doesn't filter, OrangeRX does.

Also, with a 7e and X4R-SB, I see no delay at all, like what Tom reported.

@hexfet
I discovered a potential problem which may affect binding.
In binding mode The PA is not activated which may lead(or may not) to binding fail when RF Power level is set really low.
Add this line in
static void initialize(int bind)
{

---

frskyX_init();
CC2500_SetTxRxMode(TX_EN);//enable PA

---

}

Arakon wrote: Also, with a 7e and X4R-SB, I see no delay at all, like what Tom reported.

For me it is the other way around: i got delay (a lot) with the 7e and non with 10 and 8s.

Tom

Just wanna confirm this works nicely with 7e and X4R-SB for me.

Although, I have slightly different CC2500 module than this one . In fact, it looks the same, but PA_EN and LNA_EN are different as it uses different RF frontend chip.
To my knowledge, the one with PA_EN/LNA_EN has RFX2401C frontend, and wiring is correct. Mine is XL2500-D03 and has RFX2401 (non-C) and PA/LNA switching works differently. There is CE (chip enable) line, and TX/RXN lines. However, the problem with this board is that pinout is printed incorrectly. As printed on the board PA_EN and RFC are not only incorrect, but also swapped around, like discussed in this this thread . (if 'swapped' is correct word, as they used really wrong signal names here).

PA_EN is connected to CE line on RFX2401
RFC is TX/RXN on RFX2401

To drive this properly, I had to change the code slightly to bring CE line up for both RX and TX. TX/RXN is active high for TX and low for RX.

I did not however do proper range test, but as far as my sight allowed, did work great for at least 150 meters. Response is also fast and I wasn't too much bothered by stick jitter you are discussing here

My test gear is 250 tricopter with Sparky2.0 board running LibrePilot-next. X4R-SB is connected by sbus to sparky.

It is pity though that there is not enough space in 7e for extended telemetry