No1sonuk

I'll add here that you DO NOT need to restart DCS if you stop and restart the com port .cmd files. It'll be OK even if you're running a mission.

You have to start the arduino connection software manually. It's easier to do this before DCS, but only because it's easier to open the folder to access the files. I suppose you could write a script to start both automatically, but that's not the way it's originally set up.

It's a mess at the moment. I've managed to get something kind of working, but it's not great. The Flightpanels fork devs have been discussing options.

Mine's plugged into a USB on the mobo.

I have one. Works well for 2 MFCDs. I have a third but not hooked it up yet.

Something like this? https://www.amazon.co.uk/dp/B09BJWGPXR/

OK. That's the "Hub" version that hasn't been updated for years. You'll need to switch to the "Flightpanels fork " version, which despite having a lower version number, is newer and is actively maintained. There's an installation guide here:

Which version of DCS-BIOS are you using?

That's the "Hub" version. I'm not sure it will work anymore. It hasn't been supported for years. There's an actively-maintained version that was "forked" off an earlier version of the original for use with the Saitek Flight Panels hardware. However, it also has the Arduino library, so it works the same as far as Arduinos are concerned. Plus being actively updated, it has all the more recent aircraft additions. Despite the Flightpanels Fork DCS-BIOS version number being v0.7.48, it is far more up to date than v0.10.0 Starting the connection is harder, though, as it doesn't have the fancy interface Hub has. Your code SHOULD work as-is in the Flightpanels Fork, and I'd suggest uninstalling the Hub version and installing the Flightpanels version. There's a good video for Flightpanels version installation here:

Your LED code looks correct (address and bit mask match). Which version of DCS-BIOS are you using?

Any reason why this isnt in the Home Cockpits forum?

This line works perfectly for me. Tested with Uno and on-off-on switch on pins 4 and 5.

Can you try these with appropriate switch-reading code: SendDcsBiosMessage ("ANT_IFF, "0"); SendDcsBiosMessage ("ANT_IFF, "1"); // Middle position SendDcsBiosMessage ("ANT_IFF, "2"); DON'T put them in the code just like that - add something to choose which to send. They should be what the 3-position switch code sends depending on switch position.

This is the latest one, I think:

Maybe this thread can help: https://arduino.stackexchange.com/questions/57696/how-do-i-make-a-stepper-motor-compass-cross-360-to-0

I think what you're missing is called "zero crossing" code. It needs to work out that going from 359 to 0, or 0 to 359, has to go the short way, or that 360 = 0 or -1 = 359.

It's also REALLY handy if you lose an MFD to damage and want to transfer functions to the other. e.g. DSMS on the right MFCD after losing the left.

There's no separate DCS-BIOS control ref for them. The same code should work for both unless it's WRT one of the differences between the two.

Sketches? If it's DCS-BIOS, are you using the Flightpanels fork?

No. It's relative to the file making the call. I don't remember the syntax, but I think part of it means "go up x directory levels from here".

IIRC, the ".." refers to the relative directory structure location. It's used so that path names aren't broken by installing in nonstandard folder locations.

I thought the DCS monitor config calls them all the same name if they're in the same position. If it doesn't, I'd imagine just telling it to use the same screen position for the different aircraft MFDs would ignore the ones not being supplied.

Please file a bug report on the Fork github so this can be fixed in the documentation.

If they're all powered hubs, plug the power supplies into one multi-way extension and turn that on and off as required.