Rotational Speed Error floods Event Log

The descriptions of the following Events were:
106 ‘Rudder limit reached’.
108 ‘Elevator limit reached’.
109 ‘Aileron limit reached’.

As we received continuous requests for explanation and clarification of the meaning of these Events, we changed the description as follows:

106 ‘The required Rudder speed is higher than the model can achieve’.
108 ‘The required Elevator speed is higher than the model can achieve’.
109 ‘The required Aileron speed is higher than the model can achieve’.

This is because when the pilot, using the aileron, elevator and tail sticks, asks the model while it is in flight for a high rotation speed on one of the three axes (or on more than one axis at the same time) but the gyroscopes bring the controls to maximum (more than the maximum the controls cannot go), it means that the aerodynamics and mechanics of the model cannot achieve the required rotation speed.

To increase the rotation speed on the three axes, you need to increase the rotation speed of the main and tail rotor blades (perhaps by using a tail pulley with fewer teeth), or use blades with greater aerodynamic efficiency.

If even with these changes, one or more of the events 106, 108, 109 continue to occur, it means that the maximum rotation values set in the flight controller cannot be reached by that specific model with the current configuration and must therefore be reduced (ADVANCED, Setup tab, ‘Max Rotational Speed’ values of Aileron, Elevator and Tail).

It would be important to understand if these events occur in your flight controller while the model is in flight or while it is resting on the table and is unable to respond to commands and rotate.

I would remind you that in order to return the tail control output signal to the centre, in addition to using the tail stick, you can also disable momentarily the Heading Lock function by switching the tail gyro to Normal mode by reversing the polarity of the tail gain and then immediately reactivate the Heading Lock function.

I understand the points you made, but the flooding occurred in flight while the heli was NOT turning for a significant portion of the flight.  I had just replaced the tail blades and wasn't making a lot of rudder movements.  I was more concerned with checking tail vibration and any wagging.

Just checking. The Event file I sent DID have the events flooding for Log #8, yes?

In the Event file you attached to your first post above, there are never any references to any flight logs except for the beginning of a Flight log No. 1 which was immediately interrupted and deleted following the connection to the software app.

@customercare My Bad!  Now you see why I was asking about the file name on the configurator!  However, strangely, on my computer, the same file has literally hundreds of entries for the 106 error. I have reattached another copy; here is a sample from the start of the file.

$N$;Brain Logs;BRAIN2 3.4.220;3.4.221;0017119C6030A503;0
Events Time;Log N.;Events Code;Events Type
1;;8;Receiver connected
7;;1;PowerOn
7;;2;Coldstart
7;;3;All of the Self Tests passed successfully
7;;51;Setup 1 loaded
7;;4;Receiver Signal Ok
7;9;6;Logs Recording Started
57;9;61;App connected Log stopped & deleted
88;8;106;The required Rudder speed is higher than the model can achieve
88;8;106;The required Rudder speed is higher than the model can achieve
89;8;106;The required Rudder speed is higher than the model can achieve
89;8;106;The required Rudder speed is higher than the model can achieve
89;8;106;The required Rudder speed is higher than the model can achieve
89;8;106;The required Rudder speed is higher than the model can achieve
89;8;106;The required Rudder speed is higher than the model can achieve
89;8;106;The required Rudder speed is higher than the model can achieve
89;8;106;The required Rudder speed is higher than the model can achieve
89;8;106;The required Rudder speed is higher than the model can achieve
89;8;106;The required Rudder speed is higher than the model can achieve
89;8;106;The required Rudder speed is higher than the model can achieve
89;8;106;The required Rudder speed is higher than the model can achieve
89;8;106;The required Rudder speed is higher than the model can achieve
89;8;106;The required Rudder speed is higher than the model can achieve
89;8;106;The required Rudder speed is higher than the model can achieve
89;8;106;The required Rudder speed is higher than the model can achieve

OK, now this new Event log unlike the previous one, although it has the same name, shows flight number 8.

Now the events correspond to when in the graph the tail command arrives at +100 with the normal slight time offset from the graph caused by the fact that the logging of events already starts during initialisation, before the logging of logs starts from zero only after initialisation has ended.

In the list, the event occurs seven times (at seconds 89-90, 195, 248-249, 291-300, 333, 349, 379),
and although out of phase as explained above, even in the graph the tail output signal reaches 100% seven times:

In some cases the event lasts for many seconds and many of the events are repeated several times in the same second.

Even a simple observation of the graph of the tail output signal curve shows excessive oscillations and a strong ‘noise’ of the output signal.
By zooming in on the Tail Out signal, oscillations (numerically reduced due to the low sampling value of 20Hz) of considerable amplitude are visible, which cause the repetition of events because, despite the fact that different activation and deactivation thresholds are implemented for the events, the signal has huge oscillations that exceed the thresholds: between 100% and 40%:

These large oscillations are a phenomenon almost certainly generated by excessive gain (which is in fact greater than the defaut value of 45%. It is at 60%).
Normally these large oscillations in the tail caused by excessive tail gain are highlighted by a particular and specific sound phenomenon (similar to that of a bumblebee in flight), clearly audible to the pilot who should know that when the model generates this typical sound, the tail gain must be reduced. Usually this is done directly from the transmitter via a radio channel dedicated to this function. In this case, however, software gain has been selected because the transmitter evidently has a reduced number of channels (5 or 6 channels), which has forced this function to be dispensed with. The tail gain will therefore have to be reduced by integration or apps.

Even if event repetition can, as in this case, help pilots who are less experienced in tail gain adjustment to realise that repetition is a symptom of excessive tail gain, in order to avoid recording almost 40 events of the same type in a single second, and to avoid saturating the list of the same events, in addition to different thresholds for activation and deactivation, we would also introduce a second function that prevents the recording of the same event more than four times every second.

We would also point out that, while the model is in flight, the average value of the tail output signal (Avg value) instead of being close to 0% is about +27%. Therefore, on the one hand the maximum excursion is only 73% while on the other hand the maximum excursion is 127%.
This means that the neutral tail position is incorrect.
The neutral inclination of the tail blades must be such that it counteracts the torque generated by the main rotor blades (it is usually ‘around’ 4 degrees of pitch). This allows the maximum excursions to be symmetrical.
The correct adjustment is made by lengthening or shortening the tail control link from the tail servo to the tail rotor mechanics. Obviously, after moving the centre position, the limits must be checked and adjusted again.
Correct adjustment can be checked by deactivating the Heading Lock function in flight, and checking that the model tends to turn on itself as little as possible, but to do this would require a transmitter with a radio channel available to change the tail gain in flight, and in this case it is not possible (but it is possible changing the active Setup).

Note: Elevator and aileron signals also show oscillations, even if they are very low. However, this could be caused by the tail oscillations affecting the flight controller sensors. The tail therefore needs to be adjusted before further evaluation.
A drop in RPM is also visible when the elevator controls go to maximum, so in this case it might be useful to increase the value of the ‘Cyclic Precompensation’ parameter in ADVANCED, tab Common section 6 Thrott.&Gov.

Thank you.  This makes a lot of sense.  I won't be able to try some of the suggested changes immediately, as we are experiencing periods of bad weather here in Western Australia.  I do have extra channels (I have a TARANIS X9+ (2019)), but I chose not to use them as I wasn't sure I could set up the extra channel properly.  I'll have a look at that also.  However, that will be sometime in the next week or two.

@customercare Thanks Rik.

To make sure I understand, proper tail gain is 45%? Would you recommend to use rate mode so the tail is centered in rate mode first while using the Windows program? I'm chasing all gremlins affecting the Fenestron. My next project currently on the bench is a Vario H145T2 800 size and, rich with previous experiments with Roban's H130, I'm hopeful it will fly as well. My second H130 flies even better than the 1st one and I can now achieve decent side slips against torque. The reason I have rate mode programmed in the FCU and assigned mix to one X20 3 position switch, is to look for any improvement in forward flight. It is recommended by hardcore Vario pilots, saying "lock mode" will impose too much wear on the servo and hardware and cause eventual failure. I doubt it. 

brg romeo😊