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”.
At this point, the Control Box should be finished, the last step is downloading the firmware and upload it to the board. I have covered the whole process in this post.
Now it’s testing time!
In order to test buttons and encoders, you can use the Windows Game Controllers (Start→”Set Up USB controllers”). It can check the status of up to 32 buttons, so it’s very, very limited.
A great alternative is Pointy’s Joystick Test. This simple yet very useful program allows you to test way more buttons. I have used it to test both my Auxiliary Panel and the Virpil MongoosT-50 Throttle.
Throubleshooting this Control Box is quite straightforward: software-wise there’s little to nothing to do; the harware continuity test should have been performed and passed already.
Now open DCS and start assigning you buttons. The Control Box will be seen by DCS as any other controller such as joysticks or pedals and identified by the name you have defined when you have changed the VID and PID.
Due to the changes to my setup, I had to rotate the TFT. I originally planned to rewrite the code from scratch since in the first implementation I have used different techniques but, at the end of the day, I decided to keep most of the code.
This is the original TFT for the Ka-50, based on DCS-BIOS:
..aaand *drum rolls* this is the new one!
I haven’t recorded a video yet, I will do it sooner or later.
I have added a few useful information that normally are not easy to read, such as the RPM limits for the left and right engine (impossible to read if head-down or zoomed in), the UGM8 selector (НР/АКС in Russian) to check the ballistic settings before firing a rocket / gunpod and a reminder of the Auto/Manual authority over the weapons.
A message will also remind me when it’s time to turn on the fuel tanks Cross Feed, plus a status light will confirm the switch position. The four circles represents the external pumps: when they turn off, the external tank is empty.
Finally, the VVI is now digital, with a big symbol indicating the current status: ↑, ↓, =.
This is the current status of my setup, although it won’t last long 🙂
The UFC/PRTz/PVI-800 is proving to be one of the best and most useful box I have built so far. I don’t fly the F/A-18 much so I don’t have a concrete idea of how much the UFC is used, but on the Ka-50 is great: the bottom encoder and buttons control the ABRIS, the numpad is great to input data such as target coordinates in the PVI-800 and, by simply toggling the Master Mode, I have control over the PRTz.
But my update is not finished yet! I have found a 7″ 800×600 LCD monitor that might fit well as Shkval or the F/A-18 moving map (MCPD?).
This is a diagram of the current setup (I always plan my changes in this 1:1 LibreOffice Draw-made diagram):
The first step will be the addition of two boxes, one for each MFD. The TFT will be also rotated horizontally and placed on top of the UFC.
Finally, I plan to attach the Saitek Throttle Quadrant to the bottom of the left box to increase the whole stability and, starting by one, adding the 7″ monitors. The Thrustmaster MFDs will be fixed by means of Velcro, so I can remove them in case of flying on the Ka-50.
I’m still not sure about the right LCD. It will be a later addition to the setup; I might place it vertically so it will be a decent ABRIS.
Another quick pill about Arduino, this is about setting up the IDE and manage libraries.
Arduino IDE (Integrated Development Environment) is not as advanced as other solutions but it’s quite light and easy to use. It can be found here.
Once installed, you might want to change the default sketchbook location by opening File→Preferences.
Now download, save and open a source file, for instance the one we are using in the Step by Step guide (it can be found here on AM-STUDIO’s GitHub) then compile it. You will get a number of errors, let’s review them.
Libraries are, simply put, a collection of methods and functions that tell the board how to perform certain tasks. The default package contains only a little fraction of the available libraries, not to mention the fact that you can write your own. The “Joystick” library, that our project requires, does not come by default so we have to install it in a specific location. That location is the “libraries” subfolder of the aforementioned default sketchbook location.
Let’s download the Joystick library from GitHub and install it.
Careful though to respect the order of the subfolders: the ZIP file comes with a folder called “ArduinoJoystickLibrary-master”; if you copy this folder in your libraries your project won’t compile. So:
open the ZIP file;
open the “ArduinoJoystickLibrary-master” folder;
copy the “Joystick” folder;
Paste it into your Arduino “libraries” folder.
A couple of friends had to install the “keypad” folder as well. This library can be installed in a different and faster way. Go to Sketch→Include Library→Manage Libraries and look for “keypad”. Scroll until you find the library I have selected in the following screenshot and install it.
Lord of the boards
Last step is selecting the correct board and the relative port. Depending on which board you have bought, select either “Arduino Leonardo” or “Arduino/Genuino Micro” from the Tools→Board: “xyz”. Then, in a similar way, select the correct port from the “Port” menu: Tools→Port: “xyz”.
Both entries report the last option selected.
Always try to isolate the issue. Since we are using a source code that definitely work you should fairly easily found the issue, at this stage is either a library problem or missing or a connectivy issue. The IDE suggests you where the problem is. The following, for instance, is caused by the selection of an incorrect Port.
“Solderer” – Is that even English? Not sure.. I’ve just seen the release trailer for the Kraken in Star Citizen and I got carried away..
Anyway, part 5 ended with every component allocated and screwed in its location. Now it’s time to replicate the wiring diagram into reality.
Soldering the wires is not difficult at all, it’s just a matter of practice. Here are a couple advices that might help you:
Don’t overheat! don’t leave the soldering iron in contact with wires and components for too long. You can melt the plastics of both the components and the wires.
Leave the Arduino board for last. Especially if you are not used to solder, it might happen to drop drops of melted solder wire. If one of them falls on the board, it might cause severe damages to it.
Place the wires first. Most of the components have a small hole on their pins. You can usually place your wire there before soldering it.
Pre-solder wires and contacts of any component that haven’t the aforementioned hole. By doing that you will need to hold your wire with one hand, the soldering iron with the other and that’s it: the solder material is already in place.
To pre-solder just place the iron and the solder in contact with the uncovered core of a wire. You will notice that it will be quickly covered by the solder; making your life much, much easier.
Clean your soldering iron every now and then. Solder and antioxidant might accumulate on the iron after a while (they usually form a black mass). Hold the soldering iron tight with your hand, make sure there’s nothing in the area underlying the iron and hit your table with your fist: the burnt material will drop from the soldering iron. Nice and easy.
Save your furniture! Melted solder and the iron itself are hot, easily more than 300+ deg C. Although the solder becomes cold in milliseconds, it can still damage your furniture. Place some cardboard or do your soldering on an appropriate surface. You will thank me when your wife won’t kill you for damaging her precious table 😉
If you have to connect a wire where another one is already soldered, add some solder and pre-solder the new wire. The new material will help spreading the heat.
Same as the previous point, if you do a mistake and can’t remove a soldered wire, add some solder: it may sound unintuitive but it helps spreading the heat uniformly.
That being said, this phase is quite straightforward as long as you follow a plan. I usually follow the same order I adopt when designing the wiring diagram; therefore I start from the wire that comes from the top pin of the board (although the board is always my last step) then proceed with every common connection such as GND. When the matrix is completed I then solder the encoders.
After completing the soldering of the circuit we can proceed and perform a quick test the continuity of GND, lines and buses by means of a multimeter. Do this check before connecting the board to the USB. The board is protected and we are working with low tensions but you know, better safe than sorry.
If the test doesn’t show any issue we can plug the board, load up Arduino IDE and write our firmware.
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.
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.