ATT mode Var Error

Sergekoko

Good Evening,

I have been mapping custom Duke Autopilot Functions using Mobiflight in 2024, and am having an issue with mapping the one to select the ATT mode button. All the others i have either found in the custom input list or used a generic Microsoft one. When i map the one called "ATT pitch hold toggle" from the Duke Autopilot section, it selects GA on the AP control panel instead ATT, to verify i also just clicked it and it works from the cockpit, as well as trying the default Microsoft AP ATT HOLD variable, which doesnt do anything in this case. Am i doing something incorrectly? In the description field of Mobiflight it also says "Error" when that variable is selected.

Sergekoko

The code is K:AP_PITCH_LEVELER_ON

Black Square

I think the problem you're seeing here is that MSFS provides no variable for GA mode, so I have to do a process of elimination for it. Assuming you're familiar with RPN in Mobiflight, here is the exact code that I run internally to get the mode setting correct. The extra complication at the top is due to how multiple different 3rd party GPS developers handle their autopilots.

(L:PMS50_APGA_RUNNING, bool) (L:PMS50_APGA_ACTIVE_VERTICAL_MODE, number) 3 == and
(L:PMS50_APGA_RUNNING, bool) ! (A:AUTOPILOT VERTICAL HOLD, bool) (A:AUTOPILOT ALTITUDE LOCK, bool) or and
or if{
	(>K:AP_ALT_HOLD)
}
els{
	(>K:AP_PITCH_LEVELER_ON)
}

Sergekoko

Thank you for the reply, that makes me feel better that I wasnt just missing something. I am not familiar with generating a preset, i assume thats what I will have to do to use the code that you provided?

Sergekoko

Figured it out! Thank you so much, didnt realize i can script in the Preset Code box, that is so cool! Really enjoying this aircraft as well you did an amazing job, just like you do on all of your products!

Black Square

Wonderful! I was worried I was going to have to tell you that I wasn't intimately familiar with Mobiflight. Please let me know if there's ever anything else I can do for you!

Sergekoko

One unrelated question, it seems like woth the GTN750 (I only have the PMS one), RNP RNAV approaches are not able to receive vertical guidance, but GPS annotated ones on the charts seems to work and provide the glidepath indication on the HSI, is that due to the RNAV capability of the aircraft (not having RNP capability) or something MSFS related? (And since we cant legally do that approach the computer doesnt provide us the vertical guidance?)

Black Square

Disclaimer: I speak from US-based knowledge of aviation, but I know that RNAV/RNP has different meanings in the ICAO world.

There is nothing I have done specifically relative to vertical guidance for RNAV approaches, and the approaches I expect to work and capture with the autopilot in the US do, but I can't claim that I've tried RNP approaches, which would be not legal in the US, as you point out. As such, I think the answer you seek would have to come from PMS50.

Sergekoko

I only fly in the US as well. Can you try one of the ones at KEUG, i believe each of the runways RNAV has a Y and Z variant and one is (GPS) and one is (RNP) on the chart, i guess I will try it with the GNS530 as well to see if its the 750 that is causing that problem.

Sergekoko

So RNP is legal is the US i just meant if the aircraft is not certified for RNP in the real world you wouldnt want to fly that version of an RNAV approach, RNP is a very common approch type in the US.

Black Square

Yes, I also simply meant that it would not be legal to fly an RNP approach with this setup, so it's not something that I test specifically in my aircraft. There's nothing I do on my end of things that pertains to particular approach types, so if there is any difference of behavior between the two approach types for you, then I suspect it's either the intended behavior of the GTN, or perhaps a momentary issue between versions.