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

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.

Thank you for the updates!!

Hi,

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

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.

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?

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

 

 

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

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

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

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 March 11, 20197 yr by RXP

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 March 11, 20197 yr by fppilot

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 March 11, 20197 yr by RXP

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.

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