No1sonuk

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()

I've got some BCD switches coming, so I'll do a proper test, but from jury-rigging using an SPST switch and jumper wires, it looks OK. Maybe you have a hardware fault?

Use a frequency above your hearing range... The only thing you can do is try it. Real aircraft AC power systems usually run at 400Hz. That gets annoying after a while! One of the phrases we use at work when people comment on how loud the airliner ovens we're fixing are is: "If you can hear that in a flight, you have bigger problems because the engines have stopped!" The upshot is that even if it does whine, you might not be able to hear it over the other noises. Or you could set the frequency at 400Hz and make it a feature.

It needs to be square to work. PWM works by turning on at full power for the whole cycle, or part of the cycle. So on full cycle = 100% brightness. On 50% of the cycle for 50% brightness. Sine waves won't do that. Whether or not it flickers is down to the frequency. If the switching frequency is in the audible range, you might hear it "whine" as well. Avoid frequencies that are exact multiples of your room lighting AC power, too. As for keeping it simple: I've not used a 555 since I learned how to program a PIC...

The components on the left provide the timing and duty cycle adjustment. I don't remember what pin 5 does. The MOSFET is required to drive the LED current. The 555 output couldn't do that itself. All the parts can be surface mount. Just keep an eye on the LED current draw and MOSFET rating. If you have a spare Arduino, you could use it with the inbuilt PWM outputs to provide software control of a few LED MOSFETs from one device.

You can run the connection program at any time, including after DCS has started. You can even run it while IN a mission - I do this regularly when debugging arduino code. My sequence is: Pause game while in mission Alt-tab to connection window Close the connection window Alt-tab to the Arduino IDE window Edit code and upload to Arduino Alt-tab to connection program folder Start connection program Alt-tab to DCS Unpause game and test Repeat as required

Yes. Sort of... Sending switch signals to multiple aircraft is easy: This code in one sketch would send the command for both F16 and F18 master caution reset switches when a button on pin 2 is pressed. DCS will ignore the one that's not used on that aircraft. DcsBios::Switch2Pos masterCaution("MASTER_CAUTION", 2); // F16 Master Caution Reset DcsBios::Switch2Pos masterCautionResetSw("MASTER_CAUTION_RESET_SW", 2); // F18 Master Caution Reset Note the pin number is the same for both, meaning it uses the same switch. If the label in quotes (e.g. "MASTER_CAUTION" ) is the same for any other aircraft, that aircraft would also respond to the same line and it doesn't need to be duplicated. e.g. DcsBios::Switch2Pos gearLever("GEAR_LEVER", 3); // F18 AND A10C DcsBios::Switch2Pos gearHandle("GEAR_HANDLE", 3); // F16 "GEAR_LEVER" is used by both F18 and A10C, so both would respond to that single line, but the F16 needs "GEAR_HANDLE". Where it gets tricky is in reading addresses for displays and LEDs, etc. because they use addresses. You can use metadata to detect the aircraft type and change the addresses appropriately, but it could greatly simplify matters if you could use a selector switch.