investigating Radar can still lock targets while off

[Maverick806]

The F-16Cs radar can acquire targets when NO RAD is displayed on the HUD and HMCS

The simplest way to test is:

1. Enter Dogfight Override Mode
2. Press TMS FWD to enter BORE mode
3. Press and Hold TMS FWD - Note HUD and HMCS both say NO RAD.
4. Hold the HMCS Cross over a target within range for a couple seconds. 
5. The radar will lock the target while you're still holding TMS FWD.

This causes issues if you're trying to lock a specific target out of a group and the radar just grabs the first one it passes over

This even works if your F-16 is on the ground (although the radar stops tracking immediately)

F16_NO_RAD_Ground.trk F16_NO_RAD_MultiTarget.trk F16_NO_RAD_SingleTarget.trk

[darkman222]

Its been like that for quite a while. Thanks for bringing that up. It is especially annoying if you want to pick one target that is on the outside of a group .

[darkman222]

First off, I know it might be 2 different, but closely related issues here. As they both together lead to an absolutely unreliable JHMCS in dogfights, I wanted to start a thread about both at once. If you dont look at them both, you might not get why the JHMCS is behaving as it does at the moment. The lesser of the conditions bewlo are met, you might even have the impression JHMCS is working correctly, but start wondering why it sometimes does not work as it should.

 

Reproduction, TMS up "no rad" with radar still emitting :

-DGFT mode

-TMS up to get the boresight cross in the HUD

-TMS up and hold to get the JMCS boresight cross and the radar to be slewable by the JMCS

-while TMS up pressed, it shows "no rad" , but in fact the radar is active all the time, as you can see, while displaying "no rad" the JHMCS boresight is locking the target. Note that I dont let go of "tms up". The lock happens whith "tms up" depressed and showing "no rad" all the time.

You can even bring the JMCS cross back to the HUD with "no rad" showing and then the HUD boresight cross locks the target too.

Video:

Track file attached: "tms up hold shows no rad but radar active - single target.trk"

 

This issue leads to the next problem:

Reproduction:  Put a line of jets flying in a line at same altitude in front of your jet. Try to lock the jet on the right with JHMCS. It will always lock the jet on the very left side.

See the split screen video. What happens is because TMS up "no rad" still emits radar energy, it locks the first target it sees. But there is the other thing that comes into play. It always wants to start from the left. So you always end up with the most left target. Watch the the in cockpit video first. Then watch what the B-sweep Radar Azimuth indicator (Bottom of Radar MFD) does. The only chance to lock a target to the right is actively guide the boresight away from the left side, guide it above all the other aircraft, then bring it down to the aircraft on the right side.

Also one thing to condsider. Why does the radar always need to start a new sweep from the left? Every TMS up seems to bring it to a "fresh start" from the left side. Just as a side note. This seems to waste time in a dogfight environment for which this mode was designed for. It rather seems like programming wise it initates a reset restart of the radar script.

Video:

Track file attached : "tms up locks first target azimuth left.trk"

 

This the B sweep radar azimuth indicator I am talking about. Always wants to restart from the left:

tms up hold shows no rad but radar active - single target.trk tms up locks first target azimuth left.trk

Edited March 4 by darkman222

[Maverick806]

It's already being investigated

 

[darkman222]

Nice. It did not seem to get a lot of attention though. I was only one who reacted to it more than 3 months ago. I just forgot about it.

And the investigations for something that seems quite obvious, like a "no rad" still being able to lock targets are still ongoing. Oh well...

Edit: Threads got merged.

Edited March 5 by darkman222

[WHOGX5]

On 3/4/2024 at 1:23 PM, darkman222 said:

First off, I know it might be 2 different, but closely related issues here. As they both together lead to an absolutely unreliable JHMCS in dogfights, I wanted to start a thread about both at once. If you dont look at them both, you might not get why the JHMCS is behaving as it does at the moment. The lesser of the conditions bewlo are met, you might even have the impression JHMCS is working correctly, but start wondering why it sometimes does not work as it should.

 

Reproduction, TMS up "no rad" with radar still emitting :

-DGFT mode

-TMS up to get the boresight cross in the HUD

-TMS up and hold to get the JMCS boresight cross and the radar to be slewable by the JMCS

-while TMS up pressed, it shows "no rad" , but in fact the radar is active all the time, as you can see, while displaying "no rad" the JHMCS boresight is locking the target. Note that I dont let go of "tms up". The lock happens whith "tms up" depressed and showing "no rad" all the time.

You can even bring the JMCS cross back to the HUD with "no rad" showing and then the HUD boresight cross locks the target too.

Video:

Track file attached: "tms up hold shows no rad but radar active - single target.trk"

 

This issue leads to the next problem:

Reproduction:  Put a line of jets flying in a line at same altitude in front of your jet. Try to lock the jet on the right with JHMCS. It will always lock the jet on the very left side.

See the split screen video. What happens is because TMS up "no rad" still emits radar energy, it locks the first target it sees. But there is the other thing that comes into play. It always wants to start from the left. So you always end up with the most left target. Watch the the in cockpit video first. Then watch what the B-sweep Radar Azimuth indicator (Bottom of Radar MFD) does. The only chance to lock a target to the right is actively guide the boresight away from the left side, guide it above all the other aircraft, then bring it down to the aircraft on the right side.

Also one thing to condsider. Why does the radar always need to start a new sweep from the left? Every TMS up seems to bring it to a "fresh start" from the left side. Just as a side note. This seems to waste time in a dogfight environment for which this mode was designed for. It rather seems like programming wise it initates a reset restart of the radar script.

Video:

Track file attached : "tms up locks first target azimuth left.trk"

 

This the B sweep radar azimuth indicator I am talking about. Always wants to restart from the left:

tms up hold shows no rad but radar active - single target.trk 754.21 kB · 3 downloads tms up locks first target azimuth left.trk 988.71 kB · 3 downloads

 

Regarding your second issue, I know I have personally reported that as a bug several years ago at this point, but I honestly cannot be bothered to go that far back into my post history to find that thread. Suffice to say, the issue is that the bore ellipse in the JHMCS should follow true line-of-sight of your radar (this is true for the HUD bore cross as well), however, at the moment in the DCS F-16C the ellipse is simply drawn in the center of the JHMCS irregardless of where the radar is actually pointing. When you TMS UP to slew the radar to your JHMCS, it moves the radar from pointing straight forward to pointing where your head is looking, even though this isn't shown by the ellipse, resulting a lock on whatever is inbetween that path of travel.

In the video below you can see the JHMCS in action at 3:29. As you can see, if you step through the video frame by frame using the "." and "," keys, you can see the ellipse instantaneously appear from one frame to the next where the head is looking, indicating that it initially won't lock anything while moving from looking straight in the direction of your aircraft to looking in the direction of your head, and once it's slewed to your head, it follows your head movements as good as it can (you can see how imperfect and laggy the FCR movements are). You can also see the ellipse "stick" to the target aircraft while it attempts to get a lock, and then it transitions to a square once a steady lock has been aquired.

In the second video which shows the HUD symbology, right at the very start of the clip, you can see the "NO RAD" disappear right as he slews his radar to his JHMCS. A couple of frames later, the bore cross instantanously appears in the top left of the HUD, indicating the exact same thing as the first video, that the radar will not lock anything while transitioning from pointing in the direction of the aircraft, to pointing in the direction of the JHMCS. After this, the bore cross on the HUD will follow radar line-of-sight from this point onwards, just like the ellipse will follow radar line-of-sight in the JHMCS.

As you've probably noticed, neither of these behaviours are present in DCS. If you turn off HUD blanking and look towards your HUD with the JHMCS in dogfight mode with the radar on, the HUD bore cross and JHMCS ellipse should be perfectly overlayed and following each others movements, which currently isn't the case in DCS. Instead, with their current implementation, the HUD bore cross will always point in the direction of your aircraft irregardless of where the radar is actually pointing, and the JHMCS ellipse will always point in the direction of your head, irregardless of where the radar is actually pointing. Also, the radar will lock anything in its path when slewing itself towards your JHMCS LOS, which shouldn't be the case as it makes the radar close to useless in a furball if it just arbritrarily locks anything it may come across, rather than what the pilot actually wants to lock up.

 

[Yaga]

The FCR in RWS set to Quiet or Silent will also detect new bricks despite No Rad displaying. Bricks can be tracked in SA or STT with FCR set to Quiet or Silent for a moment before being lost and the track position is accurate until it is dropped.

Similarly, new bricks are regularly detected outside the current scan volume regardless of radar emitting or not.

Sometimes other client's RWRs see the radar emitting when in Quiet or Silent, both inside and outside the current scan volume.

This is stupid and needs to be fixed.

Sent from my Pixel 3a using Tapatalk