MUST Know: Fix an F-14 Departing from a Carrier [AN/ASN-92 Bugfix]

AN/ASN-92 INS Study: Table of Contents

The recent INS Study, scratched the surface of the complex topic that is the AN/ASN-92 Inertial Navigation System: the primary means of navigation (and much more!) mounted aboard the F-14A and F-14B.
This Article, instead, goes less into the details of the avionics, but presents a problem whose understanding and resolution is fundamental to any Tomcat crew, no matter the type of experience they are looking for.
The writing of this Article actually follows the more in-depth study of the INS, and it has been encouraged by the fix of a bug affecting the function here explained, something that makes of the resolution of the issue discussion much, much simpler.

Video!

I hastily put together another short video discussing the issue, and showing how it can be fixed and how it influences the tasking of an F-14.
This video is even more concise than this article, but I thought that seeing the problem and its resolution would have a greater impact than only reading and looking at screenshots.
Let me know your thoughts in the comments, here or on YouTube!

Carrier Operations

Simply put, the Carrier is a big piece of metal, and it affects how certain components of the avionics work, in particular the device that provide correct information about the heading of the aircraft.

Therefore, the crew must recognise the problem and fix it, to avoid potentially grave issues during the mission.
This is done via the “HDG pushbutton” located in the Compass Control Panel (or simply “COMP” panel), which is part of the Right Side Console. The thing gets a bit tricky because the button must be actuated in specific conditions: unaccelerated, stable flight.

Spotting the De-sync

The issue is identifiable in several ways. RIOs checks the values of the computed magnetic variation (vC) versus the manual magnetic variation (vM) routinely, especially when operating from the carrier, or if the MV/Nav Mode (usually “IN”) acronyms alternate on the TID. Generally speaking, during long flights when there is not really much action, a couple of checks at the INS are always a good idea.
There is a third way to check, but it is slightly more complex: the Sync indicator in the COMP panel in the front seat tends to move away from the centre when a discrepancy is present. However, in order to “enable” the indicator in the first place, the pilot has to fly steadily, at constant speed and altitude.

Thus, the simplest way to check the difference between vC and vM is from the back seat. This one of the most basic tasks of the RIO, and it is part of the startup sequence.
By means of the CAP “CATEGORY” knob, select “NAV” then the “MAG VAR (HDG)” function. The values of vM and vC will alternate on the top-left of the TID.
Compare the two values: they should be quite close. If not, there is a series of steps that can be followed and are described in the in-depth discussion about the INS (Part IV).
However, in this specific example, the value of vC should be off due to the effects of the CV.

Fixing the problem

Now that the crew is aware of the issue, fixing it is rather simple and there are two ways to do it.
The first is the “natural” synchronisation that occurs when the aircraft is flying steady, at constant speed and altitude. The sync ratio is about 9° per minute, and the process is interrupted every time the attitude or the speed of the aircraft is perturbed.
A much better alternative is using the HDG pushbutton located in the COMP panel (unfortunately buggen until recently). The process still requires the pilot to fly the aforementioned stable profile and, as soon as the Sync indicator dislodges itself from the centred position, the pilot presses and holds the HDG pushbutton. In a matter of a few seconds, the problem is solved, and the RIO can verify that the discrepancy between vC and vM should now be a matter of a couple of degrees.
Quite an improvement, considering that the initial difference can easily be in the order of tens of degrees!

The figure below (click to enlarge) shows the difference between the avionics pre-re-sync and post (initial situation wrapped in white rectangles).
The sync indicator is off-centre when the Tomcat is flying at in an attitude-stable, unaccelerated flight.

Carrier departure: Example

Players depart from Carriers following different patterns. Some refer to modern or less modern US Navy standards, others YOLO up in the sky.
Personally, depending on the pilot, this is usually the procedure what I follow:

• Line up on the cat, conduct pre-departure cross-checks. Manly waive at the coloured pixels outside (or the emptiness – If you don’t own the Super Carrier module);
• Post departure, make a 10°-20° turn for clearance, just in case some goes wrong, so the carrier does not run over you;
• Turn parallel to BRC and stabilize at 500ft, 300kts;
• Maintain speed and attitude until DME is about 7nm (TACAN is quite handy for this).

Assuming it takes a couple of miles to depart, perform the clearing turn and stabilize, the crew has more than enough time to re-sync the AHRS before reaching the 7 nm DME boundary.
Time-wise, circa 90″ are required to fly such distance at a speed of 300 kts. Since the now-fixed fast erection AHRS function takes less than 10″ to complete, performing the re-sync should not constitute a problem.

Laziness kills (Drama time!)

Let’s say you want to avoid sorting out your AHRS post departure from a CV. What can happen? Considering that most players never fixed the situation anyway, why should you do it? The following examples show what can happen if the AHRS is not synchronised post departure.

Example I: Non-INS Navigation

This example is the least common, since the INS is used most of the time, and NAVAIDs can help to navigate using the aircraft as the point of view.
There are occasions where the INS is not used, such as:

• navigating using dead reckoning and pilotage;
• following IFR / nav charts;
• following specific navigation instructions from controllers (e.g. vector to base, in a map such as the Syria, where TACAN stations are not very common).

To make the matter as straightforward as possible, the scenario sees a Section of Tomcats departing from a carrier towards their objective, located due North of the CV. For even greater simplicity, we assume that the map displays Magnetic Heading, rather than True.
If the desynchronisation is null, the F-14s will fly to their objective without any issue (Figure below).

The trouble starts when the de-sync is very conspicuous. Considering what is discussed in this Article, a heading error of almost 20° is not impossible, on the contrary. The figure above shows where an error of 18° (no AHRS re-sync) and 2° (usually greater than the AHRS re-sync). Note that I did not take into consideration the sign of the difference.

Now imagine that the mission is supporting friendly troops disembarking and assaulting Ayia Napa from the sea (the Eastmost corner of land in the figure below). How much time is wasted trying to find the correct tasked area, especially in low-visibility conditions?
We can also assume that the airports of Larnaca and Kingsfield (the two just West of Ayia Napa) are protected by air defences, leading the F-14s to expose themselves to unnecessary risks, possibly failing the mission, just because they did not sort out a well-known issue.

After only 100 nm (about 12′ flying at ~500 kts), the positional error induced by not re-synchronising the AHRS is massive: more than 30 nm (Figure below)!

If you have read “Bio” Baranek’s most recent book, “Tomcat RIO”, there is a passage where he explains one case where they did not re-synchronised the AHRS, leading to severe navigation issue (albeit nowhere near as dramatic as the made-up situation described above). The quote and the chat I had with Bio are reported in Part IV of the INS study.

Example II: Air-to-Air

Air-to-Air is the aspect of a mission more affected by having wrong indications on the BDHI and other displays when information is transmitted via radio. The following scenario shows the difference between having the AHRS synchronised or not.
Modus operandi:

• one target, hot, a few tens of miles away;
• as soon as the bogey dope is answered, I turned to match the heading;
• once steadied, I took a screenshot.

The figure below shows a common scenario: the F-14 departs and immediately turns to intercept a target.
The AI AWACS calls:

BRAA (T)272, 45, 5000, hot

Translated into Magnetic, it gives 267° (mV is 4.9). The pilot turns towards such heading and finds… nothing. The closest target is circa 20° off to the left, almost at 1 o’clock. In terms of horizontal distance between the expected position and the radar return, we are talking of about 20 nm.
The angle δ represents the displacement caused by the error in vC. In fact, 4.9+12.8 = 17.7, to which more drift should be added whilst the F-14 manoeuvred to put the target on the nose.
In this case, the scenario is elementary: just one aircraft is slowly approaching the carrier. Imagine coordinating with other aircraft against multiple threats!

The figure below shows the very same scenario, post AHRS re-sync. New bogey dope request to the AWACS:

BRAA (T)272, 28, 5000, hot

The pilot turns to place the target on the nose, and this time the difference between the communicated heading and the radar situation is very close, just a couple of degrees, mostly caused by the aircraft drifting whilst the F-14 was manoeuvring.

The difference between the two scenario is clearly shown in the figure below. In both situations, we followed the AI AWACS’ directions, and in both cases the contact should have been on the F-14’s nose. However, the difference is absolutely staggering and can really create unnecessary headaches in any situation more complex than the one described. For example, problems coordinating with other assets, correlations, targeting and so on.

Conclusions: A MUCH LESS grim picture

The reality, especially when the topic is Navigation, is much, much rosy. The F-14, in fact, carries an incredibly effective Inertial Navigation System, the AN/ASN-92. When it comes to INS navigation using waypoints, the AN/ANS-92 offsets entirely the issue discussed in this Article, albeit it is affected by drift and other positional isssues.

In fact, the waypoints are stored as geographical coordinates, and the INS is used as reference, whilst the AHRS is mostly used, in normal navigation, to show the magnetic course and heading information. Moreover, when the magnetic heading is calculated, it is applied to the computed magnetic variation. However, vC partially comes from the AHRS and, eventually, the error is applied twice, annulling it
(Source: Naquaii and Grover – Heatblur devs.)

Datalinked information seems to follow a similar pattern. They as well are not affected by the de-sync of the AHRS. In fact, both waypoints and information passed via LINK4 are much more susceptible to another issue: INS positional drift.
Therefore, the de-sync of the AHRS is a problem mostly when trying to navigate using dead reckoning and pilotage, where the wrong value displayed on the compass can really throw the aircraft off course.

The figure below shows a number of waypoints and radar contacts displayed before and shortly after the AHRS re-sync: almost nothing changes besides the contacts being very slightly closer. However, the Magnetic Heading readout witnesses the huge difference before a desynchronised AHRS (right, MH 274, vC -10.7°), and the re-synced one (left, MH 256, vC +7.0°).
Note that the re-sync process was already undergoing when I pressed the pushbutton. The initial vC at departure was -12.9°.

There is another reason to rejoice: the natural tendency of the AHRS to re-sync itself when the F-14 is flying at constant speed and attitude.

The example shown below is similar to the one discussed in Example I. The goal is departing from a Carrier and head to Paphos International Airport. Planning on the F-10 map showed a True Heading from between the two points equal to T279°, with +4.9 vM.

Departure went as usual, from Cat 2 with a turn ~15° to port, followed by a turn to the expected magnetic heading of ~274° whilst climbing to FL200. This is where things get interesting: as I activated the altitude hold AP and then settled the throttle, the AHRS re-synchronisation started. Albeit much slower than using the HDG Pushbutton, it allowed me to slowly adjust my heading to maintain 274°. In other words, all I did is maintaining 274° and correcting when necessary. Eventually, as the figure below shows, the AHRS completed the re-sync, and I was flying on the correct course.

As immediately understandable, the problem is the lateral drift. However, good news because the INS was not affected by the de-sync, and further air-to-air instructions would not be affected, as the indicated heading is now within acceptable limits. This is probably why many players never fully realised this phenomenon.
However, imagine a new player trying to maintain formation with my aircraft, thus moving back and forward, up and down: his AHRS will not re-sync, leaving the Section with an incorrect reference method to correlate contacts and communicate.

So, I hope you have found this article useful. The discussed issue can potentially impact the effectiveness of the Tomcat, but it is easy to solve, once you know what to do.
Happy hunting!