Cockpit Electronics "Ecosystem" Selection

[Matthew10_28]

I’ve decided to pursue a home cockpit, but need help deciding on the electronics “ecosystem” it will be based off of. I’ve recognized three of these systems.

 

Helios (Touchscreen monitor)

DCS-BIOS (Arduino Based)

MMJoy2 based button box/gamepad device. (Arduino based)

 

I will be building a mixed reality cockpit for the A-10c to match the dimensions in game for all the “switches and buttons that matter”. This eliminates Helios as I’ll be under a VR headset and therefore can’t see any screen. This leaves me with DCS-BIOS and MMJoy2. It’s been a toss up between these two, but based on what I’ve learned recently I think MMJoy2 is the winner, but I want to make sure my assumptions are sound for my application.

 

DCS-BIOS can send and receive information from the game. At first glance, it seems very easy to program the Arduino system it uses. The downfall I’ve recently realized is that it is not directly compatible with shift registers or any sort of port expander method (IC2) which I found to be a major flaw for a system so inclusive to all of the data coming from and going to the game. (A bit like hand loading individual sheets of paper into a printer that can print 500 sheets a minute) On its own, it’s full potential can’t be realized without some hardcore coding or more boards. I’ve learned that the intention is to connect slave Arduinos (basically one per panel) to a master Arduino over RS-485 (which I barely understand) in order to use more inputs/outputs. I’ve read recently that people are still running into limits and the solution appears to be USB hubs to connect each panel individually and avoid any conflict all together. Even this requires hard setting COM ports so they don’t randomly change should Windows feel like it. As I am not concerned with LED indicators, text readouts, gauge replication, I’m beginning to think this system allows for functionality I won’t use and to get it to use what functionality I do want is a bit expensive.

 

MMJoy2 is also Arduino based. It’s major limiting factor is that DCS world (or Windows) won’t recognize a device with more than 128 buttons. I’ve seen others create HID USB devices that appear as two separate gamepads so you effectively get 256. It does allow for the use of shift registers (74HD165 in my case as I only care about inputs). Button assignment is done in game rather than hard coded into the board making it possible for me to use buttons and switches from this in other games and other DCS modules (although clearly a problem with mixed reality as I sit in an A-10c but fly something else). This solution is also more sensitive to reassignments to the control scheme should ED decide to change something. Also, I’m unsure if every cockpit function can technically be mapped. I have a TM WH and cougar MFD’s so I’ve honestly never even looked up to see if I could reassign some of those buttons to another device. I’m currently using the head tracked VR cursor with a shift modifier on my HOTAS to toggle switches and spin dials. Even still, as I only care about 1:1 tactile feel of buttons, switches, and dials, I believe MMJoy2 to be the most appropriate. The added benefit in my case, is that I only need a $0.48 cent shift register every time I want to expand functionality into another 8 inputs rather than a $5 or more Arduino for functionality from DCS-BIOS I don’t need. I can just daisy chain as many shift registers I need (until 128 of course).

 

I recognize there are things I may not be considering. Given my application, what do you believe I should go with?

[Ranma13]

DCS BIOS has a barebones Arduino library for a good reason: it can't possibly predict all the possible devices that people will use and in what configurations. It doesn't support shift registers, I2C, SPI, parallel pins, or any other cross-device communication methods because there are many ways of doing this and many libraries out there that already handle it (not to mention different libraries for different devices).

 

You can use whatever cross-device communication method you feel is best, not just RS-485. Using a USB hub and treating each device as an individual Arduino is a decidedly bad idea because you will quickly run out of ports and the resources to handle all those devices (despite the theoretical cap of 127 USB devices, the motherboard will long run out of available resources to handle all of them). Rather, a better idea is to use multiple Arduinos that feed into a master one. This gets around two major limitations: the number of available GPIO pins per Arduino, and the length of the wire runs. It's easier to have one Arduino for each panel or each section and have them communicate with a master control board, than it is to route long wires all snaking back to one Arduino.

 

DCS BIOS allows you to bind to nearly every control in the aircraft, even ones that aren't in the controls setting. For example, there's no analog axis binding for the brightness and contrast dials in the Ka-50, but DCS BIOS exposes these controls. In comparison, MMJoy2 emulates a joystick device, which means that you'll be limited to only the controls that are in the controls setting.

 

I recommend that you start by picking up an Arduino and a few switches and playing around with it. Once you have enough switches and run out of pins on the Arduino, you can then start to play around with shift registers or a key matrix. Either way you can use DCS BIOS or MMJoy2, as they're both just software and both are free. There's not a whole lot of value in picking one or the other at this point, as you can easily switch from one to the other as your use case changes.

[Matthew10_28]

Perhaps it’s a misunderstanding of terms on my part. So DCS-BIOS does natively support shift registers, IC2, ect. It doesn’t mean it won’t work with those, but you have to write more code or integrate an external library to get your particular solution to work with DCS-BIOS. Even RS-485?

 

So I could use shift registers, button matrix, IC2. Clearly for practical reasons, we have to find a way to expand the number of input pins the Ardunio(s) can recognize for all the buttons and switches possible in the game (the A-10c in my case). I appreciate your perspective on getting around the limitations of pins on the Arduino and the length of the cable runs. I’ve gone back and forth on this myself. Have one master hub where all of the inputs get bundled or using an Arduino (or shift register, etc) per panel and allowing the buttons wiring to have a shorter run to the hub, and allow only the serial wires to be the ones with the big run length back to the central Arduino. I think this comes down to a value judgement, both monetarily and build effort wise. To me, with either DCS-BIOS or MMjoy2, I’d rather buy cheap shift registers per panel than a full blown Arduino per panel using RS-485. Either way, you’d still daisy chain each panel to each other with only the serial connection between. Button wires stay local to that panel.

 

I was not aware that DCS-BIOS could pick up things that aren’t in the controls settings. Is there a reference highlighting the controls that it pick up, but the control settings don’t? This might be the deciding factor should there be a large gap for the controls that matter to me.

 

I’ve already had a few Arduinos I’ve played with in the past for other little fun projects. Nothing I needed more pins on though. I bought a pro micro for this project and a shift register (later realized I got a shift out instead of a shift in. whoops) and started working on it straight away with the shift register since I knew I’d run into that pin limit in short order. I think you’re probably right in that I can change my mind relatively easily at this point.

[Ranma13]

I feel that you're approaching the project from the wrong standpoint. Based on what you've said, it sounds like you have limited experience with Arduino, and you're trying to build a cockpit. This is like planning a road trip from California to New York when you've just started learning how to drive. Building a cockpit is not a simple affair; it requires knowledge in programming, CAD design, electronics, part selection and sourcing, and woodworking/metalworking. You need to get the basics down first before you can move on to the more complicated stuff, which is why I recommend that you start with a single Arduino and a handful of switches and get that working with the sim first. An Arduino Uno has 20 pins that you can use as digital inputs, which is enough to implement about 2 switch panels before you need to start looking into how to expand that out. You should get that working first before moving onto the more complicated stuff.

 

With that said, to more directly answer your questions, the DCS BIOS library does not 'natively' support shift registers or I2C. MMJoy2 supports shift registers 'natively', but ultimately you still need to understand what the Arduino is doing code-wise. It sounds like you want an out-of-the-box solution that you can load onto the Arduino and have it work 100%, which is kind of what MMJoy2 gives you. However, it's almost guaranteed that you'll run into issues where, if you don't understand what's happening behind the scenes, you're not going to be able to troubleshoot. For example, shift registers can't be chained indefinitely; at some point you're going to run into issues with noise, issues with the latching signal not syncing up, putting too much load on the micro-controller, or even running out of RAM on the Arduino. Other inter-device communication protocols such as I2C and SPI require that you know how those protocols work, how to wire them up, and how to write code to send and receive message properly.

 

There's no guide that shows which controls DCS BIOS supports that the control settings doesn't. The easiest way to check is to find a control you're interested in and see what bindings are available for it in the control settings. The A-10C has the most complete set of bindings out of all the aircraft so it'll likely exist, but one thing to check is if the switch has a binding per switch position. For example, the master arm switch has 3 positions, ARM, SAFE, and TRAIN. You'll want to check that a binding exists for all 3 positions (it does for this example). This is important because if you use a 3-way latching ON-OFF-ON switch, you'll want to bind each position on the switch directly so that switch down will always set master arm TRAIN, switch middle will always set master arm SAFE, and switch up will always set master arm ARM. Other switches may only have a switch move up/down binding, which is not going to work great for latching switches because it'll likely be out of sync with the sim. I wrote a DCS BIOS control browser here: https://danieltian.github.io/dcs-bios-api/ which will show you every control that DCS BIOS supports and the types of values that you can set. You can use it to compare with the control settings within the sim.

[Matthew10_28]

Thanks you for sharing your perspective. Coming from someone who’s further down the road than I am, your guidance certainly holds weight. Your analogy of planning a road trip from California to New York is a good one. Although I admit that programming is my weakest point, being a degreed mechanical engineer working in aerospace manufacturing of assemblies including systems integration does give me a solid leg up on each of those other areas. The problem I often see in design/build programs is best summed up by a quote from Jurassic Park: “Your scientists were so preoccupied with whether or not they could, they didn’t stop to think if they should.” Bad design decisions at the front end have a negative cascading effect at every step downstream. I’m just trying to avoid that by understanding as much as I can up front before I’m halfway in and realize I’ve committed myself to a system that doesn’t suit my needs. You’re probably right in that I should gain the experience of a simple build involving a few switches first. Getting my hands a little dirty will probably help me understand what’s going on behind the scenes. Thanks for showing me that control browser. I'm sure that will come in handy.

[Mr_Burns]

Not sure you need to worry about all that, there are not that many inputs/outputs if you only want the physical switches and buttons that matter.