In RL, (as we all know) one can slowly adjust the elevator trim wheel, or "flip": it around abruptly, for big trim changes.
This use to be simulate very nicely by Holding the assigned key down, increasing the trim speed.
It now no longer accelerates, which is a major regression from its correct behavior (by the SDK) that seemed to have got broken a number of SU ago.
SDK SUGGESTION:
in an APPROPRIATE cfg file for each plane
Elevator_Trim _Speed = s, t, f
s = slow speed
t = time before switching to fast speed
f = fast speed
At the moment there appears to be no speed control for the
Trim_Elev_UP
&
Trim_Elev_DN
For backward compatibility, if this NEW parameter is not included, elevator trim works in a default mode (which hopefully gets fixed to include the accelerated trim functionality, defined in the current SDK)
Is there any chance that you or or another Asobo Devs could verify that the Elev_Trim_UP & Elev_Trim_DN events now, no longer accelerate, when assigned to a hardware button, like those on a Yoke/joystick. as defined in the SDK
I have talked to a number of other Devs, who also see the delayed acceleration no longer working, when assigned to a Joystick/yoke button via the MSFS profile assignments
Please, can someone at least confirm that elev-trim-up / dn are not working with acceleration for hardware keys (only seems to work for mouse) which is NOT what is implied in the current SDK.
100+ reads, but no comments . Somewhat disappointed,
So this weekend, replaced the Asobo code, with an AAO script, and now allows manually trimming any GA plane. with trim buttons on a Hardware Yoke or Joystick and is VERY significantly easier.
Maybe one day, this will be addressed…
The new Asobo XML code, added in recent SUs, that TRIES to do this is an “interesting” fascinating read 
I seem to be then only one interested in this, and it is now solved for me, by adding extra processing with AAO.
Demo Slow trim mode, (series of short Momentary presses) then followed by fast trim mode (Long Hold Press)
This may help you guys appreciate the issue, and be able to reproduce it .
(Empty Community Folder)
In SU14 beta, in Su13, and many previous (if not all) previous updates.
Bumping this one with some Graphical PROOF that this an issue between ASOBO default planes.
It is not clear to me, as a non Asobo Dev, why this should work in some Asobo GA planes but not others.
ie Works in the Xcub, but not in the C172s (either A1000 or classic)
Can confirm that some default aircraft have a fully linear elevator trim when holding the joystick button for elev trim up/dn, some start off slow and double the rate after a few seconds, and some start slow, then do a weird jittering thing after a few seconds. c152 and c208 are examples of buttery smooth linear trim, CJ4 have the old slow, then fast.
I can’t find a way to configure this behaviour in an aircraft. How is it determined which trim behaviour a plane should have?
Might be useful if such configuration method was cross referenced in the SDK with
I can’t find a way to configure this behavior in an aircraft. How is it determined which trim behavior a plane should have?
GREAT Question
Answer to my own question:
It seems the hardware input behaviour (single rate / dual rate / dual rate but jittering and erratic) are determined by the elevator trim templates used in the cockpit xml.
An aircraft using ASOBO_HANDLING_Wheel_ElevatorTrim_Template has fully linear single rate elevator trim using joystick hardware button inputs.
An aircraft using ASOBO_HANDLING_Switch_ElevatorTrim_Template has dual rate elevator trim using joystick hardware button inputs. It starts slow, then moves at higher rate. Behaviour can be customized with parameters found in the subtemplate ASOBO_HANDLING_Trim_Variable_Speed_Base_Template
Aircraft using both of these (c172 G1000, DA40-NG) have erratic trim behaviour with joystick hardware button input. They start linear and smooth, then when the switch template high rate phase steps in it appears like the behaviour templates are fighting each other and the trim movement gets jittery.
Maybe these templates affecting hardware inputs like this, and potentially conflicting with each other could be looked into for the future?
Does anyone have any advice to work around this? I’m currently using the default trim buttons on the HoneyComb Alpha. I also have the HoneyComb Bravo Throttle Quadrant however I don’t use the trim wheel on it as I’ve heard it’s even worse. Based on the reply above me it seems like the issue has to do with using the hat switch on a joystick/yoke, so what can we get to try and fix the issue that Microsoft/Asobo won’t fix? Would one of the USB Trim Wheels that get sold on Etsy possibly fix the issue? So frustrating but I appreciate that at least we have two smart individuals looking into it here in this thread 
So frustrating but I appreciate that at least we have two smart individuals looking into it here in this thread
OK, so that earns you a response from me 
!!!
==================
I ended up using AAO to respond to a short press and a long press of the Yoke Trim buttons.
Short press (or continued jabs) = slow movement
Long Press, and it switches to a faster movement
While not 100% correct RW simulation, it works very well in the sim.
Hahaha thank you for taking the time to respond! I honestly didn’t think any was still looking at this thread 
I will try your above steps and see if it works better. I’ve used the AAO demo recently to try to solve the trim issue a diffrent way but I will try your way now
Thank you again!
you can probably do the same thing or similar is Spad. I just started using AAO a few year ago, and its difficult to teach an old dog new trick … and the though of converting all my AAO scripts and setups to SPAD is not something I really want to spend time doing – IF IT AIN’T BROKE – DON’T FIX IT
3 & 9 are how many times it executes the Trim A:Var, for each repeat loop
