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.


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!

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!

February โ€™19 โ€“ MFDs everywhere!

Quick update about my setup. Although I don’t fly the F/A-18 I decided to get a used set of TM MFD and split it with a friend, and set it up in the only position it doens’t impede my movements: the Virpil Throttle Desk Mount. I always wanted to put something there and the third MFD is probably the best option, since I can’t put it anywhere else.

This is the result, configured for the F/A-18.

My setup – February 2019

I am waiting for the F-14, probably the only FW module I will fly regualarly, to find out if I need ad hoc box for it. In that case, I will replace the Left MFD with a new Control Box (it takes a couple minutes to swap between control boxes anyway).

Reviewing DCS-BIOS & TFT

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!

The new implementation of the TFT

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: โ†‘, โ†“, =.

October โ€™18 โ€“ Current Setup & Future plans

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.