[2.9.7.59074 MT] Unable to successfully execute Dive-Level Maneuver (possible Dive Toss issue)

[Stickler]

Please reference the attached track.

My intent is to release a pair of Mk-82 LDGP bombs on a sea level target using the Dive-Level Maneuver with a release at 450 KTAS and 3000 ft MSL (= 3000 ft ATL).

According to the in-game bombing calculator, the required ballistic coefficient is 1.04, which I input manually into the appropriate window in the back seat.

As should be apparent from the track, I am achieving lockon and the desired release parameters quite accurately before hitting the nominal release point at 10152 feet (1.67 nm) from the target.

However, the bomb releases slightly beyond the target to impact 1.7 nm further downrange (that is, the calculated bomb range itself is accurate).

I am aware that I am slightly outside the 25,000 ft range limit for Dive Toss at pickle, however I repeated the test with a pickle at 3 nm with the same approximate results.

If it seems advantageous to merge this thread with the following, feel free to do so, however in that thread a similar issue was traced back to operator issue which in my case I cannot seem to find (do not hesitate to call out any errors on my part though).

dttest.trk

Edited August 18, 2024 by Stickler

[Zabuzard]

A few things to mention after watching the track:

* Let the aircraft walk the pipper into the target, dont hold it there with the stick
* Wait a second after hearing the beep before you start your maneuver
* You probably have to dive a bit steeper before you level, so that you level out before intersecting the radar centerline from the picture you shared
* When releasing at level and expecting pinpoint accuracy (hitting a ship without ripple), it is crucial that you fly your parameters even closer. Your pitch was rather 1-2°, airspeed and altitude were slightly off as well - should only cause the drag coeff to differ by 0.01 in this case though...

That said, unless it was the intersection issue mentioned earlier, the track looks a bit sus indeed. I am forwarding it for investigation, thank you!

Also, very good track quality

Edited August 19, 2024 by Zabuzard

[Stickler]

Made a track that satisfies most of your requirements.

Intended release parameters were 300 KTAS at 1000 ATL with a coefficient of 1.02 (the default).

Waited about 1 second after hearing the beep.

Made sure I was in a release position before the aircraft intercepted the radar line at pickle and before reaching bomb range:

• I rounded out 6000 ft slant range from the target, with the radar line at release intersecting the flight path at around 2900 ft slant range, so plenty of buffer.
• I undershot my target of 1000 ft ATL by about 200 ft, but the bomb range at the actual 800 ft ATL is calculated at 3500 ft plan range, so bomb release prior to target overflight was physically possible.

The result was qualitatively the same: A release about 2.3 nm beyond the target. A 800 ft ATL release would have required a coefficient of 1.03, but this - as you said - should not cause a miss of such magnitude.

I am a bit confused about your instructions for debugging though, hoping for a clarification to enhance my understanding of how DT works (or how Heatblur has chosen to implement it).

This is the relevant part of the DT description from TO 1F-4E-34-1-1:

What I take from this description is that the main function of the pipper (the other being to assist in compensating for lateral wind drift) is to aim the radar so the WSO can achieve lockon at the correct point on the ground. Why would walking the pipper onto the target and not holding it steady improve accuracy, especially given the instructions state to stabilize the pipper on the target?

I also understand that the only function of the bomb release button is to cause the radar measured slant range to be entered into the WCRS at the moment of pickle. Thus, as long as there is a valid lock, and disregarding lateral guidance by the roll tabs, where the pipper is in relation to the target when the bomb release button is pressed should be irrelevant. How would waiting 1 second after pickle improve DT accuracy?

Why must the radar line at pickle not be passed prior to reaching bomb range if lockon is not required to be maintained after pickle?

dttest2trk.trk

Edited August 28, 2024 by Stickler

[Stickler]

Figured out the reason for the problem, and it can actually be seen in both tracks: Jester does not lock the ground beneath the pipper, but the ground much further downrange. You can easily see the ground return that Jester is supposed to lock (quite lengthy in the first track, but quite well gained out in the second), but the range gate after lock is nowhere near the return.

Compare the attached track where I lock the target myself from the WSO seat. Bomb accuracy is subsequently very high; the error can be attributed to imprecise parameters at release.

This raises the question why there isn't a significantly higher number of people reporting problems with DT since Jester not locking affects all release sub-types of DT, not just Dive Level.

dttest4.trk

Edited August 31, 2024 by Stickler

[Stickler]

I believe I found the solution. It seems that binding the [WSO] Antenna Hand Control Slew X/Y axes (either one or both of them, not sure) prevents Jester from locking the ground return, but will instead cause him to lock whatever is underneath the cursors at the time of attempting the lock. I stumbled upon this per accident when I realized that Jester was unable to lock air returns in Boresight as well, instead locking some other point (the one underneath the cursors).

Setting a huge deadzone to make sure that no unintentional inputs are made to the axis does not solve the issue. I had to completely unbind the axes. Jester was then able to lock the ground return and I am now getting fairly accurate deliveries.

Haven't tested this enough to be able to say with confidence that DT (especially Dive Level) works as intended, but the principal issue I had can be traced back to the bound axis.

[Zabuzard]

Perhaps merely having the axis bound lets it constantly send its position to DCS whenever Jester tries to move it elsewhere, constantly resetting it back.
I doubt its the case for everyone though. I also have it bound in order to control Pave Spike, but dont experience any issues with ground locks.
Annoying...

[Stickler]

Found a workaround. If you assign a modifier to the axis commands in question - for example a joystick button configured as a switch - that causes the axis to only be active if the switch is ON, Jester will lock the ground just fine.