No1sonuk

Dunno. I do know I tried it on a Leonardo, which uses the 32u4, like the Pro Micro. The Due uses a different processor.

Is that after starting a mission/flight?

The good news is that Flightpanels uses a version of DCS-BIOS. Conversion requires you to install the Flightpanels version of DCS-BIOS (Which IS regularly updated), then go through your code with the new control reference and change the labels and addresses as appropriate. There may not be any changes needed with the switch side of things, but check anyway. So go here: https://github.com/DCSFlightpanels You want the DCS-BIOS block and the new Arduino library (uninstall the old one if you know how). Have a look here for the Fork setup guide: One thing to note is that the Flightpanels fork DCS-BIOS version number is 7.something, whereas the Hub version was 10.something. IIRC, this is because the Flightpanels fork was based on an older version of DCS-BIOS when it first came out. The difference is that Hub stopped being maintained years ago, while Flightpanels is actively updated regularly. There's a Discord server too, but invites are locked down. Maybe one of the Fork devs will appear soon...

You're using pins 0 and 1. That disrupts the data connection because they're the pins the Atmega328p uses to communicate with the USB controller. Try disconnecting those two switches.

The biggest benefit is from putting it on an SSD. I have 2 SSDs in my computer and DCS goes on a separate one from the OS, mainly because it's bigger.

I have them split between different drives myself. That's not the problem. It's more likely that the Hub version of DCS-BIOS doesn't work properly anymore after the many DCS updates since Hub went unmaintained. Don't forget the A-10CII just had a major update with the ARC-210 being implemented. That's likely had a knock-on effect on the rest of the code for that aircraft.

That popped up in my recommendations yesterday. Watch to the very end - there's an extra bit during the end credits.

ISTR there were problems with using a Mega as a slave?

I've tried "ED Tracker", which is a 3-axis gyro based setup, which while it doesn't have the 6-axis freedom, it's totally independent of web cams, etc. The only problem is that it's not easy to track down the data, software, etc. to get it working as it hasn't been maintained for a while. What I'm currently trying is this option which uses just a web cam and software - no IR.

If you're planning to use those on a Bodnar board, there may be no point. The board may be able to be set up specifically for rotary encoders. IIRC, there's an app that reprograms them to create up and down pulses from encoder inputs.

Two things to try: 1) Make sure the DCS-BIOS connection is using the correct com port - IIRC, hybrids somethines use a different COM port for HID and DCS-BIOS. 2) Try a new sketch with just one of the encoder lines in it to check that's working.

You don't have " DcsBios::setup(); " in your void setup function. That would stop the DCS-BIOS working. I'm not sure if that would crash the whole thing, but try changing that first. Also, on Line 52, I think the " == LOW " on the end is constantly keeping the result low and not allowing it to change.

I went looking for the Maunsell Forts in the Thames estuary. I couldn't find them at first. Then I cheated - I took an A-10CII and inputted the coordinates as waypoints. Did they do the coloured sand/rock at Alum Bay?

Check out this video:

Try it. I know some form of DCS-BIOS / HID hybrid works:

To clarify Les's post, it's the "masterModeAa" part that can't be duplicated. Those names directly before the parenthesis aren't fixed in game code, so you can change them if required. Try this instead: DcsBios::Switch2Pos masterModeAa("MASTER_MODE_AA", 13); DcsBios::LED masterModeAaLED(0x740c, 0x0800, 5); //added "LED" to the name declaration "masterModeAa" to remove the conflict with the switch

For some things, you don't need to. For simple switches, you can just us the same pin number in a different code line. e.g. DcsBios::Switch2Pos ufcMasterCaution("UFC_MASTER_CAUTION", 2); // A-10 Master Caution Reset DcsBios::Switch2Pos masterCaution("MASTER_CAUTION", 2); // F-16 Master Caution Reset DcsBios::Switch2Pos masterCautionResetSw("MASTER_CAUTION_RESET_SW", 2); // FA-18 Master Caution Reset This uses a button on pin 2, and would send all three "...MASTER_CAUTION..." messages to DCS, but DCS will only respond to the one for the aircraft you're using. If more than one aircraft uses the same message, then you don't need to add another code line. I've not tried doing that with a rotary encoder. The advantage of the HID approach is that if you get another aircraft, you don't have to recode the Arduino, you just edit the control bindings in DCS.

In DCS-BIOS, the code is (mostly) specific to just one aircraft module, meaning trying to run more than one module from the same encoder could cause conflicts in the way the arduino reads the encoder. If you go the HID (e.g. joystick) route, you only have one output, and there's no problems in the Arduino code if you add a module. You just add the binds in DCS

I just went for a drive from the Houses of Parliament in Westminster, along Whitehall to Trafalgar Square, then through Admiralty Arch and up The Mall to Buckingham Palace. So for a start, London isn't close to being that hilly. The buildings along Whitehall are not right - there's no 10 Downing Street (the Prime Minister's house) and no Cenotaph on Whitehall. Coming out of Downing Street at the St James's Park end, the aforementioned inaccurate hilliness resulted in the road being considerably higher than the park, when they should be at the same level.

You need specific code to properly compare the states of the rotary encoder inputs to determine which button to "press". Rotary encoder example: https://github.com/jssting/ButtonBox I don't think you can extract the bug data from the F-16, or any other aircraft that has an electronic HSI because there's no "physical gauge". DCS uses display driver code for that, rather than model animation, which is what DCS-BIOS picks up on with gauge position code.

That looks like it might be a problem with your computer output to the monitor. How are you connecting the second monitor to the computer?

Is there a way to make the page change buttons stay at the top of the screen when the page changes orientation?

Nice job. Especially with the limited tools. Setting the pin modes is something else I forgot. DCS-BIOS does it automatically when it's a built-in function, but the code within the onchange functions doesn't. This is because it's a normal Arduino code function. Having said that, I think there's a difference in the analogue pins.

If you try to wire two switches to one input, you'll massively complicate things. Like requiring binary step resistor networks. You'll turn a 10-position switch and a 3 position switch into a 30 posiyion switch hidden in 8192 possible combinations... A 10-position switch has 2048 possible combinations if each position could be on or off. That is significantly reduced if only one can be on at a time. Add a second switch, and the numbers go higher. HOWEVER, if you only use one switch per input, you can use linear potential dividers which are easier to decode. Check out this video, but note the comment by Kinnik Kinnick about simplifying the code with a map function:

Coupling the servo and lever with a spring doesn't preclude detecting a mismatch in the servo and lever positions. And don't limit your definition of "servo" to purely RC devices. You could easily make a suitable servo with a geared motor or even a stepper motor...