Flight Plan Sync and GPS DRIVES NAV1

[MSFS 2024] Bug Reports SDK: Tools/Samples/Documentation
1

As we continue working on updating our catalog of addons to native FS24 versions, we are now encountering a new problem with our MV22 Osprey product.

Flightplans created or modified using the EFB while in flight are not taken into account by the autopilot system (GPS DRIVES NAV1). (Using SU2 Beta for testing)

Technical Setup:
MV22 uses a custom WASM Map - a JS Gauge will listen for “Send to Avionics”, and when routing is received, will extract the latitude and longitude of waypoints on the route. These are then sent via CommAPI to the WASM module, which then renders the route on the displays. This is a rather common setup for WASM aircraft.

The autopilot implementation is fully stock, and testing with Autopilot Master ON, GPS DRIVES NAV1 on and AUTOPILOT NAV1 LOCK on.

What functions:
Creating flightplans on the WorldMap (prior to “Launch Flight”) works correctly:

  • Select Departure airport on worldmap
  • Select arrival Airport on worldmap
  • Use EFB to plan departure, route and arrival procedures
  • “Send to ATC and Avionics”
  • Only then start the flight
  • Upon flight started, use tablet again to “Send to Avionics”
    Upon takeoff, arm Autopilot and WYPT mode, and the aircraft will follow the route as expected.

What does not function:

  • If at any time during the flight, the route is modified and a new route is sent to avionics/atc, the aircraft is unable to capture the new route, nor will it follow the old route. Aircraft will continue following the current heading.
  • If flightplan is not created using the WorldMap, but instead a flight is loaded and only then the flightplan is created, the aircraft will be unable to capture the route.

We have tried several things to no avail. Perhaps we are missing an endpoint on JS to push the new route to the Autopilot system? We are not too sure, given that the EFB map displays the new route. In any case, any assistance would be appreciated.

EFB PLN load is still completely broken
EFB PLN load is still completely broken
2

Hello @vantech,

We have identified the offending code and have queried our excellent colleagues at Asobo regarding its purpose, as it was originally intended that the sim also update the legacy player flight plan when the File With ATC function is used. Presently, due to this code the legacy player flight plan is only updated from the File With ATC function while not in a flight session, therefore the stock sim autopilot will not act appropriately when updated outside of the world map (as the sim autopilot was and is still reading from this plan).

I will let you know when we have more information.

Thanks,
Matt

2 Likes
3

@MattNischan
Thanks a lot for the info! Looking forward to a fix from Asobo

4

Could you point me at some docs or examples on how to do this? The SDK document pages on all the JS listener APIs seem to be “coming soon”.

Edit. Found it GET_EFB_ROUTE

5

You’re looking for this listener: JS_LISTENER_PLANNEDROUTE

Hope that helps!
-Matt

1 Like
6

It does, thank you. With that and trooling through msfs-avionics-mirror/src/sdk/navigation/FacilityClient.ts at main · microsoft/msfs-avionics-mirror · GitHub I was able to coble together the code below which I’m sharing as a starting point for anyone else stumbling into this.

Short explanation is the facility listener gets the requested facility in the onFacilityReceived() method after it’s been asked for with the Coherent.call(‘LOAD_AIRPORT_FROM_STRUCT’… call. Which is called from the JS_LISTENER_PLANNEDROUTE’s “AvionicsRouteSync” event which is called by the sim when you press “Send to avionics” from the EFB.

And the facility listener is there because the the EFB route doesn’t contain the actual departure and arrival waypoints, just the name of the STAR or SID selected and that’s what getting the facility is for there. It is a mouthfull and still not even complete as the gotten facility is not even acted upon yet (need to extract the actual waypoints to show on my NAV display / FMC pages). Don’t know whether to continue with just JS or start using the MSFS Avionics Framework…

initRouteListener() {
	this.facilityListener = RegisterViewListener("JS_LISTENER_FACILITY", () => {
		console.log("facility listener registered");

		this.facilityListener.on('SendAirport', this.onFacilityReceived);
	});

	console.log("registering route listener");

	this.routeListener = RegisterViewListener("JS_LISTENER_PLANNEDROUTE", () => {
		console.log("route listener registered");

		this.routeListener.on('AvionicsRouteSync', (route) => {
			console.log('route received');

			this.currentRoute = route;

			console.log('getting APT ' + route.departureAirport);

			Coherent.call('LOAD_AIRPORT_FROM_STRUCT', route.departureAirport, (1 << 7) - 1).then((isValid) => {
				if (!isValid) {
					console.log('airport for ident ' + route.departureAirport.ident + ' not found');
				}
			}).catch((error) => {
				console.log('error ' + error);
			});
		});
	});
}

onFacilityReceived(facility) {
	console.log('received fac: ' + facility);
}
1 Like
7

Thanks for the JS example code.

There’s a possibility Working Title’s fixes in MSFS2024 SU2 to the GET_FLIGHTPLAN Coherent call (introduced in MSFS2020) will contain the JS data you need. I’m sure WT will recommend their TS framework as the ‘preferred’ method of using any feature they’ve added to MSFS2024 but at the same time their position seems to be everything should work in JS.

8

Well funnily enough, I used that call before 2024 launch, got my flight plan, everything was nice. The object that the call returns has a waypoints property with (seemingly) all waypoints from departure, enroute and arrival listed with ident and latlong info which was enough for me.
image

But now I’m seeing a similar thing to what @vantech is seeing (and sorry for hijacking your thread!). If I create or load a flight plan with the EFB on the world map and start the flight the GET_FLIGHTPLAN works perfectly. But if I do changes in the EFB, and send it either to ATC, avionics or both, after that the Coherent call returns almost like an empty flightplan? Cruising altitude is 0, waypoints are gone but then something like “approachIndex” property seems to retain it’s value?

I don’t know. Had the idea to listen for the AvionicsRouteSync event, but then get the flightplan with GET_FLIGHTPLAN, but it doesn’t seem to work that way. Also did a quick try with MSFS Avionics Framework but can’t say I’m immediately a fan. The smallest instrument with a component doing nothing is like a megabyte of javascript with things in there I’m not even using. This could be me though, as I’m not used much Node stuff. Maybe it can be tree shaken.

I think I’ll give this a rest for awhile and wait for someone “official” (like @MattNischan, from Working Title I understand?) to give us some answers.

9

This is related to the issue I mentioned identified earlier in the thread, yes.

It appears that this should be getting addressed by Asobo during the SU3 beta timeframe, per the latest information I have. So, check the changelog of the builds for this to land!

Also @EPellissier for vis.

Thanks,
Matt

10

Hello @vantech,

Can you check this now in latest SU3 (1.5.4.0)? Our understanding from Asobo is that these issues should now be addressed.

Thanks,
Matt

11

Hello @MattNischan
Did some testing today, and the issue seems to still persists. Only flight plans created from the WorldMap are taken into account by the autopilot system, at least with our implementation of the system. Any ideas?
Perhaps its an error on our side.

12

I think I’ve found the cause:

image
image1920×1407 182 KB

I’ve created a simple flight plan as an example. On the EFB, I can see the intended route I want to fly. However, on the World Map (shown in teal), MSFS automatically generates its own route. Sending route from tablet to avionics/atc does not change the route in teal.

The aircraft autopilot (with GPS DRIVES NAV1 enabled) will only follow the teal route displayed on the World Map. Even if I send the EFB route to the avionics and ATC, the teal route is not always consistently updated. Particularly on short routes, many waypoints on SID/STARs are not represented.

Additionally, if I start a flight without selecting a destination airport, no teal route is created. In that case, when I later create a flight plan in the EFB and send it to the avionics, the new route is still not reflected in GPS DRIVES NAV1. If a flightplan has been created in the worldmap, and edited while in the sim, the teal route does not reflect the change, and hence autopilot will continue following the initial route.

13

Bump @MattNischan @EPellissier

14

I’d also like to bump this and, once again, ask why 98.6% of the Coherent.js calls are still “NOTE: This page is currently a Work In Progress.” It’s been awhile now, I was hoping the work would have shown atleast some progress?

Anything, @MattNischan @EPellissier @FlyingRaccoon ?

1 Like
15

@vantech Moving this to bug report section. I was able to replicate the issue and will have it further investigated.

@RJiiFIN I don’t expect any progress on this in the near future unfortunately.
If you have questions or issues to report regarding specific calls, please create dedicated threads and I’ll do my best to provide an answer.
(I have seen your report regarding documentation inconsistencies and I’m about to have a look at it)

Regards,
Sylvain

1 Like
16

@FlyingRaccoon Could you elaborate slightly why the Coherent documentation won’t be seeing updates? Is it something Asobo doesn’t recommend developers using (if so, any alternates?) or is it just that it’s far down the priority list? I do have a few things in my mind regarding specific calls/orders of operations so I’ll create some threads, thanks.

17

No, not at all.
This is still one of the preferred way to create gauges, and the only one for UI components.

Documenting this is a big task, that the team maintaining this system does not have time to fulfill at the moment.

Regards,
Sylvain

1 Like