missing track file Difficulty upgrading Track Targets to System Targets

[Willie Nelson]

The heading says it all, I am having trouble doing this. To be clear, I am in CRM TWS mode with several track targets (the larger filled in squares).

I am selecting TMS right short (long switches back to RWS) and often, though not always, I cannot get these Track targets to switch to System Targets, although sometimes some do and some don't.

Is anybody able to elaborate for me or do I simply need more sweeps of the FCR? Thanks in advance.

[WHOGX5]

3 hours ago, Willie Nelson said:

The heading says it all, I am having trouble doing this. To be clear, I am in CRM TWS mode with several track targets (the larger filled in squares).

I am selecting TMS right short (long switches back to RWS) and often, though not always, I cannot get these Track targets to switch to System Targets, although sometimes some do and some don't.

Is anybody able to elaborate for me or do I simply need more sweeps of the FCR? Thanks in advance.

The FCR symbology in the DCS F-16C is not functioning properly at all, and unfortunately there is no other answer than that it is a complete guessing game. As it stands currently you cannot see which targets are buggable or not in any of the FCR A-A modes. For this reason I personally don't use TWS unless I absolutely, absolutely have to, as the issues you mention make it extremely labour intensive and unreliable. You will have the same issue in RWS when using the SAM and DTT modes, but at least there they are easy to fix by simply pressing TMS UP again.

[Willie Nelson]

8 hours ago, WHOGX5 said:

The FCR symbology in the DCS F-16C is not functioning properly at all, and unfortunately there is no other answer than that it is a complete guessing game. As it stands currently you cannot see which targets are buggable or not in any of the FCR A-A modes. For this reason I personally don't use TWS unless I absolutely, absolutely have to, as the issues you mention make it extremely labour intensive and unreliable. You will have the same issue in RWS when using the SAM and DTT modes, but at least there they are easy to fix by simply pressing TMS UP again.

Thanks for the response, can anyone else confirm this? It’s usually just my misunderstanding of how the thing works…….perhaps not this time. 

[Opesher]

6 hours ago, Willie Nelson said:

Thanks for the response, can anyone else confirm this? It’s usually just my misunderstanding of how the thing works…….perhaps not this time. 

Hello. To put it into two cents and make response useful to other people who may read this, I will get into some context.

Spoiler

With F-16C's radar you have four types of contact symbols:
- Search Target: FCR has detected a contact, but the contact has not been up for long enough for radar to build a track on it. It's reprecented by a small rectangle with a line indicating aspect (hot/cold).
- Track Target: After some time, if the contact has not disappeared, FCR has resolved contact well enough to generate track data. It's reprecented by a solid square with more details available. Radar does it automatically.
- System Target: Pilot-designated (TMS Up above contact) track targets. It's reprecented by a hollow square.
Keep in mind that TMS Right transforms all availabe track targets, but not search targets. This is one of issues you were having with it in original post. 
- Bugged Target: Basically soft target track of a system target, it allows for weapons employment with FCR tracking data. Indicated by a solid box with a circle. Be aware - when you have a bugged target, you may no longer promote track targets to system targets, and first have to remove it (TMS Aft).

As for "not functioning at all" and "cannot see which targets are buggable or not" is not true a bit in my case.
I see a lot of people having troubles with understanding difference between your own onboard tracks and datalink tracks (not to blame), and that's probably the issue you and the person above are having. 

To not play the "guessing game", there is a datalink data filter for your FCR, and the current setting is displayed above OSB15. You can either cycle through the options with IFF IN or disable all datalink tracks with IFF OUT.
- ALL: Show all datalink tracks.
- FTR+: Filter out all surveliance datalink tracks.
- TGTS: Filter out all surveliance and PPLI (donor) tracks.
- NONE: Filter out all datalink tracks.

That's a good practice to keep general situational awareness with FCR set to ALL and HSD, but switch filter to FTR+/NONE prior to engagement to actually know what your radar actually sees. It will be still correlated on HSD display, so just crosscheck it.

Let's have an example:
1. AWACS detects a contact.
2. Determines either this contact is hostile, ambiguous or friendly.
3. Sends the data over datalink.
4. You receive that data (in this example, a hostile aircraft, indicated by a hollow red triangle on fcr and hsd pages).
When you point your radar in the direction of the target, the red triangle changes to a yellow box, and that's where many people start having problems:
-- Yellow: Means target is ambiguous. Although surveliance/donors have declared the contact hostile (red), it's still unknown (white) to your own FCR. 
-- Box: Indicates track data received from a datalink source. It's not your FCR track data! Even if it's correlated, it may still be a search target. This only means that whatever radar return you had at that position has been correlated to datalink track data.

In this scenario, unless you apply a filter, you can't know the status of the contact - search target or track target.

Edited March 24 by Opesher

[Willie Nelson]

Thanks very helpful, so it looks like in fact it is as designed to be. I just need to understand the filtering better. That explains why the box was yellow although from memory I was able to TMS right between two yellow boxes. I’ll have to have another look when I get home.  
 

Thanks again for the detailed explanation, it certainly is very different from the Hornet. 

[Comrade Doge]

2 hours ago, Opesher said:

Hello. To put it into two cents and make response useful to other people who may read this, I will get into some context.

  Reveal hidden contents

With F-16C's radar you have four types of contact symbols:
- Search Target: FCR has detected a contact, but the contact has not been up for long enough for radar to build a track on it. It's reprecented by a small rectangle with a line indicating aspect (hot/cold).
- Track Target: After some time, if the contact has not disappeared, FCR has resolved contact well enough to generate track data. It's reprecented by a solid square with more details available. Radar does it automatically.
- System Target: Pilot-designated (TMS Up above contact) track targets. It's reprecented by a hollow square.
Keep in mind that TMS Right transforms all availabe track targets, but not search targets. This is one of issues you were having with it in original post. 
- Bugged Target: Basically soft target track of a system target, it allows for weapons employment with FCR tracking data. Indicated by a solid box with a circle. Be aware - when you have a bugged target, you may no longer promote track targets to system targets, and first have to remove it (TMS Aft).

As for "not functioning at all" and "cannot see which targets are buggable or not" is not true a bit in my case.
I see a lot of people having troubles with understanding difference between your own onboard tracks and datalink tracks (not to blame), and that's probably the issue you and the person above are having. 

To not play the "guessing game", there is a datalink data filter for your FCR, and the current setting is displayed above OSB15. You can either cycle through the options with IFF IN or disable all datalink tracks with IFF OUT.
- ALL: Show all datalink tracks.
- FTR+: Filter out all surveliance datalink tracks.
- TGTS: Filter out all surveliance and PPLI (donor) tracks.
- NONE: Filter out all datalink tracks.

That's a good practice to keep general situational awareness with FCR set to ALL and HSD, but switch filter to FTR+/NONE prior to engagement to actually know what your radar actually sees. It will be still corelated on HSD display, so just crosscheck it.

Let's have an example:
1. AWACS detects a contact.
2. Determines either this contact is hostile, ambiguous or friendly.
3. Sends the data over datalink.
4. You receive that data (in this example, a hostile aircraft, indicated by a hollow red triangle on fcr and hsd pages).
When you point your radar in the direction of the target, the red triangle changes to a yellow box, and that's where many people start having problems:
-- Yellow: Means target is ambiguous. Although surveliance/donors have declared the contact hostile (red), it's still unknown (white) to your own FCR. 
-- Box: Indicates track data received from a datalink source. It's not your FCR track data! Even if it's corelated, it may still be a search target. This only means that whatever radar return you had at that position has been corelated to datalink track data.

In this scenario, unless you apply a filter, you can't know the status of the contact - search target or track target.

 

It is established by available documents that the red to yellow track correlation behavior is incorrect. Now we are waiting for ED to acknowledge this, one day, hopefully...

[Opesher]

3 hours ago, Willie Nelson said:

although from memory I was able to TMS right between two yellow boxes. I’ll have to have another look when I get home.  

There's nothing unusual, think of your FCR and datalink as these are two separate entities. Onboard FCR still has to go through the whole process to generate it's own track data - detect (search target), sweep for a little and generate track data (track target), the only difference datalink provides is correlation between your detected contact and an already existing track data of that contact of a donor for situation awareness, not for a firing solution.

That's when filtering comes in place, so you can see your own contact state behind shared data.

Edited March 24 by Opesher

[Willie Nelson]

11 hours ago, Comrade Doge said:

It is established by available documents that the red to yellow track correlation behavior is incorrect. Now we are waiting for ED to acknowledge this, one day, hopefully...

Perhaps incorrect but not a bug….is that what you’re trying to say? 

[Comrade Doge]

5 hours ago, Willie Nelson said:

Perhaps incorrect but not a bug….is that what you’re trying to say? 

Yes, ED believes it is correct as is and not a bug. Me and some other folks are very open to discussing the issue with publicly available information with ED, if they decide to revisit the issue.

For instance, even from the official manual, the FCR has no authority to change ROE, but when seeing a datalink target with the FCR, the ROE changes from hostile to suspect still. A pretty obvious contradiction even at first glance.

Edited March 25 by Comrade Doge

[Willie Nelson]

Thanks. It does seem a bit cumbersome. 

[WHOGX5]

2 hours ago, Comrade Doge said:

For instance, even from the official manual, the FCR has no authority to change ROE, but when seeing a datalink target with the FCR, the ROE changes from hostile to suspect still. A pretty obvious contradiction even at first glance.

 

This is not entirely correct, but rather a slight misunderstanding of the manuals.

What happens in real life is that when a pilot hops his aircraft he will load different identification requirements from his DTC which specifies what makes a track be classified as friendly or hostile using his onboard sensors. One important thing to note, is that the F-16CM-50 is unable to correlate IFF information to tracks, so any IFF response requirements in the identification requirements will only be taken from interrogations performed by other aircraft on the same target, transmitted via LINK 16. So a hostile ID requirement could be that the target has to be of type MIG-29 and have a negative Mode 4 IFF response. Then you can determine the aircraft type with NCTR using your own radar, and if some other aircraft on your LINK 16 network has interrogated that same target, correlated it to the track, and sent that Mode 4 response back onto the network, then that target will show up as hostile on your FCR.

Now, if there is a disagreement between a track identity on the LINK 16 network and the identity which has been determined for that same correlated track by your own aircraft, then the track will mipple (flash) between the two different identities to show the pilot that there is an ambiguity there. Since ID requirements aren't necessarily the same on the LINK 16 network and in your own aircraft, you can have all kinds of ID disagreements even with the exact same information about the track in question.

Also, what the manual means when it says that the FCR has no authority to change ROE, they literally mean that what is displayed on your FCR doesn't in any way override the rules-of-engagement which have been set by the commanders and generals leading the war. Just because something has been ID'd as hostile in your aircraft, does not mean that it actually is hostile or that you're cleared to fire at it. In the same way, just because something shows up as an unknown, does not mean it's not hostile or that you're not allowed to fire at it. You can have a situation where you have identified the aircraft type via NCTR, you have performed an Mode 4 interrogation which came back negative but isn't correlated to the track so it still shows as unknown, yet you have still fulfilled theatre ROE requirements and are allowed to fire at the target.

So yeah, the main issue in the DCS F-16C regarding this specific aspect of the symbology is that correlated tracks don't mipple back and forth between the different track identities if there is a disagreement in identity between your own onboard sensors and what is supplied via LINK 16.

[RyanR]

I've noticed the same behaviors.

I think some "interesting stuff" happens when jamming/countermeasures come into the picture. The bad guys don't want to become system targets. Since DCS seems to model the avionics, and not just provide the facade of them, inconsistencies make sense. 

Of course, I could simply be new and not know what I'm doing.

-Ryan

[Willie Nelson]

@WHOGX5 That's really good info, thanks. So much to learn, so little time.

[Comrade Doge]

On 3/25/2024 at 1:09 PM, WHOGX5 said:

This is not entirely correct, but rather a slight misunderstanding of the manuals.

What happens in real life is that when a pilot hops his aircraft he will load different identification requirements from his DTC which specifies what makes a track be classified as friendly or hostile using his onboard sensors. One important thing to note, is that the F-16CM-50 is unable to correlate IFF information to tracks, so any IFF response requirements in the identification requirements will only be taken from interrogations performed by other aircraft on the same target, transmitted via LINK 16. So a hostile ID requirement could be that the target has to be of type MIG-29 and have a negative Mode 4 IFF response. Then you can determine the aircraft type with NCTR using your own radar, and if some other aircraft on your LINK 16 network has interrogated that same target, correlated it to the track, and sent that Mode 4 response back onto the network, then that target will show up as hostile on your FCR.

Now, if there is a disagreement between a track identity on the LINK 16 network and the identity which has been determined for that same correlated track by your own aircraft, then the track will mipple (flash) between the two different identities to show the pilot that there is an ambiguity there. Since ID requirements aren't necessarily the same on the LINK 16 network and in your own aircraft, you can have all kinds of ID disagreements even with the exact same information about the track in question.

Also, what the manual means when it says that the FCR has no authority to change ROE, they literally mean that what is displayed on your FCR doesn't in any way override the rules-of-engagement which have been set by the commanders and generals leading the war. Just because something has been ID'd as hostile in your aircraft, does not mean that it actually is hostile or that you're cleared to fire at it. In the same way, just because something shows up as an unknown, does not mean it's not hostile or that you're not allowed to fire at it. You can have a situation where you have identified the aircraft type via NCTR, you have performed an Mode 4 interrogation which came back negative but isn't correlated to the track so it still shows as unknown, yet you have still fulfilled theatre ROE requirements and are allowed to fire at the target.

So yeah, the main issue in the DCS F-16C regarding this specific aspect of the symbology is that correlated tracks don't mipple back and forth between the different track identities if there is a disagreement in identity between your own onboard sensors and what is supplied via LINK 16.

The identification requirements/ROE tree are a different subject than the basic track correlation that should occur here.

Since there was no additional identification performed by the FCR (no NCTR scan was performed), there is no reason that an existing Hostile track would become Suspect, or mipple back and forth between the two. If however, the NCTR would have indicated a different print other than hostile specific ones, indeed that would be the case. But as we know that is not what's happening here, a simple sweep of the radar over a target immediately changes the ROE of Hostile tracks to Suspect, which makes no sense whatsoever.

The expected behavior would be, upon painting a hostile track with the radar, that it would correlate into a hostile track as well, and only if there exists other evidence that the same track might not be hostile (such as NCTR), then we can talk about how to display other indications.

[skywalker22]

11 hours ago, Comrade Doge said:

But as we know that is not what's happening here, a simple sweep of the radar over a target immediately changes the ROE of Hostile tracks to Suspect, which makes no sense whatsoever.

By ED's standards unfortunately is does. We tried numerous of times to tell them that, but so far with no luck

[Moonshine]

they denied the things with the maverick EO VIS modes too. took years to get them to acknowledge it. lots of prior denial. still we have it now and the community was right about it. wouldnt be surprised if that repeats itself here (and with the RWR)

 

[NineLine]

The thread is tagged missing track file, instead of discussing how bad it is that when we find info later on and happily change it, it's better to stay on the topic of the thread and help get this reported if it needs to be reported. Thanks. 

See my signature for the link to properly report a bug. Thanks. 

[skywalker22]

Another thread which will be closed.

I can do a track tomorrow, but if someone is willing to do a decent example, please go ahead.

[skywalker22]

On 3/24/2024 at 4:27 PM, Opesher said:

There's nothing unusual, think of your FCR and datalink as these are two separate entities. Onboard FCR still has to go through the whole process to generate it's own track data - detect (search target), sweep for a little and generate track data (track target), the only difference datalink provides is correlation between your detected contact and an already existing track data of that contact of a donor for situation awareness, not for a firing solution.
That's when filtering comes in place, so you can see your own contact state behind shared data.

I would like to know just one thing, is there or is there not a real correlation between datalink contact and FCR contact, regarding its location (X,Y,Z) so FCR know exactly about which contact is getting the info from Datalink? If not, then ED is right, if yes, then I don't see any reason why FCR would create its only picture of contacts and therefore firing solutions (appropriate color desigantion of System and Bugged targets).

[Comrade Doge]

40 minutes ago, skywalker22 said:

I would like to know just one thing, is there or is there not a real correlation between datalink contact and FCR contact, regarding its location (X,Y,Z) so FCR know exactly about which contact is getting the info from Datalink? If not, then ED is right, if yes, then I don't see any reason why FCR would create its only picture of contacts and therefore firing solutions (appropriate color desigantion of System and Bugged targets).

The correlation is real between the FCR and the Link, and when both of those see the same target, the position atribute is taken from the FCR (since it's more accurate) but the Link 16 fills up the rest of the information, such as identification.

In any case, new threads could be made on this issue, and I and others will happily help with further clarification

[skywalker22]

5 hours ago, Comrade Doge said:

The correlation is real between the FCR and the Link, and when both of those see the same target, the position atribute is taken from the FCR (since it's more accurate) but the Link 16 fills up the rest of the information, such as identification.

In any case, new threads could be made on this issue, and I and others will happily help with further clarification

Amazing, thx for the clarification.

So I am asking @NineLine if he can open up this closed thread, so we can continue on with a constructive conversation: 

 

There are quite some evidences gathered, and some still might be added.

Edited March 28 by skywalker22