Version: 1.7.27.0
Frequency: Consistently
Severity: High
High - important feature not working as expected, frequent enough to impact production
Bug description:
When configuring the [autopilot] to have pitch_use_elevator_only = 1, which matches my application, the elevator trim is reset to 0 every frame.
This prevents me from creating a proper trim prompter system where the pilot would be prompted to apply elevator trim to relieve the workload of the autopilot servo acting on the control column.
The autopilot is configured as follows:
[AUTOPILOT]
autopilot_available = 1
flight_director_available = 0
min_feet_for_ap = -1000
min_flight_time_for_ap = 0
default_vertical_speed = 1000
autothrottle_available = 0
altimeter_indicator = 0
attitude_indicator = 0
direction_indicator = 0
use_no_default_pitch = 0
default_pitch_mode = 1 ; pitch mode
max_pitch = 25
max_pitch_acceleration = 1
max_pitch_velocity_lo_alt = 2
max_pitch_velocity_hi_alt = 1.5
max_pitch_velocity_lo_alt_breakpoint = 5000
max_pitch_velocity_hi_alt_breakpoint = 10000
use_no_default_bank = 0
default_bank_mode = 2 ; heading mode
max_bank_acceleration = 5
max_bank_velocity = 10
max_bank = 30
pitch_pid_reset_mode = 2
roll_pid_reset_mode = 2
heading_pid_reset_mode = 2
alt_mode_slot_index = 0
hdg_ref_var = 0
auto_disengage_with_pilot_input = 1
pitch_use_elevator_only = 1
The behaviour I’m seeing was also confirmed by @MattNischan in this thread: Avidyne 550/540 AP not respecting default_bank_mode - #8 by MattNischan
I confirmed that this behaviour happens regardless of the avionics in use by commenting out the panel.xml section of the IFD configuration.
Hello @JimStewart
Is this something we can witness on a particular aircraft of your fleet?
Regards,
Sylvain
Not really, since I’m in the implementation stage in a new aircraft project, as well as at the point where I have to decide if I want to create a virtualisation of the trim wheel and capture of any external trim inputs while the autopilot is engaged to mask the sim’s autopilot behaviour (I’d vastly prefer not to do this).
The autopilot I’m replicating is a Century 2000, with Trim Prompting. Here’s a relevant excerpt from the manual:
The Century 2000 may be ordered as a Trim Prompting autopilot. This means automatic control (autotrim) of the elevator trim is not available on these systems. When the autopilot displays a flashing TRIM UP or TRIM DOWN on the annunciator, the pilot should manually move the trim control of his aircraft in the direction indicated on the autopilot. When the autopilot determines that the trim condition is satisfied, the trim lamp on the annunciator will extinguish and the pilot should stop his trim action.
The behaviour in the simulator is easy to replicate, in that if you use pitch_use_elevator_only = 1 in the [autopilot] section in a systems.cfg file, it becomes impossible to affect the trim with bindings or aircraft inputs.
This behaviour can be found on the default cub.
1 Like
My apologies - I had changed the value of pitch_use_elevator_only during debugging, and forgot to change it back before writing this post.
The bug title and resulting cfg information has been edited - the incorrect situation, as described in my referenced post where Matt had confirmed the undesirable behaviour, is when
pitch_use_elevator_only is set to a value of 1. In this config, the autopilot controls the elevator directly (which is desired), but the sim is overwriting the elevator pitch trim with 0 each frame, (which is not desired).
Apologies for any confusion. My report is still valid, it’s just the configuration value that I initially used to post was incorrect.
1 Like
Hello @JimStewart
This is indeed related to pitch_use_elevator_only, autopilot will enforce neutral elevator trim when this parameter is set to 1.
And this dates back from the very beginning of MSFS 2020.
I’ll have that reviewed, using the Century 2000 as an example.
Regards,
Sylvain
1 Like
Thanks, I appreciate it.
I’ve went ahead and coded around part of the issue by conditionally virtualizing the trim input while the autopilot is active, but the one part that I can’t get around (and is one of the more egregious issues with this problem, for any aircraft which might have pitch_use_elevator_only = 1) is that if the user has any trim already input when the autopilot is engaged, that trim is immediately zero’d out, which can be quite noticeable with higher trim amounts.
Depending on which pitch mode the autopilot is configured to enter into on engagement it might not be too bad, but the Century 2000 enters into attitude hold, so it can be particularly troublesome.
I assume you’ve tried storing the trim value in a custom lvar and restore it with a key event like ELEVATOR_TRIM_SET after AP is engaged? This ends up fighting with the sim and trim stays neutral most of the time?
1 Like
Since it proved to not be worthwhile to fight with the sim, I’m simply faking the trim input while the AP is engaged and rewriting the value once the AP is disconnected.
The sim rewriting the trim to 0 at the moment of AP engagement is definitely one of the issues. Since it instantly goes to 0, and depending on the current state of the aircraft, it can take a few moments for the AP to move the elevators to hold the equivalent force that the trim may have been applying.
For example, my AP is meant to engage into attitude hold. It the user has a nose-up attitude held by elevator trim, when the sim’s AP is engaged, that trim is instantly set to 0, and the sim’s AP has to ‘catch up’ by moving the elevator to hold that same attitude.
The continued rewrite of the trim to 0 is secondary, but also problematic, as it normally then appears to the user that they’re simply unable to adjust the trim. For example, using the default EX1 wheel interaction template with the EX1 settings config (ASOBO_Elevator_Trim_Settings_Config), the user would be able to turn the trim wheel, but the trim input is ignored and stays at 0 degrees.
This is unrealistic; since the AP is only controlling the elevator, the elevator trim shouldn’t be affected (or prevented) at all.
The second half can be masked with custom L variables, which is what I’m doing, but the first half is more egregious and can’t be easily masked.
2 Likes
Well, partially, anyway. If the user is looking outside their aircraft or at the elevator simvars, they’ll see that their trim isn’t affecting how much elevator is required to hold attitude.
I suppose you could also mask the exterior animation also but now that’s a whole wild can of worms. 
-Matt
Yes, I’m masking the exterior animation as well, in addition to the trim indicator inside the aircraft and the tooltip state on the trim wheel. Not really all that much fun…
If the user wants to look at the simvars then yep, they’ll realize what’s going on. But any user with the savvy enough to understand the ‘how’ will also likely understand the ‘why’!