reported DCS F-16CM APG-68v5 look-down issues and also weird AIM-120C behavior

[CobaltUK]

I get just the same. Coming straight at me co-altitude. Fruitlessly bashing TMS up and it gets as close as 20 miles before a lock. This has been on MP servers if that's relevant. . Not yet tried with latest patch. Oh and no indication Mig jamming.

[Bunny Clark]

51 minutes ago, Invisibull said:

I'm a bit confused about this comment as I was consulting the DCS Viper Early Access Manual along with Chuck's Viper guide while writing my original post.  I'm not saying you're wrong, but that I'd appreciate knowing what terminology I used, which applies to the Hornet, but not the Viper. 

I think the confusion comes from the concept of track files in RWS. In the Hornet, the radar is building track files while in RWS, and that information can be viewed from RWS mode (assuming LTWS is enabled). The Viper does not build track files in RWS at all, you'll only see raw hits (white bricks) from radar contacts. RWS will display Link16 surveillance tracks on the radar page, which you may be getting confused by. If you want to see track files, you'll need to switch to TWS.

Not being able to lock / bug a search brick is another thing. I'm not sure what's going on there. I'd imagine that once the radar can see the contact and display it as a brick, it should be able to lock on and elevate it to a bugged target. I'm not sure why the radar will show that something is there, but refuse to track it for a while. 

[Frederf]

Wrong, APG-68 is always building track files in all modes. It doesn't display them in RWS search, but they're made just the same.

[BIGNEWY]

We have already said we are preparing a white paper explaining how radar works in DCS 

thanks

[Comrade Doge]

With all due respect, what the community is mostly asking for, is a rework of the performance, not really a description of a current system.

What we have right now is considered by many commenters, some very knowledgeable in the domain, as underperforming. They have provided numerous refereces to real documentation, and radar performance stuides, poining out that the current model might be worth taking a look at. Just a few degrees of lookdown equating to a hard coded 50% loss of performance is an indicative of something being possibly wrong.

I sincerely hope that our evidence, arguments and in-game examples that we've gathered so far will also reach the dev team, to be possibly discussed internally, and weigh in on the situation. 

We have no problem with waiting, as long as it's all going in the right direction, best wishes.

[Moonshine]

indeed. the question is not the functionality as you will explain to us in the white paper, more the performance of said functionality.

[Fromthedeep]

59 minutes ago, Comrade Doge said:

What we have right now is considered by many commenters, some very knowledgeable in the domain, as underperforming. They have provided numerous refereces to real documentation, and radar performance stuides, poining out that the current model might be worth taking a look at.

I would assume that the whitepaper is going to contain sources and explanations that could somehow (in theory) support their position. To ensure intellectual proffesionalism, we definitely should wait until the whitepaper is out, they can describe the points and support it with evidence and debunk it if it's factually incorrect.

[Comrade Doge]

26 minutes ago, Fromthedeep said:

I would assume that the whitepaper is going to contain sources and explanations that could somehow (in theory) support their position. To ensure intellectual proffesionalism, we definitely should wait until the whitepaper is out, they can describe the points and support it with evidence and debunk it if it's factually incorrect.

I definitely expect the paper to directly reference our findings and questions, for instance, look down penalty and established tracked targets having an artificial range limit until they can be bugged. That is, if they consider everything to be correct as they have implemented it.

The concern arises from all the threads being closed and merged together without much information to us, or reassurance that the data we provided has actually been taken into consideration, to either possibly enact a change, or at least a double check.

Edited June 10, 2022 by Comrade Doge

[Tango3B]

3 hours ago, BIGNEWY said:

We have already said we are preparing a white paper explaining how radar works in DCS 

thanks

With all due respect BN, this is not enough. The behavior described above was not there before the patch on the 28.04.2022 and the observed behavior was also reported and marked as a bug by at least one or two ED team members - and it clearly is a major bug. Saying we should wait for an explanation in the white paper, if there is any, is not really helpful in any way. Did you even read the above scenario I described? You just cannot leave us hanging in the loop with something which is so annoying and so wrong that I barely find the right words describing it. Thanks.

[Invisibull]

If I'm remembering correctly, the initial bricks didn't show up until they could be locked.  What's seems to have changed, and what has confused me, is that they now appear a good 20 seconds (when we're flying right at one another, co-altitude) before I'm able to bug them and begin setting up for a shot.  That's the real issue in a nutshell.   

[Bunny Clark]

On 6/10/2022 at 12:38 AM, Frederf said:

Wrong, APG-68 is always building track files in all modes. It doesn't display them in RWS search, but they're made just the same.

Cool, I did not know that.

[Dragon1-1]

You should be able to bug any brick in RWS, since it's just telling the software to display additional data for this particular hit. You do not "lock" anything that way. A lock is going to STT, and shouldn't be range-restricted either. If the contact is uncertain the bug might drop, but that's it.

Hopefully when the whitepaper comes out someone well-versed in radar tech will be able to point out the problems with it. There are things marked "correct as-is", which are very obviously not.

[Mr. Wilson]

The task of the test is to determine the dependence of the detection and lock range on the altitude of the target

Test conditions:

The two jets converge face to face at different altitudes. Attack aircraft F16 target aircraft also F16.  FCR mode - RWS (SAM).

Result:

CASE 1 -- Fighter h=1 000 ft / Target h=1 000 ft / Detection range=13 nm / Lock=11.6 nm

CASE 2 -- Fighter h=1 000 ft / Target h=5 000 ft / Detection range=14.2 nm / Lock=11.6 nm

CASE 3 -- Fighter h=1 000 ft / Target h=10 000 ft / Detection range=14.4 nm / Lock=12.3 nm

CASE 4 -- Fighter h=1 000 ft / Target h=20 000 ft / Detection range=13.7 nm / Lock=11.3 nm

CASE 5 -- Fighter h=1 000 ft / Target h=30 000 ft / Detection range=13.2 nm / Lock=11.8 nm

CASE 6 -- Fighter h=30 000 ft / Target h=1 000 ft / Detection range=26.5 nm / Lock=22.7 nm

CASE 7 -- Fighter h=20 000 ft / Target h=1 000 ft / Detection range=26.7 nm / Lock=23 nm

CASE 8 -- Fighter h=10 000 ft / Target h=1 000 ft / Detection range=27.8 nm / Lock=23.6 nm

CASE 9 -- Fighter h=5 000 ft / Target h=1 000 ft / Detection range=27.1 nm / Lock=22.6 nm

CASE 10 - Fighter h=20 000 ft / Target h=20 000 ft / Detection range=41.8 nm / Lock=35.7 nm

CASE 11 - Fighter h=10 000 ft / Target h=20 000 ft / Detection range=37.65 nm / Lock=32.3 nm

CASE 12 - Fighter h=20 000 ft / Target h=10 000 ft / Detection range=27.85 nm / Lock=23.6 nm

CASE 13 - Fighter h=20 000 ft / Target h=30 000 ft / Detection range=38.5 nm / Lock=32.5 nm

CASE 14 - Fighter h=30 000 ft / Target h=20 000 ft / Detection range=27.1 nm / Lock=23.2 nm

CASE 15 - Fighter h=5 000 ft / Target h=20 000 ft / Detection range=37 nm / Lock=31 nm

CASE 16 - Fighter h=20 000 ft / Target h=5 000 ft / Detection range=27.92 nm / Lock=23.2 nm

 

In all cases at all altitudes we see a very large delay between Detection and Lock range, Why ? we did not have such an effect before and on other planes there is no such effect either...

And also very confusing losses in the detection range in CASES 1-5... I believe this is the effect of wave reflection from the ground, but why does it break the detection range so much? perhaps there is an error here?

TRACK

Edited June 17, 2022 by Mr. Wilson

[Nuggetz]

Thank you for doing this analysis, while I do not have specific evidence to support your work, this appears to be highly representative of the experiences I have encountered for quite some time. 
 

It will be interesting to see if the White paper being written by ED suggests that this profile accurately emulates the actual radar fitted to the aircraft. 

[Hobel]

This behavior has been mentioned here from time to time, so yes others also observe this behavior.

Even if you and your targetd are enormously high, the one who is ~10k ft higher loses 10nm miles:

Spoiler

 

and also 60k vs 50k the same.

Edited June 18, 2022 by Hobel

[moggel]

 No idea why but I have major problems getting the FCR to lock, RWS/TWS doesn't matter. As an example: azimuth 6, antenna elevation correct. Track is hot, at 25-40nm, filled in (own radar and others paint it) and very often I even have a filled in white track underneath. But I keep pressing TMS up and it take a lot of them before the FCR actually locks up, and by then I'm way too close for comfort. Is the FCR bugged or is it really that crappy in the real Bk50?

Edited June 21, 2022 by moggel

[Victor3]

I'm having the same issue. I have bricks I just can't bug them.

[NineLine]

We are VERY actively researching and discussing detections vs bug range and degree of radar look down effect. We hope to have more info soon. Thanks for your patience. 

[Invisibull]

Bricks still unbuggable for the first 20 seconds after today's update. 

[skywalker22]

https://forum.dcs.world/topic/299740-dcs-f-16cm-apg-68v5-look-down-issues-and-also-weird-aim-120c-behavior/?do=findComment&comment=4993361

To continue from this thread, but cannot write in there, cause its locked. Just can join them both.

Anyway, I would like to point out one very important bit about the radar. I will not add any track, since everyone can test this out very quickly.

Its about Radar Azimuth and Elevation Bar Scan.

There is practically no difference between settings (A1,1B or A6,4B and all in between). And there is also no difference or using RWS or TWS mode.

What do you think this is? But I guess there should be a difference for sure.

[BIGNEWY]

11 minutes ago, skywalker22 said:

Its about Radar Azimuth and Elevation Bar Scan.

There is practically no difference between settings (A1,1B or A6,4B and all in between). And there is also no difference or using RWS or TWS mode.

That is incorrect. 

Azimuth setting changes azimuth volume of the scan frame, bar changes the elevation scan frame volume, and these combined allow the pilot to adjust the frame scan for search volume vs frame update. RWS and TWS provides different symbology and radar mechanics.