An aircraft carrier is a massive chunk of metal, it can drastically affect parts of the avionics.
Part III of this series practically determines the (sometimes dramatic) impact that operating from a Carrier has on the computed Magnetic Variation.
VC is the magnetic variation calculated inside INS/AWG-9 – the program takes the magnetic North from the AHRS and the true North from the IMU/INS, compares the two, and the difference is the vC. However, on a carrier deck, the magnetic North reading can be severely affected by different sources of the magnetic field, and hence the difference can get beyond that 2°.
Once airborne, the vC should slowly recover. Or alternatively, to speed up the syncing process, the pilot can press and hold the HDG pushbutton on the compass panel. One thing to remember – the aircraft must be in a straight unaccelerated flight, otherwise the acceleration gate wouldn’t let the sync happen.
Super Grover – Heatblur
After all we discussed the INS and its components, the question is: how can the discrepancies between vC and vM be attenuated post departure? After all, the sooner the avionics is synchronized and up and running, the fewer errors affect the computations.
The previous parts poured more details into the INS topic (albeit it is still scratching the surface). One of the most interesting points, is the clarification of “who does what” when it comes to the navigation in the moments immediately following a carrier departure.
This short chapter shows the somewhat dramatic effect of a non-synchronized vC.
vC Synchronization Over Time: Practical Examples and Tests
This scenario is set in the Syria map. Default year, no wind, a single F-14A-135-GR spawned hot on the catapult. The computed Magnetic Variation vC is circa -13° at spawn, whereas the manually inserted Magnetic Variation vM is 4.9°.
From this initial setup, I took off a first time, managed to fly levelled at about 300kts until vC matched vM then departed again, but this time I immediately turned and manoeuvred. Only after a few minutes I adopted a straight, levelled flight.
The following values are taken from the game itself, and show how different is the impacted on the process of determining vC.
Eventually, the question will be: is the standard departure (300kts, 500ft for about 7nm) enough to allow a proper computation of vC?
Test I: Standard Departure
To generate the chart displayed below, I collected 36 data points, from a carrier departure, until the value of the computed magnetic variation stabilized.
During the process, I flew the F-14 almost perfectly stable at 300 kts, but at a lower altitude than a standard departure (~ 100 ft).
Speed and altitude were stable from circa 45″, and after that moment, I was hands-off.
Note how vC did not decrease immediately, rather remained stable until, at about 1’20”, it started to align to vM. The most surprising aspect is the perfectly linear ratio of increase of vC, all the way until vM.
Eventually, the computed MagVar stabilized +0.8° over the manually defined MagVar.
If we consider vC stabilized as it reached the value of 5.7° (3’11”), we can calculate the distance covered by the F-14. At an average speed of 300kts, the distance covered is equal to circa 15nm, which is more than double the distance the standard departure should require.
Test II: Immediate Manoeuvres
The second scenario is based on 55 data points.
Right after the departure, I pulled and banked hard, accelerating. I then constantly turned and manoeuvred, leaving only a few seconds of straight, levelled flight, yet not at a constant speed.
After 4’46”, I stabilized the aircraft at about IAS 400 kts, at an altitude of 3000 ft. The purpose is showing how an immediate set of manoeuvres de facto stops or avoid the synchronization altogether. The process resumes later, when the aircraft is in a stable, unaccelerated fight.
The moment when the F-14 Tomcat was stable is very evident from the chart: whilst manoeuvring, the vC suffered all sorts of disturbances. Curiously, the spike at 53″ coincided with a hard turn. However, almost as soon as the aircraft stabilized, the computed magnetic variation started to move closer and closer to the manual value.
It is interesting to note how the ratio is very similar to the previous example, no matter the number of manoeuvres pulled before.
Eventually, however, vC stabilized at a value more distant from vM than the previous example: 2.1° higher.
Test III: Constant Climb
This test aimed to understand the behaviour of the computed magnetic variation during a climb. I repeated the test twice: first maintaining the True Air Speed / Ground Speed constant, the second maintaining the Indicated Air Speed. Both tests provided the same conclusion: the synchronization does not occur.
Both tests saw an initial shallower climb post departure, and a steeper climb (“Climb” in the Notes column). I stopped monitoring after 4 minutes.
Test IV: High Altitude
Another quick test involved checking the synchronization after a climb. After the desired altitude was reached, as long as the rest of the next few minutes of the journey were flown maintaining the Tomcat in a stable and unaccelerated flight, the synchronization proceeded without issues.
COMP Panel: the “HDG” Pushbutton
The last two tests deserve a few more words. The objective is using the HDG Pushbutton, located in the COMP panel in the front seat, which was discussed in the previous parts. One of its functions is to synchronize the directional gyro with the magnetic azimuth detector and sets magnetic heading on the BDHI.
In these tests, I used it to accelerate the synchronization. I tried both holding the button until the SYNC indicator aligned, and “tapping” it: holding it for a few seconds, and then releasing.
The HDG Pushbutton’s function is to fast-erect the AHRS. Compared to the speed at which the AHRS re-synchronises in stable flight conditions, it is night and day.
Note that I collected data for the HDG PB dataset only for the first 35″/40″. I have reported the latest vC value until the end of the chart to better appreciate the differences.
The speed at which the re-sync happens has two immediate advantages:
The procedure is much quicker, and the Tomcat can proceed as planned sooner;
The pilot has to maintain a stable, unaccelerated attitude for a much shorter period; thus making his life much simpler.
Considering the staggering difference between the two methods, using the HDG Pushbutton is definitely the recommended way to operate.
Visualizing the Desync Effect
The following screenshots are taken from Test V explained in the previous Paragraph. Note how, although the heading of the F-14 is unchanged, the heading indicated by the avionics varies dramatically.
The Altitude is maintained constant thanks to the autopilot, and it is monitored via the Info Bar.
As previously discussed, different display show information gathered from different parts of the INS. If nothing is changed by the Pilot or the RIO (i.e. the Comp-Slaved-Dg Mode Switch).
Note: in one of my tests, I used the HDG AP as well. I guessed the F-14 would have steered, following the indications of the various components of the INS.
However, it did not, at least according to the Info Bar.
Curious, isn’t it? It is something worth investigating at some point…
I put together a short video to better visualize the effects of the synchronization on the instrumentation. You can find it here:
Conclusions and Observations
To wrap this Chapter up, a few observations:
the new autopilot implementation allows a simple and immediate synchronization. Since the process is susceptible to changes in speed and altitude, this feature helps new pilots to maintain the flight parameters as stable as possible;
the synchronization does not start as soon as the aircraft leaves the deck. A period of 30″-40″ is usually need to start the process;
even after manoeuvring, if the aircraft is flown straight, levelled an unaccelerated, the synchronization kicks in automatically (sans failures);
the synch ratio, if the process is unperturbed, is about 10°;
it seems that the sooner the synchronization is started, the closer the computed magnetic variation is to the manual magnetic variation. However, a vastly higher number of tests are required to verify this observation.
What follows is the original series of tests conducted before the HDG Pushbutton bug was fixed.
I decided to keep such part, it can be useful if you are playing an older version of DCS, or until the Stable version is updated.
This part is however not present in my book any more.
Test V: HDG Pushbutton – HOLD
I moved the timescale to have 0″ when the vC starts the synchronization. A few seconds later, I pressed the HDG pushbutton and held it until the completion of the alignment. Note how, when the HDG pushbutton is depressed, vC sees a “spike”, but it soon stopped, and the synchronization resumed on its usual pace of circa 10°/minute.
The dashed line follows the trend of the spike. If the HDG pushbutton provided such a boot to the synchronization process, it would definitely be beneficial to every carrier operation.
In order to increase the accuracy of the flight parameters, I used the newly overhauled altitude autopilot. By means of this feature, all the pilot has to do is levelling off, activate the autopilot and settle the forward acceleration. As the aircraft settles, the SYNC indicator bulges, and, at the same time, the value of vC starts to increase (or decrease, depending on the situation).
Test VI: HDG Pushbutton – TOGGLE
The last test is still focused on the HDG pushbutton, but I toggled it after the vC stabilized. The button was depressed between:
00:11 – 00:19;
00:27 – 00:55;
01:03 – 01:15;
01:27 – 01:39;
01:51 – 01:52.
The resulting curve is displayed above. Most of the time the button is pressed, the synchronization accelerates, but it is followed right after by a “relaxation” of the trend.
The data points I collected and the charts you see above are stored in this Google Spreadsheet doc. You are welcome to have a look.
HDG Pushbutton: What Am I Doing Wrong?
I forwarded my observations to the devs, we exchanged a couple of messages, and I’m waiting to understand if I’m doing something wrong, a bug is present, or this is the actually expected behaviour.