News New output possibilities for DCS

...the calculations are simple. But you need good motors!

Brilliant! That was the construction configuration I was looking at after seeing the F-18 construction. However the roll assembly would be unbolted from the base pitch assembly as a joystick or yoke. With high speed Teensy's, roboclaws, cogless motors and a 3D printer, the mechanics are not the issue. It is getting at the Force Feedback interface.

@Zed If the mechanics coding is reliable then I feel that may be the "source" for the model draw arguments. Again, it is what-ever works. For the lua I would be trying to minimise testing of the modules to set values before the main calculation and output code.

If prop then
Do prop code...
elseif jet then
Do jet code...
elseif helo then
Do helo code...
end
Rest of code...

I have zero experience with Dash as I only have the DIY version.

@BrassEm & @Dirty - Actually, on the Arduino side, you don't even have to get an Internet shield - depending on how you are doing things. My wind Arduino is just USB interface with a USB cable. For me, I have a USB hub on my bottom frame that drives my JRKs and the Arduino Uno doing PWM for the wind as well as serves as the link for USB controls like wheel, stick, and pedals.

It's whatever works, though. If you guys are using network interfaces for your rigs, then that's probably easier. I don't have experience with those in a sim environment.

@BrassEm - I've been going through planes all day today mapping the draw values to functions to get the ones I wanted. It's actually been interesting to see how ED grouped the various functions and also how they don't all have the same ranges. Interesting plane to plane differences. I don't think it matters for some of them but the differences may make it tougher to group by prop/jet/helo. It is looking to me like your original design of branching based on aircraft model may be the easier route but I need to look more at the controls.

I've looked through the data structures like Mech and Engine and they give some (like canopy and RPM) but don't give others. At a minimum mine will probably be a mix like what you and Dirty were doing - I think. I need to be able to test to know. I can send the wind values to the Tuning Center in the Extra1 and Extra2 variables, and ultimately that may be the better way to even talk to my wind Arduino, but I don't know that I can format the messages the way I need. Lots I still don't know here.

I was looking for indicated airspeed, RPM, prop pitch, slip indication (I'm going to modify the Arduino fan code to accept S codes like before, but also R and L codes for right and left (since S for starboard is already taken) and use the slip indicator to do differential wind), and also allow for canopy holes. But there is a lot of variability from plane to plane on what features and what value ranges.

Here's what I got so far today. All that's holding me up for testing is figuring out how to send data to Game Dash since that's how my system is configured.

Edit - added F18C. Unfortunately engine RPM doesn't seem to be available as a draw value. There's a couple of other gauges that might be close but I don't know how well that would work. Not sure what their behavior is with RPM. What I was hoping was that even with a jet like the F-18 or A-10 that an engine spooling up on one side could generate a little wind while the canopy is open. But at low speeds with the canopy open, if the slip indicator works like I think, swing the nose in a turn while taxiing and you get a little side wind.

Code:

Numeric range -1=-1.000, 0=0.000, 1=1.000
0's are low value or closed
1's are high value or open

cockpit_f-18c.edm

 Fan RPM Left        Engine RPM doesn't seem to be
 Fan RPM Right        available as a draw value
 Core RPM Left
 Core RPM Right
181 Canopy Position    0-0.909 0.924-1 = gone <0 = gone
207 Slip Indicator Ball    -1-1
217 Indicated Airspeed    0-1


cockpit_p-51d-25/30-na.edm, tf-51d.edm

11 Indicated Airspeed    0-1
23 RPM            0-1
28 Slip Indicator Ball    -1-1
46 Prop Pitch        0-1
162 Canopy Position    0-1
163 Canopy Jettison    1 = gone
413 Windscreen Holes    0-0.076 Intact
            0.106-0.788 Med Hole on Left
            0.803-1 Big Hole Right & Med Left


A-10c-2019-cpt.edm

7 Canopy Position    0-0.909 0.924-1 = gone <0 = gone
24 Slip Indicator Ball    -1-1
48 Indicated Airspeed    0-1
76 Fan RPM Left        0-1
77 Fan RPM Right    0-1
78 Core RPM Left    0-1
80 Core RPM Right    0-1


cockpit_bf-109k-4.edm

2 Indicated Airspeed    0-1
6 Slip Indicator Ball    -1-1
29 RPM            0-1
30 Prop Pitch        0-1
95 Canopy Position    0-1 1 = gone

Prop pitch on the 109 is complicated - hour and minute hand. Low pitch is 4:30, high pitch is 12:30, so it wraps around. 30 is hour hand.

i-16_cockpit.edm

4 RPM            0-1
5 Indicated Airspeed    0-1
18 Slip Indicator Ball    -1-1
42 Prop Pitch        0-1
67 Left Door        0-1
68 Right Door        0-1


cockpit_spitfire_lfmkix.edm

21 Indicated Airspeed    0.000-0.500
33 Slip Indicator    -1-1
37 RPM            0.000-0.500
126 Throttle        0-1
129 Prop Pitch        0-1
138 Canopy Position    0-1 <0 = gone
151 Left Door        0-1

Damn, you have been busy there Zed! Thank you for sharing you hard work there.

Common draw values are all over the shop so there will need to be individual customisations for each aircraft. It is unfortunate that there is no flag for generic aircraft type but it is what it is. Interesting that the A-10C high end values have the canopy missing. (Canopy jettison range?) 0 to -1 draw values usually make the object disappear (damage modelling values?).

I agree with your strategy to send data value packets to the arduino and let it do the final calculations. (Any hand-off with computer processing from the main program is valuable.) How Dash works is still a mystery to me.

Keep up the good work.

Yeah, it’s weird there is so much difference between planes. I don’t know what value is used for a missing canopy in practice but there’s code here to log values to a file. And it doesnt have to be perfect. If it misses a canopy jettison, that can be fixed.

But I’m stuck until I can output to Game Dash. I’d need to rework the communications to use Extra values I think.

Are you running wind now direct from Sim Tools since you don’t have Game Dash?

I wasn’t going to have the Arduino do anything other than what it does now, though. To make it smart would mean sending it more stuff to work with. All I was planning to do was split right and left channels and do the math in the .lua so when you slip or crab you feel the different wind angle to see if that’s worthwhile.

But again, dead in the water. I wrote to value1 with questions so am waiting. All I need to do is know how to send data to Game Dash. He wrote the P3D plugin and it sends data to Game Dash but I haven’t found how he does that.

Thanks @noorbeast. That's all I'm missing is how to get telemetry from the Export.lua into Game Dash.

As part of this craziness, if I was going to drive the right and left fans differently, I would need Arduino code to interpret the new data so I rewrote some bits of the Arduino wind code I've been using to allow for S commands as before, but also R and L for right and left motors. Current Game Dash commands are Sxxx for 0-255. I added Rxxx and Lxxx.

Game Dash Interface - Output commands work just as before when using S<Dash1> (or whatever dash panel) but it now supports L<Dash1> and R<Dash2> to control the motors individually. To duplicate S<Dash1> functionality but using the R and L commands, it's just L<Dash1>R<Dash1> What I want to do is L<Dash1>R<Dash2> to have the right and left wind values that the Export.lua calculates individually using slip indicator, RPM, etc. Generally the same but not necessarily or always.

I had noticed I had to send commands multiple times sometimes in the Arduino monitor to get them to "take" when trying things manually so also added input error checking and input routine resetting if it gets a command that isn't valid. Not sure what the issue was but for me this code works first time every time now.

A few things to note - all credit for original code to the original authors and definitely thanks for paving the way! (Edit - the code block is now a cleaned-up and trimmed down version.) I took out CalcPWM entirely since it was mapping a value to 0-255 that was already truncated to 0-255. Also, I'm using a slow PWM mode of 1 for the TerraBloom fans and how I am controlling them. YMMV.

If anyone tries it, please let me know if it does or doesn't work for you. It's working great for me. Now all I need is the ability to send right and left "windiness" values to Game Dash.

Code:

#define FALSE 0
#define TRUE 1

#define BRAKEVCC 0
#define CW   1
#define CCW  2
#define BRAKEGND 3
#define CS_THRESHOLD 100

#define BOTH 0
#define LEFT 1
#define RIGHT 2

int inApin[2] = {7, 4};  // INA: Clockwise output
int inBpin[2] = {8, 9}; // INB: Counter-clockwise output
int pwmpin[2] = {5, 6}; // PWM output
int cspin[2] = {2, 3}; // CS: Current sense ANALOG input
int enpin[2] = {0, 1}; // EN: Status of switches output (Analog pin)
int statpin = 13;

// pwmMode - sets the PWM frequency, valid options as follows:
// pwmMode = 0 will use 980Hz PWM, default mode which will work with all fan types, will cause coil whine if using a MM.
// pwmMode = 1 will use 4kHz PWM, might reduce coil whine for blowers, use heatsinks on the MM - check MM temp at a low fan speed.
// pwmMode = 2 will use 8kHz PWM, might be OK for blowers with active cooling on the MM - check MM temp at a low fan speed.
// pwmMode = 3 will use 31kHz PWM, use with caution - not for blowers with MM as it will cause very high temps. Check MM temp at a low fan speed.
// server fans - should be able to use pwmMode = 2 or 3.  If you are using the PWM control on the server fan, leave this at default 0.
// if you have blowers with a monster moto, try pwmMode = 1 or 2 and check whether your monster moto temp at low speeds.
int pwmMode = 1;        // value of 0, 1, 2 or 3 - modes 2 and 3 will overheat a Monster Moto if used with blowers

int Speed = 0;
int bufferArray[4];
int whichFan = BOTH;

void setup()
{
   Serial.begin(9600);
   // initialize digital pins as outputs
   for (int i=0; i<2; i++)
   {
     pinMode(inApin[i], OUTPUT);
     pinMode(inBpin[i], OUTPUT);
     pinMode(pwmpin[i], OUTPUT);
     digitalWrite(inApin[i], LOW);
     digitalWrite(inBpin[i], LOW);
   }
   // disable timer0's interrupt handler - this will disable Arduino's time keeping functions such as delay()
   TIMSK0 &= B11111110;
   if (pwmMode == 1)
   {
     // Set pins 5 & 6 to Phase-correct PWM of 3.9 kHz (prescale factor of 8)
     TCCR0A = _BV(COM0A1) | _BV(COM0B1) | _BV(WGM00); // phase-correct PWM
     TCCR0B = _BV(CS01);  // prescaler of 8, gives frequency 61kHz/8/2 = 3.9kHz
   }
   else if (pwmMode == 2)
   {
     // Set pins 5 & 6 to Fast PWM of 7.8 kHz (prescale factor of 8)
     TCCR0A = _BV(COM0A1) | _BV(COM0B1) | _BV(WGM01) | _BV(WGM00); // fast PWM
     TCCR0B = _BV(CS01);  // prescaler of 8, gives frequency 61kHz/8 = 7.8kHz
   }
   else if (pwmMode == 3)
   {
     // Set pins 5 & 6 to Phase-correct PWM of 31.25 kHz (prescale factor of 1)
     TCCR0A = _BV(COM0A1) | _BV(COM0B1) | _BV(WGM00); // phase-correct PWM
     TCCR0B = _BV(CS00); // prescaler of 1, gives frequency 61kHz/1/2 = 31.25kHz
   }
   else
   {
     // Set pins 5 & 6 to Fast PWM of 980Hz (prescale factor of 64)
     TCCR0A = _BV(COM0A1) | _BV(COM0B1) | _BV(WGM01) | _BV(WGM00); // fast PWM
     TCCR0B = _BV(CS01) | _BV(CS00);  // prescaler of 64, gives frequency 61kHz/64 = 980Hz
   }
}

void loop(){
ReadData();
if (whichFan == BOTH){
  motorGo(0, CW, Speed);      //Motor1
  motorGo(1, CW, Speed);      //Motor2
  if (Speed == 0) motorOff(0);
  if (Speed == 0) motorOff(1);
  }
if (whichFan == LEFT){
  motorGo(0, CW, Speed);      //Motor1
  if (Speed == 0) motorOff(0);
  }
if (whichFan == RIGHT){
  motorGo(1, CW, Speed);      //Motor2
  if (Speed == 0) motorOff(1);
  }
}

void motorOff(int motor){
// Initialize braked
for (int i=0; i<2; i++){
  digitalWrite(inApin[i], LOW);
  digitalWrite(inBpin[i], LOW);
  }
analogWrite(pwmpin[motor], Speed);
}

void motorGo(uint8_t motor, uint8_t direct, uint8_t Speed){
if (motor <= 1){
  if (direct <=4){
   // Set inA[motor]
   if (direct <=1)
     digitalWrite(inApin[motor], HIGH);
   else
     digitalWrite(inApin[motor], LOW);
   analogWrite(pwmpin[motor], Speed);
   // Set inB[motor]
   if ((direct==0)||(direct==2))
     digitalWrite(inBpin[motor], HIGH);
   else
     digitalWrite(inBpin[motor], LOW);
   analogWrite(pwmpin[motor], Speed);
   }
  }
}

void ReadData(){
  // We need 4 characters - the command followed by three digits
  bool haveCommand = FALSE;
  bool haveStart = FALSE;

  while (haveCommand == FALSE){     // can't exit until have a full valid cddd command
                                   // where c is a valid char and ddd is a valid 3
                                   // character representation of three digits
   // Valid command always starts with an S (legacy for both fans), L (left fan), or R (right fan)
   while (haveStart == FALSE){
     while (Serial.available() == 0); // spin and wait for data
     bufferArray[0] = Serial.read(); // have data, read it
  
     if (bufferArray[0] == 'S'){  //S
       whichFan = BOTH;
       haveStart = TRUE;
     }
     else if (bufferArray[0] == 'L'){   //L
       whichFan = LEFT;
       haveStart = TRUE;
     }
     else if (bufferArray[0] == 'R'){   //R
       whichFan = RIGHT;
       haveStart = TRUE;
     }
   }
   // Now need the numbers - will just read three and throw them away if any don't qualify
   // if we unsynchronize, it will fail valid digits and go back to waiting for command char
 
   for (int i = 1; i < 4; i++){       // read and label each byte.
     while (Serial.available() == 0); // spin and wait for each character to arrive
     bufferArray[i] = Serial.read();  // store as they come in
   }
 
   // Check the numbers for validity
   if (isDigit(bufferArray[1]) && isDigit(bufferArray[2]) && isDigit(bufferArray[3])){
     // all are numbers - have a full cddd command
     haveCommand = TRUE;   // otherwise start over looking for a new and valid command
   }
  }
  // Now turn that into a number and clip to 255 - rely on Game Dash for proper scaling
  Speed = ((bufferArray[1]-48)*100) + ((bufferArray[2]-48)*10) + ((bufferArray[3]-48)*1);
  //Serial.println(SpeedGameDash);
  if (Speed > 255){
   Speed = 255;
  }
}

As an aside, now that I’m running wind with the TerraBloom fans, I can hear more of the sim sounds because my wind sound is so much lower. In DCS, I just turn the fans on with S020 and that is barely even audible - but very comfortable.

Anyway, now I can hear the turbine and wind noise in the F-18. It sounds exactly like the SeaFlo fans used to. I mean exactly. It was startling at first because I thought my wind was ramping up with aircraft speed but it wasn’t. Game Dash wasn’t even running. Took a moment to realize it was DCS and the F-18’s own sound effects.

Pretty funny.

Hey guys. @BrassEm just brought something very problematic for aircraft carrier ops to my attention. https://forums.eagle.ru/showthread.php?p=4194815#post4194815

Here is part of my reply, for you folks to maybe take a look at?

BrassEm, What is the 2nd image you posted there? The statement you made about boat pitch and roll being noisy makes me think that this graph is the Carrier motion.

If so, we may be able to toggle over to that telemetry via LUA when the aircraft telemetry cuts out. This is FAR from ideal but would be better than a complete loss of motion. Assuming you move slowly on the deck I'd think that really the only thing significant that would be missing is cues for using the brakes. I imagine shakers will be offline as well but still, much better than nothing, no?

I also sent a support ticket asking for a refund for the F-14 and the Super Carrier/F-18 combo if they do not intend to resolve this in the coming months.

The second graph is a zoom in of the very first "noisy bit" of the first graph. The extent of the waveform does look like it represents the boat pitch and roll which is to be expected. And also the TAS is at boat speed as well.

The graphs are the raw outputs from DCS. The trouble is that the "noise" is a vibration and not a smoothish sinusoidal wave. I have been working at getting the DCS aircraft to behave correctly on their sprung landing gear on dry land. By lowering the MAX/MIN values in SimTools you can get an accentuated "lurching" while taxiing around on dry land. The trouble is that the "noise" is also amplified and it is also amplified by TAS while Weight On Wheels. This noise is on all axis while on the ground. It is very bumpy with any TAS. I either filter it and loose fidelity on the deck (a dead aircraft) or put up with a very bumpy aircraft on deck only while moving slightly.

It is perplexing that the gear strut data does not reflect any of this "noise" in its output data. (Not that I see anything until the gear starts extending with lift at the very last part of take off.)

It may be possible to use some sort of low pass filter to get rid of the "noise" and reveal the true pitch and roll, but I have not had a chance to look into this yet. (Nice idea about using the boat pitch and roll too, something to consider.)

Also ED are moving over to a newer (better?) simulation engine so hopefully this anomily will be addressed with its new capabilities? Guess I will be flying MARINES and IAF for the mean time.

Ooh, I didn't think about that. Don't know if that update will affect the carrier problem but maybe.

I'd be very interested to learn how exactly the "fix" for the aircraft sliding on the carrier deck was done, as losing telemetry during that time is a really bizarre side effect if you think about it.

It certainly makes no sense to me, and I don't like things that don't make sense! I'm not arguing that they are wrong mind you, but I want to understand the connection. :/

I would guess that once the hook is up they are switching to a local physics grid, and that the telemetry for what's going on inside that local physics grid is sorta in a container in a different location from where it normally is, and not being forwarded. I'm making most of that up though, from vague concepts I've read about in the past.

In the unlikely event that I understand it correctly, it seems like it should not be a big deal for ED to just forward the telemetry from there to the usual output. ¯\_(ツ)_/¯

Another possible explanation for the carrier thing just occurred to me. I suppose it's possible that once the aircraft is on the deck they're turning off the complex physics simulation and operating the aircraft just like a video game might operate a car.

Once again, I'm just making stuff up. This idea has even less merit than the first. =P

One way or another we need to fix this! I asked ED to either confirm that they intend to fix this within a few months or please refund my F-14 and SuperCarrier/F-18 purchases. I don't want the refund, I want it fixed!

I will be doing some more testing on the weekend and post a video if I can, to show the effects. If you look at videos of aircraft landing on the deck (Lots of Stingers videos over at ED video forums) it gets pretty funky sometimes so it looks like the physics engine itself is not handling the transitions too well. It could well be a limitation of the engine API which ED can't do anything about. The new VULCAN API looks more like a graphics engine rather than a physics engine?

I think that’s correct, @BrassEm.

Here’s what I’m thinking for “windiness” and differential wind... The relevant draw value variables in general range from 0 to 1 which is convenient to use them as multipliers for their wind contribution. I think we can do similar for weights to make it easier to use the same calculations for multiple aircraft as was suggested. For a P-51 the RPMWeight would be big. Something like the A-10 with engine inlets well behind would get a smaller weight.

The (1 - Airspeed) term is to dynamically decrease the RPM contribution as airspeed increases to minimize clipping and keep variability in the wind speeds. In twin engine aircraft, may want to put the engine contributions in the differential part.

VentSpeed is just an offset to keep fans running at some low value just for comfort especially in VR.

Not actual code. Just thinking through how it should work...

Canopy 0-1. // Aircraft draw values - not always 0-1
RPM 0-1
Airspeed 0-1
SlipAngle -1-1

RPMWeight 0-1
SlipWeight 0-1

VentSpeed 020 // Comfort offset

EngineFactor = RPM * RPMWeight * (1 - Airspeed) // Decrease RPM contribution at high airspeed

Wind = ((Airspeed + EngineFactor) * Canopy * 255) + VentSpeed

WindLeft = Wind - (Wind * SlipAngle * SlipWeight) // Since slip angle can be negative works both ways
WindRight = Wind + (Wind * SlipAngle * SlipWeight)