Speed trend vector

[Guest Ron Freimuth]

>I realize that this thread is somewhat old but I found>another solution. Maybe it will help someone.>While programming the HUD for the SAAB AJ37 Viggen as an>external program using FSUIPC to extract data from MSFS, I>needed the climb angle to place the horizon line. Using ground>velocity and vertical velocity was not useful as the update is>too slow and even with a filter it is unacceptable with the>resulting lag. I then realized that there is a geometric>connection between the alpha, beta, roll angle, pitch and>climb angle. These are the XML Vx, Vy, and Vz AC body velocities. Reading them sequentially and saving them in L:Variables should make them consistent enough for taking successive differences and filtering to get pretty good rates, if needed. I display some rates (filtered with 0.2 or 0.5 sec time constants) to 0.001 deg/sec and 0.01 ft/sec in a Test Gauge and in stable flight they are stable to that resolution. (A:Velocity Body X,feet per second) (>L:Vx_fps,number) (A:Velocity Body Y,feet per second) (>L:Vy_fps,number) (A:Velocity Body Z,feet per second) (>L:Vz_fps,number) I think they are also FS Token Variables. In fact, I should check to see if using 'Vx' is a better way to get 'TAS' than deriving it from 'Mach'. Which, I think is a 64K integer. Data through FSUIPC is likely to be jittery. Further, I think there is a limit as to how fast it can be read. I also found that VS/TAS was quite stable:(L:VS_fps,number) (L:Weight_lb,number) * (L:V_fps,number) 10.0 max / s2 (>L:Fvs_lb,number) "(L:Fvs_lb,number)" is the equivalent thrust relative to the flight path. I multiplied by Weight to get a force. The three L:Variables are written from XML A:Variables. In fact, 'Excess Thrust' = Fvs + Facc. Where Facc is the current accelerative force along the flight path. I take successive values of 'TAS' and filter with a 0.50 sec TC to get 'Vdot'. Vdot * Weight/32.16 = Facc. From Newton's F = ma. Facc takes two seconds to stabilize within 2% of the final value. I had to filter quite a bit, since it jitters some in dynamic condtions. The numbers sum within 1.0% after a while if rates aren't changing too fast. Sometimes my 'rates' are over 20,000 ft/min vertical, 15 ft/sec^2 along the flight path. 1/2 G pushing my virtual body against the back of the seat. I see I commented on how I calculate and filter rates well back in this thread. >So the result is that the climb angle can be calculated from>the following formula:>CLIMB_ANGLE= PITCH-(sin(ROLL_ANGLE)*BETA + cos(ROLL_ANGLE)*ALFA ) I'm stealing that formula. I had used:(L:VS_fps,number) (L:V_fps,number) 1.01 max / asin rddg (>L:Theta_c,number) (* Flight Slope *) Which appears to be correct, and simpler. Very useful for seeing the aircraft slope, -3.0 degrees is a typical descent angle. 'slope' is not 'pitch'! BTW, this is how I calculated 'Roll': (A:Plane Bank Degrees,degrees) s0 180.0 > if{ l0 360.0 - s0 } (* Fix for 0.00 to -359.999.. *) l0 /-/ (>L:Roll,number) That gives a value from -180 to + 180 degrees that is 0.0 in level flight. And, doesn't die if the power fails as "(A:Attitude Indicator Bank Degrees,degrees)" does. I noted that variable also can exhibit 'gyro drift'. Ron