GNS530 V2 vertical guidance not working (resolved)

[RXP 2,338]

@Spug someone else reported another kind of issue with P3D4 and found a solution to solve it: load P3D4 with a different aircraft than usual, using the default F35. It has been known for long time FSX is better loaded with a default aircraft, like the Cessna. This ensures most of the time every internal variables are reset properly. Do you load your FSX with a default aircraft?

[fppilot 4,371]

4 hours ago, RXP said:

@Spug someone else reported another kind of issue with P3D4 and found a solution to solve it: load P3D4 with a different aircraft than usual, using the default F35. It has been known for long time FSX is better loaded with a default aircraft, like the Cessna. This ensures most of the time every internal variables are reset properly. Do you load your FSX with a default aircraft?

Jean-Luc
If you go back to page 1 of this topic, about half way down, you will see me post about my similar experience.  I took some steps, and so far after five subsequent flights, using three different aircraft, I have not experienced the vertical coupling issues again.  However here is something strange I discovered this morning:.

Between when I experienced the issue, and when I seem to have overcome it, I uninstalled my RXP GNS 430 and 530. My intent was to revert back to an earlier version as I had saved the installers.  So I used the 2.4.7 installer (Feb 10).  I noticed immediately after re installation that the startup screen on the gauges clearly show 2.4.9.  So I assumed the older installer installed the current version again.  i.e. I had just effectively uninstalled and reinstalled the gauges.  2.4.9.  And I no longer seem to have the vertical coupling issue mentioned above.

This morning, when looking though my settings to see what I have selected for the 'Optimize settings file' option, I could not find that setting.  It is just not there.  Curious, I clicked  Check Updates.  The window that pops up advises me that updates are available and that  I am using 2.4.4.  Yes, 2.4.4.  Closing the settings window, then cycling the GNS Off and then back On, the initialization shows me 2.4.9.  So Check Updates shows me 2.4.4, and the gauge shows me 2.4.9.

My issue may be cured because I am reverted to an earlier version. Difficult to tell due to the discrepancy between Check Updates and Initialization.

AN HOUR LATER → I am off line writing a new post.  Will post it as a new message here when finished. I reinstalled 2.4.9 and experienced much the same issues as I reported earlier in this topic.
 

Edited March 15, 2019 by fppilot

[fppilot 4,371]

OK. Reinstalled both 430 and 530 back to 2.4.9 and verified via both initialization and check updates.  I flew some approaches. One before I reinstalled, the others afterward, those clearly with 2.4.9..   I confirmed there are issues.

This is today, 3/15.  I state that because this will sound much like what I reported back on Monday 3/11, mid-page on page one of this topic.

To reiterate my earlier message of today, Friday, I discovered earlier today that I may have been using GNS release 2.4.4 when I reported that my GNS 2.4.9 issues appeared solved.  Again, I had attempted to revert to an earlier GNS release, 2.4.7, but after attempting that step, my GNSs were showing 2.4.9 at initialization.  So I was under the impression that my attempt to revert to an earlier release was not successful and that all week I had been using 2.4.9. I have found that was not the case. Please see my earlier message of today for more on that.

I flew three approaches with the Carenado C210, and one with the FSX default Baron 58.

For the first approach with the C210, I was still using a pair of GNSs that showed 2.4.9 at initialization, but reported 2.4.4 via Check Updates.  That approach, from a saved mid-air flight, was smooth and flawless for the entire approach, including vertical guidance down to the decision point..

Let me state here how I fly RNAV/GPS approaches. I am on NAV mode passing the IAF.  There is virtually always a stipulated descent from the IAF to FAF. I have not known of GPS/AP vertical guidance between the IAF and FAF.  I control that descent phase myself. Simultaneously, as soon as LPV or LNAV is indicated on the GPS, I manually switch from NAV to APR mode on the AP. I am normally in level flight and at the stipulated altitude when I reach the FAF, and that is where I am accustomed to the GPS and AP taking control of final descent.  That until I reach a point in the approach where I decide to disarm the AP and fly the remainder of the approach myself.

The second approach was after reinstalling 2.4.9, and confirming via initialization and check updates.  That approach showed issues. I started my descent at the IAF.  LPV soon indicated on the GNS.  I clicked on the APR key of the AP and the AP acknowledged the switch from NAV to APR.  At that same point the AP ALT function disarmed. I immediately played around with the ALT key, the altitude tuning knob and VS Up/Down keys attempting to get back on AP vertical guidance. Through multiple attempts I was somehow able, after several failed attempts, to see APR mode, ALT (Arm), and VS indications on the AP.  However the AP was not using my settings to control VS. I could change the indicated AP VS rate from -200 to -1200 and the aircraft's rate of descent did not change. It stayed at approx -400 to -500.  That started well ahead of the FAF. Once past the FAF I was seeing all red VASI at the runway. The 210 was on a steady descent, but not to the correct point.  I was not in control of the altitude or VS.  I did not finish the approach, instead I reset the flight.

The third appoach in the 210 was attempted with one change.  In the Settings menu under the AFMS Section, I enabled "Engage Autopilot APPR".  The approach went predominantly like the second approach above, but the switch from NAV to APR was automatic and came immediately after LPV annunciated on the GNS.  At that same time the AP ALT function disarmed. This time the VS and ALT functions of the AP were non-responsive. The altitude tuning knob did nothing.  The VS Up/Down keys did nothing. The Alt function key did nothing.  Again I was in a slow steady descent.  This time instead of resetting the flight I instead rebooted my system and FSX.

Then I changed to the FSX default Baron. Same approach. In the Baron I did not have the GNS,  "AFMS Engage AP APPR" selected. In the Baron after passing the IAF and getting the LPV indication on GNS, unlike in the C210, the Baron's AP ALT and VS all stayed lit.  However again I was unable to set an altitude or control VS.  Then as I passed the FAF I lowered the gear.  That brought an immediate and dramatic change.  The Baron abruptly pitched into a steep dive.  Uncontrollable.  It did not slow before doing so.  I quickly clicked off the AP master switch but still could get no control input response.

Using 2.4.4 per Check Updates.  Perfect approach.  Back to confirmed 2.4.9, major issues with AP coupling.  

I might add that I flew this same approach with the default Baron after reverting the GNS earlier in the week (2.4.4) and it was a perfect approach.  So with two perfect approaches (2.4.4) it seems evident it has nothing to do with the airport.  I have a flight planned for this afternoon to a different airport and will use the default Baron with 2.4.9.

[RXP 2,338]

Hi Frank and thank you for the detailed report and cross-flight tests, this helps a lot.

Please note:

• The version in check-update is the gauge file version.
• The version displayed in the GNS V2/GTN is the version of the 'RXP Garmin simulation component'. These are installed in "C:\ProgramData\Reality XP\rxpGnsSim32.dll" and "C:\ProgramData\Reality XP\rxpGnsSim64.dll".
• We usually release both file sets with the same version numbers.

The discrepancy came from the components in ProgramData not being uninstalled (on purpose because these are shared components) and the fact that installing an older version won't copy the files if newer of those are already installed. You'd have to manually delete these files prior installing again.

Now on your findings, I'm looking day-long to this issue and the major problem is that I can't repro at all, everything always flies normally and as expected. My intent is to offer a couple new builds with some options to test-flight different methods which will help a lot finding the root cause of all this.

I still stand puzzled not finding out what is actually happening with some of your systems which is not happening with ours.

[fppilot 4,371]

Flight completed. Into KMBG this time, GPS 35 approach.  Default Baron.  Behavior like what I reported earlier.  Upon passing the IAF and getting the LPV indication on GNS I toggled the AP from NAV to APR.  The AP ALT indication stayed and VS was indicated.  I was already at the final approach altitude this time.  Controlled descent began at about the FAF and seemed shallow.again I was unable to set or control VS.  I lowered gear and noted that my altitude began to drop with a -1000 VS.  I was able to pull the nose up with yoke pressure, but I was then in an unusual nose up attitude and strangely did not seem to bleed off speed.  Disengaged the AP but the fast speed and nose up attitude continued.  I landed OK, but I had the VC pilot's eye viewpoint way above the panel to get any view of the runway.

[fppilot 4,371]

7 minutes ago, RXP said:

I still stand puzzled not finding out what is actually happening with some of your systems which is not happening with ours.

FSX, correct?

Just so you know. I do not have any yoke or quadrant functions mapped to autopilot.  Also, I have a Saitek Multipanel in my system.  It is essentially an autopilot front end.  But since this issue first reared itself last Saturday I have left the multipanel unplugged and have not even run Spad.Next.

So for the past few days I was using 2.4.4 as my gauge without issues. Any reason why the 2/10/19 installer put back 2.4.4 instead of 2.4.7?

This afternoons flight was into the airport I frequent most with the approach most used.

Edited March 15, 2019 by fppilot

[Spug 7]

13 hours ago, RXP said:

@Spug someone else reported another kind of issue with P3D4 and found a solution to solve it: load P3D4 with a different aircraft than usual, using the default F35. It has been known for long time FSX is better loaded with a default aircraft, like the Cessna. This ensures most of the time every internal variables are reset properly. Do you load your FSX with a default aircraft?

The default Baron in FSX is what I fly 90% of the time. Jets have become boring; too high, LOD is less for ground items. I like the lower altitudes, more challenging and fun. Plus you have more traffic, weather, issues with visibility, etc. I will admit its turbocharged, sea level pressure to 25,000 feet. Yes I added an oxygen system to it.

Ok, enough of that.

I've been flying the "Triangle;" RNAV(GPS) RWY 1 at Eglin (KVPS).
This Transition/Approach is selected in the GNS530:
1. Depart KVPS RWY 19, climb to 2500 direct YOUNK
2. Autopilot display: <AP>   HDG   <NAV>   APR   REV   <ALT> 
3. Right turn direct ELISS @ 2500
4. Right turn to RWY 1 @ 2500
5. During turn to RWY 1, glideslope indicators appear on the HSI
6. Autopilot is still indicating that same as on line #2
7. Press <APR>
8. This is what happens: <AP>   HDG   NAV   <APR>   REV   ALT
9. APR is enabled, ALT is lost, nose starts to drop. But wait!!
10. Press ALT again to get altitude back. It comes right back
11. Now we have: <AP>   HDG   NAV   <APR>   REV   <ALT>
   (If you shoot the approach like this with no other input, the glideslope will not be captured.)
12. Here's what I have discovered. At this point, if you press <APR> to disconnect, THEN PRESS IT AGAIN TO RECONNECT, you will get glideslope capture when the plane crosses the glideslope path. It seems that this second press of the <APR> button does NOT disconnect the ALT mode.
13. The message regarding the PROC menu "Enter A/P APR Outputs?" has nothing to do with glideslope capture. Doesn't seem to have an affect one way or the other. 

[fppilot 4,371]

Spug,
That appears to be a great find!  I will duplicate those steps tomorrow at a different airport and post results.

Jean-Luc. I checked my flight log this evening.  I have some split some of my add-on aircraft into two instances.  One instance has the model equipped with GNS, the other instance with GTN.   Looking at the models I have logged time in I am not able to identify with certainty any time in GNS equipped model instances since late August of last year in my Carenado C210.   All of my other flights since appear likely to be in GTN models/instances.

I dusted the cobwebs off of the Carenado C210 on March 6th.  It was then that I noticed the coupling issues.  As reported earlier today, when I reverted to 2.4.4 yesterday the issues were no longer present.  But between 2.4.4 and 2.4.9 I am unable to identify  the release when  the coupling issue started.

[fppilot 4,371]

1 hour ago, Spug said:

Here's what I have discovered. At this point, if you press <APR> to disconnect, THEN PRESS IT AGAIN TO RECONNECT, you will get glideslope capture when the plane crosses the glide path. It seems that this second press of the <APR> button does NOT disconnect the ALT mode.

So to confirm what to test, when on final and the GNS has indicated LPV or LNAV, you press APR  and ALT disarms, you rearm ALT, then disarm and rearm APR mode.  Do I have that sequence correct?

Edited March 16, 2019 by fppilot

[Spug 7]

39 minutes ago, fppilot said:

So to confirm what to test, when on final and the GNS has indicated LPV or LNAV, you press APR  and ALT disarms, you rearm ALT, then disarm and rearm APR mode.  Do I have that sequence correct?

yes, that's correct

[fppilot 4,371]

25 minutes ago, Spug said:

yes, that's correct

In which aircraft have you done that?  I ask so that I can choose additional aircraft to expand that list.  To increase the sample size.

[Spug 7]

19 minutes ago, fppilot said:

In which aircraft have you done that?  I ask so that I can choose additional aircraft to expand that list.  To increase the sample size.

Baron 58 only

[RXP 2,338]

Thank you both for the detailed reports. This begs a few questions though:

About pressing the ALT mode twice:

It is as if FltSim is thinking you're intercepting from above as it is documented in the P3D4 manual:
https://www.prepar3d.com/SDKv4/prepar3d/vehicle/usage/using_autopilot.html

If you want to intercept a glide slope from above, descend through it, level off, and push the APR button twice to disengage and reset approach mode. Then intercept and capture the glide slope from below.

 

Also did you expect the ALT mode to stay engaged in APR mode?

AFAIK, the APR mode maintains altitude until capturing the G/S so in effect ALT mode shouldn't normally stay and the aircraft should fly level??!

[fppilot 4,371]

2 hours ago, RXP said:

t is as if FltSim is thinking you're intercepting from above as it is documented in the P3D4 manual:
https://www.prepar3d.com/SDKv4/prepar3d/vehicle/usage/using_autopilot.html

If you want to intercept a glide slope from above, descend through it, level off, and push the APR button twice to disengage and reset approach mode. Then intercept and capture the glide slope from below.

 

21 hours ago, fppilot said:

Let me state here how I fly RNAV/GPS approaches. I am on NAV mode passing the IAF.  There is virtually always a stipulated descent from the IAF to FAF. I have not known of GPS/AP vertical guidance between the IAF and FAF.  I control that descent phase myself. Simultaneously, as soon as LPV or LNAV is indicated on the GPS, I manually switch from NAV to APR mode on the AP. I am normally in level flight and at the stipulated altitude when I reach the FAF, and that is where I am accustomed to the GPS and AP taking control of final descent.  That until I reach a point in the approach where I decide to disarm the AP and fly the remainder of the approach myself.

Are you bringing vertical guidance active at the point when LPV or LNAV come live on the GNS?  Or when APR is first pressed?  Neither should be the case.  Vertical guidance should happen at the FAF.

If you look at the glide slope sections of the two approach plates below, note the red lines I have added.  Those lines depict the approaches I have been flying, and experiencing issues with release 2.4.9.  Note that yesterday on the approach to KBMG I was at the FAF altitude of 2500 from BEHWY on in. Before the turn to final.  When I was inbound and descending to NITTE and pressed the APR button, the ALT function disarmed.  I was at 2500 and so was clearly below the glide slope.  I was in the FSX default Baron 58.

The APR mode should come live after the turn to final in both cases, and vertical guidance should begin at the FAF.  That is at CEBOD for KPWT RNAV(GPS) 02 and NITTE for RNAV (GPS) 35 at KBMG.  The GNS/AP performance is not correct.  I have clearly been below in all cases.  When I was reverted to 2.4.4 earlier in the week everything worked as expected. 

 

Edited March 16, 2019 by fppilot

[RXP 2,338]

17 minutes ago, fppilot said:

Are you bringing vertical guidance active at the point when LPV or LNAV come live on the GNS?  Or when APR is first pressed?  Neither should be the case.  Vertical guidance should happen at the FAF.

 

Actually it is better than this: the GPS output the necessary signals and these signals drive the FltSim A/P coupling. The GPS doesn't change nor interfere with any autopilot mode unless you enable the "Auto APR mode" and only then it check from pre-conditions and simulates the pilot pressing the APR button on the autopilot.

I'm starting to narrow down the issue as I read all your reports and compare with code changes in the past and live tests I'm conducting. Until recently the A/P coupling has been very basic: override the flight director (somehow) if there is a signal. A few versions ago we've ported some more complex logic to the FltSim A/P code from the X-Plane A/P code. This code is supposed to 'ensure' the A/P modes are properly engaged/active prior overriding the coupling in using more signals and state because it was reported with some FltSim aircraft it didn't engage properly (A2A for example). However it may be in the FltSim version, given the way we override the coupling, it is a dog chasing its tail. I'm reviewing all this now.