Guest Post: Northern Routes for MH370 Ending at Airports

by Victor Iannello

[Notice: The views expressed here are solely mine and do not represent the views of the Independent Group, Jeff Wise, or any other group or individual.]

Summary

Paths were reconstructed for MH370 using the available radar and satellite data. Paths to the north of Malaysia were studied by relaxing the constraint of matching the Burst Frequency Offset (BFO), which is appropriate if the BFO data was either corrupted or misinterpreted. The choice of paths was constrained by matching the Burst Timing Offset (BTO) data. Three airports were identified that are located near the 7th arc, as defined by the last BTO data point at 00:19 UTC: Kyzlorda, Almaty, and Kuqa Qiuci. The viability of each airport was determined based on fuel requirements. A fuel flow model was developed by reverse engineering performance data at Long Range Cruise (LRC) and Holding speeds, and then extrapolating the data to other speeds and temperatures.

The fuel flow model coupled with the path reconstruction model predicts that a flight ending at Kyzylorda is unlikely due to the high speeds and unfavorable headwinds. A flight ending at Almaty was deemed viable even when considering the uncertainty in the fuel consumption model. Alternatively, Boraldai Airport, which is close to Almaty Airport, is also viable. Finally, a flight ending at Kuqa Qiuci is considered possible, although the fuel margin is small. The paths to the airports are shown in Figure 1.

The possibility that the plane reached a runway at Yubileyniy was also considered. As Yubileyniy is 237 km (128 nm) beyond Kyzylorda, a landing there is predicted to be very unlikely.

Introduction

A number of analysts have studied the Burst Timing Offset (BTO) and Burst Frequency Offset (BFO) data from flight MH370, as relayed by Inmarsat I3F1 satellite and received by the Ground Earth Station (GES) in Perth, Australia. The aircraft was a Boeing B777-200ER registered as 9M-MRO. The satellite data suggests that the aircraft flew to the South Indian Ocean (SIO) and exhausted 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. Indeed, in the past, I have proposed two endpoints ending in the SIO. In one scenario, I assumed the flight path was uninterrupted and straight after 18:34 UTC and the aircraft was flying at air speeds close to the Long Range Cruise (LRC) condition. As one of the contributors to the Independent Group (IG) study, I predicted an end point of 37.24S, 89.56E, which is close to the prediction of other researchers such as the IG’s Richard Godfrey. In another scenario proposed in July 2014, I studied the possibility that the plane “loitered” when it was in the vicinity of the Aceh province of Sumatra, and I showed that the data allows a possible landing and takeoff at Banda Aceh Airport. For this scenario, the predicted end point in the SIO is 34.24S, 93.78E.

Since the time of these predictions, the ATSB has led an extensive underwater search using advanced deep sea techniques to first conduct a bathymetric survey of a priority zone of 200,000 km2, which was then followed by a multi-beam sonar search of this same area. To date, there has been no physical evidence of MH370 discovered even though the vicinity of the end points suggested by me and others has been searched. Additionally, no evidence has been recovered on the sea surface or washed up on shore.

There remains the possibility that MH370 did indeed fly to the SIO and due to the enormity of the range of possible end points, the wreckage of the plane has not yet been found. I do not discount this possibility, and I still have hope that the search in the SIO will be successful. However, with the lack of success to date, I believe it is important to study other possible scenarios, especially since an investigation of some of these scenarios could be conducted for a fraction of the time and cost of the underwater search in the SIO.

 

Fig1
Figure 1. Flight paths to northern airports. (Click on image for improved resolution)

 

If we allow for the possibility that the BFO data is wrong, either because it has been corrupted or because we are improperly interpreting it, then it is possible to reconstruct paths to the north that match the BTO data. In general, if we assume a particular flight speed, then for each assumed flight speed, there are a pair of paths that can be reconstructed that match the BTO data. One of these paths is towards to the north and the other is towards the south. Here I am considering only the northern paths. As no wreckage from the plane has been found in countries situated to the north of Malaysia, I am particularly interested in assessing the possibility that MH370 followed a northern path and successfully landed at an airport.

In related work, I have studied how the BFO data that would be produced if MH370 had followed a northern path may imitate the BFO signature of a southern path. I have already hinted how this may have occurred. A more detailed explanation will be presented soon.

Figure 2. Airports close to the 7th arc.
Figure 2. Airports close to the 7th arc.
 Path Reconstruction Techniques

The methodology to reconstruct northern paths is similar to what has been presented by others, including the published work of Inmarsat’s Chris Ashton and the IG’s Richard Godfrey. I assume first that the primary radar data as presented in the Australian Transportation and Safety Bureau (ATSB) report is correct, and from that, the final radar position is pegged at 6.5485N, 96.3472E at a time of 18:22:17 UTC. After that time, I assume the plane continues on airway N571 on a track of 296T deg and at a ground speed of about 495 kn until it changes course at 18:34 UTC.

There are measured values of BTO at the time of each handshake between the satellite and aircraft, and these values are used to determine the range between the satellite and the aircraft. The locus of points corresponding to a particular value of BTO form 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 subsatellite position.) The satellite position is modeled using the PAR5  parameterization of Henrik Rydberg, which agrees well with the position and velocity vectors presented by Ashton. The earth is modeled as an oblate spheroid using WGS84.

I included meteorological data in the analysis in order to properly model the effect of temperature and wind on ground speed and fuel consumption. As some of the paths studied have considerable headwinds at the cruise altitude, wind is an important effect. The meteorological data for March 8, 2014 at 00:00 UTC was extracted from the GDAS database by Barry Martin. Data is available for atmospheric levels of 250 hPa and 350 hPa, corresponding to pressure altitudes of about 34,000 ft and 26,700 ft, respectively. The data has a spatial resolution of 1 deg in latitude and longitude.

I assume that MH370 changed its trajectory at 18:34 UTC by introducing a step change in Mach number and altitude, and I assume the plane continues at this Mach number until 00:11 UTC. Between 00:11 and 00:19, the Mach number is reduced in order to reach the last arc at 00:19 at the appropriate time. Turns are allowed only at the time of a handshake, i.e., as the plane crosses an arc, and great circle (geodesic) paths are followed between handshakes. Although it would be unlikely that MH370 turned exactly at the times of handshakes, this simplification was used in light of the limited data set that is available. With this simplification, for a given Mach number, there is a unique northern path that exactly matches the BTO data.

The paths were reconstructed by forward integrating using Euler’s method with a time step of 1 minute. During each time step, the ground speed and track angle were held constant. A finer time step of 1 second was used for the time period between 18:22 and 18:28 to find a path that matches the BTO, BFO, and radar data in this interval. The path involves a “lateral offset” maneuver to the right of airway N571 that would require active intervention of the pilot. I won’t discuss more about this here as the details don’t change the general observations regarding northern paths.

End Points Near Airports

The first step was to determine which airports are close to the 7th arc and therefore would merit closer examination as a potential landing site for MH370. A series of paths were reconstructed for constant Mach numbers between 0.6 and 0.89, corresponding to a realistic range of air speeds at an altitude of 35,000 ft. The end points for these paths were then plotted using SkyVector and airports within 10 km (5.4 nm) where identified.

The results are shown in Figure 2. There are three airports that met these criteria: Kyzylorda (M=0.863) and Almaty (M=0.734) in Kazakhstan, and Kuqa Qiuci (M=0.664) in Xinjiang, China, and all have runway lengths greater than 8,000 ft. The next step was to determine the feasibility of MH370 landing at one of these airports by analyzing the fuel requirements.

Figure 3. Predicted and tabular values of fuel flow at selected conditions.
Figure 3. Predicted and tabular values of fuel flow at selected conditions.
Fuel Flow Model

The calculation of the fuel consumed between 18:24 and 00:19 requires detailed knowledge of the performance of 9M-MRO, which is a B777-200ER equipped with two Trent 892 engines. In general, for level flight, the fuel rate is a function of the aircraft weight, Mach number, altitude, and outside air temperature (OAT). As the Mach number is defined relative to the wind, the calculation of the ground speed also needs to include the effect of winds, i.e., tailwinds increase the ground speed and headwinds and crosswinds reduce it. (The reduction in ground speed due to a headwind is much more significant than a crosswind of the same speed, although both effects were included.)  As high altitude winds are very strong for the northern paths studied, this is an important effect.

To model the fuel consumed along the northern paths, I needed to model the fuel flow as a function of the weight, altitude, Mach number, and air temperature. The detailed performance specifications of a Boeing aircraft are contained in the Performance Engineer’s Manual (PEM), but this was not available. If the PEM had been available for 9M-MRO, I could have calculated the fuel consumption from “first principles”. Instead, a fuel consumption model was developed based on two tables from a portion of the Quick Reference Handbook (QRH) that was supplied to me on a confidential basis. For this work, the two important tables from the QRH are:

  • Long Range Cruise (LRC). An aircraft following an LRC speed profile will be flying at a speed 2%-4% higher than Maximum Range Cruise (MRC) with a penalty of 1% on range, i.e., fuel efficiency. In the LRC table, fuel flow and air speed (Mach number) are provided as a function of weight and altitude.
  • Holding (flaps up). An aircraft flying at Holding speed will be maximizing its endurance by minimizing the fuel flow. As is the case for the LRC table, the fuel flow and air speed are provided as a function of weight and altitude. The Holding speed is in general significantly less than the LRC speed, and the fuel flow is at its minimum for a given weight and altitude.

In general, an aircraft will not be flying in accordance with either of these criteria, so instead I used the data in these tables to develop a generalized fuel model that could be extrapolated to other conditions.

There was one other important assumption regarding the performance of the engine that was required: the ratio of fuel flow to thrust is approximately constant when corrected for air temperature. The relationship can be expressed as:

Eq1

where FF is the fuel flow in units of (lbm/hr), TSFC* is the corrected thrust specific fuel consumption (assumed to be constant) in units of (lbm/hr-lbf), D is the drag in units of (lbf), which is assumed to be equal to the engine thrust, Ts is the static temperature in units of (K), Tref = 288 K, and M is the Mach number.

In order to calculate the fuel flow, it is necessary to calculate the drag for a given set of conditions. Typically, the relationship between the lift coefficient Cl and drag coefficient Cd is presented as a “drag-polar plot” in the PEM. Lacking the PEM, I reverse-engineered this relationship using Eq 1 with the assumption that to first-order, Cd is only a function of Cl and M (neglecting the effect of Reynolds number), i.e.,

Eq2

I then found an empirical relationship for Cd that produced an adequate match between the predicted fuel flow and the fuel flow values in the tables from the QRH.

Figure 3 shows the relationship between the predicted fuel flows and the values listed in the table for LRC and Holding conditions at FL350 and FL250. The RMS error is 3.2%. Another factor is the Performance Degradation Allowance (PDA) of the engine, which might increase fuel consumption by another 2%. Including uncertainty due to PDA, the model predictions are assumed to have error bounds of -3.8% / +3.2%

Fuel Consumption for Paths to Airports

Armed with a model for fuel consumption, I studied whether the model would predict whether there was adequate fuel to reach the three airports previously identified as possible landing sites for MH370. For Kyzylorda and Almaty, I assumed the flight between 18:34 and 00:19 was at 35,000 ft. For Kuqa Qiuci, I assumed the flight was at 25,000 ft as the Mach number at 35,000 ft (0.664) was below the speed for Holding and the resulting fuel consumption was high. The results are listed in the following table.

Table 1. Fuel Consumption Results

Table1sm

For the path to Kyzylorda at 35,000 ft, the required speed is M=0.864 and the average headwind was 23 kn at FL350 with a peak headwind of 43 kn. The fuel flow model predicts that an additional 7,503 kg of fuel would be required, or about 15.3% of the initial fuel load of 49,100 kg. This is well beyond the expected error margin of the fuel model prediction. It is therefore considered unlikely that there was sufficient fuel to reach Kyzylorda Airport.

Jeff Wise has proposed a scenario in which MH370 passed Kyzylorda and landed on a runway at Yubileyniy, which is 237 km (128 nm) beyond Kyzylorda Airport. I don’t see a way that this could have occurred unless the fuel load at takeoff was significantly different than contained in the ACARS data stream.

For the path to Almaty Airport at 35,000 ft, the required speed is M=0.735 and the average headwind is 10 kn, with a peak of 23 kn. The predicted fuel remaining at Almaty would be about 3,837 kg, or about 7.8% of the initial fuel load. Even with the uncertainties (-3.8%/+3.2%) of the fuel flow model, I predict there was sufficient fuel to reach Almaty.

For the path to Kuqa Qiuci Airport at 25,000 ft, the required speed is M=0.636 and the average headwind is 4 kn with a peak of 16 kn. The predicted fuel remaining at Kuqa Qiuci is 2,004 kg, or about 4.1% of the initial fuel load. Considering the uncertainties of the fuel flow model (-3.8%/+3.2%), it is possible that MH370 was able to reach this airport, although the fuel margin is significantly less than for Almaty.

Some Additional Comments

The three flights studied all cross into the Xinjiang province of China. The path to Kyzylorda skirts the border of China, but the paths to Almaty and Kuqa Qiuci represent significant incursions into Chinese airspace. Any theory developed around these flight paths would need to explain why China did not act to stop this incursion.

In addition to the civil runway at Almaty Airport, there is Boraldai Airport (UAAR), formerly Burundai Airport, located about 11 km (6 nm) to the west from Almaty, as shown in Figure 4. It is privately-owned by Altair Air and is the base of operations for Burundaiavia, which supplies helicopter services for civilian, transport, and military uses. The airport is primarily used for light fixed-wing aircraft and helicopters and has a runway with a length of 4,790 ft. Although this is relatively short for a B777, it is would be sufficient length to land a B777 that had little remaining fuel. A landing at this airport might raise less suspicion than at Almaty.

Fig4
Figure 4. Boraldai Airport is close to Almaty Airport.
Conclusion

In this work, I studied potential flight paths of MH370 that terminate to the north of Malaysia. The studied 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 error 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.

Click here to download this paper as a pdf (which includes all of the links I’ve left out of this version).

130 thoughts on “Guest Post: Northern Routes for MH370 Ending at Airports”

  1. Victor,

    Re: “I believe it is important to keep an open mind and not steadfastly cling to one scenario to the exclusion of others. ”

    Exactly. But Jeff was expelled from IG, while you have to add notes – the price for keeping mind open.

    Doesn’t your “Perhaps at this time it is not even the most likely” conflict with the formal statement of IG?

    “Do you deny me the right to explore more than one scenario in parallel?”

    Of course I do not. IG does. But this is an internal issue between you and IG, so I prefer not to discuss it.

    Re “Nobody that I know of in the IG is reluctant to comment on their point of view.”
    I am not talking about reluctance of commenting on their points of view. I am talking about discussing the things that do not fit IG’s scenario.

  2. @VictorI : My previous reply seemed to disappear for some reason into the ether, so I’ll try again.

    I was interested in whether you or the IG were aware or had evaluated research published by Stewart Yeh, in which he had put forward the assertion that the interpretation of BTO data by Inmarsat is incorrect. Specifically, that signal attenuation can increase closer to the satellite and result in dropped network packets that in turn will cause a reduction in transmission rate by the equipment, and finally increase in BTO latency.

    The upshot of this would be the direction of flight could have been completely different than has been assumed up until now. Could there be anything to this?

  3. @Oleksandr: I won’t comment on Jeff’s situation because he can speak for himself if he chooses to do so. For me, adding a disclaimer to avoid confusion is not a “price” I pay. The statement that the IG denies me the right to explore more than one scenario in parallel is patently false. And unless you know about a situation that I do not, there is currently no “internal issue” between me and the IG. If one develops, so be it; it will be resolved in way or another. We are all adults and we all make choices.

    Let’s not create drama where there is none.

  4. Victor,

    I am happy that you do not experience any pressure for a number of your statements, which obviously conflict with the formal IG conclusions/recommendations. Moreover, I honor your fearlessness to speak out ideas, which conflict with the overall IG’s narrative. And finally, I still hope to receive your comments on a few technical issues…

    P.S. What drama are you talking about?

  5. @Oleksandr: If you wish technical comments, please feel free to send them to me. I will answer to the best of my abilities and available time. Jeff can provide you with my email address.

  6. @ostrich: Previously on this blog I supplied some comments. If you read the paper that Prof Yeh cites, the latency refers to internet latency, not SDU packet timing in a time-multiplexed stream. The comparison is so ridiculous that I am not sure the paper was written in a serious light.

  7. I am with Victor re drama.

    I have little issue with him placing the disclaimer. And I think we need to distinguiish between an opinion about the validity or not of underlying assumtions and the scientific modeling work based on the same set of assumptions.

    I think its perfectly alright to say, “assuming all publicly available data is valid then my model is A”. I further think that continuously questioning one’s assumption, one or more at a time and from time to time is a prudent thing to do. And then to explore a few “what-if” scenarios. I.e., what if data sub-set x is wrong? Now explore “assuming all data minus x is valid, my model is B”.

    All that is not about opinion, but about due diligence.

    That distinction can easily be lost on readers and the contents of a what-if scenario be mis-interpreted as the opinion of the scenario’s author.

    I see Victor’s disclaimers in the light of trying to pre-empt such mis-interpretations.

    So lets back off a little and give him a rest.

    Cheers
    Will

  8. Victor,

    Re your plot:

    dropbox.com/s/0d8hdi9t2cz92qd/Near%20Miss%20MH370%20%26%20EK343.png?dl=0

    Is my understanding correct that the black circle next to the label “18:25” is NILAM, and the red circle is MEKAR?

    If yes, there is an apparent turn of your trajectory at MEKAR towards NILAM. This turn is not supported by the data, and moreover, it does not correspond to the last known heading. If I am not mistaken, it is an artifact of the assumption “N571”. Is my understanding correct?

    I am asking this in connection with the ‘hook’.

  9. MuOne,

    The issue is neither about Victor nor his disclaimer. He does outstanding work in all the senses. The issue is about IG: does IG as an entity look for answers or are they defending their original statement with regard to the terminal location? I think the answer is clear.

  10. Oleksandr – The IG were convinced they had the “answer” but it didn’t quite pan out. The issue now is how wrong were we? It could be 2025 without a scrap of plane and millions of km2 searched – and some IG members will be saying – it’s just off the edge.

    So you are right, it’s no longer about investigation for some, it’s about reinforcing one’s rightness. They have closed the book. And it was clear a while ago. There was resentment from many over so little as discussion of anything that did not fit their thinking, while the whole time the search resources were focused entirely on the data anyway. It was almost totalitarian. Maybe inside the IG that’s appropriate where you are “off the team” if you step away from the SIO 7th arc. To me it’s pathetic. There is now no daylight between ATSB and IG in that they are both scratching around from here. Unless they come out with something new do we need an IG? I suspect it would be a lot more profitable if they forgot the secret handshake and moved away in diverse tangents – like Victor. Some thought they would be up in lights by now.

  11. @Oleksandr: The black circle and red circle are the calculated positions at 18:25 for MH370 and EK343, respectively, showing the 27 nm separation.

    The last radar position at 18:22 and the (first) BTO value at 18:25 are consistent with a trajectory along N571 at 495 kn, and the BFO value at 18:25 (142 Hz)is consistent with a speed of 495 kn and a track of 296 deg, which is the azimuth of N571 at that position. Therefore, I assume the plane continued on N571 even though that requires a change in track around MEKAR. I assumed the turn occurred because that is what I believe the BFO, BFO, and radar data suggest.

    A plot showing the path, BTO, and BFO values all calculated with a resolution of 1 second can be found here:

    https://www.dropbox.com/s/ovbbo7yx313xzb8/Lateral%20Offset.png?dl=0

    The sharp climb required to match the BFO value of 274 Hz is not easily defended, especially since I now believe that EK343 was not close enough to require an avoidance maneuver. (That was the reason that I completed the calculation that you cited.) One (constructive) critic advised me that the calculation is stronger by ignoring the BFO value of 274 Hz and eliminating the sharp climb. There is merit to this.

    It is hard to know which of the BFO values before 18:28 to believe as the BFO abnormalities could have been due to thermal effects, signal noise, vertical velocity, or some combination of all three.

    As an aside, I have also produced a path that satisfies the BFO and BFO, including the spike of 274 Hz by assuming a sharp 360-deg turn to the LEFT at 18:25, with the assumption that the AES correction does not change between the log-on request and log-on acknowledge bursts, even as the track of the plane does change. (A track error of about 9 deg is required to produce the BFO spike.) This is pure speculation as I have no reason to believe that the AES correction is frozen between a log-on request and log-on acknowledge, and so I have not published my results.

    I have seen your hypothesis related to a broken INS input causing the AES correction to be absent and therefore causing the spike. That is an interesting thought, although I have not studied the specifics so I offer no comment.

  12. Oleksandr,

    Defending a thesis is part of the scientific method. It’s part of the peer review. Peers challenge the thesis with arguments to the contrary and the thesis’ authors defend their thesis with counter arguments to those.

    That process is done in search of answers.

    Nothing to snub the nose at here, I think.

    Cheers,
    Will

  13. Victor,

    Thanks for your clarification.

    Yes, I saw your climb plots. The comment I left was a possible re-appearance of MH370 on the radar if it climbed sufficiently high.

    However, by extrapolating location 18:25 based on the last heading: (1) the location at 18:25 is closer to the beginning of the ‘hook’; (2) quite a reasonable descent might be sufficient to fit 18:27 BFOs along the ‘original’ shape of the hook; (3) 18:40 BFOs would be consistent with the descent and heading towards Aceh or Maimun Saleh; (4) the descent is consistent with the disappearance from radars. Moreover, (5) the spike of 273 Hz is consistent with the same descent rate and ground speed, but the heading of 340 deg if you assume no compensation term.

    I would be interested to know if you could come to the same conclusions.

    In summary, my current view is that an event 18:22 forced the crew to attempt to land ASAP at the closest possible location, and the IR feature is the trace of smog rather than a contrail.

    Should this version be discarded as nonsense because of something I do not consider, or does it really make sense?

    With regard to 273 Hz, I can only say that the last BFO sample of -2 Hz is consistent with my hypothesis about INS: the heading of somewhat around 170 deg and groundspeed of around 200 knots can make -2 Hz achievable if you assume no compensation term.

  14. I see in Google Earth there has been earthworks at Kuqa Qiuci also….. not sure for how long.

  15. @Ipb: When I look at Kuqa Qiuci (ZWKC) via GE, the imagery date is 10/21/2013 and the airport is shown to be under construction. Yet, according to Wikipedia, the airport was reopened in 2011. Additional satellite imagery could resolve this discrepancy. Perhaps others more skilled than me in juggling satellite imagery could comment.

  16. @Oleksandr

    In the same line of thinking: assuming that the navigational data is not fed well to the AES, what happens if the compensation is not zero but for example kept constant, like at the last received value? I’m working on the vector math for this case, I don’t think it is too difficult:

    You get something like:

    D = -f/c*p ((s-p)dot(vs – vp)) + SOME_WRONG_fcomp

    in stead of Henrik’s eq. 6

    Of course all in the speculative arena. But assuming that the AES was behaving normally is speculative as well, because of all the observed abnormalities in BFO and BTO.

    Anyway, as part of the “anti-razors” contributions to the problem solving I think it is a good path to further explore.

    Cheers,
    Niels.

  17. @Ipb: The discrepancy is because Google Earth has the coordinates from the old airport in its database. (This tip from @littlefoot.) According to Skyvector, the coordinates for ZWKC are N41°40.60′,E82°52.30′, which when entered into GE shows a new airport.

  18. @Niels: See my post above where I produced the spike of 273 Hz by holding the AES correction steady while varying the track of the plane. A high turn rate is required.

  19. @VictorI

    Thanks, I indeed overlooked this posting. At first I would ignore the spike.
    What I intended to do is to look especially at the “less anomalous” BFO values (so 18:28 – 00:11 ?). What I expect if you assume a constant fcomp is that you probably have to maintain a more or less steady course to be consistent with measured BFO; so continue roughly NW after 18:28.
    The reason I expect this is that the changes in correction term due to changes in heading are actually pretty large compared to the “measured” D = fup+fcomp.
    It is all pretty “anti-razor” but I don’t care too much.

    Cheers,
    Niels.

  20. @VictorI

    Victor, would you know how to find out which data (attitude, position, velocity) is used to optimize antenna settings and how?

    On the side: it is weird we have to start addressing this and apparently the Boeings, Honeywells and Inmarsats of this world, who know all the details of the systems AND bear a big responsibility in aviation safety, mainly ignore or correct the anomalies and that’s it?

  21. Niels:

    We are on the same page. I was thinking about the compensation term based on the last available value of position and velocity.

    But I asked myself what would I do if I was the software developer? If INS ‘blackout’ lasts for sufficiently long time, the aircraft may change its heading by 180 deg, and then compensation term would result in twice large error than it would be without it. In addition, it is a bit simpler to ‘flush’ compensation term to zero if “INS/FMS/FMC is not responding”, rather than keep the last compensation value. Thus the simplest and safest way is just to flush compensation term to zero assuming the software is not allowed to hang and wait infinitely for the data from INS.

    Note, that uncompensated BFO 273 Hz can be made reasonably well corresponding to any compensated value between 142 and 176 Hz.

  22. Victor:

    Indeed, 273 Hz might be valid holding the AES correction steady.

    But just to reiterate:

    Time, BTO, BFO
    18:25:34.461, 51700, 273
    00:19:37.443, 49660, -2

    My thinking:
    1. Both pairs of (BTO, BFO) are correct, just we do not know how to interpret them correctly.
    2. Both pairs of (BTO, BFO) are erroneus (in terms of random errors) and should be discarded.
    3. Both BFOs are correct, but both BTOs are erroneous.
    4. Both BTOs are correct, but both BFOs are erroneous.

    Is there any reason to interpret BFO of 273 Hz as correct, but -2 Hz as wrong?

  23. Niels:

    P.S. Basically the problem is reduced to how to obtain answer from the software developers: Boeing, Honeywell, or Inmarsat.

    P.P.S. Apparently IG is not interested in knowing the answer because it may affect their end-of-flight scenario (e.g. plugoid or even piloted landing instead of spiral dive if -2 Hz is interpreted as uncompensated BFO). I have touched this topic already several times, but received no single comment from them.

  24. @Oleksandr

    Before continuing the discussion: disagreement on the best method to be followed is ok and better not make it a personal issue. IMO we need both the rigorous systematic “razor” based approach and out-of-the-box “anti-razor” thinking to address a complex problem of unknown nature and scale. Jeff and Victor here are doing well to stimulate both approaches so let’s keep it like that. In the end we all suffer from tunnel vision once in a while.
    Niels.

  25. @Niels: I believe the heading and attitude are used by the antenna steering hardware to properly point the antenna. If INS is lost, I don’t see how antenna steering is possible, nor will the GES support the Class 3 service without antenna steering.

    @Oleksandr: I think all combinations are possible. I can make no definitive statement about whether or not either 273 Hz or -2 Hz is valid.

  26. @VictorI, Oleksandr

    I would expect that position (wrp satellite) would be needed as well to steer the antenna properly.
    As Oleksandr pointed out we don’t know how the system reacts in the case input is not provided, seems corrupted, or is only partially provided.
    I think the strongest argument against these options is that without proper frequency compensation it is hard to produce the small “measured” numbers for (fup+fcomp) that we observe in the Inmarsat data (unless the a/c was not flying at all, which is fully inconsistent with BTO data)
    Niels.

  27. Niels, Victor,

    Thanks for your comments.

    May be the gap in communication 18:25:35-18:27:03 was caused exactly by the wrong compensation term, i.e. because fup+fcomp was out of the frequency range that can be received by the satellite. One would expect a sequence of communications on the restart, like it occurred at around 16:00, but it was not the case for the restart 18:25.

    Niels:
    Yes, uncompensated BFO is very sensitive to heading and velocity, but it is still possible to ‘reach’ both 273 Hz and -2 Hz within reasonable groundspeed and it turns that the former is generally consistent with the heading of around 340 deg, while the latter is consistent with the heading of around 170 deg.

  28. @VictorI, Oleksandr

    Would you know if there is more info available on antenna system (directionality, steering algorithm, steering precision, steering interval etc). I’m asking this because I’ve been wondering for a long time how you would maintain connection while being in a spiral dive. But also to get a feel how critical the antenna steering is in general, and how to explain the relative high power readings for 0011 and 0019 UTC.

  29. @Niels: Perhaps the higher than expected power at 00:11 and 00:19 is due to pointing accuracy of the high gain antenna (HGA), which will have a narrow half-power beamwidth. Remember that the antenna is pointed towards the geostationary position. At 19:41, the latitude of the plane is near zero and the declination is near its peak of 1.6 deg. As a result, the pointing error is at its maximum. At 00:19, the latitude is furthest from the equator and the satellite’s declination is around 0.5 deg. The antenna’s alignment with the satellite will be improved.

  30. @Victor, Niels,

    I am no expert in sat comms, but your discussion about power gave me an idea:

    If there are measurable differences in transmission power, would the 00:11 and 00:19 values hold some clues as to the relative flight path alignment to the 7th arc? I am thinking of the end of flight spiral dive scenario. One could take the 00:11 power as a baseline and infer some relative likelihoods of whether 00:19 is an out- or inbound of 7th arc trajectory.

    This could shed some light on the question of whether the plane would be more likely inside or outside of the 7th arc.

    Cheers,
    Will

  31. @VictorI

    It is an interesting suggestion. We really need to know more about the antenna system. If it is the electrically steered type I would expect opening angles (“half power angles”) of tens of degrees rather than degrees.
    Perhaps Mike Exner could help us out?

    Niels.

  32. @MuOne

    Probably the power readings could give some basic indications, as I expect mainly on a/c attitude; If the antenna steering was still working mainly in the sense that it can possibly be used to exclude certain extreme attitudes like nose down or upside down. Remember the satellite is high up (36k km) near the equator.

    Niels.

  33. Niels, Victor,

    Sorry, I don’t have more info on HGA design. I would imagine it to be mounted on a gyroscopic device to eliminate the influence of turbulence, but it is just a thought.

    Meanwhile I have compared the two login events, 18:25 and 00:19. They are almost identical in terms of the sequence of communications:

    Time(18:25); Time(00:19); Channel Name; SU Type
    18:25:27.421; 00:19:29.416; IOR-R600-0-36xx; OxlO- Log-on Request (ISU)/Log-on Flight Information
    18:25:28.852; 00:19:31.572; IOR-P600-0-36FC; Oxll- Log-on Confirm
    18:25:29.572; 00:19:32.212; IOR-P600-0-36FC; Ox40- P-/R-Channel Control {ISU)
    18:25:29.572; 00:19:32.212; IOR-P600-0-36FC; Subsequent Signalling Unit
    18:25:30.213; 00:19:32.852; IOR-P600-0-36FC; Ox41- T-Channel Control {ISU)
    18:25:30.213; 00:19:32.852; IOR-P600-0-36FC; Subsequent Signalling Unit
    18:25:34.461; 00:19:37.443; IOR-R1200-036yy; OxlS – Log-on/Log-off Acknowledge

    Here: xx= E1 and yy=ED for 18:25 logon; xx=F6 and yy=F8 for 00:19 logon – the only difference.

    Note that the very first login (16:00) is characterized by different sequence of communications.

    Abnormal pairs of BTO and BFO correspond to the last string in both the cases. Thus, I think both 273 Hz and -2 Hz BFOs require correction of the same nature; they are unlikely associated with the aircraft motion.

    If there is any reason to think that 273 Hz is correct while -2 Hz is wrong?

  34. @Oleksandr: That is an interesting way to present the data. It has been the feeling of a number of us to accept the -2 Hz as indicative a steep descent and ignore the 273 Hz, but I could not rigorously defend this. The proposal of a steep climb is a weak vehicle to match the value of 273 Hz, especially if there was no other plane in the vicinity.

    There is an interesting anomaly in the log-on data at 16:00. The BFO starts at 99 Hz at the log-on request but within 33 seconds drops down in the 86-88 Hz range. The log-on request is on channel R10, the same as the log-on at 00:19. This makes me wonder if the value of 182 Hz seen at 00:19 should be reduced by 12 Hz or so.

    Also, there is seems to be signaling data originating at the GES missing in the log-on sequence at 16:00.

  35. Oleksandr,Neils

    The HGA configuration on -MRO comprised two flat, conformal “apertures” mounted on the upper fuselage (above door 3 on each side). The aperture oriented toward the satellite is electronically selected, via solid state relay, and the “beam steering” is effected by phased array processing.
    From memory, I recall the ‘boresight’ -3db pattern is approx +/- 10°.

    Concerning the GES Rx Pwr Level, the AES sets a nominal EIRP for the R ch Log On request and the AES then adjusts EIRP based on the level of signal received from the GES. For R and T channel transmissions the power level is then maintained as a constant throughout the Log On session.

    :Don

  36. @GuardedDon

    Don, that is very useful info, many thanks!
    Would you know the manufacturer and type mounted?
    Would you also know what is the max. steering angle possible? I guess that it is a wide sweep angle around straight up, but how much?

    Niels.

  37. @Oleksander

    Yes very interesting. I’ll check your calculations based on suggested lack of freq. comp. for the 273 Hz and -2 Hz points.

    Niels.

  38. Niels,

    I had collated a PDF with antenna information about 12 mths ago. Drop me a note at gmail.com, I’ll dig it out & share.

    Oleksandr,

    Each P-channel has a number of associated R channels. The station management channels (P/smc & R/smc) , used for Log On, are maintained in the AES system table. During Log On the GES allocates R channels to the AES using the type 0x40 Signalling Unit (and its subsequent SU). The AES will select one of allocated R channels and a random slot on that channel in order to transmit a SU burst to the GES.

    The Log does not record the entire 16:00 Log On.

    :Don

  39. @Oleksandr

    Just implemented vertical speed. I get close to 0 Hz fup assuming -10 m/s vertical speed, 250 knots GS, track 220. Could it be correct?
    (Using the 0011 utc satellite pos and vel. and a/c pos. E92 S36). Expect almost the same for 0019 utc.

    Would be interesting to know standard “zero power” glide procedure and parameters.

    Niels.

  40. Niels,

    I am getting the following f_up term for 0011UTC, E92S36, 250 knot/220 deg heading:

    w; f_up (my script); f_up (Yap’s V2 calculator)
    -10.0 m/s; -67.73 Hz; -66.82 Hz;
    +10.0 m/s; 0.51 Hz; 1.65 Hz;

    I guess you have sign mistake for vertical velocity term as the difference between my and Yap’s f_up is only about 1.1 Hz.

    If I recall correctly, glide is defined by the ratio tan(alpha)=CD/CL, where alpha is the angle of descent. For B737 CD/CL = 1/17 if I am not mistaken (hence glide angle is 3.37 deg), but I don’t know the value for B777. 250 knot GS would correspond to 7.6 m/s descent rate.

    Gliding or plugoid could be made consistent with BFO for the mid to northern SIO in my opinion. The problem is to find somebody who has access to a simulator and willingness to try other modes besides AP.

  41. Don,

    Thanks for the clarification re design. How quick does the antenna respond to the change in heading? What happens in case of roll, for example?

    What did you mean by “The Log does not record the entire 16:00 Log On.”? The published logs are not complete, or Inmarsat did not record all the data?

    Anyhow I would still be interested in getting your comment about 273 Hz and -2 Hz issue (add a possible cause of the associated long BTOs).

  42. Here’s a few data and a guess:

    An A330-200 has a best L/D of 22.

    The B-777-200ER FCOM gives 93 NM and 19 minutes for a descent from FL250, that is an angle of 1:22.6 at 294 kTAS.

    The difference between a normal descent and a power-off descent is the difference between the slightly negative idle thrust and the windmilling drag of the dead engines. Perhaps 1:20 at 300 kTAS would be a reasonable guess for the power-off descent.

  43. @Oleksandr
    Thanks, you’re right, I’ve found the mistake.
    Now I get 1Hz for 226degree track, 250 knots, -10 m/s, E92S36, 00:11UTC

    @Gysbreght
    Thanks, we can have a look what it means for track if we assume those values and no freq. comp.

    Niels

  44. Oleksandr,

    The ISUL released on 26th May 2014 by MoT/MY begins with the Log On Acknowledge SU. It omits anything prior. Where should it start – the 12:50 aircraft power up, the day before, the week before? ATSB published an update on 23/12 including two 15:59 Log On Rqst SUs. I have no insight to the reasoning for the log start point but earlier would have been better.

    Concerning the ‘long’ BTO values recorded for the received R ch Log On Acknowledge SUs: it’s all in the frame timings. While the superframe is consistent at 8 seconds, the P and R channels do not employ consistent framing across all data rates. At 600bps the P channel comprises only 4 frames per superframe; at 600bps the R channel comprises 8 frames per superframe whereas at 10500bps the P channel comprises 16 frames per superframe as does the 1200bps R channel. The frame boundary markers are the timing datum points for BTO.

    The consequence of the preceding information for the R ch frame burst carrying the Log On Ack SU is that it is being measured relative to the 2 second 600bps P ch frame for which it is the response but it is transmitted in a 500ms slot. Therefore, the P ch frame -> R ch frame timing may be ‘normal’, +500, +1000 or +1500ms depending on the slot the AES selects to transmit the R ch frame burst.

    I’ve previously described the ‘long’ BTO as being an artifact of the sequence of Log On exchanges ‘crossing’ from the station management channels to the AES’ allocated data channels.

    Above, I stated that the frame boundary markers are the BTO datum: this implies that BTO can only be measured once per frame burst.

    BFO, however, is recorded for each interleaver block (max 31 for a T ch burst) within a frame as it is ‘clocked in’ at the GES.

    I hope my attempt to convey this information succinctly make sense.

    :Don

  45. @Don – your attempt to explain is appreciated, but it still doesn’t make sense, unfortunately.

    You state:

    “… the frame boundary markers are the BTO datum…”

    and

    “… frame timing may be ‘normal’, +500, +1000 or +1500ms depending on the slot the AES selects to transmit the R ch frame burst.”

    That suggests, as I’ve long suspected, that the BTO really isn’t just the oft-suggested “round trip – 495679” because as you say, the AES chooses among a series of subsequent slots. The round trip is delayed by a multiple of 500us. Correct?

    If the AES is choosing the slot, rather than just doing a response ASAP, it must be sending the signal so that either 1) it leaves the AES at a frame boundary, or 2) it arrives at the GES at a frame boundary.

    Option 1 would be simpler and would not require any timing compensation other than the AES knowing when the slot starts.

    Option 2 would require compensation of the distance by the AES and would not provide any insight into that distance unless the payload had a sent time in it.

    We’ve ruled out Option 2 for the moment because those with more expertise than me have unequivocally stated that the AES does not compensate timing, only frequency.

    However, the problem I keep having with Option 1 is that it seems to be contradicted by the log data, showing numerous signals received at .405 or .905 seconds, +/- a few us?

    It seems they all arrive on a schedule. The variation in the BTO seems to be much greater than the variation in the receive times. You are saying the slot/frame boundaries are one endpoint of the BTO measurement. What exactly is the other end of the measurement? The timestamp?

    Is it possible to create a chronology from a single log entry that includes the frame and slot boundaries, the bias, the BTO, and the timestamps? It would make a lot more sense to see numbers that show what was measured.

  46. JS,

    The condition for a ‘long’ R ch BTO only exists during the Log On phase when the AES is using the 600bps station management channels.

    Once Log On is complete all channels use a 500ms (millisec) frame.

    The AES must transmit the return burst within 300us (microsec) of the P channel timing datum, that is the only timing variance allowed at the AES.

    Don’t forget that transmission of the forward P channel is continuous.

    Probably a case of a picture being worth a thousand words….

    :Don

  47. @JS

    I would suggest that the time column in the Inmarsat log is the start of the _slot_ at the GES as defined by the P channel structure. So effectively it is the transmit time since the AES sends its reply for that slot (if it has been allocated that slot by a previous P channel transmission by the GES) when the structure that defines the slot is received at the AES. By inspection there are a number of slots with multiple records indicating more than one event in a particular slot.

    Since the BTO needs to be accurate to a few microseconds (not milliseconds which is the accuracy of the logged time) I suspect a separate process is used to measure that time which is then entered into the log.

    Alex – please don’t keen quoting the ‘Aeronautical Air-Ground Data Link Communications’ reference. It is just wrong – check the primary AMSS standards.

  48. JS, Richard,

    The time column in the log is merely the logging time stamp. The allocated P and R channel entries occur in 500ms multiples because 500ms is the frame period for P ch at 10500bps & R ch at 1200bps.

    The P-ch sync ‘datum’ for return transmissions is the Unique Word forming the end of the P ch frame (and start of next). The AMSS spec states the return burst must start within 300us of that event. There is no other variable or timing compensation involved in the transmission of the return channel burst at the AES, none.

    :Don

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.