[Q&A] A sit down with FlyByWire

The custom autopilot (to our knowledge the first such implementation in MSFS addons) was definitely a highlight. This accomplishment emerged as a product of our initial ambitious efforts, which in turn enabled us to meticulously refine various facets of the A32NX. Among these enhancements were the flight model, FMS, Autoland capability, and a comprehensive TCAS simulation. Notably, our TCAS implementation featured AP/FD TCAS adding automated vertical guidance resolution during TCAS RA scenarios.

An equally remarkable achievement is centered around the comprehensive hydraulic system development. This is one of the deepest and most intricate simulations of the A320neo’s hydraulic systems to date, incorporating flight surface hydraulics, dynamic gear system simulation, and realistic PTU. This is what we continuously strive and work towards when building our aircraft.

Furthermore, a meticulous overhaul of the default electrical system in the Asobo A320neo, showcased our commitment to detail. Our custom electrical implementation delved into the accurate replication of circuit logic, ensuring that buses were powered in alignment with their real world counterparts. This level of fidelity extended even to the activation of exterior and interior lighting, adapting their functionality based on the status of specific electrical systems.

The intention was always to bring the systems to a level where individual quirks and obscure details are represented - and in order to faithfully do that, it is essential for our systems to be entirely custom. Default aircraft do a good job at providing a simple experience, and their programming is made according to that principle. In order to offer the level of complexity we aim for, we had to start from a clean state. The custom systems allow us to replicate things that might not necessarily seem obvious at first, but eventually lead to massive advantages when developing functionality on top of them. An example of this is the ARINC429 communications protocol - by modeling how different computers talk and signal failures, we get a faithful representation of failure effects on avionics without “hard-coding” the consequences of the failure ourselves. All of this is not possible if we build on top of default systems, which is why the codebase is almost all from-scratch nowadays.

We take particular pride in replicating LNAV and VNAV to the exact extent of its capability in real life - our goal is always to give simmers the exact experience you would have in an A320 equipped with our choice of FMS - not less, but also not more. An example is a certain type of turn that can occur after an overfly waypoint or on some course legs during SID or STAR procedures - you will notice that those turns will sometimes cause your cross-track error indicator on the navigation display to suddenly jump. In fact, this is due to a detail in how those turns are implemented in the real plane - the autopilot will not follow the green line displayed on the navigation display, but will rather capture the straight part of the active leg in the flight plan. This is one implementation detail we have replicated, and something we are particularly proud of.

flyPadOS 3, although sharing many similarities with our previous EFB offerings, now has almost completely redone internals. The team has made great strides in things such as state management and improving the general quality of our code compared to before that will enable us to do so many great things in the future much more easily. flyPadOS 3 has been such a powerful force in the way of driving changes to our existing UI, branding, and accessibility standards and we are so happy that we had the opportunity to reconsider how we create UIs with the user at the center of thought.

A fundamental question that we inevitably answered was “should the flyPad be restricted by real-world device layouts and functionality?” and the consensus was ultimately that if we wanted to give our users the best experience and integration within the simulator, we would have to do away with emulating traditional device operating system layouts and focus on making information readily accessible to users in the cleanest format possible. Although we had some doubts before, accepting that the flyPad could be a ‘magical’ place where reality and fiction intersect has opened our options up so much and we are truly happy with this decision.

flyPadOS 3 has been a great success for us in regards to it’s feature set and usability. We are very happy with the months of work done by our contributors and team implementing all of it’s aspects. One core feature we are particularly proud of is the flyPad UI’s ability to be displayed in over 30 different languages through Localazy - a first in flight simulation history.

These features listed are just an overview of the treasures found in the new iteration of flyPadOS and we are so happy to finally get this into the hands of our users after months of work from our contributors.

On hydraulic systems, a lot of things have already been done that probably only a few will notice. A lot of which we believe is a first on the flight simulation scene.

From small details like:

• pump cavitation from lack of air pressure
• electric pump speed regulation that you can notice by its sound, and that will consume the needed electrical power
• PTU physical based model, that has random parameters of wear or production dispersion, that actually spins and can run in barks or continuously in a kind of “organic” behavior

To bigger achievements, like the decision to actually model every hydraulic actuator physically, and every moving part having its own mass and hinge and attachment positions.

That last topic, while sounding a bit “obscure”, implies that when a flight computer sends a position to a flight control surface, we don’t just send back this position into MSFS. What actually happens is that the hydraulic actuator receives a target position, has its own control loop so it can use hydraulic pressure and flow to reach that position, or try to reach it, fighting wind and aerodynamic forces. If a failure occurs while the surface is deflected, you might end up with an aileron stuck in an up or down position, and taking a bit of time to reach a neutral position thanks to aerodynamic forces. This will certainly cause unwanted plane inputs for some amount of time… Be patient! That neutral position will surprisingly be a bit up, as lower pressure over the wing will suck that aileron up.

All that new hydraulic physics stuff has recently been applied to the gear system, and we believe it’s also something that was never seen before. Just try to extend and retract it in various downgraded hydraulic situations…. It will even gravity extend faster if you pull more G's in steep turns. Try not to fly inverted for the process to complete.

All those things are there, and cannot easily be noticed. But when all pieces will eventually come together, we believe you’ll get incredible results, particularly in abnormal operations where some details are even probably considered irrelevant in a level D simulator.

We have invested significant amounts of time and financial resources acquiring reference material that will help us model the cockpit and exterior accurately. While we do prioritize our modeling efforts on the A380X, we have recently fixed a long requested issue with the curved glareshield in Asobo’s model. A definitive first step of many towards accuracy in the cockpit model as we make headway with progress in other areas such as the wing and engine modeling.

We expect liveries to need to be remade for the custom model. This will be outweighed by a much better model quality allowing for higher fidelity re-creations - we plan to make a migration plan in our documentation and work with some livery makers to provide early content.

We are working on further integration of the audio system with IVAO. An example of this is the ability to control the volume of IVAO comms from the ACP (audio control panel) - as well as the integration of SELCAL functionality, allowing controllers to call the pilot via VHF and have the correct audio effects in the simulator.

Our project is entirely driven by the passion of the team members - aviation is a big part of life for a lot of us, and even our job for many as well! This means our team is very motivated to create the content we produce. Whether it is about avionics or documentation, everyone here wants to offer their best work, since it allows us to eventually reach a polished product that everyone in the group can be proud of.

In addition to our aircraft development endeavors, we've undertaken a significant project involving our documentation website . This initiative initially took root as a means to offer newcomers a straightforward text-based beginner guide, along with aviation insights vetted by pilots, specifically tailored for users of the A32NX. Over time, we've diligently enhanced this website, transforming it into a comprehensive resource that delves into virtually every facet of the A32NX. This encompasses an array of features and support topics meticulously curated to facilitate pilots in acquainting themselves with both our product and Microsoft Flight Simulator. Furthermore, we've extended coverage to our other offerings like SimBridge, complete access to Stable Release Notes, and fundamental overviews of our ongoing projects, coupled with guidance on how enthusiasts can actively contribute to these projects.

For our comprehensive guides, including the beginner's guide, we've established a dedicated section known as the "Pilot's Corner." Within this space, readers can access intricate insights into the A320neo's systems. What sets this apart is an interactive and clickable flight deck feature, enabling direct navigation to specific systems or instruments of interest onboard. Moreover, we're embarking on the creation of advanced guides. These encompass an array of topics, ranging from holding patterns, vertical navigation principles and symbology, to addressing discontinuities, and comprehending the functioning of autoland and TCAS systems. These guides amalgamate real-world applicable theories with a focus on practical utilization within the simulator environment. While it's paramount to emphasize that our guides are tailored exclusively for simulation purposes, we're enthusiastic about nurturing a deeper understanding among our readers about the intricacies of these systems, given our commitment to their lifelike emulation.

We do plan to offer the ceo engine variants at some point, however we are for now focusing on the current variant (A320-251N) in order to bring the systems to a point where we think variants can be worked on. Additionally, relying on user feedback, other variants might be prioritized before those. Our avionics and systems are made in a way to replicate how the real life counterparts adapt to configuration changes, so this will not be a difficult problem on that front.