Jump to content

TWS mode not being able to detect targets that fly in a formation


Invictus_ds

Recommended Posts

4 hours ago, xarann said:

I do not know where they got this information from, but processing data from the radar for display on the TID  is nothing like the operation of a digital camera.

Everything displayed on TID has already been digitized, there is no analog information there! And why is it that a computer(our WCS) having the same source data (from DDD) can separate them as four targets in RWS, but in TWS mode "sees" only two of them? TID image should be the same for both modes

Once again, you're asserting something and not really backing it up? I'm sorry the analogy didn't land for you.

 

20 minutes ago, GGTharos said:

You're confusing incoming data with algorithms.   RWS is fairly raw, it produces a hit with a specific position which can be sent to TWS.

TWS receives the positions and figured out how to build a track from that.  If two hits fall inside the same track oval one may be rejected or they can be merged for TWS, whatever the TWS algorithm is programmed to do in that case.

 

This, this, and more this.

If you really really want to get into the electronics of it you're correct the DAC step happened before the RWS returns were drawn to the TID, but now we're getting into programmable vs non-programmable electronics.

While you're running in RWS mode you're right, there is a DAC step, but all of that is occuring in non-programmable fixed logic silicon. Again, based on iteration of previous designs this is a very well understood problem and accepting certain limitations with regards to the processing of that signal return we can get a pretty good result on the B-Scope. As GGTaros said, strictly this is where our gating comes in. We literally mean hardware encoded logic gates to process the input in near real time and then draw a dot on the B-Scope / TID.

TWS takes all of that as an input to its algorithm where it will then lay on a TWS trackfile, so firstly, this is slower as generally before a trackfile is even shown to the TID it has to go through 2 passes to be considered valid and shown. Secondly because the TWS part is part of the software oriented programmable CPU this has to accept that we have a certain clock speed. In this way we are limited to 24 active tracks, both due to memory and process speed limitations.

TWS is basically drawing an oval around the track (as i was trying to explain with the cells analogy earlier, hes in B1 right now, hes moving toward me and a bit to the right, we expect him in C2 on the next cycle). These track files are really pretty binary in their interpretation, there is something in gate B1, we expect to see something in C2 next time - if we do continue to build the same track, if not, attempt correlation (sources are debatable if this was possible with the AWG-9 and how rudimentary the implementation was). If correlation outright failed and nothing is where we expected it to be, dump the track. 

So yes, the TID is showing "digitized" information in all cases. However one is based on a very raw return and is updated as fast as the radar can do its bar scan. The other has had a lot more computations done on it. 

I should also point out that even with much more modern radars, well into the Allied Force / 1999 time period - it was still doctrine to use STT for attacks and was unusual to rely on TWS in the scenarios real life pilots found themselves in. And a lot of that is because TWS simply is not as reliable as other modules in DCS make it out to be.

 

  • Like 2
Link to comment
Share on other sites

 

1 hour ago, GGTharos said:

You're confusing incoming data with algorithms.   RWS is fairly raw, it produces a hit with a specific position which can be sent to TWS.

TWS receives the positions and figured out how to build a track from that.  If two hits fall inside the same track oval one may be rejected or they can be merged for TWS, whatever the TWS algorithm is programmed to do in that case.

 

So, there is an algorithm for RWS. )

If the radar data (DDD) is the same, why can't a more complex and sophisticated algorithm(TWS mode that records target tracks, correlates these tracks, calculates the future position of targets, etc.) do what a simpler algorithm of RWS does - resolve a four separate targets?

How is it possible, having four separate radar returns (the fact that they differ is confirmed in RWS mode), to be able to write them in two TWS tracks? Where is the logic?


Edited by xarann
  • Like 1
Link to comment
Share on other sites

1 hour ago, xarann said:

So, there is an algorithm for RWS. )

No.

1 hour ago, xarann said:

If the radar data (DDD) is the same, why can't a more complex and sophisticated algorithm(TWS mode that records target tracks, correlates these tracks, calculates the future position of targets, etc.) do what a simpler algorithm of RWS does - resolve a four separate targets?

RWS doesn't build tracks.   TWS builds tracks and it requires certain assumptions to be made that RWS does not, and therefore you have this result.

1 hour ago, xarann said:

How is it possible, having four separate radar returns (the fact that they differ is confirmed in RWS mode), to be able to write them in two TWS tracks? Where is the logic?

Maybe you should do your own research at this point or write a TWS algorithm instead of repeating questions to which correct answers have been given 🙂

Anything less and I'll have to assume that you're trying to be deliberately obnoxious.

  • Like 6

[sIGPIC][/sIGPIC]

Reminder: SAM = Speed Bump :D

I used to play flight sims like you, but then I took a slammer to the knee - Yoda

Link to comment
Share on other sites

Isn't it been said that the "computer" of the WCS is very much a old piece of crap (during the introduction the hottest <profanity> though). If you are old enough, you would remember that you would be able to observe the TI-30 calculating stuff, just as a analogy. 

That said, track files need processing power which need cpu cycles and these were low these days. Thus the big block radar cells to make it working with the available hardware. 

I have hands on experience with GBAD radars from that time frame, which did the same stuff: build in hardware to digitize the returns, but the WS computer was also pretty slow and used huge correlation cells where everything in that thing was ONE target.

As an operator, one was able to figure out that there were more than that, if the resolution of the radar was good enough to deliver the data.

So yes, RWS und TWS are two very different things, which delivered totally different things to the operators for further considerations.

Yes Operators, like the RIO, which worked with the analog part anyhow. Who needs a stupid computer to tell one what to do. 


Edited by Lt_Jaeger
Link to comment
Share on other sites

18 minutes ago, Lt_Jaeger said:

That said, track files need processing power which need cpu cycles and these were low these days. Thus the big block radar cells to make it working with the available hardware. 

So much this.

There are also physical space limitations when referring to non programmable logic gates, although individually they are quite small they do add up, then you have power and heat dissipation to think of. Hence the gates have to be carefully chosen and can result in these seemingly imprecise cells and bins.

Link to comment
Share on other sites

This is a great discussion.  I've had exactly the same question as the OP, experiencing the RWS as having excellent resolution at very long ranges, yet often requiring closing to 15 nm to separate 4 Backfires in standard formation.  These formations aren't flying wingtip to wingtip or super close trail, they're standard tactical formations.  Yet the DCS TWS function seems unable to resolve them until surprisingly close ranges.

This wouldn't be so bad, except that in DCS, firing on a merged contact at longer ranges can cause loss of the Phoenix when the contacts later separate at close ranges.  Over and over in a training mission I created, I've seen 4 clear contacts with RWS at 80-90 miles (Backfires).  Under TWS, it's all one contact.  I close to 50 miles and fire an AIM-54A, but as we close and while the Phoenix is in flight, TWS begins resolving into 2 contacts, and often the original "track file" starts going sideways off the radar scope at high speed trashing the Phoenix.  Same happens if I fire Phoenix missiles when TWS has two contacts, but resolves them into 4 contacts while Phoenix missiles are in flight.  

The explanation that TWS is creating "cells" with coarse resolution due to the limits of the CPU makes sense.  But then trashing the Phoenix missiles as it resolves into greater resolution as they close seems to make the AWG-9/Phoenix combination surprisingly ineffective against exactly the kind of threat it was designed to fight. 

It seems the only way to use the Phoenix properly is to use RWS to get the number of targets at long range, then wait until TWS resolves to the same number of contacts (which may only be 15nm away), then ripple fire.  Is that how the Tomcat was used historically?

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

11 hours ago, near_blind said:

Last time I checked PD-STT doesn't have a resolution issue at range, and a flight member exploding is a great way to introduce a little entropy into the formation

I do have a feeling that API is partially to blame on this one in terms of how easy it is to hold it;

It's the same thing that Jester has a godly ability to acquire STT locks on close flying formations that no human RIO could do.

Link to comment
Share on other sites

  • 4 weeks later...

Not an API issue or bug or any of the sorts, but precisely a limitation of TWS building tracks (vs RWS not building any tracks) at distance, and merging them into one. Just like the RWR would for example. This happens because our radars (and RWR for that matter) are modelled realistically in terms of "not knowing what is out there" but processing the incoming signals and interpreting them, building tracks from them, etc based on the received signals, computations, algorithms, etc.

As GG explained, due to its algorithms, computing power etc, TWS at distance will be more prone to merge a formation into one single contact, while RWS will not do this because it is not building tracks at all. The closer your target gets, the easier it will be for it to distinguish them, just like the RWR would as well.

Don't forget this is the first TWS ever, on a computing power way weaker than your 1990's Blackberry phone... It was not a very reliable mode at all. Even modern TWS will always be less reliable than RWS, STT, etc. If you are coming from FC3, the TWS there is extremely overmodelled and way too reliable for example, because it does not blend out what it should not know. It just knows "there is a contact", without simulating the processing of return signals, computing them into tracks, etc. It sets up for wrong expectations of just how unreliable TWS can be potentially.

  • Thanks 1

Heatblur Simulations

 

Please feel free to contact me anytime, either via PM here, on the forums, or via email through the contact form on our homepage.

 

http://www.heatblur.com/

 

https://www.facebook.com/heatblur/

Link to comment
Share on other sites

On 6/17/2022 at 8:42 PM, Istari6 said:

Is that how the Tomcat was used historically?

In parts, yes. But it does not need to be 15nm, usually it will show contacts well separated at much longer ranges, and you can even as only the pilot flying with Jester judge when they start becoming more stable tracks. TWS, from what I could gather from the SMEs, was not necesserily their go-to attack mode. RL also works somewhat differently, and you would likely prefer P(D)STT over TWS anyways.

This happened in the Iran-Iraq war btw, where they fired a phoenix on some iirc MiG-23s, and splashed actually a 3-ship with one missile, because they were so close together, hehe. If they would have known that it was 3 bandits, I guess they would have fired 3 missiles. 😉

The question "but why did they develop this for this or that purpose when it then didnt work as intended" serves little purpose. It is like asking why did they develop heat seekers, when they did not work in the beginning. Giora Epstein said they called them "bidons", because they would literally fall of the rails and nothing would happen.

It is called a great idea that has to undergo a certain evolution to improve from its first implementation to what it is today: something that works way better and much more reliably. But even then RL will impose limitations, such as during desert storm, where you could not fire AIM-9s on lower flying bandits, because the background of the sand was simply too hot. (Referencing the A-10 killing a helicopter with guns, because its much more modern aim9 at this point simply failed, too.) Yet, in retrospect, it was the right choice to implement it and to undergo the evolution it needed. Just as an example.


Edited by IronMike
  • Like 1

Heatblur Simulations

 

Please feel free to contact me anytime, either via PM here, on the forums, or via email through the contact form on our homepage.

 

http://www.heatblur.com/

 

https://www.facebook.com/heatblur/

Link to comment
Share on other sites

As a workaround i sometimes don't switch to Phoenix until certain distance is reached (depending on aspect, altitude, mach, offset...) and avoid building tracks. This way i retain the better resolution for more SA. Only after i feel confident the radar will build tracks do i switch to 54's. 

Modules: FC3, Mirage 2000C, Harrier AV-8B NA, F-5, AJS-37 Viggen, F-14B, F-14A, Combined Arms, F/A-18C, F-16C, MiG-19P, F-86, MiG-15, FW-190A, Spitfire Mk IX, UH-1 Huey, Su-25, P-51PD, Caucasus map, Nevada map, Persian Gulf map, Marianas map, Syria Map, Super Carrier, Sinai map, Mosquito, P-51, AH-64 Apache

Link to comment
Share on other sites

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...