TWS, WCS & Situational Awareness: Video Snippet Analysis

I recorded the footage as a reply to a post on r/hoggit, about TWS and guidance; to test and understand whether the guidance of the AIM-54 by the WCS is correct, especially if a track is lost. Moreover, in a comment in the previous video about STT, a question was asked about TWS. To kill two birds with one stone, I used the footage from the first answer and used to reply to the second. Here is the result:

Tacview track: https://www.dropbox.com/s/p28fnxt9xv05v37/20210520-hoggit-Tacview-20210520-194333-DCS.zip.acmi?dl=0

I received more questions related to this video, via comments or PM, so this is an analysis of the scenario, and the observations about the Track While Scan radar mode and the Weapon Control System.

Track While Scan: the best worst radar mode

TWS is a radar mode meant to be used in a number of situations, such as the employment of the AIM-54 Phoenix, to get additional information about a hooked target and IFF it. It is, however, the worst radar mode you can choose when you are looking for targets: it is extremely limited, due to the necessity of refreshing the tracks every couple of seconds. This means that the two available settings are both uncapable of covering a meaningful amount of airspace. On top of that, its range is shorter than RWS and PDSRCH. In fact, the more info a mode provides, the shorter its range (PDSRCH > RWS > TWS).
On the other hand, TWS provides additional information and data, the most obvious of which is the visual representation of the track.
The displayed tracks can immediately tell the RIO whether the target is Parallel or True Head-on or on a Collision Course.

More information about Track While Scan are available here:

• DCS HB F-14 Manual;
• Back to Basics: Radar Elevation Bars and Scan Azimuth;
• Intercept Geometry: Definitions;
• Intercept Geometry: Target Aspect and Lateral Separation.

Enough with the introduction, let’s get back to the video!

I – Scenario

To better explain the scenario, I use Tacview. This is the situation as I spawned: three contacts, parallel head-on, flying at different speeds and same altitude.

How long does it take to correlate the information displayed on the TID and build the “mental picture” above? Just a bunch of seconds, less if the DDD is used rather than the TID to determine the V_C. This number may sound absurdly low, but it is actually quite realistic:

• Parallel Head-On: as we know from the study of the geometry and the TID, the displayed vectors is the subtraction of the Euclidean vector of the F-14 and the target. Therefore, they point straight down or upwards only when FFP and BFP are parallel or they overlap.
• Variation of TA over time: this is important to “predict” the future positioning of the contacts and the engagement range (if they do not jink). Again, from the Geometry study, we know that in this scenario, the TA doubles as the SR is halved.
• V_C: in the video, due to the considerable range and for clarity, I used the TID to understand the V_C. In PD mode, the DDD is AZM vs Closure, so V_C can be understood by looking at the DDD.

Image II shows the TID AS from the video (not the same timestamp of the track in Image I):

II – Beaming

After a few seconds, the two targets on the right (B and C) split and, passed a certain angle, I turned off the MLC filter and dived slightly to maintain the antenna slightly looking up and ready to dive even more if necessary. Being feet-wet, that was not immediately necessary.

The simplest answer to a target beaming (they were not notching though) is, as mentioned, disabling the MCL filter. This operation does not solve, however, the next issue: the limitations of the TWS.

III – Plan and Employment

This is the moment where the scenario becomes interesting and the need to act becomes compelling.
As mentioned, the TWS has severe limitations due to how the track is built. Even in a scenario simple such as this one, where the contacts are co-altitude, the fact that C is moving towards the right means that soon the angle between A and B on the left, and the C, will be greater than 80°, “breaking” the TWS.

There are probably several valid plans, mine was straightforward: employ on C, as it’s turning away, and I want to avoid wasting more of the AIM-54 energy, then on A, since it’s the fastest. At that point crank left for a few miles whilst employing on B, then reverse to support the missile on C. The AIM-54 on A, due to V_C should have hit already at that point.

The issue in this case is how I managed Iceman and the fact that I did not realised how poorly it turned, resulting in the creation of an insufficient offset.

IV – Pitbulls & Observations

Post employment, there was not really much to do besides supporting the missiles until each its A-Pole.

As expected, the first missile to be activated by the WCS was Alpha.

This is where something unexpected happened: I was victim of the WCS Prioritization logic!

WCS Prioritization Logic: messing up RIOs’ lives since 1962!

V – Conclusion

The very last part of the scenario sees the repositioning for a follow-up shot on Bravo. Eventually, it got hit, but only because it turned hot again; the AIM-54 was almost out of energy.

Questions Answered? Sort of…

The first question was about the implementation of the TWS radar mode. The TWS seems to work partially as expected: the missile is activated depending on the range from the extrapolated track, but the guidance is similar to the previous implementation of the WCS. When the contact is lost, in fact, the AIM-54s does not loft and simply flies towards the track following a flat trajectory. This behaviour appears inconsistent though, because, as you can see from the video, the two Phoenixes hitting B and C did not turn into a flat trajectory but instead continued towards the extrapolated track until the activation command was sent by the WCS.
Correct or not, this at least tells us that a missile losing the track in the final part of the guidance can still be deadly. However, if the range is too high and the track is lost shortly after the employment, we may consider the missile trashed immediately. In this scenario, the RIO should wonder whether the AIM-54 may be still activated by the WCS on time to be a threat to the hostile (a means to have an idea is checking the TTI counter) or not. If the RIO concludes that the missile is trashed, then probably it would be better to switch radar mode (to “purge” the tracks) and take action (e.g. a follow-up shot or go “Out”).

The second question, asked in the comments of the video, is about the reasons why I lost the contacts. These are my observations, in chronological order:
Alpha: guided correctly until the activation. Charlie (Timestamp 5’14”): if you stop exactly at 5’18” you can see the return on the DDD. My impression is that the WCS tried to maintain the priority it originally assigned, causing the loss of the support of the missile flying towards Charlie, in favour of Alpha. If the returns weren’t there, then the most plausible explanation is the Zero Doppler (the MLC filter was turned off). What I don’t get is why Alpha was dropped as well… gimbals perhaps? So, it looks like that the WCS dropped Charlie but “realised” that Alpha couldn’t be maintained either, and it focused on Bravo (to prove that empirically, the angle between RBRG 0 and Alpha should be measured).
At Timestamp 5’39”, the WCS tried to reacquire the extrapolated track of Charlie. At Timestamp 5’49” Bravo is dropped, which is weird because a second earlier the track was refreshed on the DDD. I think the WCS maintained again the priority, no matter the fact that the track was an extrapolation and not the actual radar return.
As mentioned before, a solution to this rather interesting situation is marking the tracks as DO NOT ATTK on the CAP. This comes, however, with a potential loss in SA, as the target is not monitored anymore. It’s up to the virtual RIO to decided what is the best course of action.

I hope you find this brief analysis interesting. If you have reached different conclusions, I’m more than happy to discuss them together!