F-14 Released!

f-14-released-pic1

The f-14 is finally here and, simply put, it’s definitely the best DCS module so far in terms of quality and attention to the details.
I’m in love with the FM: the constant use of rudder during high-AoA manoeuvres is something I really missed and feels so natural if your are used to non-FBW or propeller aircraft and it’s main reason why I don’t really like the F/A-18 in the first place. Don’t get me wrong, the FBW totally makes sense in reality, same as the increased use of computers since the digital revolution but DCS is still a game, at the end of the day.

f-14-released-pic2-donkey
132nd.Donkey, my “chauffeur” yesterday

The RIO seat is amazing. I have already assigned most of the controls and I had to plug my ancient CH MultiFunction Panel back and use its 35 additional buttons ..and here comes the first issue: many functions, knobs especially, can’t be assigned to my encoders because an option such as “next/previous” is not available. The sub-functions of every knob are instead directly assignable That’s the case for the CAP category knob, the TID mode knob and the TID range knob. I can work around these limitations by using Arduino but I don’t want to write a custom version of the firmware for my UFC/PVI-800 box. It’s no big deal at the moment (I’m using one of my 3 TM MFDs for those) and I am use they will be implemented later.

The second issues is about exporting avionics to my 7″ LCD screen. I just need to find how the screens are called (I tried default values but no luck so far).
These two are my biggest complains so far. What? Do they look very marginal? Well, they are. And that’s because HB has done a flipping amazing job with the F-14. If you don’t have it. GET IT (and use HB’s store! I used it twice, no issues at all).

Advertisements

Getting ready for the F-14: Preliminary controls arrangement

The Tomcat is coming in three days. This is my preliminary assignment of the most common buttons in the Pilot cockpit.
Everything is still very much WIP since I won’t know how buttons will be used and which methods of binding will be available until the release day. For instance 3-way switches can be assigned to two buttons (up/down – RAZBAM does that usually) or/and real 3-way switches (pos Up, pos Down, pos Mid – ED/Belsimtek way).
Moreover, functions such as the Target Designator use are still a bit obscure to me so I might move them later to more easily accessible positions.
Another example is the Weapon Selector on the stick: will each weapon be assignable directly to a position of a hat or it will require an up/down pair of buttons?

F-14-first-setup

There are a number of unassigned buttons, I left them in order to have a flexibility until I finalize the setup.
Other temporary controls are the TACAN (Jester / Human RIO can handle it) and the AN/ARC-159.

The real challaenge is the RIO seat. I might end up using my CH MFP again!

Radio Box v3 – Getting ready for the Tomcat!

The F-14 Tomcat is finally close to the release date (13/03, 9 days!) and I really can’t wait to fly one of the few FW modules that has really managed to capture my interest despite being myself primarily a RW pilot.

The F-14 is quite different from the F/A-18 and especially the Ka-50 (you don’t say??) and there’s a little detail that really buggers me: the Master Arm. You might have noticed in fact that the F-14 has a protective cover over the Master Arm that needs to be lifted before turning it on. Other aircraft, such as the aforementioned F/A-18 or the Ka-50 have no such thing. Having to interact with two entities (protective cover and Master Arm switch) means that four buttons are now required. Can you imagine how impractical would be having to push a button to lift the in-game cover then open the Control Box cover and finally toggle the physical switch? The solution, however, is very, very simple.

..1 ..2 ..3!

Three lines of code are enough to solve the issue. This solution is rough but works decently and proves how issues can be easily solved when we write our own code.
The following is the original code. It reads the value from a pin and toggles two Joystick outputs accordingly.

radio-box-3-original-code
Master Arm switch – Original Code

As you probably have already figured out, the easiest solution is to add two more toggles so each Joystick output can control a step of the toggling process.. and that’s exactly what I did. A not-so-minor detail though: the animation. Raising the cover takes a few milliseconds so we have to insert a delay. I am using 500ms at the moment and it works for the F-5E Tiger II.

radio-box-3-new-code
New Code for Master Arm + Cover. Note the delay.

How does it work? The original code was very simple: if the pin is HIGH then Button#2 is turned on and Button #3 is turned off. Therefore by assigning Button#2=Master Arm ON and Button#3=Master Arm OFF, toggling the physical switch has the effect of toggling the in-game Master Arm. Now we have two additional entities on top of Master Arm ON and Master Arm OFF: Cover UP and Cover DOWN.
This is how the Joystick outputs must be assigned in order to make it work:
Button#2: Cover UP
Button#3: Master Arm OFF
Button#23: Master Arm ON
Button#24: Cover DOWN

Why this order, you may ask? Quite simple actually: when the pin is set HIGH then Cover UP is activated while Master Arm OFF is deactivated (we’re about to turn the in-game Master Arm ON!). Therefore the cover is now lifted and after a few milliseconds the in-game Master Arm is activated. Cover DOWN is not needed and therefore turned off.
When we toggle the physical switch again the pin is set to LOW: Cover UP is deactivated and the Master Arm OFF is turned ON; ergo the in-game Master Arm is now off and after a few milliseconds the cover is lowered.
(NOTE: If you feel more confused after this explanation than before it’s normal. Feel free to rewind your mind and pretend that the previous paragraph doesn’t exist).

If you are wondering why I have used #23 and #24 the answer is easy: those buttons didn’t exist in the previous version of the Radio Box and I haven’t changed anything else, therefore I can load the previous configuration in DCS without being forced to remap the whole Box.

Improving the idea

There are a few issues with this implementation, namely the physical switch shouldn’t be toggled back before 500ms and the animation of a particular aircraft might take more (or less) than 500ms.
If I will have issues with the F-14 I will implement an asynchronous timer to control a predefined number repetition of Button#23 ON/OFF and Button#24 ON/OFF after a certain amount of time. The process will also be controlled by a flag that interrupts it in case I toggle the physical switch back.

I’m sure that are many other ways to improve this solution, use the one you prefer!

Arduino Pills – Be Flexible or Be DCS-BIOS

This is more a Showerthoght than an actual “Arduino pill” and it’s about HID vs DCS-BIOS. It’s potentially a quite long discussion but I will keep it as short as possible by pointing out the factor that, in my opinion, is the most important: flexibility.

By using HID (Human Interface Device) your control box is “seen” by the PC as any other game controller, allowing it to be used with almost any game (I managed to fly my ships in Star Citizen via the UFC, for instance). DCS-BIOS-based controllers instead use a bus to communicate with DCS and they work on just one module (not entirely true, see below). Therefore, if your intention is to use your Control Boxes with multiple games and modules then HID is probably your best option. It must be noted thought that HID is not supported by every Arduino board (at the moment) so if you need a specific feature not provided by Arduino Leonardo or similar, well, that can be a problem.

DCS-BIOS on the other hand provides an impressive interface between your device and DCS. By using DCS-BIOS you have access to the status of most of the avionics (in the form of numerical values), then what do to with those values is entirely up to the coder. For instance, I use DCS-BIOS to interface my TFT (Arduino Uno). A fellow 132nd Virtual Wing friend uses DCS-BIOS to bring the idea of building Control Boxes to next level. Have a look!

A quick note about DCS-BIOS and multiple modules: I did some tests and my TFT worked both for the Ka-50 and the Mi-8 at the same time. I implemented a number of checks in order to understand which module was running (reading a certain variable, for instance) and then by running only the routines needed for that particular module.
Unfortunately I later scrapped the Mi-8 code because I was running out of memory..

Exporting MPCD and avionics to a secondary monitor

Howdy! I have bought a small 7″ LCD, resolution 800×600 for my setup. Here’s a quick guide about how to export avionics to an external / secondary LCD or monitor.

My main monitor is a 1920×1080 23″ or something. It’s fairly small, due to the lack of space on my desk. I have configured the additional 7″ monitor as the primary then I created an ad hoc configuration for it. The simplest way to do this is by copying and existing similar config and edit it.
Monitor cfg files can be found in \Config\MonitorSetup.

I created a few different config files but most of them are similar so I’m going into the details of just three of them:

  • RW: a single file to display the ABRIS (Ka-50), the TV screen and the RWR of the SA342;
  • F/A-18: the AMPCD is not in a really comfortable position hence I decided to export it;
  • AV8B NA: just for the sake of experimenting, I have exported the Right PCD.

Setting up the Views

This is the file for the RW. The first part of the file is similar for both configs.
_ = function(p) return p; end;
name = _('RotaryWing');
Description = 'RotaryWing: Ka-50; SA342 profile'
Viewports =
{
Center =
{
x = 0;
y = 0;
width = 1920;
height = 1080;
viewDx = 0;
viewDy = 0;
aspect = 1.777;
}
}

RIGHT_MFCD =
{
x = 1921;
y = 0;
width = 600;
height = 800;
}

SA342_TV =
{
x = 1953;
y = 0;
width = 570;
height = 490;
}

GazelleRWR =
{
x = 2071;
y = 495;
width = 300;
height = 300;
}

UIMainView = Viewports.Center

Viewports describes the main monitor, RIGHT_MFCD represents the ABRIS (default name) wherease the other two entry are included using a different tecnique I will cover later.

This is the cfg file for exporting the AMPCD:

_ = function(p) return p; end;
name = _('fa18');
Description = 'fa18'
Viewports =
{
Center =
{
x = 0;
y = 0;
width = 1920;
height = 1080;
viewDx = 0;
viewDy = 0;
aspect = 1.777;
}
}

CENTER_MFCD =
{
x = 1921;
y = 0;
width = 600;
height = 600;
}

F18RWR =
{
x = 1921;
y = 650;
width = 150;
height = 150;
}

UIMainView = Viewports.Center

It includes the code to export to the RWR. I am not currently using it since the monitor is not big enough to host both views (I have also attached a Thrustmaster MFD on top of it. Velcro rules!). I haven’t tried exporting the Left or Right MPCD but I guess the standard nomenclature will do (RIGHT_MFCD and LEFT_MFCD).

Last example, the Harrier’s Right MPCD. The beginning of the file is the same as the F/A-18 (of course the name and description are different) so I paste just the interesting part:
RIGHT_MFCD =
{
x = 1921;
y = 0;
width = 600;
height = 600;
}

Please not that this will not export the MPCD unless you bind the reletive buttons from the Controls options and activate the export in-game. The easiest way to find these controls is to open use the Search function, type “export” and bind them.

export-binding-harrier
Binding the MPCD Export controls for the Harrier.

More lua editing

Now that the Views are up and running we need to tell DCS what to export. In some cases there’s no need to do it because DCS deals with that on its own, for instance the ABRIS or the AMPCD. In other cases, we have to manually specify what to export and link them to the Views.
NOTE: these files might be overwritten in case of Repairs or Updates. You can either make a copy of the modified file and overwrite the new file every time or use OvGME or similar tools.

Exporting SA342 RWR and TV

The RWR file is located in \Mods\aircraft\SA342\Cockpit\RWR\indicator\init.lua. This is the code I have appended in order to export the RWR:
dofile(LockOn_Options.common_script_path.."ViewportHandling.lua")
try_find_assigned_viewport("GazelleRWR")

As you can see, it’s quite easy. The same principle applies to the TV; its file is located in \Mods\aircraft\SA342\Cockpit\TV\Indicator\init.lua.

dofile(LockOn_Options.common_script_path.."ViewportHandling.lua")
try_find_assigned_viewport("SA342_TV")

I have found these info on ED’s forum, credits to them.

Pictures time!

Some pics of the setup and the 7″ LCD. Note that the MPCD is not centered relatively to the TM MFD simply because of the position where I took the picture.

As usual, feel free to comment and ask if you need any help 🙂

132nd VW Training Mission: Op Snapshot

Training mission run last Sunday, it has been my first taste of multi-asset combined operation.. Juicy taste but also a very hard bite.

This slideshow requires JavaScript.

Asset that partecipated:
3x Ka-50
1x Mi-8
6x A-10C
6x F/A-18C
2x Controllers (ATC/AWACS)

Kudos to everyone involved in the planning; in particular AssafB, great mission maker, Junior that has prepared the RW package briefing and led it and the controllers. Coordinating so many assets plus having to deal with a good number of green pilots must have been tough!

This is an extract from my stream with complete Briefing and Debriefing. The full stream was 3h59’10”.

Ka-50 A-10C – Sharing Data IV: Bearing & Distance and Final Thoughts

The last part of the guide covers an alternative method of sharing a target (or, more precisely, any point) location. The reference point must be known by both parties (it can be the bullseye or an IP, just to name a couple). This method is not precises as latlong coordinates but it’s worth knowing nevertheless.


Bearing and distance

Lat/long coordinates actually are not the only way to provide the location of a target to another aircraft. As you can see in the picture regarding the ERBL, both bearing and distance are displayed besides lat/long coordinates. However those data are referred to your position, which usually changes often. Fortunately we can choose a different reference point, pressing the “MARKER” FSK. This point can be, e.g. the Bullseye used by A-10s or an IP, previously communicated and inserted with the PVI-800 (as the picture below shows).
The “MARKER” function can be activated only when the ABRIS is in ERBL mode. First of all place the ERBL cross over the Bullseye or the reference point. Now press the “MARKER” FSK. The cross will turn in a triangle, a new one will appear and all you have to do is just move it over the target. Distance and bearing to target (as well as other data) are real-time calculated.

Providing bearing and distance can be useful sometimes, but is not an accurate method. Each step you follow adds an error, which increases considerably over long distances. Moreover, bullseye coordinates saved via PVI-800 aren’t precise and the approximation introduced rounding heading values can result in an error that can be calculated as:

Position_Error = Range * Bearing_Error [in radians]

Therefore ½ degree of bearing measurement error would result in ~8.7m position error per kilometer of range from the reference point.

Moreover remember that Ka-50s use True bearing, but A-10s use Magnetic bearing. Therefore you have to subtract the magnetic declination value (MVR) every time you provide a bearing. Also remember that default unit of measurement for distance is in metric system (km).

However bearings and distance combination can be useful, especially to provide an approximated indication of target’s position. For this purpose a distinctive geographical element close to the target can be efficiently used as the reference point.

sharing-data-4-bearing-distance
Bearing & Distance from the ABRIS

Final considerations

Even if A-10s and Ka-50s haven’t a common system which should allow them to share data directly, there is more than a way to move around the problem. Summing up, the Ka-50 can use:
1. ABRIS to provide lat/long coordinates;
2. ABRIS to provide distance and bearing;
3. PVI-800 to provide lat/long coordinates;
All you have to do is choose the most performing way, basing your evaluation on your task and the situation around you.


Additional final thoughts

This guide is definitely old; there are so many new aircraft in the DCS’ skies compared to when I wrote it. Nevertheless we lack a real attack helicopter besides the Ka-50 and that makes this platform a niche yet a still relevant module.
I plan to write a similar guide for the Mi-24P and the AH-1S, depending on the capabilities of their simulated avionics.

Aye, it will take a decade 🙂