Home Cockpit Simulator
Control Interface Software

Read This First --> -> -> -> ->

HCSCIS project - history and reasons for major changes made during development

During its lifetime (since 2012), this inteface project was subject to a number of significant changes, which isn't surprising, considering that it is the successor of ARDref, ArdSim and ArdSimX, all of which (including HCSCI ) are basically a single continuous project, with enough major modifications to warrant a name change at certain points. The project had hundreds of versions, but SimImCockpit was always v 0.9.xx, considered unfinished, when development progress creates the need for some major changes in functionality, sometimes with the need to remove something in favor of a new approach.

It is understandable that moving from one concept to another can be seen as an inconvenience for people using the previous interface. They learned how to use it but for us, however, it was a need to respond to hundreds of emails from people who are confused and have many questions about systems or are using them incorrectly. This is one of the reasons why we end up changing this interface to something more reliable and easy to use. Sadly, sometimes it takes us a bit of time to update the needed info on the website, especially if we're actively working on a particular system and still figuring out the best way to implement it.

So, here I'd like to provide the rationale for some of the major changes that happened in HCSCI , and hopefully make it more clear why we've made them and how to use them properly.

First of all, I'd like to point out that we've been getting many hundreds of e-mails and forum questions over the years, and a lot of them were repeated questions on how to use certain features of our interface and configuration. This is one of the primary things that led to some of the changes over time, as we were made aware of features that many people found confusing or prone to bugs if used incorrectly. Some configuration features were mostly used for just one particular aircraft system. As a result, we have considered getting rid of such features when possible, instead modifying the interface in such a way that they will no longer be needed.

Major changes made when making HCSCI / SimVimCockpit after the previous ArdSimX project:

1. Parameter names instead of datarefs and commands

Initially (when started in 2012 with XPData project), it was just Arduino code that worked with in-built X-Plane UDP protocol. Then it was ARDref that expanded this concept and included the plugin, which allowed more flexibility and more efficient communication protocol. At first, these interfaces worked with X-Plane datarefs and commands in a rather simple way.
In its most basic form, this meant that one physical action (button press, encoder step) initiated one X-Plane action.

Soon, various options were added to the configuration file, such as ranges for analog input data, increment values for a single encoder step, and so on. However, most of the time these options were not something the users could freely customize, but simply something required by the plugin to work correctly. For example, the value range for flight yoke positions is always "-1,1", and the range for engine controls is "0,1". Every user who has these controls would need to specify these values in their configuration, and the values would be the same for every user.

This makes the need for such options in the configuration inconvenient, and creates more questions from users. Another example of redundancy are encoders and switches, which usually required a set of 2 commands assigned as different inputs, which will always be the same "Up/Down" or "On/Off" pair.

The same goes for many cases of multiple assignments for the same input pin. So, instead of "assign multiple functions to a button/switch", we started to include more custom functionality for some multi-purpose inputs and devices, making them act like real equipment without the need for extra configuration. We intend to program more and more aircraft systems and devices independently on any custom planes, to be used with any free X-Plane model.

Another complication in the previous interface is that anyone using a custom aircraft had to know the custom commands and datarefs it has, and use them directly in their configuration.

All of this led us to making HCSCI use pre-set parameter names (or functional determined "keywords") instead. The plugin now contains a parameter database that we made, with each keyword being an alias for a datarefs with pre-set values, a set of commands, options, or complete HCSCI custom functions with sets of conditions for its operation - whatever this aircraft parameter requires.

Parameter structure variants:

Param_Name --- > Plugin-- input - >X-Plane Command-- option -- Command(s)

Param_Name --- > Plugin-- input - >X-Plane DataRef + Value + options +Internal Conditions

Param_Name --- > Plugin-- output >X-Plane DataRef + Output Format + Options, mapping

Param_Name --- > Plugin <-- I/O -->HCSCI Function --- > X-Plane or HCSCI DataRefs/Commands

Param_Name --- > Plugin <-- I/O -->Custom Conversion Table --- > DataRef, Commands

HCSCI configurator database includes almost every control element and device that can be found in an aircraft panel. Some parameters (switches and other controls) that are not presented in the configurator yet for some reason will be added eventually.

This also allows to use the same configuration file for any aircraft, as custom aircraft datarefs and commands can be made compatible with it by using "conversion" files, some of which are included in the plugin by default or available for download.

2. One master board instead of multiple Arduinos

The main reason for switching to a system where only one board communicates with the computer were problems that some people were having with serial ports when more than 1 board was used. This proved to be system-dependant, with no easy fix by the plugin itself. It could usually be solved by installing a different serial driver. With HCSCI , we instead focused on a cheaper method of getting more inputs and outputs using multiplexers, as well as specialized slave boards that don't communicate with the computer.

3. Firmware upload via the plugin instead of Arduino IDE

One of the reasons - we wanted to protect our code. But, on top of that, the interface has developed to a point when no programming was required on part of the user at all.

The whole project initially begun as Arduino code working with built-in X-Plane communication protocol, that depended on the user programming to configure it.
Shortly afterwards, the plugin was created to allow for much more flexibility and communication efficiency, and the Arduino code became a library. Over time, going from ARDref to ArdSimX, all of the configuration was moved to the plugin's configuration file, with Arduino programming being completely optional, mostly just needed for some output devices not yet supported as-is.

By the time we were making HCSCI , we've settled on our standards for all input and output devices that could be used for it, and the controller code could now automatically initialize all these devices based on configuration data received from the plugin, eliminating the need for any programming on the user's part. The code was also made much more efficient and dependant on good performance.

Any use of inefficient third-party libraries and user code in Arduino could always badly affect such performance-sensitive devices as encoders and PWM. Now, with support for so many different devices, the code became even more sensitive to slowdowns, and any device could now be implemented without any programming, so we've decided it was time to make it closed-source firmware.

We've never positioned the libraries for our previous interfaces as open-source (even if they technically were), as they were always tailored to our plugin. We also didn't describe it as specifically an Arduino project - we provide instructions on how to connect all inputs and outputs to the controller board on our website, and throught the run of our project, sometimes the problems some users had were caused by them following some "Arduino How-To's" instead of the info on our website. It has become a very complex project, and in order for it to work efficiently and be easy to configure, certain standards need to be followed for making the cockpit.

Role of Arduino in this project

As of now, HCSCI doesn't require any knowledge of Arduino on the user's part, and doesn't require installation of Arduino IDE. Arduino is just used as a convenient and readily available platform for use as the core of your cockpit.

Currently, HCSCI plugin is the most essential part of this interface. It's a C++ program with about 15,000 lines of code.
Now it can be called a "cockpit simulator", not just an input-output interface, because many inputs are not simply executing some command, but rather call a complex function for some specific system (such as most radios).

The code in Arduino board (firmware) is more like a universal "driver" for all output devices and input controller, it's a program for AVR controller written from scratch, without using any Arduino libraries, and it almost has not changed since late 2019 (there was no need).

Major changes in HCSCI/SimVimCockpit versions during development:

1. Custom aircraft conversion tool

Making a cockpit work with custom aircraft has always been a source of many questions. In the earlier versions of our interface, custom aircraft needed a configuration file made for the specific model, with its custom datarefs and commands. In HCSCI, this is done with a conversion file instead.
The common problem is that custom commands and datarefs sometimes work very differently from the standard ones, and require in-depth knowledge to configure correctly. That's why our long-term goal has always been to remove the need for the user to make a custom conversion at all. It started with including our own conversions for several commonly used custom aircraft (including all aircraft with custom datarefs that are present in X-Plane 11 by default) bundled in the plugin.

Right now, we've settled on having an online conversion tool that includes a community variant, where approved people who know what they are doing can collaborate on making conversions that are then available for public download. The goal is to make sure that most users won't need to make a conversion themselves, as it always raises a lot of questions on how to do it properly.

As for why the conversion tool was removed from the plugin - in short, we were aiming to focus on the community converter, were planning some changes that would be hard to implement in an X-Plane menu, and would need to program two different converters at once if they were both on the website and in the plugin.

Not all parameters are available for conversion - these are parameters that already have custom HCSCI functions programmed for them, covering a wide range of device types and interconnected actions. Foremost, this includes all Radio devices. These devices will work independently of any particular plane model, if you use both physical inputs and outputs, or relevent HCSCI Panel modules. They may not always be synchronized with on-screen virtual panel of some custom model, but will still be synchronized with X-Plane systems.

Allowing to reassign some of these parameters will mean that our functions related to them will stop working correctly. This will include HCSCI Panel radio devices not working as intended. While some people may only want to build some inputs and fly with a built-in virtual panel of their aircraft model, this will be detrimential to those who want to use physical LCD and 7-segment screens or HCSCI Panel. In such dilemmas, we prioritize the correct work of a full physical cockpit, that is provided by our interface, over synchronization with virtual cockpits of custom models that may all work differently, making it next to impossible to keep the interface compatible with all of them, especially when aiming for the ease of configuration, as described earlier under "Parameter names instead of datarefs and commands".

2. Conditions and mode switches

Mode switches were initially introduced for encoders to allow switching them between 2 or more different functions. By far the most common use for it was switching a radio knob between Mhz/khz.
In time, mode switches were expanded, being able to control all types of inputs and outputs, supporting the use of different types of mode switches (button/switch/rotary).
Conditions were also added to allow using a parameter value to enable/disable a specific input or output parameter.

All this raised a lot of questions from users on how to use it properly (along with making the configurator more complex), and these options were changed several times as we tried to find the most user-friendly format for them, while keeping them versatile.

However, after we've started making our own custom functions to model the work of some devices in a more realistic way (including all the radio devices), it became clear that many of the new functions made the use of conditions and mode switches for these devices obsolete. The example is the most commonly used switch for Mhz/khz encoder - now it's all programmed in the plugin itself, and the user just needs to assign 1 parameter to an encoder and 1 parameter to its button, without the need to specify it as a mode switch.

So, with the most common use cases for mode switches and conditions now handled by pre-made plugin functions (with more to go as we will be programming more of the common devices), these configuration features are now less necessary. None of the radio devices require them now. They remain available as just an option, in case anyone still needs them for something.

3. Configurator image map

At first, the configurator contained a parameter table where you chose the parameters to assign to your board. Later, we've added image maps of different panel areas, to make it easier to find the needed elements to assign.

Now, image maps have an even more important role - they serve to automatically assign additional device options based on the exact image map you used for assignment. For example, if you were assigning buttons for a COM/NAV device, the configurator will know what image map with what device model you used for this assignment, and save this device type into the configuration file. So, to properly configure a particular device model, instead of having to set it in some separate menu you just need to use the correct image map with this device model while making your configuration (the type can always be changed by opening an image map with a different device type).

For this reason, some of the parameters have been removed from the table, and must be assigned using the image maps. The table doesn't contain the full parameter list any more, and just serves as an alternative assignment method now for parameters that haven't been included in the image maps yet.