A new Arduino project: the RIO seat – Part I

Heatblur released their sublime F-14 a few weeks ago and I’m totally amazed by the RIO role. Coming from rotary-wings, I learnt a great deal of things about how fixed-wing are operated and about a (fairly recent?) radar works. Obviously, I couldn’t just rely on my mouse and current setup to handle the amount of new controls therefore I ended up planning a new ad hoc control box (actually, I planned two). This is a good chance to write another step-by-step tutorial about how to plan and build a control box. For this purpose I will use the same structure I have used for my step-by-step guide; I will not go into the detail as much though.

Step I: Planning

This step took me a few weeks. For real. Since the release of the manual, I thought about how new boxes would fit into my tetris-like setup.
In primis I identified which functions are used more often: the DDD panel, alt/elev knobs plus bars and azimuth, TID, HCU and countermeasures are definitely the one that are used more often (I did not consider Radio and Tacan because I use my usual boxes for those). If you are not sure about which functions are more used in a particular airframe the answer is always the same: fly it! After a while you will have an idea decent enough to start planning.

Once I had a good understanding of which functions I wanted, I drew a 1:1 scale of the boxes with LibreOffice Draw.

Eventually I added the sketches to diagram of my setup.

None of the boxes were set in stone yet but having a full picture is very important before ordering buttons, switches, resistors and whatever else is needed in order to avoid wasting money.

Step II: Drilling

I find this step the most boring sans the soldering.. Anyway, thanks to the 1:1-scaled diagrams, this part is quite easy. A quick tip: place your switches on the box itself before drilling. Having real items in your hands is different than planning on a monitor. Pay also attention to factors such as the thickness of the box or the size of the blog where the screw rests.

..and, a couple hours later, the first glimpse at how the final panel will look like.


F-14 Released!


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.

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).

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?


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!

Arduino pills: Sending Keystrokes

Arduino has a very simple and effective way to send a keystrokes to the PC. It just takes a single instruction, Keyboard.write and the parameter is the key that we want our board to simulate. As usual, details and more info are available in the official documentation.

I use this instruction to send the F12 key and reset my Track IR.


I have assigned the big round button of my Radio Box to it since I have the habit of recentering my ancient Track IR v4 quite often.

Playing with resistors Part I: 3-way latched switches

Right after finishing my second Control Box (the so-called Radio Box since I planned it to control R800L1 and R828) I looked for a way to increase the flexibility and the capabilities of my control boxes. Something I really wanted to control were the 3-way latched switches. These switches look exactly as the 3-way momentary switches I used on my very first Control Box but are not spring-loaded to return to the central position after the release (I’m going to call them “Momentary” and “Latched” for semplicity from now on). This apparently little detail have a number of consequences: for instance Latched switches cannot be used in a basic button matrix because, by holding their position, they are a constant closed circuit whereas the Momentary are just a temporary one.

A long time ago in a High School far, far away…

There are (as usual I’d say) a number of ways to solve the issue. Mine comes from some reminiscences from the high school: Voltage Dividers. I have mentioned already the theory behind this simple circuit in the article I linked above. Now I’m going a bit more into the details of its implementation.

In primis we need some additional materials, namely two resistors for every Latched we want to implement. I usually build them in pairs unless I’m working on something specific, such as my UFC/PRTz. These resistors will be classic 10kΩ each. In addition, a stripboard or similar is also great.

The Circuit

I have used Voltage Dividers to update the initial implementation of my Radio Box. The following is an extract from the wiring diagram of the first version.


As you can see, nothing different from the examples I wrote about in my step by step guide. The Momentary switch is, in fact, part of a button matrix.

As I mentioned earlier, a stripboard is great to build the voltage divider. This is how it will look like:

Voltage Divider

You can build your own board in a different way: for instance, #1 can go straight to GND but I put it there in order to have a more clean and organized wiring diagram.
The circuit is quite simple: GND and Vcc are self-explanatory, An is the Analog input, 1-2-3 are the positions on the 3-way switch. The Analog input is required: it reads a different value depending on the position of the switch and a digital input simply cannot do that. This highlights immediately one of the limitations of this solutions, i.e. the fact that the number of Analog pins on an Arduino Leonardo board is limited to 4.

This is the result when we put everything together:


This is not really difficult, isn’t it?
That’s all for the hardware, now let’s go back to the IDE. I know you can’t wait 🙂


Since the Latched is not part of the button matrix anymore and works in a complete different way, we have to write some ad hoc code.
In primis we have to verify that the circuit is working correctly. There is a very simple firmware I use very often when I work with Analog inputs. It’s just a loop that outputs the value of an Analog input to the serial monitor. I will write an “Arduino Pill” about it at some point but for now, this is its simplified code:

#define ANALOG_PIN A3 //change A3 with your analog pin number
void setup() {
void loop() {
int analogValue = analogRead(ANALOG_PIN);

Please note the pinMode INPUT_PULLUP instruction. This instruction must be used in the Control Box firmware as well. Going into its details now sounds a bit pointless to me but make sure to have a look here for more info about how it works.

If the firmware is working correctly you should read different values depending on the position of the switch. It should be either:

  • close to zero;
  • close to 10 bit (that’s the analog pin’s precision); therefore 1023;
  • a value in-between: due to how the circuit works and the fact that we have used two identical resistors, the value should be split in two equal parts; therefore int(1023/2)=512.

Unfortunately real life is not as perfect as life is in theory, so due to electrical noise, tolerances, temperature and interferences these values can change a bit. Therefore the easiest way to implement the code is a series of nested IFs instead of comparing a precise value.
The code looks simple and kinda rushed but works fine. For testing purposes you can toggle the Joystick output into the nested IFs but I have found that it degrades considerably the performance of the board. I guess it’s because the Box “bombards” the PC with Joystick outputs instead of sending them when there is an actual status change (my code does exactly that, as a matter of fact). Anyway, the case-switch construct is easy to use, does its job and it’s very intuitive to amend when friends with no coding experience want to play with my firmwares.
WARNING: justification/rant ahead! Note that we have plenty of memory available and the box doesn’t perform any real-time or timing-sensitive operation. If you have worked with single-resister 8-bit PICs you know what I mean..

NOTE: I understand you are probably hating me for putting screenshots of the code instead of actual text but I absolutely hate how WP formats the code. I am using a free hosted versions, I haven’t found any decent plugin so far and I have no intention to pay for a full-feature hosted site. Please bear with me! 🙂

This is a picture of my Radio Box v2. The brownish board you see holds two Voltage dividers.
Radio Box - Version 2

Keep Delving!

As a last note, please google “Voltage Divider Arduino” or similar to find tons of info about how Voltage Dividers can be applied to Arduino. I’m sure you will also find solutions similar and probably better thought and explained than mine (I admit I relied a lot on trial-and-error; luckily I didn’t break anything 😛 ).
Another interesting subject is the PULLUP resistor. I just mentioned it here because its explanation is beyond of the scope of my site but I really suggest you to spend a few minutes and understand how it works. It will be very helpful later!

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.

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.

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..