No EECH over EOS

Sounds cryptic, but if you remember, I tried to connect the EECH telemetry output via the siconbus with the Helios "Virtual Cockpit" using the EOS bus protocol. The bad news is: it won't work that way - for two reasons:

1. the binary indicator information of EECH (various indicator lights) seem not to be exported. It seems to be a bug of a previous release that was either not fixed or reoccured. Anyway, there is no way at the moment to export the indicator light status and therefore there is no chance to map them to any Helios indicator light. The good news however is, the bridge from EECH-to-Helios over EOS works in principle, although it's not relevant with the current bug.
2. There is no chance of mapping the telemetry information (altitude, speed, etc) to any of the analog inputs. The reason is, the analog EOS inputs have a discrete value range of 0 to 1024. For certain gauges (i.e. Altimeter), Helios only accepts continuous float values. The CommServer of EECH however does export float values. So there is simply one conclusion: EOS is not the right protocol to transport the telemetry data.

These two results lead to the following next steps.
First, I have to address the indicator export issues to the EECH developers community, so that those information will be exported again via CommServer.
Second, I have to find a different way of transporting the (float) telemetry data to Helios, and I already have an idea for that: Helios was initially created to receive the telemetry data from the LUA export of DCS. The format exported is a bit different to that of EECH (not much) and customizable (great!). Further, Helios provides a LUA export script for DCS out of the box, so I could use that. The major difference between DCS Lua Export and EECH CommServer is, that DCS pushes the data while EECH responds to requests. As Helios was intentionally designed to communicate with DCS, it expects the data to be pushed to it. And here comes in the siconbus. The idea is, to connect a "Pull"-Connector, that polls EECH for telemetry data with a "PUSH"-Connector that pushes the data to Helios. The polling interval is controlled by the Pull-Connector and the data is transformed on the bus.
Now I just need to find the time to implement this idea...

Device Link

In the last weeks I've been a bit away from my simulator project as I was busy with education and certification activities. Anyway, I've finished the implementation of the device link support for the simulation interconnect bus (see last blog post). The device link protocol is rather simple, as it consists only of request and response messages with a set of key-value pairs. If its just a key, it marks a request for a value - usually sent in a request message - and if it contains a value, it denotes either a set request or a response to a value request. The protocol runs over UDP and I tested it with the Commserver of Enemy Engaged.
With Device Link API that I've implemented, it should be relatively easy to create a DeviceLink Client (or even Server) that is capable of sending or responding to requests. The API basically consist of two main interfaces:

• DeviceLinkPacket - which could be a request or a response and may carry a list of parameters
• DeviceLinkParameter - carrying the numerical id of the parameter and marks the parameter as either a getter or a setter parameter and may carry a value of the parameter's type

and a couple of supplemental interfaces (DeviceLinkParameterDefinition, DeviceLinkParameterSet and DeviceLinkPacketListener) and some default implmentations for the interfaces.
A central utility class (DeviceLink) provides methods for creating request and response packets of the API types as well as parse a string into a DeviceLinkParameterSet. The DeviceLinkClient allows to connect to a DeviceLinkServer, such as the Enemy Engaged CommServer. With the listener interface, functionality can be added to the client to react upon incoming packets.

For Enemy Engaged I defined an implementation of the DeviceLinkParameterSet (HelicopterType) and for the according DeviceLinkParameterDefinitions (EECHParameter) carrying the various parameters for the helicopters. Connecting to Enemy Engaged is rather simple and I implemented an example client (for my testing purposes).


try (DeviceLinkClient client = 
new DeviceLinkClient(HelicopterType.Any)){ 

  //eechhost is mapped to localhost in hosts file, port is 10000
  client.connect("eechhost", 10000);

  //output all packets to console
  client.addPacketListener(new DeviceLinkPacketListener(){
    public void onReceive(DeviceLinkPacket incoming) {
      for(DeviceLinkParameter p : incoming.getParameters()){
        System.out.println(p);
      }
    }
  });


    
  //poll the server periodically for values
  while(...){
    DeviceLinkPacket packet;
    ...                 
    final List params = new ArrayList<>();
    //request all telemetry parameters
    for(EECHParameter.Common c : EECHParameter.Common.values()){
      params.add(DeviceLink.createParameter(c));
    }
    packet = DeviceLink.createRequest(params);
  
    System.out.printf("\t --> (%s)\n", packet);
    client.send(packet);
  }
 
} catch (IOException e) {
 ...
}

To test and play with API you may download the source code from (Simulation Interconnect Bus) - its not packaged yet.
I'd be happy to know what you think of it.

New Software Project

3 years silence and now two posts within an hours, well thats an improvement...
Last night I opened a new sourceforge project (Simulation Interconnect Bus) in order to have a repository for my code as it seems, what I've started a couple of days ago might take a bit more time and I can code while travelling as well. But what is what I've started? Lets go back a bit in time.

A long time ago I bought the Enemey Engaged: Apache vs Havoc and the Enemey Engaged: Comanche vs Hokum (EECH) helicopter simulators and spent quite some time with it. Over the years, although being a bit outdated from a technical perspective, a fine community extended the simulator with various options including exporting the MFDs to a second monitor and telemtry data over the DeviceLink protocol of IL-2 Stormovik.

Jumping to year 2013, where I was about to trashed my 8 years old notebook when I had the idea to take it apart and see what components I could use from it. I extracted the panel, bough a controler board on ebay to make a standalone monitor out of it.

Over some evenings in the basement, I build my first and simple homemade cockpit from the panel and the Thrustmaster Cougar MFD frames. With that panel I was able to use the old laptop panel as a second monitor to display the EECH MFDs.

A couple of weeks later I bought the Digital Combat Simulator series (DCS) and while learning how to fly I also tested varios community-build extensions. On of this extension was Helios, a tool to build your own virtual cockpits with gauges, panel lights and buttons that is able to connect to the DCS so that you have all you telemetry on a second or third screen. Of course my simple home-made cockpit was the major target for the exported gauges.

A couple of days ago I tested the Helios in combination with EECH. Although not natively supported, I was able to "label" the programmed MFD buttons as overlays on the screen (making it easier to remember what the buttons actually do) and mapped some actions of the programmable joystick to info-panel light of helios. The result was a much more comprehensive overview of the current flight situation and improved controls.

But I also wanted to have the telemetry data on the second screen. So I investigated a bit more and came across some supported interface in Helios called "EOS Bus". The EOS Bus and its protocol was intended to connect external electronic boards like Arduino via Serial Bus to Helios in order to map external switches, controls and indicator leds to event in Helios respectively the Simulation. So the idea came up to build a bridge between the UDP based DeviceLink protocol used by EECH (EECH CommServer) and the Serial Bus based communication of the EOS and Helios and this was the hour of birth of this project.