[BUG] Radar TWS wierdness

Chaff?

A track would be more useful.

Chaff?

A track would be more useful.

Ran it again with similar results. Attached is the track file.

TWS-A_Test_Track.trk

Chaff?

A track would be more useful.

Even in my original post chaff was not used. It isn't the cause.

Even in my original post chaff was not used. It isn't the cause.

Concur, it isn't chaff. When I mentioned that, I was remarking that when I switched to PAL it would pick up chaff, which I anticipated it would because I've seen it before, then confirmed later tonight with another player. TWS never was doing so. Also, I was able to test TWS-A with a human RIO on MP tonight. Unfortunately, the massive track-offs happened and made the mode unusable. Didn't get a track file, but did take video. Will post vid and details at a later time.

Hello Again!

 

With TWS-A, I was definitely stoked to actually be able to launch a Phoenix at someone and more properly crank away, rather than trying to hold the guy ~+/-20 degrees off center-line. But, this whole "track-off" thing is really throwing a wrench into that ability. I went ahead and made a video from a single-player 1v1 test of TWS-A. I ran the scenario twice and it executed exactly the same both times. The video is from the second test. Because this is a potential bug, I made this an unlisted video. The "target" aircraft was a Mirage 2000C.

 

At the start of the video, I tell Jester to select TWS even though he's already in it just to keep him in it (I don't want him to switch out). I fire the first AIM-54 at 1:03 and take an offset to the right, very slowly and not too extreme because I'm still testing the mode, allowing the radar to maintain track (still smiling that it can do this). I then pull back across, bringing the nose back left, and the target is now offset right of the nose. As I level off, the trouble starts.

 

At 1:36, the radar will generate another (false) return which tracks off of the actual target very rapidly. TWS-A attempts to track the false target and pulls itself off of the actual return. At about 1:55, I pull to put the proper return on the nose, and the radar continues trying to chase the false return. I switch to PAL, then back to TWS-A and the radar reacquires the original return. At 2:40, I fire at the original return again, which then turns into a bad track, and the radar again goes chasing a false target. At 2:55, I switch to PAL, and the radar continuously is picking up chaff packets (expected behavior for a pulse mode), until I eventually find the target (when he fires a Fox 2 at me) and shoot it down with a pair of AIM-9Ms.

 

I don't know what is causing this, and I will need to do a lot more testing, but if this false return stuff isn't supposed to happen I can see it breaking TWS-A functionality because the radar keeps getting pulled off by a bad return and keeps adjusting relative to that return. If it gets multiple bad returns (like in OP's picture and as I've experienced before), I'm not sure what the behavior will be, but it certainly won't be good. Will see if I can simulate that.

 

Other notes: I was using the AIM-54C, and did NOT have an AWACS.

 

Video here:

 

Hope this helps figuring out the strange behavior, and keep up the good work, HB!

I am experiencing the same, however TWS-A locks onto the correct contact once it reappears.

I hope that the lost contact behavior going away from the screen is a bug and will be fixed in the future. It also takes away the TTI with him :lol:

I found similar results in my recent tests. If a single target is flying straight and level at you, you can crank all you want and the track remains correct. As soon as the target starts cranking/defending, you get the ghost tracks. In Quids video, I suppose the ghost tracks appear as soon as the Phoenix went active and the target started defending.

Another problem is with two aircraft close to each other. At long range (say 50nm), you will only see on track which however has a rather high chance to start flying off the screen as the radar probably picks up the other target but assumes it is the same target and calculates some faulty velocity for the original target.

I'm a little unsure though if this is realistic behaviour. On the one hand this is 60's technology here and I remember an F-14 driver saying on some YT video that the F-14 was good at picking up targets far out but wasn't really good at tracking maneuvering targets in contrast to more modern radars.

On the other hand, there should be some logic to detect excessive changes in track speed and direction and discard them.

Given the enormous effort HB has put into the F-14 I'm however afraid the current behaviour is more or less accurate :/

I found similar results in my recent tests. If a single target is flying straight and level at you, you can crank all you want and the track remains correct. As soon as the target starts cranking/defending, you get the ghost tracks. In Quids video, I suppose the ghost tracks appear as soon as the Phoenix went active and the target started defending.

Another problem is with two aircraft close to each other. At long range (say 50nm), you will only see on track which however has a rather high chance to start flying off the screen as the radar probably picks up the other target but assumes it is the same target and calculates some faulty velocity for the original target.

I'm a little unsure though if this is realistic behaviour. On the one hand this is 60's technology here and I remember an F-14 driver saying on some YT video that the F-14 was good at picking up targets far out but wasn't really good at tracking maneuvering targets in contrast to more modern radars.

On the other hand, there should be some logic to detect excessive changes in track speed and direction and discard them.

Given the enormous effort HB has put into the F-14 I'm however afraid the current behaviour is more or less accurate :/

We did some more experimentation last night and it does seem that when a target starts defending that can cause the bad track, however, we also tested it where (with a human RIO), we were closing on two non-maneuvering, co-altitude targets and I did not fire. The radar started doing its "tracks everywehere" thing and they were not defending, just flying straight and level. It happened twice, and both times, TWS-A became unusable even with the RIO trying to re-assign "must track" repeatedly back to the original targets. That was MP, but was PvE, so it wasn't a player reacting to being painted, and like I said, the AI hadn't gone defensive. Track file is 145MB so I can't post it, but I did take video and will post that hopefully later tonight to show what was happening.

we were closing on two non-maneuvering, co-altitude targets

Did the radar show one or two tracks in that situation? If it showed only one, I suspect it will pick up the second target at one point but will not create a seperate track for it, hence the track first track going nuts.

Okay, so, this is the video I took; like I said, the track file is 145MB and is a multiplayer track file so I have no idea how useful/corrupted it will be, but it's larger than what I can post here. I don't have our audio because there was some colorful language going on with all of the ghosting, but the text at the top describes what is happening. The pertinent data I can think of:

Crew: Both players (human pilot/human RIO)

AWACS: Yes (human)

Datalink: Yes initially, the RIO turns it off as noted in the video text

Bandit actions: Flying straight and level, roughly co-altitude. Never go defensive until AIM-54s are launched in PDSTT (watched on TCS), so there are no notching attempts, chaff, diving towards the deck, etc. while in TWS-A for all four bandits (2x MiG-23, 2x F-5E)

NOTE: The RIO could see normal returns on the DDD, even with TWS-A freaking out. This is how we eventually went to PDSTT.

If there's anything else you think might be useful, please let me know.

Video here:

As to defensive maneuvering/jamming/etc, I do have another track file from further experiments with another player, but basically, yes, if the adversary manages to notch the radar, it can produce a track-off, but it was always a single. Will try to upload that later.

Thanks for the vid hopefully with all the posts here recently this issue will get some traction and be fixed asap.

Those are weird observations indeed. I used TWS auto with Jester for the first time tonight and while i did observer the ghost contacts on few occasions, it was nowhere near as dramatic......but.....i was in SP and testing only against a single AI bandit. The Ghost usually appeared at closer ranges, mid, to low 20's NM. But i didn't degrade my missile shots performance. And it never happened while actually maneuvering. Just when the target went defensive. I should have recorded the video.

I started at 60+ NM 25000ft, coaltitude with the F-15. I rolled about 45 degree to the left and climbed to 35000ft, then leveled off and accelerated as much as possible. At around 40-45NM i cranked into the bandit, fired an AIM-54C, then dropped the nose about 30 degrees down. Then i slowly introduced a right roll to crank away, while going engine idle. At around 26 NM from the bandit the ghost contact appeared and started moving away. I leveled my nose, the radar picked the target again, above me, little to the left and 24 NM away. I fired off the 2nd Phoenix and proceeded to crank right to gimbal limits (i received his missile warning - an AIM-120C). The 2nd missile did get him as i evaded the AMRAAM. I tried the same tactic again, and the next HOP, it was the first missile that got him. So i'm not sure if the missiles are affected by this, or is it only the display.

If i go for a look up situation and stay bellow him the entire time, the Ghost almost never appears.

I have a feeling this has something to do with the update rate of the radar simulation, and might be made worse by the multiplayer syncing between the rio and pilot regarding the radar.

This is really something that needs a look from Heatblur so we can figure out if we're crazy or not.

Happens easily in SP so nothing to do with MP synch. My feeling is that's realistic. Even more modern radar's TWS are not perfect at tracking multiple maneuvering targets close to notch.

Happens easily in SP so nothing to do with MP synch. My feeling is that's realistic. Even more modern radar's TWS are not perfect at tracking multiple maneuvering targets close to notch.

When defending, certainly, but if you check the videos and discussion, it's happening when aircraft are straight and level, doing nothing to defend. I don't think that's even remotely realistic.

Happens easily in SP so nothing to do with MP synch. My feeling is that's realistic. Even more modern radar's TWS are not perfect at tracking multiple maneuvering targets close to notch.

Here's that vid. It does happen when the target defends, that's for sure.

Next step, trying it with multiple bandits

Mind explaining why the DDD always gets the returns right without any ghosting? That is not realistic.

Might actually be a display issue?

Happens easily in SP so nothing to do with MP synch. My feeling is that's realistic. Even more modern radar's TWS are not perfect at tracking multiple maneuvering targets close to notch.

As has been posted in the thread already, you can test targets close to notch who maneuver and this specific behavior doesn't happen.

You'll lose targets as they go into the notch, but they just fade out and reappear once they come out of the notch.

This behavior is specifically talking about the TWS track compiler freaking out and either extrapolating the track as suddenly going Mach 30+, generating 5+ tracks out of nowhere and then immediately fading them all out, or generating 1 or more tracks in the exact same place/heading/speed as the current track while losing the current track.

None of which seems like realistic behavior... TWS-A makes some of these especially obvious, as the computer will freak out and jiggle the radar azimuth all over the place and flicker back and forth between the TWS scan types as it struggles to keep track of an extrapolated target going hundreds of NMs per second.

Here's that vid. It does happen when the target defends, that's for sure.

Next step, trying it with multiple bandits

It would help if you either removed the stick from view (backspace) or watched the track file instead so you can monitor the bandit and the TID to find out what's actually going on.

It would help if you either removed the stick from view (backspace) or watched the track file instead so you can monitor the bandit and the TID to find out what's actually going on.

That's a very good point, if you can believe it, i actually forgot i have Tacview :doh:

Unfortunately, as tracks have been broken for ages, i didn't save this one (recorded it in real time). I guess i'll have to fly the mission again.

There was an actual RIO that did a Livestream with a DCS group recently. It would have been nice if someone had asked about whether this behavior was normal with the TID.

Attached is an image from an op we flew tonight that shows just how bad this can get. This is a shot of the TID with us in TWS Manual looking at two non-maneuvering enemy aircraft just prior to us hitting our launch distance. This doesn't seem like normal behavior at all, and I'd really like a response from someone at Heatblur on if this is/isn't intended behavior.

Edit for more info: These aircraft were both roughly co-altitude and hot on us, but the TWS tracks that spawned out of them are flying off to the right/left.

Just read a great RIO site (https://flyandwire.com/2019/09/02/f-14-tdi-aircraft-stabilized/) where interpreting what is shown on the display is discussed and apparently, in a/c stabilised modes you are seeing relative vectors displayed, not target speeds ... is this what you are seeing in that screen cap as the target manoeuvres?

When I read what was discussed, my thought was: oh no too much maths!

Just read a great RIO site (https://flyandwire.com/2019/09/02/f-14-tdi-aircraft-stabilized/) where interpreting what is shown on the display is discussed and apparently, in a/c stabilised modes you are seeing relative vectors displayed, not target speeds ... is this what you are seeing in that screen cap as the target manoeuvres?

 

When I read what was discussed, my thought was: oh no too much maths!

No, what's shown here are two non-maneuvering targets who were flying straight and level.

The right target was hot, we're approaching him from his 11 o clock. The left target was also hot, nose onto us, but both aircraft were flying relatively slow (250 or so knots), and we're also in the middle of climbing, so we're at a relatively low speed as well (200 or so knots).

Those insanely long relative velocity lines would indicate the target is flanking us at well over 2-3 times the speed of sound, which just doesn't make sense.

 

Attached is an image from an op we flew tonight that shows just how bad this can get. This is a shot of the TID with us in TWS Manual looking at two non-maneuvering enemy aircraft just prior to us hitting our launch distance. This doesn't seem like normal behavior at all, and I'd really like a response from someone at Heatblur on if this is/isn't intended behavior.

 

 

Edit for more info: These aircraft were both roughly co-altitude and hot on us, but the TWS tracks that spawned out of them are flying off to the right/left.

I would have to agree. That is a bit ridiculous and certainly not a "one off" event.

Hi guys!

I'd just like to jump in here and say that we're definitely looking at this but we're having a great deal of difficulty reproducing it on our side.

It's unlikely to be due to the INS and it's not jamming. It is for certain possible to have ghost tracks when you have bandits flying close to each other and skirting around the distance where the radar can tell them apart but not at this level.

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)

We'll keep working on this for sure.