MH370 Flight Path Model version 13.5d

MH370 Flight Path Model version 13.5d

by Richard Godfrey 
2015 May 28th

A previous post on May 10th made available my MH370 path model version 13.5. Since then three minor errors have been identified, and the present post rectifies those within my path model version 13.5d, which is available for download from here (2.46 MB).

My Independent Group colleagues Sid Bennett, Geoff Hyman and Barry Martin (hereafter SGB) recently published their MH370 path investigation studies showing various flight paths, with and without a lateral offset, with and without a climb and with and without cancellation of the lateral offset. In my path model V13.5d I have replicated their path labelled as D (hence the nomenclature), which includes a lateral offset and a small climb near 18:27 UTC, with a cancellation of the lateral offset near waypoint ISBIX.

This V13.5d provides for an exact fit to the BTO values and a good fit to the BFO values including those at 19:41 and 23:15. The overall RMS BFO error value is 2.49 Hz for the eight values between 19:41 and 00:19. The point reached at 00:11 in V13.5d is 36.09S 90.0E, compared to SGB’s 36.23S 89.66E for their path variant D.

In the diagram below I show the various locations indicated for 00:11 UTC, and it can be seen how close the various calculations are in terms of end locations. My colleagues’ points SGB-A through SGB-E are close to my V13.5a. My V13.5b is a little further southwest, and V13.5d a little further northeast, on the 6th (blue, here) arc which pertains to 00:11 UTC and a substantial (i.e. cruising) altitude.

RG_V13.5d

The key take-away here is the implication for the SIO search area. The area marked in yellow is around 100 km in length and 30 km in width, and has hardly been searched yet (cf. red lines showing search ship paths that have been followed so far). This yellow-shaded area lies between 36.3S and 36.9S and just inside the 7th arc at sea level. My ‘impact location’ based on V13.5d is as shown in the above map.

 

Asteroid discovery efficiencies for the Korean Microlensing Telescope Network

Asteroid discovery efficiencies for the
Korean Microlensing Telescope Network

Duncan Steel
2015 May 19

Introduction
The Korean Microlensing Telescope Network (KMTNet) is planned to include three telescopes located in the Southern Hemisphere in a project aimed at the identification of Earth-mass planets orbiting other stars through gravitational lensing effects. The telescopes are to be located in Chile, South Africa and Australia.

The telescopes will have an aperture of 1.6 metres, and a field of view (FOV) covering about four square degrees which will be imaged using a 340 megapixel CCD camera. The intent is to obtain repeated images of four adjacent fields near the Galactic Bulge, with 24-hour coverage being possible in principle from these three observatory sites. The variation in light intensity received due to transient events may then indicate the presence of extrasolar planets, as described above.

The preceding two paragraphs comprise a brief (and inadequate) summary of the aims of KMTNet. The intent here, in this paper, is simply to indicate the possible effectiveness of the KMTNet telescopes for the discovery of near-Earth asteroids (NEAs). No specific data collection is envisioned; I am just exploring how often NEAs might be detected in KMTNet imagery routinely collected for the purposes of that project, should the imagery be processed to this end in a timely manner using suitable moving-object algorithms.

Gould and Yee have pointed out that microlensing surveys such as KMTNet will render a huge volume of useful data on main-belt asteroids. It is emphasized that here I am considering only NEA discoveries and not the far larger number of discoveries (and invaluable information on spin rates etc.) of main-belt asteroids that will be spawned by KMTNet and the like.

 

Current NEA search programs
Simply as background for the interested reader, I point out that ongoing NEA search programs are listed here. A notable new project due to commence at the end of this year is ATLAS. Note that ATLAS (that’s a different link) will make use of quite small telescopes (aperture near 50 cm) but will cover large areas of the sky.

 

Asteroid discovery efficiency metric
Twenty years ago I studied the feasible NEA discovery efficiencies for telescope systems at Siding Spring Observatory (SSO), and a few other systems, plus plausible NEA discovery efficiencies should suitable CCD cameras be installed on various systems at SSO. My analysis (the paper in question is available by clicking here; 1.85 MB PDF) was based on a method developed by Al Harris.

Subsequently (and consequently) the Uppsala Southern Schmidt Telescope at SSO was modernized and equipped with a CCD system, as part of the University of Arizona Catalina Sky Survey, and proved to be a highly-effective device for the discovery of NEAs and comets. Its limited aperture (0.6 metres), however, has meant that as the majority of large NEAs (1 km and above) have been found its utility has passed.

Larger aperture systems are now required, for the discovery of smaller NEAs (see this report from 2011, and for more up-to-date information see the various papers presented at the Planetary Defense conferences held in 2013 and 2015). Deliberate, dedicated searches are under way. However, there are also other astronomical surveys being conducted which will inadvertently turn up NEAs – astrophysicists have been known to term asteroids the “vermin of the skies” – and KMTNet is an example of one of the surveys.

All I have done here is to resurrect my software from two decades ago, and input the relevant parameters for the KMTNet systems. It is emphasized that I have not updated, say, the asteroid population model that I have used, as introduced by Harris; it would be useful if someone could perform such an update, and make use of the experiences obtained in the various NEA search programs over the past twenty years.

 

KMTNet systems parameters
I am indebted to Dr Michael Albrow for information regarding the KMTNet CCD cameras. The relevant parameters for the present analysis  are as follows:
   Detector system:  2 x 2 mosaic of 9k x 9k E2V 290-99 CCDs.
   Nominal FOV: 2 degrees x 2 degrees.
   Pixel angular width: 0.39 arcseconds.
(Note that 9,000 x 0.39 arcsecond pixels indicates a FOV 1.95
degrees wide; and this is the FOV I have used.)

The other input parameters to the NEA discovery efficiency software are as below:
   CCD quantum efficiency: 0.8 (assumed value).
   Minimum signal-to-noise ratio for asteroid detection: 6 (six).
   Exposure duration: 60 seconds.
   Exposures per hour: 24 (i.e. a duty cycle of 40 per cent).
Because there are four fields (each of four square degrees) being
repeatedly imaged, each of those fields is imaged six times per
hour.

Telescope effective aperture: 1.3 metres
(The actual telescope aperture is 1.6 metres, but the central
obstructions cut down the effective collector area. I have assumed
that about two-thirds of the aperture is free of obstruction:
[1.3/1.6]² ≅ 0.66.)

 

Results
Using the above input parameters I obtained results as shown in Figures 1-3 below. It is intended that these plots should be compared with Figures 2, (3 & 5) and (4 & 6) respectively in my previous paper.

CCDKMTFig1Figure 1: The limiting (asteroid) magnitude obtainable as a function of asteroidal angular speed between 0.25 and 128 degrees per day. 

 

CCDKMTFig2Figure 2: The logarithmic relative discovery rate as a function of asteroidal angular speed . 

 

CCDKMTFig3

Figure 3: The logarithmic relative discovery rate as a function of asteroid equivalent diameter. 

Discussion
If one compares the above plots with my previous results, there are few surprises in terms of the general form of the curves. The most pertinent results to compare with are those I derived for the GEODSS cameras, actually before they were brought into use for NEA detection. For these 1-metre aperture systems, assuming 30-second exposures, I found that the discovery efficiencies indicated are about eight to ten times higher than those found here for individual KMTNet telescopes, with relative discovery curves having shapes very similar to those in Figures 2 and 3 above.

Why are the KMTNet telescopes indicated to have lower NEA discovery efficiencies? There are several contributing considerations, as follows.

  • With 60-second exposures and 0.39-arcsecond pixels, only the slowest-moving NEAs will be pseudo-stationary (in the terminology of my earlier paper); those moving at one to eight degrees per day will produce short trails in the KMTNet images, while those travelling at angular speeds of 16 deg/day will result in long-trailed images, and there is no benefit in having trailed images, as such, in terms of moving object identification.
  • By repeatedly imaging the same fields, rather than covering new areas of the sky, the KMTNet observing routine will produce multiple detections of the same NEAs rather than a large number of discoveries; this has some advantages, in that the KMTNet system in effect will be doing its own ‘follow-up’ of NEA positions within each night (and over several nights for the NEAs moving at less than 2 deg/day), resulting in astrometric arcs lasting several days for most of its NEA discoveries, and this will be highly advantageous in view of the sparsity of asteroid follow-up astrometry in the Southern Hemisphere.
  • After the original NASA Spaceguard Goal (covering 1-km NEAs) was nominally achieved, the target sizes were dropped first to 140-metres, and now lower still. Consideration of Figure 3 indicates that the KMTNet systems will provide for peak discovery efficiencies in the 50 to 300 metre size range, and it will be these-sized NEAs that are moving quickly enough to replenish the FOV of the KMTNet cameras from night-to-night.
  • Systems like ATLAS will cover smaller sizes still, but not much; KMTNet will have substantial discovery efficiencies for NEAs in the 20- to 50-metre size range (smaller asteroids, such as the Chelyabinsk object, cause relatively little damage on impact) and, since KMTNet will be operated with self-consistent observing routines and directed at only a small region of the sky, it might be anticipated that the analysis of results from KMTNet will be of especial interest in terms of developing improved understandings of the population and orbital distribution of small NEAs and therefore their impact frequency on Earth.

Acknowledgement: I thank Dr Michael Albrow for discussions and correspondence regarding KMTNet.

 

Northern Routes and the Burst Frequency Offset Values for MH370

Northern Routes and the Burst Frequency Offset Values for MH370

by Victor Iannello
2015 May 18

 

Prefatory statement by Duncan Steel: The middle of May has passed, and weather considerations mean that the search of part of the bottom of the Southern Indian Ocean (SIO) for signs of the wreckage of MH370 believed to lie there will soon need to be suspended for the austral winter. As of yet, nothing related to MH370 has been found there, nor indeed anywhere else.

With that in mind, it seems an appropriate juncture at which to step back and consider alternatives, in terms of where MH370 might have ended up, whilst maintaining the belief that the conventional interpretation of the satellite-derived data (that MH370 turned south and crashed into the SIO on fuel exhaustion) is most likely correct until proven otherwise.

The core question is this: how could MH370 have taken a different path that might also satisfy the requirements of the satellite data (the BTO and BFO values)? In a recent paper Victor Iannello investigated possible northern routes ending up at airports close to the 7th arc by excluding the BFO values from consideration and basing his analysis only on the BTO values, and the constraints imposed by the known fuel availability.  Victor has now extended that analysis, as foreshadowed in that recent paper, so as to include a possible mechanism through which the BFO values might also be satisfied.

It is not my place here to summarise Victor’s ideas and results, especially as he has done this very well himself in the paper below.

At the present time I am unsure myself what to make of this. Since getting involved in MH370 investigations 14 months ago, my own position (or belief, if you prefer) has been that it seems most likely that some terrible on-board emergency led to MH370 being turned back westwards, and that all subsequent legs of its flight were governed by the autopilot rather than direct human input. Recent papers/posts that have appeared here have made me question again whether that is indeed what happened, with evidence being brought forward indicating that around 18:22-18:40 UTC, an hour after MH370 was turned back westwards over the Malay Peninsula, there was some human activity on the flight deck. Victor’s analysis builds on that idea, suggesting other human actions that might have occurred at that time, persisting through to a possible landing close to the time of expected fuel exhaustion.

Doubtless there will be vociferous critics and trolls elsewhere who will seize upon this as ammunition to shout and scream about. This worries me not. My main qualm in posting this paper by Victor is that it will likely give false hope to those, mainly the friends and families of those who were on board MH370, who still have faith that the aircraft did not crash into the SIO. I would not wish them any ill, nor want to cause them further angst. Nevertheless my discussions with them over the past 14 months indicate that they would prefer all possibilities to be aired, and investigated. It is for this reason that Victor’s paper appears below.

——————————————————————————-

Northern Routes and the Burst Frequency Offset Values for MH370

 

Notice: The views expressed here are solely mine (VI) and do not represent the views of the Independent Group (IG), or any other group or individual. 

A PDF of this paper (467 kB) may be downloaded from here.

 

Summary
In previous work, paths were reconstructed for MH370 using the available radar and satellite data. Paths to the north of Malaysia were studied by matching the measured Burst Timing Offset (BTO) data, but relaxing the constraint of matching the Burst Frequency Offset (BFO), which is appropriate if the BFO data was either corrupted or misinterpreted. It was found that there are paths to the north that end at airports that could be reached with the fuel that was loaded onto MH370.

In the present paper, the conventional interpretation of the BFO is challenged. In particular, the possibility that the operation of the SATCOM was deliberately modified so that a northern path would have the BFO signature of a southern path is studied. Some of the findings are as follows:

  • The Honeywell Thales MCS-6000 SATCOM used by MH370 has a frequency correction algorithm with the capability to correct for the Doppler shift caused by the inclination of the satellite’s orbit. This is known to the official investigation team but is not generally known by independent researchers.
  • The value of inclination for the Inmarsat I3F1 satellite that was broadcast by the Ground Earth Station (GES) at Perth, Western Australia, to be used by SATCOMs logged into the satellite, was zero. The true inclination of the satellite was around 1.65 degrees. The two parameters that describe the satellite’s movement compared to the equatorial plane, the inclination angle and the time of the ascending node, are stored in the System Table of the SATCOM in non-volatile memory, and are used by the frequency compensation algorithm.
  • If an individual obtained unauthorized access to the non-volatile memory of the SATCOM, the value of the inclination used by the frequency correction algorithm could be changed from 0 to 3.3 degrees, or about twice the true inclination of the satellite. With this change, the BFO signature of a northern path that satisfied the BTO data (as previously discussed) would resemble the BFO signature of a southern path that satisfied the BTO data (i.e. the conventional path interpretation, ending in the southern Indian Ocean).
  • The apparent turn to the south between 18:28 and 18:40 UTC that is suggested by the measured BFO values might have been caused by a change to the inclination parameters stored in the SATCOM’s System Table during that time interval.
  • The calculated values of BFO for northern paths with the inclination parameter changed to 3.3 degrees match the measured BFO values with an RMS error less than 3.8 Hz. This is true for Mach numbers between 0.65 and 0.85 at FL350, with little variation in RMS error seen across this speed range.
  • At each log-on, the inclination parameters would be reset to zero. Therefore, the BFO data associated with the log-ons at 18:25 and 00:19 UTC should be evaluated with inclination parameters set to zero. The BFO data at times between these log-ons should be evaluated with the possibility that a change was made.
  • The BFO value at 00:19 matches an aircraft along the northern part of the 7th arc on the ground and stationary once the BFO is adjusted for the log-on offset seen at 16:00 UTC (i.e. when at its departure gate in Kuala Lumpur). This suggests that if MH370 actually flew north, it might have successfully landed.
  • Researchers have identified security vulnerabilities in other SATCOMs, including backdoors and access to memory, although the MCS-6000 has not been specifically studied. The possibility of ‘spoofing’ the BFO to disguise location has been considered before.

 

Introduction
A number of analysts have studied the Burst Timing Offset (BTO) and Burst Frequency Offset (BFO) data from flight MH370, as relayed by the Inmarsat-3F1 satellite and received by the Ground Earth Station (GES) in Perth, Western Australia. The aircraft was a Boeing B777-200ER registered as 9M-MRO. The satellite data are indicative of the aircraft flying to the South Indian Ocean (SIO) and exhausting its fuel. The constraint of matching the BFO data within any reasonable limit on error eliminates the possibility of a northern path. Performance constraints such as fuel consumption and unattended (autopilot) navigation also limit the range of possible end points for southern paths.

More recently, I have reconstructed paths to the north that are allowed by the BTO data if one ignores the BFO data. That study was performed to assess the possibility of a successful landing in the event that the BFO data from MH370 is either corrupted or has been misinterpreted. I used the BTO data to identify the paths to the north that end at airports along the 7th arc at 00:19 UTC with the requirement that the BTO data is matched at all other handshake times. Three airports were identified that are located within the uncertainty bounds of the 7th arc. Of the three, there appears have been insufficient fuel to reach Kyzylorda Airport. On the other hand, there appears have been sufficient fuel to reach Almaty and Kuqa Qiuci Airports, although there would have been significantly less fuel margin to reach Kuqa Qiuci. Near to Almaty is a smaller airport named Boraldai that is also viable for landing. It is very unlikely that MH370 reached the runway at Yubileyniy, which was suggested in a scenario by Jeff Wise.

In the current study I investigate the possible corruption of the BFO data. In particular, I have researched a technical scenario in which the operation of the SATCOM was deliberately modified so that a path to the north would have the BFO signature of a path to the south. The technical feasibility of malicious intrusion into the SATCOM is also discussed.

 

BTO and BFO Calculations
The methodology to reconstruct northern paths is described in my previous work, and is similar to what has been presented by others, including the published work of Inmarsat’s Chris Ashton and others and the IG’s Richard Godfrey . A BTO value defines an arc on the surface of the Earth, and paths can be reconstructed that cross these arcs at the appropriate time by matching the satellite-aircraft range. (The exact position of the arc depends on the altitude of the aircraft; at higher altitudes, the arc is located further from the sub-satellite position.) The paths were reconstructed by forward-integrating in time and exactly matching the satellite-aircraft range at handshake times as derived from the BTO values and the satellite position. Paths for which the Mach number was held constant were studied. The model includes an accurate parameterization of the satellite position and velocity, meteorological data, and the WGS84 model of the Earth’s ellipsoid geometry.

The explanation of the BFO data is more complicated. Each measured value represents the sum of six terms, as described by the following equation (1):

VI2eqn1

where the SATCOM on the airplane is referred to as an Aircraft Earth Station (AES), the corresponding Ground Earth Station (GES) is located in Perth, and

  • Δfup is the uplink Doppler shift due to relative motion between the aircraft and the satellite
  • ΔfAES is the frequency correction applied by the AES to compensate for Δfup 
  • Δfdown is the downlink Doppler shift due to the relative motion between the satellite and the GES
  • ΔfAFC is the correction applied by the Enhanced Automatic Frequency Compensation (EAFC) at the GES to compensate for Δfdown  
  • Δfsat is the frequency offset of the satellite due to thermal effects
  • B is the fixed frequency bias

In accordance with the analysis by Chris Ashton and others, a bias value of B = 150 Hz is used, which is a calibrated value based on the measured BFO when 9M-MRO was parked at Kuala Lumpur International Airport (KLIA). Geoff Hyman and Barry Martin have shown that the bias B shows a statistical correlation with the particular GES channel used for the AES-GES communications, with a value of 150 Hz for channels R4 and R11 and 154 Hz for channels T10, T12, R8, and T8. In fact, the handshakes at 19:41, 20:41, 21:41, 22:41, and 00:11 UTC all were on channel R4, so the use of a constant value B = 150 Hz is justified for the work here. (The satellite calls at 18:40 and 23:14 UTC produced BFO values using channel C6; unfortunately, there is no calibration data available for this channel to determine if a different bias is warranted.)

Of the six terms in equation (1), four (Δfdown, ΔfAFC , Δfsat, and B) are independent of the specific path of the aircraft and can be calculated based on the satellite position and velocity vectors, the location of the GES in Perth, and the measured performance of the EAFC at Perth. That leaves two other parameters, Δfup and ΔfAES, that are dependent on the particular path that MH370 followed.

By ICAO specification, an AES is required to compensate for the uplink Doppler shift, Δfup, by applying a frequency correction ΔfAES that modifies the transmitted frequency so that the residual offset L is less than 100 Hz, where the residual is given by equation (2):

VI2eqn2

The uplink Doppler shift Δfup is dependent on the following:

  • The position and velocity of the satellite;
  • The position, ground speed, track, and vertical speed of the aircraft; and
  • The frequency of the uplink signal, which is in the L-band, and equal to 1.6466525 GHz

One way to compensate for the uplink Doppler shift is for the AES to calculate what it expects the uplink Doppler shift to be, and then apply a correction to the transmitted frequency which ‘pre-compensates’ for this expected shift.  If this correction algorithm were to use the exact position and velocity of the satellite, as well as the exact position, ground speed, track, and vertical speed of the aircraft, then the residual offset L would be close to zero, and the BFO could not be used to discriminate between different paths followed by the aircraft.

The SATCOM in 9M-MRO was a Honeywell Thales MCS-6000. In this SATCOM terminal, the AES correction algorithm uses a simplification of the full model that would be required to compensate exactly for the uplink Doppler shift, and the result is a non-zero residual offset. As described by Chris Ashton and others, the AES correction algorithm makes the following simplifications:

  • The satellite is assumed to be geostationary: that is, not to be moving relative to the Earth, with the velocity vector being zero, the altitude above the Earth constant at 35,786 km, and the sub-satellite position remaining at a constant longitude above the equator;
  • The vertical speed of the aircraft is assumed to be zero.

In fact, we know that Inmarsat’s I3F1 satellite is not truly geostationary. The satellite’s orbit is indeed geosynchronous (i.e., one orbit about the Earth lasts one sidereal day, or 23.9345 hours), but the satellite orbit is tilted relative to the equator (i.e. it has a finite inclination) and the orbit is also slightly non-circular (i.e. the orbital eccentricity is non-zero). In consequence the satellite is not stationary relative to the Earth: it moves both in terms of latitude (or declination) and longitude, and also in terms of altitude, these varying sinusoidally with a period of one sidereal day. This movement means that the AES correction algorithm is imprecise.

As a consequence of the inexact cancellation of the uplink Doppler due to the orbit simplification in the AES correction algorithm, the residual L varies according to the path of the aircraft (cf. equation 2). It is this variation that allowed investigators in the days after the disappearance to conclude that MH370 followed a southern rather than a northern path.

To show how the BFO can be used to discriminate between paths to the north and south, I reconstructed two representative paths in this way:

  • For both northern and southern paths, there was an assumed turn at 18:34 UTC.
  • After 18:34, the speed was held constant at M = 0.8 at an altitude of 35,000 ft (FL350).
  • Meteorological data was incorporated so that the effects of wind and temperature aloft were included.
  • The BTO was matched exactly at each handshake by allowing turns at each handshake, and great circle routes were flown between handshakes.
  • At 00:11 UTC, the speed was reduced so that the plane reached the 7th arc at 00:19 at sea level.
  • A bias of B = 167 Hz was used to calculate the BFO at the log-on at 00:19 UTC on channel R10 since that this bias was observed for the log-on at 16:00 UTC, also on channel R10.
  • For the southern path, a steep descent was introduced to match the measured BFO at 00:19. For the northern path, the plane was assumed to be on the ground and stationary.

Figure 1 shows how the BFO varies for the representative northern and southern paths. As can be seen in the figure, the calculated BFO curve for the southern path agrees with the measured BFO values, and the calculated BFO curve for the northern path does not agree with the measured values. Analyses similar to this are what led the official investigative team to conclude that the plane followed a course to the south. The conclusion is independent of the details of the modeled paths, i.e., whether or not MH370 followed a constant track after the turn, the exact airspeed, the time of the turn, etc. These details have been the subject of vigorous debate, and affect the final location of MH370 if it turned to the south. However, for the work presented here, these details are not important.

VI2Fig1

Figure 1. BFO for representative paths to the north and south.

 

Ways to Alter the Measured Values of the BFO 
I was interested in exploring ways that the input values to the AES correction algorithm might have been altered such that the modified frequency correction ΔfAES might have caused the BFO values for a northern path to look like a southern path. A constraint is that by changing the input parameter, the steering of the high gain antenna (HGA) should not be affected since we know from the class of service that the HGA was in use. With that in mind, I evaluated two schemes for altering the input parameters to the AES correction algorithm:

  • Intercepting and replacing navigational parameters sent to the SATCOM over the ARINC 429 bus, as proposed in Jeff Wise’s scenario
  • Altering values stored in the SATCOM’s memory related to the satellite orbit.

If one or more navigational parameters were intercepted and replaced, it would require a processor to be placed inline before the ARINC 429 bus input to the SATCOM. This processor would take the actual value of position, speed, and track and replace one or more values such that it would cause the SATCOM to apply a frequency correction ΔfAES in a way that the residual Doppler shift L is consistent with a southern path, even though the actual uplink Doppler shift Δfup and the frequency correction ΔfAES are individually different for southern and northern paths. (Only the residual L can be derived from the measured BFO if there is no knowledge of the path or the frequency correction.)

Because of the constraint of continuous antenna steering, it would be difficult to change the position or track fed to the SATCOM without the satellite falling outside of the main lobe of the HGA’s antenna pattern. The variable parameter that is left is the ground speed. In fact, I have found that by changing the ground speed used in the AES correction algorithm, the BFO can be varied, and so a northern path could be disguised as a southern path. However, this scheme suffers from two shortcomings:

  • The sensitivity of the BFO to speed is low at 19:41 UTC, requiring that the actual speed of the aircraft be replaced with one unrealistically high. (This is because the plane was flying tangentially to the ping arc around this time and the satellite was at its point of highest declination; i.e. furthest north of the equatorial plane.)
  • The complexity involved in designing the hardware and the software, and getting it on the plane, and installing it in-flight, is high.

I next considered the possibility that one or more of the values related to the satellite’s orbit stored in the SATCOM’s memory were altered. This scenario is inherently simpler than the previous one because values do not need to be continuously changed based on the aircraft’s position and speed and so there would be no need for an inline processor. However, there would have to be a method for accessing the SATCOM’s memory and altering one or more stored values.

If the model used to describe the satellite’s orbit was the geostationary representation described by Chris Ashton and others, there is only one parameter needed to specify the position of the satellite: its longitude, which is 64.5 degrees for I3F1. However, the constraint that steering of the HGA remains operational severely limits the possible range for the modified value of the longitude. Independent of this constraint, I could not find a modified value of longitude that would produce a BFO signature for a northern path that is consistent with the measured values.

 

Near-Geostationary Model for the Satellite in the AES Correction Algorithm
It occurred to me that, independent of what was presented by Chris Ashton and others, the AES correction algorithm might use a more accurate model for the satellite orbit than the geostationary representation we have assumed.  I considered a model that is incrementally higher in complexity, corresponding to a satellite with an orbit that is circular (zero eccentricity), but with a finite inclination. We know that the actual inclination of I3F1 was about 1.65 degrees at the time of the flight of MH370, and this finite inclination produces the discrimination in BFO between northern and southern paths. A satellite with a small value of inclination is sometimes referred to as ‘near-geostationary’. I was very interested to see what effect a change in the inclination parameter would have on the predicted BFO values.

A satellite orbit that is near-geostationary can be described by three parameters: longitude, inclination angle, and time of the ascending node, which is the time of (sidereal) day that the satellite passes over the equator moving from south to north. With the observation that antenna steering was not disturbed, I held the longitude of the orbit constant and studied what would occur if the AES correction algorithm had the capability to model the effect of the inclination based on the two relevant parameters (inclination angle and ascending node) were changed. In particular, I studied whether there were parameter sets that would cause the BFO values for northern paths to look like southern paths.

The results are shown in Figure 2 for northern paths having speeds between M = 0.65 and M = 0.85. For all speeds, the modified value for the inclination angle parameter used in the AES correction algorithm was set to 3.3 degrees, or about twice the true inclination of 1.65 degrees, and the time of the ascension node was set to 14:12 UTC. These modified values were used for the BFO calculations between 18:40 and 00:11 UTC, inclusive. For the log-on at 00:19, the value of inclination angle was again set to zero. The reason for this reset to zero is described in the next section.

VI2Fig2

Figure 2. BFO for northern paths with altered inclination correction in the AES algorithm. 

The RMS error in BFO for any of the northern paths studied is less than 3.8 Hz. The error in the calculated BFO at 00:19, which is based on the assumption that MH370 was on the ground and stationary, is about 5 Hz. This lends support to the hypothesis that MH370 successfully landed.

In order to investigate further whether a modification of the AES frequency correction was a mechanism used to disguise a path to the north, I had to discover whether a near-geostationary model for the satellite was indeed implemented in the AES correction algorithm. If it was not implemented, a much more elaborate hack involving reloading new firmware into the SATCOM would be required to disguise the northern path. A modification of input parameters to the AES correction algorithm is much simpler than a modification of the algorithm itself.

 

Confirmation of the Near-Geostationary Model in the AES Correction Algorithm
Readers might recall that ICAO requires that the residual frequency offset L (which is referred to as the AES AFC error in the ICAO specification) is limited to +/- 100 Hz. For a satellite that is following a near-geostationary orbit, its speed (relative to a true geostationary orbit) will be at a maximum value at the time of the ascending node, and the speed will be proportional to the inclination of the orbit (assuming the eccentricity is small enough to have negligible effect). Therefore, if the AES correction does not account for satellite inclination, the offset L grows with inclination. Normally, a satellite’s inclination is kept small by applying orbit maneuvers for ‘station-keeping’. However, there is a finite amount of thrust propellant onboard a satellite that is available for station-keeping. As a result, as a satellite nears the end of its life and the supply of propellant is depleted, the satellite’s inclination is allowed to grow. Such is the case for I3F1 which at the time of the disappearance of MH370 had an inclination of about 1.65 degrees.

For satellite I3F3, which is a sister satellite to I3F1, I was able to find the Technical Description for the application for its Federal Communications Commission (FCC) license. As part of that application, it specifies that the satellite will be operated with an inclination of less than 2.7 degrees. The problem is that if the satellite’s inclination does grow with time to the maximum allowed value of 2.7 degrees and the AES correction algorithm does not compensate for satellite inclination, then the residual offset L just due to the inclination could be greater than the allowable limit of 100 Hz, depending on the position of the aircraft relative to the satellite. Since it is unlikely that Honeywell would produce a SATCOM that does not meet the ICAO specification, I reasoned that the actual model implemented in the AES correction algorithm probably did allow for a near-geostationary satellite orbit, i.e., it compensates for the effect of inclination of the satellite’s orbit.

Based on these suspicions, I queried a knowledgeable individual who is close to the investigation. My suspicions were confirmed; I received a statement that Honeywell’s MCS-6000 SATCOM “does indeed have a capability to correct its Doppler for satellite inclination: this is controlled by a table broadcast to all terminals, and this table was broadcast in no inclination for the 3F1 satellite at the time of the incident. Hence AES was not compensating for satellite Doppler.

So there was the confirmation that the capability existed for the SATCOM of MH370 to compensate for inclination, but there was also the belief by some close to the official investigation that this capability was not used, and certainly not used with modified inclination parameters as I proposed.

Each AES maintains a System Table stored in non-volatile memory in the Satellite Data Unit (SDU). The System Table contains the data required for an AES to interface with the Inmarsat network, including channel frequencies, channel data rates, satellite locations, and the GESs associated with each satellite. As part of the log-on process, an AES updates its System Table based on the values that are broadcast by the GES. The inclination and time of ascending node are broadcast as part of the System Table. But since the broadcast value was zero, there is the belief that no compensation in frequency was made for the satellite inclination.

It occurred to me that since the values of the System Table are overwritten each time the SATCOM logs on, if a deliberate change was made to the inclination parameters, then that change would have occurred after the log-on that was initiated at 18:25 UTC. In fact, the apparent turn to the south is predicted to have occurred between 18:28 and 18:40 UTC, as suggested by the BFO. What has been interpreted as a turn to the south could actually have been an indication that the inclination parameters were deliberately altered. If so, the AES was applying a frequency correction, but the correction was based on value of inclination that was about twice the actual inclination in order to disguise the northern route. At the log-on at 00:19, the inclination parameters stored in the System Table of the SDU would again be overwritten to zero. Hence, the BFO value at 00:19 should be interpreted assuming the inclination parameters were zero, as was presented in the previous section of this paper.

 

How the Inclination Parameters Might Have Been Altered
If the inclination parameters were altered in the SATCOM, it is hard to imagine a scenario in which that modification was not deliberate. More specifically, it would indicate there was unauthorized access to the non-volatile memory of the SDU.

Ruben Santamarta, a security consultant associated with IOActive, has studied the potential for the malicious attack of SATCOMs. In a landmark white paper entitled A Wakeup Call for SATCOM Security, he studied the vulnerabilities of SATCOM systems offered across many sectors, including maritime, land communications, industrial control, civil aviation, and military, and presented his results at the Black Hat USA 2014 conference. His method of study was to obtain the firmware for the SDU and then reverse engineer (disassemble) the code using an Interactive Disassembler (IDA). Santamarta found that every SATCOM he studied had vulnerabilities that could be exploited by hackers.

To be clear, Santamarta did not study the Honeywell Thales MCS series of SATCOMs, although the Cobham Aviator 700, which offers Classic Aero service like the MCS-6000 on MH370, was part of the study. For the Aviator 700, he found backdoors, a weak password reset, insecure protocols, and hardcoded credentials. He discovered a backdoor that could be entered through the Multi-Controller Display Unit (MCDU) in the cockpit that would allow parameters to be changed and the SDU to be rebooted. I suggest that a similar method might have been used to alter the inclination parameters stored in the non-volatile memory in the SDU of MH370.

The prospect of BFO spoofing was considered by Gerry Soejatman, an aviation expert in Jakarta, Indonesia. I collaborated with Gerry in analyzing the data from the Indonesia AirAsia QZ8501 incident, and I found him to be knowledgeable and honest. On his blog, Gerry writes:

In 2011, I led the Aerospace and Defence Solutions department at one of the local Inmarsat resellers here in Indonesia. I told him [Jeff Wise] that back then I have heard rumours of 2 Indonesian guys who have managed to remote spoof the Doppler while they worked for Inmarsat during integrity testings of the Inmarsat 3 system. And then in several defence related meetings in 2011, I was also told that the other guys who can spoof the Doppler (remote or through the satcom terminal) are Israelis (using Russian immigrant engineers), the Chinese (using the Israeli expertise) and the Russians too, but obviously my sources didn’t want to go into details. The other interesting thing is that the Israelis do have their own set of satcom engineers dealing with “new innovations” for Inmarsat satcom, through one of the Inmarsat Distribution Partners, so, nothing surprising there if anyone can spoof the BFO… all you need to do is spoof the Doppler.

In this blog post, Gerry described the technical details of a scenario similar to that of Jeff Wise, in which the inertial data fed to the SDU is replaced by an inline processor feeding altered inertial data, except in his scenario, the tampering was performed by access to the SATCOM in the cabin instead of in the Electronics/Equipment (E/E) bay as was suggested by Wise. For reasons I outlined above, I don’t think this is as likely as changing the value of the inclination parameters stored in the SDU. However, the fact that others had considered ways to spoof the BFO is very relevant.

 

Conclusion
This paper follows the previous work in which possible northern paths for MH370 was studied by constraining the paths based on the BTO data and the available fuel. The present paper extends the analysis by offering an explanation of how the airplane might have flown north and yet exhibit the BFO signature of a southern path in order to disguise the true path taken. To do this, parameters related to the description of the satellite’s orbit and stored in the memory of the SATCOM would need to be changed via a backdoor or some other means of unauthorized access to the SATCOM’s memory. Other SATCOMs have been shown to possess vulnerabilities of this kind, and spoofing of the BFO may have been considered before the MH370 incident. This work challenges the conventional belief that MH370 flew south to the SIO.

 

Space Scientist, Author & Broadcaster