Arduino, Command Gateway & Prepar3D 2.4

You may find this video interesting. It’s a demonstration of Arduino, Command Gateway and Prepar3D working together.

In the breadboards we have two ICM7218 chips. Each one is controlling one array of 7-segment displays. Each chip is controlled in turn by one Arduino board. The sketches are running a very simple program that uses oacsp.h library in order to communicate with Command Gateway. The program just registers a listener for the N1 of engine 1, in case of Arduino Uno on the top, and N1 of engine 2 in case of Arduino Mega on the right.

The purpose of this experiment is to test the behavior and performance of Command Gateway under multiple connections.

I hope you enjoyed the video.

Happy flying!

New section for Arduino Libraries and more

You may find a new section in the software page corresponding to Arduino libraries. In this new section you may find documentation on the different libraries used by Open Airbus Cockpit to implement the logic in the Arduino boards.

This section includes a download links to… the new and awesome Open Airbus Cockpit Arduino Libraries installer! Yes, my friend. Now using OAC Arduino libraries is easier than ever. You only have to download the installer and execute to have all the libraries available in your system. No more manual installation.

Unfortunately, I had not time enough to upload documentation for all the libraries that comprise the kit. Please be patient as I complete all the sections.

I hope you find this new section and the new installer useful.

Happy flying!

Moving the website… again

Yes, I know. I shouldn’t move stuff all around again and again. But, after all, that’s for good.

Now we are on wordpress.com. It’s simpler than Jekyll, and that’s important when you hardly find time to write and upload resources to the website. Also, it is much simpler to create documentation and static pages. And that’s likely the weakest part of the project: document the progress so others can reuse what I’m doing.

At least this time the URL remains the same. The hostname openairbuscockpit.org is redirected to this new website. So you’ll only notice it by the new theme.

As usual, any feedback or comment would be more than welcome.

Happy flying!

OAC Serial Protocol and Command Gateway

It sometimes happens. You can dedicate hours and hours to solve a problem, and then you realize that the solution was in front of your eyes all the time.

Some day, I was working with Prepar3D files when I found a folder named FSUIPC Documents under Modules directory of the Prepar3D installation. Once open, I saw a bunch of PDF files there and one of them called my attention: FSUIPC Lua Library Reference. Then I remembered the Lua scripting engine provided by FSUIPC. I read time ago about it. The ability to execute scripts that interacts with the internal state of the simulator. In that time, I didn’t want to look any further. I thought that’s something out of scope of Open Airbus Cockpit. But then, the curiosity lead me to open the file and check out what kind of interactions are supported by the Lua libraries. And then I realized I shouldn’t ignore the FSUIPC Lua engine the first time I knew about it.

One of the biggest challenges of the project was how to integrate the Arduino boards with the simulator. There were several options. First of all, the channel used to communicate the Arduino board with the PC: use the built-in serial over USB or a Ethernet shield? The former is cheaper but rudimentary. The former is more expensive but more flexible. And then we have to decide what’s behind the cable. Serial communication requires a very specific process running in the PC to act as a bridge between the serial device and the simulator. Ethernet requires a TCP/IP enabled process for the same.

The initial approach was to use a custom serial bridge to FSUIPC, what initiated the Wilco Exporter subproject to have the Wilco Airbus internal state available as FSUIPC offsets. Then was the time for FlightVars. An initial version using a custom protocol over TCP and some recent experiments with MQTT. But we were far away to have something that could interact with the Arduino board.

And some weeks ago I was opening that PDF file. I read about the Lua libraries available for script makers. I read about the IPC library to read and write FSUIPC offsets and LVARs. The COM library to connect with the outside world using serial ports. And the Event library to have a event-oriented design in your script. And then I realized those were the building-blocks to have a process that integrates the Arduino board with the simulation state. The building-blocks of OAC Command Gateway.

The rest was only coding. Design the OAC Serial protocol used to send write and observe commands from the Arduino to the gateway running as a Lua script, and to receive events coming from the gateway back to the board. That grants access to FSUIPC offsets and aircraft LVARs using the serial port. And that’s it. You may find OAC Command Gateway in the GitHub repository with the corresponding instructions to install it in your system.

But, Command Gateway is useless if you cannot communicate with it, isn’t it? Of course you could send the commands using the serial port with your own code. But that would be tedious. In order to solve that, the OACSP Arduino library does it for you. You’ll find OACSP in GitHub repository with the appropriate instructions on how to install it and some examples on how you can use it.

Are OACSP and OAC Command Gateway the final solution of OAC project to integrate electronics and software? Honestly, I don’t know. It depends on its limitations that will be arised as the time goes, and the benefit-cost rate of implementing a more sophisticated solution as FlightVars. Right now, OAC Command Gateway has demostrated to offer low-latency receiving events, and I’m working on some stress tests to verify its performance on a realistic setup for a cockpit. And the most important: it works. I succeed to integrate the A320 engine ignition and the ECAM control panels. And one of our beta testers (thanks David!) has designed an IAS gauge controlled by an Arduino board using OACSP with a very good performance. As long as OACSP fits the expectations, it will be the integration solution for the project.

Finally, I want to encourage you to try OACSP and OAC Command Gateway. As the rest of the results of the project, you are free to use it without any fee, and the code is available for you to adapt it to your needs according to its open source license. If you find any problem or you have any question, please don’t hesitate to ask.

Happy flying!

First Impressions on Prepar3D v2

Several weeks ago Lookheed Martin released the version 2 of their simulation platform, Prepar3D.

For those who are not familiarized with this product, I can give a short introduction and… a telling off. You should know what Prepar3D is. Many many people have been complaining that Microsoft had discontinued the Flight Simulator series. Especially after the release of Microsoft Flight, there were many enthusiasts moaning on having to flight in a simulator like FSX. But in the meantime, Prepar3D was there and not much people was paying attention to that. Until now.

That’s the end of the telling off. Now the short introduction. In 2009, Lookheed Martin bought the intellectual property of Microsoft ESP, including its source code. That means all the Microsoft’s flight simulator technology belongs to Lookheed Martin since then. In 2010 they released the first version of Prepar3D, the name of the new product based on that codebase. Not much impressive, to be honest. The most significant new feature was the night vision for military simulation, something useless for the majority of users. The rest of the product was very closed to what FSX was.

But in November 2013 the version 2 has been released. And now everybody is talking about it. The most significant differente respect version 1 is that they reimplemented the render engine moving from DirectX 9 to DirectX 11. And that’s a bunch of new amazing features that makes every of the 69 US$ of the academic license worthy.

First of all, the performance boost is spectacular. One of the most drawbacks of FSX and Prepar3D v1 was that it was coded for DirectX 9. The modern GPUs and the drivers they are shipped with are designed and optimized for modern software written for DirectX 11. That makes a high-end ATI Radeon HD 7850 with 2GB of DDR5 memory give the ridiculous 8 frames-per-second with Aerosoft Airbus X Extended on ground in a very complex airport like Aerosoft Madrid Bajaras X. You may imagine how much frustrating that is for the user (me).

With Prepar3D v2, using the same aircraft in the same airport with the same graphics card you may obtain 20 FPS. That’s not even close to the 3D standards of some cutting edge games that expect around 60 FPS or even more. I know. But 20 FPS are fair enough to have a fluent simulation. And we should take into account the new features like cockpit shadows or volumetric clouds that are more GPU demanding.

Yes, cockpit shadows. Prepar3D implements this feature that makes the cockpit surfaces to project shadows on itself. As you are flying and turning, you can appreciate that the shadows are alive, and their projection moves as the aircraft turns. I couldn’t image how realistic is that until I try it.

And yes, volumetric clouds and fog. In previous versions, the clouds were just plain textures in front of the point of view (POV). That makes a terrible efect when you fly through them. You can notice how some grey polygons appears as the aircraft cross them in an effect that recalls a night club rather than a cloud. The simulation of fog was even worse. The flog was an horizontal flat grey plane with some transparency. The things below it were seen foggy, until you descend across that plane. Again, the same polygons smashed against the aircraft nose. Even while flying above the fog, the effect is terrible if there are hills or mountains around. The fog plane crosses the hills causing the polygon joins to vibrate as the POV moves. Fortunately, all that stuff is history. Prepar3D implements volumetric clouds and flog. That means they are seen as real concentration of water particles using the GPU to render them.

IMG_0651_800x600

There are some other graphic enhancements like the reflection of the sky in the water. The moon looks pretty nice reflected on the peaceful waters of Mediterranean Sea as you flight over Valencia heading Mallorca island.

Well. Prepar3D v2 is a great advance respect its previous version and FSX, but… unfortunately, it’s not perfect after all. The changes on the render engine are massive and causes some incompatibilities with some scenarios. In particular, the Aerosoft Madrid Barajas X doesn’t work very well. As the POV moves on the taxiways, there are some phantasmagorical buildings that appear and disappear, some polygons of the fingers that are missing, etc. Also, the addon installation is still not trivial. Prepar3D v2 can be installed in your computer along v1, so it is installed in a different location. It means that any addon designed to work with Prepar3D v1 is not able to detect v2 until a new installer for that addon is shipped. You’ll have to copy files and edit config properties in order to Prepar3D v2 to use the aircrafts, scenarios, and other addons you were using with Prepar3D v1 or FSX.

In spite of these issues, Prepar3D v2 is a great product that make the difference respect its predecesors. It is the living proof that the classical Flight Simulator saga is not over as many people thought. Now we can expect more and more hours sitting on the cockpit with realistic shadows, clouds, fog, sky, water, all combined into a smooth and fluent rendering. Long live to Prepar3D!

Happy flying!

FlightVars

I think it’s time to talk about FlightVars.

One of the key points of the software architecture of Open Airbus Cockpit is how the electronic devices controlling switches, buttons, LEDs, displays, etc, communicate with the flight simulator. The hardware must have a mechanism in order to progress commands to the simulator and represent the state of the aircraft.

There are several approaches to communicate your hardware with the flight sim. None of them are perfect.

One of the most popular is FSUIPC, which has become a defacto standard for Flight Simulator addon vendors. Its popularity is due to its simplicity. The whole status of the simulation is stored in a data buffer inside the sim. FSUIPC provides two primitives, read() and write(), to obtain or alter the state of the simulation, respectively. Each primitive operates on a given offset (a internal address in the buffer), so it is possible to read and write only certain parts of the sim state.

The FSUIPC architecture is pretty fine when an addon have to change the state of the simulation. It’s a good candidate if all you want is to process commands that alter the aircraft state by writting into FSUIPC offsets. But if your addon have to observe the state of the simulation, FSUIPC is not the best solution. With only read and write primitives available, the only way to observe the simulation is to read FSUIPC offsets periodically and detect changes by comparing each result of read operation with the result of the previous call. Note that even if the datum has not changed we have to read it in order to be aware of any change. And we have to do it relatively often. The more frequently we read the less delay we will obtain from the instant the change happens and the instant we detect it. But it is obvious that we will waste more CPU (and perhaps network) resources. For an addon that have to observe a bunch of variables, that’s not a big deal. But, can you imagine an addon that reads several hundred of variables several times per second? Of course you can: that’s your cockpit. The FSUIPC approach, known as polling), may become a performance killer for your cockpit.

Other software component used to write FS addons is SimConnect. SimConnect is an API shipped with MS Flight Simulator SDK, which provides functions to read and write variables and send or receive events. Both variables and events are identified by name rather than address or offset. The event system follows the publish-subscribe pattern, so no more polling is needed in SimConnect! We can code an addon that observes the simulation by indicating what is the data it is interested in (subscribe). When any variable changes, the corresponding event is sent to the addon (publish).

SimConnect could be a very good candidate for cockpit builders if (and only if) we ignore some considerations. Firstly, and not necessarily the most important, the API is terrible. As most of APIs written by Microsoft, it’s very hard to use and understand. It implements most of the anti-patterns of software engineering. Secondly, and the most important one, any addon using SimConnect must run in the same machine as the simulator runs. And, of course, there is nothing like a SimConnect client for your favorite microcontroller. You have to implement some piece of software that interacts with your electronic devices and transmits the information to and from the simulator using SimConnect. Not funny.

Well, there are other alternatives that we should mention. IOCP Server is a very good candidate software that many people are using in their cockpits. It mixes the offset-oriented approach with a publish-subscribe mechanism across a TCP/IP network. An IOCP client connects to the server, running in a FS plugin, using TCP protocol. When connection is established, the client sends its subscriptions to the server by indicating the list of offsets it is interested in. After that, the server will respond with a variable-changed event every time that a variable changes. The client may send the same events as well to the server, indicating it wants to overwrite the current value of the variable.

The main drawback of IOCP is that the offsets are bounded to certain data, and the offset map cannot be extended without rewritting the server. If you want to publish or subscribe to a data that is not mapped by IOCP server you’ll have to think in another approach. And that’s not so unusual. Many third-party aircrafts do not use the standard variables to maintain the state of the aircraft.

We have seen several approaches, and as I introduced early, none of them are perfect for the job. That’s weird. Integrating electronic devices with a flight simulator software is not brain surgery. We should have a software component that fits perfectly to our needs as cockpit builders. We deserve it!

Now, it’s time to talk about FlightVars. Imagine a FS plugin that runs a mechanism that allows you to publish-subscribe to a variable by name. What kind of variable? Potentially, any of them. Some examples of variables could be:

  • /flightvars/fsuipc/offset/0x1234:2, which names the FSUIPC offset 0x1234 read as a 2-bytes value.
  • /flightvars/simconnect/var/Indicated Altitude:feet, which names the SimConnect variable Indicated Altitude as a value represented in feet.
  • /flightvars/projectmagenta/a320/var/apu_gen_status, which names a Project Magenta variable corresponding to the APU generator status of a A320 aircraft.

Now imagine that your addon can subscribe to any of these variables, and the plugin is able to publish any change when it happens. Imagine that your addon can publish as well any change it wants to in order to overwrite the current status of the variable. It means that you could publish-subscribe to FSUIPC offsets, SimConnect variables or internal data exported by any third-party aircraft addon using that imaginary plugin. Imagine that you can easily use connect to that plugin using an intuitive API already available in many programming languages and many microcontroller platforms. Imagine as well that extending the plugin is an easy task, you can add more namespaces to the ones that are shipped with the product. An finally, imagine this software is free or charge and open source.

Can you image all that? Congrats! You are imagining a reallity: OAC FlightVars. Want to know more? Great! Keep this frequency.

Happy flying!

Software, Hardware and vice versa

These last weeks have been plenty of software and plenty of hardware.

Let’s start talking about hardware. After several weeks flying with only the left MIP panel, I have decided to work on the rest of MIP panels. I used the same technique used for captain MIP: design the panel with Librecad, draw it onto a 3mm wood panel and cutting it using a jigsaw and a drill for the round corners. After some paint, the result is similar to the following one.

IMG_0621 IMG_0632

Work in progress, of course. I am considering the chance to cut the panels using a laser cutting machine to produce more precise shapes. But that’s an story for another post.

Now, let’s talk about software.

So far, the goal of OAC software have been to integrate the electronic components with a FS addon aircraft like Wilco A320 or Airbus X. The reason to have defined that goal is simplicity. Use an available software and reduce the task only to integrate the cockpit state with the electronics outside the simulator.

Unfortunately, that approach is not as simple as it initially seemed. The authors of Wilco Airbus and Airbus X were not thinking in cockpit building when they implemented their products. For instance, Aerosoft Airbus X is not designed to output the glass cockpit displays in separate panels. You may use a known hack, but you still will have issues with ND display. On the other hand, export the internal state of the aircraft to be handled by electronic devices is not trivial. As discussed before, Wilco Airbus doesn’t provide any API to export such data. Airbus X provides some information using SimConnect variables, but under the risk to be mistaken I guess not all of them are available (checking it is in my TODO list).

Another important drawback of using these third-party addons is that the aircraft systems are not simulated very well. As an example, let’s jump into a cold and dark Airbus X cockpit and try to connect the APU without batteries or ground power connected. That shouldn’t work at all. The APU starter is energized by the DC battery bus, which is not powered with the batteries and the external power disconnected. But, after several seconds, you’ll check that the APU has started and then all the systems are magically energized.

Well, after all, using third-party aircrafts is not a good idea after all. Alternatives?

  • We may pay thousand of euros for a Project Magenta license. But that goes against the low-cost principle of OAC project.
  • We may wait for a new addon designed for cockpit builders. An addon with a complete SDK to integrate the simulated systems with the electronic devices. An addon with aircraft systems simulated with high fidelity. Wait… how much time?
  • We may implement our own addon, designed for cockpit builders, with a rich API, with realisticly simulated systems.

I think I just revealed a proof-of-concept subproject of OAC codenamed Gwaihir. I will tell you more in upcoming posts.

 

New website

One of the weakest points of OAC project is the communication. The time you dedicate to your blog, Twitter, etc, is time you don’t dedicate to code or design hardware. Nevertheless, communication is part of the project as well. One of the lessons I recently learned is the importance of communicate the results of your work. Without that, such results are, in some sense, unsuccessful.

We are custom to hear people out there who dedicates most of their time to communication. You only have to attend any professional conference or submit to realize. Professional speakers, we might say. The first feeling I have when I hear one of those rock stars is “well, if he’s continuously twitting, posting and speaking, where is his time to do real things?”. I’m sure that’s a good question. Perhaps their work vs communication proportion is around 20-80%. 20% of his time working, 80% of his time communicating. And it works very well for them. They are popular, they are everywhere, they are known by all the community. But, are they really doing real things?

Well. My target is clearly far away from 20-80%. In my case, I fear it’s about 95-5%. And that’s a problem as well. Such a proportion is as unsuccessful as the 20-80% is. A lot of work nobody is aware of might be equivalent to no work at all. Actually 95-5% could be even worse than 20-80%. You are not even a rock star.

What would be a good proportion? Perhaps the other way around. 80-20% sounds very good to me. 80% of the time working. 20% of the time communicating. That’s my new target from now on.

So I finally decided to revisit all the communication infrastructure. Welcome to the new website of Open Airbus Cockpit project. This website replaces the former blog in Blogspot and it will host not only news but specs, designs, software downloads, howtos, etc. I promise I will post news every week to follow up the progress of the project. Right now there are several sections that are incomplete. More contents will come in the following weeks.

I hope you’ll find this new communication format more helpful.

Happy flying!

Some tests on MIP integration with Aerosoft Airbus X

I’ve been working the last weeks mainly on wood frames, the bones that will support the cockpit, and some attempts to create panels with wood and plastic. Here you have some interesting pics on the result.

IMG_0347 IMG_0312

After painting and installing the monitor that will display PDF and ND, it was time for a test flight to check how it works with Aerosoft Airbus X. Here you have some results.

Now it’s time to come back again to code. Keep tuning for some interesting announcements on Open Airbus Cockpit Software Distribution.

Open Airbus Cockpit Software Distribution v0.1 Beta is released

I should post more than I do, but unfortunately the spare time I have to work on OAC is limited, and I’d rather reserve it to code. But let me break the silence to announce a very important milestone: Open Airbus Cockpit Software Distribution (OACSD) version 0.1 has been released.

I think I’ve never talked about OACSD, so I guess some words would be appreciated. OACSD is the name given to the software distribution of OAC Project. From now on, any software piece will be packed in a installer and distributed under that product name.

What software? Well, if you follow the project progress, you might have some clues. The best way to figure out is to check out the release notes for v0.1 but let me summarize.

  • The first version of Wilco Exporter. Yes, finally we did it. Reverse engineering bore fruit, so you can enjoy a open-source, free-of-charge replacement of FSUIPC Exporter. In this version, it have some constraints (only EFIS Control Panel and FCU are supported, and only for A320 CFM) that will be eliminated in further releases.
  • liboac-commons library. This is some utility code used by Wilco Exporter that will be reused in other components in the near future. If you are a developer and are interested in C++ code that makes it easier to work with FSUIPC and SimConnect, you should check it out. If you are interested in OACSD after this brief summary, you may download it following this link.

If you have any question or comment, please do not hesitate to ask with a comment, email, bug report, etc.

Happy flying!