Is it possible to get these trough a dataref? Through the discrete out maybe? I couldn't find it in the documentation.

Hi,

Yes you can!

You're right, it is the purpose of the discrete_out dataref and it is also consistent both between the GTN and the GNS V2.

It is not documented but I'm sending you a PM with details. Do you mind sharing what you'd use this for?

PS: customers of our FltSim version also get WAAS and TAWS annunciation panel gauges which are coded in XML and which document how to use the 'discrete_out' data. They are entirely based on this.

Edited March 5, 20206 yr by RXP

Hi Jean-Luc,

Could I get the details for this as well, please?

I'm trying to interface between X Plane 11 and an EHSI in AirManager to bring up indications of LOI, phase of flight, type of approach etc, to practice PBN operations.

@TIJMacLean I've sent you a PM!

My SASL 3 code used in freeware Bell 429.

local gps_dis = globalPropertyi("RXP/radios/indicators/gps_discrete_out")
local mask    = {8, 16, 128, 256, 512, 4096, 16384, 16777216, sz = 8}
local dref    = {WPT, TERM, INTEG, MSG, APR, TERR_WRN, TERR_CAUT, TRAFFIC}

function update()
    local gdo = get(gps_dis)
    for i = 1, mask.sz do
        set(dref, bit.band(gdo, mask) / mask)
    end
end

 

New datarefs created in MAIN.

APR                    = createGlobalPropertyi("429/gps/APR");
INTEG                = createGlobalPropertyi("429/gps/INTEG");
MSG                    = createGlobalPropertyi("429/gps/MSG");
TERM                = createGlobalPropertyi("429/gps/TERM");
TERR_CAUT            = createGlobalPropertyi("429/gps/TERR_CAUT");
TERR_WRN            = createGlobalPropertyi("429/gps/TERR_WRN");
TRAFFIC                = createGlobalPropertyi("429/gps/TRAFFIC");
WPT                    = createGlobalPropertyi("429/gps/WPT");

If you're doing like so, which is iterating the bits and set a separate dataref for each, you could save the division:

local gps_dis = globalPropertyi("RXP/radios/indicators/gps_discrete_out")
local mask    = {8, 16, 128, 256, 512, 4096, 16384, 16777216, sz = 8}
local dref    = {WPT, TERM, INTEG, MSG, APR, TERR_WRN, TERR_CAUT, TRAFFIC}

function update()
    local gdo = get(gps_dis)
    for i = 1, mask.sz do
        set(dref, bit.band(gdo, mask) and 1 or 0) -- ternary operator
    end
end

PS: if the 'WPT','TERM' etc... are just tested like this: != 0 meaning is set, == 0 meaning is not set, then you don't even have to convert the bit and result to 1 or 0, just do:

set(dref, bit.band(gdo, mask))

Edited March 5, 20206 yr by RXP

Got it - thanks! Have been playing with GPS approaches and can distinguish between LPV and LNAV approaches (and then bring up a display of the type of approach) by just checking to see whether a glideslope is available on the HSI. However, still working on a way to distinguish between an LPV with an LNAV/VNAV or LP+V etc. 

On 3/8/2020 at 3:08 PM, TIJMacLean said:

However, still working on a way to distinguish between an LPV with an LNAV/VNAV or LP+V etc. 

Hi,

Trying to give you a 'best answer' I've found this page which is interesting:
https://www.boldmethod.com/learn-to-fly/navigation/what-is-the-difference-between-lpv-and-lnav-vnav-gps-approaches/

I'm not sure why there would be a need to know whether it is +V or LPV because it seems to be a "GPS only matter". Can you please elaborate?

 

Differences between the types of approaches, I’m happy with, but thank you.

 

I’m trying to replicate the bottom part of the GPS where it tells you whether you’re on an LPV or LNAV/VNAV or LNAV + V approach, to put that indication on the HSI. At the moment, as far as I can tell, the discrete out only lets you know if you’re in APR rather than ENR or TERM. Just to make it more obvious which approach you’re on directly in field of view instead of having to check the GTN. 

If I understand correctly, the approach type could be a factor for the HSI instrument for determining whether the GPS is using an angular or linear deflection scale. However, the output signal is 'shaped' to fit a regular HSI gauge if I'm not mistaken.

Unfortunately the GTN plugin doesn't expose this data and I can't promise anything for now, but we're updating our implementation regularly and this kind of data could be exposed in the future.