No1sonuk

DCS-BIOS doesn't do anything with "pinky switches" and Luas.

Because the others are basically 2-character values. Freq2 is a single digit.

Does it respond properly to the in-game controls?

No. I was able to set 123.100MHz.

OK... lcd.print(newValue[0]); Will send just character 0. Note the addition of "[0]" to the variable name. Change it to 1,2,3, etc. for the other characters.

If this is for the A-10, why aren't you using the whole frequency string? I use this for my LCD radio display: void onVhfAmFrequencySChange(char* newValue) { lcd.setCursor(0,0); lcd.print("VHF AM: "); // Clear the line lcd.setCursor(8,0); lcd.print(newValue); } DcsBios::StringBuffer<7> vhfAmFrequencySBuffer(0x12de, onVhfAmFrequencySChange); That gives the whole frequency in one string, including the decimal point. It's available for all 3 radios, the ILS and the TACAN.

Maybe have a rubber tube under the existing button to give more resistance?

I actually helped someone with the KA50 radio display the other day. In that case, freq 1 and 4 are strings, 2 and 3 are integers. Maybe this will help (it's for the KA50): char* WHF2freq1 = "00"; // Display digits are mixed string and integer so separate variables are easier int WHF2freq2 = 0; int WHF2freq3 = 0; char* WHF2freq4 = "00"; void WHFR2DisplayPrint(){ tcaselect(0); display.clearDisplay(); display.setCursor(10,10); display.print (*WHF2freq1); display.print (WHF2freq2); display.print ("."); display.print (WHF2freq3); display.print (*WHF2freq4); display.display(); } void onR800Freq1Change(char* newValue) { // Freq1 change - "10" "11" "12" "13" "14" "22" "23" "24" "25" "26" "27" "28" "29" "30" "31" "32" "33" "34" "35" "36" "37" "38" "39" *WHF2freq1= (newValue); WHFR2DisplayPrint(); } DcsBios::StringBuffer<2> r800Freq1StrBuffer(0x190e, onR800Freq1Change); void onR800Freq2Change(unsigned int newValue) { // Freq2 change WHF2freq2=(newValue); WHFR2DisplayPrint(); } DcsBios::IntegerBuffer r800Freq2Buffer(0x190c, 0x3c00, 10, onR800Freq2Change); void onR800Freq3Change(unsigned int newValue) { // Freq3 change WHF2freq3=(newValue); WHFR2DisplayPrint(); } DcsBios::IntegerBuffer r800Freq3Buffer(0x1910, 0x000f, 0, onR800Freq3Change); void onR800Freq4Change(char* newValue) { // Freq4 change - possible values: "00" "25" "50" "75" *WHF2freq4=(newValue); WHFR2DisplayPrint(); } DcsBios::StringBuffer<2> r800Freq4StrBuffer(0x1912, onR800Freq4Change); I assume yours is for the A-10? If that KA50 code doesn't help, I'll have a look at the A-10 code when I get home from work.

Socat is the program that runs the USB interface with the Arduinos. If you don't know that, you might be using the out of date 'Hub" version of DCS-BIOS.

Socat does, yes.

How about something like this? LED Filament: https://thepihut.com/products/3v-260mm-flexible-led-filament-chip-green

Not sure it'll do much in a short network, but it might help.

Reset Xform just blew up the model.

If I put the model in with x left/right, it goes in game sideways.

In Max, front/back is +- X. Left/right is +- Y.

Are you sure those coordinates are Y,Z, X, and not X,Z,Y?

I'm getting nowhere with this. There's insufficient information, so I've decided to abandon the idea entirely.

The Mega2560 is used because the processor has multiple hardware serial ports. That's necessary to run as a master because it has to use one for USB and another for the RS485 bus. The 328 can't do that because it only has one hardware serial port.

If I remove all the collision features, it still sinks, but will take off and fly as it takes no damage. Also, I don't have any suspension code in the lua - neither do some other mods I've looked at.

That's generally a bus termination load. I'm not sure what the RS485 spec says about that.

It's definitely something to do with the undercarriage collapsing at about 58 to 61 knots. The sink position changes when I alter the main gear collision lines. I have no idea why, but I think it might be related to the tail wheel being sunk. I still have no idea why that's happening either.

Lol. It basically means doing serial comms manually, rather than using a UART device. You transmit by turning the output on and off with the appropriate timings, and receive by reading the port pin status.

Looks like the code library is trying to use pin definitions that don't exist. If the RS485 code is "bit-banging", it could be why your motor driving is a bit glitchy.

Looks like the DCS modding Discord has some of them too...

Hmm. Can you swap the devices? It might be the one on the right can't keep up with the input in RS485 mode because it needs to "hand-hold" the serial comms more than when running USB. I have two different "compatible" Unos that have very different latency when used for a CDU display.