No1sonuk

No. The + side to 5V and the - to the I/O pin. In other words, move the arduino from above the LED to below it. The LED will be on if the pin is off. The other method I can think of uses the onchange code with the LED wired the normal way. Which particular LED are you thinking of?

I know you can do it in hardware. The arduinos can source or sink enough current for LEDs. See attached. For DCS-BIOS, you'd normally wire an LED as in "active high" - LED comes on when line goes high (on). BUT, if you wire it as in "active low", the LED will come on when the line goes low (off). No code change required - just assume the LED will do the opposite of the pin.

If you read a couple of posts above, you'll see he's having trouble with the MOSFET not working properly even when it's not connected to an Arduino.

Yup. Seems like the MOSFET is faulty. Though I had expected the 15 M ohms to be much lower. More like 0.5 ohms. Did you include a diode reversed across the solenoid? This kills the back-EMF generated by the coil closing down. It might have killed the MOSFET if the coil is big enough and it worked once or twice. Try getting it working using a light bulb first. There's no danger of that killing a MOSFET with a back-EMF.

Yup. To me (electronics engineer) that indicates a faulty MOSFET. Do you have a meter you can measure resistance with? With nothing connected at all, the resistances I get are: Black lead on V- (output), Red Lead on GND (12V terminals) = too high for the meter to read ("OL") on my meter. Red lead on V- (output), Black Lead on GND (12V terminals) = 8.3Mohms If either of those are significantly lower, you have a faulty MOSFET. BTW, I just tried the "disconnected from arduino signal" thing I described above on one of my modules like yours. It worked exactly as I described it should.

That's correct. Disconnect it from the arduino. Only connect the solenoid and 12V. The solenoid should be off. If that's OK: Connect the arduino GND to the MOSFET input GND, and use a 5V line from the arduino (not a signal line) to trigger the MOSFET either with a switch, or just touching the wire. If the MOSFET turns on and off when you connect and disconnect the 5V line, the MOSFET is OK. If all that works, try loading the "blink" example sketch and connect the arduino pin 13 (the LED) to the MOSFET signal input line. That should turn the MOSFET on and off with the LED.

That wouldn't give four independent outputs, though. As I understand it, each of those switches can only select between one of 12 outputs.

Without knowing exactly how the code works, it might give odd results, or not work at all, with just 3 or 4 resistors. You might have to add extra resistance at one end to fool the processor and make the 3 positions the first or last 3 of 12. It could be worth experimenting.

OK. It might be nothing to do with the code... Have you got another one of those boards? It seems to me like the MOSFET itself (the transistor) is possibly faulty. Take a look at the schematic attached. It's a very simple circuit. Your solenoid should be where the motor is shown. With 12V connected to the VIN terminal, 5V on SIG on the input side should turn on the solenoid. Removing the 5V input ( or grounding that pin like an arduino output would ) should turn off the MOSFET. How it works: The LED with 1K resistor in series gives an indication that the input is receiving a voltage. The other 1K resistor pulls the input low to turn off the MOSFET when no signal is present, but is easily overridden by a voltage on the SIG input. There's nothing in the circuit that could turn on the MOSFET without a voltage present on the SIG input. This means that if the solenoid is turned on as soon as you connect the 12V, with no input connection, you have a faulty MOSFET. And FYI, the common fault state for MOSFETs is on.

I have some of those drivers, but I've not used them yet. However, all the drawings I've seen of their use show no connection to VCC. Try removing that.

Which particular MOSFET board are you using? The first thing I'd do is eliminate DCS-BIOS as a problem. Try this: const int ThrottleStop_Solenoid = 2; //const int is for the coding only const int button = 3; // It doesn't use device memory void setup() { pinMode (ThrottleStop_Solenoid, OUTPUT); pinMode (button, INPUT_PULLUP); } void loop() { digitalWrite (ThrottleStop_Solenoid,!digitalRead(button)); digitalWrite (13,!digitalRead(button)); // Makes the built-in LED mimmick the solenoid output } That should turn on your solenoid and the arduino's built-in LED when you press a button connected from pin 3 to GND.

WRT burnout, have you considered a push/pull solenoid? This would need two drivers - one to set the latch and one to release it. In either state, the coils are off, and switching requires a brief pulse.

My first computer was a C64...

In the joystick library version on the Pro micro, don't you send a "button released" signal? When you do, also send a pulsed "off" button press.

Could you not use the Pro Micro to sense the return to centre and send the stop command automatically? Some Bodnar boards have an option for hat switch inputs.

A suggestion: Start a fresh thread in this forum (home cockpits) for this question so we can keep this announcement topic tidy and go into detail in a dedicated thread. I don't have the Ka50, so I don't know exactly which controls are used for the switches, but if you can give that info, or the DCS description of the switch, I might be able to find what you need. Also include which DCS-Bios version you're using - I know the Flightpanels version has some additional features on some aircraft that aren't available in the Hub version.

Bourns call it a "rotary position sensor". I think that's because it's a potentiometer with no end stop - it just keeps rotating. And without knowing how those wheels work (stops, etc.), it's possible that could be what the real ones use.

You CAN use the same pins in multiple DCS-BIOS code lines for different aircraft - I have tried it in a limited way. BUT you have to be careful that there are no address clashes, and the functions have to be basically the same. crash test pilot's warning about instability still applies. I only tested a couple of simple switches and lights. You shouldn't put too much in one device or it could cause issues. Check out my post here and the one following it:

A few ways to make the burst indicators: 1) "Open loop" in hardware: Use a double pole switch that uses one pole for the Arduino, and the other to switch on the LEDs. This would be easy to make 2 LEDs work with a DPDT, centre-off switch, but a bit trickier for 3 LEDs. 2) "Open loop" in software: Use a single pole switch for the Arduino and add a code routine that regularly checks the position of the switch and sets the LEDs accordingly. 3) "Closed loop" in software: If you set the control reference view to "Advanced", you'll see there's usually a set of code lines for output on controls that have only input in "Simple" view. You could use these lines to read the state of the control as DCS sees it. This would allow you to use the onscreen cockpit control, or any other bound control, and still have your LEDs work. Open loop means you set the LEDs without checking if DCS responded to the switch. Closed loop means you set the switch and read the feedback from DCS to set the LEDs. As for the laser: Is it any of these? DcsBios::LED lwrLaserRange(0x1810, 0x0010, PIN); DcsBios::LED lwrLaserTargeting(0x1810, 0x0020, PIN);

I actually can't remember. I've not tried that mission since I posted this.

Also looks like they've installed the HUB version, which might not be such a good idea, due to it not being actively updated.

You CAN use DCS BIOS with "Keypad.h" and "Joystick.h" in the same device, BUT, it has to be the right Arduino. From my experience, the "Joystick.h" libraries only work properly on Arduinos with the 32u4 processor. That's the Pro Micro and Leonardo primarily. I've actually tested it on a Leonardo. The 32u4 has USB support built into the processor, which makes it possible to use the joystick library. Other Arduinos have to use serial to USB translation devices which cause problems with the joystick library for some reason.

Thanks for looking. As I've said elsewhere, I can understand the turret geometry issues - I worked on the hanging-down style for 20 years. What I don't understand is why that would shift the SPI, as I noticed in a recent Maverick attack.

October 1963 https://www.theaviationzone.com/factsheets/c130_forrestal.asp That's a C-130, but still...

I think the Maverick imager page was SOI at the time.