[ALREADY REPORTED] "Bouncy" target bracket on HUD

[Greyman]

When i lock a target, using Radar, the square bracket that appears on the HUD does not seem to be stable and appears to follow my own joystick movements, rather than stay over the target aircraft. It appears to return to where it should be on the HUD, ie over the target, when i point my nose at the target aircraft.

 

I did save a track, but on replaying it, the target aircraft did not get locked, so there didn't appear to be any point.

 

By the way, if you need to reproduce, i was flying RedKite's refuelling mission, starting behind Texaco and then heading straight for Shell, using TACAN channel 22Y,

[Sephroth]

Usually when I see this I'm in SAM mode. I don't have a full lock. Once I go to a full lock it's smooth.

 

Sent from my SM-N975U using Tapatalk

[Greyman]

You are right, in that it definitely becomes more stable with a full lock, but it feels like it is still trying to follow the aircraft's nose, but is more restrained in some way, than it was in SAM mode.

 

If this is how it is in RL, then fine, but it just feels a little odd.

[dax]

I noticed the same behavior, and I guess it's probably normal.

In RWS mode, the target is not illuminated continuously as in STT mode. Hence the target location is only updated when the antenna beam illuminates it.

[Greyman]

Now that does make some sense, if the square image stays where it is until a new scan redraws it back where it should be. If the aircraft moves relative to the target between scans, this is probably what it would look like.

 

So does a fully locked target get scanned more frequently then, as that would explain the smaller "bounces"?

 

Thanks both

[dax]

Yes, in STT mode, the radar beam is focused on a single target and tracks it, in order to get continuous updates.

The drawback is that you then become blind to potential other targets.

[Frederf]

I noticed the same behavior, and I guess it's probably normal.

In RWS mode, the target is not illuminated continuously as in STT mode. Hence the target location is only updated when the antenna beam illuminates it.

 

Not entirely true, SAM or STT or TWS develops a track. A track is a mathematical object which is smoothly interpolated at each burst of update information. It is this track and not the detection data that is displayed on HUD and MFD. And the track exists at all times, not just when new data is available. As long as the target motion is uniform updates five times per second or once every 5 seconds are indistinguishable by viewing the display. As information about the track grows it's not just linear interpolation but its first and might be second derivative.

 

As for RWS "bricks" these are memorized and displayed according to their position in the Earth coordinate system not the airframe coordinate system. For example if a contact is detected only once 2 degrees left of nose, 10 miles then it is memorized as existing at some place on Earth. If the pilot drives the airplane in S-turns he won't see the brick remain fixed on his display like it was drawn there with a pen on the screen. Instead the brick will slide right when he turns left and slide left when he turns right. This motion of the contact on the display will happen with all the smoothness and frequency of the ownship INS's knowledge of attitude and position.

[Greyman]

So whereas @dax post would explain what might be causing the "bounce" your post would suggest that the square bracket should not move like that at all. If that is the case then it looks like this will need to be addressed, at some point.

[dax]

Not entirely true, SAM or STT or TWS develops a track. A track is a mathematical object which is smoothly interpolated at each burst of update information. It is this track and not the detection data that is displayed on HUD and MFD. And the track exists at all times, not just when new data is available. As long as the target motion is uniform updates five times per second or once every 5 seconds are indistinguishable by viewing the display. As information about the track grows it's not just linear interpolation but its first and might be second derivative.

 

Thanks for the detailed comment! I didn't want to write a long story yesterday... ;)

 

But even if track is extrapolated, and whatever the interpolation order, some error will remain. For 1st, 2nd or 3rd order, the speed, acceleration, or rate of change of the acceleration will have to remain constant for the interpolation function to extrapolate position correctly. And the higher the order, the longer parameters have to remain constant. It's very unlikely to happen in a dogfight.

That said, as I don't know neither the exact behavior of the radar, nor the implemented one, there may still have an issue in the DCS implementation. That's why I wrote "probably" in my first post.

A good test would be to track (but not in STT) a target flying straight at constant speed and check if these big bounces are still there. If yes, there may be indeed an implementation issue.

[Ramsay]

When i lock a target, using Radar, the square bracket that appears on the HUD does not seem to be stable and appears to follow my own joystick movements, rather than stay over the target aircraft. It appears to return to where it should be on the HUD, ie over the target, when i point my nose at the target aircraft.

 

The radar bug is the same as this Hornet one, reported in April :

 

https://forums.eagle.ru/showthread.php?p=3895048#post3895048

 

IRL the radar tracks a point in 3D space (azimuth and elevation) and the HUD's 'target designator box' movement is stabilised with respect to the artificial horizon, pitch ladder, etc.

 

AFAIK the 'target designator box' might have a small amount of 'jitter' as it's position is updated with each radar sweep but shouldn't jump around as seen in DCS unless the target is close/manoeuvring.

 

In DCS's F-16C the 'target designator box' is stabilised with the aircraft datum and when you pitch up, it will move up with the aircraft, if you hold this new pitch angle, the target position on the HUD is updated on the next radar sweep and returns to it's old position (relative to the horizon).

 

As well as effecting the HUD, it effects the Hornet's RWR and HARM tracking.

 

I have to admit to being disappointed to see this 'major' radar bug carrying over to the F-16C and that there's been no apparent progress after 6 months.

 

Tested DCS Open Beta 2.5.5.38040

Edited October 20, 2019 by Ramsay

[falconbr]

Maybe this is the same thing...

 

https://forums.eagle.ru/showthread.php?t=251248

[Ramsay]

You are right, in that it definitely becomes more stable with a full lock, but it feels like it is still trying to follow the aircraft's nose, but is more restrained in some way, than it was in SAM mode.

Switching from SAM to full STT lock increases the target's update rate, which masks the underling issue (the target box is wrongly stabilised to the aircraft datum, rather than a position in 3D space).

[Tomcat84]

Frederf is correct. This should not be happening. But from the other thread it seems like ED has reached the same conclusion so hopefully they will fix it soon.

[launchpad72]

Correct, when in missile mode it bounces left and right across the screen....