No1sonuk

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.

There's no ejection handle command in DSC-BIOS. You CAN send keybinds from an Arduino, but it would need to be a Leonardo, Pro Micro, or any other with a 32u4 processor that can act as a HID. Have a look here for an example of running DCS-BIOS and a HID on the same device: You might have to pulse the output 3 times for the ejection to work.

You might find this of interest:

There's also a new app for the Fork called DCSBIOSBridge which behaves in a similar manner to the Hub connection page

Open the model (e.g. f-5e_lod_00.edm) Set to ortho view Select TOP VIEW Left mouse button for moving the camera. Right mouse button for zoom. For f-5e_lod_00.edm: Move slider for argument 38 to -1 to remove the canopy. Move slider for argument 50 to around 0.6 to remove the pilot.

Mouse buttons seem to work for me...

Try "DCSBIOS_DEFAULT_SERIAL" at the top. I think the IRQ one doesn't work with the 32u4 processor in the Leonardo.

OK. That's the "Hub" version that's no longer supported by its original developer. I'm surprised it works at all now. You should switch to the "Skunkworks" fork (formerly called the Flightpanels Fork). That's actively maintained and updated. https://github.com/DCS-Skunkworks/dcs-bios There's an installation guide here: And a Discord here: https://discord.gg/T3bHedJk

He's a bit annoying. Myself and one of the DCS-BIOS Fork devs have posted a few responses to questions from others on there, but he's deleted them. I can only assume it's to increase his traffic when he finally gets around to making tutorial videos for things we've already done a while ago...

If you can, do resistance checks with the leads both ways round.

Do you have more than one Leo Bodnar device with the same name?

The data I have for an Airbus landing gear control lever says the panel lighting power is 5VAC 400Hz or 5VDC.