correct as is STT won't lock when target at 83-100% of max radar range.

[MARLAN_]

For example, a Fulcrum is detected by your ownship radar at 47NM, but you are unable to lock him (STT) until 39 miles.

An A-50 is detected at about 95NM, but you are unable to lock him (STT) until 80 miles.

STTLock2-7-11.trk STTLockA502-7-11.trk

[Wing]

Experiencing the same issue with Viper radar.

[BIGNEWY]

I have checked with the team, detection and lock ranges are not the same. 

thanks

[Ahmed]

If this is the intended result, the team should probably consider implementing a model based on % probability of detection per sweep vs range/rcs (instead of a hard-coded formula that always returns the same max distances for detection and acquisition for a given RCS), as one of the third parties has already done, together with full MEM logic (that I think is working now) and RCS variation with external stores.

Otherwise the current effect from having that reproducible hardcoded result and reduced "lock range" is really not realistic.

Edited March 26, 2022 by Ahmed

[Harker]

If this is the intended result, the team should probably consider implementing a model based on % probability of detection per sweep vs range/rcs (instead of a hard-coded formula that always returns the same max distances for detection and acquisition for a given RCS), as one of the third parties has already done, together with full MEM logic (that I think is working now) and RCS variation with external stores.
Otherwise the current effect from having that reproducible hardcoded result and reduced "lock range" is really not realistic.

Yeah, if you can detect a target reliably, you can also command STT on it. STT can fail if commanded on a trackfile that the radar fails to reliably acquire, but if you're already detecting the target without issues and a good update rate, STT should work as well.

As for the memory logic, it's still not working correctly, same as before. MSI memory doesn't exist and the Radar memory is still controlled by the brick timeout, whereas it should be dependent on radar frames. Are you seeing something different? Because I can't notice a difference from before.

[Ahmed]

1 hour ago, Harker said:

As for the memory logic, it's still not working correctly, same as before. MSI memory doesn't exist and the Radar memory is still controlled by the brick timeout, whereas it should be dependent on radar frames. Are you seeing something different? Because I can't notice a difference from before.

 

Oh, I'm afraid that you are right. I noticed that there was some MEM logic working in-game and wrongly assumed it was fully implemented. Good point!

[Hulkbust44]

On 3/22/2022 at 9:01 AM, BIGNEWY said:

I have checked with the team, detection and lock ranges are not the same. 

thanks

Could you possibly elaborate? Because that response goes against all logic. If the target can be detected and a trackfile created, you can absolutely tell the radar to focus the scan and processing on that track. Only time this wouldn't be true is with VS I would think, but of course we don't have VS modeled. 

[norman99]

Exactly.

Surely if you can detect a target accurately whilst still scanning a relatively large area, then it should absolutely be possible to track this same target once the radar scan is focused entirely on one point?

[norman99]

@BIGNEWY Can you please investigate this further .

The logic behind reducing STT range compared to the detection range when in a scan mode, doesn’t correspond with any normal radar theory.

It doesn’t make sense that I can track a contact in RWS/TWS, (including the ability to designate L&S and employ weapons,) whilst spreading the radar scan out across a large piece of sky, yet once the radar is focused onto one specific point, I can no longer track the same contact.

Theoretically, STT should yield longer tracking ranges than scan modes for this exact reason, not shorter. If a STT’d contact turns cold and range subsequently starts increasing, it should be possible to maintain the STT lock beyond the RWS/TWS detection ranges, again, as all of the available radar energy is being used to track the contact.

This issue, combined with the below bug that clears the trackfile memory completely if the STT is dropped, makes STT almost impossible to use.

I know this is marked ‘correct as is’ but surely this warrants some further investigation?

Edited April 7, 2022 by norman99

[nighthawk2174]

I've never really seen any indication in any manuals that they are different in the American jets, F15/F16/F18, in all the manuals I have for these jets I haven't seen it stated that STT can't be done the moment the target is detected.  Maybe I'm wrong.  @Beamscanner is far more knowledgeable here then I am, is there any reason they should be different in range.

[norman99]

@nighthawk2174 I agree. My understanding is that for all intensive purposes, they should have the same range. Especially because to first detect a contact, you have to start in a scan mode, and hence you can then STT the contact immediately.

My example of STT having a greater range is more based on the theory, and a specific case of obtaining an STT and then the contact range subsequently increasing.

Edited April 7, 2022 by norman99

[Ahmed]

If you can reliably detect a contact you can track it. The thing irl is that there is no such thing as a hardcoded maximum range to detect a specific RCS target, this will vary due to a wide variety of factors, and can be modeled as 50% probability of detection range, 99% pd range and so on, and in the lower %pd ranges consistent detections will be unreliable and thus tracking may break too.

That's why a certain 3rd party has done a great job bringing that radar model to DCS, and that's also why the current ~83% hardcoded limit in ED's modules (while you can perfectly track in TWS) is really inaccurate.

[Beamscanner]

There is not absolute answer to this. What solutions Raytheon comes up with can be vastly different to what Northrop does. 

 

So, what I say below is a generalization. And not an exact truth for any one radar. 

 

Where does 'STT range is less than RWS' originally come from.

Primarily it comes from the first pulse only analog radars from the 50s and 60s. These radars had lots of clutter in their scope as they did not perform doppler filtering or digital signal processing.

With this radar type:

Search mode detection range was a calculated average based on human performance to discern the target amongst the clutter. (target contrast)

Tracking modes were accomplished via a range gate tracker, which held a target automatically by comparing the target reflection in a given range bin to adjacent bins in front of and behind the target. Due to noise that exists in all range bins, the target needs to have a SNR (signal to noise ratio) an order of magnitude greater than the noise in the adjacent range bins. The radar operator/Pilot would move a cursor (the range gate bracket) onto a given reflection, and only if that reflection had adequate contrast (ie good SNR) would a lock be obtained. 

 

The human eye can discern low contrast targets much better than 1960s analog circuitry could. Thus search range was farther than tracking range. 

 

Modern Radars are very different

With modern pulse doppler radars with doppler filtering and digital signal processing, the search volume of the radar provides very high contrast (good SNR; hence much improved detection ranges). With these radars, the search mode performance is automatic and is not based on human perception. Thus on paper search and tracking modes should be the same. 

 

That being said, there is one tracking technique that can reduce STT performance in a modern airborne radar. But this can be overcome very easily.

 

----------

Mono-Pulse comparison is the process of splitting your antenna into 4 quadrants on receive. By doing so, you can compare the phase and amplitude of a return and determine a targets angle within the radars beam. (typically to a resolution of 1/10 of your radars 3dB beamwidth) 

The way it works is that your antenna is actually 4 quadrants that mix the incoming signal in various ways to create multiple output channels. These include:

• SUM (all 4 quadrants combine)
  • Benefits are full antenna gain / max detection range
  • Downside is that angular measurement is limited to antenna 3dB beamwidth
  • The SUM channel is used to provide target range, doppler and angle (limited to beamwidth).
• Delta Azimuth (combine the 2 left side antenna quadrants, combine the 2 right side antenna quadrants. compare the signal between the two halves)
  • Benefit is that you can compare the phase and amp between these 2 quadrants to improve azimuth measurement of the target.
  • Downside is that you only use half of your antenna, and thus receive much weaker signals.
• Delta Elevation (combine the 2 top side antenna quadrants, combine the 2 bottom side antenna quadrants. compare the signal between the two halves)
  • Benefit is that you can compare the phase and amp between these 2 quadrants to improve elevation measurement of the target.
  • Downside is that you only use half of your antenna, and thus receive much weaker signals.

----------

That being said, there are important questions pertaining to this. 

• When is Mono-pulse comparison used by radar X? (In STT only? in TWS and STT? in all modes?)
• Is a radar track not built unless the SUM and Delta channels detect the target? (ie will the system allow a trackfile to be built with only the SUM channel?)
• Does the radar use the detection of a target in the SUM channel to enhance/filter for the target in the Delta channels? (ie a lower threshold could be used in the Delta channels if you know where in range and doppler to look for the target)

 

By far the simplest solution to such a problem is an extended dwell. 

 

STT vs scanning

When a radar scans the sky it does so at a set interval. This interval limits how many pulses the radar can transmit and integrate down a given direction. Pulse integration improves SNR because background noise fluctuates a lot, while targets fluctuate only a little (were talking periods of milliseconds). Thus, the more pulses you transmit / integrate, the further you can see a target. If you cant increase your PRF, but still want to integrate more pulses, you have to slow down the scanning speed of your antenna. With fighter jets, this isn't always easy since the radar may need to scan a large volume while also revisiting a target periodically enough to maintain trackfile correlation (ie correlating raw hits to the same trackfile).

 

The solution

Once you're in STT, the radar has a LOT more time on target and can integrate many many more pulses on target as the antenna is fixated on the target and not searching around. This extra time on target means that the SNR will be vastly higher than in search mode, because its integration count is not as constrained.

Factoid: Many modern radars can perform 'cued search', where in the radar receives external information on a target and then performs a very long dwell in that volume of sky. This reduces the need for volume search, and allows the radar to use much longer integration counts. 

 

TL/DR:

Old analog "Pulse" radars: Search mode range > tracking range

Early "Pulse Doppler" radars: Search mode range = tracking range (albeit with some hurdles)

Modern radars: Search mode range < tracking range (assuming you know where to look)

 

Reference: The best radar book ever, George Stimson's "Introduction to Airborne Radar"

Edited April 7, 2022 by Beamscanner
wording

[MARLAN_]

@BIGNEWYReally great investigation by Beamscanner

[norman99]

That’s a great explanation @Beamscanner, thanks for taking the time taken to write it.

[MARLAN_]

Looks like fixing this issue would likely be either deleting this line or setting it to 1.0.

edit: It could actually probably be set higher, not sure what value, I'm sure a radar SME could figure out, but for example 1.15 -- This wouldn't do much right now since we don't have the capable to designate an offboard track yet, but would future proof a bit. (Unless you STT a contact and then they run away or something like that)

edit 2: this code snippet sounds like it may only apply to the AI F18's, appears it was a coincidence or perhaps code duplication that it appeared to match the 0.83 test mentioned here. I'm sure a similar value probably exists elsewhere that ED has access to.

Edited April 25, 2022 by MARLAN_

[oldcrusty]

37 minutes ago, MARLAN_ said:

Looks like fixing this issue would likely be either deleting this line or setting it to 1.0.

Hey...

[MARLAN_]

4 minutes ago, oldcrusty said:

Hey...

Not sure what you mean

[oldcrusty]

1 hour ago, MARLAN_ said:

Not sure what you mean

didn't realize it was that easy... that's all

[MARLAN_]

2 minutes ago, oldcrusty said:

didn't realize it was that easy... that's all

Oh, yea. It seems that code snippet might be for just the AI version of the APG-73, not sure. But I imagine it's that easy still even for the player version of it.

[BIGNEWY]

The team are happy with the current values based on the data we have and can use. 

thanks

[Harker]

The team are happy with the current values based on the data we have and can use. 
thanks

Is there any chance we can get a reference for this then, from the team? I'm sure we'll be happy to lay this issue to rest.

[MARLAN_]

7 hours ago, BIGNEWY said:

The team are happy with the current values based on the data we have and can use. 

thanks

Yea a reference would help put our minds at ease since I assume ED is trying to create an accurate representation of the F18.

Perhaps a "intended" or "legally unable" tag would work better than "correct as is" for some features.

[Darkenmass]

@MARLAN_ Can you give me the file location of that sensor ? I can't find it on CoreMods/tech/TechWeaponPack/Database/db_sensors , i find other radar but not the AN/APG 73....

[MARLAN_]

https://github.com/Quaggles/dcs-lua-datamine/blob/master/_G/db/Sensors/Sensor/ANAPG-73.lua

It believe this may be the AI version of the sensor though (didn't realize initially).

I would have expected that the AI would use the same one since they are the same radar and all, but sounds like they have a different version for the AI Radar. There are notable differences such as gimbals being incorrect on this file as well.