AGM-45A Shrike ADI crossbar behavior

[callmepartario]

as seen in https://youtu.be/eqxfNAEkQo8?t=182

and https://youtu.be/eqxfNAEkQo8?t=414

[callmepartario]

just noting, this would be far less of an issue with apr-25 implementation - but much of the same information could be used to drive the bdhi needles for these purposes.

were this to be implemented, it might be best suited as an equipment option in the ME, since it required shrike seeker head equipment to be placed in the nose cone.

[nadav-yo]

We are talking about the crossed lines here, right? (bottom left to the center)

[callmepartario]

that's correct

[nadav-yo]

Do we have documentation regarding this? What's the expected behavior, is it only shown with shrikes, etc?

[callmepartario]

in this setup, the radar head in the nose cone of the aircraft is replaced with a shrike seeker. a pilot probably had a different equipment panel set up since there would be no point in having the radar screen there.

for implementation in the a-4e-c. it'll end up an equipment option you select in the mission editor - ground radar OR shrike seeker head in the nose. then use the same radar power standby / switch to enable the function.

will probably have to also set up some sort of override for the MCL so they can't fight over the needle position.

[nadav-yo]

I see there is a [devices.SHRIKE] = 3, in adi_needles_api.lua precedence list, so that just mean a adi target should be set when we have a lock in shrike.lua? and I see adi_needles_api:setTarget is being called from ara63_mcl.lua. so you mean when a target is lost, MCL should bump to control again? That's all given that the shrike seeker head was installed, of course.

[callmepartario]

those sound like the right bits to look at, yeah!

i would probably do it up so that the moment the MCL is turned on (which is instant, it's a solid state piece of gear). i think the best outcome here is:

if the MCL is powered on, disable the shrike seeker head driving the ADI needles, even if the radar is turned on.

[nadav-yo]

So isn't MCL has higher priority?

device_priority = {
        [0] = 0,
        [devices.SHRIKE] = 3,
        [devices.MCL] = 2,
        [devices.NAV] = 1,
    },

[callmepartario]

oh, is that already in the code somewhere? i would have thought MCL would take the wheel, but if that's already in there, go with it.

[nadav-yo]

Yeah, that's in adi_needles_api.lua along with the code to make sure you can claim the needles only if no device has it, or your device have higher priority.

So by current logic, Shrike will win and claim the needles from MCL.

[callmepartario]

right on. the cone is small so it'd be a rare pop only, anyway if you're flying a landing pattern.

[nadav-yo]

I've started an initial implementation for that in https://github.com/nadav-yo/community-a4e-c/commit/18092aeab42b95e46596bd74402591dfdda0a74e I just wanted to see if I'm in the right direction. I'm also not sure about the gs and loc values - as this is very new to me I still need to understand what exactly to put there

the glide slope is a tricky one.

[08jne01]

The reason I didn't do this in the past is there is no way to guarantee which radar the shrike will go after on launch so the needles will mislead the player.

[nadav-yo]

I guess that it choose the one with the highest intensity, which for us could mean the highest "power" (though it's not accurate, as there are more variables to it)

I also guess that in real life there was no guarantee

[nadav-yo]

looking at the image above again, is it possible that it was more than 3 degrees down or sideways? we use the const

SHRIKE_HORZ_FOV = 6
SHRIKE_VERT_FOV = 6

then check if horz_deviation < (SHRIKE_HORZ_FOV/2) and vert_deviation < (SHRIKE_VERT_FOV/2) so it's only 3 degrees each direction.

[callmepartario]

yeah it's 3 degrees for the seeker head in the missile itself. i would imagine that would be considerably wider when using the much larger and mobile mounting in the nose cone. the radar itself sweeps 60 degrees azimuth with a 5 degree horizontal beam height.

[nadav-yo]

So you will see it in the ADI before any sound indication?

[Drofseh]

So you will see it in the ADI before any sound indication?

If we could simulate what I believe is the correct seeker in the nose cone then yes.

[callmepartario]

So you will see it in the ADI before any sound indication?

yeah, that would be my thinking, yeah -- you essentially cross reference your RWR audio, if any and the ADI to start getting the bead with the shrike, then use the audio to refine your input from there to get on target.

[nadav-yo]

So, today we have a list of contacts, and the algorithm today will find one within 3 degrees.

The question I think is exactly how will it work, and I can think of one option

• Assemble the contact list as before
• Have the missile "lock" as before (it's basically the sound at this point) .

Then, from the contacts list we have 3 options if I'm seeing it correctly, to find the ADI crossbar "target"

1. filter by power, take highest
2. filter by deviation from center, take closest by degrees.
3. something from both?

Because let's say you have 2 radars , one in front of you but far, and one close, but at a higher angle. Which one should I track? I guess mostly 1? What could be the angle of the seeker? I guess it wasn't a full 30 per side (or 60).

I'm trying to get a hold of an actual pilot who flow a-4e through air force contacts, maybe he remembers 🤷

[callmepartario]

i think locking on to the highest power signal is a good way to prioritize the display, but welcome any good knowledge or input from others.

[08jne01]

So, today we have a list of contacts, and the algorithm today will find one within 3 degrees.

The question I think is exactly how will it work, and I can think of one option

• Assemble the contact list as before
• Have the missile "lock" as before (it's basically the sound at this point) .

Then, from the contacts list we have 3 options if I'm seeing it correctly, to find the ADI crossbar "target"

1. filter by power, take highest
2. filter by deviation from center, take closest by degrees.
3. something from both?

Because let's say you have 2 radars , one in front of you but far, and one close, but at a higher angle. Which one should I track? I guess mostly 1? What could be the angle of the seeker? I guess it wasn't a full 30 per side (or 60).

I'm trying to get a hold of an actual pilot who flow a-4e through air force contacts, maybe he remembers 🤷

In reality this would depend on the signals themselves and how they are mixed. I would imagine the steering signals from each of the contacts would contribute since the shrike is receiving from bands.

Fyi this is why I stopped with this originally because the API we have is not capable of providing us with what we need to make these decisions.

Also the shrike antenna has a beamshape the gain varies with angle and there are 4 lobes which determine the incoming signals. So it's not a case of the shrike can see +/- x degrees.

And for everyones information the shrike outputs the audio which should correlate with the adi needles.

Again the reason I didn't pursue this was because it would be misleading to the user which target the shrike is going for especially given we can specify that ourselves so when you centre the needle the shrike may fly off at a different target.

[nadav-yo]

Makes sense, but doesn't that mean that the sound output might also be incorrect?

I understand we can't get the information from the actual missile code, the only question is do you want to make a compromise. Doesn't the missile seeker itself shares a similar code or code capabilities?

The answer I got so far from a pilot who trained on the A-4 but not with the shrike - "you can't believe how inaccurate those were"