Reverse Engineering On Wilco Airbus

We have been several weeks without news on OAC. But we have been working on it after all. The main front-lines have been the integration between OAC server and Karen Core framework (some utility code as a baseline for C++ programming) and the modeling of cockpit parts (both pieces as knobs and buttons to be 3-D printed and main cockpit structure). But that’s content for future posts.

Today I’m gonna write about one of the parts of the project that scared me most: the integration between OAC server and Wilco Airbus software. Wilco Airbus is the most realistic, payware Airbus available for FSX/Prepar3D. Unfortunately, it doesn’t provide any SDK to aid cockpit builders. But fortunately, we have something called reverse engineering.

For those who are not familiarized with such stuff, reverse engineering is a discipline aimed to discover the technological principles of something from its implementation. In case of Wilco Airbus, we are interested in finding out how to interact with it from — its compiled code. It doesn’t look easy, and it is not. But impossible is nothing. Actually, I’m not the first guy who tries. Eric Marciano get it some time ago in his plugin FSUIPC Exporter. For only 45€ you may connect your cockpit to Wilco Airbus via FSUIPC. OAC will bring it to you open sourced and for free.

Further details? Well, Wilco DLL files export some functions that expose some data to be consumed outside their libraries. By reading the machine code of the library, you can make some assumptions regarding the signature of these functions and the nature and purpose of each data field of the objects they return. From that point, it’s possible to write a custom plugin that connects to FSX via SimConnect and loads the DLL accessing to these data. With some patient, you may log the values that are absolutely unknown and run the simulator to analyze their values as you interact the cockpit controls.

So far, I am able to read the most basic parameters of the cockpit, including IRS status, configured transition altitude, active TCAS mode, barometer mode and throttle position among others. I identified as well how to read more interesting stuff, as the position of most switches and the values loaded into FCU. I hope to have most of the data available for reading using this approach. For writing the values, the thing isn’t so clear. Probably determining the memory locations of the variables and writing the desired values there doesn’t work. There are exported functions for sending commands in the DLL, but reversing their signature and their inputs could be a very hard task. An alternative approach could be to handle the writing operations by using FSUIPC macros. Anyway, too soon to discuss about that.

The positive part of all this is that I am obtaining successful results. That’s encouraging. The negative part is that reading machine code is an exhausting task. Most contemporaneous programmers are not familiarized with machine code and assembler, so it isn’t easy to recognize high-level language forms and idioms in the machine code. Despite of that, it’s funny to learn this kind of very-low-level programming skills, as when you realize that that weird subroutine being called is actually malloc() or sprintf() by only seeing the calling convention and the parameters pushed into stack.

Well, these days I’ll continue working on this reverse engineering with the goal of integrating it with OAC server. I mean to do that in a way that the component that extracts the data from Wilco is decoupled from the rest of OAC, so it may be used by other projects as an alternative to FSUIPC Exporter. In parallel, I will dedicate some time to the piece and structure models. I’ll try to post more frequently to keep you updated.

Happy flying!

Moving from wxWidgets to QT

The server side of OAC is implemented in C++ language. This is due to two main reasons. Flight simulators, as almost any real-time application that must fit some responsiveness requirements, is implemented in a compiled language, typically C or C++. Using Java for this kind of software is like driving in F1 in a truck. And there is a chance that OAC requires such a grade of integration with the simulator that requires writing plugins for it, of course, in C/C++. C++ is my favorite language.

The very first implementation of the server was just a set of C++ classes that wraps serial device handling behavior and some UI based on wxWidgets for testing the device. Why wxWidgets? It seemed to be a good idea. C++, open source, portable, etc. But the nightmare comes into scene when you plan to work on C++11.

C++11 is the (new?) revision of the language appeared in (you guess?) 2011. It includes new fascinating features that makes C++ more productive and easy to use. The cons is that — well, the new features are pretty disruptive, and not easy to implement for compiler developers. In the middle 2012, not all new features are present in all compilers. But some of these features worth the risk of early-adopting the latest versions of C++ compilers.

wxWidgets does not work when using a C++11 compiler. Why? Well, I don’t know the details, but there is a reported bug in the project that claims not to compiler with -std=c++11 flag. And I had the same issue compiling OAC.

The lack of support of C++11 could be enough by its own to discard wxWidgets. But there are more reasons. wxWidgets is old, very old. It was designed when C++ was pretty young, and some of the most basic features we expect from a C++ compiler wasn’t invented yet. More concisely, the way it have to connect widget events and handlers (signals and slots in QT terminology) is weird. It is based on pointers to function members with the restriction that receiver object must be the window where the event was generated. That means that your handlers must be function members of your window class. High coupling. Not funny. In addition, the look&feel of a wxWidgets application is not fully integrated with the target desktop. It was very frustrating to see that group boxes are framed by a high-contrasted white line rather than typical Windows group boxes with a fine grey line.

In summary, wxWidgets has been discarded. I am rewriting the test utility using the QT framework, which not only supports C++11 but have in its roadmap to integrate some of its features (e.g., lambda functions) in its source code. I was unwilling to use it due to my tendency to believe that big code monsters are not good solutions (QT SDK occupies over 2GB on disk). But, after the typical issues that appear when you start with a new IDE and building tools, we are moving forwards. You may find in the repository the utility tool, capable of launching the main window and connecting to the device by requested COM port. Last night I worked on the FCU test window, which I estimate to have it coded by the end this week.

After this little break of code refactoring, I will come back to the breadboard. Next step is to connect the inputs (rotary encoders and buttons) to the Arduino board and integrate them with the test utility. That will be the last step of the device development. Next chapter will be a little harder: integrate the server with FSX and Wilco Airbus addon.

Outputs for FCU are almost done

When I started working on OAC, I had one thing clear in my mind: the first device to implement should be the Flight Control Unit. Why? Because it is complex enough to have an idea of the effort required and simple enough to built it with commodity parts (e.g., no display screen is required as for FMGS).

So I started with FCU. Breadboards, 7-segment displays, integrated circuits, rotary encoders, buttons, and cables, dozens of cables. And, of course, the Arduino board to rule them all as Sauron meant with the Middle-Earth. The first code I wrote was in the latter of July in Foz, a beautiful village in the north-west of Spain. My vacations, and I didn’t hesitate to pack my hardware parts and laptop in the case. Among relaxing sessions in the beach and delicious meals, I mounted the breadboard and programmed some code.

The device is comprised by sixteen 7-segment displays. Before purchasing the parts I realize I would have a problem with the number of output pins of the Arduino board. Each display requires 8 pins (7 segments plus dot point). That means 144 pins only for displaying numbers. That’s insane, and obviously there are some tricks to save pins.

One alternative is to use serial shift registers like the 74HC595 chip. This integrated circuits have a sort of internal memory and are able to maintain a determined digital value for their outputs. The nice point is that they are managed via serial communication. Only three pins are required to manage 8 outputs. Or even more, since the 74HC595 may be chained in cascade providing 8 more outputs per additional chip.

This is the cheapest alternative, but not the simples one. Using shift registers means programming the display logic by yourself. In other words, any number or symbol displayed is calculated by your code executed on the Arduino board. Another cons is that you will need one resistor per segment to keep the current flow in the range indicated by the manufacturer. There is another alternative, which simplifies the things by requiring more output pins of your Arduino board: the ICM7218.

The ICM7218 integrated circuit is designed to manage up to 7-segment displays using a very simple communication protocol with the microcontroller. It takes care of the current flow, so no resistors are needed. It takes care of the logic of displays, so you provide numbers which it decodes to the proper segment logic. The cons is that it takes 10 output pins to manage it.

So finally I decided to use ICM7218 rather than shift registers. So for 16 displays I needed a couple of chips, each one consuming 10 output pins of Arduino board, with a total of 20 pins dedicated to 7-segment displays. This immediately discards the most popular and cheapest Arduino board, the Arduino Uno (which only have 14 digital pins), in favor or Arduino Mega 2560 (which have the impressive amount of 54 digital pins).

Along 7-segment displays, the FCU requires some LED bars to indicate the active modes. These are indicators present in the FCU display like SPEED/MACH mode, HDG/TRACK mode, managed modes engaged…, and so on. Anyone familiarized with Airbus operation knows what I mean. This bars are wired among them when necessary. For instance, HDG and TRACK indicators cannot be active at the same time, since each one means the opposite respect the other. In addition, some modes cannot be independently controlled. For instance, the HDG/TRACK and the VS/FPA are wired, so if HDG mode is enabled, VS is enabled as well. Changing from HDG to TRACK means changing from VS to FPA. This wiring saves some output pins of the Arduino board, since only one PIN is required to manage the HDG, TRACK, VS and FPA indicators.

Not much more to say about FCU so far. I succeed to integrate it with the test utility, a desktop application that simulates the status of the FCU using a Windows form. As soon as I have it all bounded, I will upload some videos of the FCU prototype working with the test utility.

Happy flying!

Welcome to Open Airbus Cockpit Blog


For those who are wondering what the hell is this 😉 Open Airbus Cockpit is a open-source project aimed to produce software and hardware specifications to build a homemade Airbus cockpit.

There are some people out there who love aviation but, for one reason or other, didn’t dedicate their professional life to it. But there is no reason to not become aviation as a hobby in what we call virtual aviation. We use computer-assisted simulators to enjoy the pleasure of flying. In the most simpler form, they are just computer programs controlled by a combination of keyboard, mouse and joysticks. It may become more sophisticated by adding some peripherals that simulate some aircraft systems and some other monitors to provide a wider field of view. And you may even go beyond and replicate an aircraft cockpit at home that requires almost no interaction with the computer via standard keyboard or mouse 😉

Talking about cockpit building. There are some solutions in the market that provide realistic replicas of an airline cockpit, and they work very well. Unfortunately, they are too expensive for most people. A complete Airbus cockpit using such hardware may cost over 10.000€. For instance, there is a very popular replica of Airbus Flight Control Unit for around 700€. This is not an option for many people, including me.

Fortunately, there is one alternative: make it yourself. Again, there is no chance for most people. Advanced knowledge on programming and electronics is required. That’s where Open Airbus Cockpit comes into play.

Again, Open Airbus Cockpit provide the software and hardware specs required to build an Airbus A320 cockpit to be integrated with MS Flight Simulator. It is open, which means that all the software and specs are public. You may find them in GitHub. This means that most of the technical knowledge required to develop the solution is already made when you start building your cockpit. No programming, no circuit designing.

This blog is aimed to provide a way to follow the evolution of the project. So, let’s rock!