reported Low HUD refresh rate for LTWS L&S and DT2 targets

I understand the low refresh rate of the target's position and direction (because of RWS scan volume), but the HUD is absolutely useless right now when doing any kind of maneuver. If a target is detected, the HUD box for L&S target refreshes at the same time as the radar, which does not make any sense.

The HUD should have a much faster refresh rate, since the attitude and velocity of our own aircraft updated much faster. This way, the target box should stay (or be extrapolated from the last velocity track) in a point in space, the HUD adjusting at the normal refresh rate for own aircraft maneuvers, but at a low (RWS) refresh rate for target aircraft maneuvers.

Currently, the target box is static with respect to the HUD FOV (updated once per target measurement), whereas it should be static (or with a velocity extrapolated from measurement) with respect to the world's coordinates, with the target world coordinates updated at a lower refresh rate.

Here's a quick drawing of what I'm trying to say:

i was thinking about making the same thread

+1

i hope thats not how it works in the real aircraft because its quite silly when you change heading

Low HUD refresh rate for LTWS L&S and DT2 targets

Same here. It’s best to leave LTWS off. I’ve been shot down numerous times because I can’t even get the steering cue inside the reticle. I turn to the left. TD box appears off to the right. Turn to the right, TD box back left. Turn back left, oh look a death stick.

Sent from my iPhone using Tapatalk Pro

I agree with OP. There is no logic behind the TD box not updating its position with respect to the HUD FOV using the HUD's refresh rate.

The HUD and the radar are two separate systems. As far as the HUD is concerned, the TD box is the same regardless of the radar's update rate and it should update with respect to the HUD, at its own refresh rate.

The way I see it (which is the same as the OP), the radar sends a target position to the HUD, the HUD puts a TD box over it and keeps it "world stabilized" until the next radar update, but still updates it at full refresh rate to correct for ownship maneuvers.

I agree. The HUD TD box should follow the last known position of the target. So if I turn left the TD box should move right, following the last known position even if it’s old. Instead, it currently follows an X and Y position on the HUD. Meaning ownship movements make the TD box lie to the pilot about the targets last known position.

Also, this isn’t just for LTWS, it occurs with the HARM as well. And probably anything else added with a low update rate.

EDIT: After doing some test flights, I've come to realize that the RWR symbols have the same issue. Instead of associating the RWR symbol to a azimuth relative to the aircraft, it associates the RWR symbol to a clock position. Thus, when you turn the RWR symbol doesnt continue to follow the bearing.

Example:

- My heading: 270; Nails 12 oclock on RWR. Thus, the enemy radar is bearing 270 from my aircraft.

- Hard bank left. My new heading is 180. Nails is still 12 oclock. Thus, my RWR is trying to lie to me and tell me the enemy radar is 180 from me. It eventually corrects itself, but only after re-detecting the emitter.

Instead, what it should be doing is associating the RWR symbol to a bearing of 270 and not a relative clock position. Thus, when I turn the RWR symbol follows the 270 position on the EW page/ADU.

Considering that the RWR data is sent to the mission computer and used with other sensors and the HARM, it makes sense that it would follow a bearing and not a relative clock position.

Good posts. It would be nice to hear from the devs if they agree.

I agree. The HUD TD box should follow the last known position of the target. So if I turn left the TD box should move right, following the last known position even if it’s old. Instead, it currently follows an X and Y position on the HUD. Meaning ownship movements make the TD box lie to the pilot about the targets last known position.

 

Also, this isn’t just for LTWS, it occurs with the HARM as well. And probably anything else added with a low update rate.

 

EDIT: After doing some test flights, I've come to realize that the RWR symbols have the same issue. Instead of associating the RWR symbol to a azimuth relative to the aircraft, it associates the RWR symbol to a clock position. Thus, when you turn the RWR symbol doesnt continue to follow the bearing.

 

Example:

 

- My heading: 270; Nails 12 oclock on RWR. Thus, the enemy radar is bearing 270 from my aircraft.

 

- Hard bank left. My new heading is 180. Nails is still 12 oclock. Thus, my RWR is trying to lie to me and tell me the enemy radar is 180 from me. It eventually corrects itself, but only after re-detecting the emitter.

 

Instead, what it should be doing is associating the RWR symbol to a bearing of 270 and not a relative clock position. Thus, when I turn the RWR symbol follows the 270 position on the EW page/ADU.

 

Considering that the RWR data is sent to the mission computer and used with other sensors and the HARM, it makes sense that it would follow a bearing and not a relative clock position.

What happens when the radar source is moving - such as an aircraft... it would then be lying to you again. Cant win unless you do some unrealistic tracking of the position without an actual source.

For search radars, they sweep at a certain interval, and it is then, when it sweeps over the aircraft, that the RWR will update.

When you are locked, and a tracking radar is used, or the radar switches to single target track mode then that's a different story because your RWR should be continuously getting a source signal, but I am pretty sure the RWR doesn't have latency then... again, which is what you would expect.

Similarly with LTWS the position will only update when the radar sweeps over it. Sure it could make some guesses on where the aircraft might be based on its last return/track... but that could be problematic close in.

If you want less latency , narrow the azimuth, decrease the number of bars. it will update more frequently.

What happens when the radar source is moving - such as an aircraft... it would then be lying to you again. Cant win unless you do some unrealistic tracking of the position without an actual source.

 

 

 

For search radars, they sweep at a certain interval, and it is then, when it sweeps over the aircraft, that the RWR will update.

 

When you are locked, and a tracking radar is used, or the radar switches to single target track mode then that's a different story because your RWR should be continuously getting a source signal, but I am pretty sure the RWR doesn't have latency then... again, which is what you would expect.

 

Similarly with LTWS the position will only update when the radar sweeps over it. Sure it could make some guesses on where the aircraft might be based on its last return/track... but that could be problematic close in.

 

If you want less latency , narrow the azimuth, decrease the number of bars. it will update more frequently.

You dont understand what were saying.

We're not talking about the radar or radar tracks. Were talking about the HUD and RWR symbols. The displayed symbols should move smoothly across their given display if I turn the aircraft.

ie even though my Radar track or RWR only updates once in awhile, the HUD/RWR symbol itself should move continuous (or near continuously) because it is associated with a azimuth (and elevation for the TD box) and not a relative clock position.

Meaning the TD box should be able to move if the radar track hasnt updated yet. The TD box should smoothly to follow that last known position in azimuth and elevation.

Right now, it gets locked in position relative to the display window. Meaning that if the TD box is in the upper right corner of the HUD, and i make a hard turn, the TD box will still be in the upper right corner of the HUD.

Same is true for the RWR.

They need a track :D

All the issues below are interrelated. As previously posted, this is not about low update rates for the sensors. This is about the TD box and RWR symbols not tracking a position as I move my aircraft. Even if using a low update rate sensor (like radar in LTWS), the HUD TD box should continue to follow the last known position.

Please read below. Tracks are attached.

Radar TD Box issue:

HARM TD Box issue:

RWR Symbol issue:

Regardless of track updates from the sensor, the display for the:

Radar TD Box should continue to track the last known target position in azimuth, elevation and range.

HARM TD Box should continue to track the last known target position in azimuth and elevation.

RWR should continue to track the last known position in azimuth.

i.e. My own maneuvers should not move the TD Box off the target.

IMO, these issues make the Radar, HARM and RWR 'feel' choppy and scatters the target data. I believe fixing this would lead to a smoother, more realistic and enjoyable experience using these systems. Not just on this aircraft but on other upcoming modules as well.

RadarHUD.trk

HARMandRWR.trk

Excellent break down. Thank you for accurately documenting this problem. This is exactly my observation as well.

Sent from my iPhone using Tapatalk Pro

Trackfiles aren‘t missing anymore, time to update the bug report title.

I won't list the source (although it's not classified, I'm following forum rules), but I did just read that the RWR we have in the Hornet* is indeed connected to the INS to enable accurate emitter azimuth display during high G maneuvers.

Although this is more about the RWR refresh rate itself, it's part of the same problem.

*We should have the AN/ALR-67(V)3, since this one has the ability to interface with the HARM and it fits better chronologically; the above might be true for the (V)2 version also.

DCS 2.5.5.32299 Open Beta has improved LTWS TD box (though if one rapidly maneuvers up and down in pitch you can still see the TD box struggling to keep up).

But the HARM TD box and RWR symbols are still suffering from the issue.

See attached track

HARMandRWR.trk

HARM TD box still moves around relative to aircraft maneuvers, rather than following the angle in space it detected the target.

Hopefully this gets some love soon.

Aye. The RWR bearings would be especially helpful as well.

confirming again.

the primary LTWS target is fixed but the secondary LTWS target, HARM TOO target and RWR sources still act wrong. since the primary LTWS target's behaviour was fixed, i imagine making the others behave the same way shouldnt be that difficult.

All trackfiles in LTWS are working. The DT2 on the HUD and trackfiles on the page in general do seem to look a little choppier now though; I think it's got to do with the (already reported) bug of donor info not showing with a designation or when under cursor; they seem to be in their own world when designated or cursored over vs. not, and when not they appear choppier on the radar.

any update on this?

DT2 and HARM TOO target boxes still do not behave correctly in 2021.

L&S was corrected however.