Ahmed

Not a Hornet but: Regardless of being FBW or not, aircraft are usually designed to fly like..... aircraft.

Not specifically ownship related, so it may not be the same issue that OP reports, but this happens all the time in MP with other humans. I haven't had time to reproduce into a short track:

Hi, 1. Set up a mission with me and a single group hostile 2. within 25nm head on, NCTR prints single group hostile as Su-27, trackfile gets a hostile HAFU, as expected. 3. Lost lock, flowed North for a while to ensure that there are no trackfiles left 4. Turned South. As soon as I locked the previous group, it gets unexpectedly ID'd as hostile with print Su-27 while outside of the 25nm "NCTR range" It seems like the code caches previous per-object NCTR prints but doesn't clear cached prints when the trackfiles are dropped, and thus stores them forever, leading to a new trackfile on the same object getting automatically ID'd as hostile and it's type to be known when it should not. I originally noticed this when reacquiring targets from a side aspect. The procedure above and the track are just a way of consistently reproducing it. nctr.trk

I don't think there is any clear definition of "flared landing" other than a landing in which descent rate is arrested prior to touchdown. There is a semi-relevant note about 500 fpm with asymmetrical stores, that could be a reasonable threshold to call something flared (although 500 is definitely on the "positive" side). Not to be confused with aerobraking, as mentioned above.

Hi, Running a test to investigate the issues trying to maintain on-speed during turns in not-auto flaps up operation, I noticed the following: 1. Started test by setting on-speed (~152 KCAS) 2. Entered turn, applied aft stick input up to maximum (limited to 3.55 inches aft in not auto flaps up logic, and also to a ~70% of travel in DCS) 3. Noted that pitch stick command and pitch trim bias allow to pull up to ~14º AOA (stab deflection up to 24º teu). All within expectation. 4. Accelerated to ~230 KCAS, trim untouched, entered turn attempting to capture on-speed. 5. Max pitch stick command won't achieve the previously trimmed 8º AOA, max resulting stab deflection is now only 6º teu. 6. Finally, accelerated to ~243 KCAS to force transition to auto flaps up logic. On transition, noted big AOA and pitch rate spikes as the FCS command transitions between 6º teu and up-to-24. (Note that these spikes will also happen in case of only applying the ~70%/3.55" stick limit mentioned above, and smaller deflections too -- this is not in the attached track, where I used full deflection, but the result will be similar) I'm unsure of what exactly is wrong here. The pitch stick command, trim bias, and aircraft sensor feedbacks are scheduled by airspeed in not-auto flaps up operation, and the gains and limits may benefit from some tuning. I couldn't find a reference to the 6º teu limit observed above at higher speeds anywhere. The aircraft seems to have very little pitch authority in the above test conditions with the current gains. I'd appreciate if you can run this report by your dev team FCS expert, as this particular test case may have slipped through them. FCS_PA.trk

Edited the title as this is not related to crossing from one elevation hemisphere to the other, it has some other cause. In response to your question: it is not, as evident in the track. It can be reproduced at near zero az/el from the emitter.

As per the thread tittle. It seems to randomly lose handed off target. EDIT: it is not related to hemisphere change, thus the edit. Added second non-maneuvering track where it also happens. Hornet_TOO.trk harm-nonmaneuvering.trk

+1, there are still quite a few inconsistencies in the INS modeling, update modes that are not implemented, and also some shortcuts taken, such as this one:

I'd advise though to keep anything that is not directly related to the WOW issue in a different thread, or we may get everything marked as "correct as is", if both reports get intermixed. My initial report is intended to address the apparent lack of WOW logic since the last update, and the associated unexpected FCS stab commands during the take-off/landing rolls.

Hi BIGNEWY, I understood that the changelog item meant that they were supposed to hold throughout the whole MIL check range (they don't past ~95% in current DCS). If it is intended, then disregard.

Hi, Looking for the cause behind the takeoff/landing issues noted after the FM update, I think that I have found an issue with the new FCS code. It looks like the transition to WOW mode, at least in pitch command, is not happening, or that WOW mode logic has been changed to a wrong one. According to documentation, for stabilator command in WOW operation, aircraft sensor feedbacks are set to fixed values or do not exist. This was how it seemed to work in DCS prior to the FM update, but now it seems to receive the same feedbacks than in "Not auto flaps up operation". I did the following tests: - taxi.trk: noted that the stabilator reacts to changes in pitch rate/aoa while taxiing (like it would on a viper, but should not in a hornet, as seen in any YT video) - takeoff_12.trk: take off with 12º ANU stabilator. Rotation speed for this configuration is about 145kt. At approximately 100 knots the FCS starts commanding ANU stabilator, as in seeking to capture an AOA. The aircraft lifts off by itself. FCS reverses the ANU stabilator command and captures 6º AOA. - takeoff_16.trk: take off with 16º ANU stabilator. Same observations than above, just the FCS captures 10º AOA. - landing.trk: notice that immediately after touchdown, the FCS commands 24º ANU trying to recapture the trimmed AOA and holds it throughout the landing rollout until the speed reduces to near zero. It seems that the FCS logic after the update disregards WOW mode and just remains in "Not auto flaps up operation" logic, trying to capture the command trim AOA. This explains all the weird things observed after the update, such as: - Aircraft taking off by itself prior to rotation speed (due to FCS commanding unrequested ANU stabilator) - Nose strut staying extended after nose gear touchdown (due to FCS commanding 24º ANU stabilator on touchdown) - Possibly also explains the uncontrolled pitch up issues that people have reported if taking off with flaps auto The correct behavior would be as documented in the WOW operation description (and as it seemed to work prior to the update) Aside from the quoted documentation reference to "WOW operation" logic, I link below the following videos: - Taxi out (little-to-nil stabilator motion) - Landing (no such thing as sudden command of permanent 24º ANU on touchdown. - Another example (notice that the pilot commands aft stick later on during the rollout to aid in braking, but there is no such thing as a FCS 24º ANU command on touchdown) This was working well before the update, so it must be an issue with the new code and WOW logic. Probably some of the SMEs in the forum can amplify on this. landing.trk takeoff_12.trk takeoff_16.trk taxi.trk

Last changelog included: Fixed: Brake check holding at Mil power. However, they don't. The FCS commanding aft stabilator deflection to rotate the nose also looks suspicious, as the NATOPS technique states that the pilot must apply aft input at the nose wheel liftoff speed. brake_check.trk

Noticed unusually high fuel burn against planned. At a reasonable M .80 cruise at 25k in ISA with a DI 100 loadout and 46000 lbs: - Expected FF: 6300 - Observed FF: 7900 That's a +25% error in an area of the envelope that should be quite commonly encountered, near optimum cruise aoa. Either FF or drag seem to be significantly off. Ref: specific range chart for 25k 46klbs Most likely other data points will render similar errors. 25k_M080_FF.trk

No, I don't, other than this highly unusual handling characteristic that the DCS hornet shows not being documented in the NFM handling characteristics, which should be enough evidence by itself. Any conventional aircraft is not expected to roll further into the turn as that would make it display negative static lateral stability.

Hi, After the last FCS/FM update, the hornet still overbanks considerably when in PA mode. pa_overbank.trk