No1sonuk

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.

Take a look here:

No. As I said in your oxy switch thread, I tried A-10C and A-10CII. Both worked perfectly as expected. The control reference is the same for both.

This is in mine, from Line 1042: -- TEST MASK position is spring-loaded elements["PTR-OXYGENCP-EMERGENCY"] = default_button_tumb(_("Oxygen Flow Emergency/Normal/Test Mask"), devices.OXYGEN_SYSTEM, device_commands.Button_4, device_commands.Button_3, 601) elements["PTR-OXYGENCP-EMERGENCY"].sound = {{SOUND_SW1_OFF, SOUND_SW1}, {SOUND_SW1}} elements["PTR-OXYGENCP-OXYGEN-DILUTER"] = default_2_position_tumb(_("Oxygen Normal/100%"), devices.OXYGEN_SYSTEM, device_commands.Button_2, 602) elements["PTR-OXYGENCP-SUPPLY"] = default_2_position_tumb(_("Oxygen Supply On/Off"), devices.OXYGEN_SYSTEM, device_commands.Button_1, 603) What COULD be the difference is I'm running the Open Beta version. And both the A-10C and A-10CII are spring-loaded in the test position. Both respond properly to this: DcsBios::Switch3Pos oxyEmergency("OXY_EMERGENCY", 2, 3);

I can't check mine until I get home from work.

Mine's a fairly new install, and I don't tweak stock luas.

Try that with the 3-position (2 pins) code. Grounding a pin should move the switch to each side, with it in the middle when no pin is connected. BTW, I tested on the A10CII. Not sure if I can select the older A10C.

No problems for me. I used: const byte oxyEmergencyPins[3] = {2, 3, 4}; DcsBios::SwitchMultiPos oxyEmergency("OXY_EMERGENCY", oxyEmergencyPins, 3); I only have a SPDT ON-ON switch that I connected first with NO to 2 and NC to 3, then common to gnd. That switched between centre and aft. Then I swapped 2 and 4 in the pin list, and the same switch changed between centre and fwd. In this way, I confirmed the control itself works in all three positions. If yours doesn't, it must be a fault with your code or wiring. This also works with a 3-position SPDT ON-OFF-ON switch: DcsBios::Switch3Pos oxyEmergency("OXY_EMERGENCY", 2, 3);

Do you have any small capacitors? Could try putting one across the two pins. Also, email the company. They might have some ideas.

Could it be because your using the 1305 library, not the 1306 one? Try this: #define DCSBIOS_IRQ_SERIAL #include <DcsBios.h> #include <SPI.h> #include <Wire.h> #include <Adafruit_GFX.h> #include <Adafruit_SSD1306.h> #include "Fonts/FreeSans18pt7b.h" #define SCREEN_WIDTH 128 // OLED display width, in pixels #define SCREEN_HEIGHT 32 // OLED display height, in pixels // Declaration for an SSD1306 display connected to I2C (SDA, SCL pins) // The pins for I2C are defined by the Wire-library. // On an arduino UNO: A4(SDA), A5(SCL) // On an arduino MEGA 2560: 20(SDA), 21(SCL) // On an arduino LEONARDO: 2(SDA), 3(SCL), ... #define OLED_RESET -1 // Reset pin # (or -1 if sharing Arduino reset pin) #define SCREEN_ADDRESS 0x3C ///< See datasheet for Address; 0x3D for 128x64, 0x3C for 128x32 Adafruit_SSD1306 display(SCREEN_WIDTH, SCREEN_HEIGHT, &Wire, OLED_RESET); char* ILSkhz = "00"; // Set a "blank" frequency to display at startup char* ILSmhz = "000"; DcsBios::RotaryEncoder ilsKhz("ILS_KHZ", "DEC", "INC", 18, 19); DcsBios::RotaryEncoder ilsVol("ILS_VOL", "-3200", "+3200", 16, 17); DcsBios::RotaryEncoder ilsMhz("ILS_MHZ", "DEC", "INC", 15, 14); void setup() { display.begin(0x3C); display.setFont(&FreeSans18pt7b); delay(1000); DcsBios::setup(); ILSdisplay(); // Call the display routine to show the blank frequency at startup } void loop() { DcsBios::loop(); } void ILSdisplay(){ // ILS display driver display.clearDisplay(); // clears the screen and buffer display.setTextColor(WHITE); display.setCursor(8, 27); display.print(ILSmhz); display.setCursor(66, 27); display.print("."); display.setCursor(75, 27); display.print(ILSkhz); display.display(); } void onIlsMhzChange(char* newValue) { ILSmhz = newValue; // Set the ILSmhz variable ILSdisplay(); // Call the display driver } DcsBios::StringBuffer<3> ilsMhzStrBuffer(0x116e, onIlsMhzChange); void onIlsKhzChange(char* newValue) { ILSkhz = newValue; // Set the ILSkhz variable ILSdisplay(); // Call the display driver } DcsBios::StringBuffer<2> ilsKhzStrBuffer(0x1172, onIlsKhzChange); You'll need to adjust the screen height information at the start, and may need to install the 1306 library. What I did was remove the display driver from the loop - there's no need to run it every loop, and it was causing issues. The display also updates the whole thing at once using variables to hold the frequency values. This makes clearing the screen easier, and doesn't use a massive overhead as it's only changed when the pilot changes the frequency. So now, the two onchange routines update the frequency variables, then call the display driver. The display driver clears the screen, then rewrites the whole display. I tested it with a 128 x 32 OLED on a cold and dark A-10CII mission.

How about store the old values and print them in black before printing the new ones in white? And should you do the "display.setFont" only once in the setup? Maybe doing it every time is messing something up.

Starts the application without starting a new window. The multi-com file starts the single com file for every listed port, but the /b flag means it does it in the same window.

The BU0836A needs diodes for its matrix. If you buy the matrix breakout board, it has the diodes built in.

On my system it's here: D:\Eagle Dynamics\DCS World OpenBeta\Doc\Sounds

Just ran a test using code byteman posted on Discord with a Mega and single BCD switch. Both Mode 1 wheels work perfectly as written. None of the Mode 3 wheels work at all as written. Pins 54+ are A0+ and don't work reliably for the Mode 1 wheels. I rigged them all to repsond to pins 25, 26, and 27 at the same time. Both Mode 1 wheels responded as expected. None of the Mode 3 wheels moved at all. So my conclusions are: 1) There appears to be a fault with the Mode 3 wheels in DCS-BIOS (or DCS itself) EDIT: There was a code error: The 4 code lines said "IFF_MODE3a_WHEEL1", etc. but should be "IFF_MODE3A_WHEEL1", etc... 2) The analogue pins might not be reliable for digital input.

Limiting movement of the type with an "operating crown" should be relative easy, but the pushbutton types would be harder. I'll have a look when mine come later.

LOL. I think it should be this: // TEST For "Profile switch" currently set to read BCD switch // once during setup; move code as noted below for repeated reads // BCD Switch inputs attached to pins D4-7, common to Ground // (use internal pullups) // Define data bit pins int profile_BIT1 = 4; int profile_BIT2 = 5; int profile_BIT4 = 6; int profile_BIT8 = 7; // Define profile variable, set to 0 int profile = 0; void setup() { // initialize serial communication at 9600 bits per second (only needed // for debugging: Serial.begin(9600); // make the profile switch's pins inputs, with internal pullups on: pinMode(profile_BIT1, INPUT_PULLUP); pinMode(profile_BIT2, INPUT_PULLUP); pinMode(profile_BIT4, INPUT_PULLUP); pinMode(profile_BIT8, INPUT_PULLUP); } void loop() { // read the input pins: NOTE - CLOSED switch (binary 1) returns "0" int val_profile_BIT1 = digitalRead(profile_BIT1); int val_profile_BIT2 = digitalRead(profile_BIT2); int val_profile_BIT4 = digitalRead(profile_BIT4); int val_profile_BIT8 = digitalRead(profile_BIT8); profile = 0; needed in loop to reset to 0 for each pass // turn bit values into single profile value by adding decimal value // of each bit to profile variable if ( val_profile_BIT1 == 0) { profile = profile + 1; } if ( val_profile_BIT2 == 0) { profile = profile + 2; } if ( val_profile_BIT4 == 0) { profile = profile + 4; } if ( val_profile_BIT8 == 0) { profile = profile + 8; } // DEBUG - prints out the state of the switch bits and profile value {Serial.print("[profile_BIT1: "); Serial.print(val_profile_BIT1); Serial.print("] "); Serial.print("[profile_BIT2: "); Serial.print(val_profile_BIT2); Serial.print("] "); Serial.print("[profile_BIT4: "); Serial.print(val_profile_BIT4); Serial.print("] "); Serial.print("[profile_BIT8: "); Serial.print(val_profile_BIT8); Serial.print("] "); Serial.print("[profile: "); Serial.print(profile); Serial.println("] ");} // delay in between reads for stability, uncomment if in loop delay(1000); }

Did you notice this part? It's why you have to reset the device every time. // to make read on each pass move all below this to "loop", // uncomment profile reset

I think there's an error in that instructibles code. I think the line: int readSwitch() Should be: void readSwitch()