Thanks for this tip! For me it always looked like the trim wheel keeps resetting frequently and then AP tries to correct it. I’ll try to set a deadzone for my analog ttim axis tonight and report back. This sounds at least logical.
Let me know how it goes!
Hope it helps!
Okay, tests done. Good news: The problem is indeed the analog trim axis. The bad news is that dead zone will not help. The reason is that the dead zone is only related to “area” around 0-point in the axis (I’m using the -100% to 100% trim axis). This is mapped, in my case, to a 3-wind precision potentiometer. The dead zone only works if I set the potentiometer (i.e. the trim) to neutral before engaging autopilot. Not really practical.
So, I’m not sure if the trim axis of the controller should be completely disabled when AP is engaged or whether the noise from the potentiometer should be cancelled to avoid the trim going nuts.
In my case I have a self-made “button box” using Arduino. I can easily create a software-based low-pass filter to filter out the noisy behavior (I will implement this tomorrow and can report back in case someone is interested) of the precision potentiometer. I hope this will help. If it doesn’t then the only way to sort it out is really for Microsoft/Asobo to change how the analog trim axis is used or not used during different AP modes.
All in all I want to thank you for pointing out the right direction for finding the culprit. When disabling the trim axis completely I can confirm that AP works in ALT hold. C172 can also climb and descent to desired ALT using VS mode (for example).
1 Like
I too confirm the noisy pot was the problem with the AP but as noted by @Nadelbaum3685 the dead zone cannot be a definitive solution as it implies reset the trim wheel to the neutral position before engaging th AP. I have removed the analog axis for the trim control and assigned to two digital button, a better solution would be a rotary encoder or even better someone with a better technical language skill open a zendesk ticket for reporting to developers and see if they can find a solution…
Thanks for sharing this. I didn’t get much time to test last night so I didn’t discover this. I guess I will switch the trim to a button solution for now until I figure something out.
Thanks for sharing this info!
I have rotary encoders for aileron and yaw trim axes, but for elevator axis I want to use an analog control. This is mainly due to flying other simulators like Il-2 Great Battles series.
In any case I’ve now implemented a low pass filter using Exponential Moving Average (EMA) algorithm. I’m sharing this info as I’m also keen on hearing if someone has better solutions in mind based on experience. An alpha value of 0.4 with EMA seems to be working pretty well. I got rid of more or less all the noise and the trim is still very responsive when used. Autopilot functions now as it should 
You can also use a rotary encoder to incement or decrement the value of a register in the arduino and then generate a new stable analog tension from this value and have no noise at all
Apologies for the slightly minor necro (a week-and-a-bit is a long time in sim fandom) but I just wanted to thank the dedicated investigators in this thread, both for their ultimate unpicking of the problem and for their infinite patience when dealing with some of the egg-sucking replies. It was clear there was an issue here, so thank you for being so tenacious.
I am still having various problems with the simulation, some of which may be down to my unfamiliarity with these new systems but many of which I suspect are bugs especially in the realm of autopilot and ATC. Last night the Baron nosedived into the deck three times, twice upon performing frequency changes at the request of ATC and once when I cancelled flight following.
But the biggest common issue, the crazy rollercoaster of AP-based altitude changes, was indeed due to noisy potentiometers on my X52 Pro trim controls. There’s a chance I would have stumbled upon this solution myself in a couple of days – remapping trim axes to buttons was on my to-do list – but to find it all laid out in this thread was a wonderful discovery. Those few extra days of not thinking I was losing my marbles are priceless.
If this information isn’t already in a FAQ or sticky, it should be. I know from my own experience that there’s a fair bit of crossover between users of Flight Simulator and users of Elite: Dangerous and that many of the latter have X52s. Pinning this information somewhere might save a lot of frustration, at least until the developers can code around this problem (the trim pots work fine in other simulators, so it would appear that software filtering is a viable solution).
2 Likes
Please give me the noise suppression code. Better yet, the whole code.
Thats exactly why in the real world the autopilot disengages at stall warning activation.