No1sonuk

A digital output Hall effect sensor would be treated as a switch in DCS-BIOS if you get the open-collector or open-drain types. The transistor operates as a switch, shorting the output terminal to ground when the magnetic flux density is higher than the Hall effect sensor ‘on’ point. DCS-BIOS would turn on the internal pullup resistors required for use of open-collector or open-drain outputs, so no additional compenents should be required. Be careful about the type of digital Hall effect sensor too. "There are two types of digital Hall effect sensors: bipolar and unipolar, which differ depending on the type of magnetic field needed to operate them. Bipolar digital Hall effect sensors need a positive magnetic field (which comes from the South pole of a magnet) to operate them, and use the negative field (from the North pole) to release them. Unipolar sensors only need a single magnetic South pole to both operate and release them as they move in and out of the magnetic field." You'll probaly want unipolar if you just want to detect the presence and absence of the magnet. And FYI, this one is available in surface mount form. Not recommending this over others, just the first one that popped up. https://www.ti.com/product/DRV5023#params

Which version of DCS-BIOS are you using, and what code line?

See example 2 here: https://github.com/DCS-Skunkworks/dcs-bios-arduino-library/wiki/RotaryEncoder

I'm surprised Hub works at all with the AH-64.

UK source GBP 2.39: https://www.active-robots.com/rotary-switch-10-position.html Though the datasheet indicates it's NOT 10 over 360 degrees. Looks like it might be like a 12-way is limited to 10.

Series connection would be better then if you need two LEDs - each Arduino pin is only good for 40mA max. The 200mA overall capacity is still a thing, though. That's because of the overall package power tolerance.

NP. Just making sure you weren't using the HUB version (you're not ). The latest version of DCS-BIOS Fork doesn't have the "-" character in those locations. WRT names you can't change, there are some: e.g. in input functions: DcsBios::Switch2Pos afcsAlt("AFCS_ALT", PIN); You can't change "AFCS_ALT" because that's what DCS recognises. "DcsBios::Switch2Pos" is part of the function definition, and can't be changed either. "afcsAlt" is a unique name for that instance of the Switch2Pos function, and it CAN be changed. And in LED output functions (if you have one of the recent versions of the DCS-BIOS Arduino library): DcsBios::LED extStrobeLeft(A_10C_EXT_STROBE_LEFT, PIN); "A_10C_EXT_STROBE_LEFT" is a label mapped to address and mask figures that used to be in the reference, but were changed to these names to make updating code easier. When a DCS update requires the address and mask values to change, users that have these labels in their code only need to recompile the code after updating the library files. That line looks like this in the old system: DcsBios::LED extStrobeLeft(0x11bc, 0x4000, PIN); With the new setup, "A_10C_EXT_STROBE_LEFT" is defined as "0x11bc, 0x4000" in the addresses file. If that part needs to change, the "A_10C_EXT_STROBE_LEFT" definition will be updated as part of the library update, meaning the users don't need to track down and change all the addresses and masks that were affected. As before, "DcsBios::LED" is the non-changeable function definition and "extStrobeLeft" is the changeable unique name of that instance. In case you're wondering about why you would want to change the instance name, consider if you want two pins to respond to the same light signal for some reason. This would fail to compile because the names are not unique: DcsBios::LED extStrobeLeft(A_10C_EXT_STROBE_LEFT, 2); DcsBios::LED extStrobeLeft(A_10C_EXT_STROBE_LEFT, 3); This WOULD work because the names are unique: DcsBios::LED extStrobeLeftA(A_10C_EXT_STROBE_LEFT, 2); DcsBios::LED extStrobeLeftB(A_10C_EXT_STROBE_LEFT, 3);

NP Ooh. That would help with things like the P51 ASI that has a non-linear scale on the gauge, but a linear value output from DCS.

Ah. OK. What you need to do is make the light control a separate function that uses the brightness and enable global variables, and is called every time one of them changes. Don't put the light control in the main loop - it doesn't need to run every loop, only when one of the variables changes. Try this: int StateOutR = 0; int LEDBrightness = 255; const int LEDOutR = 6; // This sets the LEDBrightness variable based on the value of PltSignalL (0-65535) void onPltSignalLChange(unsigned int newValue) { LEDBrightness = map(newValue, 0, 65535, 0, 255); lightControl(); // Call the light control because a variable changed } DcsBios::IntegerBuffer pltSignalLBuffer(0x8734, 0xffff, 0, onPltSignalLChange); //Right Out Board 'ARM' // This sets the StateOutR variable based on the value of PltJettROutboardL (0-1) void onPltJettROutboardLChange(unsigned int newValue) { StateOutR = newValue; lightControl(); // Call the light control because a variable changed } DcsBios::IntegerBuffer pltJettROutboardLBuffer(0x872a, 0x2000, 13, onPltJettROutboardLChange); void setup() { DcsBios::setup(); pinMode(LEDOutR, OUTPUT); } void loop() { DcsBios::loop(); } void lightControl() { // This controls the light based on the variable values if (StateOutR == 1) { analogWrite (LEDOutR, LEDBrightness); } else { analogWrite (LEDOutR, 0); } }

A normal Arduino can handle a maximum of about 200mA in LEDs. That's 20 LEDs at 10mA. However, that panel is using 2 LEDs per light for the rectangular ones, so if the LED forward voltage is less than 2.5V (Red LEDs are usually somewhere around 2V but check yours), it's theoretically possible to run them in series to reduce the current load on the Arduino. Basically; 10mA through two LEDs in series is 10mA total. 10mA through each of two LEDs in parallel is 20mA total.

I asked which version of DCS-BIOS you are using, not DCS. You might have an old version and need to update it to get the corrected reference.

I don't have the AH-64, so I'm not 100% sure what you need. However, this might be what you need: // Put these with your global variables int LEDBrightness = 255; const int LEDpin = 5; // Or whatever PWM-capable pin number you want // This goes with your DCS-BIOS code lines void onPltSignalLChange(unsigned int newValue) { LEDBrightness = map(newValue, 0, 65535, 0, 255); analgWrite (LEDpin, LEDBrightness); } DcsBios::IntegerBuffer pltSignalLBuffer(0x8734, 0xffff, 0, onPltSignalLChange); BTW, to insert code like that, press the <> symbol in the controls between " and the smiley.

Those are names you can define yourself. To fix the problem, just replace the - characters with underscore ( _ ) (shift and - ). And I'll go check the most recent version of the control ref. and get it changed if it's still like this. EDIT: It's correct in the latest version - Which version of DCS-BIOS are you using?

Have you considered using the parts of the code that feed back the individual dimmer control positions and using that? Though that won't turn lights off unless the dimmer value is 0.

I've used them a couple of times. Similar delivery times to the UK. The only problem I've had is when I asked them to make two different SMT boards named "Board A" and "Board B". They made Board B the wrong way round (tracks on the bottom) because they assumed the "B" meant it was the bottom layer, not the top layer.

Yes. I've done it. I used SS49E linear hall effect sensors. Direct connection: V+ to 5V, V- to GND, and Output to the Bodnar input. Basically, any linear Hall sensor with a supply range that allows 5V should work.

This: https://wiki.st.com/stm32mcu/wiki/Getting_started_with_ADC Says: Technology 12-bit successive approximation Conversion time 188 nS, 5.33 Msamples/s (when fADC_CLK = 80 MHz) That's better than the standard 10-bit ADCs of Arduinos, and on-par with Leo Bodnar analogue boards.

More likely an "opal" plastic. i.e. one that looks white, but is translucent.

Doesn't the STM32 have ADCs?

Maybe Tacview does what you want? https://www.tacview.net/product/en/ It's free to try, and some features will continue to work after the initial trial period.

Why not just use a Leo Bodnar BU0836A? It has eight 12-bit analogue channels and up to 32+4 digital button inputs. It requires no programming (unless you want to change its name or use the rotary encoder functions), and plugs straight into a USB port.

Just noticed there's no "F4" on the DCS-BIOS compatability list. It'll have to be added after release for the Uno/DCS-BIOS combination to work for it. The Pro-micro operating as a game controller would work straight away, though.

Just to make sure, you need to start with this version of DCS-BIOS, _NOT_ the "Hub" version: https://github.com/DCS-Skunkworks And this is a decent start-up video:

The first thing to think about is that the Uno and Mega can't work like game controllers over USB (also called HID or Human Interface Devices) without reprogramming the base code of the USB interface device - IF the Arduino you have has a reprogrammable interface device. If you're new to coding, I'd suggest NOT doing that. You CAN use those devices with DCS-BIOS, though. DCS-BIOS is an interface system for Arduinos and ESP32s to interface with DCS. It's aircraft-specific, though, and relies on the aircraft being included and updated by the developers (who are not employed by ED). That's generally a few days behind DCS updates. Oh, and no - you can't bolt 2 Arduinos together with a single USB out. But with a USB hub, you can use multiple Arduinos. For what you want, you might be able to use a Leo Bodnar BU0836X. This has 32 digital inputs (encoders use 2 each) and 8 analogue inputs (pots, etc.). It'll show up as a game controller in Windows and DCS with no coding, other than using the Bodnar encoder configuration program. If you still want to go the Arduino route without DCS-BIOS, a Leonardo or Pro Micro have the correct USB interface devices for use as a HID. The Leonardo is usually compatible with Uno form factor shields, and the Pro Micro is similar to a Nano, but not the same size. Firstly, you need to determine exactly how many inputs you need of each type: Encoder = 2 digital inputs each (3 including the push) Pot = 1 analogue input each Switch = 1 digital input per on position Once you have that list, you can decide which device(s) to use, and how. Hope that helps for a start. EDIT: Also, I just looked at Circuit.io - It doesn't do things the way I would. For example, it uses "active-high" switches, which need external pull-down resistors. The Arduinos have built-in pull-up resistors for "active-low" switches...

Could that be a camera perspective problem? If you have the panel and a flat bed scanner, you can get a flat image with no perspective problems.