Jump to content

Ahmed

Members
  • Posts

    405
  • Joined

  • Last visited

Everything posted by Ahmed

  1. 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
  2. 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.
  3. 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
  4. +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:
  5. 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.
  6. 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.
  7. 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
  8. 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
  9. 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
  10. 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.
  11. Hi, After the last FCS/FM update, the hornet still overbanks considerably when in PA mode. pa_overbank.trk
  12. Not a bug as such, but definitely something to raise as a dubious gameplay decision. For a few updates already, the controls freeze when the salute command is given, until after catapult launch. While the intent behind this may be to simulate that no inputs are possible when the pilot models' hand away from the stick, this can result in very undesired behaviors. For example, if the salute is given with the controls in a "wrong" position, the player will be unable to return the controls to center. This is completely unrealistic. Another example is if a prompt correction is needed after launch, this is also not possible until the pilot model animation finishes and the game allows the player to make any new inputs. In both cases the player may end up crashing, while nothing would prevent a pilot irl from actuating the controls. Please consider reverting this change, or at the very least adding an option in the module settings to toggle it on/off. For those of us that don't use the pilot model, this is just a nuisance. I don't think that a track is needed for this but let me know if you need one.
  13. Hi, 2.8.2 introduced some scripting changes regarding when Group script objects get deleted. Previously, they existed even after all Unit objects had been removed. This has highlighted the fact that DCS currently doesn't trigger any event when an aerial Unit gets despawned after engine shutdown and will make any scripts that make reference to that Unit or Group crash after the Unit/Group gets despawned. Please consider adding a new event that gets triggered on unit despawn, or triggering S_EVENT_UNIT_LOST also at that point.
  14. The OP is correct regarding the SA-2 and other non-CW waveforms in DCS wrongly illuminating the CW light. The SAM light turning off at the missile launch is also wrong. The CW light indicates that the system has detected continuous wave illumination (@BIGNEWY refer to the FRM, among other documents, for evidence of that). As a rule of thumb, CW illumination would normally be linked to SARH guidance. DCS seems to not distinguish between command guidance and SARH guidance for SAMs, the same way that it doesn't support different tracking/guidance methods for the different phases of the engagement. This is one of the many issues affecting the implementation of the DCS Hornet's ALR-67, together with the wrong implementation of the different lethality categories, missing HUD EW symbology (flashing long stem being the main miss), tones wrongly playing together, etc. Hopefully ED will pay a visit to the Hornet's RWR at some point to fix all these points.
  15. what's exactly wrong here? Tuning the paired channel of a VOR/DME station should receive DME from it, the same way that a VOR/DME receiver can tune a TACAN paired frequency to receive DME for it.
  16. Also, a lot of useful things for the player happen there, such as setting voice callsign or flight lead/mission commander status. With the new L16 improvements in other modules, it needs to be implemented in the hornet to access basic stuff such as the voice callsign.
  17. With the wings folded, the AIL row should be Xd out, as no hydraulic pressure is being supplied to the aileron actuators. Source: multiple checks and cautions through the NFM-000 to ensure that AIL row is Xd out with the wings folded, including after a FCS reset and FCS BIT. ail_x.trk
  18. Ahmed

    MC1/MC2 cautions

    Thanks for the reply @Lord Vader. Are you sure that the MC switch has no function? Part of the logic at least seems to be implemented (MC1 OFF -> loss of various SUPT menu options, MC2 OFF -> loss of STORES option on TAC menu). What is missing is getting the associated MC1/MC2 cautions, when the switch is moved to those positions. Thank you!
  19. Xs should appear on the FCS status monnitor PROC row for CH1 and CH3 when the INS ATT caution is displayed or ATT switch set to SBY. Source: DCS F/A-18C Early Access Guide (DE) F/A-18C (digitalcombatsimulator.com page 71 (and NFM) fcs_proc.trk
  20. The MC1 and MC2 cautions don't show when the respective MC is off. ("Functional Check Procedures"), Before Taxi, Mission computer operation, and Status Monitoring Backup. mc.trk
  21. Hello, The L FLAMEOUT and R FLAMEOUT cautions and their associated "engine left, engine left" or "engine right, engine right" aurals don't sound when RPM drops below 60% with the throttle at or above IDLE. ("Functional Check Procedures"), Engine Start, Engine Fire Light Shutdown. l_flameout.trk
  22. Hi, The SA-2 kill radius ('KillDistance' paramter) in the data files is defined as 20 meters, that is less than 1/3rd of the commonly found value if one investigates. If I'm not mistaken, this parameter controls the proximity fusing of the missile in DCS (that is already flawed as it doesn't seem to consider the dimensions of the target aircraft either and just its origin). The values commonly found if one investigates are 65-70m for kill radius and 100-120m for severe damage blast and consistent across sources. The fuse in the V-750 missile series has various settings depending on target height and closure and will be armed at between 100-300 meters from target to actually fuse just past the closest point of approach. For comparison purposes, the DCS AIM-120 is defined with 15 meter kill radius!! The AIM-120's warhead weighs basically 10 times less than the ~200kg SA-2 missile warhead. The SA-5 that has a similar weight warhead than the SA-2, is defined with 45 meters. This results in near misses in DCS not detonating, when they should, and in DCS not correctly depicting the real power of the SA-2 system to take out several aircraft of a formation in a single detonation, or the large warhead compensating for the missile's low maneuverability. No track attached due to the numbers in the data files speaking by themselves.
  23. In this last update, the radar track files seem completely broken. After some testing, it looks like the track files are being dropped within 6 seconds, ignoring age setting. (EDIT: age setting is unrelated to this. However, the "new" 6 seconds are still wrong and result in anything with a frame time greater than 6 seconds being unable to generate/keep a track file. This processing is at the very least performed after one full frame). This means that only very small search volumes (az/bar/prf setting) will result in a track file being generated and maintained in this DCS update... and severely affect Hornet air-to-air performance in SP and MP. Track attached. rdr.trk
  24. The LAR indications for the GBU-38 at altitudes <= 10000 are wrong. At all tested airspeeds, the bomb falls short. gbu38lar.trk
  25. @BIGNEWY, we are not talking of adding errors or drift here. We are talking that the aircraft thinks it is at N 00 E 00, while the TPOD shows the real coordinates of the point being aimed. It is not generating the coordinates relative to the aircraft's INS, based on Azimuth and Elevation, but it is just cheating and showing the absolute world coordinates instead. That's a bug and a development shortcut, not a new feature to add.
×
×
  • Create New...