98abaile

It's not possible anymore I think (at least not legitimately) and I think is now forbidden by ToS.

Install SRS anyway. Most multiplayer servers use it still and there's nothing stopping you having both and using whichever is applicable.

I know you want them from within the EU, but those LED buttons are dirt cheap from aliexpress and arrive fairly quickly.

I can't find anything below 5 euro. https://uk.rs-online.com/web/p/rotary-switches/7118394 https://uk.rs-online.com/web/p/rotary-switches/1616634 I can't imagine a project where you'd need a tone of them though.

Are you really that worried about a significant number of forum users having multiple accounts?

In the vein of knowing what you don't know, if you do use encoders with arduino code instead of DCS-BIOS, make sure you know what the interrupt pins are for your chosen board (0, 1, 2, 3, 7 for a pro micro) and make sure you keep them for encoder use only. As I said, in my experience programming encoders in arduino is a pain and I'm only just getting to grips with my own project that uses encoders, everything else works fine. Some encoders send 1 pulse per click, some send 2 pulses and some even send 4 and you have to code around them if you don't want multiple button presses with each click. But yes, general workflow is figure out all the functionality you need (including limitations like space, and what compromises you're willing to make) and lock that down first, then figure out the switch requirements, then the hardware requirements. Also don't be afraid to ask questions or for assistance.

Pretty sure the minimum for each PCB design is 5. If you want pick and place assembly, it's 2 assembled green boards or 5 in any other colour. Delivery took about 2 weeks when I used them. EDIT: Sorry, I just remembered that I used JLCPCB, but I think it's the same for PCBWAY.

Do you know if metal dome buttons are standard for real panels or is it a mix?

Always start with the design requirements, design the panel first. Decide exactly what you want to include or exclude; decide the layout and what compromises you're willing to make (you don't need true to life panels in a non true to life gaming setup), THEN decide what hardware you need. For now the coding part seems like the biggest hurdle because you've never done it before, but really once you understand it it's more tedious than hard. It's A LOT easier to change the code after the fact than it is to have to redesign and rebuild the panel though. Design the panel first. As to your stated idea, as an example, here's what I'd do: If it were me, looking at the real panel, I'd ditch the instrument brightness knob and move the fuse selector switch lower in order that everything can fit on a rectangular panel. If I didn't have one I'm working on already, I'd include a switch for the landing gear lever where the AoA dial would be. Since I play in VR exclusively, I've no need for the LED indicators, so I'd use cheaper switches with custom caps; this avoids having to buy or design/make specialised buttons and also means I can avoid having to wire or program any LEDs; this also means I wouldn't require DCS-BIOS, so I could make it a generic (albeit oddly laid out) button box. Next, because rotary encoders are a pain to code outside of DCS-BIOS, I'd need to decide if I wanted to use them for most of the knobs (making it more generically useful) or not. Assuming I wanted to keep some sense of immersion, I'd use 12 position and 8 position rotaries for the qty selector and weapon selector knobs, the AWRU knob could be a potentiometer but I'd be specifically looking for one with 270 degrees of rotation (which is most cheap ones). The delivery mode knob has a centre push but the label implies it's only for jettisoning nuclear weapons; I'd have to ask if that functionality is even in the game, because if not I could be using a 16 position rotary pined for 13 positions instead (NOTE: 16P rotaries are expensive, so in reality I'd probably use an encoder anyway, but for this example we'll assume a rotary). The only knob that would give me a headache would be the selective jettison knob. It's an 8 position rotary using 7 positions, but the issue is the need for a centre push. I've done it before on another panel with an encoder (with push), but what if I wanted to make it more realistic instead? For arguments sake, let's assume I'd found a way to use a rotary instead. With the hardware figured out, we can work out what inputs we need. We need two analogue inputs (one for the AWRU knob and one for the dimmer next to the pylon indicators). The two position switches only need 1 input (since the off state can also be coded for or just setup in game), similarly the 3 position switches only need 2 inputs. This gives 19 digital inputs plus 2 for the landing gear lever I specified earlier (I used a 3P switch in mine), so 21 digital inputs so far. Now comes the question how many digital inputs would we need for the rotaries? By my count it would require 39, giving us a total of 50 digital inputs required. With 50 digital inputs and 2 analogue inputs (and no outputs) we can now decide what controller to use. With that many digital inputs, we'd need an arduino mega (54 digital inputs available), knowing that we could now design the enclosure. This would also be the simplest to wire and program. However since I've already got experience with coding multiplexers, I could use 3X 16 channel multiplexers and reduce that pin count to 8 digital pins and 2 analogue, meaning I can now use a pro micro instead. Now let's assume I'd selected encoders for the delivery mode knob and the sel jett knob. That's 16 less inputs required and one gained for the nuclear jettison; leaving us with 35 digital inputs. The problem is that encoders don't work well if at all with multiplexers, meaning we need 4 pins wired directly to the board. So 31 inputs using 2 multiplexers and 4 directly connected inputs means I would need 10 digital pins and 2 analogue pins. If I replaced all the rotaries with encoders, I'd have 21 inputs I'd still need 2 multiplexers for and now 8 digital inputs straight from the board, which equates to 14 digital inputs and 2 analogue. If I weren't using encoders I'd need 29 digital pins, so I would need something bigger than a pro micro. EDIT: ...and then I found out 5 of those buttons were just lights. I can't be bothered to change the above text now.

I got mine installed and I like it, the new damper is amazing too. My only complains aren't to do with the grip at all, I'd like to mount the collective about 2 inches lower but there's no combination of the mounting hardware that would let me do that (I've got some aluminium spacers on the way). A point people should look out for: just because you have the new damper installed doesn't mean you can completely undo the clutches. If you slacken the clutches off fully you'll find the shaft wobbles quite noticeably. My advice would be to lube the clutches with silicon grease and then tighten them just enough to remove the side to side play.

The obvious question should be: Why are ED using turn servers rather than letting the game servers handle their own VoIP data?

Got mine today (after DPD didn't bother on both saturday and sunday despite saying they would). Lighter than I thought it would be. It's also a tight fit if you have big hands.

I would also very much like a radial menu. I don't want to fumble with keys or a mouse in VR any more than I have to, I'd rather just turn my head.

As the title says, can DCSbios actions use booleans stored in an array rather than digital pins? For example: A normal action would be: DcsBios::Switch2Pos ufcMasterCaution("UFC_MASTER_CAUTION", 10); Would I be able to instead use: DcsBios::Switch2Pos ufcMasterCaution("UFC_MASTER_CAUTION", muxArr[15]);

I got the solution from discord. The problem was that I hadn't set my muxSIG pin's internal pullups. Changing the pinmode from INPUT to INPUT_PULLUP fixed the issue. ------------------------- I'm wondering if anyone can help me with my attempt at using a multiplexers? Here's the code I have so far: #include <Arduino.h> const int muxSIG1 = 2; const int muxSIG2 = 3; const int muxS0 = 15; const int muxS1 = 14; const int muxS2 = 16; const int muxS3 = 10; int SetMuxChannel(byte channel) { digitalWrite(muxS0, bitRead(channel, 0)); digitalWrite(muxS1, bitRead(channel, 1)); digitalWrite(muxS2, bitRead(channel, 2)); digitalWrite(muxS3, bitRead(channel, 3)); } void setup() { //Joystick.begin(); pinMode(muxSIG1, INPUT); pinMode(muxSIG2, INPUT); pinMode(muxS0, OUTPUT); pinMode(muxS1, OUTPUT); pinMode(muxS2, OUTPUT); pinMode(muxS3, OUTPUT); Serial.begin(9600); delay(1000); } void loop() { for (byte i = 0; i < 15; i++) { SetMuxChannel(i); bool a = digitalRead(muxSIG1); bool b = digitalRead(muxSIG2); Serial.print("Push button at channel "); Serial.print(i); Serial.print(" is "); Serial.println(a == LOW ? "pressed" : "not pressed"); Serial.print("Push button at channel "); Serial.print(i+15); Serial.print(" is "); Serial.println(b == LOW ? "pressed" : "not pressed"); delay(1000); } Serial.println(); delay(1000); } Unfortunately all that happens is that all buttons show as constantly pressed. I know the wiring is fine since the same setup works just fine in Mobiflight and everything works as expected.