DummyCatz

Hi, has this bug report been recognized and acknowledged? THIS is the evidence and the video was just used to illustrate the differences.

I'd like to differ. Any 'tweaked' FCS would subject to well-recorded, extensive flight testing, and thus the allocation of time and money. A perfect example would be from https://apps.dtic.mil/dtic/tr/fulltext/u2/a307768.pdf, back in the times when a particular version of FCC software, the OFP v10.5.1, was being flight tested. What was believed to be a very simple change resulted in a serious amount of problems. Handling qualities were dangerously degraded and a lot of time and money was spent trying to fix it. It is not feasible to develop and thoroughly flight test a 'tweaked' version of FCC software just for airshow demonstrations.

I'd also like to point out the yaw rate and sideslip angle achieved in this knife edge maneuver, starting at 1:47: And a brief sideslip excursion at rolling off, starting at 4:13: With the current sideslip feedback logic of the rudder that is unique to DCS, it would be impossible that such sideslip excursions are being allowed with the excessive sideslip dampening.

As far as I can tell, this is still present with 2.9.1.

Time history of NASA FLCS control system A performing 1g stall, for example: Ref Figure 18, NASA TP-1538, https://ntrs.nasa.gov/api/citations/19800005879/downloads/19800005879.pdf

By referencing a publicly available FLCS flashcard (https://quizlet.com/309832047/flcs-flash-cards/), the yaw rate limiter is activated when AOA > 35° until AOA is reduced below 32°. A similar description can be found in the dash-1 manual (which is not quoted here), but I'm not seeing this behavior in DCS F-16. In the two tracks below, the activation AOA is 29° as indicated by the suddenly reducing aileron deflection upon crossing 29° AOA. This is an incorrect value by the F-16 version we had. Viper yaw rate limiter activation AOA - track2.trk Viper yaw rate limiter activation AOA.trk

Here's a bug in the CAT I limiter: By just performing a max effort pull to the AOA limit and reducing the throttle to IDLE, the aircraft developed an aggravating pitch oscillation by itself and eventually overshot the AOA limit and resulted in a deep stall. This dangerous behavior is not listed in the dash-1 manual. Viper AOA oscillation.trk

I'm not sure about the Su-33, but the lag filter in Su-27 is to reduce sensitivity in pitch control especially at higher speeds, as it poses a danger in pitch control over-sensitivity. The same can be said for the F-16 as there's a 'pitch prefilter' applied after the pitch 'stick command limiter', and there's also a known issue of pitch control over-sensitivity at transonic speeds in the F-16. According to Figure 3.1 in the paper "F-16 Simulator for Man-in-the-Loop Testing of Aircraft Control Systems", https://apps.dtic.mil/sti/citations/ADA189675, the pitch prefilter is a first-order low-pass filter (a.k.a lag filter so yes it creates lag), with a time constant of 1/N14. The gain N14 is variable, scheduled with dynamic pressure. With a dynamic pressure below 250 psf (~= 266KCAS), the time constant is 1/8.3 sec, which means the shaped g-command will be reaching 63.2% of the commanded g value in 1/8.3 seconds, given a step input. With a dynamic pressure greater than 400 psf (~= 585KCAS), the time constant is 1/6 sec, lowering the control sensitivity at higher speeds. This essentially shapes the desired first-order g-response of the aircraft, with no overshoots nor oscillations. This may explain both the lag and the g-onset. An illustration of first-order response given a step input: The location of pitch prefilter as shown in Figure 3.1, https://apps.dtic.mil/sti/citations/ADA189675

Update flight model for ground effect, takeoff pitch effects, auto-pilot based on FPM, touch and go handling, and other remaining flight model issues [In Progress] Hi, I've already noticed that the Flight Model and FCS has been WIP for more than 5 years. I may ask, what are the other remaining issues and has this particular bug been reported? I'm not seeing the reasoning behind the 'as stated in the road map' cuz I'm doing a bug report (regarding the rudder FCS) of an implemented feature (sideslip feedback), not a wishlist item that is not implemented (like missing logic in FCS). It's basically including all subsequent FM related bug reports into this category automatically, and it's just like saying that all the remaining issues that could possibly exist are WIP. (of course) The fix should be simple and it’s not related to the aerodynamics. Just pure control logic: Remove the sideslip feedback to the rudder, and add it to the aileron and diff-stab instead. See, it’s not a missing logic, but a bug.

After several failed attempts at the above described MSRM falling leaf entry procedure, I realised that the aircraft is just too stable for the aileron to generate enough sideslip angle and start oscillating. This is about pure aerodynamics now. I'm using the coefficients and derivatives from the NASA F18 HARV wind tunnel and flight tested data, which shouldn't differ too much with our production F18C, especially the trend of stability reduction at high AOA. There're three main areas of under-representation in our current flight model: 1. Directional static stability (Cn-beta) is just too high above 30° AOA. According to the wind tunnel data, Cn-beta drops below zero (= statically unstable) above 30° AOA, which means any sideslip built up has a tendency to increase by itself. I'm not seeing such instability in DCS. Any sideslip created by the aileron or rudder would just be reduced immediately at all AOA ranges, and this is with MSRM engaged so no FCS augmentation. 2. Insufficient adverse yaw created by the aileron. Please refer to the Cn-dA curve below, which is the coefficient of yawing moment created by the aileron. There should be a huge amount of adverse yaw created above 40° AOA, but I'm not seeing much and it's not generating enough sideslip. 3. Too much roll control power by the aileron. Refer to the Cl-dA curve, rolling moment coefficient is greatly reduced above 40° AOA, but I'm not seeing such trend either and it's just like rolling at 25° AOA. Additional observations by @Maverick Su-35S, thanks for the testing: References: Figure 19, 22, 23 from "AERODYNAMIC PARAMETERS OF HIGH-ANGLE-OF-ATTACK RESEARCH VEHICLE (HARV) ESTIMATED FROM FLIGHT DATA", NASA TM 202692, https://ntrs.nasa.gov/api/citations/19900019262/downloads/19900019262.pdf

Our current Auto Flap Up FCS implementation is using sideslip feedback to control the rudder, which I consider as a bug, because the feedback is erroneously applied to the rudder rather than to the aileron and differential stabilators. The sideslip and sideslip rate feedback should be fed to the aileron and diff-stab above 20 deg AOA, as in FCC OFP v10.7 IRL. For now, I'm seeing rudders move with sideslip changes even if AOA < 20°. Test procedure: 1. Set an extremely turbulent weather. 2. Flaps to auto. 3. Press F4 to get a closer look at the rudder 4. Check if the rudder is moving with turbulence/sideslip changes. Use active pause so that there's no lateral acceleration and yaw rate interference to the rudder. Test with AOA below or above 20 degrees. References: 1. Park, David J., "Development of F/A-18 Spin Departure Demonstration Procedure with Departure Resistant Flight Control Computer Version 10.7. " Master's Thesis, University of Tennessee, 2004. https://trace.tennessee.edu/utk_gradthes/2312 2. Mitchell, Eric John, "F/A-18A-D Flight Control Computer OFP Versions 10.6.1 and 10.7 Developmental Flight Testing: Out-of-Controlled Flight Test Program Yields Reduced Falling Leaf Departure Susceptibility and Enhanced Aircraft Maneuverability. " Master's Thesis, University of Tennessee, 2004. https://trace.tennessee.edu/utk_gradthes/2372 3. Simulation Model of a Twin-Tail, High Performance Airplane, NASA TM 107601, including a set of FCC OFP v10.1 block diagrams (https://ntrs.nasa.gov/api/citations/19920024293/downloads/19920024293.pdf) 4. NATOPS manual which is not quoted here but contains relevant info. According to the Directional Auto Flap Up CAS block diagram from reference 3, there's no sideslip or sideslip rate feedback in v10.1 as there was no sideslip measurements available to the aircraft. The feedbacks were only included in v10.6.1 (a test version of 10.7) and v10.7, together with the sideslip estimator. From reference 2 describing the sideslip estimator: From reference 1 describing the sideslip and sideslip rate feedback: Also from reference 1: Hronet rudder moves with sideslip.trk

This might be the root cause: our current FCS is using sideslip feedback to control the rudder, which it shouldn't IRL in the first place. To make things worse, there seems to be a massive sideslip feedback gain being put on the rudder, causing a very weak control response. Reported here:

A bug related to g-response and pitch instability is fixed in 2.9, which could also affect g-onset if more pitch dampening is applied: Using the example of going from 9g to 1g by releasing the stick, in DCS 2.7 and later 2.8 (with partial fix) this looked like going from 9g to 0.5g rather quickly, undershooting below 1g and then slowly creeps back to 1g, especially at speeds between 400 to 500 kts, displaying a lack of dynamic stability. Now it looks like 9g -> 2g -> 1g as a 1st-order g-response, which is a correct response type as IRL is. But the bug fix introduces pitch creep, which is to say, upon releasing the stick the nose tends to continue creep a bit more degrees until it stops.

The phugoid is gone in 2.9. Many thanks. Now the opposite happen and there's a tendency to overshoot the pitch attitude upon releasing the stick, but the original bug is fixed.

While I understand both are WIP for several years, I'm not seeing sideslip and sideslip rate feedback being implemented either. So our current FCS cannot prevent falling leaf OCF from happening at all. An OFP v10.1-10.5.1 would best describe our current FCS status. But I keep failing at entering the falling leaf intentionally. Or maybe it's a very early WIP flight model. The procedure of MSRM falling leaf entry as described in reference 1:

Haven't had the time to check it thoroughly but I would recommend looking into the IRL control logic for any rudder authority limitations. A good place to start is the paper 'Simulation Model of a Twin-Tail, High Performance Airplane' by NASA (https://ntrs.nasa.gov/api/citations/19920024293/downloads/19920024293.pdf). Page 113 contains detailed description of the Directional Auto Flap Up CAS with a set of control block diagrams of FCC OFP v10.1 directly from the MDC report. Page 115 and beyond detailing the block diagram and gain schedules: (Ri = dynamic pressure Qc / static pressure Ps) So your pedal command is effectively shaped by the PEDAL GRADIENT, that uses Function 10 to reduce the gradient at higher dynamic pressure (or airspeed), which prevents exceeding the vertical tail load limits. Then the command is multiplied by (0.5 - Function 17 * Function 114), and is limited to -/+30°. Function 17 increases the gain at higher alpha, while Function 114 increases the gain at higher mach number. The more gain they produces, the more reduction to the command ratio. The idea is to prevent medium to high alpha yaw departures caused by misplacing the pedal. This concludes the command path and may explain why the rudder command is reduced. The remaining paths are feedback paths, like yaw rate feedback and lateral acceleration feedback, that are used to enhance directional static stability (provides turn coordination) and yaw rate dampening. A higher feedback gain could increase stability and dampening effect, but could also lower the yaw response and destabilize the system, causing the rudder to oscillate. Sideslip and sideslip rate feedback is only added in OFP v10.7, and is not provided to the rudder, but to the aileron and diff-stab. But I found no indications that any v10.7 logic is implemented in DCS. Cheers.

Hi, This is not a bug report YET as I try to collect info about the FCC software version implemented in DCS, which could be OFP version 10.7. My main references are: 1. Mitchell, Eric John, "F/A-18A-D Flight Control Computer OFP Versions 10.6.1 and 10.7 Developmental Flight Testing: Out-of-Controlled Flight Test Program Yields Reduced Falling Leaf Departure Susceptibility and Enhanced Aircraft Maneuverability. " Master's Thesis, University of Tennessee, 2004. https://trace.tennessee.edu/utk_gradthes/2372 2. Park, David J., "Development of F/A-18 Spin Departure Demonstration Procedure with Departure Resistant Flight Control Computer Version 10.7. " Master's Thesis, University of Tennessee, 2004. https://trace.tennessee.edu/utk_gradthes/2312 3. NATOPs manual which is not quoted here but contains relevant info. Preliminary testing in game shows that a core function, which is described as 'Opposite Differential Stabilators for Roll', is not implemented. Description from reference 1 is quoted below: Description from reference 2 is quoted below: Video evidence of Opposite Differential Stabilators, from 0:42: To my understanding, this would be very useful in generating proverse yawing moment in the direction of intended yaw, increasing the yaw/sideslip maneuverability of the Hornet at elevated AOA, which is currently lacking in DCS. I'd like to know if this is an intended omission, or we're getting an earlier (pre-10.7) OFP version of FCC. I'm also testing the effectiveness of sideslip and sideslip rate feedback to the aileron and differential stabilators, and the susceptibility to the falling-leaf mode, as described in the papers referenced above. Let me know if anyone has insights into those subjects, thanks.

Figure B1-1 (sheet 1). Note that the basic aircraft drag index is different in the USAF manual (0/0) compared to the ones in HAF manual.

@TOT_53 The payload in your F-16 test DCS Word Test Data (silver.ru) seems not correct. According to CJ-1-1, Drag Index of a basic aircraft includes AIM-9L tip missiles on 16S210 launchers. It's not a completely clean aircraft.

Track is attached to OP, and it includes 4 tests at different speed/alt. The third test, starting at 540 kts, shows a correct 1st order g-response. The rest of them are all incorrect behavior with a noticeable phugoid.

Track is attached to OP with a condition of DI=0, GW around 26,000 lbs and an altitude just above sea level. Notice the decelerating max-g pull before AOA hitting 15 deg.

Hi, holding 9.3g does not mean holding speed as well. The test is to check the top right portion (max-g line) of the EM diagram, whether the F-16 is able to hold and keep a max g-limit while bleeding speed or increasing speed. As long as the EM diagram of the same test condition shows that the max-g line is there and attainable, it's worth to test. From an aero and FLCS point of view, the max-g is attainable when: 1. AOA < 15 deg (CAT I) where FLCS starts to decrease g-limit. 2. The horizontal stab doesn't use up all its authority (travel range) in supersonic flight when the aerodynamic center moves backward. I may need more tests (and yes tracks) to come to a conclusion, but my initial tests do suggest that it's somewhat related to the bleed rate, that if the aircraft bleed its speed during a max-g pull, the attainable max-g would be reduced by 0.1-0.3g. This is pretty common in a BFM situation.

The dynamic pitch stability is degraded over around 400 kts, indicating a recurring bug that was fixed some time ago. The g-response is no longer a first-order response. New track is attached. Viper phugoid at speeds.trk

Never heard of that. IIRC the Angle of Sideslip feedback function is unavailable for the FLCS when AOA < 10 deg.