Autopilot stops holding altitude

[Boeing or not going 578]

In the newest version I started having this problem. The Autopilot will even though the altitude was intercepted and now supposed to hold, it starts to lose altitude or gain altitude and the plane does not recover. I will turn off the AP and back on, select ALT SEL and VS or Speed and it climbs back up and then holds. Sometimes doing it again disregarding the mode it should be in. This is the first time that happened to me and I have 100 hours in previous versions of the Learjet. Using P3D 4.5 HF3.

[ark 1,288]

 Did this start happening the first time you flew version 4.3c of the Lear, or has ALT HOLD been working correctly in v4.3c and has now 'suddenly' started happening?

Has anyone else experienced this problem in the latest version of the Lear (ver 4.3c)?

Al

[Boeing or not going 578]

On 5/12/2020 at 2:32 PM, ark said:

 Did this start happening the first time you flew version 4.3c of the Lear, or has ALT HOLD been working correctly in v4.3c and has now 'suddenly' started happening?

Has anyone else experienced this problem in the latest version of the Lear (ver 4.3c)?

Al

It happened again v4.3c, holding FL400 it captured, then went to ALT HLD, and started drifting up climbing. I was in vertical speed when capturing not speed hold while this happened.

Edited June 3, 2020 by Boeing or not going

[Boeing or not going 578]

On 5/12/2020 at 2:32 PM, ark said:

 Did this start happening the first time you flew version 4.3c of the Lear, or has ALT HOLD been working correctly in v4.3c and has now 'suddenly' started happening?

Has anyone else experienced this problem in the latest version of the Lear (ver 4.3c)?

Al

Happened a second time climbing to a new cruise altitude. Entered ALT SEL, then used trim to pitch up and then V/S hold, it captured then held and a minute later kept climbing up past FL410

[Flysimware 647]

I found out how you could get this exact situation where the button is still on but the aircraft is not holding pitch. 

You basically can use the default altitude hold key to disable the hold but our button will remain on.

I also noticed how this could happen by accident. The default function to enable or disable is CTRL + Z.

The funny thing is this is similar to SHIFT + Z to bring up the aircraft info top left corner or CTRL + S or CTRL + A to reverse cycle views.

So i am pretty sure your hitting  CTRL + Z by accident and once you do there is no way to notice you have disabled the default hold (besides pitch is no longer holding) as our Lvar will remain on and go out of sync.

Edited June 4, 2020 by Flysimware

[Flysimware 647]

If this is not the issue we found that leaving the sim (like going to another monitor) during a climb or decent to a new set altitude and coming back to the sim after it has reached the altitude is like pressing CTRL + Z.

We are looking into this.....

Edited June 4, 2020 by Flysimware

[ark 1,288]

I did a lot of testing today to try and reproduce the problem you have reported and finally discovered that if you climb or descend to a new altitude using the AP while the sim's screen does not have focus, and then return focus to the sim's screen after capturing the new altitude, the sim's internal Altitude Lock function gets turned off and as a result the a/c can drift up or down in altitude even though the AP ALT HLD is still on.  This seems really strange and I don't know why this happens. There may well be other situations which also lead to the sim's Altitude Lock function getting turned off unexpectedly, but I haven't found anything else so far. Mark and I will be investigating further to see what we can find.

Al

Edited June 4, 2020 by ark

[Flysimware 647]

I confirmed this does not do this in FSX so i think its a P3D bug. But this does not mean we can't fix it because we can't get the same result in the Falcon 50. And they are close in autopilot systems.

[Boeing or not going 578]

44 minutes ago, Flysimware said:

I confirmed this does not do this in FSX so i think its a P3D bug. But this does not mean we can't fix it because we can't get the same result in the Falcon 50. And they are close in autopilot systems.

Thanks for looking into it. I was not on another window out of focus. But I think it is the vertical speed that will cause it to not go into a true altitude hold. The speed hold to capture an altitude was working.

[ark 1,288]

10 hours ago, Boeing or not going said:

Thanks for looking into it. I was not on another window out of focus. But I think it is the vertical speed that will cause it to not go into a true altitude hold. The speed hold to capture an altitude was working.

I've confirmed the issue we found with the AP Altitude lock variable happens whether you use VS or SPD to acquire a new altitude. I understand the 'lost focus' experiment described above is different than your situation, but the result of lost altitude hold is the same so there may be a common cause, and it provides a repeatable failure for testing. Trying to fix something that only happens relatively infrequently and randomly is difficult to say the least. BTW, when it does happen, I think you will find that turning ALT HLD quickly off and then back on will restore the altitude hold function. If so, that would help confirm we are dealing with the same issue.

I put together a possible fix in the form of a new Learjet_35A cab file you can try to see if it makes a difference. The cab file goes in the Lear35's panel folder -- you can back up the original cab file by renaming it. The new cab file is in a folder called Lear AP LOCK FIX in my Dropbox here: https://www.dropbox.com/sh/0jnx27ytfbtwsi6/AAAeLH5BTS_6Ifxq7VU4835Ja?dl=0

While this may fix the problem (correct it when it occurs), it doesn't explain why it happens, so we will continue to see what we can learn. The problem does not happen in FSX-SE (which agrees with Mark's FSX result), but does happen in P3Dv5 HF1 as well as P3Dv4.5HF3.

Al

Edited June 4, 2020 by ark

[Boeing or not going 578]

On 6/4/2020 at 10:33 AM, ark said:

I've confirmed the issue we found with the AP Altitude lock variable happens whether you use VS or SPD to acquire a new altitude. I understand the 'lost focus' experiment described above is different than your situation, but the result of lost altitude hold is the same so there may be a common cause, and it provides a repeatable failure for testing. Trying to fix something that only happens relatively infrequently and randomly is difficult to say the least. BTW, when it does happen, I think you will find that turning ALT HLD quickly off and then back on will restore the altitude hold function. If so, that would help confirm we are dealing with the same issue.

I put together a possible fix in the form of a new Learjet_35A cab file you can try to see if it makes a difference. The cab file goes in the Lear35's panel folder -- you can back up the original cab file by renaming it. The new cab file is in a folder called Lear AP LOCK FIX in my Dropbox here: https://www.dropbox.com/sh/0jnx27ytfbtwsi6/AAAeLH5BTS_6Ifxq7VU4835Ja?dl=0

While this may fix the problem (correct it when it occurs), it doesn't explain why it happens, so we will continue to see what we can learn. The problem does not happen in FSX-SE (which agrees with Mark's FSX result), but does happen in P3Dv5 HF1 as well as P3Dv4.5HF3.

Al

Thanks! I will test it this weekend.