Vinc_Vega

@bojote Thanks for the reply. I've already deleted the post after another look into your GitHub and reading the ESP32 stuff. I'll give it a try with the Pi. As the ESP unfortunately has not enough memory to serve bigger screens for e.g. HSI, it's probably worth to connect other stuff. Regards, Vinc

I like your design! But isn't in reality the yaw axis controlled by the rudder pedals? If you really mean the grip's yaw, you should measure the applied torque. That's not easy but may be a calibrated and combined signal of all four strain gauges. It will be even harder to get the direction of the torque moment. Regards, Vinc

If this really will be the case, that would have been my last pre-purchased module. Regards, Vinc

@SrSosio As expected, you may have to change the declaration of bool status into int status to use the onSeatPositionChange function, even if the output would be either 0 or 1. Regards, Vinc Edit: it's a really great hack to use the dynamic sketch to even swith the function of a whole panel. Respect!

The seat function expects an integer but your status variable may still be declared as bool. I'll later have a look into the new sketch. Regards, Vinc

Not sure what the signal actually is triggered from. Just jump between the cockpits, read it out and you'll see. Regards, Vinc

No, as I don't have the AH-64 module I didn't had a look into it's code. But that sounds promising Regards, Vinc

I would try to completely replace the onAcftNameChange function with a reading of your selector switch Regards, Vinc

@SrSosio Sorry, that I misinterpreted the above postings as an output problem (I'm not a native English speaker). I now understand that you have duplicated your inputs. That's because you use the same keypress (e.g. pin 35) for pilot's and gunner's KU (here PLT_KU_2 and CPG_KU_2). Yes, "tryToSendDcsBiosMessage" is the kind of a function to directly send commands to DCS Bios. I used that a lot within the code for my VHF FM radio, to send switch positions of a port expander. Have a look into the source code of DcsBios to see that functionality: https://github.com/DCS-Skunkworks/dcs-bios-arduino-library/blob/master/src/DcsBios.h In short the arguments may be explained as follows: bool tryToSendDcsBiosMessage(const char* msg, const char* arg); char* msg can be the name of a switch, same like you have already used in your sketch (e.g. "CPG_KU_2" for key 2 of your gunner's keyboard or "PLT_KU_2" for that of the pilot). char* arg represents a value to be send to DCS Bios: for a two position switch it is either "0" or "1", or for multi position switches "0" to "max position (minus 1)". Btw. that function also can send all the other input arguments, like "INC" or "DEC" to increase or decrease values e.g. for a channel selector knob (like with the rotaries). Instead of tryToSendDcsBiosMessage you also can use sendDcsBiosMessage, but I recommend to leave it like that. So you are able to directly send switch positions to DCS Bios, like the reading for pin 35: if (digitalRead(35) == 0) DcsBios::tryToSendDcsBiosMessage("CPG_KU_2", "0"); if (digitalRead(35) == 1) DcsBios::tryToSendDcsBiosMessage("CPG_KU_2", "1"); (or the other way around if your switch is active LOW) Be carefull to use it within the LOOP section, as it than permanently sends the read values. I therefore used variables to hold the actual status and send it only in case it has changed. Have a look into my VHF FM radio sketch linked below. You may group your keyboard readings within different sections of a function. Imagine, that a key may be send either from the gunner's or the pilot's KU, depending on the position of your (status) selector switch (input A3). You may have an idea of what I mean. It's a lot of coding to be done, but on the other hand you build two separate input devices Regards, Vinc Edit: I had a further look into the DcsBios library but havn't worked with the DynamicControlMapping.ino example yet. If I understand the sketch right, it even may be adjusted to your input needs.

I can see your switch working. The possibility to input different content is by using the global variable (status 0/1) within each of the input (key) functions. You therefore cannot use the short DCS Bios statements. Edit: Read the button and than use functions for every key like DcsBios::tryToSendDcsBiosMessage("CPG_KU_2", "1"); Regards, Vinc

@SrSosio Okay, you may just declare two new variables within the header of your sketch String(CpgKuDisplay); String(PltKuDisplay); Then put the content of the DCS Bios strings into these variables and call the display to be updated void onCpgKuDisplayChange(char* newValue) { CpgKuDisplay = newValue; updateDisplay(); } DcsBios::StringBuffer<22> cpgKuDisplayBuffer(0x80ac, onCpgKuDisplayChange); void onPltKuDisplayChange(char* newValue) { PltKuDisplay = newValue; updateDisplay(); } DcsBios::StringBuffer<22> pltKuDisplayBuffer(0x808e, onPltKuDisplayChange); And lastly, use that function and dependent on the switch position print the variables to the LCD (function just simplified) void updateDisplay() { lcd.setCursor(0,0); if (status == 0) { lcd.print(CpgKuDisplay); } if (status == 1) { lcd.print(PltKuDisplay); } } That should print only one string to the display, even if both variables (strings) are updated. Regards, Vinc PS: you also may trim that strings (variables) and cut e.g. the first 8 chars before printing to the LCD.

@SrSosio Independent of the switch position, you will see no difference on the display. This code always prints an "yes" into the display if the first char of the string is a hash tag. void updateDisplay(char* newValue){ lcd.setCursor(0,0); if (newValue[0] == char(35)) lcd.print("yes"); } What if you dispose the "updateDisplay" function and put the code directly within the respective onDisplayChange parts? void onCpgKuDisplayChange(char* newValue) { if (status == 0) { if (newValue[0] == char(35)) { lcd.setCursor(0,0); lcd.print("Cpg"); } } } DcsBios::StringBuffer<22> cpgKuDisplayBuffer(0x80ac, onCpgKuDisplayChange); void onPltKuDisplayChange(char* newValue) { if (status == 1) { if (newValue[0] == char(35)) { lcd.setCursor(0,0); lcd.print("Plt"); } } } DcsBios::StringBuffer<22> pltKuDisplayBuffer(0x808e, onPltKuDisplayChange); Regards, Vinc Edit: How is it in the Simulator Cockpit? Doesn't the display ever show the same line, no matter which KU is in use? It may be intentionally, that e.g. the commander can see the pilot's input.

You may also try the plain ASCII code without the char() statement.

@SrSosio As characters are represented as signed bytes and for the hash tag the ASCII sign is 35, something like that may work for you if (newValue[0] == char(35)) Regards, Vinc

@SrSosio Can you read out some lines, e.g. by using the Bort software and copy the line content? We than my see if there are some unusual characters like a cursor or so. Regards, Vinc

@SrSosio I don't have that 1601A LCD but used other displays already in a similar way. Furthermore, I don't have the AH-64 module, so I can't verify my suggestions. But, the exported string may hold up to 22 characters, that's what the StringBuffer declaration for DCS Bios says. I think that you don't need the code to set the cursor in the second line (0, 1), because it's a single line LCD that holds maximal 16 characters (that is what 1601 stands for). The setCursor command brings you e.g from the first digit (0, 0) up to the 16th digit (15, 0), where 0 after the colon stands for the first line (and 1 would be the second line). So at first glance you are limited to print either the first or the last 16 chars (bytes). I don't know how important the last characters are and if all bytes are used in every messages. It may help if you'd provide some examples on the content of the line to be printed. To display more than the 16 characters you may produce some kind of scrolling effect, that unfortunately is not supported by the library. If you were familiar with Arduino coding, you may write a function that reads all the 22 characters from the string and that prints characters 1 to 16, clears the display and prints 2 to 17, clears the display and prints 3 to 18, and so on. Depending on your microcontroller that may waste a lot of calculation power. Or you read the string and print the first 16 chars, wait a a few seconds (do not use delay() !) and than print over the last 16 chars. So you automatically switch between the begin and the end of that string. You also may use a function that reads all characters and looks for spaces or so and than prints the line only until that byte. Regards, Vinc

@Bucic You also may use port expanders. They are available in I2C and SPI bus variants. I described an example here in that posting: Regards, Vinc

It may have the SSD1306 chip, try this library to talk to your display: https://github.com/gadjet/1602-OLED-Arduino-Library Regards, Vinc

@Aapje Thanks for sharing the info. If it's free programmable it may be used to easily control the user interface of DCS and save key commands of the HOTAS controllers, like center TrackIR or VR-Headsets. Regards, Vinc

Hi there, you may try this snippet for lc2 void onUhfFreqDispChange(char* newValue) { lc2.setChar(0,0,newValue[0],false); // digit 1 lc2.setChar(0,1,newValue[1],false); // digit 2 lc2.setChar(0,2,newValue[2],true); // digit 3 with dot lc2.setChar(0,3,newValue[4],false); // digit 4 lc2.setChar(0,4,newValue[5],false); // digit 5 lc2.setChar(0,5,newValue[6],false); // digit 6 } DcsBios::StringBuffer<7> uhfFreqDispBuffer(0x45b2, onUhfFreqDispChange); Depending on the order of your LEDs, you may swap the digits (newValue[0] to [6]). Element 4 of the string (newValue[3]) is a dot and not a number, additionally the "true" on digit 3 than may be shifted to digit 4. As the radio display code seems to be similar to that of the A-10, you also may adapt that of my OLED displays. For the F16 you use the "UHF Manual Frequency Display" and "UHF CHAN Display" code snippets. Regards, Vinc

Many thanks for your efforts. Will the Preschen air base from former East Germany be included? It was home of Fighter Squadron No 3, including two MiG-29 ant one MiG-21 wings. Thanks in advance, Regards, Vinc Edit: I found it in phase 3, thanks

You can try to keep the boot button pressed during the upload process. Regards, Vinc

Did you installed the latest ESP32 drivers? I put the following lines into File -> Preferences -> Additional board managers URLs: https://dl.espressif.com/dl/package_esp32_index.json https://espressif.github.io/arduino-esp32/package_esp32_dev_index.json https://raw.githubusercontent.com/espressif/arduino-esp32/gh-pages/package_esp32_dev_index.json https://raw.githubusercontent.com/espressif/arduino-esp32/gh-pages/package_esp32_index.json Regards, Vinc

@questerymj01 You can readout the hardware SPI ports like I posted here: Regards, Vinc

As there are a few on the market, please tell us exactly what ESP32 board do you use. Probably a link to the supplier would do it. Regards, Vinc