UPDATE: iniBuilds has confirmed on their Twitter/X page that a “full fledged developer stream” covering all aspects of the A220 project is scheduled for mid-2024, which is projected to include information on a release timeline.
Development on Synaptic Simulations’ Airbus A220 for Microsoft Flight Simulator has been continuing quietly in the background ever since the studio announced its partnership with iniBuilds to bring the project to market. That was until yesterday, when a new video was uploaded to the team’s YouTube channel giving us a detailed look into the complexity of the aircraft’s avionics.
Developer Mike first shows us the screens that compose the A220’s cockpit. To save time and resources, these are modelled within a piece of software the team has dubbed “Advanced Cockpit Emulator” or ACE. This, according to Mike, was developed in-house and has since become an invaluable resource to the team, saving loading times and computer resources from having to run the avionics suite with every other aspect of the sim in the background.
Checklists
First we look at the normal checklists. Here we see that all the checklists you would expect for every phase of flight are already in. Mike shows us the power-on checklist, and specifically draws our attention to “First we look at the normal checklists. Here we see that all the checklists you would expect for every phase of flight are already in. Mike shows us the power-on checklist, and specifically draws our attention to “sensed items”. These items appear green in the checklist without any user input, which is due to the fact that they are completed automatically based on the sensed state of the aircraft. Among these sensed items are the parking brake, batteries, PTU, hydraulics, gear lever, thrust levers and engine status.
Next, Mike moves onto the preflight checklist. This checklist contains an item known as a “conditional”, where the aircraft asks the pilot a question and, depending on the answer, the checklist may be different. In this instance, the conditional is “Flight flight of the day?”. Mike selects “yes”, and is then presented with an appropriate checklist for an aircraft which has been cold and dark overnight. We also see that there is a way to override sensed items in the checklist, if for whatever reason the aircraft fails to sense the item, or in the event you are operating under special procedures. Simmers with experience on the Boeing 787 will already have an idea of how these “sensed items” work in practice, since a very similar system operates on that type.
Mike also shows the before taxi checklist, which contains another conditional for “Single engine taxi out?”. Perhaps even more impressive though is the fact that simmers can create their own checklists and share them with other simmers. Mike doesn’t show a great deal of how this works within the airframe, but says that the team are looking to build an online tool to facilitate the sharing of checklists. Immediately the idea of operator-specific checklists to reflect airline SOPs springs to mind, although for the casual simmer, the ability to add or remove items which you always find yourself forgetting is an added bonus!
Before moving onto the next part of the video, Mike also explains that non-normal and procedure checklists are not in the aircraft… yet. He suggests that the team are going to be working to bring these into the aircraft as development progresses, as well as a number of failure conditions which would make them actually relevant to the simmer in the event of, say, an engine failure.
CPDLC
On CPDLC, Mike brings us really good news which transcends the development of this specific project. For those unfamiliar with CPDLC, it is a method of communicating with air traffic control without the use of a radio, and is primarily used by aircraft transiting across multiple FIRs (Flight Information Regions) at high altitude, where there is very little need to speak to ATC apart from to be handed off to the next frequency. For simmers, this only really comes into play when connected to an ATC network like VATSIM, and the scope of what Mike is talking about in this section really only applies to simmers who often fly on networks like VATSIM.
That being said, Mike tells us that the team want to implement a more modern and refined version of CPDLC. Synaptic are working with a number of other flight sim developers as well as the top air traffic networks to flesh out what this system should look like. Mike says that the consensus among this working group is that Hoppie (the current system used for CPDLC on networks) is getting very old and not meeting the needs of networks and pilots anymore. Therefore, the new system will be more true-to-life and based upon the ICAO specifications.
Mike tells us that a “rough draft” of the protocol is complete, and currently the team are simply working on ironing out any issues.
Mike shows us the logon page as well as a “request menu” which opens up some standard requests that might be processed using CPDLC. In the video, Mike focusses specifically on an altitude request for example’s sake, and shows how easily a message can be generated by just a few clicks. The requested altitude is entered, and tick boxes are presented for possible reasons to request the step climb/descent such as aircraft performance and weather. A “step at” field is also visible, should you wish to request enroute climb at a specific waypoint along your flight planned route. By clicking the “set” button, an ACARS message is generated using the selected criteria inputted by the user, which can then quickly be sent out to the relevant area controller by clicking the “send” button.
Mike explains that the system as shown and implemented in exactly accurate to the ICAO specification, bringing a new lever of immersion and depth to our flight simulation on virtual air traffic networks!
Mike then also briefly touches on other requests available using the new CPDLC system including requests for offsets, speeds, route directs, and voice contact. Also visible in the drop down menu shown are options for clearances, free text, monitoring and “when can we?” questions.
All in all, this is a very exciting development for the world of virtual air traffic, and judging by the fact that Synaptic has already spoken to and are working with the major VAT networks, I would make an educated guess that this new system will be integrated within pilot clients soon, without the need for the Hoppie system.
Graphical Flight Planning
The last feature that Mike treats us to in the showcase is what’s known as graphical flight planning. This is a new means of quickly building a flight plan by physically clicking on waypoints as they appear in the aircraft’s map screen. In the example depicted, might quickly builds a flight plan from Zurich to Munich, selects a departure runway and SID, and from there is able to continue planning the flight from the map screen. We can see how, using the “SYMBOL” map key, Mike is able to highlight high navaids only, and then physically scroll across the map using a trackball cursor, position this cursor over a waypoint, click on it, and then see this waypoint imported into the flight plan, along with a line being drawn from the last waypoint in the plan to this new waypoint.
Once you’re done picking waypoints from the map, the user can simply click “end” to stop their selection, and “exec” to finalise this flight plan within the flight computer. This is also then shown in the “route” page of the flight computer, with “DIRECT” to each waypoint being shown in the VIA field. It’s yet to be seen whether entire airways can be selected using the graphical flight planning mode.
As well as VORs, NDBs, waypoints, and other navigational features, users can also simply click any point on the map to bring up a set of coordinates to add to the flight plan, as well as create custom fixes through the same method of simply clicking on the map.
A “reroute” feature is also available, which seems to function effectively as a “direct to” function, but with the added benefit of being able to visually see the waypoint you’re directing to on the map.
In a similar fashion to the Airbus A320’s avionics, a “FIX” page is available where the pilot can select any fix and draw radials from the fix at any angle, as well as circles extending from the fix with a specific radius to assist with planning for arrivals and MSA.
Closing
Mike draws the video to an end there, saying that as well as the features showcased in the video, the team has been working to optimise and simplify the project structure to make it simpler to work with. Finally, Mike says that the team are looking forward to sharing more updates later this year.
When those updates do indeed come, FSElite will be quick to bring you full and detailed coverage so you don’t miss a beat!
