GNS530 V2 vertical guidance not working (resolved)

[RXP 2,338]

13 minutes ago, fppilot said:

Apologize that I do not have RXP gauges configured into any of the FSX default aircraft.  Just do not fly them.

Not a problem not flying them, however, easier to have a known common ground for comparison. In this case, I'm wondering how would the B58 or Mooney (both defaults) would react when flown to your KRWT scenery then.

[fppilot 4,371]

We may have been typing posts at the same time.  KRWT is a freeware add on airport. I made the approach several times, with two aircraft per my earlier message. CArenado C210 and Milviz C310.  Similar results except the Milviz C310 went into a very steep dive from which I could not recover.  That happened when with no annunciation of either Alt or VS, I subsequently pressed the Alt key on the AP.  In the case of both aircraft I could no longer command control of altitude with the AP.  AP ceased responding to inputs in both aircraft.  Shallow uncontrolled descent in the case of the 210, steep descent in the case of the 310. 

I replaced the .ini files for each individual aircraft before reinstalling as I anticipated they lacked settings relative to some updates, such as the AFMS section settings. What I was attempting to preserve was my 5th parameter work.  The current .ini files are dated today, the reinstall may have written new ones.

[RXP 2,338]

@fppilot let me recap because I get confused:

1. Only at your freeware KRWT there was an issue with these 3rd party vendor aircraft. Can you please fly the same with the default B58/Mooney to compare whether the issue is the aircraft?
2. You've replaced the ini files with another one? which one then? What about removing the ini file altogether and use all default settings? (for this, after a backup just in case, just delete the [GNS_530_1] or [GTN_750_1] section but leave the instances sections alone (the one you reference with the 5th param).
3. Did these aircraft on this airport used to work before ok and if so with which GNS version if you remember?

[fppilot 4,371]

58 minutes ago, RXP said:

@fppilot let me recap because I get confused:

1. Only at your freeware KRWT there was an issue with these 3rd party vendor aircraft. Can you please fly the same with the default B58/Mooney to compare whether the issue is the aircraft?
2. You've replaced the ini files with another one? which one then? What about removing the ini file altogether and use all default settings? (for this, after a backup just in case, just delete the [GNS_530_1] or [GTN_750_1] section but leave the instances sections alone (the one you reference with the 5th param).
3. Did these aircraft on this airport used to work before ok and if so with which GNS version if you remember?

1. It might be a couple of days before I can do so. Involved in some other activities. I do not have RXP installed into any of the FSX default aircraft and other than continuing to track down this issue I am done with KRWT.  Was part of a one time trip.
   
   Question: Is there a setting in the AFMS section that allows the GNS to signal the AP to pick up an approach earlier than the IAF and track it on in?  If so I may wish to disable that setting.  Seems like I was seeing LPV annunciate on the GPS, the AP to switch to APR, and the AP's ALT function to extinguish, with no VS either.
    
2. Same as 1.  I'd prefer to fly into a couple of different airports as tests.  The fact that the same aircraft, GNS, and my familiar KBMG worked like they are supposed to has me suspicious of that one airport.
3. First time I had flown into KRWT. But as for KMRY I have been in and out of that airport. It is Orbx.  I will see if I fly in and out of there again with the 310, again with the 210, and perhaps with another aircraft. 

[RXP 2,338]

@fppilot It would be great to compare all of us on the same basis though, and the B58/Mooney at KVPS RW19 is working fine on our end, with the sequencing happening like I've described (and expected in regard to the GNS V2 and/or GTN).

As for the settings, there is not much that I've already mentioned in my past PM. The only setting which might have an effect is "Transition to Approach".

At least, when using default settings and not changing anything, and even more flying the test flight at KVPS as described, you shouldn't be concerned about which one is affecting the sequencing/coupling. This flight just takes 5 minutes max if you use the x4 simulator rate between takeoff and YOUNK. This allow you to try out different combinations of settings quickly too.

Please note the GTN/GNS V2 will change the Autopilot Mode to APPR if and only if:

• "GPS Selected" enable
• "Engage Autopilot APPR" enable
• There is a VDI signal AND the GPS signals 'APPR' (up to the GPS when it signals this).
• The aircraft autopilot is ON

When all these are met it will send the FltSim "APPR HOLD ON" command.

Otherwise if any of these is not valid it won't change the modes at all. Which means if you disable Engage Autopilot APPR setting the only reason the autopilot changes modes is the autopilot itself.

As a matter of fact, the autopilot interface to the GTN/GNS V2 hasn't changed much since the first version. The only difference is that it is now more conservative prior 'overriding' the flight director in making sure the correct signals are valid, whereas before it didn't take as much precautions and was just using the CDI 'valid' signal. In addition, since the introduction of the AFMS settings, it now also uses additional signals (more conservative as well) to determine whether it can override. And since the last 2 versions, you can now enable the "Engage Autopilot APPR" setting for aircraft with stubborn autopilots. This is not a Garmin setting in itself, just a gauge implementation to ease autopilot and aircraft integrations.

Nevertheless, it might help others so here is a copy of my PM with some AFMS settings details from the Garmin GTN Installation manuals:

Transition to Approach

Enabled

• Vertical path attempts a smooth transition from en route to approach vertical guidance
• Aircraft intercepts with approach guidance from below the glidepath/glideslope

Not Enabled

• En route VNAV terminates at the waypoint prior to the FAF on approaches with vertical guidance
• En route VNAV terminates at the FAF (LNAV only)

 

Here are the possible autopilot functions configured and typically reported in the AFMS document.

Coupling the Autopilot during approachesCAUTION

When the CDI source is changed on the GTN, autopilot mode may change. Confirm autopilot mode selection after CDI source change on the GTN. Refer to the FAA approved Flight Manual or Flight Manual Supplement for the autopilot.

Analog only autopilots should use APR mode for coupling to LNAV approaches. Autopilots which support digital roll steering commands (GPSS) may utilize NAV mode and take advantage of the digital tracking during LNAV only approaches.

GPS Selected

Enabled

This installation supports coupling to the autopilot in approach mode once vertical guidance is available. To couple an approach: Once established on the final approach course with the final approach fix as the active waypoint, the GTN will enable vertical guidance.

Vertical Guidance CONFIRM AVAILABLE
Autopilot ENGAGE APPROACH MODE

Not Enabled

This installation prompts the flight crew and requires the pilot to enable the approach outputs just prior to engaging the autopilot in APR mode. To couple an approach: Once established on the final approach course with the final approach fix as the active waypoint, the GTN will issue a flashing message indication.

Flashing Message Button PRESS
“Enable APR Output” Button PRESS

If coupled, Autopilot will revert to ROL mode at this time.

Autopilot ENGAGE APPROACH MODE

[fppilot 4,371]

19 hours ago, RXP said:

Not a problem not flying them, however, easier to have a known common ground for comparison. In this case, I'm wondering how would the B58 or Mooney (both defaults) would react when flown to your KRWT scenery then.

Just completed two approaches in to KRWT with the FSX default B58 configured with a pop up GNS530.  Loaded the same enroute plan I have been using with the C210 and just switched aircraft.  Did not change any GNSv2 settings from default other than auto save flight plan and legacy knobs.  Approaches were perfect.  Noted all of the GNS settings.

Loaded the same enroute plan again, staying in the C210 this time.  Went into GNS settings menu and duplicated the B58 settings.  Flew the approach and it too was perfect.  Before duplicating the B58 settings,  for my settings for the GNS in the C210 I had the first five options and Connect CDI Mode to NAV/GPS checked in Panel Instruments, and in the AFMS/Main system I had GPS Selected set to "Prompt".  To match the B58 I changed the 210 GNS settings in Panel Instruments to just the first three options plus Connect CDI Mode to NAV/GPS, and changed the AFMS/Main System setting for GPS Selected to "Auto".

The airports did make some difference because at KBMG and other airports my GNS settings in the 210 were working, and working prior to adopting the more default like settings this morning from the B58.

I will try your KVPS approach later, with both a GNS equipped and with a GTN equipped aircraft.

Edited March 12, 2019 by fppilot

[Spug 7]

Did the flight (YOUNK.RNAV 01) at KVPS with the Baron 58 using the different GPS settings:

GPS Selected Auto/Engage APPR Enabled
GPS Selected Auto/Engage APP Disabled
GPS Selected Manual

Nothing has changed. If on AUTO, as soon as the GPS has glideslope, the APPR engages and the ALT light goes out, nose drops. No g/s capture. If on MANUAL, as soon as the g/s markers appear and prompt indicates to activate PROC A/R, when I press APPR, ALT light goes out, nose down . No g/s capture.

It behaves as if the GPS has not identified the g/s even though the g/s indicators are showing on the HSI. It would be the same on an ILS if you were flying down the localizer without the g/s indicators showing and then you pressed the APPR button. That would turnoff the ALT and you would be hand flying the altitude. Except in this case, using GPS, we have the g/s indicators showing and it still behaves that way.

btw, I made a backup of the RealityXP.GNS.ini file and let the program create a default one in order to eliminate specific settings. No difference.

Something that is bugging me though is that I have always had two AP Heading buttons on my controls. One is with the six autopilot buttons just like on the default Bendix Radios [AP HDG NAV APP REV ALT]. I use FSUIPC to program the HDG button so that it selects AP PANEL HDG ON which causes the plane to turn toward the direction of the HDG bug and track that course. The other HDG button is on a throttle quadrant and it is programmed to select  AP PANEL HDG HOLD which, when pressed, resets the HDG bug to the current aircraft heading and tracks that course. I've had that setup for several years. I know I'm not losing my mind, but for the life of me I can't find a control to assign to the HDG button on the throttle quadrant , using FSUIPC, that gives that behavior any longer. ALL of the AP HDG controls that I select cause the plane to turn toward the heading bug. None of them reset the HDG bug to the current heading any longer.

This is why I'm thinking that something is wrong with my autopilot.

Now, here's the real problem.. My computer crashed about a week ago. I now have a fresh install of Windows 10 and FSX, Reality XP GNS 530, and other programs. The problems is still there.

I might be losing my mind...

[RXP 2,338]

38 minutes ago, Spug said:

Now, here's the real problem.. My computer crashed about a week ago. I now have a fresh install of Windows 10 and FSX, Reality XP GNS 530, and other programs. The problems is still there.

I though you were on P3D4. Can you please let me know what is the FSX.exe file version? (right click | properties | details)

[Spug 7]

Microsoft Flight Simulator X:Acceleration 10.0.61637.0
Microsoft Flight Simulator X:Acceleration SDK 10.0.61637.0

[RXP 2,338]

This is a supported version ok. Can you please disable FSUIPC from loading entirely and compare? It is possible it is trying to 'assist' behind the scene in way which makes you loose the ALT mode for example. In parallel, we'll further do additional tests around the 'arm/engage' logic within FSX to see how it goes internally.

Mind you: nothing as changed much at all since our initial release and the way we 'override' the autopilot though.

[fppilot 4,371]

FSX

Flew a successful approach today into KLUK in a Milviz B55 Baron equipped with a pair of RXP GNS gauges and it was flawless.  I had the AMFS section GPS Setting set to Auto.

Possibly tomorrow am I can fly with the (3) approach settings into KVPS with the default Baron.

Edited March 13, 2019 by fppilot

[Spug 7]

With FSUIPC not loading the problem is still there. ILS approaches work flawless, it's only the RNAV(GPS) approaches that has the issue of not capturing the glideslope.

 

 

[fppilot 4,371]

34 minutes ago, Spug said:

With FSUIPC not loading the problem is still there. ILS approaches work flawless, it's only the RNAV(GPS) approaches that has the issue of not capturing the glideslope.

 

 

Would you post the settings you have in the GNS in that aircraft in the Panel Instruments section and in the AFMS sections?

[RXP 2,338]

14 hours ago, Spug said:

it's only the RNAV(GPS) approaches that has the issue of not capturing the glideslope.

Do you mean it is still disarming ALT mode on your FSX and the aircraft takes the plunge?

[Spug 7]

10 hours ago, RXP said:

Do you mean it is still disarming ALT mode on your FSX and the aircraft takes the plunge?

That's correct.