Disconnecting A/P causes nose dive
Occasionally when I am flying at relatively high speeds, and I select autopilot disconnect, the aircraft nose-dives in a severe out of trim condition. If I am low enough, I am unable to recover the aircraft with up trim before it strikes the ground. What gives?
Comments
Showing a video clip of your event would be better suited as one is not able to tell if you are flying the aircraft correctly.
Most likely P3D's Autopilot kicks in if you were using Z to disengage via the button assignment of your joystick.
Q400 is not using FSX autopilot as such, but it will listen to the commands unless you set: AFCS_FSX_SYNC=0 in the mjc84.ini file
I am using the ini file binds, but I will double-check that there is not also conflicting P3D native/FSUIPC binds.
OK, upon further investigation, the trim jumps to nearly full nose down when I press AP DISC on the yoke. I have no FSUIPC or P3D native binds for that button. Here are some before and after shots of my panel, before and after AP disconnect. Note the big trim difference: https://imgur.com/a/USLc5pJ
Any ideas why?
Thanks, fixed it. Why would anyone enable AFCS_FSX_SYNC?
I guess it should allow the autopilot to accept ones common binds and commands in addition to custom binds through the 400s own files.
Problem is, its not working that well and is often a source for trouble.
I suggest you assign as much as you can through either the ini file or the utility (not sure which version has the latter) and avoid default p3d/fsx stuff
Not quite sure what is triggering your specific issue but the AFCS_FSX_SYNC=1 should not not cause such erratic behavior. It however is in place to allow users relying on default bindings which work well for the most part for those who do utilize it.
Good to hear that disabling it has allowed for the behavior to cease.
Not quite his "specific issue".
The nosedive upon AP disconnect is rather a long standing, well documented problem encountered by many. As a matter of fact, the solution I suggested (fsx_sync=0) , is a cut/paste from a response provided by majestics support team...
@ha5mvo
The OP's issue was during high speed cruise to which @MASTER_WARNING_PTR responded, which is not common to the original issue of the nose dive event during approach. Granted he did also mention if he is close to the ground it is unable to recover. I have executed multiple tests and I do leave this switch enabled and do not experience such issues. It would be good of him to show a video of his issue to see if it is user induced, and or if he is using an improper version of the Q400.
We did offer the suggested fix for that issue for the nose dive events, and there was backend work done to further prevent against such behavior.