No1sonuk

So iconic they left out the rather large castle...

As with any network, it needs to be faster so that the speed you want can be achieved.

As more updates are done, less of the Hub version of DCS-BIOS will work because it's not being updated. Switch to the Flightpanels fork. Starting connections is "harder", but at least everything else works or gets fixed.

Something came up. I'll do it this weekend.

The fake LCD effect on the clock is nice. I just made mine black it out, rather than dark green/grey.

So why all the other fine details in the area, but omit one of the most significant buildings on the South coast?

Ironic that London is in high detail, but Dover castle is missing...

That shows Dover Castle is missing...

Servo is MUCH easier. One wire from the Arduino plus 5V power. The servo has a motor, drive electronics and feedback built in. All you need to do is put the end limit times in the code line and you're done. I'll make a demo this evening.

Good luck finding a compatible square screen. They're used to show live camera feeds of rocking horse manure being polished with unicorn hair cloths. Most people use 4:3 ratio 8-inch monitors and hide the extra height. I would suggest looking into "The Warthog Project" ( https://thewarthogproject.com/ ). He uses a single monitor for the whole instrument panel, but with switches/buttons overlaid. That solves a multitude of problems WRT things like the very complex ADI and HSI.

If you're building "compact", you should consider the Thrustmaster units. They are basically just missing the rotary off/day/night switch. And they're A LOT easier to use than building a unit yourself.

Nice. But wouldn't it have been easier (and cheaper) to use a servo?

Did you send feedback to NLR about the mods you needed to do? MFG pedals are a common thing. I'm surprised the plate wasn't compatible.

Helios Virtual Cockpit: https://github.com/HeliosVirtualCockpit It's a cockpit simulator that can be used to export gauges and display ports from DCS. One example of its use is The Warthog Project, where he uses Helios to export all the gauges, ADI, HSI, etc. from the A-10C to a single monitor he uses as the instrument panel. There's a comment about it here: https://thewarthogproject.com/software-1 The notes for the latest Helios release show the ARC-210 has been added: https://github.com/HeliosVirtualCockpit/Helios/releases/tag/1.6.6000.0

Looks like Helios has been updated: https://github.com/HeliosVirtualCockpit/Helios/releases

Considering we know what they are, is there a way to find the mfcd viewport names in the code? If so, maybe search for a similar format for the ARC-210.

I think the Flightpanels fork guys have at least some of it working, but I've not updated my DCS-BIOS since the ARC-210 was included in DCS.

1920 is correct for the second monitor. The main monitor would be 0 to 1919 (1920 pixels includes "0").

From the Flight Panels Discord: WarLord — Today at 2:42 PM i know but cant find a fix. if you open cmd / powershell and navigate to and execute it. it works. just the direct click thing doesnt work WarLord — Today at 2:47 PM open cmd/powershell navigate to the file and execute it this works as a workaround. i try to find a fix

A lot of people are flagging a problem with the multi-com port program. I don't think there's a fix yet.

From the latest I have: Altimeter_CoarsePtrBf-109K-4/ALTIMETER_COARSEPTR DcsBios::ServoOutput altimeterCoarseptr(0x424c, PIN, 544, 2400); Altimeter_FinePtrBf-109K-4/ALTIMETER_FINEPTR DcsBios::ServoOutput altimeterFineptr(0x424a, PIN, 544, 2400); Altimeter_PressureBf-109K-4/ALTIMETER_PRESSURE DcsBios::ServoOutput altimeterPressure(0x424e, PIN, 544, 2400);

That's OK then. It's common to run some devices from the 5V out of the Arduino which comes from the onboard regulator. They have limited current supply, but if you're already running everything from an external power supply, that's not an issue for you. WRT the twisted and/or shielded cable: I've not had problems with my very short test runs using jumper wires. I guess it depends on how far you need the cables to run, and how much interference there is on the lines. I will say twisting the wires will mean the interference on both wires will be the same, and because RS485 is a differential transmission system, the same interference on each wire will basically cancel out any effect it might have.

You might be able to use one of the time parameters in the common data. Something like compare the mission time after a couple of seconds and see if it has advanced or stopped - Though this could give a false reading if you pause.

Before hanging too much off the Arduino's 5Vout, make sure you're not going to overload on the current.

1: "Due" is one of the types of Arduino, like "Nano", "Uno", etc. 2: FASTLED is an Arduino library used for driving serial addressable LED strips like Neopixels and their clones. You could use a string of LEDs for backlighting and change the brightness and colour using only a coupl of IO pins. Likewise, it's theoretically possible to run an entire A-10 CWP from 2 IO pins with addressable LEDs. As for mag switch code, I wrote this just now to use SPST mag switches with hold-on. The checkSW function is written so it can be used like a DCS-BIOS function. Just feed it the DCS-BIOS label for the switch and the pin number - see code for examples: /* This code is designed to run a single-throw magnetic switch. The A-10C's Left Yaw SAS switch was used in this example as it's easy to get it operational in-game for testing. The right switch is checked too, but no hold function is tested. The way it works is very simple: If DCS thinks the switch is on, it turns on the holding coil using the LED function. If DCS thinks the switch is off, it turns off the holding coil. If the switch is moved it sends a one-off signal to DCS ONLY when its state changes. This means that DCS will ignore the actual switch position if it thinks it should be opposite. i.e. DCS will turn off a magnetic held switch if the physical switch is in the ON position, and if that switch then goes to "OFF", DCS will already be in the "OFF" condition, so it will ignore the change. Your switch should be rigged to hold only when the coil is energised. The checkSW function is written so it can be used like a DCS-BIOS function. Feed it the DCS-BIOS label for the switch and the pin number - see code for examples */ #define DCSBIOS_IRQ_SERIAL #include "DcsBios.h" #define Sw1Pin 2 #define Sw2Pin 3 #define Sw1HoldPin 13 // Output to hold coil - Use built-in LED for testing int SwStates[16]; // Array for holding pin previous states. Set the number to the highest pin number you're using /* paste code snippets from the reference documentation here */ DcsBios::LED saspYawSasL(0x1108, 0x0400, Sw1HoldPin); void setup() { DcsBios::setup(); } void loop() { DcsBios::loop(); checkSW("SASP_YAW_SAS_L", Sw1Pin); // Use the DCS-BIOS names checkSW("SASP_YAW_SAS_R", Sw2Pin); } void checkSW(const char* switchMessage, char pin){ // This is written so it can be used like a DCS-BIOS function pinMode (pin, INPUT_PULLUP); // included here to make the setup code simpler int SwPos = digitalRead(pin); // compare the switch tate to its previous state if (SwPos != SwStates[pin]) { // if the state has changed, increment the counter if (SwPos == HIGH) { // if the current state is HIGH then the switch went from on to off: sendDcsBiosMessage(switchMessage, "0"); // Always switch off if switch moved to off by player } else { // if the current state is LOW then the switch went from off to on: sendDcsBiosMessage(switchMessage, "1"); // Always switch on if switch moved to on by player } // Delay a little bit to avoid bouncing - may not be required. delay(50); } // save the current state as the last state, for next time through the loop SwStates[pin] = SwPos; } I've not tested that with an actual mag-hold switch, but the testing I could do indicates it will work as intended.