Search the Community
Showing results for tags 'vrs'.
-
Hello, I'm not sure if this is a bug or if it's theoretically possible, but it happens often enough for me to question it. I tried searching for previous threads regarding this, but couldn't find something with the exact issues either. Please feel free to move/close/point this thread to an existing one if one does exist. From a theoretical standpoint, helicopter rotor discs have 3 modes of flight: 1: Normal flight (air travels down through the rotor disc) 2: Autorotation (air travels up through the rotor disc) 3: Vortex ring state (air travels down through the disc, and is then recycled around the rotor tips and back through the top towards the bottom) I'm a huge believe in practicing full-down autorotations, thus I use DCS as a good platform to play around with. I am a real pilot (only ~100 hours however), so I'm not an industry veteran, and I'm well open for suggestions, corrections, and others' experiences. The issue at hand essentially seems to be the ability to enter VRS while the engine is idle or off, and the aircraft is already in a state of autorotation. To replicate this, set up at around 2000ft AGL, drop the engine to idle, and enter a direct vertical descent autorotation. Once in a stable auto at 0 knots airspeed, and 1500-2500FPM descent, firmly pull the collective to max pitch. What I would expect to happen is my descent rate being reduced, until the rotor RPM decays enough. What happens instead is a rapid increase in descent rate (Unexpected), along with the rotor bleeding off RPM(Expected). As I understand it and as the industry has been teaching, the following factors must be present to enter vortex ring state: 1: Descent rate of greater than 300FPM (This factor varies widely based on aircraft, rotor loading, etc. The FAA just uses 300FPM as a safe number) 2: Airspeed less than Effective Translational Lift 3: Between 20-100% engine power (essentially some power that's keeping the rotor spinning rather than RPM decaying) I have two ideas as to what could possibly be happening: 1: The firm pull on the collective is enough for the aircraft to enter VRS briefly as if it were still under power 2: The flight model doesn't have this simulated properly I'm at about a 50/50 split between my two theories, and I'm open to what others may have to say. I've done autos in an R44 at ~20 knots with no flare, and the rotor RPM decays immediately and arrests the descent. I'm able to replicate this in DCS as well, and I'm 99% sure it can be attributed with there being enough airspeed to be in ETL. So the only effect I'm questioning at this point is the ability to enter VRS at 0 airspeed. I know the DCS Huey flight model has been particularly prone to VRS in the past as well, based on some other forum posts I was reading. Again, feel free to question, critique, correct, or share your experiences, I've been meaning to ask this for a while and finally had some time to do it.
- 9 replies
-
- vrs
- autorotation
-
(and 2 more)
Tagged with:
-
Before I type my bug report - a positive note. The latest patches have introduced an enhanced fidelity if the collective blade pitch is changed either for the airframe reaction and orientation. Not only the nose or airframe vector but also the entire tilt and drift change in a very fidelic way. This is especially noticeable if the КРЕН and ТАНГАЖ dampener channels of the ВУАП-1 suite system are in use, and the НАПРАВЛЕНИЕ dampener channel and the высота maintain channel are turned off. This is a very positive sign and I hope this is a small symbol about the intent to have a fidelity gradient for this module this iconic rotary frame deserves, Now for the less positive - aka the bug report. Unfortunately the situation described in this bug report: and especially in its mysteriously vanished parts have worsened and are now clearly a more systemic issue that is a culmintation of various (in parts acknowledged and already being worked on in insularity) issues that cause cascading issues. The missing weight (mass) and inertia is leading to more oscillations, especially with a "light" configuration (less fuel, light munitions load) that is itself problematic during a terrain final (hover) on non-flat "terrain" surfaces. Clearly noticeable is now that the DCS trim settings ("control helper" or "special tab" options) of "default" and central position are NOT reliably working during any instance, even within the same DCS client session. Further the INGAME settings of "AP trim" (trim button setting) and "manual trim" (fe coolie hat) seem to cause cascading issues in the game code, resulting in more and more offsets to the point that even a full reset result in progressive input necessity and corrections (cyclic stirring). On top of this the constant exception catcher events of the DCS proprietary settings result in more and more input necessity during a longer flight (no reinit of airframe and or world load). Another sympton is the drift-gauge suddenly showing random indications, while the player can notice the airframe behaving completely differently. Sometimes this even results in mirror indications of what is going on or the gauge switching from random left/port-right/starboard indications with the airframe having a TVI in an entirely separate third orientation. On top of all of this there seemingly is a threshold where - again as reported before - VRS seems to suddenly occur like a trigger event (the attentive enough can even see the airframe frameblink before the VRS effect kick in as if an ingame event was triggered). Where before VRS might have been recoverable, it now is an unrecoverable disatrous quicktime event.. even if this even occurs already on the ground or at 1-2 m AGL. More disturbingly this event can occurr in a stable hover and a sinkrate of -1 or -2 on the VSI (radar alt on) and the Doppler-hover system working. So apart from the bug state in each part mentioned, there is a cascading interaction on a systemic level. If the results are caused by this cascading interaction cannot be judged by an enduser and it evenly shows the possibility of an unerlying fundematal source issue causing said interaction or even gradients of the insular bugs in each keylog submodule. Which could be the clearly hardmodified weight variables, the currently missing physicalized inertia, anything. That there IS a bug can not only be noticed by the osciallation issues, the VRS states, the inability to trim at a certain point (or the "trimlock bug) but also by clear exception catcher and outlier events. Example: if these bug in any subset have started occuring.. an RBS effect will result in the airframe rolling at 3-4 times the speed it would normally RBS roll to the right in a comparable, replicable scenario. Test scenario: Singleplayer and multiplayer with repeatable scenarios in direct comparison to prior bug notice x52 sets magnet modded, spring modded, zero signal stutter, controls cleaned (not double binding of active peripherals) trim setting (DCS proprietary) "central position" including "rudder" ingame settings as described above current workaround of constant "reset" and retrim from zero applied Dxdiag irrelevant but attached. Trackfiles: 2x singleplayer, direct comparison to prior scenarios, chosen because of drastic showcase and 8+ repetitions and chosen because of lean trackfile. https://drive.google.com/file/d/1ojlq_M56d2skyne8_9QmqmFvgFqcHZE2/view?usp=sharing https://drive.google.com/file/d/1ok5VXQnXas7UBmTQgEIrHr_4wcDA3e91/view?usp=sharing DxDiag.txt