bojack

@MadKreator - you might be correct, it could be the Helios patches that are making it work without anything I did in the Helios viewports having any effect. I built a new PC over Christmas so had a clean install of DCS and SimAppPro. Tested it clean and alt-F1 didn't update the UFC, then I installed Helios and made a test layout with the UFC included and when I tested again alt-F1 the UFC was updating. But it could just have been the Helios install patches that made it update

I have experienced a similar problem when using helios - I think that DCS doesn't generate the data for displays when the viewport isn't rendered, so the data can't be read by Helios or in this case the WinWing UFC. I solved the problem in my Helios layout by rendering the additional viewports for the UFC and IFEI smaller in a space outside the screen area so that the values have to be generated (even in Alt + F1). Maybe this solution will also work for the WinWing UFC? - add the code to the LUA to render the UFC outside of the screen area or make a Helios profile that does this. You can set up the DDIs this way and not need to use SimAppPro to manage the screens, which will also let you combine multiple aircraft configure into a single LUA without having to restart DCS to change aircraft. --EDIT I've just tested my theory and it works - I've attached a Helios profile that works for me There was space in the blank area above the DDI viewports to add the IFEI and UFC viewports at full scale FA18C.hpf

I don't think it works the way you are hoping it does. I had a quick look through the DCS bios source (https://github.com/DCSFlightpanels/dcs-bios-arduino-library/blob/master/src/internal/Encoders.h) The DcsBios::RotaryEncoder method is expecting the values to be passed as PIN numbers (it does the read of the pins itself) - you are passing it a zero (from your in_mat array) which it is interpreting as PIN0 - I think is shared with the serial input(?) hence the bouncing around. I can see that there is a method DcsBios::MatRotaryEncoder that accepts pointer to a value instead - I think this may be what your are looking for (though I'm not sure how you use a pointer to an array element in c++)

With those 20 pins you could create a 10x10 matrix (or something smaller) to give you 100 buttons (the A0-A7 can be used as digital pins). You would only need 100 cheep signal diodes (such as 1N4148) here is an example of the idea with code https://www.baldengineer.com/arduino-keyboard-matrix-tutorial.html) If you are a little bit creative you can get this to work with 3-way toggle switches too - the center/common pin is in the row with each output pin in a different column I've used this technique to get 128 buttons using a pro-micro and this library https://github.com/MHeironimus/ArduinoJoystickLibrary doing a read of the matrix every 50ms acts as simple debouncing (don't use delay() see https://docs.arduino.cc/built-in-examples/digital/BlinkWithoutDelay)

I have both the original Orion and the Gemini - I would say the throw was the same (My guess it is that it is the same throttle mechanism inside). I purchased it with the F18 handle and finger lift kit. My problem with the Orion in VR is that, even though it has lots of useful buttons and switches, they are not where I want them - I am forever engaging the parking break instead of the landing gear as I fumble in blind panic during a brake Using the Gemini gives me the option of building my own panel with the switches exactly where I want them to be - I am still building my panels so I haven't used the Gemini much as, but I think it will suit me. One thing worth noting is that it doesn't come with the suction feet that the Orion has and the unit weight is a lot lighter - if you do use one you will definitely have to find a solution to securely mount it (it does have the same mounting holes at the front and rear) As money is a consideration I would suggest the Orion as it is a one stop solution - the Gemini is a component in a bigger project, not a solution on its own

I think you have the wrong control - the "RWR Intensity Knob" will be the one on the front of the receiver

You might be better with natural coloured PLA filament than with clear. I have made some mock up 3D printed panels of designs that I plan to get cut in acrylic - but I found that with transparent filament it wasn't easy to see the text when the backlight was off. I had better results with natural coloured PLA which is still translucent enough to let light through, but has enough of a whiteish tint that the text is visible with no backlight - better, but still not perfect I have a cheep laser engraver (not powerful enough to cut the acrylic) and I did the spray paint black and laser etch the artwork through technique - so not exactly what you are doing

I had the same problem - the rotary control is sending fake button presses to simulate the up and down - which works for rotary controls in the sim. The problem is that the HDG and CRS switches expect click-and-hold style operation (like you would do with a mouse in the sim or a long press on the keyboard) There is a setting in SimAppPro to change the switch press delay time for rotary controls (I forget what they call it in SimAppPro and I don't have access to it where I am to check) I have to change this setting to 50ms to get the HDG and CRS to work - this does make the true rotary controls move in bigger steps (like the HMD brightness - about 15 steps from off to full brightness) but I am OK with this.

Problem with the MAX7219 is that each the LED is only on for 1/8th of the time so you are never going to get the same brightness as if you drove them directly with 5V and then putting them in series makes it worse. Do you have the brightness set all the way up in the sketch that controls the MAX7219? What @Vinc_Vega says above is normally correct, but the MAX7219 uses a resistor (Rset) to set the current it provides per LED (which saves you from having a resistor per LED). For two green LEDs in series you are looking at 4 - 4.4V voltage drop across the two LEDS which isn't in the table for Rset values provided in the data sheet - but my guess would be that 10K should be the lowest you can go (the data sheet says 9.53kΩ for 40mA), I'm not sure that driving that voltage is even supported? But your matrix looks sound - you may be able to drive it a different way?

I think it is related auto align(?) - where the elements snap together when you bring them close enough, to make it easier to create aligned rows of switches etc.

You can use an (ON)-OFF-ON switch with the momentary on the side facing down. The cover will push the switch into the momentary (ON) when closed and then when you open the cover the switch will move to the OFF. The up for ON and center for OFF work as a normal ON-OFF switch One pin on the switch tells you the cover is closed, the other tells you if the switch is active. If neither pin is activated the switch cover is open and the switch is off.

If you don't want to go with matrix you can add more digital pins to your Arduino using the MCP23017 (https://www.adafruit.com/product/732) for an extra 16 pins accessible via i2c (or the MCP23S17 spi version). You can add up to 8 of these on unique addresses for a maximum of 128 extra pins. I'm using these on some of my more complicated devices as I can keep the main loop clear for complicated things and use an interrupt to trigger the button state read only when something changes. This takes a bit more programming work though (arduino libraries are available to do most of the work for you)

The main differences I have found (other than the USB connector) are that some of the PWM capable pins are different and all the digital pins on the nano-every can have interrupts, where the standard nano only has interrupts on pins 2 and 3.