AWG-9 apparently drops tracks when looking away from contacts

[captain_dalan]

Hey guys, this is a question and potential bug report (if the behavior isn't intended). A short video follows. When looking away from the bandits after Jester sorted them out and the radar built tracks for them, especially if banking away slightly but still apparently inside radar gimbals, AWG-9 would sometimes drop the tracks, just like long ago it would drop STT locks. Is this a bug or a feature of the radar? And if the latter, how do we counter it except for running straight for the bandits?

The video:

The tackview:
Tacview-20221204-175352-DCS-F-14A_IA_Marianas_BVR_JA11 Mk60C.zip.acmi

[near_blind]

Are we talking about the behavior at 0:43? If so, what was the radar commanded to do there? It almost looks like PAL was briefly selected. 

 

If that's the case, entering any of the pulse modes or RWS will instantly clear any tracks you might have.

[captain_dalan]

19 hours ago, near_blind said:

Are we talking about the behavior at 0:43? If so, what was the radar commanded to do there? It almost looks like PAL was briefly selected. 

 

If that's the case, entering any of the pulse modes or RWS will instantly clear any tracks you might have.

Yep, 0:43-0:46.
I didn't give any commands, either PAL, PLM, or shortcut for a Jester command. i was just trying to build some offset, like i usually do when i accelerate before launching. The targets were too far away for any such attempt anyways. Though, now that you mentioned it, could it be that some weird part of the Jester logic kicked in, and he changed the radar mode on his own?

This is fairly easy to reproduce really, just wait for the tracks to build, and then gently turn away from them. It also appears to happen only the first time around. Later on, if you pick them up again and let Jester/AWG-9 sort them out and build track, they won't drop if you turn away.

[Spurts]

could rule out jester being the cause by testing with a human RIO

[near_blind]

Other question would be are you running any mods that effect Jester? AIRIO, etc.

[captain_dalan]

5 minutes ago, near_blind said:

Other question would be are you running any mods that effect Jester? AIRIO, etc.

No mods, except for custom skins (some made by me) and A-4 and T-45. 

1 hour ago, Spurts said:

could rule out jester being the cause by testing with a human RIO

That's actually a very good idea!

[draconus]

15 hours ago, captain_dalan said:

I didn't give any commands, either PAL, PLM, or shortcut for a Jester command.

Ghost presses from your HOTAS?

What mission is this from?

[near_blind]

It looked like the Dragons Tooth BVR instant action on the Marianas.

I flew it and didn't see any issues with the radar snapping off or dropping tracks without reason. I dragged the contacts from one gimbal to the other

[captain_dalan]

17 hours ago, draconus said:

Ghost presses from your HOTAS?

What mission is this from?

Not an impossibility, but it would happen more randomly if it was so, and there seems to be a method to this. Also, PAL and PLM are mapped to my throttle buttons. And once i punch in blower i leave it alone. My Jester shortcuts are mapped to my keyboard, and they only involve TID orders.

13 hours ago, near_blind said:

It looked like the Dragons Tooth BVR instant action on the Marianas.

I flew it and didn't see any issues with the radar snapping off or dropping tracks without reason. I dragged the contacts from one gimbal to the other

It's my own modification of that mission to include Charlie Phoenixes, but the mission isn't an issue, i can recreate it on any mission, including vanilla instant actions. Here's some from the Persian Gulf BVR mission. In the first 2 cases, the radar reacquires and continues tracking, but in the third one it doesn't:
 

It appears the issue is more likely to appear near the edge of the radar cone. Also, not sure, but switching TID to 50 mile scale may play a part? I also include two tracks as short as possible, for all those are worth these days:
 

track lost and recovered.trk track lost and not recovered.trk

Edited December 7, 2022 by captain_dalan
Adding tracks

[near_blind]

The only behavior that seems like it might be repeating it on my end is if there are no healthy tracks that exist both within the scan volume and the TID display area. I.E. Turning such that a track centroid is dragged off either side of the TID will cause a TWSA scan volume to snap back to the center. I don't know if that's a bug or not. 

[Callsign JoNay]

Maybe try turning on the r.ctrl + enter controls overlay so you can see exactly what modes the AWG is in.

[captain_dalan]

11 hours ago, near_blind said:

The only behavior that seems like it might be repeating it on my end is if there are no healthy tracks that exist both within the scan volume and the TID display area. I.E. Turning such that a track centroid is dragged off either side of the TID will cause a TWSA scan volume to snap back to the center. I don't know if that's a bug or not. 

Hmm, it seems that the best workaround would be to keep the nose still for about 8-12 seconds from the moment the radar transitions from RWS to TWS. That should be enough for tracks to properly build, right?

As for it being a bug or a feature.... @IronMike?

9 hours ago, Callsign JoNay said:

Maybe try turning on the r.ctrl + enter controls overlay so you can see exactly what modes the AWG is in.

Might try that as well if i have the time this evening. 

[DSplayer]

16 hours ago, captain_dalan said:

Not an impossibility, but it would happen more randomly if it was so, and there seems to be a method to this. Also, PAL and PLM are mapped to my throttle buttons. And once i punch in blower i leave it alone. My Jester shortcuts are mapped to my keyboard, and they only involve TID orders.

It's my own modification of that mission to include Charlie Phoenixes, but the mission isn't an issue, i can recreate it on any mission, including vanilla instant actions. Here's some from the Persian Gulf BVR mission. In the first 2 cases, the radar reacquires and continues tracking, but in the third one it doesn't:
 

It appears the issue is more likely to appear near the edge of the radar cone. Also, not sure, but switching TID to 50 mile scale may play a part? I also include two tracks as short as possible, for all those are worth these days:
 

track lost and recovered.trk 300.85 kB · 1 download track lost and not recovered.trk 236.65 kB · 1 download

 

Hmm what I'm seeing here is the tracks basically be off the visible display area and then being dropped/centroid not considering them in the weighting to keep the scan volume centered there. That was something I used to use to my benefit since it would prevent TWS creating a centroid in between on a target that was 80 nm or so out and the target you actually wanted to shoot at which was like 40 nm out and you didn't want TWS to just drop your intended target. From what I'm guessing, your third case didn't reacquire because you didn't have a SP/PH selected like in the first two cases but I have two hypotheses which use that as a springboard. 

One hypothesis is that having a SP/PH selected might contribute to a longer track extrapolation time (which I don't remember really existing but things might've changed) which then would allow for the target aircraft to enter the visible display area and then the radar would slew back and create new tracks in the same airspace as that extrapolated track.

Another hypothesis is that since you have SP/PH selected in the first two, once the targets reentered the visible display area, it immediately slewed over to the extrapolated track and started creating new tracks based and the WCS immediately assigned target priority to those tracks which made the radar slew over the first and second time. This didn't occur in the third case since there was no weapon selected and when there isn't a weapon selected, target priority isn't assigned.

 

BTW, this is quite different than what happened in the first video you posted.

Edited December 7, 2022 by DSplayer

[near_blind]

Word of God is if the track isn't visible on the TID, it isn't weighted for scan zone slewing

[captain_dalan]

4 hours ago, DSplayer said:

Hmm what I'm seeing here is the tracks basically be off the visible display area and then being dropped/centroid not considering them in the weighting to keep the scan volume centered there. That was something I used to use to my benefit since it would prevent TWS creating a centroid in between on a target that was 80 nm or so out and the target you actually wanted to shoot at which was like 40 nm out and you didn't want TWS to just drop your intended target. From what I'm guessing, your third case didn't reacquire because you didn't have a SP/PH selected like in the first two cases but I have two hypotheses which use that as a springboard. 

One hypothesis is that having a SP/PH selected might contribute to a longer track extrapolation time (which I don't remember really existing but things might've changed) which then would allow for the target aircraft to enter the visible display area and then the radar would slew back and create new tracks in the same airspace as that extrapolated track.

Another hypothesis is that since you have SP/PH selected in the first two, once the targets reentered the visible display area, it immediately slewed over to the extrapolated track and started creating new tracks based and the WCS immediately assigned target priority to those tracks which made the radar slew over the first and second time. This didn't occur in the third case since there was no weapon selected and when there isn't a weapon selected, target priority isn't assigned.

 

BTW, this is quite different than what happened in the first video you posted.

 

I don't think this to be case, as i have recording of the same thing happening with selected Sparrows or Phoenixes, but i fear that if i upload any more DCS content, Youtube will ban me for spamming! 

2 hours ago, near_blind said:

Word of God is if the track isn't visible on the TID, it isn't weighted for scan zone slewing

It must be that then. And a few fast experiments i performed tonight, showed that if i count slowly to 10 or so before turning away, the tracking never drops. So there's a new good common practice to have in mind i guess.