I received the following questions today from Jan Svoboda and my email response failed to send for some reason. So Jan, I hope you get this and I hope you don’t mind me responding publicly as I am sure there are others with the same question. 

Dear Jan,

Many thanks for your interest in our venture. In answer to your questions the following:

Do you have any timeline when the simulator parts will be done?

• Our planning is to complete the designs and prototype build by the end of the year.

 Will you supply leather parts, canopy and other parts in the shop?

• No, we don’t plan on that at the moment but this will depend on what we find during the building of the prototype.
• We intend providing full plans, including construction methods, for all of the build.
• However, where there are more difficult components to the build, as for instance the Malcolm Hood (bubble canopy) could be, we will consider keeping a number in stock. Bear in mind though that the shipping cost for such a bulky item will be high, therefore we will endeavor to find an easy way to make these for builders.
• Leather patterns will be made available. These can be cut and stitched easily by your local leatherworkers. The same will apply to laserjet cutting of aluminium and CNC routing of plywood. Most major centres in the world have these services available and shipping things which can easily be done locally does not make financial sense.
  
• 3D Printed SLS Nylon components will be available from our Shapeways shop. (We do not make the shape files available for these for self-printing)

 And I would like to know if it will be possible to use simulator also for commercial purposes?

• The purchase of a plans set will license the builder to build one example of the simulator cockpit. This may be used privately or commercially, for instance by museums or training organisations. The software that forms the basis of the simulator, for instance DCS World’s Spitfire Mk.IX, will be subject to their licence agreements and the builder/operator will need to make their own arrangements in that regard, although we are always available and happy to provide assistance or advice.

Let me know if that that helps and feel free to ask more questions. Be sure to follow our progress on our web page and we also always appreciate any “LIKE”’s we get on our Facebook page 😊  

We are working through the painstaking process of confirming the correctness of our controls.  We have tested all the possible permutations of selected control sensors with Arduinos, DCS-BIOS and the DCS World Spitfire Mk.IX. We are able to confirm that the result is fantastic.

Now we are back-designing the instruments to incorporate Tri-Axis Hall Effect Sensors in the place of potentiometers. Not only are these much more accurate and steady, they are also very compact and have a significantly lower cost to good grade potentiometers.

Here is a full listing of the available controls in our Spitfire. All the controls are fully functional.

We have a design which replicates in exact detail the cockpit of the Supermarine Spitfire Mk.IX. We have 75 controls which can be wiggled, poked and jiggled.

How do we connect this into the virtual world?! We need something that translates our physical actions and presents it to our simulation in a manner that it can understand.

We need an Interface.

Firstly, it needs to be clear that our product is being designed in such a way that all wires from switches, encoders, sensors and potentiometers are easily accessible on wire terminal blocks, and can be connected to any interface the builder prefers to use.

That said, the last few weeks we have been doing intensive research on how we will be implementing our own design while also getting to understand other available options.

The interface consists of the necessary hardware to gather and interpret the data and then the software to present that data to the simulator in a manner it can understand.

Hardware

Those of you familiar with the Maker Culture will have come across the term Arduino. It is a wonderful open source microcontroller that has made man-machine interaction so much more accessable through its low cost and simple interface.

The Arduino was a simple choice if it could be shown that it could handle the 75 control inputs required and that it could do so simply. We knew that the Arduino Mega has 54 digital and 16 analog inputs, but it does not simply show up as a joystick controller when plugged in to a PC, so what would it take to make it talk to the simulator?

Another option would be a ready made solution which operated simply as a plug-and-play joystick. Here the most well known and best supported option would be the LeoBodnar BU0836X with 32 digital and 8 analogue inputs. Other commercial cards offering this functionality include the GP-WIZ40, DSD Designs with a 64 button controller and the Brydling B256A13 joystick controller which offered an array of 256 buttons and 13 axes. However the current support and availability of these are unclear.

The plug-and-play option has the advantage that the Spitfire simulator can be used in conjunction with any number of simulation software programs which portray the Spitfire in one of its incarnations. For VR enabled versions these include IL2 Stalingrad, MS Flight Simulator/Prepar3d and X-Plane. However, none of the versions in the sims mentioned have the fidelity or depth of systems found in the DCS World Spitfire. The P-n-P option also requires quite a bit of controller setup when used with any of these sims, including DSC World.

Software

When working with the Arduino it is no longer a simple case of plugging in your joystick. It requires a program which does the interpretation of the control inputs into a form that the simulator can understand.

Many programs have been created to achieve just that. Some of these communicate directly with the simulator and are quite specific to the simulator being run while others turn the Arduino into a plug-and-play joystick. Most of these are free to use in non-commercial applications, while some are fully open source and may be applied in any manner. These are all factors which needed to be considered in our final selection.

A selection of the software considered follows:

SimVim: As with the others, this is Arduino based. It is a very expandable interface, however there is a somewhat higher degree of complexity and it is focussed on X-Plane. It is also limited to personal use.

MMJOY2: Turns the Arduino into a plug-and-play joystick. Certainly an option for those wishing to save on a Leobodnar card and prepared to follow instructions closely on how to flash their Arduino. Limited to personal, non-commercial use only, so not suitable for museum or training type applications.

Arduino USB Joystick (Overpro): Similar to MMJOY2

MegaJoy Arduino: Similar to MMJOY2

DCS-BIOS: Some very enterprising individuals have directly mapped all the interfaces of a growing number of DCS World aircraft and translated this into a simple set of instructions which run of an Arduino. No setting up in the simulator is required once the program has been loaded onto the Arduino, and it is available for use whenever the simulator is started. It is fully open source. It is however restricted to DCS-World. It also only caters for the clickable items in the cockpit. As such the main flying controls (Rudder, Elevator, Ailerons) and a few specifics such as the primer lock and pump action need to be controlled separately.

Conclusion

There are many potential solutions depending on your preferences and specific requirements. Our selected route considers that the turn-key simulator will be used in a high-fidelity commercial setting with DCS World’s Spitfire Mk.IX. As such we will be taking the approach:

• Two off Arduino Mega’s running DCS-BIOS and catering for all the functionality that this provides.
• One Leobodnar board to allow for the non-clickable controls.

The details of our interface are as follows:

Introduction

We’ve been hard at work to research the very best simulator control options. Our selection criteria was based on a balance of the following attributes:

• the best accuracy
• the easiest installation and setup
• low cost

There are just such a plethora of options available that it became important to understand what the benefits of each are and work from there. The control options were categorised along the following lines:

• Inputs – the sensors providing information to the control devices
• Control Devices – the controller hardware which receives the Input information
• Control Software – the software that is required for the Control Devices in order to interpret the Inputs and provides the simulator with information it can understand.

As indicated in various previous posts, there is no need to read information from the simulator to control external monitors, gauges and the like. Given that our simulator is built around VR interaction, our controls only need to provide a one direction feed to the simulator. In other words, we are creating a giant joystick interface.

The following is a summary of our findings on means of input. We will post separately on the control devices and control software.

For inputs we differentiate between Digital (as in switching) and Analog.

Digital Inputs

The Digital inputs can be:

• Physical –
  • Toggle switches (Lever and Rocker),
  • Pushbuttons (momentary, latching and interlocked latched) and finally
  • Rotary switches.
  • In our design we use both Toggle switches and Pushbuttons but not Rotary.
• Hall Effect – This is switched by the proximity of a magnet. They can be:
  • Latching (switch stays in position even when the magnet is removed, and can be either
    • pole sensitive where you need say a South Pole to activate and deactivate the switch, or
    • Non-pole sensitive, where any pole will do.)
  • Non-latching (switch flips as soon as the magnet is removed). Again, these can be:
    • Pole sensitive – examples are the Allegro A1101/2/3/4/6, which switch on South Pole only
    • Non-pole sensitive – example the UTC UH8104
  • In our design we use exclusively the UTC UH8104 non-latching, non-pole sensitive switches for the proximity sensing of the following:
    • switch cover is open or closed
    • fuel cut-off position
    • gunsight dimmer slider position
    • chassis control lever position
    • (the incorporation of these are currently undergoing redesign)
  • Finally it should be noted that Hall Effect Sensors come with through-the-hole (SIP3) wiring or as SMD (Surface Mounted). The latter makes it a pain to connect so we have stuck with units that are available in through-the-hole.
• Encoders – These send on/off signals or pulses through two channels. The signals between the two channels are offset in a certain pattern depending on which way the encoder is being turned. It is then up to a controller to determine the direction and speed and provide that information to the simulator. It really provides multiple button or key presses and they are ideal for controls where there is no set number of rotations. An example would be setting a clock or altimeter. We have settled on a Bourns PEC11R which has a 12mm threaded through panel mount. They provide between 12 to 24 pulses per 360 degrees.

Analog Inputs

The Analog inputs serve axes of movement, such as trim, rudder, elevator, throttle etc. They can be linear, i.e. slide forward and backward, or rotary/angle sensors, measuring number of degrees turned. Most often the role for these were fulfilled by mechanical potentiometers, which slid across a resistive material thereby providing an indication of its position. These are being largely replaced by solid state Hall Effect sensors.

The advantage of Hall Effect sensors is that they provide a very steady, accurate signal, whereas potentiometers very often provide a bit of a quivering signal. A potential problem with Hall Effect sensors is that they send data in serial bitstream, which adds complexity and increases the real-time processing requirement to interpret these signals.

In the last few years however these have become more and more friendly, some providing an analog output based on a variation in voltage, typically from 2,5V to 5V.  These can then be simply used as straight-up replacements for potentiometers.

So for our design we have decided to keep it simple yet very accurate by replacing all rotary potentiometers with the Melexis Tri-Axis MLX90371 (Gen III). These are tri-axis – they provide linear and rotary on-axis or off-axis. They also come in SIP3 Through Hole and provide an analog output. It should be noted that they measure 360 degrees, so for instance for the elevator trim where 4 turns are required end to end, we will be designing printed gears.

There are a few applications where a linear Hall Effect sensor will be used, eg. the brake lever. Replacing the original design, which had a very expensive Bourns 3046 linear pot, has simplified matters greatly through the use of an Allegro A1324 linear Hall Effect Sensor, again with analog output.