Spug

GNS530 V2 vertical guidance not working (resolved)

Recommended Posts

Flying an ILS approach seems fine. On a GPS LPV approach while using NAV and ALT on the autopilot as I approach the glideslope, I receive the yellow triangles indicating that vertical guidance is available. At this point, in the past when I pressed the APP button, the ALT continues to be lighted just like in an ILS approach. When the plane intercepts the glideslope, the ALT light goes out and the plane starts down. However, now when I press the APP on the autopilot, the ALT light goes out immediately, long before glideslope intercept, and the plane starts down.

Just wondering if anything has changed in the programming for GNS530 v2 that would affect this?

-Spug

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

Hi,

I'm sorry for the delay.

We're currently conducting a series of flight tests with other members of the forum with a new build and this seems to correct this kind of issue. An update will be released soon with fixes and a few more features too.

Thank you for your patience in the meantime.

Share this post


Link to post
Share on other sites

Hi,

we're just released v2.4.9 which should work better.

Share this post


Link to post
Share on other sites

Just download v2.4.9.

Looks like no difference between v2.4.8 regarding capturing the glideslope on an RNAV(GPS) approach. When the APP button is pressed on the Autopilot, you lose the ALT hold and the plane pitches down. It should hold the present altitude until capturing the glideslope, then start down. I'm using the default Baron 58. Nothing special.

Share this post


Link to post
Share on other sites

The latest version has had changes specifically to the autopilot coupling so that it behaves as intended and all our tests where conclusive. This makes me wonder with what simulator is this happening? Have you enabled AFMS auto APPR mode setting or not?

Share this post


Link to post
Share on other sites

Using v2.4.9:

GPS Selected: Prompt
Engage Autopilot APPR: Disabled
If I use the above settings, when the glideslope indicators appear, I get the prompt message. Pressing the APP on the autopilot causes the ALT light to go out immediately and the plane pitches down. It should activate the APP mode and hold altitude until intercept of the glideslope, then start down.

GPS Selected: Auto
Engage Autopilot APPR: Enabled
The same action happens with this setting except everything occurs automatically as soon as the glideslope indicators appear; ALT disengages, nose pitch down before glideslope intercept..

If I'm the only one that this is happening to then maybe something in my setup is not right: FSX Acceleration, Beech Baron 58, Bendix autopilot. Standard equipment

It used to work great. Maybe that was version 2.4.7. Don't remember

 

 

Share this post


Link to post
Share on other sites

I'm experiencing the same only with the GTN. Captures GS Then just drives the aircraft into the ground.

Share this post


Link to post
Share on other sites

@Spug what about trying this:

GPS Selected: Auto
Engage Autopilot APPR: Disabled

Also what simulator are you running?

@Adrian123 this sounds different from Spug: in you case it captures GS whereas in his case it dives prior capturing isn't it? When you mention it drivers the aircraft into the ground, does it mean this is an issue in itself in your opinion?

Share this post


Link to post
Share on other sites
32 minutes ago, RXP said:

@Adrian123 this sounds different from Spug: in you case it captures GS whereas in his case it dives prior capturing isn't it? When you mention it drivers the aircraft into the ground, does it mean this is an issue in itself in your opinion?

Sorry jean-Luc. I discover it is only the Carenado saab 340 that has the issue. Sounds like thats their deal!!

Share this post


Link to post
Share on other sites
Posted (edited)

Let's put this to practice with a quick pattern you can fly in a few minutes.

I've just cross checked again with the GNS V2 and the GTN, both working the same:

  1. Start with the Baron 58 at KVPS RWY19
  2. Select the procedure KPVS | RNAV 01 with transition: YOUNK.
  3. Preselect 2500 ft on the A/P
  4. Takeoff, positive climb, gear up, arm autopilot NAV + ALT modes
  5. Set simulator time acceleration to x4 (menu Options | Simulation Rate)
  6. Note how well it tracks with time acceleration, another time try x128 too!
  7. Before YOUNK, set time acceleration back to x1

Now depending:

  1. GPS Selected Auto / Engage APPR Enabled:
    right in the middle of the turn to ELISS, the APPR mode arm, the ALT stays, once G/S crosses it starts descending.
     
  2. GPS Selected Auto / Engage APPR disabled:
    right after the turn to ELISS when the G/S is live, press the APPR button on the autopilot. Once G/S crosses it starts descending.
     
  3. GPS Selected Manual:
    right after the turn MSG flashes, tells you to use PROC before APPR. Press the PROC button, enable the A/P APPR output, then press the APPR button on the autopilot.

NB: this works equally well in XP11/10/9.

Edited by RXP

Share this post


Link to post
Share on other sites
Posted (edited)

I am an FSX user only.

I have experienced a variety of issues with the GNS both before and after 2.4.9.  Today I flew the same approach RNAV 02 approach into KPWT (Bremerton, Washington, USA).  Two in the Carenado Cessna C210, and one in the original MilViz Cessna 310R (not the Redux).  Vertical navigation is not behaving, and APR behavior is strange.  I should have paused more often to write notes but did not.  I use strictly add-on aircraft and thus have no RXP gauge installations in default models.

The first issue I note on this approach is that the GNS annunciation changes from TERM to LPV very early, some distance before the IAF.  Using 2.4.8 over the weekend the Carendao C210 would enter a shallow descent, say 200 FPM as soon as, or shortly after LPV was ennunciated.  The ALT annunciation would extinguish and VS was never annunciated. This was a point in the approach that called for a level altitude.  Since I considered that I was early in the approach, I tried to overcome the issue by turning the AP off and back on and catching up with the settings.

2.4.9.  If anything, the behavior was worse today with all three approach attempts. Two in the Carenado 210 and the other in the Milviz 310 (original).  I should have slowed my actions but I was trying to recover the flights.  In the Milviz 310 at least, and perhaps in the 210, it seemed that APR mode became enabled automatically.  ALT mode was extinguished.  VS was never enunciated.  Altitude did not change. And when I attempted to change from APR to NAV and back to APR, while also trying to get vertical navigation I entered a wild nose dive that I could not recover from.

I have no idea what settings to try, or set in the AFMS section, and over the past few days with too much trial and error I have totally confused myself on what some other settings perform, or don't perform

At this point I just want to get back to flying and to do that I may wish to revert to a version prior to 2.4.7.

Edited by fppilot

Share this post


Link to post
Share on other sites
Posted (edited)

Can you please all:

  • Try the flight I've posted above so that we can have something to all compare against with.
  • It is short a flight, quick to do in a few minutes from takeoff to approach:
  • Try the default Baron58, eventually the default Mooney if you don't have the B58 anymore in P3D4.
  • Rename/Backup the RealityXP.GNS.ini and let the GNS uses defaults settings next time around if you've already used the B58 and/or the Mooney depending.
  • The only settings you might want to manually enable from then on are "Connect HSI/CRS (auto-slew)" and "Connect HSI/OBS (input)".

Let's see at least how it goes with a standardized scenario.

From then, hopping it works fine, let's refine the test incrementally:

  • Copy the RealityXP.GNS.ini file from the aircraft causing problem to the B58 and/or Mooney and fly again.
  • If it works the same, we'll focus on the aircraft.
  • If it fails the same, we'll focus on the combination of settings (could be)

NB: the outcome should be the same regardless whether it is GNS V2 or GTN: the autopilot implementation is based on the same logic/code.

 

Edited by RXP

Share this post


Link to post
Share on other sites

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

See that it is too late to edit my previous  message above. Over the past two hours I have uninstalled GNSv2 gauges, backed up .ini files, reinstalled the V2 gauges, and successfully shot three approaches into in the Carenado Cessna 210 without any vertical guidance issues. I flew the approaches into a different airport that I frequent (KBMG) and using approaches that I am highly familiar with. 

I went back to KRWT, Bremerton, Wa, and once again experienced very early annunciation of LPV on the GNS,  early and automatic engagement of APR mode on the AP, and early and shallow descent with neither ALT or VS annunciated.  I allowed the descent to continue and the rate varied and did not meet the GS. 

Just have no handle on what is going on. I see attention given to differences in aircraft and in autopilots. Can there be difference in the coding of a same approach type from one airport to another?

I would say that it is then an issue with that particular airport or approach, but I had a similar issue at a totally different airport last Friday using 2.4.8.  That one being the Orbx KMRY at Monterey, Calif.  The issues at both airports were first noticed last Friday with GNS 2.4.8 and today at KRWT with 2.4.9.   I may not have logged any earlier GNS approaches anywhere with 2.4.8.  I fly most often now with GTN equipment.

I  have not flown yet with the new GTN release 2.5.14.  I had not noticed any issues with 2.5.13,

I would greatly like to see a setting by setting description for each of the settings in the AFMS sections for both gauge types.

Share this post


Link to post
Share on other sites

@fppilot 

  • Did you remove the ini file and let the GNS V2 deal with defaults, or did you just backup in case but kept them for your successful flights?
  • is the KRWT a default airport or an add-on?
  • Did you make the KRWT approach with the same aircraft with the same ini file?

 

NB: Both GNS V2 and GTN work the same in regard to the autopilot, using one or the other should give very similar results. The autopilot coupling is also airport agnostic. However it could be there are some vendors using some 'tricks' when doing there sceneries and if there are I have to take this in account for troubleshooting the issue.

NB: default settings has "Engage Autopilot APPR" disabled in which case there the GNS V2/GTN doesn't command any autopilot change. Therefore any autopilot mode change comes from the aircraft itself, or a 3rd party module/add-on, but not from the RXP gauge which are merely 'monitoring' the autopilot modes and 'override' the flight director axes depending on the actual armed modes.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

@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?

Share this post


Link to post
Share on other sites
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. 

Share this post


Link to post
Share on other sites

@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

Share this post


Link to post
Share on other sites
Posted (edited)
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 by fppilot
  • Like 1

Share this post


Link to post
Share on other sites

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...

Share this post


Link to post
Share on other sites
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)

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now