Something every F-14 crew Should be aware of [CV Ops & AN/ASN-92 INS].

[Karon]

Hey folks!

I have spent some time studying the basics of the INS mounted on the F-14. It's definitely not brand-new technology, and it suffers from a few quirks but, generally speaking, is an outstanding piece of kit.

One of the issues affecting the avionics is related to the Naval employment of the Tomcat (and not only the F-14, definitely the A-6, probably the F-4 too).
A recent bugfix was recently released that sorted out the primary method of addressing this problem. Thus, I took the occasion and put some stuff together, something that I hope you can find interesting. Rather than go too much into the technical details of the problem, I'll keep this short and straight to the point. At the end of the posts, there are a bunch of links to a more in-depth look at the issue, and a study of the AN/ASN-92 INS.

 

So, where do we start?
Carrier. Big carrier. A lot of metal. The carrier causes some parts of the avionics to go nuts, namely the ones that should indicate the aircraft's direction. Let's call it "compass".

This causes issues to the relatively rarely used non-INS navigation (DR & pilotage, Aerodrome charts, specific instructions, etc) and, especially, Air-to-Air.
As mentioned, until recently, the only reliable fix was flying straight and unaccelerated (even non-continuously) until the AHRS re-synchronised. The ratio was ~9°/minute. This is why many never noticed the problem, but sometimes this is not a sufficient solution (especially if you YOLO from the catapult).
The dedicated function to address the de-sync of the "compass" is located in the front seat, in the Compass Control Panel: the HDG Pushbutton. Now that the HB devs sorted it out, it can sort out the "compass" in a matter of a few seconds, rather than minutes.

A lengthier article is available here; it provides a few more details.

A more in-depth short study about the INS is here. This article contains the tests I made and a few other observations.

 

I hope you can find this stuff interesting. Feedback is always welcomed.

PS: fun fact, this is probably my first post in this subforum

[WelshZeCorgi]

Does this mean that if both lead and wing do this fix, their headings will be comparably accurate to each other? We noticed that the heading differences between ships in multiplayer were off by a lot, making heading changes a bit difficult cause our true headings were off when we went to the assigned heading as directed by the HSI and hud. 

[Digitalvole]

Straight over my head, but the “banana for scale” deserves a 10/10

[algherghezghez]

But I’m not sure it’s working as intended.

In slaved mode it still gets substantial degradation (usually in lazy turns). What I think happens is that the compass still updates the gyro even when in a bank (where at certain headings depending on latitude the compass over or under reads).

this in the real tomcat was prevented by updating the gyro only in level flight 

[sLYFa]

I have the same impression. Very often afte I finish AAR my heading readout is way off. Same for flying in the marshall stack. Shallow turns seem to result in an unwanted sync to a wrong heading. 

[JupiterJoe]

Ignorance was bliss 

[Karon]

4 hours ago, algherghezghez said:

But I’m not sure it’s working as intended.

In slaved mode it still gets substantial degradation (usually in lazy turns). What I think happens is that the compass still updates the gyro even when in a bank (where at certain headings depending on latitude the compass over or under reads).

this in the real tomcat was prevented by updating the gyro only in level flight 

You sure it's not precessing? The AHRS doesn't like prolonged turns with rate < 6°/minute.

Another cause of precession is pitching > 82°, but this is of course not the case.

 

16 hours ago, WelshZeCorgi said:

Does this mean that if both lead and wing do this fix, their headings will be comparably accurate to each other? We noticed that the heading differences between ships in multiplayer were off by a lot, making heading changes a bit difficult cause our true headings were off when we went to the assigned heading as directed by the HSI and hud. 

If nothing else is going, then this should fix the problem. Obv there are situations where the de-sync occurs again post fix, the RIO should maintain awareness.

Edited August 11, 2022 by Karon

[algherghezghez]

Pretty sure since in dg mode doesn't precess even closely to the error a single turn can induce in slaved mode

Edited August 11, 2022 by algherghezghez

[Karon]

I can't check the bible right now, but I don't recall limitations about the mode. IIRC, it said that the AHRS has freedom of movement minus something, and precesses when pitch > 82° and over prolong easy turns with AoB leading to 6°/min.

 

EDIT: had a quick and I think what I said it's correct. I'd take longer to thoroughly check.
I noticed that the COMP knob looks weird on the displays. I could swear this was fixed a long time ago, or perhaps I'm just wrong. I raised it to the devs, though.

Edited August 12, 2022 by Karon

[sLYFa]

6 hours ago, Karon said:

I can't check the bible right now, but I don't recall limitations about the mode. IIRC, it said that the AHRS has freedom of movement minus something, and precesses when pitch > 82° and over prolong easy turns with AoB leading to 6°/min.

 

I experience these "faulty syncs" at much higher turn rates at about 90°/min. It also doesn't happen in DG mode so I assume it must have something to do with the automatic MAD correction feature in SLV mode.

Edited August 12, 2022 by sLYFa