Volk.

The tandem ones are also very interesting. I'm definitely wanting to understand all the flight dynamics, at least the stuff that affects the pilot, not necessarily all the crazy maths and possible forces. I'm very tempted to do a vid at some point about tandem (and specifically the Chinook, given it's one of the most popular variants). Though that has it's own complications, e.g. cyclic sideways tilts the rotor cones like one would expect in tail rotor/coax, but tilting cyclic forward/back leads to different inputs in the front and rear rotors - so different control input and reaction there, nevermind all the dynamics of the airflow between the two rotors. Attached below from the Chinook A/B familirization manual - for forward flight the upflap & downflap is definitely in front & rear - which I'd expect from the Shark as well. It also makes sense that the max angle of incidence/pitch is at the 3 & 9 respectively (or close to those angles), where the flapping velocity (but not height) is at it's maximum. It'd follow that the max coning/flapping is at the 12 (or close to it depending on dampeners and offset of the hinges etc). In my mind the upflap and separation are linked, so yes, that is a point of confusion for me. I'd think maximum angle of incidence/pitch in combination with airspeed is what generates more lift (90-ish degrees later) and thus the flapping up (culminating 90-ish degrees later) , which finally leads to the rotor intersection for a coax. I did see Einstein (that SimHQ links) article before - useful stuff. But for the upper rotor generating more lift at speed, would indicate more torque from the upper clockwise rotor and thus that the Shark's fuselage would naturally turn to the left and need a right cyclic input to counter it (which should also tilt the cone to lower on the right and raise on the right), not a left one. If the top rotor's lift in fast forward flight weren't dominant, then the left/right cyclic to counter transverse flow banking should be offset and simply require forward stick.

There's also advanced blade compressibility stall, and I think a few other rarer ones - not sure if all that's in DCS, or if a coax really 'feels' it. For that sharp turn - I'm assuming you're doing some pitch-up movement (like a cobra maneuver) to brake and then turn - that definitely gives a sharp right yaw. I suspect it's from the air suddenly rushing through the lower rotor that then generates more torque than the upper rotor. In a hover without the AP channels there is a slow right yaw, yes. So in the flight model there's also clearly a slight right yaw always, but that's still in the AP channels 20% authority to fix for you. I've just come onto pedals from using a paddle-thingy on the throttle myself for rudder. It is tricky, but ultimately the auto-turn won't always align one well enough for a good shot, especially in wind, so practicing the rudder pedals while targeting is probably the best way.

Cheetah, I have found that if you refire the laser (ie. lock with laser) after slewing while the laser is already firing, like trying to tap the lock button in trying to lock up a fast moving target, it's almost guaranteed to corrupt the range, usually coming up short once the laser stops firing. Think my second vid on sniping & locking shows this better than I can explain in words. No idea if that's a bug or simulation of the real thing, given re-firing/ranging isn't protocol from the manual. The Range also gets funky if you scroll 'upwards' and it goes past the 15km limit - then it keeps going into infinity. I've also seen it do this over time with tracking a helo at 6.5km - eventually it lost sync and kept increasing the ranging. Also unsure if bug or what it's supposed to do. As far as I've read there's isn't INS error accumulation/drift in the K-041/PVI-800 in the sim at the moment (i.e. like with the Tomcat where even without violent maneuvers your stuff becomes misaligned), though they did code the alignment procedures on the panels. Lastly, it's only accurate when you've ranged for a distance - ie. pressed lock. At any other time, barring HMS usage the laser isn't firing and it's just guessing the range - same with pressing laser reset - from then on you'll see the number adjust subtly as it adapts that number, guessing it by angle I guess, but it's rarely exactly accurate unless you laser-lock again - that I believe is correct. Whether it should overshoot / undershoot to a crazy number, I don't know, but then again not all this tech from 20-40 years ago was accurate/solid on every use.

Cheetah - one of the more recent OpenBeta fixed the Vikhr reticule not dropping and external-view launchers not lowering - that was a more recent bug and has been fixed (in Openbeta). As for the Shkval drift - if there's no laser ranging then the ground stabilisation/internal tracking doesn't kick in, so in certain flight regimes it will drift. If you laser lock it generally stays on target unless you run the target outside the gimbal limits, or bank/yaw too hard. That said it may still lose a lock on a moving target, especially a fast mover - though that doesn't seem like a bug. If I recall you can't store datalink targets without a laser-lock (ie. correct ranging), but if you could, or you corrupting the lasing by refiring it early then that datalink store would be innaccurate. Other than that the ABRIS is supposed to be accurate to ~20m, though I've read if you have insufficient satelites it may be less accurate - haven't tested that. The Shkval itself isn't on par with other modules with a similar locking mechanism - that's just what it is. That said they could fix the curves/deadzone on the axis slewing and make it proper contrast lock system. Otherwise try the helmet to lock things up at certain ranges. Can't disagree with your other statements.

Thanks for that reply. I'm clearly not quite following yet. Unfortunately most footage of the Ka-50, Ka-52 or just any coaxial rotor is normally either slow flight, acrobatics far from Vne or simple not at an angle where one can make out the separation between the rotors. I think I've seen footage of a Ka-52 with rotors closer on the right, possibly slightly just behind right, but I've also seen footage of a cockpit view showing a Ka-50 going 250kph with the rotor discs seemingly equally separated. For cyclic feathering - it's easily demonstrable on the ground. Attached 3 pics, showing max right cylic on the ground at Auto Throttle, with collective so it won't start taking off (or coning really). While it's not that easy to see the cyclic feathering pitch changes itself (could be hard to see or may just take too much CPU out of your sim for things people will never see), but one can see the result of those pitch changes - from the rear one can easily see both rotor cones have tilted to the right. The lower (counter-clockwise) rotor increases pitch in front to produce the extra lift on the left (from gyroscopic precession) and as result of that increased pitch flaps up fully on the left - somewhere near the 9 o-clock position. In the third shot I tried to frame it - though it seems to be max upflap/vertical flapping height just past the 90 degree mark instead of just in front of it, but that may just be a wrong screen capture - so it's not an issue. The Top rotor pitches up at the rear and flaps up fully on by the time the blade reaches the left. This way lift is produced on the left to bank right (if I had enough collective pitch and RPM for flight) and both rotor cones seem to match their tilt and separation. If I pitched the cyclic forward on the ground (not pictured), then both cones tilt down on front and up at the back, which again makes sense. The max downflap visually appears to be about 1 o clock for the lower rotors (that would fit with the 70 degree phase lag from the hinge mechanics/position) and the top rotor about 11 o-clock. And yes, that was fun - don't think I've ever marvelled at the rotor disc tilting just while on the ground before - nice modeling there. In fast forward flight, where there's pitch down, you'd also have coning, so both rotors would angle a little more up all round from the lift. Also dissymmetry of lift happens when the advancing side of each rotor gets more lift and starts flapping up. With that dissymmetry alone, ignoring coning from lift and flapping cyclic feathering momentarily, you'd get the lower rotor getting more lift as it advances on the right, starts flapping up to reduce the dissymetry and has it's full upflap near the front, possibly the 1 o-clock position, and maximum downflap probably 7 o-clock. Meanwhile the top rotor would have more lift on the left, culminating in the blades starting to flap up as it gains airspeed on the left and flapping upwards to it's limits in also in front, maybe 11 o-clock. In both tilting the disc with the cyclic and with dissymetry of lift, the discs stay equally distant from one another. I do understand that the Ka-50 has a natural speed limit - it will experience retreating blade stall and the advancing blades breaking the sound barrier at one point, and there are just natural stress limits for various components. And I do also understand that it will have rotor intersections in certain violent maneuvers. Especially with low RPM and stall the blades would flap more erratically and greatly increase the risk of intersection. The bit I'm not understanding is that with both flapping from cyclic input (in this case forward & tilting the cone/disc down at the nose) and from the dissymmetry of lift (tilting the cone up at the nose in my theory), should keep the blades apart. Possibly it might even experience a pitch up moment from the dissymetry before rotor intersection. What force/factor is missing from the above that makes the rotors grow closer to one another on the right, possibly the 4 o-clock position (70 degrees from tail counter-clockwise) during fast forward flight? I know there's a slight left cyclic needed to keep it level in fast forward flight, which I'm not quite sure why that exist (transverse flow?) but should again result in both rotor cones tilted slightly down on the left and up on the right with equal separation.

The area of effect of rockets (splash damage) in DCS is generally considered to be weaker than it should be. But IRL rockets outside of APKWS and the JF17 BRDMS are also area-effect weapons IRL, not expected to be on target with every volley. Just note most rockets you can carry in DCS aircraft are ineffective against armour. You practically need a dead-on hit from a heavier armour-piercing rocket (maybe S-13) in the rear of armour like a tank to even scratch it, which is pretty close to reality if one's not modeling sensor suppression etc. (which would take more outta your CPU/frames). And most missions I've seen made for the Shark, it's set to attack AAA and things with TOW missiles, so that very approach to within 4 or less kilo's for an inaccurate volley (closer = more less spread), and of course wanting to dive a little to reduce spread rather than a level hover-popup, puts you in danger of getting shot by those thing. Similarly the Cannon, while a really powerful accurate 30mm, also won't be effectual until you start getting into range where return-fire is a thing. So for most part if you're taking on armour, then you need to use the Vikhrs or Kh-25. Trucks, infantry, BTRs and that stuff the guns can take out fine and rockets will work there (again splash damage not quite as damaging as it should be). So rockets IRL are also considered area effect weapons, not necessarily expected to land on target and with a few small exceptions not expected to take out a tank - that's where the ATGMs or precision bombs come in. There's a couple of tuts out on rocket runs and how to do them as accurately as possible - short version is slightly faster dive into the wind (or with it), when your flight regime is already stable and the cursor stays level on the target rather than creeping up to it.

Most Shark pilots I know of, if they're not stuck on using FD all the time, fly by holding in the Trim button, then maneuvering, then settling on a new position and once airflow across the airframe and momentum has ceased any wobble (moreso with uncoordinated flight), release trim and release the stick. The 'tappity' thing they do IRL with trim doesn't really work with the Shark in DCS. Unless you were intentionally flying in on a target, or being lazy (which is fine), Auto-turn (if you're referring to the button on the left at the targeting panel) should not be on. I do fly that way on occasion (being lazy) in a non-combat environment, but I wouldn't recommend it if one's learning the Shark's flight. So for normal flight, most people fly with FD off, holding trim while maneuvering, with Heading Hold, Bank Hold and Pitch Hold autopilot channels on. Your choice on which trim-release method and rudder trim options your set in the special settings menu. This is generally the more 'organic' flying, unless you prefer the total control but unstable flight of turning off all autopilot channels... If you do turn on FD, it behaves exactly as it would if you held down trim while maneuvering. That said once you want to release the stick (or at least stop applying pressure), then FD doesn't really hold your parameters while having it off generally does (within authority limits, balance between the channels like trimming for an orbit vs level heading and wind disruptions). Heading Hold off, and by extension all Autopilot channels off absolutely should increase your turning rate, unless you've got double keybinds, curves or deadzones messing with it, hardware issues (again for these check your controls indicator to see that your pedal is actually applying 100% left or right in a stable way), you're not going too fast and you're not flying with lower (and by that I even mean 50%) collective. You also mention auto-turn being on but yaw channel off - that should do almost nothing as Auto-Turn sets a new heading hold, which if you turned off heading hold it has nothing to act on. Unless you've trimmed in a bank it's maintaining, wind is pushing you or maybe you also have route mode engaged which is steering you somewhere or leveling out bank. Most of us don't appear to experience your issues, so likely either your build of DCS got corrupted, there's an issue in your setup/controls or you may need to check out some videos on the specific trim-flying one needs to to in the Shark to get anywhere without it flying crazy. Yeah I think a trackfile or video with your controls indicator would be beneficial.

If you are still having problems with it after you've checked your pedal inputs aren't conflicting and registering 100%, and it's not a speed or low-collective issue, maybe post a video/trackfile? I might not fully be getting your context.

The rotational movement is from (a) the tail rudder turning, likely more useful in fast forward flight, but primarily from (b) the upper and lower rotor changing pitch and thus generating different amounts of torque. When this differential stops, that yaw rate would slow down. But it still has a lot of momentum and possibly airspeed to overcome to start turning - it is an attack helicopter with appropriate weight. I've run a few tests about 2 months back, and at ~74kph ground speed and found on almost no different in speed doing purely max rudder turns whether you were holding trim, not holding trim or with FD with the channels on. No AP channels it went 25% faster at that starting forward speed (and then it wouldn't matter if FD were on or off). Those were just consistent-controls tests, not perfect flat turns which would require multiple controlled inputs. I don't recall anything in the last month or two patching the Sharks flight model, so those results should still hold. I have also looked at some flight show tests, and when the spin around in 6 seconds (can't remember exact timing), they were going slower and more importantly doing a simultaneous pitch up or down movement, not a flat turn as it were. Those crazy spins in shows - usually not with full payload, nor cannon rounds, possible reduced fuel. Unless it's the flat turns with purely rudder and a little counter-bank to avoid tilt, those sharp turns always were at slower speeds combined with a coordinated sharp nose pitching which really gets you moving quickly in the sim too. For the spinning climbs, of course once it's got yaw momentum, keeping that rudder in makes yaw go faster up to a point. Wags did some of those too in the old Eagle Dynamic YT vids - slowing to 70kph with a nose-up, then full rudder and bank. I can't comment on what FD does in terms of slowing a rudder input you've left - can't say I've ever tested that specifically.

If you're flying with your controls indicator on (Right Control Enter), maybe just check that your pedal inputs are indeed going full left/right and returning to centre when you centre them. It might be you have a conflict in the controls (and the indicator 'jumps'), there's a deadzone or curve setup or the pedals might not be working fully. Maybe also check if you've ticked rudder trimmer in the special settings - if you've trimmed a large amount of right rudder, then pressing right rudder won't give you more yaw.

Mistyped - instead of "that yaw", it's meant to say "that heading". ie. the heading you set with your last trim, engagement of auto-turn/hover mode/route mode (there's some complex interactions there) or re-engaging the heading hold switch. It'll try and return you there if FD is off. With FD on it's won't try and return/correct any of your channels, so yes, that one moves/wobbles around kinda like the Huey would. FD is more a thing if you don't want to fuss about holding/tapping the trim button. Personally I'd only use it if I were doing a LOT of maneuvering, say snaking around canyons at speed or acrobatics stuff. It's not the breath of life and only way to fly like some claim. By dampen I mean that if you were to switch all your autopilot channels off, your helo becomes VERY agile, to the point that you intersect your rotors really quickly. Again at high speed and/or low collective you'll have much less maneuverability. If you pull up-right with a little right pedal at 130kph you can die instantly with those channels off. With them on they dampen your crazy maneuvers so you might have a better shot at not getting a rotor intersection or uncoordinated flight. If your channels are on, then it dampens the movement, and after you release trim & the stick, tries to stabilise you back on the heading/bank/pitch (combination of the 3 with 20% authority). If you were to Hold down trim while maneuvering with channels on it has the dampening of crazy movements, but won't try to stability/return to heading etc. until you release trim. FD works like you're holding trim all the time. The FD phrase does seem like an odd translation. Although maybe it's a literal translation to a context that's understood differently in Russian. IDK.

Ah, ok, didn't know of that function before. Can't help you on that one I'm afraid.

I can't say I've had to lock Cobras recently, in case there's anything weird there, but it works fine withe Gazelles, Apache, HIND, Ka-50s & Mi-26s. The Tracking Gate (aka box) has to be either just beyond the bounderies of the target on your Skhval screen, or smaller. A box that's just big enough to still lock, but not too bit not to lock does appear to retain that lock a little longer on a fast moving target. It does get trickier to gauge what's too big if the target isn't a fat blocky tank, but rather a complex shape with a tail rotor. And yes, pointing at a perpendicular moving fast mover and pressing lock as it passes by definitely isn't sure-fire. On that 9.5km range - I've had the Shkval not locking at 3km when looking out the cockpit there was ample light, but certain times+atmospherics can get in the way. That thing on the helmet sight isn't cheating - it's not to do with padlocking or displaying dots/^ symbols over the target either. That said, it's not in the manual - kinda discovered it by experimenting. But it makes sense that with the natural movement of the helmet sight that it would allow for a window of time to lock up something the sight is moved across. Hard to explain better in text unfortunately.

Couple of reasons this could happen: The Shkval can lose lock or fail to track fast moving targets - that is a thing. It can only lock targets from about 9.5km - less if there's even a hint of low light (early morning/late afternoon/night) or fog/dust haze. Contrast from your IT-23 screen doesn't affect it - atm it's doing Shkval locks by approximation rather than literally using visual contrast, so that won't affect it's ability to lock. A larger box (tracking gate) does help keeping a lock (limited tests I've done) - not sure it locks it easier, but can't confirm. There is an advanced technique involving using the Helmet sight and 'slew locking' it (I got some youtube vids - check out the second one on sniping). This is very useful against fast moving targets, especially if they have a sky backdrop behind them, you're not still reposition/maneuvering (either a good hover or flying dead at them) and they're at the right range so your helmet sight isn't bouncing all over the place. Especially if you can lock that be looking out the cockpit rather than the Shkval - but it can still be tricky, especially if the Shark's flight isn't perfectly stable and isn't guaranteed. The Shkval does have a harder time locking really fast movers like a jet, as you gotta wait for that narrow 9.5km or less range and then get it while it's still in range and not flying over above you (assuming you're staying low as to not get shot). When we get the Black Shark 3 module with IGLAs then killing jets might be easier as you probably don't have to lock it at short range with the limited-angle Shkval.

There is a function of saving custom cockpit views - I forget the exact name now. But if you find you're suddenly looking off at an angle instead of forwards when you've centered your headtracking (or just loaded in and haven't pressed keys to look around), then it might be that. There is also a Helmet Ring Displacement setting under the main menu > options > special settings tab > Ka-50. Default is 11 degrees. That means that your centre-view is offset 11 degrees down from normal. This is an intentional function so that when you look around you can keep your eyes between the Helmet Mounted Sight slightly higher up, and the Shkval IT-23 screen. You can set it to zero degrees (or close to it), which will then align the Helmet sight with your view, but then you can't keep the screen in your view at the same time.

Maybe it's a bug, which can't say I've had flying a couple hours today - but some of the things affecting yaw/heading: The Shark is pretty streamlined and turns into the wind. So strong wind in a hover will turn it into the the oncoming wind sometimes if that 20% control authority the Autopilot channels isn't enough to keep your facing. Similarly, as you approach 100kph it'll automatically move out of a sideslip or rearward flight and turn into the direction you're facing. From there, the faster you go, the less effective rudder pedals will be given that speed. To have effective rudder control at those speeds, you'd need to nose-up to lose speed, put in a bit of bank and you can rudder over quickly. A flat-turn without bank is most effective at very slow speeds. You can rudder over a bit faster with higher collective - low collective you'll struggle turning. If the Heading hold channel is off, you can rudder over really quickly, provided you're not going too fast or lowered your collective too far. If the channel is on, it's only got 20% authority of your controls - so if you released trim while you've got more than 20% pedal in one direction or the other (check your controls indicator), it won't be able to hold that course. It's also trying to balance the heading you last commanded vs the bank you last trimmed, so a strong bank will have the Shark orbiting rather than keeping a heading. FD does dampen your movements, but it won't return you to that yaw. That said FD also makes it less stable or precise one you've trimmed and the released the stick. All Auto-turn does is set your trimmed/commanded heading to wherever the target is. So if the Heading hold's 20% rudder authority isn't enough to turn you there, like when wind or a slight bank in the opposite direction, then it might not turn at all. Also it's just not that accurate - it'll get you point in the direction, but not exactly on target for rockets. Do note Vikhr reticule hops left-right of your centre-point depending on the launcher. For your problem that it keeps turning, it could be your pedals don't recenter immediately, strong wind as mentioned before, autopilot is returning you to your last trimmed heading (which it's supposed to), trimmed bank is stronger than heading hold, you left Auto-Turn or Route mode on. As with any helo there is also an element of momentum and 'hanging off the rotors' so to speak. Lastly there are also moments like with extreme braking nose-up (you'd also have high RPM) where I think the lower rotor catches more air and it has a strong bank/yaw to the right. Hope that helps.

Slightly longer tutorials trying to explore topics as thoroughly as I can. Most of the content is based on how the sim behaves as at making the tutorial, so it's been tested to have that behaviour at the time. I'll mentioned variables or exceptions I'm aware of so you can spend more time enjoying your Shark than wondering why it did a certain thing a certain way. At the end of the day, if you've learned to command the autopilot to do what you want it to do, and you've acclimated to the helmet-mounted sight and reconning and locking things with it, it can be an amazingly satisfying sniper. Make no mistake it can do many other roles, but sniping armour from relative safety this helo excels at.

Hi, thanks for the reply. ps kudos on the flight model being what it is already. I've pasted an attachment on the flapping. This is for conventional tail-rotored helicopters, but the basics of flapping should hold for coaxial designs. I do understand the Ka-50 has a fully articulated system, so the lead-lag hinge might influence the usual 90 degree gyroscopic precession to be slightly less than 90 degree. Flight dynamics info like this on coaxials is a bit hard to find - typically there are more scientific papers exploring mathematical models or purely stating "it's more efficient in a hover" than diagrams like the below. There's also a few less English-speaking pilots around to find. So might be like you say there are more complex interactions with coax that I'm not getting.

Just to preface this - I'm not a pilot, and I'm still going through FAA guides and such learning these topics. Now guides/learning material I've found is a bit scarcer on coaxial rotors, but from my understanding there are 2 things weird with the Ka-50 - the rotors getting that close in fast forward flight and the cyclic needing forward left input to counter a right bank in fast forward flight. Again this is based more on conventional tail-rotor flight, but correct me where I'm wrong: #1 If the Shark is nearing Vne in forward flight (assume no wind), then you'll see from external view from behind the lower rotor is flapping up to it's max on the right. This rotor travels anti-clockwise, so that's the advancing side. Meanwhile the top rotor is at it's lowest on the right (it goes clockwise, so retreating blades). Flapping happens naturally from the increased speed (ie. dyssemetry of lift) and increased pitch from e.g. cyclic feathering. For this dissymetry of lift, the blade has max upflap velocity, and thus lower angle of attack/lift on the advancing side, i.e. the top rotor at the 9 o-clock/left and the lower rotor at the 3 o-clock. However that's not where the blade's at it's highest, but just the max upflap velocity, hence the decreased lift. The maximum upflap, or where the blade's flapped up the highest vertically is 90 degrees later, which would be the forward for both rotors. So in fast forward flight, the rotors shouldn't be that close but in fact but should be tilted up in front and thus remain relatively equally spaced. ps. I'm not saying the rotors will never clash, or that ~250kph shouldn't be the Vne, just that they shouldn't be clashing on the right like they do at present in the sim. #2 Once you hit transverse flow, you need to (for a counter-clockwise single-rotor) push forward cyclic and left to counter the nose-up+right bank. In the Shark, you need left-cyclic as well. However, I'd think with the coax rotor, those forces would either be equalised so almost no cyclic correction needed for any banking, or that perhaps the upper rotor (which is tilted into the wind) is getting more air and dominant, which from it's clockwise rotation would lead to blowback pitching you up and banking left, requiring right cyclic instead. pps. The slight left-cyclic input currently required in forward speed would logically create more pitch / upflap on the right hand side if I'm correct, but I'd think that would be less than the lift created from the Vne forward airspeed and it should also result in the top rotor also flapping up by a similar amount on the right.

TBH I've got both Republic & Oil War campaigns, but have yet to try them after especially the deployment campaign. It'd be one thing if the AI weren't necessary in the campaigns, but the way they were designed, their fuel, munitions and scouting were definititely considered as a given in the campaign design. But as it stands, their AI is lacking as it. And while DCS doesn't use contrast (yet) as method of locking targets for the Shkval, the artificial limitations from lighting weather fx and time of day are excessive from what you can see on the IT-23 vs. what it can actually lock. Combined with the other choices they made with making it single-seat autoamtion & helo dynamics, it really doesn't help selling the very competent Ka-50 to new players. BS3 news, even if just saying it's months away, would be welcome, though the patches needed to the introductory campaigns, AI behaviour and Shkval limitations are additional issues. Make no mistake, I love the helo and the FM, but it needs a LOT of selling to newcomers believing it's all borked.

In the Deployment campaign I tried earlier this year (on OpenBeta), the wingman as utterly unreliable - for scouting he'd approach way too fast after spotting threats and then only break off once engaged, and for attacking (armed with Vikhr and rockets) he'd acknowledge maybe, but not engage with any weapon systems. This is both on targets he spotted after scouting, telling him to engage my target or attempting to send datalink targets. He did choose to hover IGE in the middle of the town filled with hostiles. I wonder if the hostile Black Shark AI is more ready to engage (you or friendly ground forces)...

I believe the ABRIS and PVI-800 were developed and integrated at different times, possibly also from responses of the generals saying they wanted more automation to offload the single-pilot thing then maybe one system leapfrogged the other. But the PVI-800 is based off the Shark's inertial navigation unit, while the ABRIS is more like a GPS as it gets info more from the satellites (although it does combine it with some sensors from the Shark). If you wanted to capture coordinates from the ABRIS, either from a flightplan or because you maybe used the INFO>Search function to look up a nearby airport or town, then just remember to first go from the Menu page > Option > Setup > Units and switch the first two coordinates from the default to decimal which the PVI-800 uses. ps. if you store Target Points (Nav Tgt) on the PVI-800, you'll see those on the ABRIS as selectable 'x' icons. So there's a small overlap between the systems. Having a PVI-800 target point selected also overrides the ability to select a different datalink target.

The basics of helo flight stuff I was just replying to Reticuli. But on the Shkval, I know that when you lase (lock with the laser), and once in a while if you're slewing around wildly with a range already (when it's only fuzzy-updating) it will fire the laser, then the laser timer appears on the HUD. It seems to be lasing for this whole 3-8 seconds time (3 usually if terrain, 8-ish seconds if locking an object). If during this time something obstructs the laser, like descending beneath tree-top level or masking behind a hill, it will update the ranging with that instead. So that comes in more often if you were designating targets before a coordinated launch, quickly pop down to avoid incoming fire or you're planning trick shot things from outside line of sight. To avoid that just wait till the lasing finishes, or press laser reset before the laser measures the wrong thing. I wouldn't put it past the trees to have a 'hitbox' that's different from the billboard planes that are rendered though. Might even be that they simulated the laser firing from slightly offboard (ie. not from the literal actual centre of the Shkval camera but maybe 30cm off). If one didn't laser-lock terrain, then the Shkval doesn't have inertial guidance to prevent it slipping across the terrain or moving at a different speed from the target. Also heavy bank or yaw (even while still in the Shkval line of sight) will cause it to lose it's tracking. If it breaks lock off a moving target it'll run on memory mode and guess the target position so it'll keep drifting in that direction. For re-acquiring the saved target, did you select the datalink target type and then press DL Ingress as well (otherwise it would just bore-sight uncage, or uncage whereever your Helmet sight is pointed if that's out)?. Also if you have a Target Point selected on the PVI-800 it aims there instead of DL if I recall. I have also found that especially if you slew & lase while the laser is already firing, the range can corrupt, often ending up with a fraction of the actual distance. I have no idea whether that's an IRL feature or a bug. It only shows the wrong ranging once the laser stops firing the second time around. Not sure if it was maybe one of the above issues/cases you experienced. But all that said, I have also found the DL Ingress datalink targets to not always be accurate. Sometimes it's more accurate than other times. May be there's some bug (or IRL drift) if one changes altitude a bit from the altitude you saved it at (ie angle of the Shkval/Laser thing) that it goes out by a lot.

Bit of an old thread, but the random slewing, are you maybe pressing Uncage Shkval twice with the Helmet mounted sight off? It has a built-in scan mode where if you uncage (not lock) it twice, it starts scanning left-to-right, based on whether you slewed left or right last. That mode is pretty useless. It also doesn't have internial/ground stabilising unless you lock with the laser on, so it will drift, especially I think if you have sideslip. Random yaw could be it's returning to your last trimmed heading (ie. the heading you set it to try and hold and return to - heading hold autopilot is by default always on), it tends to weathervane by turning into wind - stronger the wind the more it does so. There's also a few occasions it'll yaw if you do a rapid break (just pitch up and keeping it from rising) or if you hover and heading hold is off it has some right yaw in it specifically. VRS can develop from anything typically under 50kph, if your descent is getting to 5m/s or more. The Mi-8 starts dropping from 3m/s onwards. Was it any of these symptoms or were you experiencing something else?

New one up on Dust causing Engine Vibration. If people are really interested I can post trackfiles for the majority of the tests, but otherwise, as stated in the vid, use the test results loosely - there's still some variability in there. One interesting find is that anti-icing, as it stands in the current OpenBeta seems to rapidly accelerate dust failure if you're really low. I can't comment any any protection it might afford higher up. Also interesting is that ambient dust haze (setting in mission planner to haze up the entire sky up to set distance/altitude) doesn't seem to affect it.