WASM fsPlannedRouteGetEfbRoute returns VIA field not to spec

bm98 · March 27, 2025, 10:51pm

Version: MSFS 2024 V 1.3.23 SDK V1.2.4

Frequency: Always ?? mostly ??

Severity: High

Similar MSFS 2020 issue: N/A

Context: WASM fsPlannedRouteGetEfbRoute returns Leg Data Via not to spec.

Attachments: N/A, but can be provided upon request

Bug description:

Using fsPlannedRouteGetEfbRoute() does not always data according to spec.
from PLN but more so when importing from SimBrief
as I don’t know if the problem is in MSFS and/or the plugin I file it here first

e.g. FPlan LSZH to LSGG

Using SimBrief Import

After calling SimBrief Latest Flight:

Route: LSZH/34 NO297F140 VEBIT2K VEBIT T50 ROTOS Z669 ULMES ULMES2R LSGG/22
which is OK as requested

Action: Click Import Route -result: green Mark / OK

EFB shows:

Dep: LSZH Rw 34
DepProc: VEBI2K (direct)
Enroute:
  VEBIT
  ROTOS
  BADEP
  ULMES
    i.e. expanded Waypoints, no airways / seems to internally maintain airways
ArrProc: ULME2R (direct)
Appr: none
Dest: LSGG Rw22

/see screenshot below

Calling WASM fsPlannedRouteGetEfbRoute() returns:
(where the fields are stringified to be readable)

RTE;TYP;VFR
RTE;DEP;LSZH;LS;34;0
RTE;SID;VEBI2K
RTE;SIDT;
RTE;CRS;14000;1
RTE;ENR;0;;Waypoint;VEBIT;LS;VEBI2K;0;0;0.000000;0.000000; ;;-1;-1  <---Wrong 1)
RTE;ENR;0;;Waypoint;ROTOS;LS;T50;0;0;0.000000;0.000000; ;;-1;-1
RTE;ENR;0;;Waypoint;BADEP;LS;Z669;0;0;0.000000;0.000000; ;;-1;-1  <---Wrong 2)
RTE;ENR;0;;Waypoint;ULMES;LS;Z669;0;0;0.000000;0.000000; ;;-1;-1
RTE;STAR;ULME2R
RTE;START;
RTE;APP;0;;0;0
RTE;APPT;
RTE;ARR;LSGG;LS;22;0

Which are not to spec

via field: VEBI2K is not an airway but a procedure
via field: Airway should be placed at the exit only
i.e. ROTOS; T50 is OK
but BADEP should not be here at all I think
then ULMES; Z669 is OK again

from SDK Doc:
via: An eight-character maximum null-terminated string containing the name of the airway via which this leg fix is reached.
If used, this leg should be where the airway is exited.
The airway legs that connect the previous leg (airway entry) and this leg will be automatically handled by consumers and must not be included in the route.

Using PLN file Import

Exported to PLN file (content see below)
Import the PLN file from export
WASM fsPlannedRouteGetEfbRoute() returns:

RTE;TYP;VFR
RTE;DEP;LSZH;;34;0
RTE;SID;VEBI2K
RTE;SIDT;
RTE;CRS;14000;1
RTE;ENR;0;VEBIT;Waypoint;VEBIT;LS;VEBI2K; 0;0;0.000000;0.000000; ;;-1;-1  <---Wrong 1)
RTE;ENR;0;ROTOS;Waypoint;ROTOS;LS;T50;    0;0;0.000000;0.000000; ;;-1;-1
RTE;ENR;0;ULMES;Waypoint;ULMES;LS;Z669;   0;0;0.000000;0.000000; ;;-1;-1
RTE;STAR;ULME2R
RTE;START;
RTE;APP;0;;0;0
RTE;APPT;
RTE;ARR;LSGG;;22;0

Which is not to spec

via field: VEBI2K is not an airway but a procedure

Rated High because one has to patch the received data not knowing when the VIA field is correct and when not which usually leads to errors and customer dissatisfaction…

Attachments:

Exported PLN File (HAS VEBI2K in the ATCAirway field which is Not OK):

<?xml version="1.0" encoding="UTF-8"?>
<SimBase.Document>
    <FlightPlan.FlightPlan>
        <DepartureID>LSZH</DepartureID>
        <DestinationID>LSGG</DestinationID>
        <Title>LSZH - LSGG</Title>
        <Descr>Flight from LSZH to LSGG</Descr>
        <FPType>IFR</FPType>
        <CruisingAlt>14000.000</CruisingAlt>
        <AppVersion>
            <AppVersionMajor>12</AppVersionMajor>
            <AppVersionMinor>1</AppVersionMinor>
            <AppVersionBuild>282174</AppVersionBuild>
        </AppVersion>
        <DepartureDetails>
            <RunwayNumberFP>34</RunwayNumberFP>
            <DepartureFP>VEBI2K</DepartureFP>
        </DepartureDetails>
        <ATCWaypoint id="VEBIT">
            <ATCWaypointType>Intersection</ATCWaypointType>
            <ATCAirway>VEBI2K</ATCAirway>
            <ICAO>
                <ICAORegion>LS</ICAORegion>
                <ICAOIdent>VEBIT</ICAOIdent>
            </ICAO>
        </ATCWaypoint>
        <ATCWaypoint id="ROTOS">
            <ATCWaypointType>Intersection</ATCWaypointType>
            <ATCAirway>T50</ATCAirway>
            <ICAO>
                <ICAORegion>LS</ICAORegion>
                <ICAOIdent>ROTOS</ICAOIdent>
            </ICAO>
        </ATCWaypoint>
        <ATCWaypoint id="ULMES">
            <ATCWaypointType>Intersection</ATCWaypointType>
            <ATCAirway>Z669</ATCAirway>
            <ICAO>
                <ICAORegion>LS</ICAORegion>
                <ICAOIdent>ULMES</ICAOIdent>
            </ICAO>
        </ATCWaypoint>
        <ArrivalDetails>
            <RunwayNumberFP>22</RunwayNumberFP>
            <ArrivalFP>ULME2R</ArrivalFP>
        </ArrivalDetails>
    </FlightPlan.FlightPlan>
</SimBase.Document>

EFB after Importing either SimBrief or PLN file (seems OK)

MattNischan · March 28, 2025, 9:31am

Hello,

Could you test this scenario by making the same plan directly in the EFB planner app? With the planned route coming from SimBrief, which is not our software, it is unclear if the issue is in their planned route they are sending to the sim or not. It is possible that is how they are setting the via fields, because there is no code on our side that sets the via field as the departure procedure, for example.

A planned route built from inside the EFB would not have the data structured this way, and it does not look correct to me. For example, it seems that they are creating an enroute waypoint for the departure transition, when instead the transition field should be set for departure details and there should be no enroute waypoint. So my guess here is that this improper data is from the SimBrief end.

Thanks,
Matt

Skysail · March 28, 2025, 12:00pm

This indeed looks like an issue on our side, at least if you’re using the official SimBrief EFB Dispatch app. @bm98 here is a custom build, let me know if that does the job better for you:

navigraph-efb-simbriefapp.zip (175.0 KB)

Relevant changes:

Stopped adding the procedure transition as a waypoint to the enroute section
Stopped including consecutive waypoints with the same airway (keeping only the exit waypoint)

As far as I can see, the default planner is not setting a transition at all. The only available transition option in the UI is “Direct”, so I guess that makes sense. In the build provided above, we don’t set this waypoint as the transition nor add it as an enroute waypoint. The output seems to be identical to what’s generated by the built-in flight planner.

Is this correct? Or should we still set departureTransition and arrivalTransition to the first/last enroute waypoints?

Best Regards,
Malte

MattNischan · March 28, 2025, 2:32pm

Hi Malte!

That is correct. Since VEBI2K does not have any individual transitions, only a single full procedure in the data, then you would neither set a departureTransition nor make the first enroute waypoint the last waypoint of the departure (VEBIT), as the departure procedure already includes this waypoint.

Hope that helps!
-Matt

bm98 · March 28, 2025, 2:49pm

Now this gets a bit lengthy…

there is also another effect with the WASM call I describe at the end of this post…

Building in the GUI:
Reset plan entry - OK
Add LSZH - OK
Change Procedure to VEBI2K/direct - OK
Try to add Airway T50 with exit ROTOS - OK
Try to add Airway Z669 with exit ULMES - OK, expands BADEP along the route
Add LSGG - OK
Change Procedure to ULME2R - OK

now I have
LSZH / VEBI2K/direct
ROTOS
BADEP
ULMES
ULME2R/direct / LSGG

exported plan is: (LOST the T50 airway on wyp ROTOS)

<SimBase.Document>
    <FlightPlan.FlightPlan>
        <DepartureID>LSZH</DepartureID>
        <DestinationID>LSGG</DestinationID>
        <Title>LSZH - LSGG</Title>
        <Descr>Flight from LSZH to LSGG</Descr>
        <FPType>IFR</FPType>
        <CruisingAlt>14000.000</CruisingAlt>
        <AppVersion>
            <AppVersionMajor>12</AppVersionMajor>
            <AppVersionMinor>1</AppVersionMinor>
            <AppVersionBuild>282174</AppVersionBuild>
        </AppVersion>
        <DepartureDetails>
            <RunwayNumberFP>34</RunwayNumberFP>
            <DepartureFP>VEBI2K</DepartureFP>
        </DepartureDetails>
        <ATCWaypoint id="ROTOS">
            <ATCWaypointType>Intersection</ATCWaypointType>
            <ICAO>
                <ICAORegion>LS</ICAORegion>
                <ICAOIdent>ROTOS</ICAOIdent>
            </ICAO>
        </ATCWaypoint>
        <ATCWaypoint id="ULMES">
            <ATCWaypointType>Intersection</ATCWaypointType>
            <ATCAirway>Z669</ATCAirway>
            <ICAO>
                <ICAORegion>LS</ICAORegion>
                <ICAOIdent>ULMES</ICAOIdent>
            </ICAO>
        </ATCWaypoint>
        <ArrivalDetails>
            <RunwayNumberFP>22</RunwayNumberFP>
            <ArrivalFP>ULME2R</ArrivalFP>
        </ArrivalDetails>
    </FlightPlan.FlightPlan>
</SimBase.Document>

WASM get route: (LOST the T50 airway on wyp ROTOS)

RTE;TYP;0
RTE;DEP;LSZH;;34;0
RTE;SID;VEBI2K
RTE;SIDT;
RTE;CRS;14000;1
RTE;ENR;0;ROTOS;Waypoint;ROTOS;LS;    ;0;0;0.000000;0.000000; ;;-1;-2147483648
RTE;ENR;0;ULMES;Waypoint;ULMES;LS;Z669;0;0;0.000000;0.000000; ;;-1;-2147483648
RTE;STAR;ULME2R
RTE;START;
RTE;APP;0;;0;0
RTE;APPT;
RTE;ARR;LSGG;;22;0

Building in the GUI - try to add VEBIT as waypoint:
Reset plan entry - OK
Add LSZH - OK
Change Procedure to VEBI2K/direct - OK
Try to add wyp VEBIT - NOT possible, it is shown as selection but Add will not add it
Try to add Airway T50 with exit ROTOS - OK
Try to add Airway Z669 with exit ULMES - OK, expands BADEP along the route
Try to add wyp VEBIT before ROTOS - OK - now it is possible ?? why now and not before ??
Add LSGG - OK
Change Procedure to ULME2R - OK

now I have
LSZH / VEBI2K/direct
VEBIT
ROTOS
BADEP
ULMES
ULME2R/direct / LSGG

exported plan is: (LOST the T50 airway on wyp ROTOS)

<SimBase.Document>
    <FlightPlan.FlightPlan>
        <DepartureID>LSZH</DepartureID>
        <DestinationID>LSGG</DestinationID>
        <Title>LSZH - LSGG</Title>
        <Descr>Flight from LSZH to LSGG</Descr>
        <FPType>IFR</FPType>
        <CruisingAlt>14000.000</CruisingAlt>
        <AppVersion>
            <AppVersionMajor>12</AppVersionMajor>
            <AppVersionMinor>1</AppVersionMinor>
            <AppVersionBuild>282174</AppVersionBuild>
        </AppVersion>
        <DepartureDetails>
            <RunwayNumberFP>34</RunwayNumberFP>
            <DepartureFP>VEBI2K</DepartureFP>
        </DepartureDetails>
        <ATCWaypoint id="VEBIT">
            <ATCWaypointType>Intersection</ATCWaypointType>
            <ICAO>
                <ICAORegion>LS</ICAORegion>
                <ICAOIdent>VEBIT</ICAOIdent>
            </ICAO>
        </ATCWaypoint>
        <ATCWaypoint id="ROTOS">
            <ATCWaypointType>Intersection</ATCWaypointType>
            <ICAO>
                <ICAORegion>LS</ICAORegion>
                <ICAOIdent>ROTOS</ICAOIdent>
            </ICAO>
        </ATCWaypoint>
        <ATCWaypoint id="ULMES">
            <ATCWaypointType>Intersection</ATCWaypointType>
            <ATCAirway>Z669</ATCAirway>
            <ICAO>
                <ICAORegion>LS</ICAORegion>
                <ICAOIdent>ULMES</ICAOIdent>
            </ICAO>
        </ATCWaypoint>
        <ArrivalDetails>
            <RunwayNumberFP>22</RunwayNumberFP>
            <ArrivalFP>ULME2R</ArrivalFP>
        </ArrivalDetails>
    </FlightPlan.FlightPlan>
</SimBase.Document>

WASM get route: (LOST the T50 airway on wyp ROTOS)

RTE;TYP;0
RTE;DEP;LSZH;;34;0
RTE;SID;VEBI2K
RTE;SIDT;
RTE;CRS;14000;1
RTE;ENR;0;VEBIT;Waypoint;VEBIT;LS;    ;0;0;0.000000;0.000000; ;;-1;-2147483648
RTE;ENR;0;ROTOS;Waypoint;ROTOS;LS;    ;0;0;0.000000;0.000000; ;;-1;-2147483648
RTE;ENR;0;ULMES;Waypoint;ULMES;LS;Z669;0;0;0.000000;0.000000; ;;-1;-2147483648
RTE;STAR;ULME2R
RTE;START;
RTE;APP;0;;0;0
RTE;APPT;
RTE;ARR;LSGG;;22;0

WASM call returns a strange string for

route->enrouteLegs[i].pbdReferenceIcao.ident

when it should be empty it returns a Space and a DEL char (0x7F) which cancels out in an editor but not in code.
Maybe check for this as well. It appeared somewhere during SU1 development.

bm98 · March 28, 2025, 3:17pm

Using the provided efb plugin
(cleared the WASM cache, else it failed to import)

WASM call:
It no longer reports enroute wyps along an airway - OK

WASM and GUI:
It does not report the end wyp of the procedure - OK ??

The WASM call returned:

RTE;TYP;0
RTE;DEP;LSZH;LS;34;0
RTE;SID;VEBI2K
RTE;SIDT;
RTE;CRS;14000;1
RTE;ENR;0;;87;ROTOS;LS;T50;0;0;0.000000;0.000000; ;;-1;-2147483648
RTE;ENR;0;;87;ULMES;LS;Z669;0;0;0.000000;0.000000; ;;-1;-2147483648
RTE;STAR;ULME2R
RTE;START;
RTE;APP;0;;0;0
RTE;APPT;
RTE;ARR;LSGG;LS;22;0

Export of PLN file of that import (seems OK I think):

<?xml version="1.0" encoding="UTF-8"?>
<SimBase.Document>
    <FlightPlan.FlightPlan>
        <DepartureID>LSZH</DepartureID>
        <DestinationID>LSGG</DestinationID>
        <Title>LSZH - LSGG</Title>
        <Descr>Flight from LSZH to LSGG</Descr>
        <FPType>IFR</FPType>
        <CruisingAlt>14000.000</CruisingAlt>
        <AppVersion>
            <AppVersionMajor>12</AppVersionMajor>
            <AppVersionMinor>1</AppVersionMinor>
            <AppVersionBuild>282174</AppVersionBuild>
        </AppVersion>
        <DepartureDetails>
            <RunwayNumberFP>34</RunwayNumberFP>
            <DepartureFP>VEBI2K</DepartureFP>
        </DepartureDetails>
        <ATCWaypoint>
            <ATCWaypointType>Intersection</ATCWaypointType>
            <ATCAirway>T50</ATCAirway>
            <ICAO>
                <ICAORegion>LS</ICAORegion>
                <ICAOIdent>ROTOS</ICAOIdent>
            </ICAO>
        </ATCWaypoint>
        <ATCWaypoint>
            <ATCWaypointType>Intersection</ATCWaypointType>
            <ATCAirway>Z669</ATCAirway>
            <ICAO>
                <ICAORegion>LS</ICAORegion>
                <ICAOIdent>ULMES</ICAOIdent>
            </ICAO>
        </ATCWaypoint>
        <ArrivalDetails>
            <RunwayNumberFP>22</RunwayNumberFP>
            <ArrivalFP>ULME2R</ArrivalFP>
        </ArrivalDetails>
    </FlightPlan.FlightPlan>
</SimBase.Document>

IMHO: If I recall the route string - why does the GUI not mimic that approach?
I would think that procedure entry / exits would be helpful to be expanded at least in the GUI

Also there is no mean to know if and what airway was selected despite the EFB maintains internal knowledge of it - so the user is left alone with a bunch of waypoints not knowing what is going on.
I would not expect airways to be expanded but see the route string approach and a list like:

T50 ROTOS
Z669 ULMES

rather than only a list of wyps, which gets overly long when going along overseas (see below)

Why I suggest the above ?

My plan EDDF RJJA -

EDDF/07R MARUN1D MARUN Y152 ARPEG Z850 HMM L602 SUPUR P1 ROLUM P13 ASKAM L7 TIMUP DCT SOSAR DCT 69N010W 75N020W 80N040W 82N060W 82N080W 82N100W 81N120W DCT OMEKA DCT JUJXI DCT MARCC R338 NATES R220 NOGAL R220 NANAC Y810 OLDIV Y809 SUPOK SUPOKT RJJA/34L

and it does not even add the coordinate points.

Skysail · March 28, 2025, 3:59pm

I am unsure what happened there; this EFB app has no explicit WASM integrations besides what the MSFS SDK implements. I did not see any failures when I tried your flightplan. I’m happy to hear that it works now though!

What does this mean? It does not add VEBIT to your route, no. It is my understanding that we should not do this, as per the previous correspondence. Perhaps your comment is to the UI at this point, not our imported data?

The rest of your post seems aimed at the UI, and I can’t help much there obviously so that feedback is likely not directed at SimBrief / Navigraph.

bm98 · March 28, 2025, 4:28pm

true - as I don’t know what is supposed to be there and what not - I only guessed it is OK…

and yes the GUI comments are not specific to NG but using the NG plugin one ends up with the EFB GUI anyway - I hope the MS team takes a look at them

re WASM module - the package is carrying a wasm module and if the version does not change it may use the one from the cache ?? At least not clearing the cache I was left with an empty EFB after the import signaled OK - so I did as mentioned, restarted the SIM and it worked.

Thanks for the immediate feedback

Skysail · March 28, 2025, 5:07pm

I see. I don’t know what’s correct here either - we just removed the “enroute transitions” from our import following the feedback here. I’ll leave it to you and @MattNischan to advise if that was the correct move or not, but so far it is my understanding that this is the proper way!

Yes, we do have a WASM module that is true. We use it for persistence since we have had trouble with the built-in DataStore solution. That module should not have changed in this build, though, unless you had an older version of the EFB app Anyways, I’m sure that explains the situation! I’ll keep that in mind in case somebody else would encounter the same issue!