crossfire protocol via ERLS pitch channel glitches

To the best of our knowledge, with ELRS the most common problem is related to radio channel 5, which with recent firmware versions for ELRS transmitter modules and receivers is used as the "ARMING" command, even when using the 16 channel-wide mode.

On the gitub of the ELRS site, ( https://github.com/ExpressLRS/ExpressLRS/releases) from version 3.3.1 in November 2023 this information appeared:
"Arming must be on AUX1 for safety and feature reasons, having this fixed allows us to maintain small packet sizes and deliver better aux channel options."

This means that radio channel 5 unlike the other radio channels does not have linear behavior, and the sequence of bytes transmitted in packets containing radio channel information changes starting with channel 5.

Channel 5, since, with all other radio systems by default would adjust the tail gain, could also affect the behavior of the other functions of the flight controller.

Also, since ELRS as written above decided to "compress" the size of radio packets containing radio signals, it would be better to use for analog controls the channels before channel 5 (1,2,3,4).

This may be fine with drones, airplanes, boats, cars, motorized gliders, but it is not good with RC helicopters which being more complex than all other types of RC models, in addition to Aileron, Elevator, Motor and Tail must also handle Pitch.

We did a compare of our sources for decoding radio channels with Crossfire protocol and we find no difference between the source version of our firmware 3.4.122 and the sources of later versions.

We can therefore only assume that the problems you are experiencing did not occur as a result of a firmware upgrade of our flight controllers but as a result of a firmware upgrade of the ELRS transmitter modules and/or the firmware of the ELRS receivers.

As we have said many times before in other threads and repeated here above as well, the ELRS protocol was unfortunately not born with even RC helicopters in mind where it is essential to be able to handle 5 channels but thinking only of all other types of models where only 4 analog channels are sufficient for model control.

Therefore, until ELRS allows to be able to disable by means of the configuration programs this anomalous behavior of channel 5 (anomalous for RC helicopters) and therefore of the subsequent channels, the simplest thing is to use for transmitter and receiver modules, ELRS firmware prior to version 3.3.1

Or, another possible solution is to use channel 3 for Pitch and channel 6 for Throttle and instead of channel 5 for full tail gain control from transmitter, use channel 9 or 10 or 11, etc. etc. or disable the tail gain control by transmitter and have it managed directly by the flight controller using the "Is set in software" checkbox.

I am well aware of channel 5 issues and that is why I use the full 16 channel mode 

The problem only starts after version 3.4.122. 

I am able to provide logs to prove the issue

I would look at changes to code to spot the issue but this option is not available to me

Warning!
The OpenTX and EdgeTX operating systems provide a Fail Safe mode called "No Pulses" Contrary to what the description might imply, when a Faill Safe occurs with this mode, the various channel signals are not removed from the output of the receivers, but all signals are set to minimum (to zero). This if it were to occur would cause a simultaneous and instantaneous maximum rotation of the model's aileron, elevator and tail which would be most dangerous. For that reason, for the safety of pilots, spectators, animals and property as well as the model itself, we had to implement a safety function that brings all signals to 0% when the receiver output brings the channels to absolute minimum.
Therefore, it must be prevented that channel excursions can fall below -100% / -105% otherwise if the -110% values are exceeded, the commands are brought to zero by this function.
Therefore, since you signal that at maximum and minimum the pitch signal shifts, we suggest that you check the maximum and minimum excursions of the various channels.

As for the jumps you see in the channel 6 adjustment, however, we have modified in the transmitter the management of channel 6 by having it automatically generate a ramp that rises from -100% to +100% by means of a switch, and recorded by means of the diagnostic section the signal trend. This is the result, and no signal jumps or reversals appear to be present:

The full extent of all channels are set to show the 100% travel at full stick defections

The problem occurs at zero pitch  and a single blip at -+50%.    In other words just using 0 to 100 travel  with 50 being stick at centre.  50 is were the problem occurs and glitches at 25 and 75

Fail safe for pitch should not be doing any ramping normally fail safe would be center except for motor control where it would turn motor off

I would expect fail safe to occur after a period of no frames.  Or immediately on value out of range 

As only pitch channel is effected and no events are recorded then I dont believe failsafe is occuring

The graph above is what does happen on 3.4.122

After that version. The centre can glitch and maybe at25% and 75%. I suspect that related in time. Domain of when frames are reciceved

It could be a erls bug but it was corrected with firmware up to 3.4.122  

Have used crossfire from start on many model I not had this problem on many firmware versions

I would guess I help setup over 50 different brain installations with me owning about 10 on my models 

As you can see above from the two graph, we don't have the problem with 3.4.122 or 3.4.139 fw.

if we don't have and cannot reproduce a problem, we also cannot analyze it, identify it, solve it and verify that is really solved.

At the very least, to see if we can reproduce your problem, we would need to know what transmitter module you use, what receiver model you use, what firmware the two devices use, what ELRS configuration you have, and the configuration file of your Flight Control Unit as written here:
https://www.msh-electronics.com/faq/#Q01

Or here:
https://www.msh-electronics.com/forum/support/when-you-ask-for-support/

I happy to supply my files after the weekend of flying .... I will update to version with problem and post the before and after 

I appreciate it's hard to debug a problem you can't see  I just assumed that it would be easy to reproduce as had problem with two independent systems 

Thanks for trying

I will  post some files as soon I got time to temporarily flash to lastest version

It maybe to do erls version and brain version combination 

I can go all the way to record the interface with a logic analyzer if required

For your info the use of erls is becoming very common with about 10 people out 40 in just my club witch is primary a heli club

I will also check my failsafe mode  I never intend to no pluses as this does not work nicely with frame based protocols

Posted by: @scooper1

↑

The following problem occurs on multiple tx16s, multiple ERLS models and multiple rx's  using multiple brain 2 running the latest firmware for each part

when the pitch channel is at zero then all the cyclic servos jump between positive and negative pitch continuously.  

this problem can be seen in both the recorded logs and real-time logs. in addition, a glitch occurs around +- 50% but only occurs once on each pass through that value

It shows as uncommanded rx pitch input no channels are affected just channel 6

if I go back to firmware 3.4.122 then all is normal and no glitches occur 

this problem exists for the two current firmware versions after this  which include the current latest version as of writing 

To me, this appears to be an issue with crossfire protocol decoding when driven via ERLS rx

I have tried multiple ERLS frame rates  but all at 16 channel-wide mode   most at 333 hz \2   at 100hz\2 the effect is the same but with glitches lasting longer 

before version 3.4.122  i have been using this mode without any noticeable glitches 

 

Do you still have the issue?

I had the same issue. My solution was to put the receiver on 8 Channels instead of 16 (you can use 12 ch mixed also) so you can us channel 1 to 4 and 6 to 9 full rez full rate and I also swap the pitch and throttle channel. Pitch to channel 1 and throtlle to channel 6 as it's generally a fixed value (and not near 0). 

It happens any channel rate and mode for channel six 

Moving pitch away from channel six works and stops the pitch problem

I have raise this directly with technical support I have offered them  to do deep analysis of problem  but no response as lees then 2% use the erls protocol according to them 

So more people recording responding they have the problem the better

The other response they gave was there is no change in erls codebases.... The release notes say different but that old version is not available from severs to test

We suggest careful reading of the following section of the ExpressLRS website regarding possible configurations:
expresslrs switch-config

@customercare 

Please read the support ticket  I mostly understand the erls protocol options 

This is msh bug that your team are not accepting I can not help debug this issue without support from msh

Boiler plate replies are not useful for all sides

I know you don't like erls but it is being used a lot more then your stats show