No1sonuk

I updated DCS-BIOS, and now it works properly.

I updated this, and now it works: https://github.com/DCSFlightpanels/dcs-bios Delete the DCS-BIOS folder from your SCRIPTS folder in the DCS savedgames folder, then copy the new one there. Open DCS and run a mission to reconstitute the files. Close DCS, then do the connection start and and restart DCS.

You could potentially switch a Nano to a Pro Micro and run a hybrid setup.

It may not be you. Something I had working isn't anymore. I'll investigate after work tomorrow (Monday).

Tnx. I'm using one of these, so I thought it might be faster: https://www.elecrow.com/esp32-display-3-5-inch-hmi-display-spi-tft-lcd-touch-screen.html It might just be the jpeg reading/decoding from the SD card that's slow. The graphics tests run very quickly. Aaand my non-response issue may be my DCS-BIOS install - the Uno version of my sketch isn't working either. That's an investigation for tomorrow evening...

Thanks. I've managed to make it compile. Now it's just not responding to DCS. I was trying to convert my BMP-reading TFT code to the ESP32 to see if it was faster than my Uno - it doesn't appear to be, but I'll try something simpler later.

Don't know what I'm doing wrong, but I keep getting the error.

Use a Pro Micro or Leonardo in HID mode and have a switch turn on and off the eject button output in quick succession.

Thanks. Which library should I use? I don't even want to run servos on it...

Hi all, I'm having a problem with an ESP32 DCS-BIOS program that won't compile. The error is this: My code begins like this, as suggested in another post: /* The servo library has to be included before DcsBios see: https://github.com/dcs-bios/dcs-bios/issues/101 */ #include <ESP32Servo.h> #define DCSBIOS_DEFAULT_SERIAL #include "DcsBios.h" #include "SPI.h" Any ideas how to fix it?

#define DCSBIOS_IRQ_SERIAL Both should work for ATMega2650, though.

Are the working switches on the same Arduino as the LEDs you're trying? If they are, those Arduinos are correctly connected, and it must be an issue with the LED side. The next suggestion is to comment out all the switches to see if there's a conflict there. In case you didn't know, remember this: // This is a single line comment - it automatically ends at the end of the line /* This is a multi-line comment Anything between the two marks is a comment */

If you look at some of the threads to do with the CDU, you should find a link to a modified font you can insert into the gfx library.

This kind of reminds me of the "Duck tape mod" for Doom 3. The game was written is a way that you could use your gun OR your flashlight, not both. The "Duck tape mod" used the theory that a soldier would tape a flashlight to his gun...

OK, so it looks like you're only able to run 10 named switches? You say you've tried 6 BCD and 4 toggle, but have you tried any other combinations up to 10? e.g. 5 BCD and 5 toggle, 4 BCD and 6 toggle, etc.?

The problem is it WASN'T made like that from the beginning. What you also need to bear in mind is that the original intention of the Flightpanels Fork was to interface the Saitek Flight Panels. A couple of the devs there don't have Arduino experience - one only just bought a starter kit today. The address issue IS being discussed in the staff discord channel, but the radical change required to eliminate the address change problem will take time to develop. A potential "workaround" was discussed in public before it switched to the staff channel: https://discord.com/channels/533342958712258572/577071592870248448/1131602412411551795

You're basically trying to run 33 switches at once. Have you tried #define DCSBIOS_DEFAULT_SERIAL

IIRC, the addresses are auto-generated based on the DCS code. I don't know exactly how. If something is added or removed from the data stream (e.g. when the ARC-210 was added to the A-10C II), the addresses change. The Fork devs are looking at options to solve the problem, or at least make updating easier, but it's not going to be a quick process. In the mean-time, have you considered a hardware solution? e.g. running a control line from one decoder to all the required panels.

Is the CMWS display a purely text display? If it isn't, and is video, forget any kind of arduino-driven display - they're not remotely fast enough.

The name (e.g. "masterCaution") can be changed as long as it's unique in the code. My export.lua: pcall(function() local pw=require('lfs');dofile(pw.writedir()..[[Scripts\pw-dev_script\ExportInit.lua]]); end,nil); pcall(function() local dcsSr=require('lfs');dofile(dcsSr.writedir()..[[Mods\Services\DCS-SRS\Scripts\DCS-SimpleRadioStandalone.lua]]); end,nil); dofile(lfs.writedir()..[[Scripts\Helios\HeliosExport16.lua]]) dofile(lfs.writedir()..[[Scripts\DCS-BIOS\BIOS.lua]])

Well mine is latest Open Beta and latest DCS-BIOS as above. Code line: DcsBios::LED masterCaution(0x1012, 0x0800, 13); Have you checked the lamp is OK?

I did a test, and mine wasn't working until I updated this: https://github.com/DCSFlightpanels/dcs-bios Now it works again. Try that.

You said this: Your response to my question only said you CAN use a lower Ohm pot (which I'm not disputing), but your post I questioned said you NEED TO use lower. I was curious as to your justification. Which you apparently don't have... Because, if you ran the ohms law numbers yourself, you'd see that HIGHER resistance is better if you have a few pots because they run LESS CURRENT, putting less strain on the 5V supply or regulator. 10k runs at half the current of 5k (0.5mA vs 1mA @5v).

Hmm. Might need a visual reference to figure out what you want. The code maps the given input range to the full 16-bit range for DCS. If you want the in-game lever to move more than the physical one, the numbers need to have an upper limit less than 1024. I _think_ making the upper limit number more than 1024 would make the in-game lever move more than the physical one.

Maybe this? // A linear axis control where the physical or electrical range of the input does utilize the full 0 to 1023 range. DcsBios::Potentiometer clippedPotentiometerExample("MSG_0", ANALOG_PIN_A, false, 256, 768); I think the way this works is that the AtoD result 256 to 768 (the middle of the pot input range) is mapped to the whole range of the control in DCS. You change the numbers to suit your control. To get the numbers, you could write a program to read the pot and send out the A to D result to an LCD or the PC serial monitor.