AWG-9 TWS-A Active Track weighting issues, and other general performance problems

[DoorMouse]

@Naquaii Opening up a new thread on this per our other exchange. Appreciate it, as always.

 

With the changes to the Phoenix, Potential new API and INS/Active capabilities, and hopefully some guidance fixes in the near future, its going to be ever more important to make sure that the missiles you fire actually go active and have a chance of connecting. There are multiple issues which plague the AWG-9 and have for a very long time, but were hard to track down and form a good hypothesis on, but are the source of frustration for most of the complaints about both Jester, and the AWG9. Having several thousand hours in the simulation, i've noticed patterns, and have been recording them. 

I'll try to make clips of all of these, and happy to work on some way of reproducing or finding track/tacview files. Just let me know what you need

 

• TWS-A weighting causes the most threatening target to often be removed from its volume. Active Missiles being pulled out of the scan volume by new contacts appearing at extremes of Azimuth and/or Elevation is the worst of this bug. This is the first one I'll cover in hopes we can track down a resolution. 
   
• Momentary 'network' issues causing targets to look like they are traveling very fast and disassociating otherwise compliant targets. I don't know how you solve this. Perhaps smoothing out the requirements to maintain a lock to be slightly more forgiving than the real life radar?
   
• Sometimes the track will simply not display a TTI - It is in TWS properly, and once the missile is fired no time indicator will display. Sometimes if you wait long enough it will appear with an inappropriate number (120 seconds, for a 20 mile shot) and then rapidly count down. I think this is associated with the issue above, where if you fire when that target is having network issues it screws up. I also have this one on video.
   
• Getting TWS Tracks/Jester Operation. Jester is not particularly smart about "High" contacts and will not scan/find Data Link/AWACS targets that are 30,000+ at <40mi unless explicitly told to do so.  He should recognize that data link contacts are also a threat and TWS Manual to the largest threat. Once you do find it, it is often subject to the same weighting issue once you get a track.
  
  This is just a quality of life thing but also causes some real head scratching moments where you cannot get a track without a lot of knowing how to fudge jester's operation- IE Telling him to scan up at 45,000/ feet on a 30,000 bandit so he wont start picking up low contacts.
  
   

To Illustrate what I am talking about, here is a horrible set of diagrams, and a video i've compiled of 3 scenarios which all happened in the same session last night. As I had said before, this happens multiple times a day every day. Its a pervasive and repeatable issue. 

1. Track built on bandit at Alt-3 band,  prioritized as #1 target
2. Track built on bandit at Alt-2 band, prioritized as #2 target
3. New target appears at Alt 2 band but further away, prioritized as #3 Target, TWS-A slews down, now bringing targets 4-5 in the Alt-1 band into the volume
4. TWS-A slews down, causing #1 target to be removed from the volume, and the track is trashed. 

This regularly happens with TWS Tracks and fairly consistently even with Active missiles.  This happens in both Altitude and Azimuth adjustments

Here is an issue illustrating some examples of this in operation (I've removed the audio because its 99% me using profanity when these issues occur): 

 

Edited January 31, 2022 by DoorMouse

[ldnz]

Yep this one drives me nuts. I've taken as rio to binding 'do not attack' CAP button and mashing it on every new track I can see before the radar slews over to it. I especially hate it when it slews towards a track at ~100nm and trashes my missile that was on a high threat at ~30nm. Surely active guided tracks should have priority. 

Re de-sync and dropped tracks - me and my pilot have just given up on at least the first missile in any fight as its almost guaranteed to suffer immediate track loss. I assume there is a slight hesitation as the missile spawns, textures load or something, but again its enough for a single missed sweep and wasted launch. 

[Nazgul 1-2 -Kjell-]

vor einer Stunde schrieb DoorMouse:

@Naquaii Eröffnen Sie dazu einen neuen Thread für unseren anderen Austausch. Schätze es wie immer.

 

Mit den Änderungen an Phoenix, potenziellen neuen API- und INS/Active-Fähigkeiten und hoffentlich einigen Leitfäden in naher Zukunft wird es immer wichtiger, sicherzustellen, dass die Raketen, die Sie abfeuern, tatsächlich aktiv werden und eine Chance haben, sich zu verbinden . Es gibt mehrere Probleme, die die AWG-9 plagen und die es schon seit sehr langer Zeit gibt, die aber schwer aufzuspüren und eine gute Hypothese zu bilden waren, aber die Quelle der Frustration für die meisten Beschwerden über Jester und die AWG9 sind. Nachdem ich mehrere tausend Stunden in der Simulation verbracht habe, habe ich Muster bemerkt und sie aufgezeichnet. 

Ich werde versuchen, Clips von all diesen zu machen, und arbeite gerne an einer Möglichkeit, Track-/Tacview-Dateien zu reproduzieren oder zu finden. Lassen Sie mich einfach wissen, was Sie brauchen

 

• Die TWS-A-Gewichtung bewirkt, dass das bedrohlichste Ziel oft aus seinem Volumen entfernt wird. Das Schlimmste an diesem Fehler ist, dass aktive Raketen durch neue Kontakte, die an Extremen von Azimut und/oder Elevation erscheinen, aus dem Scanvolumen herausgezogen werden. Dies ist die erste, die ich behandeln werde, in der Hoffnung, dass wir eine Lösung finden können. 
   
• Vorübergehende „Netzwerk“-Probleme lassen Ziele so aussehen, als würden sie sich sehr schnell fortbewegen, und ansonsten konforme Ziele werden getrennt. Ich weiß nicht, wie du das löst. Vielleicht die Anforderungen glätten, um eine Sperre aufrechtzuerhalten, damit sie etwas fehlerverzeihender ist als das Radar im wirklichen Leben?
   
• Manchmal zeigt der Track einfach kein TTI an - es ist richtig in TWS, und sobald die Rakete abgefeuert ist, wird keine Zeitanzeige angezeigt. Manchmal, wenn Sie lange genug warten, erscheint es mit einer unangemessenen Zahl (120 Sekunden für einen 20-Meilen-Schuss) und zählt dann schnell herunter. Ich denke, dies hängt mit dem oben genannten Problem zusammen, bei dem es Probleme gibt, wenn Sie feuern, wenn dieses Ziel Netzwerkprobleme hat. Das habe ich auch auf Video.
   
• Abrufen von TWS-Tracks / Jester-Operation. Jester ist nicht besonders schlau in Bezug auf "hohe" Kontakte und scannt/findet Data Link/AWACS-Ziele mit mehr als 30.000 auf <40 Meilen nicht, es sei denn, er wird ausdrücklich dazu aufgefordert. Er sollte erkennen, dass Datenverbindungskontakte auch eine Bedrohung darstellen und das TWS-Handbuch die größte Bedrohung darstellt. Sobald Sie es gefunden haben, unterliegt es häufig demselben Gewichtungsproblem, sobald Sie einen Titel erhalten.
  
  Dies ist nur eine Sache der Lebensqualität, verursacht aber auch einige echte Kopfkratzmomente, in denen Sie keinen Track bekommen können, ohne viel zu wissen, wie man Narrenoperationen fummelt - IE Ihm sagen, er soll bei 45.000 / Fuß auf einem 30.000-Banditen scannen, damit er es nicht tut Fangen Sie an, niedrige Kontakte aufzunehmen.
  
   

Um zu veranschaulichen, wovon ich spreche, hier ist ein schrecklicher Satz von Diagrammen und ein Video, das ich aus 3 Szenarien zusammengestellt habe, die alle in derselben Sitzung letzte Nacht passiert sind. Wie ich schon sagte, passiert dies jeden Tag mehrmals am Tag. Es ist ein allgegenwärtiges und wiederholbares Problem. 

1. Auf Bandit auf Alt-3-Band aufgebauter Track, priorisiert als Ziel Nr. 1
2. Auf Bandit auf Band Alt-2 aufgebauter Track, priorisiert als Ziel Nr. 2
3. Ein neues Ziel erscheint im Alt-2-Band, aber weiter entfernt, priorisiert als #3-Ziel, TWS-A schwenkt nach unten und bringt nun die Ziele 4-5 im Alt-1-Band in das Volumen
4. TWS-A schwenkt herunter, was dazu führt, dass das Ziel Nr. 1 aus dem Volume entfernt wird und der Track zerstört wird. 

Dies passiert regelmäßig mit TWS Tracks und ziemlich regelmäßig sogar mit Active Missiles. Dies geschieht sowohl bei Höhen- als auch bei Azimuth-Anpassungen.

Hier ist ein Problem, das einige Beispiele dafür in Betrieb veranschaulicht (ich habe das Audio entfernt, weil ich zu 99 % Obszönitäten verwende, wenn diese Probleme auftreten): 

 

 

Can only confirm the listings and to the first example I can say it helps to keep the TID range as small as possible e.g. TID50 so that the targets are no longer tracked above it.

[Naquaii]

I've forwarded this to our radar guy.

Just to clarify, the radar should still try to track new non-engaged targets but it should never allow that to affect the targets under missile attack. The WCS assigns each track a weight which determines where the center of gravity of the scan zone will end up and when a track is under missile attack it will recieve a weight that always gives it prio over non-engaged tracks. So the only thing that should make the WCS drop an engaged track is if they split or otherwise end up in situation where it's not physically possible for the scan zone to encompass both. Within those limits it will also try to follow non-engaged tracks if possible.

It could be that we need to tighten this up even more or that desync somehow affects this but looking at your video it definitely looks like the WCS allow the non-engaged tracks to affect the scan zone steering too much.

[DoorMouse]

1 minute ago, Naquaii said:

I've forwarded this to our radar guy.

Just to clarify, the radar should still try to track new non-engaged targets but it should never allow that to affect the targets under missile attack. The WCS assigns each track a weight which determines where the center of gravity of the scan zone will end up and when a track is under missile attack it will recieve a weight that always gives it prio over non-engaged tracks. So the only thing that should make the WCS drop an engaged track is if they split or otherwise end up in situation where it's not physically possible for the scan zone to encompass both. Within those limits it will also try to follow non-engaged tracks if possible.

It could be that we need to tighten this up even more or that desync somehow affects this but looking at your video it definitely looks like the WCS allow the non-engaged tracks to affect the scan zone steering too much.

Thanks!

It looks like Active tracks have 5 points of weight. Which with 5 targets, is acceptable.  But with the maximum of 24 targets, its 23 v 5, so the computer says - Not as important as tracking those guys way over there...

Edited January 31, 2022 by DoorMouse

[Katsu]

This is a recurring problem.

I can say that several times the radar behaved in this way, giving priority to targets that it shouldn't.

[Naquaii]

4 minutes ago, DoorMouse said:

Thanks!

It looks like Active tracks have 5 points of weight. Which with 5 targets, is acceptable.  But with the maximum of 24 targets, its 23 v 5, so the computer says - Not as important as tracking those guys way over there...

 

Yeah, and if that's actually the case it's wrong, no amount of other tracks should be able to outweight an engaged target ofc so yeah.

[ldnz]

One possible subtlety here is the track sweep time. Lets say you've got a track at the center of the sweep pattern, and the antenna has just moved over it moving left. If the computer swings the pattern left to follow a new track - the antenna has to go all the way to the new edge and back. Does this make it take longer than the strict 2 second refresh time?

[DSplayer]

Oh I remember this issue! I always hated having to deal with that, especially when the WCS decides to start using TWS 2 bar 40 degree scan and basically drop everyone in the scan volume. I've experienced this ever since like December of 2020 when I first got the module? This issue, on top of the volatility of the AWG-9 tracking targets on MP servers, made multishot TWS Phoenixes basically gambling but with worse odds than the Powerball.

A way I did to work around this was to switch the TID range to the closest it could get to the target that I had just fired at while also keeping a TWS Auto track. That really helped me out against like people taking off from an airfield 40nm behind someone that I'm shooting down at. Another way of course is reaching all the way into the back and grab the HCU from Jester's hands and start marking stuff as 'Do Not Attack' but that's a bit more complicated.

Edited February 1, 2022 by DSplayer

[ldnz]

Does TID range actually affect tracked targets? I don't think it does - I'm sure i've had the system decide that tracks at greater ranges were high priority. 

[sLYFa]

It does, TWS auto only uses the tracks visible in the current TID range. 

[Naquaii]

Ok, so after watching the video and thinking about it my thoughts are that, firstly, we need to differentiate between when you have a TMA (target under missile attack) or not.

When you don't (and don't use mandatory attack) there's really not much differentiating the tracks from each other so the WCS will simply steer the scan zone towards the greatest concentration of tracks. This is just how it works, the WCS simply had no algorithms for deciding what was the greatest threat etc, that's a limitation it had afaik.

When you do however have a TMA it should afaik never let that go unless there's another TMA on the other side of the scan zone forcing the WCS to choose between them. If you have multiple mandatory attack tracks this can also happen but you'd need at least 2x as many of those as TMAs on the opposite side.

Watching the video what I see in the first two cases shouldn't happen afaik so we need to look at that. The third and last case seem to me to be a case of excessive maneuvering, that said it could still also be something else but a roll like that in TWS is ill-advised. In TWS you need to avoid anything but level flight or careful slow maneuvers.

We'll discuss this internally and see what we come up with.

[DoorMouse]

3 hours ago, Naquaii said:

Ok, so after watching the video and thinking about it my thoughts are that, firstly, we need to differentiate between when you have a TMA (target under missile attack) or not.

When you don't (and don't use mandatory attack) there's really not much differentiating the tracks from each other so the WCS will simply steer the scan zone towards the greatest concentration of tracks. This is just how it works, the WCS simply had no algorithms for deciding what was the greatest threat etc, that's a limitation it had afaik.

When you do however have a TMA it should afaik never let that go unless there's another TMA on the other side of the scan zone forcing the WCS to choose between them. If you have multiple mandatory attack tracks this can also happen but you'd need at least 2x as many of those as TMAs on the opposite side.

Watching the video what I see in the first two cases shouldn't happen afaik so we need to look at that. The third and last case seem to me to be a case of excessive maneuvering, that said it could still also be something else but a roll like that in TWS is ill-advised. In TWS you need to avoid anything but level flight or careful slow maneuvers.

We'll discuss this internally and see what we come up with.

Just so it's clear, that roll at the end happened AFTER  the tracks trashed and I went defensive. The only maneuver I did during the TMA period was roll Port and hold a crank. You can see the artificial horizon on the TID. You can see it has that track way over on the right side of the TID which is pulling the TMA to the extreme edge of the gimbal, and eventually trashes it.

Its really easy to see with discrepancies in Azimuth, but honestly the worst examples are when this happens with Altitude. There is nothing more frustrating and potentially game ruining as having a target at 30 miles, 1,200knots closure, under TMA, get trashed because something 90 miles away popped up and pulls the radar down. It obviously screws up your timeline, and then you die. 

 

I have another example from last night I need to record. But in short, there was a TMA on the left and a Track on the right... Once the right track dropped the radar snapped back to have the TMA center mass again. I had the thought that the computer isn't applying different weights to TMA tracks and queued TWS tracks...  Sounds like that is what you were saying. 

For differentiating more hostile threats - I had thought that since it does have some logic for re-ordering 1,2,3,4 based on Closing speed, distance, etc.  That it could weight target 1 more than target 5?  but I guess not. It would be interesting to see how the computer decides who is target 1,2,3 etc.

Edited February 2, 2022 by DoorMouse

[WhiteRabbit]

On 1/31/2022 at 8:00 PM, ldnz said:

One possible subtlety here is the track sweep time. Lets say you've got a track at the center of the sweep pattern, and the antenna has just moved over it moving left. If the computer swings the pattern left to follow a new track - the antenna has to go all the way to the new edge and back. Does this make it take longer than the strict 2 second refresh time?

This is something I'm really curious about. I know I've seen cases where TWS-A will have a TMA track, then adjust scan volume slightly to include a new contact, and almost instantaneously drop the TMA even though it seems to be inside the scan limits. I say I suspect it's still inside the scan limits because on the next pass the system will immediately place a fresh contact right on the broken/held track (and fail to associate them).

I think a similar phenomenon is the dreaded "I dropped your track the instant you foxed on it". Maybe because changing to a TMA caused the WCS to readjust weights which caused it to reset the scan volume which caused it to drop the TMA due to a refresh timer error or the like?

It raises a few questions for me:

• What level of abstraction are you using to model the AWG-9's raster scan? Do you keep track of where the array is steered and check for aircraft within the limits of the main beam when it's "physically" steered there, or is it a more abstract (possibly more generous) "as long as it's in the scan volume I'm checking the object every 2 seconds post-detection and comparing against the predicted track position"?
• Similarly, what level of abstraction are you using for the scheduler? When does the TWS-A mode decide to adjust the scan volume and when does that take effect in the AWG-9? Two seconds is an awfully long time in a radar timeline so I assume the WCS is scheduling a series of short jobs that make up the entire two second TWS-A scan. At what point is it actually able to interrupt the pattern and restart the TWS scan to cover a different scan volume? When would it decide to do that - would it at least complete enough of the pattern to update all existing targets before resetting to start a new scan using the adjusted az/bar limits? Obviously the pilot or RIO can interrupt the timeline to change modes, but while TWS-A is in control it should be "greedy" and not bump jobs that are intended to update an existing track.
• How do the answers to my first two questions affect when the WCS decides a track has been lost? Is there a timer (either based on raster scan position or an abstract timer) that is being reset on a scan volume change before a track has been updated, which causes the track to "time out" because it was due to be refreshed in 0.1 seconds but the scan restarted? 

I'm only familiar with modern radar timelines so modeling the real-life limitations of a mostly analog, mechanically scanned system controlled by the world's earliest microprocessor is totally foreign and totally fascinating.

TL; DR: As a radar guy, I'd love to talk to your radar guy about how and when TWS-A changes the scan volume and how that affects the refresh rate of tracks, especially TMA tracks.

[Naquaii]

37 minutes ago, WhiteRabbit said:

This is something I'm really curious about. I know I've seen cases where TWS-A will have a TMA track, then adjust scan volume slightly to include a new contact, and almost instantaneously drop the TMA even though it seems to be inside the scan limits. I say I suspect it's still inside the scan limits because on the next pass the system will immediately place a fresh contact right on the broken/held track (and fail to associate them).

I think a similar phenomenon is the dreaded "I dropped your track the instant you foxed on it". Maybe because changing to a TMA caused the WCS to readjust weights which caused it to reset the scan volume which caused it to drop the TMA due to a refresh timer error or the like?

It raises a few questions for me:

• What level of abstraction are you using to model the AWG-9's raster scan? Do you keep track of where the array is steered and check for aircraft within the limits of the main beam when it's "physically" steered there, or is it a more abstract (possibly more generous) "as long as it's in the scan volume I'm checking the object every 2 seconds post-detection and comparing against the predicted track position"?
• Similarly, what level of abstraction are you using for the scheduler? When does the TWS-A mode decide to adjust the scan volume and when does that take effect in the AWG-9? Two seconds is an awfully long time in a radar timeline so I assume the WCS is scheduling a series of short jobs that make up the entire two second TWS-A scan. At what point is it actually able to interrupt the pattern and restart the TWS scan to cover a different scan volume? When would it decide to do that - would it at least complete enough of the pattern to update all existing targets before resetting to start a new scan using the adjusted az/bar limits? Obviously the pilot or RIO can interrupt the timeline to change modes, but while TWS-A is in control it should be "greedy" and not bump jobs that are intended to update an existing track.
• How do the answers to my first two questions affect when the WCS decides a track has been lost? Is there a timer (either based on raster scan position or an abstract timer) that is being reset on a scan volume change before a track has been updated, which causes the track to "time out" because it was due to be refreshed in 0.1 seconds but the scan restarted? 

I'm only familiar with modern radar timelines so modeling the real-life limitations of a mostly analog, mechanically scanned system controlled by the world's earliest microprocessor is totally foreign and totally fascinating.

TL; DR: As a radar guy, I'd love to talk to your radar guy about how and when TWS-A changes the scan volume and how that affects the refresh rate of tracks, especially TMA tracks.

The short answer is that it all runs in 2 second frames. That's why you're limited to two different scan patterns that take exactly 2 seconds to run. At the conclusion of each 2-second frame the WCS calculates and displays everything, including tracks, prioritys for AIM-54 and antenna steering commands. So basically the AWG-9 performs the scan pattern and then the WCS calculates everything, updates the parameters and then repeat.

We model all this including where the antenna is pointing and making sure the radar would actually see a track depending on different factors.

Because of this set 2-second timeframe marking tracks as lost is simply a matter of how many frames they've missed.

[WhiteRabbit]

On 2/4/2022 at 10:28 AM, Naquaii said:

The short answer is that it all runs in 2 second frames. That's why you're limited to two different scan patterns that take exactly 2 seconds to run. At the conclusion of each 2-second frame the WCS calculates and displays everything, including tracks, prioritys for AIM-54 and antenna steering commands. So basically the AWG-9 performs the scan pattern and then the WCS calculates everything, updates the parameters and then repeat.

We model all this including where the antenna is pointing and making sure the radar would actually see a track depending on different factors.

Because of this set 2-second timeframe marking tracks as lost is simply a matter of how many frames they've missed.

Thank you for the reply! So what I'm taking from this is:

• When TWS (or TWS-A) running, the WCS only updates the weighting and scan parameters at the end of every 2 second scan
• You do consider the beam position in the scan pattern, but that doesn't affect the timing for whether a track has missed a frame. In other words: if the contact seen at the start of one scan (T = 0.1 seconds) and is seen later in the pattern in the second scan (T = 2.2 seconds), it has been 2.1 seconds between detections, but the WCS only cares whether the contact was detected anytime in each consecutive scan
• Firing a Phoenix, which changes your track to a TMA, should not instantly change weights or cause the scan volume to change
• Switching from TWS to TWS Auto should not cause a dropped track. I assume when you switch to TWS-A the scan pattern is restarted in the new mode but the unfinished previous scan isn't counted against you.

We'll wait until the TMA weighting is fixed and then we'll try to isolate examples of any other weird behavior.

[DroptheHammer]

@Doormouse thanks so much for posting this.  I really dont have anything else to say except after firing around 300 missiles this patch using my test range, I fully agree with your findings and hope this gets fixed for MP with and without Jester.

Edited February 7, 2022 by DroptheHammer

[Hextopia]

On 2/4/2022 at 7:28 AM, Naquaii said:

The short answer is that it all runs in 2 second frames. That's why you're limited to two different scan patterns that take exactly 2 seconds to run. At the conclusion of each 2-second frame the WCS calculates and displays everything, including tracks, prioritys for AIM-54 and antenna steering commands. So basically the AWG-9 performs the scan pattern and then the WCS calculates everything, updates the parameters and then repeat.

We model all this including where the antenna is pointing and making sure the radar would actually see a track depending on different factors.

Because of this set 2-second timeframe marking tracks as lost is simply a matter of how many frames they've missed.

If this is how you're simulating it, do you think it's possible to either detect bad mulltiplayer tracks (and clamp onto them until they stop lagging and behave) or do some light "fuzzing" of their location when in MP to expand what the WCS will allow to correlate and reduce some of the erroneously dropped tracks?

[DoorMouse]

17 hours ago, Hextopia said:

If this is how you're simulating it, do you think it's possible to either detect bad mulltiplayer tracks (and clamp onto them until they stop lagging and behave) or do some light "fuzzing" of their location when in MP to expand what the WCS will allow to correlate and reduce some of the erroneously dropped tracks?

Yes. This would be great.  

You can see this sometimes when a contact FLYS off the side of the TID at 10,000 knots, because the contact just warped and the TID is like, well I guess they are going that fast now. 

[DSplayer]

20 hours ago, Hextopia said:

If this is how you're simulating it, do you think it's possible to either detect bad mulltiplayer tracks (and clamp onto them until they stop lagging and behave) or do some light "fuzzing" of their location when in MP to expand what the WCS will allow to correlate and reduce some of the erroneously dropped tracks?

3 hours ago, DoorMouse said:

Yes. This would be great.  

You can see this sometimes when a contact FLYS off the side of the TID at 10,000 knots, because the contact just warped and the TID is like, well I guess they are going that fast now. 

Yeah. Recently I’ve been having problems (while having a human RIO on a stable server with all below 120 Ping) with losing tracks that were just travelling in a straight line. 
 

In terms of contacts flying off the TID, Ive had experience where 2 contacts basically get close together (either in closure rate or actual distance) that the AWG-9 can’t differentiate the targets and basically trash the target with erroneous data.

[DoorMouse]

1 hour ago, DSplayer said:

Yeah. Recently I’ve been having problems (while having a human RIO on a stable server with all below 120 Ping) with losing tracks that were just travelling in a straight line. 
 

In terms of contacts flying off the TID, Ive had experience where 2 contacts basically get close together (either in closure rate or actual distance) that the AWG-9 can’t differentiate the targets and basically trash the target with erroneous data.

This one is always a headscratcher and happens fairly regularly.  I am curious if this TWS Weighting issue is causing much of these problems, as sometimes a new target pops up and pulls the radar cone too far down/over.  

The second item is not happening during a merge, which is a feature in that it was a real issue in the AWG9... but rather a steady target flying straight will sometimes disassociate and fly off the side of the TID at a speed that would make an SR-71 pilot jealous. 

[DroptheHammer]

Just wanted to re-affirm that after the network fixes I still see this issue in SP and MP in similar scenarios (fire at 40-80NM and shortly after these weird fresh contacts fly off to the left and right of the prior track that was launched on... trashing the track...).

I've been changing my tactics to just shoot much closer in and try to separate bandits by maneuvering in random ways as I close distance (also to avoid the sneaky ET).