[2.9.11.4686] MAP-PPI display not (fully) drift compensated

[Stickler]

Compare the attached tracks showing an F-4E at 20,000 ft true altitude passing north to south by a carrier offset about 15 nm east from track.

In no-wind conditions, to get a precise fix on the carrier (confirmed with Pave Spike) in TGT FIND, the center of mass of the radar return has to be aimed at. After pushing FREEZE, the radar cursors (and the pod slaved to them) perfectly track the carrier.

In strong crosswind conditions from the left in flight direction (90 kts), to even get a precise fix on the carrier, the radar cursors need to be placed on the right edge of the return. After pushing FREEZE, the cursors drift away from the target in downward-right direction.

The issue occurs in the same way in OFFSET, but visualization is not as nice due to the missing pod integration.

I don't know exactly what "drift stabilized" means in the context of MAP-PPI, but I see no obvious reason why the radar shouldn't be able to compensate for the aircraft's drift in a constant-speed, constant altitude situation.

This issue is likely related to the following:

 

radar_drift_tgt_find_crosswind.trk radar_drift_tgt_find_no_wind.trk

Edited December 27, 2024 by Stickler

[Stickler]

I have noticed another issue which is possibly related.

Observe the attached tracks and associated .acmis.

The mission consists of two carriers positioned exactly on a north-south bearing, 4.993 nm apart. This results in a 303 South offset which I enter into the appropriate dial.

The first run of the mission has zero wind, with successive iterations having more and more crosswind from the left in flight direction.

Note the following: No matter the crosswind, the physical points of space at which both carriers are overflown are (within the limits of random inaccuracy) the same in the first four iterations. However, selection of FREEZE and TGT INSERT results in the pod slewing to a target point in space more and more to the right (west) the stronger the crosswind from the left (east).

If I decide to actually follow the steering provided by the roll tabs (last file "steering"), the system accurately flies me over the wrong point, which means the system really does think that the target is at a different point in space depending on the wind drift at FREEZE/TGT INSERT.

The issue occurs in OFFSET as well, but has been recorded in TGT FIND due to the ability to visualize the problem.

While this doesn't appear like a big deal at first glance, in the "very strong wind" scenario the error reaches approximately 200 ft which precludes accurate bomb delivery.

If this behaviour is realistic by all means do not change it, but it doesn't seem immediately plausible to me that the wind drift the aircraft is experiencing should have any effect on WRCS offset handling.

Tacview-20241227-175424-DCS-vip_offset_wind.trk.zip.acmi Tacview-20241227-175257-DCS-vip_offset_no_wind.trk.zip.acmi Tacview-20241227-180032-DCS-vip_offset_very_strong_wind.trk.zip.acmi Tacview-20241227-175635-DCS-vip_offset_strong_wind.trk.zip.acmi Tacview-20241227-180520-DCS-vip_offset_very_strong_wind_steering.trk.zip.acmi vip_offset_no_wind.trk vip_offset_very_strong_wind.trk vip_offset_very_strong_wind_steering.trk vip_offset_wind.trk vip_offset_strong_wind.trk

Edited December 27, 2024 by Stickler

[Stickler]

While trying to find a workaround for this issue I was able to reproduce what the underlying problem actually is: The along track cursor uses a zero azimuth reference that is neither the aircraft's track nor the aircraft's heading.

For example, with the aircraft flying a true course of 360° at 500 KTAS in a crosswind from 270° true at 97 knots, the required wind correction angle (WCA, or crab angle) is -11°, which translates into a heading of 349° true to stay on course.

In TGT FIND, to make the Pave Spike look directly at the target in WRCS ACQ, the radar cursors need to be placed 11° RIGHT of the target, which equals the WCA with an inverse sign. Alternatively, you can use rudder (trim) to take out the crab while moving/freezing the cursors ON the target, but this will of course screw up your track. In the above example, this doesn't work though since the required correction exceeds rudder authority.

If you manage to actually point the radar at the target using this workaround, the TGT FIND/OFFSET steering will accurately guide you to it or any offset you entered.

If you start with the cursors zeroed/reset and press the along track wheel to move the cursor straight up on the radar scope, the point the pod is looking at moves away from the aircraft along the 338° true bearing in the above example. I would expect either the 349° true bearing if the cursor zero azimuth is the aircraft's heading or 360° true bearing if the cursor zero azimuth is the aircraft's track.

Even if the design choice is made not to model drift stabilization, I cannot see the logic in the zero azimuth reference of the radar SCREEN being the aircraft's heading and the zero azimuth reference of the radar CURSORS being the aircrafts heading plus the WCA (or the aircraft's track plus the WCA times two), so I strongly suspect we are looking at a bug (possibly a sign error in the code).