[BUG] Radar TWS wierdness

[Svend_Dellepude]

Looks like there is a feedback loop in the radar, where new contacts are fed to the input which again generates a new output, and so on, in the direction of the sweep.

[Bosebcc]

I have also reproduced the problem.(SP and MP) The problem in multiplayer seems to be worse. In addition, during testing I found another bug that may be related to this problem. I was not able to use acm mode or let jester stt lock after jester freaked out and mess with a button in the back. (You can hear him trying to switch something and I was not able to get the target lock). Though this is not really a common apperance compared to the ghost track. To compare, I was able to reproduce the ghost track behavior 90% of time during testing in single player and only 20 % resulted in the jester freaking out and spamming a button.

 

 

Note: If anyone need the tacview file for reference just contact me.

(Single player - instant action: beyond visual range(persian gulf))

 

 

Edit: Another problem! Something catched my eyed at 1:21, when I fired the 2nd pheonix on the target the computer suddenly cleared the tws number. I tried to reproduce this and I was sucessful. I think the problem only occured after the radar try to track the ghost track.

 

 

__________________________________

 

List of problem and video timestamp

 

1. Ghost track 0:50

1.1 An interesting ghost contact that came out of no where 1:44

2. 2nd pheonix fire went dumb and radar suddenly lost track 1:21

3. Jester went nuts after setting azimuth to center 1:52 and I was not able to lock the target in any circumstances 2:50

______________________________

Personally I don't know if this is realistic or intended, but for the past I have never stumbled upon this issue. But if this is an realistic/intended behavior I just want to say that right now the F14 is very frustrate to fly and engage a target with no rio (jester controlled). Not only it is unreliable, you cannot overide the tws auto once the pheonix is fire which makes thing very frustrating. I hope that this is a real issue and they will get it fix soon, so we will not be stuck with this weird radar behavior.

 

Thanks.

______________________________

Edited April 22, 2020 by Bosebcc

[Looney]

Last night we were trying to lock up an S-3 tanker for target practice. We were at 15K feet, head on to the target which was at 6K feet. At around 30 - 25Nm I saw a ghost contact appear from the valid target and leave the normal radar return as a track with high speed to the right of the screen, another one spawned as well but it was short lived.

 

This was in an MP environment, roughly 15 aircrafts with only one lag-spike due to the spawning of ground units, well before the ghost contact. Version was 45915.

[lordfool]

You mean these ghosting contacts were actually a bug? I thought this was just some jamming or something. I've been having these way back since the release as rio/pilot and always in mp don't know about singleplayer.

 

It was certainly never as bad as the last few videos posted on here. The picture first posted is what it'd it look like, it mostly lasted 7 seconds at the most and disappeared so I thought it was just some jamming.

[nighthawk2174]

Nope its a bug, jamming effects aren't implemented yet.

[mattag08]

Every time the contact goes to the notch when defending against a missile I get this behavior, FWIW. It's more pronounced now that TWS Auto has the automatic track hold for AIM-54 launches.

[Naquaii]

Just as an update we have gotten hold of a mission that reproduces the issue fairly consequently so we do have something to work with.

 

No timeline on a fix unfortunately but we're on it!

[nighthawk2174]

Nice hopefully this will get fixed as when the new phoenix code gets added its going to be super critical that the system doesn't loose the track because of this.

 

Edit just wanted to add my own vid of what happened + track:

https://www.dropbox.com/s/wxlu9oou9ef91dr/AIM54TWSBug.trk?dl=0

Edited April 25, 2020 by nighthawk2174

[Quid]

I was able to get in a few flights online today - TWS-A worked perfectly. I recorded every instance I used it, and I can post the videos, but I got zero ghosting from straight-and-level targets to include multiple targets on the scope at the same time. Only after either being shot down or going defensive did they ghost (as they are supposed to). I just figured I should report that it doesn't break every single time.

[captain_dalan]

I was able to get in a few flights online today - TWS-A worked perfectly. I recorded every instance I used it, and I can post the videos, but I got zero ghosting from straight-and-level targets to include multiple targets on the scope at the same time. Only after either being shot down or going defensive did they ghost (as they are supposed to). I just figured I should report that it doesn't break every single time.

 

Very similar to my experiences. It seams quite hard to nail what exactly is causing it. Last night i had a fairly successful MP and SP use out of it, very little ghosting, but at times.......

 

Still, MP seams to be more prone to the issue

[Airhunter]

Maybe it could be related to chaff usage or the enemy firing weapons (as those will show up on your datalink). And honestly, on a maneuvring target I'd personally go for STT.

[Quid]

Maybe it could be related to chaff usage or the enemy firing weapons (as those will show up on your datalink). And honestly, on a maneuvring target I'd personally go for STT.

 

It's neither chaff nor datalink - check the videos and discussion from the past few pages - the ghosting happens even without any defensive action from the target aircraft or as a result of friendly or enemy weapon usage.

[gyrovague]

Spent a bunch of time investigating this the past few days, there appear to be a number of reasons causing this, and some of them are legitimate:

1) targets with large acceleration vectors - legitimate, since TWS in the tomcat only tracked position and velocity according to our info. Large acceleration changes of course lead to velocity changes over time, and if this falls outside the threshold of track correlation, it will form new tracks. Turning sharply is an example of a large acceleration change (rate of change of velocity vector).

2) rubberbanding in MP - legitimate-ish, the radar sees the target going backwards and forwards, so forms new tracks since the observations don't correlate to track extrapolations, shrug... Not sure we can solve this while still maintaining realistic TWS tracking, and not just directly using DCS object info.

3) closely spaced targets just flying constantly straight and level - bug/shortcoming

 

I've fixed/improved the behaviour regarding #3 at least. It can still occur somewhat, as it happens at the boundaries between where clustered targets split or combine, but the effects should be far less now (no sudden massive velocities peeling off at large angles).

[near_blind]

1) targets with large acceleration vectors - legitimate, since TWS in the tomcat only tracked position and velocity according to our info. Large acceleration changes of course lead to velocity changes over time, and if this falls outside the threshold of track correlation, it will form new tracks. Turning sharply is an example of a large acceleration change (rate of change of velocity vector).

 

What's the logic for track correlation then? I've seen plenty of situations for example where something similar to the following happened:

 

Frame 1 the target has an apparent velocity of 400 knots and a heading of 180

Frame 2 the target has an apparent velocity of Mach 6 and a heading of 160

Frame 3 the target has an apparent velocity of 390 knots and a heading of 175

Frame 4 the target has an apparent velocity of 380 knots and a heading of 180

 

Why does the track accept that the target in Frame 1 and Frame 2 are the same track, but Frame 3 and 4 are new tracks even though the target is still basically on top of where it was during Frame 1?

[KlarSnow]

Spent a bunch of time investigating this the past few days, there appear to be a number of reasons causing this, and some of them are legitimate:

1) targets with large acceleration vectors - legitimate, since TWS in the tomcat only tracked position and velocity according to our info. Large acceleration changes of course lead to velocity changes over time, and if this falls outside the threshold of track correlation, it will form new tracks. Turning sharply is an example of a large acceleration change (rate of change of velocity vector).

2) rubberbanding in MP - legitimate-ish, the radar sees the target going backwards and forwards, so forms new tracks since the observations don't correlate to track extrapolations, shrug... Not sure we can solve this while still maintaining realistic TWS tracking, and not just directly using DCS object info.

 

Gyrovague, regarding 1 ( and 2) Does the AWG not have any correlation limits, or sanity checks. I understand that if the target makes a significant acceleration that this can lead to a false track, however there are some pretty basic sanity checks that could resolve this. For example if the target is going 400 knots in one frame and then suddenly 1600 knots in the next... thats a bit out of the realm of possibility for an air breathing target... and it shouldn't correlate the original track to the new one. This kind of sanity check is pretty normal for any track generating algorithm cause otherwise you could get spurious velocities all over the place from just ambient EM spectrum that can cause false doppler returns and totally screw up your tracks.

 

Essentially there should be some kind of a filter or gating mechanism that prevents it from correlating sudden massive acceleration changes to the original track unless they pass a sanity check. What that limit is I have no idea, maybe its 800 knots, maybe its 400 knots, but when you suddenly see a track walk off at several mach numbers higher than the original track was going... That doesnt seem right

[nighthawk2174]

Agreed the issues were seeing are a generation of tons of new contacts even on contacts flying level and straight and not accelerating. With tons of different random contacts with very different and absurdly high velocities spawning from the position of the target and often also resulting in the loss of the target. Surly though one of your SME's can comment on this behavior, I doubt highly that this is in any way accurate. It seems like something that if it did happen it would have been caught and fixed almost immediately. As KlarSnow said above as well its also not a complex process to reject such random contacts.

[gyrovague]

Agreed the issues were seeing are a generation of tons of new contacts even on contacts flying level and straight and not accelerating. With tons of different random contacts with very different and absurdly high velocities spawning from the position of the target and often also resulting in the loss of the target. Surly though one of your SME's can comment on this behavior, I doubt highly that this is in any way accurate. It seems like something that if it did happen it would have been caught and fixed almost immediately. As KlarSnow said above as well its also not a complex process to reject such random contacts.

 

This is the thing that is fixed now, and sounds like nearblind and klarsnow are referring to this too.

[KlarSnow]

So just to be clear, this should help with the first two issues as well, while they will still happen and its still possible for desync/lag or a rapid maneuver to create a false track, it should be less likely to then transfer the original track instantly to the false/inaccurate track. Not saying impossible, or even improbable. Just that this seems to be what should solve most of the track issues caused by all 3 of the aformentioned causes. IE if it gets a hit or two that are obviously spurious due to whatever reason (lag/desync/maneuver) the correlation algorithm should be able to hold onto the original track, even if it picks it up?

 

Cause what essentially seems to keep happening in the current system is it gets a false track for whatever reason while you have a missile in the air, and then immediately correlates the original track to the false one. The original track is still usually being picked up. Then due to track hold it propagates the new track into infinity, essentially acting as if it had immediately lost all radar contact with the original track and gone into a lost lock kind of situation. With TWS-A it then gets dragged off trying to hold onto the false track getting track held and any other tracks will then get screwed.

 

With a single contact resolving into two (res cell) a similar thing can happen, because it sees the second contact, correlates, and then assumes the split between the two is acceleration, and then boom same thing happens, and the track gets track hold yeeted away from the actual position dragging TWS-A with it, all while the radar is seeing two perfectly sane tracks where before there was none. If a track splits like that it should just settle on one of the two or more new contacts as being the original, because it is seeing two actual skin tracks, not propagating an entirely fictitious one that is zooming off into nowhere when it has two perfectly good radar hits that are still present on the radar scope to choose from.

 

IE it could/should do that if the maneuver resulted in a loss of radar contact, IE a notch or terrain masking, etc... But as long as its still seeing the skin returns, and it has some kind of gating logic, it should be able to hold onto a skin return instead of jumping immediately to track hold on a false track.

 

using Near blinds example from above

 

1st frame: Track showing heading 180 and 400 knots

2nd frame: Track showing heading 160 and 1400 knots (track correlates to false track)

3rd frame: correlated track shows no return goes into track hold at heading 160 and 1400 knots, also shows 2 tracks at almost same position showing heading 180 and 400 knots and heading 170 and 450 knots.

4th frame: correlated track in track hold continues to show no return with the 2 tracks behind it showing heading 180 and 400 knots and 170 and 450 knots.

 

This seems to be how its working, where what it seems it should be doing is disregarding what it sees in the second frame especially as it still has skin hits in the original tracks location. it should then settle on one of the two skin hits as correlating to the original track.

 

This exact same logic should apply to maneuvers that dont result in losing a skin hit on the track (IE not going to the notch), or or most network/desync issues, IE if it gets a frame or two of bad data, and then good data, it should be able to recover it from the track hold march into nowhere.

Edited April 27, 2020 by KlarSnow

[Hextopia]

Spent a bunch of time investigating this the past few days, there appear to be a number of reasons causing this, and some of them are legitimate:

1) targets with large acceleration vectors - legitimate, since TWS in the tomcat only tracked position and velocity according to our info. Large acceleration changes of course lead to velocity changes over time, and if this falls outside the threshold of track correlation, it will form new tracks. Turning sharply is an example of a large acceleration change (rate of change of velocity vector).

2) rubberbanding in MP - legitimate-ish, the radar sees the target going backwards and forwards, so forms new tracks since the observations don't correlate to track extrapolations, shrug... Not sure we can solve this while still maintaining realistic TWS tracking, and not just directly using DCS object info.

3) closely spaced targets just flying constantly straight and level - bug/shortcoming

 

I've fixed/improved the behaviour regarding #3 at least. It can still occur somewhat, as it happens at the boundaries between where clustered targets split or combine, but the effects should be far less now (no sudden massive velocities peeling off at large angles).

 

 

Is there any chance to do a sort of "sanity check" for lag where you look to track the "true" velocities of the targets from the server and clamp false targets when the server appears to be telling you targets are accelerating at insanely high rates (that couldn't be possible) it might not be true behavior, but it would make flying the F-14 bearable using TWS until we get some more stable multiplayer.

 

 

It's honestly gotten so bad that I've been flying with phoenixes and using TWS extremely rarely, and when I do I almost always lose the shot to lag.

[nighthawk2174]

So just to be clear, this should help with the first two issues as well, while they will still happen and its still possible for desync/lag or a rapid maneuver to create a false track, it should be less likely to then transfer the original track instantly to the false/inaccurate track. Not saying impossible, or even improbable. Just that this seems to be what should solve most of the track issues caused by all 3 of the aformentioned causes. IE if it gets a hit or two that are obviously spurious due to whatever reason (lag/desync/maneuver) the correlation algorithm should be able to hold onto the original track, even if it picks it up?

 

Cause what essentially seems to keep happening in the current system is it gets a false track for whatever reason while you have a missile in the air, and then immediately correlates the original track to the false one. The original track is still usually being picked up. Then due to track hold it propagates the new track into infinity, essentially acting as if it had immediately lost all radar contact with the original track and gone into a lost lock kind of situation. With TWS-A it then gets dragged off trying to hold onto the false track getting track held and any other tracks will then get screwed.

 

With a single contact resolving into two (res cell) a similar thing can happen, because it sees the second contact, correlates, and then assumes the split between the two is acceleration, and then boom same thing happens, and the track gets track hold yeeted away from the actual position dragging TWS-A with it, all while the radar is seeing two perfectly sane tracks where before there was none. If a track splits like that it should just settle on one of the two or more new contacts as being the original, because it is seeing two actual skin tracks, not propagating an entirely fictitious one that is zooming off into nowhere when it has two perfectly good radar hits that are still present on the radar scope to choose from.

 

IE it could/should do that if the maneuver resulted in a loss of radar contact, IE a notch or terrain masking, etc... But as long as its still seeing the skin returns, and it has some kind of gating logic, it should be able to hold onto a skin return instead of jumping immediately to track hold on a false track.

 

using Near blinds example from above

 

1st frame: Track showing heading 180 and 400 knots

2nd frame: Track showing heading 160 and 1400 knots (track correlates to false track)

3rd frame: correlated track shows no return goes into track hold at heading 160 and 1400 knots, also shows 2 tracks at almost same position showing heading 180 and 400 knots and heading 170 and 450 knots.

4th frame: correlated track in track hold continues to show no return with the 2 tracks behind it showing heading 180 and 400 knots and 170 and 450 knots.

 

This seems to be how its working, where what it seems it should be doing is disregarding what it sees in the second frame especially as it still has skin hits in the original tracks location. it should then settle on one of the two skin hits as correlating to the original track.

 

This exact same logic should apply to maneuvers that dont result in losing a skin hit on the track (IE not going to the notch), or or most network/desync issues, IE if it gets a frame or two of bad data, and then good data, it should be able to recover it from the track hold march into nowhere.

+1

[sLYFa]

This is the thing that is fixed now, and sounds like nearblind and klarsnow are referring to this too.

 

Did that fix already make it in the current open beta? I don't seem to have problems with two contacts flying close together anymore.

[Svend_Dellepude]

AFAIK a radar needs to see a return more than once before building a track file. That doesn't seem to happen here. In TWS-A tracks seems to be build immediately upon getting a return.

[Rlaxoxo]

AFAIK a radar needs to see a return more than once before building a track file. That doesn't seem to happen here. In TWS-A tracks seems to be build immediately upon getting a return.

 

That first contact that shows on the TID has no velocity vector and if you move the radar scan volume from the target it that contact will drop after 3 sec (Track not built)

 

If you hold your scan volume on the target for 2 seconds the track will be built and it will have a velocity vector and it will take 14 seconds to drop it.

[captain_dalan]

Is there any chance to do a sort of "sanity check" for lag where you look to track the "true" velocities of the targets from the server and clamp false targets when the server appears to be telling you targets are accelerating at insanely high rates (that couldn't be possible) it might not be true behavior, but it would make flying the F-14 bearable using TWS until we get some more stable multiplayer.

 

 

It's honestly gotten so bad that I've been flying with phoenixes and using TWS extremely rarely, and when I do I almost always lose the shot to lag.

 

For what is worth, my kill ratio in MP went from less then 1-8 to something like 1-5 since TWS-AUTO was implemented (yeah i do keep count). Then again, i only fly with Jester and have never turned cold on a 20+ NM launch.

 

In SP, the kill ratio is about the same, but then again this is more related to some other issues.

 

Disclaimer: i seldom do BVR and generally suck at it

[Hextopia]

For what is worth, my kill ratio in MP went from less then 1-8 to something like 1-5 since TWS-AUTO was implemented (yeah i do keep count). Then again, i only fly with Jester and have never turned cold on a 20+ NM launch.

 

In SP, the kill ratio is about the same, but then again this is more related to some other issues.

 

Disclaimer: i seldom do BVR and generally suck at it

 

 

Problem is you can't (and won't) be able to hit DCS AI with TWS shots easily since they treat it just like you had them in STT and fired. They're aware of the missile the moment it leaves the rail.

 

 

So it's generally more useful against players, but with how unstable DCS MP is right now compounded with this TWS bug and how vulnerable TWS is to lag in the first place, I find it's often smartest to just wait till they're closer and STT launch the phoenix to make sure it doesn't get lost due to lag, but at that point you've only got a longer range AIM-120 that can't be used reliably in TWS and gobbles up chaff, so against decent players it's fairly limited in what it can do.