AZ/EL CIT FOV limits

[Smashy]

I've been reading about and experimenting with the AZ/EL page in the Hornet and one thing I can't figure out is the purpose of the CIT range function (OSB 12, 13) and azimuth limit function (OSB 19).

 

Is there a tactical or technical reason why I would want to limit the range or width of the FOV for IFF interrogations?  It seems that keeping both options at their maximum values provides the most benefit in terms of information and SA.  There doesn't seem to be a performance penalty nor does there seem to be any reason to do so from a tactical perspective.  I mean the radar is surely putting out a ton more EM energy than the CIT interrogator, right?  What am I missing?  Perhaps something that is yet to be implemented in the AZ/EL format will help make sense of this?

 

On a related note, I've found that keeping the "L&S INT" option unboxed and the "AUTO INT" option boxed to be the best combination when CIT range/azimuth are at their maximum values as the "L&S INT" option will perform an automatic 22-degree pointed interrogation of the L&S trackfile where the "AUTO INT" will do an automatic 140-degree scan interrogation and hit everything on the page.

 

Other questions and observations after playing with the AZ/EL format over the last few days:

• I'm still trying to find the best way to use the AZ/EL page to contribute to SA.  There's a lot of HOTAS'ing to fiddle with and a lot of information to digest/crosscheck when considering the ATTK, SA and AZ/EL pages.
• the AZ/EL is really useful in controlling the scan volume center of the AA radar, especially in RWS.  I don't think the azimuth of the RWS FOV could be controlled before AZ/EL was available.
• it's slightly easier to cue the FLIR off the radar from the AZ/EL page.  At least with the way my HOTAS is currently setup.
• it's really cool to have some kind of visual feedback when pressing the SCS to perform an IFF interrogation.  Before AZ/EL, doing an IFF interrogation felt like a button press that went straight to /dev/null.

 

How are you guys using AZ/EL?  Any tips or tricks that you've found useful?

[Svend_Dellepude]

Interesting questions. I would like to know as well.

 

In TWS you can engage AUTO before you bug a track and then use the AZ/EL page to control elevation and azimuth, to acquire targets. Much easier than taking the hand off the stick to toggle between MAN/AUTO on the DDI.

 

I'm sure there is a missing link between BIAS/MAN and AUTO in TWS that will make TWS AUTO more useable, but until that is implemented this is an 'ok' workaround.

 

Haven't used the FLIR much for A/A because i basicly found it useless. too much fiddling around on OSB's. Maybe i should give it another go.

[Joni]

Interrogations signals will tell everyone that they are being interrogated so there's a thing there where you might not want that.

 

But at the same time why would that matter if the radar itself is already giving away your position and type of threat (carrier frequency)?

 

I think there should be a performance penalty but in DCS no matter what you set it will always interrogate every 10 seconds. 

 

Wags even said there is an update rate change but they forgot to code it in dcs? I don't know.

 

Good questions though.

[Smashy]

1 hour ago, Svend_Dellepude said:

In TWS you can engage AUTO before you bug a track and then use the AZ/EL page to control elevation and azimuth, to acquire targets. Much easier than taking the hand off the stick to toggle between MAN/AUTO on the DDI.

 

I'm sure there is a missing link between BIAS/MAN and AUTO in TWS that will make TWS AUTO more useable, but until that is implemented this is an 'ok' workaround.

 

Haven't used the FLIR much for A/A because i basicly found it useless. too much fiddling around on OSB's. Maybe i should give it another go.

 

Good suggestion with TWS AUTO.  I'll give that a shot and see how it works for me.

 

I wouldn't burn too much time on the AA FLIR mode if you don't already use it.  I was fiddling with it out of curiosity and to see if it worked as advertised in the various docs I've read.  It works as described most of the time but I've only used it in controlled test missions.  I thought it might be useful in setting up a sneak attack like the EO sensor in Flanker 1/2 but it's not that easy to use and can't imagine it being very useful in an actual combat mission.  The helmet-mounted display and AIM-9X are much better at setting up and executing an attack without using radar.  Still, the FLIR does have the advantage over the HMD/9X in that it can acquire BVR targets so perhaps more FLIR practice is needed.

Edited January 14, 2021 by Smashy

[Mo410]

Consider if you are interrogating Mode 3/C as well as other modes in an area where there might be civilian traffic.  You may want to limit the range to 40 or 80 to avoid cluttering the AZ/EL or radar page with too many symbols.  This is more of a filtering option, as the interrogation signals continue to travel regardless of the range you set.  80 is a good number as you rarely care about track files that will respond to an interrogation beyond that.  Width-wise is as you describe, keep it wide and in auto unless EMCON is a concern.

[Joni]

4 minutes ago, Mo410 said:

Consider if you are interrogating Mode 3/C as well as other modes in an area where there might be civilian traffic.  You may want to limit the range to 40 or 80 to avoid cluttering the AZ/EL or radar page with too many symbols.  This is more of a filtering option, as the interrogation signals continue to travel regardless of the range you set.  80 is a good number as you rarely care about track files that will respond to an interrogation beyond that.  Width-wise is as you describe, keep it wide and in auto unless EMCON is a concern.

 

Say what?

 

I don't think you're talking about the same thing here. We're talking about the interrogation azimuth and range, has nothing to do with how many things are shown in any radar format.

[Mo410]

Any interrogations that respond positively should appear on the AZ/EL and Radar format.  It is done a little artificially in DCS, but the options exist.  The question was why limit the range, and the answer is to filter out returns of transponders that you don't want to see.  It is purely a filter, does not do anything with the distance of the signal, which I think was potentially a source of the question.

[Joni]

7 minutes ago, Mo410 said:

Any interrogations that respond positively should appear on the AZ/EL and Radar format.  It is done a little artificially in DCS, but the options exist.  The question was why limit the range, and the answer is to filter out returns of transponders that you don't want to see.  It is purely a filter, does not do anything with the distance of the signal, which I think was potentially a source of the question.

 

No, it doesn't work like that. Only the covered radar beam generates trackfiles to be interrogated.

 

 

[Joni]

2 hours ago, Mo410 said:

Any interrogations that respond positively should appear on the AZ/EL and Radar format.  It is done a little artificially in DCS, but the options exist.  The question was why limit the range, and the answer is to filter out returns of transponders that you don't want to see.  It is purely a filter, does not do anything with the distance of the signal, which I think was potentially a source of the question.

 

OK I see now that you were talking about range not azimuth. In azimuth is like I said.

 

As for the range, I'm sure the velocity and range gate are the same as the radar's, so it won't allow it to display everything.

[Smashy]

2 hours ago, Joni said:

 

No, it doesn't work like that. Only the covered radar beam generates trackfiles to be interrogated.

 

 

 

Ok, I'm not the most technically adept at this stuff but here goes...

 

Is it possible that the AZ/EL format is capable of displaying IFF contacts that aren't getting painted by the onboard radar?  Sort of like how non-military ATC systems work at airports.  As @Mo410 suggested, an appropriate interrogation mode would have to be used.  If so, I would think a filter based on IFF mode would be better than a range filter.  But hey, it's the Hornet not the F-35.  As I dig into the Hornet more, I'm finding various user interface/usability issues that have me scratching my head and wondering, "who decided to do it this way?".  It's all part of the charm of the Hornet and I'm really enjoying learning about the plane and its systems, warts and all.

 

At any rate, I don't think any modes besides Mode 4 is implemented in the Hornet module yet so all this might not matter anyway.

[Joni]

1 minute ago, Smashy said:

Is it possible that the AZ/EL format is capable of displaying IFF contacts that aren't getting painted by the onboard radar?

 

Nope. Simple as that

[Bunny Clark]

1 hour ago, Joni said:

 

Nope. Simple as that

It's not actually. IFF is a form of radar transponder, it's entirely possible to get a return from a contact that hasn't been detected by the radar. It does need to be within the radar's field of regard, but you can get an IFF return off an aircraft that's too far away or that has too slow a closure rate to be detected as a target by the radar. 

 

This is the exact reason civilian airport terminal radars use a transponder system: it allows them to identify returns as specific aircraft, and it allows them to extend the range of a relatively low power radar system. 

[Joni]

13 minutes ago, Bunny Clark said:

It's not actually. IFF is a form of radar transponder, it's entirely possible to get a return from a contact that hasn't been detected by the radar. It does need to be within the radar's field of regard, but you can get an IFF return off an aircraft that's too far away or that has too slow a closure rate to be detected as a target by the radar. 

 

This is the exact reason civilian airport terminal radars use a transponder system: it allows them to identify returns as specific aircraft, and it allows them to extend the range of a relatively low power radar system. 

 

No, it doesn't need to be in the radar's field of regard. The blades send an independent beam, but the carrier frequency is totally different and has no intention to listen to the return of the interrogations rather than the reply itself.

 

Remember the hornet doesn't have the interrogator in the mechanical gymbal of the radar. It uses the blades antennas that you see in the nose.

[LastRifleRound]

 I love the AZ/EL page. The primary way I use it is with TWS MAN. I keep the TDC on the attk radar format. Now, I can use the TDC azimuth to control azimuth and the elevation wheel to control the elevation and see positive readouts of both immediately without taking my hands off the controls and without ever leaving the same DDI. TWS AUTO isn't properly implemented yet so it doesn't use a scan centroid, so this is the best way of keeping the tracks I want in the radar FOV.

 

It also works great in RWS when I'm trying to keep a track file on a subset of contacts (140deg AZ tends to drop tracks at more than 1 bar).

 

As for FLIR, I haven't tried it yet, but could you use AZ/EL to cue the FLIR on to a datalink target, then track it with the FLIR? Should work within 20nm sort of like a poor man's IRST (really more of an IRT as you're not really searching with the FLIR).

[Smashy]

1 hour ago, LastRifleRound said:

As for FLIR, I haven't tried it yet, but could you use AZ/EL to cue the FLIR on to a datalink target, then track it with the FLIR? Should work within 20nm sort of like a poor man's IRST (really more of an IRT as you're not really searching with the FLIR).

 

I just tried this and no luck.  I think the only way to cue the FLIR is from a trackfile.  I could be wrong but I could find no way to get the FLIR to cue off of a datalink target.

 

While playing around with this, I found that I could cue the FLIR from a stale trackfile by putting the radar in SIL mode, setting trackfile timeout to max (32), doing one narrow sweep with the ACTIVE button, then designating an L&S.  With the L&S, the FLIR would slew on to the contact with the RRSLV button on the FLIR page.  It would lose track after the trackfile expired but I could establish a PTRK pretty easily after that.  It worked a little under 20 miles.  AZ/EL wasn't much use other than providing HOTAS access to the FLIR format.

 

I can't imagine how this could be useful as it was pretty complicated and required a lot of HOTAS gymnastics.  Also, I would imagine any sneakiness gained could be lost after that one radar sweep.  I was like a blacked-out special forces guy who drops his flashlight while sneaking around and the light turns itself on as it bounces across the ground.  Well, maybe not that bad.

 

Still, It was fun trying to get this to happen and good practice for that HOTAS muscle memory.

[Harker]

Right now, the AZ/EL page doesn't show offboard tracks, but it's supposed to. So when that feature comes, it'll be possible to cue the FLIR at an offboard track, while keeping your radar silent.

And as Wags showed in the last Hornet video, you can cue the FLIR on a jamming contact (AOT) that your radar hasn't resolved the range for yet.

[BIGNEWY]

Hi, 

 

In our references, we have zero indication of offboard / MIDS-only track on the AZ/EL page. If you have public information this is different please let me know. 

 

thank you

[AvroLanc]

1 hour ago, BIGNEWY said:

Hi, 

 

In our references, we have zero indication of offboard / MIDS-only track on the AZ/EL page. If you have public information this is different please let me know. 

 

thank you

 

hmmm...we were led to believe this might be coming.

 

The question should be - why wouldn't it be there? Most importantly, does the documentation specifically rule it out? Does the AZ/EL documentation pre-date / is concurrent / post-date documentation for MIDS / Link16? Because if there's a mix of documentation being used instead of a single harmonised reference I can see that being an issue.... 

 

 

Edited January 17, 2021 by AvroLanc

[BIGNEWY]

20 minutes ago, AvroLanc said:

 

hmmm...we were led to believe this might be coming.

 

The question should be - why wouldn't it be there? Most importantly, does the documentation specifically rule it out? Does the AZ/EL documentation pre-date / is concurrent / post-date documentation for MIDS / Link16? Because if there's a mix of documentation being used instead of a single harmonised reference I can see that being an issue.... 

 

 

 

Hi 

 

We initially thought so, but upon a further review of our references material, there is no mention of this.

 

thanks

[Santi871]

AzEl is an MSI display along with the attack and SA formats and as such, any MSI trackfiles - onboard, offboard or both - should be displayed. There is no question about this.

[BIGNEWY]

16 minutes ago, Santi871 said:

AzEl is an MSI display along with the attack and SA formats and as such, any MSI trackfiles - onboard, offboard or both - should be displayed. There is no question about this.

We have no information to support this if you have some please let us know.