investigating Azimuth select in TWS should cycle all and decrement bar as necessary

[Jak525]

Current behavior - In TWS, with a given bar selection (2, 4, or 6), the azimuth selection is limited to whatever azimuth is allowed for that bar. For example, if 4B is selected, the azimuth select cycles through 20 and 40 degrees. If 6B is selected, only 20 degrees is available. If the elevation bar setting is cycled, the azimuth is automatically decreased to meet the limit. For example, if 2B and 60 degrees is selected, cycling the bar setting to 4B would automatically command a 40 degree azimuth.

 

Correct behavior - It should work like it does, but both ways, instead of just one. For example, with 6B selected, you should still be able to cycle to 40, 60, and 80 degree azimuth. However, if you cycle to 40, it would decrement the bar automatically to 4B, and if you selected 60 (or 80), it would decrement the bar to 2B.

 

In other words, both elevation bar and azimuth width can be selected at any time in TWS (with the exception that TWS does not ever allow for 1B elevation bar or 140 degree azimuth width). When you select either the bar or azimuth, the one you did not change yourself is automatically changed IF required. Right now, this works when changing the elevation bar, but not the other way around.

TWS azimuth select bug.miz.trk

[Fri13]

It would make sense that when you want to change one value you can, but the linked another value would automatically adjust to maximize effectiveness if it was set maximum. 

But what should happen if you have example 20D (degree) for maximum update rate at 4B and you go from 4B to 2B? Should it keep the 20D azimuth but just change the bars and not jump to 120D?

[Jak525]

9 hours ago, Fri13 said:

It would make sense that when you want to change one value you can, but the linked another value would automatically adjust to maximize effectiveness if it was set maximum. 

But what should happen if you have example 20D (degree) for maximum update rate at 4B and you go from 4B to 2B? Should it keep the 20D azimuth but just change the bars and not jump to 120D?

You cannot have 120 degree in TWS. 80 is the max. But yes, if the uncommanded value is within limit, it's not going to do anything. It will only change the uncommanded value if it violates the TWS scan volume restrictions. Tl;dr it's less than or at max, no change, if it's more than maximum, the uncommanded value is automatically decreased.

 

So yeah, if you have a 20 degree azimuth, it's never going to be changed when you cycle through the bars, because 20 degrees is permitted in 2B, 4B, and 6B.

 

If, however, in 4B you were at 40 degrees, going to 6B would change it to 20, since 40 at 6B is no bueno. However, if you directly cursor-selected 2B, it wouldn't change, since 40 is permitted at 2B. (The cursor selection function is bugged at the moment.)

 

(TWS restrictions)

2B - 20, 40, 60, 80

4B - 20, 40

6B - 20

Edited March 23, 2021 by Jak525

[Kempleja]

I have no idea, what is the correct behaviour in reality, but this described correct behaviour would be a downgrade from current behaviour and I wonder why would they design radar to behave like that. It would require pilot to press more buttons and could cause accidental track drops.

For example, if a pilot has 4B-40° setting and has a contact on lower half of search cone. If he wants to narrow azimuth to 20° to get better track, he would actually command azimuth from 40° to 60° and elevation to go automatically from 4B to 2B and actually skip scanning the lower portion of initial cone? 

So if in current behaviour it would require one press to get from 4B-40° to 4B-20° then with the described correct behaviour pilot would need to press azimuth button three times (40°-60°, 60°-80°, 80°-20°) and then elevation button again (2B-4B). Is also a lot easier for brains to remember that you first have to set elevation and then can cycle through azimuth (or vice versa) rather than having to adjust both settings.

[Tholozor]

Instead of pressing the OSB to change the bar scan or azimuth scan by cycling through them, you can use the TDC cursor to directly select the option you want. Hover the cursor over the bar scan or azimuth setting and all options will appear. Hover over the desired option and hit TDC Depress to select it. @Jak525 mentions this: 

18 hours ago, Jak525 said:

However, if you directly cursor-selected 2B, it wouldn't change, since 40 is permitted at 2B.

But also mentions it's bugged, so hopefully fixed soon.

[Kempleja]

Ah, nice. Did not read his second message and did not know that elevation and azimuth can be cursor-selected. 

But when using OSB, is the current behaviour correct, as it should be? To me at least it would make sense.

[Jak525]

4 hours ago, Kempleja said:

Ah, nice. Did not read his second message and did not know that elevation and azimuth can be cursor-selected. 

But when using OSB, is the current behaviour correct, as it should be? To me at least it would make sense.

Yeah, the cursor-selection is the way around it. And no, the OSB logic right now is not correct. It should be as I describe in the report.

 

You do make a good point but apparently they elected to do it the other way. It's a trade off because although you do describe a problem, with the current way it's in DCS another problem is created in that if you desire to increase the azimuth, say you're in 4B at 40° and want to be at 80°, right now you'd have to cycle through 6B, then to 2B, which'd reset the azimuth to 20° since you're going thru 6B. Then, you'd have to increase the azimuth to 80° after. Similar to the problem you described.

 

In the end though using the cursor would be the quickest way since you can directly select any bar or azimuth without cycling.

[GGTharos]

The main limitation for all TWS modes is data-rate required to consistently update a track, more so when shooting than when surveilling.   This is why there is a maximum size (ie. you could select smaller in theory) combination of AZ/BAR in order to keep the scan time constant - for the F-14/15/16/18 this seems to be approximately 2 seconds, maybe 2.2 or so.

 

So consider that the problem is this:  Build a track requires 3-4 hits.  If you had a 140 AZ and 6 bars, the antenna moves at 70deg/s, you need 12 seconds minimum (it will more likely be around 13 to add time for stepping from one bar to other other) per hit.   This means you need 36-48 seconds to build a track, and the track prediction/correlation algorithm needs to throw such a wide gate around the target that it can easily correlate wrong things.

Likewise, a contact can maneuver to change its closure and heading enough to throw off track correlation (and thus track building) in 12 seconds even if it's an airliner.

 

So, 2.2 seconds is a reasonable trade-off with high-data rate (1.1s) TWS modes and SAM coming in next with even better performance engagements.

Edited March 25, 2021 by GGTharos

[Jak525]

10 hours ago, GGTharos said:

The main limitation for all TWS modes is data-rate required to consistently update a track, more so when shooting than when surveilling.   This is why there is a maximum size (ie. you could select smaller in theory) combination of AZ/BAR in order to keep the scan time constant - for the F-14/15/16/18 this seems to be approximately 2 seconds, maybe 2.2 or so.

 

So consider that the problem is this:  Build a track requires 3-4 hits.  If you had a 140 AZ and 6 bars, the antenna moves at 70deg/s, you need 12 seconds minimum (it will more likely be around 13 to add time for stepping from one bar to other other) per hit.   This means you need 36-48 seconds to build a track, and the track prediction/correlation algorithm needs to throw such a wide gate around the target that it can easily correlate wrong things.

Likewise, a contact can maneuver to change its closure and heading enough to throw off track correlation (and thus track building) in 12 seconds even if it's an airliner.

 

So, 2.2 seconds is a reasonable trade-off with high-data rate (1.1s) TWS modes and SAM coming in next with even better performance engagements.

 

Correct, yep. The max TWS frame time is ~3 seconds (obviously can be less). Regardless this isn't about the frame time restriction itself - that's implemented. It's just about the UI mechanization of selecting the azimuth width.