Avid users of Microsoft's Flight Simulator 2020 will be well aware of the name FlyByWire. An open-source development organisation that has taken the flight simulation community by storm with its high-quality freeware aircraft, and more commonly known, their Airbus A320neo enhancement.
The organisation started as a simple Reddit post from Will Pine (or Iceman on Discord) to one now, with over 190 contributors on GitHub and a dedicated core team of about 60 members. Like IVAO, their entire organisation is comprised of volunteers who spend their spare time dedicating their fantastic talent to various aspects of development, website and graphics design, social media management, documentation writing, and Discord management.
Throughout the last three years, they have been continuously breaking ceilings with the sheer commitment to delivering the A32NX project to the flight simulation community, one which is saturated with competition. Still, the statistics show that what FlyByWire stands for and delivers is loved by our community, with three million downloads by flight simulation enthusiasts of their product.
FlyByWire stands by its core principles of creating realistic flight simulation aircraft supported and verified by an ever-growing list of pilots and engineers who have joined their team to enhance the realism of the airframe further. They aim to continue developing the A32NX project as close to real life as possible and use this knowledge to maintain those same principles on their upcoming aircraft, the highly anticipated A380X, which will take to the virtual skies sooner rather than later.
You can visit the FlyByWire YouTube channel to keep up-to-date with the development of this project and the detail that the team has managed to achieve so far.
A member of the FlyByWire Simulations team said:
"We are happy to be able to partner with IVAO to share some insight in this short Q&A interview about various aspects of the organisation and our projects."
We sat down with the FlyByWire team during late summer in 2023 and spoke with them about their current products, their plans and how they were looking further to integrate their range of phenomenal aircraft with IVAO.
Here is what we discussed:
What have been some general major achievements from the start of development to now? What about some challenges?
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.
Can you explain the reasoning behind developing the custom FMS and AP?
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.
What are some details you can share about LNAV or VNAV?
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.
Can you tell us more about flyPadOS 3?
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.
What are some lesser-known aspects of the aircraft that users might not readily be aware of?
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.
What’s the current status of the new FBW A32NX Model?
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.
Are there any significant changes to the livery meshes?
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.
What are your plans for integrating IVAO further?
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.
How are you able to offer aircrafts and documentation free of charge?
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.
Do you offer detailed documentation on the handling of the aircraft?
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.
Are you planning to offer an A320-200 with CFM/IAE engines and wingtip fences?
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.
The future for FlyByWire...
FlyByWire’s Rebranding Efforts
FlyByWire’s visual identity embodies our pioneering open-source spirit, driving innovation in the flight simulation industry through high-quality, true-to-life simulations of the A320neo and A380. Since the start of the A32NX project, we’ve embarked on a comprehensive rebranding journey, uniting all our products under a single umbrella. Ensuring a consistent visual language across various platforms is pivotal in establishing familiarity and trust. Our updated philosophy embraces minimalist design principles but also touches on modernity and professionalism. We have been working to ensure that FlyByWire’s website, social media, promotional materials, all have a coherent use of typography, color palette, and imagery to unite our products and various projects. We believe this reinforces our commitment to our ideas of quality and reliability.
A prime example of this transformation is our logo, which was one of the first elements to receive a rebranding. Transitioning from the original two-tone tail, our logo is now a single gradient cyan, with the tail elegantly elongated on a 15x16 grid for enhanced scalability across all applications. While some projects are still transitioning into our current branding, our robust branding guideline document, crafted by one of our very talented media team members, provides clear directives that outline best practices and no-gos. It encompasses typographic rules, color palette usage guidelines, and graphical elements all serving as a compass for our rebranding endeavors.
Our Latest Product - SimBridge
Our latest product release, the SimBridge application, is a bespoke solution crafted to facilitate seamless connectivity between our aircraft and external devices, as well as invaluable data sources. SimBridge operates externally via the FlyByWire installer, affording us unparalleled flexibility in the integration and expansion of our onboard aircraft systems. Features bundled and run through SimBridge, allow us to bypass simulator limitations while safeguarding optimal FPS performance. By leveraging SimBridge, we’ve been able to better deploy features such as our Remote MCDU and also integrate custom built systems like our Terrain Database which has worldwide coverage.
Across all of our aircraft versions, users can readily access the aforementioned Remote MCDU feature but also curate a repository of preferred company routes, seamlessly interface with external printers to physically print relevant information from the aircraft into the real world, and conveniently peruse personally owned PDF charts and information. Our most recent integration allows pilots to utilize our terrain data to enable the Terrain Awareness and Warning Systems (TAWS) to overlay the approach terrain on the ND.
Through SimBridge we hope to start bringing more displays externally, such as the EFB, so that pilots can use our flyPadOS remotely on their tablets while flying our aircraft.
FlyByWire A32NX Project
A community-built and maintained project providing a high-quality and detailed version of the Airbus A320-251N for Microsoft Flight Simulator.