Please help me explain this loss of STT TID tracks

[Stickler]

EDIT: This post was originally about a loss of PD-STT lock. Through more testing I found the actual problem is a loss of the TID track obtained from an STT lock, not the loss of the lock itself. Text and title changed accordingly.

 

2.8.1.34667

 

Start parameters:

F-14B, 25000 ft, M 0.8, human

Su-30, 25000 ft, M 1.0, AI, programmed to maintain pure pursuit on F-14B and not to use chaff or ECM

Split range 55 nm, head-on

 

Steps:

1. F-14B establishes a valid PD-STT lock. TID track file visible
2. F-14B cranks to 40° ATA, 3-4 G
3. F-14B maintains new heading, TID track file remains visible
4. F-14B bunts over, 0.5 G
5. Loss of track (X) occurs at about 15° nose low with a radar elevation of around +10.0 ° (indicated by flares in .acmi). Track file is deleted shortly thereafter. Track file data readouts (bearing, track altitude etc.) are lost.
6. The STT lock, WEZ symbology, HUD radar cross are maintained throughout. When re-establishing pure pursuit, the TID track and the corresponding track file data readouts re-generate automatically.

 

This has been 100% reproducible for me. Happens both with a human RIO and Jester, also in PULSE STT and/or against A-50 (this one is slower than 1.0 M of course).

 

It it likely this has something to do with TID track generation capacity based on radar elevation/azimuth in STT, since the test can be varied as follows:

• When crank is 50° instead of 40°, loss of TID track occurs at around 5-10° nose low.
• Without crank (maintaining 180° aspect), the TID track is maintained during bunt-over until the vertical limit of the radar elevation is reached (lock breaks around 54° indicated antenna elevation).
• In general, the loss of TID track occurs at a smaller nose-down angle the greater the crank.
• The track file is maintained throughout when using TWS.

Is anyone able to explain why the loss of track occurs at parameters which should be able to support it (at least I am not aware of a track production limit based on azimuth/elevation when in STT)?

Not posting this as a bug since it is possible I'm overlooking something obvious or things are working as intended.

loss_of_lock.acmi

Edited December 25, 2022 by Stickler

[Noctrach]

Yep, has been happening for >1.5 years now

A combination of antenna elevation + azimuth + roll exceeding a certain value will break the track but not the lock. Seems to happen when the sum exceeds 55, even if none of the individual components exceed gimbal limits.

Quite annoying during BVR cranks or flying an aggressive intercept since as a RIO it means you lose target SA in STT unless your pilot reverses the crank.

was reported as investigating but never received a fix

 

Edited December 25, 2022 by Noctrach

[WarthogOsl]

So, does that mean it's dropping TWS tracks when it shouldn't, or that it's maintaining STT locks when it shouldn't?

[Stickler]

Thanks @Noctrach, looks like I'm not crazy after all. I think the loss of lock/track due to roll and the loss of track due to ATA and pitch might be closely interrelated but they need not necessarily be the same issue. I can hold an STT-generated TID track all day long with 90° or even 180° AoB provided my ATA remains close to 0°.

So the "antenna elevation + azimuth + roll > 55°" relation is probably not really additive (at least with regard to roll); if it was, you'd certainly lose the track at 90° AoB.

I incidentally found that if you set 40° ATA, then roll inverted and then push the stick forward, the track will be lost when reaching around +15° antenna elevation as well.

In any case, no need to debug this further on our end since this has been reported twice now.

@WarthogOsl I'd say it's dropping STT-generated TID tracks when it shouldn't. Since I do not have access to the original aircraft's AWG-9 manual I cannot prove my point but I can hardly imagine the real radar couldn't maintain an STT-generated track at 40° ATA, 15° pitch and 0° roll when the radar's limits are ±65° in azimuth and -76°/+54° in elevation, especially since the lock itself can be maintained at these parameters.

In other words, why should it be able to maintain the lock but not the track?

[Noctrach]

16 hours ago, Stickler said:

Thanks @Noctrach, looks like I'm not crazy after all. I think the loss of lock/track due to roll and the loss of track due to ATA and pitch might be closely interrelated but they need not necessarily be the same issue. I can hold an STT-generated TID track all day long with 90° or even 180° AoB provided my ATA remains close to 0°.

So the "antenna elevation + azimuth + roll > 55°" relation is probably not really additive (at least with regard to roll); if it was, you'd certainly lose the track at 90° AoB.

I incidentally found that if you set 40° ATA, then roll inverted and then push the stick forward, the track will be lost when reaching around +15° antenna elevation as well.

In any case, no need to debug this further on our end since this has been reported twice now.

@WarthogOsl I'd say it's dropping STT-generated TID tracks when it shouldn't. Since I do not have access to the original aircraft's AWG-9 manual I cannot prove my point but I can hardly imagine the real radar couldn't maintain an STT-generated track at 40° ATA, 15° pitch and 0° roll when the radar's limits are ±65° in azimuth and -76°/+54° in elevation, especially since the lock itself can be maintained at these parameters.

In other words, why should it be able to maintain the lock but not the track?

If you look at the TID readout when you're in a roll attitude on a cranking target >10 left or right you will notice the antenna elevation will actually go crazy beyond the expected azimuth-to-elevation transpose. So they might be separate issues but I definitely feel they've the same root cause.

The AWG-9 has no roll gimbal and will transpose ATA onto elevation and vice versa to generate the required angles to position the dish during banking turns. I've long felt something is fundamentally scuffed with the simulation of how it does this. 40 ATA plus a 15 degree roll can have your TID elevation readout shoot up way into the 30s, which is not how that math works out. In doing this you will also see the DDD return fade out and the TID track start dropping, even though STT is maintained throughout.

I feel that it is somehow doing a partial simulation of the AWG-9 going out of bounds on its gimbals, without actually doing so. Not sure why this never got fixed though since it's crazy easy to reproduce.