There was some discussion of this subject in Orlaam's topic on lateral tracking issues with the A2A S-TEC 30 autopilot, but as this is a separate issue I've started this thread to avoid confusion.

The problem I encountered was the A2A KAP 140 autopilot simulation failing to follow vertical guidance from the GNS 530 for approaches such as LPV and LNAV+V procedures. In response, Jean-Luc made the following comment here.

Quote

[...] Nevertheless, if they have implemented a custom A/P, which works based on normal simulator data (such as LOC/VOR radial signal, HSI needle deviation etc.., the reason it doesn't work in LPV might just be they have not accounted for any GPS LPV because the default GPS is not offering vertical capabilities.

However, if they only rely on 'radio-like' signals to feed their A/P code, then, it might be as simple to do vertical guidance as they do horizontal guidance when using our GNS V2, because we do override HSI, NAV and GPS sim variables (and module_var as well).

By the way, have you tried this A/P when you enable "Connect GPS to VOR indicator" in the settings panel?

This settings makes the GNS V2 override all 'NAV' related variables.

This works the same way "Connect GPS to HSI" makes the GNS V2 override all 'HSI' related variables.

NB: your GNS V2 must be the 'Master' otherwise it won't override the variables!

As suggested, I tried an approach with the "connect GPS to VOR indicator" option selected and the autopilot indeed intercepted the GPS glideslope. This would seem to be a good solution, except that it  renders the NAV2 radio inoperable!

I did note the guidance on page 114 of the GNS 530 Pilot's Guide: "Enabling Autopilot Outputs for the King KAP140/KFC225." At first, I though this may be relevant to trying to troubleshoot the issue in question. However, presumably this procedure of manually enabling autopilot outputs during each relevant approach isn't included in the trainer because it's autopilot specific?

Anyway, still hoping a workable solution can be found as I'll be using the GNS more-or-less exclusive in A2A products. 

Thanks,

Nick

This is a good wrap up and description! The real GNS output setting is for feeding real voltage to real wires!

In the virtual world, there is nothing more needed than sharing data the way we want.

Your test seems to concur what I've said: because the default GPS is not designed for vertical guidance, their A/P was not designed to follow the vertical needle when in GPS mode. However, when in VLOC mode, they do, and they probably do so based on the VLOC data (needles). 

To solve this problem: just have their A/P follow vertical guidance whenever there is a valid signal (not flagged). When doing so, regardless if the input is from a GPS (ours), or a VLOC radio, their A/P will track it!

25 minutes ago, RXP said:

To solve this problem: just have their A/P follow vertical guidance whenever there is a valid signal (not flagged). When doing so, regardless if the input is from a GPS (ours), or a VLOC radio, their A/P will track it!

Thanks, though I'm not sure I follow this correctly. Do you mean there's something I can do in terms of how the GNS and/or autopilot is configured to solve this, or that it's something that requires attention at developer (i.e. coding) level?

Nick

12 minutes ago, Nick M said:

that it's something that requires attention at developer (i.e. coding) level?

Most likely! But given they've implemented their own tracking code based only on signals like 'needle deviation' (per my understanding of your explanations), it sounds like they just have 'disabled' vertical tracking when in GPS mode.

Your tests with 'Connect GPS to VOR indicator' indicate their code is perfectly capable of tracking the 'needles' our GNS is overriding, so it would be as capable of tracking the 'needles' from the HSI, like from this set:

"HSI CDI NEEDLE,percent"   
"HSI GSI NEEDLE,percent"   
"HSI CDI NEEDLE VALID,bool"
"HSI GSI NEEDLE VALID,bool"
"HSI TF FLAGS,enum"        

As a matter of fact, they just have to enable their vertical tracking not just when it is in NAV mode, but also when in GPS mode. A simple change. In other words, enabled vertical guidance not based on GPS/NAV mode, but based on "HSI GSI NEEDLE VALID" only!

Okay - thanks for the clarification Jean-Luc. Incidentally, are you in contact with the A2A guys regarding them officially supporting the new GNS units in their current and future fleet?

Nick

No I'm not! However, if their A/P is coded in XML, it should be a simple fix! 

Let's hope so! And hopefully you'll be able to work with A2A (as well as other developers) over the coming weeks and months to get the new GNS (and GTN when they're available) products supported as widely as possible.

Nick

19 minutes ago, RXP said:

if their A/P is coded in XML, it should be a simple fix! 

I meant a user done fix, that is something you can do yourself. Is this A/P gauge coded in XML ? (i.e. the file extension is .cab)

No - as far as I'm aware, all of A2A's avionics are encoded within DLLs.

Nick

Hello Jean-Luc,

Just wondering if there's any likelihood of a solution for this issue? I figured the GNS V2 would work OK with the A2A add-ons as V1 is supported, but starting to think this may have been a mistake.

If it's any help, I've pasted an extract of the legacy RXPGNS.INI below which A2A provides with the installation, presumably to help compatibility between the V1 unit and their code. Just wondering if it gives any clues as to what settings in the V2 unit will work best, as they don't seem to be exactly the same as the options below. (I didn't own the V1 product, so can't comment on how well it worked in respect to this issue.)

AutoPilotMode=2
Radios=1
LinkCdiKey=On
AutoCdiMode=0
AutoApproach=Off
LinkVor=1
LcdStyle=Off
AutoWidth=500
AutoHeight=360
Trainer=
NoKeyClick=Off
DisableRxTx=Off
AutoPowerOn=Off
AutoRadiosOff=Off
GndSpdFromDeltaLatLon=Off
AutoCourse=Off
LinkObs=On
ShadinFuel=On
RadioSyncMode=Full
Brightness=-1.000000
CrossFill=Off
TCAD=Off
Taws=On
TawsVolume=60

In particular, it's "AutoPilotMode=2" which I'm curious about.

Thanks,

Nick

 

 

Hi Nick, the legacy had 2 modes: NAV or HDG. The former is the normal mode like with the GNS V2, the latter is only when there is no possible way to control the NAV A/P. In this case, the gauge changes the HDB bug instead.

Also, can you please let me know the exact file version of your simulator .exe file?

Thanks -  looking at those settings and the LinkVor=1 line, I'm wondering if the GNS V1 integration with the A2A KAP 140 suffered from the same limitation; or are there  V1 vs. V2 code differences which could account for this?

7 hours ago, RXP said:

Also, can you please let me know the exact file version of your simulator .exe file?

I presume you mean the fsx.exe (FSX-SE: 10.0.6.61625.0) and Prepar3D.exe (P3DV4: 4.0.28.21686) - I currently run both. Or did you mean rxpfsxml.exe? (V2.0.0.0 - I installed the recent update.)

Nick

Thank you. Yes I was asking for these (not rxpfsxml.exe). Are you sure your FSX-SE is not 10.0.62615 instead?

Sorry, yes, a mistype!  FSX-SE is 10.0.62615.0 though I've mostly tested in P3D. In any case, both sim platforms and the A2A products in question are fully updated.

Nick

On September 2, 2017 at 11:40 AM, Nick M said:

ested, I tried an approach with the "connect GPS to VOR indicator" option selected and the autopilot indeed intercepted the GPS glideslope. This would seem to be a good solution, except that it  renders the NAV2 radio inoperable!

I realize I might have skip this initially. Just to make sure, when enabling this setting, the A/P then works ok? What do you mean more precisely with "radio inoperable"?