Jump to content

AG Radar defined SPIs is way of target


b0bl00i

Recommended Posts

After flying with my buddy yesterday we both noticed that using the ground radar for adding SPIs used for targeting is very unreliable.

We both targeted an airplane on ground at an airport, click the TGT button to see in detail what we defined, the TGP is now looking 2-300 meters off target. JDAMs and other weapons we tried to launch at the target also ended up way of target.

Also, the HUD symbology does not correlate with what we define as SPI with the AG radar.

Anyone else noticed this? Seemed to work a lot better before the last patch, probably this is a new bug (or several)

Link to comment
Share on other sites

I think I've figured it out at least in some situations. The frozen radar display has skewed imagery to cursor positional relationship if the imagery is frozen after a slew but before a new radar image. The numbers are always correct but the picture may or may not be accurate to the numbers. This is related to the "snapback" behavior the radar imagery has when releasing the cursor switch as the imagery slews on the previous frame are reverted.

Watching the imagery behavior one can see there is a period between slewing ceasing and the imagery matching cursor position. There is a window of time where the cursor displays over where the slewing started falsely which does not represent the actual cursor position. This window closes when the next radar image is processed and the cursor visible position again matches the cursor actual position. If the pilot commands a radar imagery freeze in this inaccuracy window then that inaccuracy is frozen as well.

F16 GM snapback.trk

Link to comment
Share on other sites

16 hours ago, Frederf said:

I think I've figured it out at least in some situations. The frozen radar display has skewed imagery to cursor positional relationship if the imagery is frozen after a slew but before a new radar image. The numbers are always correct but the picture may or may not be accurate to the numbers. This is related to the "snapback" behavior the radar imagery has when releasing the cursor switch as the imagery slews on the previous frame are reverted.

Watching the imagery behavior one can see there is a period between slewing ceasing and the imagery matching cursor position. There is a window of time where the cursor displays over where the slewing started falsely which does not represent the actual cursor position. This window closes when the next radar image is processed and the cursor visible position again matches the cursor actual position. If the pilot commands a radar imagery freeze in this inaccuracy window then that inaccuracy is frozen as well.

F16 GM snapback.trk 578.48 kB · 2 downloads

This is definitely an issue, but I'm seeing a more subtle issue as well in my testing. Designation accuracy seems to decrease once angle off exceeds 20 degrees. I can't find anything in the MLU docs saying this ought to be the case (though the MLU doc does say to slew as soon as possible after the image appears, though it doesn't say why. With the "snapback" this certainly shouldn't be done in DCS right now). I'm still testing this and will come up with a track if I can repeat it and nail it down.

Link to comment
Share on other sites

6 hours ago, LastRifleRound said:

 (though the MLU doc does say to slew as soon as possible after the image appears, though it doesn't say why.

Wild guess, there is extrapolation going on within the targetting software to calculate where you placed the cursor, because the image is out of date while the jet keeps moving.  The longer you wait, the less accurate the extrapolation becomes. 

"Subsonic is below Mach 1, supersonic is up to Mach 5. Above Mach 5 is hypersonic. And reentry from space, well, that's like Mach a lot."

Link to comment
Share on other sites

On 10/30/2021 at 11:21 PM, Machalot said:

Wild guess, there is extrapolation going on within the targetting software to calculate where you placed the cursor, because the image is out of date while the jet keeps moving.  The longer you wait, the less accurate the extrapolation becomes. 

I know this exists in azimuth when it comes to DBS calcs, but the inaccuracy of the calculation running in reverse doesn't change over time assuming the aircraft has done a good job keeping its own position. The only thing I could guess is the documentation assumes an unassisted INS.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...