reported some problems with AZ/EL pages

[Sting57]

isn't that a Survelience track recieved from a Donor and not actually a radar track?

[Recluse]

5 hours ago, Sting57 said:

isn't that a Survelience track recieved from a Donor and not actually a radar track?

YES it is, but Surveillance tracks have Elevation and azimuth information associated, so the AZ/EL page should represent their position as inside or outside the current radar scan volume just as you can TDC over it on the radar screen to get the Elevation and slew the scan and elevation to bring it within constraints for detection by your radar.

[AroOmega]

This is still an active issue in 2.8. Tested during a multiplayer session so I'll go back and get make a smaller trackfile later on. Maybe since this is incorrectly marked as "correct as is" we should submit a new topic?

Are you guys noticing it too?
Until then just know that you cannot trust your AZ/EL page box elevation--you need your target to be decently inside the box before they are within the radar top/bottom alt numbers.

[Hulkbust44]

On 10/18/2022 at 9:46 AM, raus said:

Indeed, in AZimuth and ELevation... but at what distance? The volume covered by the radar is not a parallelogram, and you will not be covering the same height 2nm away from your plane, as 80nm away from it. That is what I meant, I think the yellow box represents the radar coverage at a given distance, which might or might not be the same at which you put your Attack Radar cursor, and therefore the mismatch.

 

It's half the Attk format scale

[Recluse]

11 hours ago, Hulkbust44 said:

It's half the Attk format scale

Not sure I understand.  Since the AZ/EL page does not have a distance measurement, it is hard to tell where contacts are without cross referencing with the radar. For example, I often am tracking a Radar contact (let's say they are at 40 miles and just coming into my TWS 40 mile scan) I can find that contact on my AZ/EL page but there may be (DATALINKED) contacts "below" it which on a B-scope means CLOSER, but on AZ/EL just means lower elevation. When I put the TDC over them on the AZ/El page, I can see they are FARTHER away (often outside the ATTACK RADAR range setting) and just at lower Elevation than the contact I am tracking.

Since they are datalinked contacts, I never stopped to wonder (until now) why they seem to appear within my Radar Scan Volume, when my radar is only scanning out to 40 miles.  I was thinking that the Scan Volume shown on AZ/EL is based on the Attk Radar range setting, but I am now thinking it reflects  scan volume of MAXIMUM radar range despite what the radar is set to actually DISPLAY. Makes sense since, setting your radar display  to a shorter distance doesn't mean the radar beam itself is cutting out early, just that it is only displaying contacts within the set range.

[AroOmega]

On 11/12/2022 at 12:08 AM, Hulkbust44 said:

It's half the Attk format scale

Range does not matter. "Maximum range", "half of the Attk format scale", or anything else is incorrect for C-Scope.

Imagine looking through a camera. The boarders of the camera's field of view is your yellow box. If someone asked you "what range is that camera set at?" what would you say? There is no "range" setting that changes a field of view. If you had the moon as a datalink target, it would either be in or out of your field of view just the same as a bird 20 feet from your aircraft.

Just to clear up the analogy, "zooming" a camera changes the FOV which is the same as changing the radar bars and scan width not the "range".

IIRC you can limit the datalink range of contacts to help declutter the display to show only near targets. In our analogy this would be like blurring the background of your photo--it has zero effect on which objects are in or out of the view.

Edited November 14, 2022 by AroOmega

[Recluse]

2 hours ago, AroOmega said:

Range does not matter. "Maximum range", "half of the Attk format scale", or anything else is incorrect for C-Scope.

Imagine looking through a camera. The boarders of the camera's field of view is your yellow box. If someone asked you "what range is that camera set at?" what would you say? There is no "range" setting that changes a field of view. If you had the moon as a datalink target, it would either be in or out of your field of view just the same as a bird 20 feet from your aircraft.

Just to clear up the analogy, "zooming" a camera changes the FOV which is the same as changing the radar bars and scan width not the "range".

IIRC you can limit the datalink range of contacts to help declutter the display to show only near targets. In our analogy this would be like blurring the background of your photo--it has zero effect on which objects are in or out of the view.

Well put!

[GumidekCZ]

null@BIGNEWY Please, re-open this bug report. There is for 100% bug in blind evelevation areas inside of scanned box.

[Hulkbust44]

On 11/14/2022 at 11:33 AM, AroOmega said:

Range does not matter. "Maximum range", "half of the Attk format scale", or anything else is incorrect for C-Scope.

Imagine looking through a camera. The boarders of the camera's field of view is your yellow box. If someone asked you "what range is that camera set at?" what would you say? There is no "range" setting that changes a field of view. If you had the moon as a datalink target, it would either be in or out of your field of view just the same as a bird 20 feet from your aircraft.

Just to clear up the analogy, "zooming" a camera changes the FOV which is the same as changing the radar bars and scan width not the "range".

IIRC you can limit the datalink range of contacts to help declutter the display to show only near targets. In our analogy this would be like blurring the background of your photo--it has zero effect on which objects are in or out of the view.

 

It's what is stated in the radar manual, 742-100 I believe, and 600-100. Also rember the elevation scale is not always fixed, there's a option at OSB 11.

[MarcT-NL]

Remember, the AZ/EL also shows information from the datalink, not only your own radar.

 

I'm not shure what they did in the Jan-25 update however. Now the AZ/EL only shows targets that are already locked by my own radar !  What use is that ?

Ik have to investigate this further however. Maybe I'm doing something wrong. Or do you guys see this too ?

-EDIT- Hmmm, seems alright afterall

Edited January 30, 2023 by MarcT-NL

[amalahama]

Has this bug been fixed in latest OB? 

[Mario.]

Nope, its been a bug I've worked around for years and by the looks of what the solution is I bet the f-18 will be broken in many ways for years to come.

[howie87]

My main problem with this bug is that data-linked targets show as being within the radar's FOV when they aren't... Which makes the AZ/EL mode useless for locking targets. What's the point in having an FOV box that doesn't show the radar's actual FOV? Could you please review this and remove the 'correct as is'? @BIGNEWY

[AroOmega]

Does anyone know if there is an official way to unmark this as "solved"? It seems clear that the solution was incorrectly marked out of confusion. Do we contact mods or report the solution post?
If not, I assume we'll need to re-test the issue and make a duplicate post.

[norman99]

Seems like ED are back to burying their head in the sand when it come to things they don't understand. The AZ/EL FOV is wrong, and should be fixed.

If it is incorrectly showing the bounds of the radar scanning area as absolute elevation values (as opposed to angular elevation), then there is a misunderstanding on what this function is actually supposed to display.

Some feedback from either @BIGNEWY or @NineLine would be greatly appreciated.

[BIGNEWY]

2 hours ago, norman99 said:

Seems like ED are back to burying their head in the sand when it come to things they don't understand. The AZ/EL FOV is wrong, and should be fixed.

If it is incorrectly showing the bounds of the radar scanning area as absolute elevation values (as opposed to angular elevation), then there is a misunderstanding on what this function is actually supposed to display.

Some feedback from either @BIGNEWY or @NineLine would be greatly appreciated.

I will ask the team to take another look, but please keep your feedback back civil, no matter what you think we do take care of many issues and tweak when evidence is found, but we will take our time, rushing changes leads to more work and errors. People who claim to be knowledgeable on various aspects of our aircraft are not always right and send wrong or conflicting evidence so we have to be very careful.

thanks 

 

[HILOK]

maybe what has everyone confused is, we would expect that the AZ/EL FOV box should grow (while keeping its edges proportional to the scan area set), when moving the radar TDC up (=forward =further away), and the box should shrink (to a point ideally), when moving the radar TDC down (closer to the nose).
then again, that would not make any sense, as the B-scope of the radar page does not depict a cone, but instead is stretched out left and right, as the TDC comes closer to the aircraft's nose.
in other words the EZ/AL page reflects the radar page's distorted view.

[GumidekCZ]

@HILOK AZ/EL is not top-down radar view, but something like radar first person view. Borders should change only by changing scan elevation, azimuth, #bars. NOT distance.

[dorianR666]

6 hours ago, HILOK said:

maybe what has everyone confused is, we would expect that the AZ/EL FOV box should grow (while keeping its edges proportional to the scan area set), when moving the radar TDC up (=forward =further away), and the box should shrink (to a point ideally), when moving the radar TDC down (closer to the nose).

if youre moving tdc vertically on attk rdr, the shape of the scan volume doesnt change. therefore nothing in az/el should change either. that is correct.

the problem is something else, there is some kind of a math bug in calculation of the bottom and top yellow lines of the box. perhaps it doesnt take into account that bars are overlapping, making the box larger than correct.

Edited May 9, 2023 by dorianR666

[Tholozor]

3 hours ago, dorianR666 said:

perhaps it doesnt take into account that bars are overlapping, making the box larger than correct.

Yea, I was going to suggest something like this as well regarding if the beamwidth was just being multiplied by the bar scan or if the overlap was accounted for.

[Ghosty141]

So let's get this straight. Basically the documentation CANNOT be right. It lists the yellow box clearly as RADAR FOV meaning, the radar can see everything in it's field of view. In the following screenshot we can clearly see the LST is in the box of the AZ/EL page and within the elevation range of the radar on the right side.

The problem arises once I move the yellow box (or radar elevation) so that the target is OUTSIDE of the radar elevation boundaries. On the radar we can clearly see the LST is 2k ft below the cone of the radar. On the AZ/EL page though the contacts are outside of the field of view of the radar (the radar cannot see them anymore because of the elevation), they are still shown within the yellow box called "Radar FOV" in the documentation.



This discrepancy makes the AZ/EL page almost worthless since I can't use the yellow "Radar FOV" box to control the radar elevation since based on it, I can slew my targets out of the radar FOV while the yellow box still indicates they are in view until they fade.

[Rissala]

Still "correct-as-is"?

To reproduce this issue:
Spot any target at some range (preferably in TWS so alt is shown)
-> open AZ/EL page on the left
-> move antenna elevation so that the target is just about not inside altitude range
-> observe that the AZ/EL page still shows the target inside the radar fov (yellow box)
-> the discrepancy is that attack radar page shows that the target is outside the scan range while AZ/EL shows the target inside the scan range

[BIGNEWY]

We have made a report regard scan volume the team will make some tweaks

thank you