Python Tutorial for Aerowinx PSX

Hoppie Home

File size 5.9 KiB
22-Mar-2020 16:57Z

File size 6.8 KiB
22-Mar-2020 17:54Z

File size 21.6 KiB
04-Jul-2022 19:23Z

This is a work in progress. For discussion and suggestions, please use the Aerowinx Forum.


  • 2022-07-04: AA-beta-03 Renamed the module file to all lowercase to better adhere to the Python recommendations. Couple of other Python coding style changes. Added DEMAND mode initiator with Lexicon support. Changed the MCDU head controller, in preparation of a more capable MCDU support library based on higher-level specifications and templates.
  • 2020-07-12 Added, a fully modular version of the previous code, that can be used with import. Still need to document it, but it is very comparable to the demo. Jump down to read the instructions.

Python Resources

  • Main Python Web site where you can download the interpreter and find everything else.
  • Python 3 documentation is your go-to resource for nearly all questions on what Python is and how to use it to write programs.

PSX Resources

  • PSX Networking is the official reference to all PSX network details and the list of available variables.

Explanation of the Python Code

I wrote this code with two goals in mind:
  1. Demonstrate how to work with the PSX network model.
  2. Demonstrate how the relatively new asyncio library can be used to write robust, understandable, and maintainabe network code without using threads and other artifacts that tend to make things complicated.

I do not claim that this approach is the best or that there are no other ways, and if you know what you are doing threads certainly are okay, but for many applications, keeping things asynchronous with an event loop is a very clean solution. If you are not trying to squeeze the very last bit of performance out of your multicore CPU, which needs work that is inherently parallelizable, you don't need threads. When done properly, both methods use zero CPU if there is no incoming data.

The file is not part of the tutorial and an earlier item that performs a useful function. For more info, see the PSX forum thread about it.

This is not a plain Python tutorial. If you are not sufficiently fluent in the language yet, I recommend you to use the excellent Python tutorial referenced above (part of the Python documentation) to figure out what the various language constructs do. For questions, either search the Web, or post in the appropriate thread on the Aerowinx Forum.

What does do?

Not a lot!

This script connects to PSX, and listens to the MCP Altitude Window. It shows you the value in that window every time it changes, for example when you turn the MCP Altitude knob.

If the altitude is below 37,000 ft, the Left FMC is selected (that selector knob is just below the MCP Altitude knob). If the altitude is 37,000 ft or higher, the Right FMC is selected. That's it.

However these minimal things demonstrate how to listen to simulator variables and how to kick physical controls around. You can easily add new functions while not touching the networking and database code at all.

class PSX

This structure contains the networking part of the script. It attempts to maintain a link to PSX all the time and will retry if something went amiss. When a connection has been established, the received variables are sent to the database so that they can be processed.

Note that although it is a Class, there is not such a thing as a PSX Connection Object. I abuse the class as a namespace, it only is an envelope around a few related methods, but it works fine. Having more than one PSX connection is just not going to happen anyway.

The two class variables reader and writer are to store the currently open socket to PSX. They are declared outside the connect() method because send() also needs access.

The connect() method is the work horse. It is declared as an async co-routine, so it can block itself on an I/O stream if there is nothing to do, without stopping the whole program dead. This is the core feature of the asyncio library. The method gets the usual host and port parameters to know where to find PSX.

The first block is to connect to PSX and cleanly fail that if PSX isn't ready or for whatever other reason. Note the use of the asyncio.sleep() which also is a co-routine that, when pausing this method, does not stop the whole program. That is what the await keyword does, but it needs an "awaitable" co-routine to work.

The second block is the connection handler. It loops around for each received line from PSX. If something seems odd, it ends and then the outer loop tries to to reconnect. For each received line, the code decides whether it is a Lexicon update or a normal PSX update, and calls the appropriate handler. Most of the code is to handle network issues, like usual with networking programs.

The separate send() method simply sends the given (key, value) pair to PSX. The only trick it plays, is that if a key is specified as a Lexicon mnemonic instead of as a meaningless Q-code, it will remap it to the Q-code. PSX understands and emits only Q-codes.

Note that this whole PSX class knows nearly nothing of what data PSX exchanges. Most of that is in the territory of the Db class.

class Db

Each subscribed variable is stored in the database, so that the script can get its last known value whenever it needs it. Additionally, variables may have an associated callback function that is called immediately after a change. This avoids the script having to poll variables all the time.

This class also is not supposed to be instantiated into objects, for the same reasons as the previous class. There is no use in keeping two parallel databases or two parallel PSX connections. But the class construct in Python also gives a nice "capsule" to warp up things that belong together.

A few simple dictionaries keep the relevant data structures. lexicon holds the translation map between Q-codes and variable names. variables holds the last known value of the Q-code. And callbacks contains a list, per Q-code, of all functions that should be called just after a new value for the Q-code becomes available. There is no indexing or other performance optimization beyond what Python internally does with the hash tables. Never add code just because you can. Wait until you run into performance issues first. Premature optimization is the root of all evil.

The class methods to straightforward things. You can just read the code to see what. If you don't grasp a Python construct, look it up in the excellent Python documentation referenced above. Or ask me.

function McpWdoAlt()

A very simple processing callback. It displays the new value shown in the MCP Altitude Window, and depending on its value, flips the FMC selector left or right.

Note that this function is not declared as async. It is a normal function. Only the PSX class has some async functionality, all the rest of the program is plain synchronous callable.

function Main()

Python likes it best when the main event loop is set up as a separate co-routine. This function does just that. When called, it sets up a list of tasks (in this case, just one) and waits until they all return their final result. In this program, the only task is not designed to ever return, but a Ctrl-C keyboard interrupt can cancel it which causes it to return.

Executable part

This is the part of the Python script that actually does things, instead of defining tooling like the classes and functions/coroutines. It begins with a simple check for Python 3.8 or better. Then it processes command line arguments, if any.

Before a PSX connection is opened, the script subscribes to all PSX variables it is interested in. Some of these are not related to the simulated aircraft, such as id and version. For the others, I personally prefer to use their nickname, such as FmcEicas, instead of their Q-code. The PSX Lexicon hands you the translation and this demonstration shows you how to work with it. Note that you need to subscribe to both the input and the output variables to get the lexicon mapping. The Db functions accept both nicknames and Q-codes.

Some subscriptions have an associated function that is called when a new value of that variable has been received. The McpWdoAlt() function is a good example. For the version key, I used a nameless function built with the Python lambda feature. A nice thing to study but by no means important; I could have declared a normal function as well.

Lastly, the script starts the Event Loop and feeds it the background tasks it wants to run. The program will remain in there until something blows up or you hit the Ctrl-C key to stop the script.

PSX Support Module

Much of the code in the two toplevel scripts has been isolated in a Python module, so you can cleanly separate your own code from the module that you may update once in a while. The structure of this module is largely the same as of the original monolithic code. I have improved a few sections because I also still find out better ways to code elements. Often the functionality is the same, but it reads better.

The can be used by importing it as usual. The module will load a class that you can use to connect to your PSX Main Server.

To show you how things are done, and to give a quick self-test and demonstration, the module also has code at the bottom that will be executed if you do not import it, but execute it directly as if it were a Python script (application). Just type: python and the demonstration will start. It looks for your PSX on the same machine, if you run PSX elsewhere you will need to update the IP address. Do this by adjusting the example code on line 619:


or whatever your server's IP address is.

Class PSX

Basically the same as in the monolithic script. A few more hooks to install your own functions, so you can respond to events such as PSX connecting, pausing, or disconnecting.

By adding the enter and exit "magic methods", it becomes possible to work with the Python with statement. This makes it a lot cleaner to assure the connection is properly closed when the script is ended. You can see this when you Ctrl-C the script: PSX will cleanly unplug the MCDU head, instead of just leaving the display as it was when the module ended.

I have included the previous Db class into the Client class, as nobody would have two databases supporting the same Client anyway.

Class MCDU

This is new. PSX has good support to "install" new avionics (subsystems) on the three MCDU heads, but the interface is low-level and can be cleaned up by specialized code. This class contains such code. It brings PSX up to nearly the ARINC 739A standard, so it can be used to convert PSX into a MCDU emulator for various applications. Note that it is not actually using ARINC 429 words to control the MCDUs, though this would be straightforward to add.

In order to control a MCDU, just as in reality, you must first wire it in. Each MCDU is wired separately, and each prompt is wired in separately, too, just as in a real aircraft. You first set up a "head" to define where your wires go: which MCDU (you have three), which prompt position (you have several), and which prompt text will appear there. Then, after PSX gets connected, you "plug in" the head to the aircraft, which will make the prompt appear on the actual display.

The rest of the MCDU operation is straightforward, and you are invited to check the example code in the script to see how it works. This example code doubles as self-test, nearly all available features of the MCDU class and the PSX class are exercised by it.

Independently of PSX, I am working on a MCDU control library that brings a host of features to the party. With this one you can develop professional avionics interfaces that can use PSX, but also other interfaces and components, including real aircraft. But this takes a while.

Comments? Questions?

Please use this thread on the PSX Forum for all communications about this web page. You're welcome!

© 2024 Jeroen Hoppenbrouwers For more information, mail to