I hope anyone can help me figure this one out. I have X Plane 11.5 installed, Reality XP GTN 750 installed and updated to the latest version which I use in the following aircrafts:
- Alabeo M20R_Ovation_v1.3
- Carenado C340 II_v1.1
- Digital Replica Cessna 310L
- MilViz CT310R V1.09
In ALL of them, the GTN 750 blends with the cockpit without any issues, can follow a flight plan and connects with the autopilot well for flying the plane. However, on approach, neither of the planes captures the glide slope. The AP keeps the ALT HOLD altitude. When I switch all planes to the default Garmin 530, no problem in capturing the GS. I have read several posts here from the past (2018) where a similar situation was happening to another guy, and I followed the different fixes suggested like disconnecting the "Connect GPS to VOR" (I tried it while connected and disconnected) but it didn't correct the issue. I also contacted Carenado Support, and they sent me as a solution the RealityXP.GTN.ini file for their planes... I believe the issue is not on the .ini file but in the way the device is communicating with X Plane 11.5.

I also must add that before this setup, I was using X Plane version 11.4 with the previous version of the GTN 750 without any problem - all planes would follow the GS, so I believe there has been a disconnect between the new 11.5 version of X Plane and the GTN 750. I forgot to mention that it wouldn't work either on the previous version of the GTN 750 on X Plane 11.5.

Can anyone please share some light as to how to fix this, or what are the steps to follow to troubleshoot this issue? Any help is greatly appreciated.

You are or automatically having the AP activate approach mode when established?

Thank you Adrian for your reply.

Yes, the AP is on APR mode. This morning, I tried something different and got it to work - partially. The airport in question was KAPF (Naples Municipal, FL) departing from KRSW (For Myers, FL). A 10-min flight. KAPF has 2 runways: 14-32 and 5-23. When approaching on RWY 14, neither plane would capture the GS on the GTN750 (but it will on the default Garmin 530). This is also true when the approach is done to RWY 32. However, when I approached RWY 5 and RWY 23, GTN 750 would capture the GS on all planes, as well as the Garmin 530. Flying a reverse course back to KRSW would also capture the GS on approach to KRSW on the GTN 750. So at this point, I know the error is on the GTN 750 not been able to capture this particular runway. Maybe there are others as well where it would show a similar behavior. Could this be related to a database issue on the 750, not having the right specs for that runway?

Hi,

I'm sorry for the delay.

This is peculiar but the only way to discern any such bug is to use the GTN on a default aircraft like the Baron 58 otherwise you're adding the possibility there is a bug in these aircraft not following the XP11.50 standards too.

So what about this in a default aircraft?

Thank you for your response. I tried it with the Baron as you suggested and it did work. I also tried it with the MilViz 310R and it did work. Digital Replica Cessna 310L and Carenado Mooney M20R didn't pick the glideslope. I'll take this issue to them, you could be right - maybe those aircraft models are not updated to X Plane 11.50.

I just installed the GTN 750 and have the same problem.  I’m running x-Plane 11.5 and using the default Cessna 172 SP with steam gauges. The G-530 runs the entire flight plan without a hitch, and captures the glide scope for the KLOM - KPNE RWY 24 RNAV approach using the FLITS IAF.

The GTN 750 goes into GPSS and tracks waypoints.  Then, upon pressing APP, the S-Tec 55x AP displays “GS” but the VOR does not display the localizer or GS and the airplane does not descend.  Guidance to resolve this issue would be appreciated.

PS - I tried unchecking the "Connect GPS to VOR" setting with no success.

For the default C172 this is a known open isue if you connect it to VOR1 when flying RNAV approaches with vertical guidance., If you would connect it to the HSI (although a HSI is not there in the default C172), it works as expected. But in that case you do not have the OBS function of the VOR1 indicator to the OBS mode of the GPS.

RXP did not solve it yet.

 

For me it is more important to have the full OBS functionality than flying the vertical path with the AP. I fly the approach from the FAF onwards by hand, which is anyhow better for training purposes.

OBS functionality is relevant for e.g. circlings. But ther are many other uses cases.

 

Edited March 18, 20215 yr by PeterBremer

@PeterBremer The issue is complex because there are many different diverging sources and limitations in XP11.

For example, the default C172 VOR1 is using a few new datarefs which are not respecting the "override_" datarefs:

1. open in notepad++ Cessna 172SP\objects\instruments\vor_glideslope_adf\vor1_gs_ag.obj
2. go to line 633 and see it is using sim/cockpit2/radios/indicators/nav1_flag_glideslope_mech

The problem with this dataref is that unlike the traditional sim/cockpit2/radios/indicators/nav1_flag_glideslope it is not honoring the "override_nav1_needles" which is the dataref supposed to be used when plugins are overriding the nav needle source data.

What does this has to do with "Connect to HSI"

For the similar reasons, the autopilot system in XP11 is not taking in account the override_gps unless we also override some hsi related datarefs. This depends on some internal "logic" depending on the type of autopilot and a few other aircraft specific settings/configuration in plane maker.

What does this has to do with OBS?

Because there are similar limitations with it too. There is no "hsi override" and this instrument related datarefs are sourced from either NAV or GPS depending on the source selector. The RXP GPS setting "Connect HSI" is basically telling to override the "gps_xxx" datarefs which are the ones the HSI is displaying when it is in GPS mode (fromto, hdef/vdef, course). However because of how the XP11 internal datarefs are used and sources, it seems there is no way to also have the NAV OBS working as expected when overriding the GPS datarefs related to the HSI. This is why our GUI Settings Panel is indicating the OBS you'll be taking data from to feed the RXP GPS is either the HSI OBS if you connect HSI, or the VOR OBS if you connect VOR. It can't be both and HSI OBS has a priority over VOR OBS because of the "override_gps" making them both dependent.

I've also not revisited this for a long time now but I've spent countless hours trying every single combination I could and this is deeply rooted in the internal XP11 logic upon which we have not much control. I'll keep a note to revisit this in the future though.

Edited March 18, 20215 yr by RXP

3 hours ago, RXP said:

@PeterBremer The issue is complex because there are many different diverging sources and limitations in XP11.

...

I've also not revisited this for a long time now but I've spent countless hours trying every single combination I could and this is deeply rooted in the internal XP11 logic upon which we have not much control. I'll keep a note to revisit this in the future though.

Thanks, Indeed I also expect that waiting for an improved version of the datarefs will be required. There ar some datarefs you could expect you could use, but they are read-only.

At this moment there are two mutually exclusive options for the default C172 and RNAV approaches with vertical guidance with the RXP sytem:

1. Connect to VOR1: handfly the approach from FAF onwards and have full OBS functionality on the GPS
2. Connect to the not existing HSI: autopilot available for the approach from FAF onwards, but no OBS functionality on the GPS

I have chosen option 1, which works best for my training purposes.

There is one other minor issue with RNAV approaches with vertical guidance due to issues with the datarefs: The GS error flag remains visible, which offically would disallow using the autopilot or the VDI for vertical guidance; It should be treated as a LNAV only approach when normally it would have been a LPV, LNAV/VNAV or LNAV+V approach, (a LNAV+V would have had anyhow the LNAV minima).
But for simulation purproses that reasoning can be skipped of course, as long as you do the check and are aware.

Edited March 18, 20215 yr by PeterBremer

Thanks for the info.  If the G530 can overcome the limitations and capture the GS I would expect there is a similar solution for the GTN-750.

is it possible to please refund my purchase, as the system doesn’t work?  I will buy it when the bug is fixed. I bought it for training for the actual C172 I fly, which has a GTN 650.  I intended to purchase the GTN-650 at the sale price too, but now I will wait until the issue is resolved.

14 minutes ago, rasander said:

Thanks for the info.  If the G530 can overcome the limitations and capture the GS I would expect there is a similar solution for the GTN-750.

is it possible to please refund my purchase, as the system doesn’t work?  I will buy it when the bug is fixed. I bought it for training for the actual C172 I fly, which has a GTN 650.  I intended to purchase the GTN-650 at the sale price too, but now I will wait until the issue is resolved.

The 530 from X-Plane can reach all the internals of the sim of course and thus does not have those limitations, the GTN750/650 and GNS530/430 from RXP can not reach does internals as explained.

Whether this is solvable does depend on Laminar, not on RXP. So I would have no idea when it can be solved, if ever.

For me using the RXP GNS530/430 compared to the X-Plane ones have far too may advantages, to name a few:

• all real menu's are there
• all screen options are available
• CDI guidance in turns is correct, guiding you through the turn instead of just stupid unrealistic switching of legs,

Edited March 18, 20215 yr by PeterBremer

1 hour ago, PeterBremer said:

There is one other minor issue with RNAV approaches with vertical guidance due to issues with the datarefs: The GS error flag remains visible,

The problem is that XP11 internals are just ignoring the fact there is a plugin overriding the gps data signals and this doesn't count as a "glideslope signal received" for removing the flag from view.

This is most likely due to the 172 VOR gauge using the new dataref introduced since XP11.30 I'm mentioning above:

sim/cockpit2/radios/indicators/nav1_flag_glideslope_mech

Glide slope flag, nav1 – mechanical instrument flag that shows whenever no glideslope signal is received

 

Should you manually edit the .obj file to use the following instead, I'm pretty certain it will work as intended:

sim/cockpit2/radios/indicators/nav1_flag_glideslope

Glide slope flag, nav1 – EFIS style flag that shows when glideslope is expected, but not received

 

Since you're raising the question about this OBS thing, I'd like to further the topic and find out what we can do.

Can you please help me out understanding exactly what you mean with these:

1) Connect to VOR1: handfly the approach from FAF onwards and have full OBS functionality on the GPS

• Do I understand correctly in this case, the GPS/autopilot coupling is only working for lateral, not vertical for LPV approaches? (unexpected)
• Do you mean you can set the GNS in OBS mode and change the radial on the GNS when turning the OBS knob on the VOR1 gauge? (expected)

2) Connect to the not existing HSI: autopilot available for the approach from FAF onwards, but no OBS functionality on the GPS

• Do I understand in this case, the GPS/autopilot coupling is working for both lateral and vertical for LPV approaches? (expected)
• Do you mean turning the OBS knob on the VOR1 gauge doesn't change the radial on the GNS when it is set in OBS mode? (unexpected)

 

POk, I was able to get the GTN 750 Localizer and Glideslope to work in Autopilot mode.  I entered a flight plan with only an approach, and then activated the flight plan.  After taking off I activated GPSS.  The autopilot flew the course in the GTN 750, including the holding reversal.  Upon crossing the IAF I activated the APR.  The GS indicator lit up on the autopilot panel and the autopilot flew the approach, descending on the glideslope to the runway threshold.  I flew the course twice and it worked both times.

Here's my GTN 750 settings:

Mater Device: checked

Connect GPS to Autopilot: checked

Connect GPS to HSI (pilot): checked

Connect HSI/CRS (auto-slew): checked

Connect HSI/OBS (course in): checked

Connect GPS to VOR1 indicator: checked

Connect CDI Mode to NAV/GPS Switch: checked

 

In the Plane Maker Systems Page I chose the STec 55 Autopilot and under HNAV course I selected GPS/LOC

This forum doesn't seem to offer a means to attach an image from the computer, and the copy\paste function doesn't work.  If it did, I would send you images of the GTN and Plane Maker settings screens.

I'd be glad to check it out on the GTN 650 if you send it to me!

Regards,

Richard Sander

1 hour ago, RXP said:

The problem is that XP11 internals are just ignoring the fact there is a plugin overriding the gps data signals and this doesn't count as a "glideslope signal received" for removing the flag from view.

This is most likely due to the 172 VOR gauge using the new dataref introduced since XP11.30 I'm mentioning above:

sim/cockpit2/radios/indicators/nav1_flag_glideslope_mech

Glide slope flag, nav1 – mechanical instrument flag that shows whenever no glideslope signal is received

 

Should you manually edit the .obj file to use the following instead, I'm pretty certain it will work as intended:

sim/cockpit2/radios/indicators/nav1_flag_glideslope

Glide slope flag, nav1 – EFIS style flag that shows when glideslope is expected, but not received

 

Since you're raising the question about this OBS thing, I'd like to further the topic and find out what we can do.

Can you please help me out understanding exactly what you mean with these:

1) Connect to VOR1: handfly the approach from FAF onwards and have full OBS functionality on the GPS

• Do I understand correctly in this case, the GPS/autopilot coupling is only working for lateral, not vertical for LPV approaches? (unexpected)
• Do you mean you can set the GNS in OBS mode and change the radial on the GNS when turning the OBS knob on the VOR1 gauge? (expected)

2) Connect to the not existing HSI: autopilot available for the approach from FAF onwards, but no OBS functionality on the GPS

• Do I understand in this case, the GPS/autopilot coupling is working for both lateral and vertical for LPV approaches? (expected)
• Do you mean turning the OBS knob on the VOR1 gauge doesn't change the radial on the GNS when it is set in OBS mode? (unexpected)

 

Yes you fully undestood me correctly. For point 1) not only LPV, but for LNAV/VNAV and LNAV+V as well.

 

I will try your suggestion in .obj file for the GS flag issue!