No1sonuk

There's a "control reference" section of the DCS-BIOS files.

How are you connecting the arduino to DCS? If you're using SOCAT or the DCS-BIOS bridge, you can disconnect those by alt-tabbing out of the DCS mission. Then edit your code, upload to the arduino and reconnect it. Alt-tab back to DCS and test.

Those address constants are used to make code updates easier - assuming you have the correct library installed.

The Bodnar USB joystick boards have 8 analogue inputs... Just sayin'.

Do you have the Adafruit GFX library installed in your Arduino IDE? If not, try installing that.

AFAIK, DCS won't let you run both at once. And if it did, that's a LOT of data to be transferring twice. Input TO DCS may not be a problem between the two, though updates could break stuff. It's where you take data OUT from DCS where the addresses issue will crop up. e.g. your CDU screen lines reading code will probably fail unless you recompile it for the Fork. Having said that, you wouldn't need to rewire the hardware - just rearrange pin numbers in the code if required. Remember that the Flightpanels Fork is called a Fork because it was based on an earlier version of DCS-BIOS, and followed a different evolution to the original that became "Hub". This means it's essentially the same at its base functioning.

@Vinc_Vega It's apparently not possible. Or at least, I didn't find a way to do it - I've raised an issue with the Bort dev.

Looks to me like the resistor pulls the enable lines low in case the Arduino doesn't. The Capacitor (the English name for it) smooths and reduces noise on the power supply.

You need the whole box of code: void onCmsp1Change(char* newValue) { /* your code here */ } DcsBios::StringBuffer<19> cmsp1Buffer(A_10C_CMSP1_A, onCmsp1Change); The "void..." etc. part is what the "DcsBios::StringBuffer<19> cmsp1Buffer(0x1000, onCmsp1Change);" is looking for. BTW, it looks like you're using an old version of the library - did you see mine has "A_10C_CMSP1_A" in it? That's a new thing to make code updates easier.

Something you might come up against when using rotary encoders is the steps per detent being wrong. It might move 4 steps when you want one. See "Example 2" here for how to fix that: https://github.com/DCS-Skunkworks/dcs-bios-arduino-library/wiki/RotaryEncoder

I use Fusion360 for my physical designs and KiCAD for schematics/PCBs. I export the component positions sketch from F360 as a DXF and import that into a drawing layer in KiCAD's PCB design module. The cool part is, if you have 3D models for the parts in KiCAD, it can produce a 3D model of the board you can then import back into the CAD software and check it fits!

Were they powered hubs? Non-powered hubs may not pass enough power through.

So I see your options like this: 1) Connect both handles to one HID-enabled arduino. 2) Connect the handles on each side to their own HID-enabled Arduino and us the DCS controller binds to make either handle work. In both cases, some other functions could be handled by the HID Arduino if you need to optimise device use.

That thread was made to demonstrate it was possible to use a Leonardo where a game controller interface was required, but also not "waste" any connections that could be used for feedback. I chose that particular aircraft and light because it's a module very DCS player has access to as it's part of the basic free download. There are a lot of controls that can be implemented with DCS-BIOS without making use of the feedback. The thing with the 32u4 Arduinos is that they can be made to emulate a joystick controller AND a keyboard that will show up in DCS's control binds screen. That's not possible with a Nano or other non-32u4 based Arduino. BUT, the 32u4s can ALSO make use of DCS-BIOS controls. I'm not saying you should change all your Arduinos to one tpye, but you should consider that the original reason for having different types is to be able to choose the type you use based on what you want it to do.

The Nano has the Atmega328 processor, which doesn't have native USB, so it can't use the HID libraries. Why are you seemingly averse to using a Pro Micro? If you're willing to add a module to the Nano, why not just use another Arduino? The Pro Micro can do pretty much the same job as a Nano.