No1sonuk

Tek Creations has a sub-channel on the Skunkworks DCS-BIOS Discord: https://discord.com/channels/533342958712258572/1226210379894624357 okopanja's link indicates the panel might be totally DCS-BIOS connected. That could explain why Windows sees it as a HID (because it's an S2 board), but doesn't respond to the switches. Another thing to check is if there's a way to find out if it's old enough to be set up for Hub.

Which Arduino are you using - it's important to know that...

Which Arduino are you using, and what code? If they're connected as HID, do they work properly in the windows game controller app? If they do, check in the controls screens of DCS in case there are any other controllers, keyboard, etc. that affect the throttles.

What's the problem you're having? It should be a simple 0-5V coming from the sensor, just like a potentiometer.

One option (This one is the P-51 rockets/bombs arming switch) https://www.ebay.com/itm/WWII-Switch-Toggle-Panel-select-bombardier-Aircraft-Rare-Vintage-8905-K671-C-H-/303665840906?_ul=IL Another option I've seen is use a mini joystick with custom detents and Arduino code to interpret the analogue signals.

That's very odd. The fact that the backlight goes out indicates it might be a problem with the hub power. Try this: void setup() { DcsBios::setup(); lcd.init(); // zapnutí LCD lcd.clear(); lcd.backlight(); // zapne podsvícení LCD TRUEheading = 400; // Set to a value DCS won't produce to indicate startup condition screen0(); delay(4000); // Wait 4 seconds TRUEheading = 0; // Set to 0 screen0(); } That sets the TRUEheading variable to a number DCS won't produce so you can see if the displayed number is a result of startup. If the power is being cut, after the LCD comes back on, it should sit at 400 for 4 seconds, then reset to 0. Don't forget to wait until the display is 0 before the first connection to DCS after turning on the Arduino. If that happens, the next thing I'd try is direct connection to a USB port on the computer - maybe the hub is causing a problem. If eliminating the hub doesn't fix it, it might be the display updating that's causing the problem. Try changing the code to this: void onHdgDegChange(unsigned int newValue) { TRUEheading = newValue; // screen0(); // Disable this line for testing } That should stop the code updating the display, but leave everything else working the same. This is testing if the display updating too quickly is causing the problem (Though that problem should look different to what you showed).

Did you set it up as a HID ("joystick" buttons)? If you did, did you blank the whole column in the button AND axis controls pages in DCS before setting up the controls you want? When you add an new HID, DCS "guesses" what you want to use it for.

Can you recreate the INS switch separately? It might be you have too much on one Arduino. Try commenting out everything except the INS switch and see if it works OK. You might need to split the panels across a couple/few Arduinos.

Yes. COMPLETELY remove Hub and any DCS-BIOS. Then the installation instructions for the new version are here: https://github.com/DCS-Skunkworks/dcs-bios This is a reasonable guide to installation:

I've only just seen this - as intimated by Mr_Burns, the Home Cockpits page would have found an answer sooner. There are a few ways I can think of to configure MFD buttons-only devices for multiple modules. 1) (DCS-BIOS) Use this code block to detect the aircraft name and set a variable for your button code to read and send appropriate messages: void onAcftNameChange(char* newValue) { /* your code here */ } DcsBios::StringBuffer<24> AcftNameBuffer(MetadataStart_ACFT_NAME_A, onAcftNameChange); However, this result in a lot of code as you need to program all the messages, and if you add a new module (or even a second seat in the ones you have), you need to add all that code too. 2) (DCS-BIOS) Ignore that and just send ALL of the button press codes. DCS will ignore codes it doesn't recognise. e.g. DcsBios::Switch2Pos cpgMpdLL1("CPG_MPD_L_L1", 3); DcsBios::Switch2Pos mfdL1("MFD_L_1", 3); DcsBios::Switch2Pos fMpdLB1("F_MPD_L_B1", 3); This will send the status of pin 3 to all three DCS messages ("CPG_MPD_L_L1", "MFD_L_1", "F_MPD_L_B1"), but DCS will only obey the one relevant to the module you're flying. BUT, like #1, it'll result in a lot of code. BTW, this option is useful for some things like master caution resets. Some modules even share the same message, so you'd only need that once. 3) The one I recommend: Abandon DCS-BIOS for this unit. Make a HID (Human Interface Device). Use an Arduino that can appear to the PC as a game controller, then you use the DCS controls configuration screen to set up each module you use. This option also makes it possible to easily add another module without a massive coding effort, as well as use the device on anything else on the computer that uses game controller inputs. Generally speaking, this means you'll need an Arduino that has a 32u4 processor, like a Pro Micro or Leonardo. There may be other options, such as EPS32s, but I've never tried those. Nanos and Uno R3s can't do it, but the new Uno R4 can - the processor is different to the Uno R3 and Nano. This video includes how to rename Arduino Micro based HIDs:

As I said in the Discord, I think you're still using Hub-derived code which has errors and is out of date. I notice you have a part that says "/* KY58 Panel NOT CONNECTED WILL GO ON THE UNO V3" with a pot in it. Is the pot connected, or is the pin connected to ground? Unconnected analogue inputs will have the same value as the input read before it. Then in parts like this: const byte tempKnbPins[13] = {tempKnbPin0, tempKnbPin1, tempKnbPin2, tempKnbPin3, tempKnbPin4, tempKnbPin5, tempKnbPin6}; DcsBios::SwitchMultiPos tempKnb("TEMP_KNB", tempKnbPins, 13); You're telling the code there are 13 pins, but only giving it 7. That's going to give errors. And that particular control should be a potentiometer anyway.

Try using the "manual" connection programs (SOCAT). DCSBios bridge has some issues, and this may just be how it manifests itself on your estup.

Please post the code that's giving the problem.

Don't use digital pins 0 and 1 with Arduinos running DCS-BIOS (or any other serial comms). Those pins are used by the processor to communicate with the USB interface (and for programming the device). There is no newer version of the Hub program that is reliable. There IS a program called DCS-BIOS Bridge that has a graphical connection scheme, but it's very unreliable, and the developer left the whole DCS-BIOS project, so that is "frozen" not recommended for long-term use. You'll have to manually start the connection using the port number(s) in the connection program(s) for a reliable connection.

As mentioned in the other thread, I think you're using the outdated "Hub" version of DCS-BIOS.

Looks like Hub to me. I think you're using the outdated "Hub" version of DCS-BIOS. You'll need to remove that and use the Skunkworks fork. I don't have the link available on my phone.

The control ref I have shows: const byte hudAltSwPins[3] = {PIN_0, PIN_1, PIN_2}; DcsBios::SwitchMultiPos hudAltSw("HUD_ALT_SW", hudAltSwPins, 3); The number (3 in this case) is how many positions there should be. I looked at the others, and they're wrong in your examples as well. Where did they come from?

I'm 3 minutes into the video, and so far it looks like it's just the normal AnalogMultiPos function. I also searched the transcript for "Expanded Input Support", but didn't find it. Where did that come from?

Which video? The OP of those videos sometimes uses odd (and confusing) descriptions of things. If you can link the specific video and part of it, I can see what is meant.

Just for the sake of maybe giving you a warning: Which version of DCS-BIOS did you install? Where did you get it? There are two versions, and one hasn't been supported for years (v10.something, also called "Hub"), but people still install it and have problems later. The up-to-date one comes from here and other areas on this GitHub: https://github.com/DCS-Skunkworks/dcs-bios

I'm guessing that's why the library is 16-bit compatible.

I'm guessing the library is capable of 16-bit precision if the Arduino ADC is capable. Otherwise, it's only possible to get "16-bits" out of 10 by upscaling.

Google the FS numbers...

Which model kit code? Some of them use "real" FS codes.

BTW, the LCD connects to +5V and GND for power. SDA and SCL for I2C data. Those are on A4 (SDA) and A5 (SCL) on the Uno. If you're using a different device, check where those pins are. Some Arduinos have separated pins for SDA and SCL, but they still connect to the other I/O pins listed. e.g. my Arduino Uno has pins labelled SDA and SCL in the far corner from A4 and A5, but they're still connected there.