If you are new to this site skip to ‘Dear Visitor’ some block below.
News Feb 2020
Update of PMDGDataEventServer for 737NGX
Today I put an updated (1.40) version of the PMDGDataEventServer for PMDG 737 NGX. The 2 main changes are:
- When a data value is registered that in PMDG have non interger values, PMDGDataEventServer will send the integer portion only. By registering with ‘ * ‘ the data is send multiplied by 100.
Previous version would send all received data from PMDG even if the integer value did not change. E.g. for flaps needle this will lead to the same integer number being send more than once, leading to overload of the input routine of the Arduino. This changed version will now send these values only once, until integer changes.
- I added a seach facility to the Data and Event grid to allow easy search for Data and Event mnemonics.
Update of all CDU screen only programs
I reviewed the CDU screen only programs and improved the way I handle the screenpainting. This results in faster performance and less flickering of the screen.
News Jan 2020
Today I released new versions of the PMDGDataEventServer for the newest PMDG 737NGXu for P3D.
The PMDG 737 NGXu is a ground-up rebuild of the famous PMDG 737NGX. Read on the PMDG site.
New plane means, new and (improved) SDK with more data elements and events for the cockpit builders. More on this page: PMDG 737 NGXu for P3D……
As always you will find the download links in the forum.
Previous ‘NEWS‘ you find here
Dear visitor of this site,
On this BLOG-site I write about my efforts to design hard- and software to enable me to build a cockpit and/or cockpit elements for MS Flight Simulator.
This site is not a complete guide how to build a cockpit. It’s mainly about the electronics and software that allows you to build your own panel hardware and interface these with FSX/PMDG.
I’m an electronics engineer and worked in the computer industry for many years in various functions. Support engineering, project management, marketing managers, software architect…. just to name a few.
My goal has never been to make a full blown cockpit. I do not have the place for it, nor the time. I wanted to create enough panels that it would allow me to fly PMDG 737 without having to use the mouse to click to operate switches etc.
Below I will briefly touch the history of the design and the reasoning behind it all. Read it to better understand the different programs and their differences.
Long time ago I started by looking at OpenCockpit.com. One of the reasons I did not make/copy or adapt the open cockpit IO cards was the fact that they connect to the Centronics (parallel interface). At the time the OC hardware was designed, it was a perfect, cheap and simple solution. However, parallel interfaces were disappearing from the PCs and USB was the way to go. So, I started to design my own ‘OC like’ IO Cards, but entirely based on microprocessors directly connected to the USB ports.
As the interface between SIOC and the OC hardware is not published, I had to design my own.
The first panel that I build was a MCP. I wrote the microcode, and additional software to connect USB to FS2004. For the MCP I needed 2 IO Cards of my own design. A single display card for the digits and one input/LED card for the indicators, switches and rotary encoders.
I had looked at other MCP’s build with Open Cockpit Cards. One of the things I disliked more than the Centronics interface was the complexity of the wiring for a MCP build with IO Cards.
I learned a lot from these initial designs, but I my IO Cards needed not just a microprocessor but also additional hardware (transistors and diodes, power drivers etc.). I also learned a lot from writing the software. There was another reason to abandon the initial design. If I needed 2 IO Cards for just that one MCP panel, how many would one need for a full blown cockpit?
I kept the good (software) but I decided to change my hardware architecture completely.
So, you have some hardware connected to the USB buss that can send switch events, rotary encoders data and receive display and other data. Somehow these events need to get-in to the flight simulator. So I needed a piece of software that connects those 2 together. This software should also ‘know’ what physical switch should go to which FS function.
When I defined my requirement for this piece of software I found that SIOC/IOCP from Open Cockpits covers my requirements.
One thing I hate is, when I make changes in one place I need to think of making changes in x more places, e.g. a change in hardware that would require me to make changes in the microcode and in the host software.
So I decided to design every piece in a way that I can use SIOC script as my single place of configuration data.
This left me with the task to connect my hardware (USB) to SIOC/IOCP. My program IOControl does exactly that. IOControl finds and reads the active SIOC scripts. From that it gets the information about hardware – FS function.
Controlling PMDG was more challenge. To control the FS2004 version of the PMDG NG737 we needed virtual keyboard and a lot of configuration.
For the FSX/NGX version, PMDG released a SDK. This allowed me to create a program that (sim)connects to FSX/PMDG. Through the SDK we can get all PMDG data and send events to all switches and knobs of the PMDG 737.
Lessons learned, second design
So all this led to my second design, or better; architecture. I explain this in FSIO overview. Read it first, and when you did, come back here and I explain about the Arduino developments, that I did later.
I strongly recommend to use SIOC and its scripting engine to be the centre of your cockpit as it gives you great flexibility. Also, all microprocessors in FSIO have the same microcode, not a bit different. From a software maintenance point of view this is one point less to worry about. I keep developing panel cards for this architecture.
I leave the lookup function: e.g. what hardware switch connects to what function in FSX, P3D, PMDG or Pro-Sim to a program running on the host. Let microprocessors do what they do best (scan the panel hardware) and let host programs do what they do best (lookup functions, communications with FSX etc).
A cockpit build with FSIO components does not require the builder to have C or C++ programming skills. The only ‘programming’ is building the SIOC script.
Arduino developments are in fact not a part of the FSIO architecture.
When I published the development of the PMDGDataEventServer I got a request from a visitor of my site if this program could be used by Arduino. My simple answer could have been, make sure Arduino talks to SIOC/IOCP and you can. OK, this Arduino-to-SIOC/IOCP connection requires an Ethernet Shield and for sure more programming skills.
I decided to give it a try and took the PMDGDataEventServer stripped of all the SIOC/IOCP communication and added serial interfaces.
With the PMDGDataEventServer for serial interface, Arduino ‘artist’ can now build panels that can retrieve PMDG Data and send command to it very easily. No restrictions, the full SDK is implemented. The protocol is simple and straightforward. I provide a simple Arduino program that can serve as a basis for Arduino based panels.
BTW: In the mean time I created a simple program that acts as a Serial to TCP/IP converter and allows Arduino (serial communication devices) to connect to SIOC/IOCP. This means that you can now have SIOC as central configuration engine and use a mixture of OpenCockpits IO Cards, FSIO Panel Cards and Arduino panels. If you started with OC cards you now can add Arduino build hardware or the other way around. If you started with some Arduino panels you can expand with FSIO or OC.
The difference between Arduino based panels and my FSIO based panels, is that the Arduino code is ‘panel aware’. Each Arduino in you cockpit has its own code. This means that, depending how complex and versatile your cockpit is, software maintenance gets more complex.
Arduino with FSIO Hardware
In FSIO, panel hardware and microprocessors, that drive them, are separated.
So, can we use FSIO panel hardware with other microprocessor (Arduino)? YES we can!
I have an FSIO MCP panel. The interface to FSIO panels is SPI. So in fact any computer/microprocessor with SPI interface can connect FSIO panel hardware. It just needs the right code. So I took a lot of code from the FSIO CPU cards and put it in Arduino, wrote some ‘panel aware’ code and viola. I have a working MCP that is driven by an Arduino UNO, that, on its turn talk to the PMDGDataEventServer in the FSX PC. I published about it here.
Recently PMDG released SP1D. In this SDK PMDG makes the CDU screen data available. That makes life a lot easier for CDU builders. Until this release, CDU screens had to be retrieved by software screen scraping or a little screen connected to your display card.
PMDGDataEventServer with TCP/IP interface.
Around the same time I started to release the SP1D version(s) of the PMDGDataEventServer a reader of this site asked if it would be possible to have an Ethernet (TCP/IP) interface to the DataEventServer. Again the easy answer is: connect to IOCP. However I realised that the SIOC/IOCP cannot handle the CDU screen data.
By now, you know I like those challenges. I also could see the need for myself. So I added a TCP/IP server within the Arduino/Serial version of the PMDGDataEventServer. This version already made the CDU screen available to the serial interface.
As a test program for the TCP/IP connection I wrote a virtual CDU for Windows using C#. It is fully functioning on my Windows pad laptop with detachable touch screen.The virtual CDU running on a touchscreen (windows) tablet is a perfect solution for people that do not want to build their own hardware CDU.
I made a CDU screen only version. This allows you to offload the CDU screen from your main computers graphics card. Maybe there is some one out there that will design a CDU based on Raspberry Pi. Would make a great freestanding CDU that connects to the network.
Available for you
I make all my software, microcode and designs available. You can download it free of charge but also free of any warranty from my side. If you ‘understand it’, you ‘can use it’. There is a lot of explanation on this site, read and read again. Tell me if something is not clear or is difficult to understand.
I have opened a forum for all this. Here is where you find download links for firmware and software. Please use the forum to ask questions that can be beneficial for others. PM me for all the other things.
Oh…. And let me know if you use the software and what you created with it. I want to have some clue as to, if – and how many people are using this. Share your experiences with others as I do with you through this site.
To make a full cockpit all by yourself is a crazy idea. The skillset and tools to make everything yourself is very wide. Sure one can buy things, there is a lot on the market, but that is not why I started all this.
I own a lot to Sebastian from Poland. He is a big supporter of my designs. He is my sparring partner. Sebastian checks and recheck my designs.
Sebastian also concentrates on the parts of the designs that I’m not good at; all the other hardware, like engravings and the production of PCB’s. Soon we will have some engravings for panel front, so they not only work perfect but also look perfect.
Sebastian made the PCB’s for panels. Most are professionally produced. He will make them available for you on his site: MyFirstBoeing.COM
The works is not nearly finished. Sebastian and I are working on more panels, PCB’s and front panels. We will publish as soon as we have reached some level of confidence that the designs are working.
If you have questions, remarks, feel free to use the forum or PM to contact us.