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.

Long time no write

It's been a while since I posted something into this blog. A lot of things happened since back then. To make it short, I quit my job at IBM due to total absence of projects, got married, became father, started working at a swiss bank, became father again, left the bank and now I am working for a small company doing consulting in the Enterprise Content Management area. So if any of my readers (if there are any?) will expect some more postings regarding Lotus Connections or any other Lotus software (well, hope dies last)... I recommend to look somewhere else.

I intend to revive this blog and write more about what I do in private life and less what I do at work, but nevertheless I hope it might still be interessting to someone although the target group might change a bit. My recent activities regarding hobbies have been around flight simulation and home-cockpit building, although I focus less on the physical cockpit part and more on the virtual parts running on the pc.

The Gathering in Pratteln, 02/10/10

Last week I was in Pratteln (CH) watching The Gathering touring with their latest album The West Pole. I've been following this band since I was 16. Back then they made sort of Gothic Metal (starting with Death Metal on their earlier releases) and in the following years they developed their style to something they call "Trip Rock", a mix of Trip Hop and Rock, quite melancholic and gloomy, but still rock. After their last album their former singer Anneke van Giersbergen left the band in 2007 starting a solo career with Agua de Annique, leaving the band without a charismatic singer. And I must admit, they found a real good successor for Anneke in Silje Wergeland from Norway. I was positively surprised, she did a pretty good performance even on the old songs. All in all I think she fits perfectly into this likable, natural, down-to-earth group of great musicians. And of course I got another band item for my garderobe - a new hoodie - and a signed poster for home office :)



See this video from the show, playing the very first song from my first The Gathing album "Nighttime Birds"

Installing Lotus Quickr on Ubuntu Linux Server 9.10

The installation of Lotus Quickr Services for WebSphere Portal includes an installation of DB2. Installing Quickr on an out-of-the-box installation of Ubuntu will fail due to a missing C++ library. The DB2 service requires a standard C++ library in version 5. Ubuntu Linux 9.10 includes version 6 of that library. In order to install Quickr 8.1.1 on a Ubuntu 9.10 system, you have to manually install the required library from an older release. You can find the package in the Debian package repository

. Download the .deb file from the repository and install it by issuing the following command as superuser

dpkg -i libstdc++5_3.3.6-18_i386.deb

The next issue I stumbled upon was during the creation of the was profile. The default shell of Ubuntu Linux is /bin/sh which does not support arrays and therefore a call to wsadmin.sh during the profile creation fails. I found this blog entry that describes how to solve this. You have to unlink /bin/sh, link it to bash and do a reconfigure. Enter the following commands as superuser:

unlink /bin/sh
ln -s /bin/bash /bin/sh

or

dpkg-reconfigure dash

Finally, after the installation is complete, you have to change the default shell for the created DB2 instance user for Quickr (i.e. quickradm), which is set to /bin/sh. Using this shell won't properly initialize the db2 environment when running the db2profile script. You should change the shell to bash, otherwise commands like db2stop and db2start won't be accessible. To change the default shell, edit as superuser the file /etc/passwd, look for the quickr users (usually in the end), and change the /bin/sh to /bin/bash.

"Plane attack prevented by disarming Swiss Cheese Bomber"

It's a ridiculous story that happend to me yesterday. I intended to visit my mother who lives near Hamburg for the 1st advent, I bought a gift for her, as I live now in Switzerland, what is more obvious than bringing some Swiss presents so I bought a complete Swiss Fondue Set, including forks, heater, a big cheese-pot and some dishes and - of course - 1.5kg of Swiss Fondue Cheese (and also some flour for making fresh bread). All our suitcases where full (mine and that of my girlfriend) so we decided to carry the present in our hand luggage. Of course we had to pass security and we where already quite late at the airport. But at the security x-ray scanner we had two findings. One was the flour in my bag pack (scary, huh?) and the other was - you might already guess - the 1.5kg Swiss fondue cheese. Ok, you might think, it was found, considered harmless and that's all about it. But no way! The security officer told me, that this chunk of cheese is considered as liquid (!) and we where not allowed to take it on board. I thought they were kidding, but they weren't, they argued, that it contains wine - which is alcohol - and inflammable. Yes, of course, how could I forget, most of all fire accidents happen due to exploding wine bottles. They said, if I would have some time I could check it in as normal luggae (how normal is it to check in a separate chunk of cheese?). But anyway, we could not take it with us and had to leave it. My girlfriend wished them a nice fondue party and they told us they had to destroy it anyway. The fresh, new, sealed and unused chunk of cheese.
I mean, how stupid is this liquid policy? What's more obvious than carry some cheese when carrying a complete fondue set? Everyone saw it - even the security officers saw it, they looked pretty helpless explaining to us, why a chunk of cheese is a threat. Around 8mio swiss people knew that such a chunk of cheese causes if ever then most likely a bilious attack - but not a plane attack. This has nothing to do with common sense. This has even nothing to do with security or terror prevention. How could liquids in general and a chunk of cheese in special help hijacking a plane? I mean, if it's really a bomb, then the plane just explodes and that's it, you could not fly an exploding plane into a skyscraper, and it's way more easier to get a bomb into a train and blow an entire main station out of this world then getting a chunk of cheese on board of a plane. This is pure stupid, made by people that are not affected. This reminds me of former times, when the soviet central government dictated, what famers had to plant - regardless if farmers complained that the plants are not growing in that region (as I've read in the Occupation museum in Riga).
Stop stupidity and start thinking again!

Well, in the end, we arrived safe and sound in Hamburg thanks to the security authorities who disarmed the dangerous swiss-cheese bomber (me). Happy X-mas!

(and the weird end of the story is the fact, that I could easily take 80g of burning paste which was included in the heater-set onboard without noticing and which is much more inflammable than a chunk of cheese...)