[BUG] Radar TWS wierdness

I'll try and reproduce it in single player and get a track or stream of it happening if I can.

I do know something similar will happen if the pilot or server is lagging, but it's generally less severe. Speaking of the radar getting weird with closely grouped contacts, do you know what that range is before it starts trying to group contacts together?

It isn't really the radar trying to group them together but it being unable to tell them apart. Within a certain distance the radar return simply appears as one to the radar. And when merging into one or splitting into two the WCS will create a new track or drop a track accordingly.

This distance depends on range from the radar as it depends on the azimuth resolution and that angular. So close in the radar has a greater resolution vs distance and further out less.

In general this number is between 2 and 3 degrees in azimuth but it varies slightly with selected radar mode.

Here is that vid, in this case at least, it appears the ghosts appear as the bandit goes into the notch

EDIT, sorry for the low quality rushed quality, i did this in a hurry

I can consistently reproduce a similar, although less extreme issue in SP. Single Mig-31 head on at 34k (co altitude with me). Once it launches its R-33 it starts cranking. Now if I start cranking too, its track will get x-ed out eventually (due to him being in the notch) and a second track appears. The old track either goes wild or retains a reasonable (yet still wrong) velocity vector. These two tracks start drifting apart as the original track remains due to the automatic track hold function. Here, I would expect the radar to reassign the original track to the new one.

Another scenario: A single Su-27, same distance same altitude. He will keep flying straight at me until the PH goes active. Until then, I can crank all I want and keep the track. As soon as he starts defending (i.e. PH goes active), the original track goes bananas and a second (sometimes even multiple) track appears which gets again lost and I get a TID full of x-ed out contacts + the correct one.

I undestand that TWS will occasionally loose track of a maneuvering target but it seems the radar is discarding old tracks too soon and fails to reassign new radar returns back to the orignal track.

I also suspect two targets in more or less close proximity causing issue but I need more testing on that.

EDIT

Here is that vid, in this case at least, it appears the ghosts appear as the bandit goes into the notch

Exactly this

Hi! Thanks for the video, it is entirely possible that you might get spurious ghosts against a maneuvering target when it's in our out of the notch, that's realistic and intended.

The main issue is when it happens against targets that aren't maneuvering or if it is a lot of fake tracks. That said, everything helps!

Just to clarify, having ghost tracks appear in situations where the radar is and should have trouble keeping track of targets is realistic and intended.

We are also looking at track generation in general but what we currently have is quite close to how it is described in our documentation.

The main issue here that is clearly a bug and wrong is where targets generate a lot of spurious ghosts in situations where they shouldn't.

spurious ghosts against a maneuvering target when it's in our out of the notch, that's realistic and intended.

Is it really? I mean the ghost contact's velocity is insanely high. Shouldn't there be some logic to check for kinematic plausibility of tracks? Not being edgy, just geniuniely intersted in what the AWG-9 is and is not capable of.

https://www.twitch.tv/videos/596842092

Here's a quick video in singleplayer of it happening. The test has multiple pairs of F-16's flying a generally flanking course in and out of the notch, with a few set to defend if fired on.

After firing phoenixes, the non-maneuvering targets suddenly spawn a huge amount of false contacts, whereas the maneuvering targets simply disappear and leave a ghost contact as they enter the notch and start defending.

Edit: First time the highlight screwed up in getting created.

Edit2: Twitch doesn't seem to want to create the video properly, so here's the original video link:

Thanks, I'll forward the video to our radar coder.

Is it really? I mean the ghost contact's velocity is insanely high. Shouldn't there be some logic to check for kinematic plausibility of tracks? Not being edgy, just geniuniely intersted in what the AWG-9 is and is not capable of.

Velocity is one of the criteria for sure so there might be something else at play here as well.

https://www.twitch.tv/videos/596842092

 

 

Here's a quick video in singleplayer of it happening. The test has multiple pairs of F-16's flying a generally flanking course in and out of the notch, with a few set to defend if fired on.

 

 

After firing phoenixes, the non-maneuvering targets suddenly spawn a huge amount of false contacts, whereas the maneuvering targets simply disappear and leave a ghost contact as they enter the notch and start defending.

 

 

Edit: First time the highlight screwed up in getting created.

Edit2: Twitch doesn't seem to want to create the video properly, so here's the original video link:

It happens from about 0:43 to 1:20.

Had a look at that video with our radar guy and it has us a bit stumped.

We're kinda thinking we might be dealing with multiple issues.

One thing that interests us with that video in particular is that you seem to have gone A/G for a short while there, I guess maybe you wanted to wipe the targets? We really haven't tested that as you'd never do that IRL as switching means you're loading a physical magnetic tape which always runs a risk of failing (not modelled but still). Still doesn't mean that should happen so we will look into that.

Our main lines of reasoning atm is that we might be looking at one issue in mp relating to rubberbanding and lag, one in sp where it relates to positioning of targets and or doing other stuff we hadn't thought of in the cockpit.

We'll have to test this stuff more to try and find out.

Additional bug reports will help ofc, try to mention if it was in sp or mp and if with a human RIO or not. If in sp a copy of the mission and how you got it to happened helps.

Unfortunately I'll be out of the loop until late friday this week due to RL but feel free to post anyway, if not sooner I'll have a look next weekend.

Hi! Thanks for the video, it is entirely possible that you might get spurious ghosts against a maneuvering target when it's in our out of the notch, that's realistic and intended.

 

The main issue is when it happens against targets that aren't maneuvering or if it is a lot of fake tracks. That said, everything helps!

Thanks, good to know!

Can we expect the same during other "evasive" maneuvers too? Like loosing or gaining altitude rapidly, or changing direction rapidly? Or only during notching maneuvers?

:thumbup:

Thanks, good to know!

 

Can we expect the same during other "evasive" maneuvers too? Like loosing or gaining altitude rapidly, or changing direction rapidly? Or only during notching maneuvers?

 

:thumbup:

The TWS algorithm only tracks position and velocity (as change in position over time), and only dead-reckons based on that too. Acceleration is not calculated, tracked or (obviously therefore) used in any calculations, so any target with large acceleration vector (e.g. due to tight turns etc.) can cause a mis-correlation with a previous track and establish a new track. Taken together with TWS only getting observations on a target every 2s, one can see how rapidly maneuvering targets cannot be tracked.

Some of the observations posted do look suspect however, but I also think there could be other factors involved in some of the cases, such as MP rubberbanding (if the position of the object jumps forwards and backwards, you imagine what that does to the calculated velocity vector).

Just to clarify, having ghost tracks appear in situations where the radar is and should have trouble keeping track of targets is realistic and intended.

 

We are also looking at track generation in general but what we currently have is quite close to how it is described in our documentation.

 

The main issue here that is clearly a bug and wrong is where targets generate a lot of spurious ghosts in situations where they shouldn't.

Thanks for taking the time to check! I've made another track file and took a video of a single-player mission against 4x Tu-22M3s to check to see if the “freak out” against co-altitude/straight flight targets it is MP related.

During my first run of the mission, I only got the weird ghosting when the bandits started to react, dropping altitude quickly and notching, which based on this thread's conversations, is correct radar behavior. However, on my second run, no changes to the setup, it did its freakout while the four-ship was flying straight and level until about 55NM away. At this point, TWS stopped having a conniption, but had difficulty discerning the returns, and they were close enough that this was anticipated as well. By about 45 miles or so, the radar could discern two contacts on TWS. After firing a Phoenix at both, everything held for a few seconds, then the bad contacts started coming again.

In this case, I started receiving bad contacts before the bombers had really gotten into their defense. In the video, you can see the first bad return flying in the wrong direction and I swap the camera over to the bombers – none of them are near the notch yet, and have just started diving away. As they get into their defense, all bets are off, as I’d expect, because they are all now trying to deny my radar.

So, the takeaway I have from running this is that yes, TWS-A can still, for some reason, freak out even in SP against a co-altitude, non-maneuvering, non-defending target. That said, in the first run, it didn’t mess up until the expected enemy defense. On the second run, it did upon detecting the bandits.

I hope this helps with your assessment.

Video here:

TWS-A_Test_Track_1.trk

Had a look at that video with our radar guy and it has us a bit stumped.

 

We're kinda thinking we might be dealing with multiple issues.

One thing that interests us with that video in particular is that you seem to have gone A/G for a short while there, I guess maybe you wanted to wipe the targets? We really haven't tested that as you'd never do that IRL as switching means you're loading a physical magnetic tape which always runs a risk of failing (not modelled but still). Still doesn't mean that should happen so we will look into that.

 

Our main lines of reasoning atm is that we might be looking at one issue in mp relating to rubberbanding and lag, one in sp where it relates to positioning of targets and or doing other stuff we hadn't thought of in the cockpit.

 

We'll have to test this stuff more to try and find out.

 

Additional bug reports will help ofc, try to mention if it was in sp or mp and if with a human RIO or not. If in sp a copy of the mission and how you got it to happened helps.

 

Unfortunately I'll be out of the loop until late friday this week due to RL but feel free to post anyway, if not sooner I'll have a look next weekend.

Me hitting into A/G was actually just a mistake, I usually fly in VR, so using Trackir was causing me some issues controlling where I was looking, as I also have no way to zoom bound.

A similar situation happened in an earlier run where I only flipped it to A/A to fire off the missiles.

As best I can tell, things that make it more likely to happen are:

Firing a Phoenix

Target maneuvering hard

F-14 maneuvering (especially rolling)

Multiple targets near each other

Attached are two tracks from multiplayer where both players saw the aforementioned TWS strangeness, Tacview from the server is also included, so you can see the "trueish" position of everything.

Aircraft were both pilot only, with Jester as RIO, have seen this same thing happen with RIO's as well. Don't have a track of it currently though. All enemies were AI.

https://drive.google.com/file/d/1Ay5BqIJAUW0U3rIRlIjtV_M93bjlwB4D/view?usp=sharing

https://www.dropbox.com/s/3z89fb085c09gum/PracticeMission_PG2-20200416-202851.trk?dl=0

https://www.dropbox.com/s/7irqss5xs3jll5m/Tacview-20200416-214531-DCS-PracticeMission_PG2.zip.acmi?dl=0

You can see the fake high velocity tracks getting created and TWS-A freaking out and trying to hold them.

The TWS algorithm only tracks position and velocity (as change in position over time), and only dead-reckons based on that too. Acceleration is not calculated, tracked or (obviously therefore) used in any calculations, so any target with large acceleration vector (e.g. due to tight turns etc.) can cause a mis-correlation with a previous track and establish a new track. Taken together with TWS only getting observations on a target every 2s, one can see how rapidly maneuvering targets cannot be tracked.

 

Some of the observations posted do look suspect however, but I also think there could be other factors involved in some of the cases, such as MP rubberbanding (if the position of the object jumps forwards and backwards, you imagine what that does to the calculated velocity vector).

Makes sense, as the only times this happened in my flights were when:

1. The target went into the notch;

2. Target was diving-climbing rapidly in a hard maneuver

3. The F-14 was maneuvering "hard", and not just rolling, also in the pitch.

I haven't really tried a mission with multiple bandits yet, so i can't comment on that.

One thing that remains puzzling though, is that this tends to happen more often at closer ranges then longer (EDITED by poster) ranges, even when a missile hasn't been fired, and the target has no reason to go defensive. But i'll have to experiment more with passive targets to double check this.

Had it yeasterday on our MP server flying as RIO as part of a three-ship F14B in CAP over the Persian Gulf.

AI Mig29s come towards us and we engaged, shot at 45Nm, crank to the left. At time of missile employment, the targets sprouted numerous false contacts. We just believed it to be ECM but it makes correlating targets quite difficult.

This was in a head-on engagement, daylight, 32000 feet, 1 human RIO and 2 Jesters. One humand failed to get a phoenix off the rail, the other two fired one AIM54 each and later another one.

We did not experience noticeable lag this event, it was restricted to 30 pilots max and was not played on the latest Beta build but on the 45915 version.

Here is my reproduction

Target was a 4 ship of MiG-29A flying at 4000m at Mach 0.8 in Line Abreast 2743m x 0m, no chaff was given to them and their task was set to 'Nothing' and they were forced to not react.

Started by swapping to Pulse Search to make sure the TID was cleared, then swapped to TWS. It seems like in certain target formations the AWG-9 needs to decide which cluster of returns to group as a track, as it flip flops between choices it can seem like the target is doing an erratic instant movement which can cause the track to disassociate from the returns at a high velocity, in this case targets were flying at Mach 0.8 and ghost targets were around Mach 4.

Unsure of the real capabilities of the AWG-9 but maybe something like a velocity filter for tracks would fix it, ignore anything over ~Mach 3 to 3.5 for example? Ideally an acceleration filter or at least a velocity delta from the last TWS scan frame filter would be added but it sounds like from an above message the AWG-9 doesn't have that capability.

F-14 Ghost Tracks.miz

F-14 Ghost Tracks.trk

One theory we're trying to work around is that it might be related to lag in mp. Have anyone of you guys had this issue in SP or is it only MP and do you have any recollection of general lag when it happens. (rubberbanding etc)

I flew the Tomcat exclusively in MP from the backseat and I have seen such odd pictures on my TID quite regularly:

I'm usally flying on big MP servers like Blue Flag, which makes it pretty difficult to get a good track file.

Sometimes I do fly smaller coop missions against AI and I don't think I've ever encountered this issue there, although I'm not entirely sure. I will keep an eye on when exactly this happens from now on.

Here is my reproduction

 

${1}

 

 

Target was a 4 ship of MiG-29A flying at 4000m at Mach 0.8 in Line Abreast 2743m x 0m, no chaff was given to them and their task was set to 'Nothing' and they were forced to not react.

 

Started by swapping to Pulse Search to make sure the TID was cleared, then swapped to TWS. It seems like in certain target formations the AWG-9 needs to decide which cluster of returns to group as a track, as it flip flops between choices it can seem like the target is doing an erratic instant movement which can cause the track to disassociate from the returns at a high velocity, in this case targets were flying at Mach 0.8 and ghost targets were around Mach 4.

 

Unsure of the real capabilities of the AWG-9 but maybe something like a velocity filter for tracks would fix it, ignore anything over ~Mach 3 to 3.5 for example? Ideally an acceleration filter or at least a velocity delta from the last TWS scan frame filter would be added but it sounds like from an above message the AWG-9 doesn't have that capability.

I think you've found one of the issues right there. It looks like the radar is assuming those nearby targets are actually a single moving target, which is what's making it freak out and generate lots of ghost targets. I don't think that should happen, but it's just my guess that the designers would have optimized TWS track generation for multiple non-maneuvering targets near each other.

Here is another example of it happening in a 2 ship formation with the same setup as my previous example:

Based on more testing in singleplayer, it looks like it's almost exclusively caused by targets located close to each other, and the TWS track generator freaking out and thinking two or more nearby target returns are actually one extremely fast target. This can also be triggered by a single target defending hard enough that it's picked up multiple times in one TWS scan, or the F-14 maneuvering enough to cause the same effect.

This is doubly troublesome in multiplayer where even a tiny amount of lag can cause subtle rubberbanding, which can ALSO cause the same issue. Compounded with the previous effects, this makes using TWS in multiplayer very difficult.

Edit: The AWG-9 has trouble breaking out targets in TWS until they're about 2.3-2.5 degrees separated in AZ/EL (even if they're significantly separated in doppler return) when they move into/out of that threshold there's a chance the weird ghost targets show up, or more accurately it seems that anytime the TWS has to make a determination on whether they're one or more targets, it can cause this problem. Also interestingly, targets within 5NM of each other and within that ~2.3 degree AZ/EL area are shown as one return in RWS or TWS, but will show up very clearly separated in PDS if their speeds are different. This is especially curious for cases where there are 5+ targets within 5NM of each other, as they show up as a single tiny bar on the DDD in RWS/TWS, but will show as a large blob in Pulse search or PD search (assuming they're at different speeds).

Made this test earlier today, but now did i get the chance to upload it. It seams like the proximity of the contacts, the number of contacts, relative elevation and ground clutter don't contribute to the "ghost track" creation. At least not in SP. My guess is, it works as it should.

Haven't tried firing at he bandits though.

What Quigon sees in MP server, we see on our servers but less severe. We will be running a couple of tests later on to see if we can replicate the behaviour.