MH370

MH370: This is simply a new (empty) post to allow for a new thread of comments

74 Comments

MH370: This is simply a new (empty) post to allow for
a new thread of comments

Duncan Steel, 2014 June 01

I am posting this empty/dummy post simply to enable people to start a new discussion/comment/reply thread without needing to download all the >600 comments and replies under the previous post.

 

74 thoughts on “MH370: This is simply a new (empty) post to allow for a new thread of comments”

  1. Just a note: 9M-MRO was a 777-200 (2H6ER). Not sure how much the numbers will vary between the 300 and 200 series.

  2. I’m sure there was a comment in one of the reports or interviews with Inmarsat that the last ACARS message received included the current fuel load.

  4. This is the most definitive statement on fuel endurance that I have seen. The response comes from my friend, the very experienced B777 captain, who I know to be very reliable. I gave him some figures, known takeoff weight, known fuel load etc – – – –
    ——————————-
    “This is a most interesting calculation and the TAS at 490 knots would be almost exact under normal cruise speed situations. If you knew the cost index (CI) inserted into the Flight Management computer you could make an assumed cruise speed, but it would be fairly close to the 490 knots you’ve found. This calculation is thrown out the window if the crew insert a fixed cruise Mach number or indeed LRC (Long Ranger Cruise). Long Range Cruise has a higher Mach number early in the flight and as fuel is used & the aircraft becomes lighter the cruise Mach number reduces. Long Range Cruise means the aircraft cruises at a constant angle of attack, so as the aircraft becomes lighter with fuel usage the angle of attack reduces and the cruise speed reduces as a result. I personally use this method of cruise if on or slightly ahead of schedule. On long range flights (6 to 7 hours or more) you can actually use this method to reduced you total flight time as the cruise Mach number is quite high for a good portion of the early stage of cruise then revert to a cost index cruise once LRC reduces to the same as the CI cruise Mach number which is plus/minus 10/15 knots of around 500knots TAS. Sounds complicated but actually extremely simple use of operating the aircraft.

    Using your numbers needs no great calculation, but I can do this in my head as the numbers are very familiar.

    Fuel exhaustion could actually go beyond 00:19 but even to 00:30 or slightly beyond as the aircraft is actually quite light and no where near maximum take off weight, hence a lower fuel consumption for that weight at optimum altitude for weight. As the fuel burns off the optimum altitude increases as a note to know.

    A huge amount of this calculation assumes normal operating speeds, but if you wanted you could cruise for endurance in which case with these numbers fuel exhaustion could go beyond 00:30.

    Your figures, if you were to fly under standard cruise conditions Brian would be an accurate enough answer.”
    —————————–
    Some weeks ago I described how the CI was applied, and how minimum drag is achieved at a particular angle of attack. This explains it in a nutshell.

  5. Hi Duncan,

    This is an example of a southern flight path that fits the known ground data, ADS-B data, Malaysian Military Radar trace, your latest ping rings, the BFO data as interpreted by Yap and the speed of 482 knots from 18:40 UTC onwards as derived by Brian.

    The location at 00:10:59 UTC is 38.15S 85.99E. It is exactly where AMSA started searching on 18th March 2014.

    http://skyvector.com/?ll=-15.057978557895726,94.17187500375482&chart=304&zoom=13&plan=G.2.7493,101.7214:G.2.8084,101.683:G.6.9031,103.57:G.5.6807,98.9407:G.6.5868,96.2438:G.6.8511,95.99:G.-2.75,93.54:G.-10.64,92.02:G.-18.56,90.62:G.-26.48,89.24:G.-38.15,85.99

    AMSA Search Area 18th March 2014:
    https://www.dropbox.com/s/eefckd513tpcr3t/AMSA%20Search%20Area%2018032014.pdf

    The full data set is here:
    https://www.dropbox.com/s/n1pmpxhxiwy1if3/MH370%20Inmarsat%20Data%20BFO%20and%20BTO%20V2.pdf

    An excel is here:
    https://www.dropbox.com/s/e3pel3g830w8eee/MH370%20Inmarsat%20Data%20BFO%20and%20BTO%20V2.xls

    Richard

  6. Alexander,
    We all are curious and want to contribute; however, we have to be reasonable about requests for Duncan to do additional work for us. I know I have a lot of test cases that I would like to run. I am fortunate that I have developed the numerical tools that enable me to do many of these calculations myself within a reasonable level of accuracy. That said, I can’t keep up with my OWN requests, never mind fulfilling the requests of others. I am sure, although he is too polite to say it, that Duncan feels the same sense of being overwhelmed. Original thoughts and insights are helpful and always welcome, but requests for Duncan to do more work are not fair to Duncan.
    Victor

    2. Actually – to that end, I have a proposition:

      Let’s all take a vacation for five days. Close the shop. Take your kid’s fishing. Enjoy that movie you never got around to watch. Read up on all those posts you never had time to read.

      How about it?

      Henrik

      1. Good idea Henrik.

        In fact I had been intending to close this blog down due to the number of rude and personally abusive messages and comments I have received.

        Duncan

  7. Duncan,

    I think we need to converge on the BTO interpretation, or we will only create more confusion. There is a model, suggested by Richard Cole and further tested and refined by myself, which reproduces the “fuzzy elevation angle” graph to a very high degree of accuracy. It puts the ‘nominal terminal’ at (0N,64.5E) on the ground. Then we have the linear BFO model, by Mike and yourself, which seems to involve a moving ‘nominal terminal’ and a geostationary satellite. Both models cannot be correct. What say you?

    Henrik

    2. I almost forgot to mention this: In the reproduction of the “fuzzy elevation angle” graph, I used a time delay offset of 180 us in order to match the graph precisely. However, as we know, the elevation angle at KUL is wrong by a little bit, after warmup (0.4 deg). Putting the time delay offset at zero instead, the elevation angle is 46.94 at 16:30. It does not get much better than that. No parameters or calibration at all, just a nominal terminal at (0N, 64.5E).

      And the warm-up could very well be important around 18:25 as well, as you have mentioned. Perhaps the recalibration from 16:00 can be transferred over.

      Henrik

  8. Here is a document that contains a way to find a unique flight path from the BFO/BTO data: http://bitmath.org/mh370/mh370-path.pdf

    Before anyone jumps, it should be noted that the path depends strongly on the information *between* the known points, and hence is not a conclusive solution – yet. That said, there are a number of observations:

    1. The BFO/BTO data we have is not enough to reproduce the known path (radar observations included in the known). There are a few key BFO points that need to be added: one close to IGARI, one close to Penang, and one close to NILAM. With those points added, the known flight path up to 18:22 is reconstructed – *without using any ADS-B data or other constraints than BFO/BTO*.

    2. There are at least two solutions that are vastly different, and that seem to depend critically on the BFO around 19:00. One solution is the ’round-trip’ solution I was sketching last week, which ends in the Java sea, and the other is the straight-into-the-indian-ocean solution, that we are already familiar with. The last couple of days there has been uncertainties around whether an excursion to the Adaman island (which the former solution depends on) is possible, and it seems that it still is, given details in the BFO and altitude between 18:40 and 19:00. Victor is also working to confirm or deny this.

    3. It should be stressed that the only ‘control’ one has over the solutions in this model is to add BFO points between the already known ones. This also tells us something about what we can expected to ever find out: without additional corroboration, it is impossible to determine a unique ending point.

    Henrik

  9. Re: DrD — 2014/06/02 at 11:04 http://www.duncansteel.com/archives/812#comment-6463
    You have asked the right questions (to my ear at least…)

    I specifically chose to keep the BFO model flaw discussion/explanation isolated to just the first 4 BFO data points to keep to the singular topic of RoC having been omitted from the original BFO model.

    You point out another conclusion coming out of the collective work analyzing the formatted data. The 18:25-18:29 BFO data points are not indicative of a ‘possible turn’. At least the first of the three previously published BFO data points (the highest one at 18:25:34.461) is a direct, and expected, result of the SDU re-starting and initiating the log-in sequence. (I consider this conclusion to have reached consensus status)

    The understanding of the other two original data points has not been discussed as much.
    (and, we now see in the formatted data that there were not just three 3 BFO data points as seen on the original BFO chart, but 13 BFO readings during this time period – the one at 273Hz, 9 ranging from 142Hz to 148 Hz, and 3 ranging from 172 and 176.
    – The second point (~175Hz) is not well understood. It is higher than ‘expected’. Or, at least, it is not clear yet why it differs so much from the BFO values both before and after it. This could be due to:
    a) another effect of the log-in sequence (a good comparison would be to review the initial log-in sequence prior to 16:00, which was not included in the formatted data)
    or b) a result of a change in altitude, or some other real frequency shift that was not fully compensated for by the AES.
    (This may be a viable working theory to be further examined. )

    -The third data point (~145) in this series appears to be in line with the BFO curve as currently understood. But, this is not provable. And, further investigation could even swap our understanding of which of these two values represents the nominal BFO around this time, and which is the exception (that is not yet understood…)

    (opinion: I am inclined to believe the plane was turning and changing altitude around this time. But, I have not yet seen a proposed flight path that would align with even 12 of the 13 BFO values in this time period.)

    The possibility that the BFO or BTO calibration was significantly disrupted when the SDU re-started (18:25 or 00:19) has been looked at, and the consensus is that there is no observable shift in the recorded BFO or BTO data. So, while there may be some effect, it appears that it is less significant than the baseline noise in these numbers (the +/- tolerance or error margins inherent in the raw data, which are better understood with the benefit of the formatted data.)
    The observable noise and error margins do need to be written up. This would include mapping the margins of the BFO (maybe +/-2 Hz) and BTO (maybe +40/-0 uSec) data out to the resulting values for elevation angles, handshake arcs, and potential airplane positions and flight paths.

    In my opinion, running a re-creation of the entire flight would be a huge piece of work, and would provide very little useful information. Controlling so many variables at once, just to match the known information, would be a daunting task. But, worse, there are so many interrelated unknowns over the many hours and many miles of the flight, that any one flight would only look at one specific permutation of the many many many (: that’s many^3) possibilities. If we are going to iterate through many possibilities, I’d rather use mathematics on computers, driven by our collective wisdom and imagination. ,,, pretty much what we are doing here.

    My opinion – I believe that the recent increased understanding of the BFO algorithms and numbers does preclude any Northern path flown in a relatively direct fashion. There is still work under way to understand just how ‘wild’ a Northern flight path would have to be to create BFO and BTO values that match with the ones recorded in this data.

    (The ‘increased understanding’ is that the BFO is primarily comprised of imperfections in the Doppler pre-compensation applied prior to transmission from the airplane, due to satellite position and movement not included in the algorithm.)

    -Bill

    1. Bill,

      “[…] result of the SDU re-starting and initiating the log-in sequence. (I consider this conclusion to have reached consensus status)”.

      No, there is no consensus here. A rapid change in altitude is still a possibility. There are also combinations of the temperature effect, altitude change, and turn to consider.

      Thanks,
      Henrik

  10. Looking at the data closely it seems that the offset in both BTO and BFO is a fixed amount. The BTO is also not the same for all the channels. 5000 us steps seems a good guess. At maximum speed a 5000 us BTO difference would mean two hours of flying time in distance.

    For the BFO the same calculation seems much more difficult. My best guess at this time is 15 us offset and this gives a maximum acceleration of 264 m/s in 17 s as a limit. This means that if the samples are more than 17 s apart, a step of 15 us might be possible. Is the 20 us change between 16:42:28 and 16:42:32 possible in a T7? If not the steps might be 20 us?

    1. sSquare,
      I am not understanding your post.

      – The 5000uSec (5mSec) offset between R-Channel and T-Channel BTO values does look consistent.
      – It was asked previously if there is a consistent offset between the BTO values from individual numbered channels within a channel type. But, I have not seen any analysis that concluded that there is an offset. (and showed what offset to use)

      A 20uSec change in BTO is insignificant noise. The BTO measurement is recorded to the nearest 20uSec.
      At any one point in time, the BTO measurements generally seem to stay within 40uSec (tolerance of +40/-0uSec from the actual value?). There are some time periods in which the values vary up to 80uSec, seen mostly on the ground.
      ( I am interested in understanding why some values would be 60 or 80uSec above other readings. The leading assumption is that there is multipath noise causing timing jitter in the BTO results.)

      Looking at BFO values for the pre-flight period:
      – first 10 seconds, first 6 entries BFO = 103 {no explanation, want to see the missing log entries prior to these…}
      – 16:01UT to 16:28 – sitting at the gate BFO varies between 84 and 90.
      ( I think I see a trend downward in these numbers, but it is pretty low in the noise. Would be nice if satellite motion is creating the slight downward trend.)
      – 16:28-16:29 – push back and taxi – BFO 95 to 100 for awhile, then 2 BFO around 88 around 16:29.
      – 16:41 – 16:56 – take off, turn and climb – BFO changes a lot, but hangs around a specific value for a while, then jumps to another range. (140-141, then 1476-149, then 154-160, then 145-153, ten 120-125, then 131-133, 155-163, etc.)
      – 17:06 – 17:07 after climb, Level flight at FL350 – BFO ranges from 130 to 138.

      That’s the main sections of the flight that we have ADS-B flight data, as well as the Inmarsat data showing BTO and BFO.

      -Bill

  11. Dear Duncan,
    Just a small question relating to the file that you placed on dropbox that gave the location of the 3F1 sat in terms of azimuth, elevation and range relative to the theoretical Position. Comparing the 3f1 positions calculated therewith in terms of lat, lon and altitude with the earlier orbital positions that you gave in the thread “positions of inmarsat 3F1 during the flight of MH370” I sometimes find some minor deviations that are however beyond rounding. Would you say that the values given in the thread are more accurate, less accurate or should be the same ? (If you want, I will make an overview of the differences).
    Best regards

    1. I think they should be the same. Recall (from comments & replies here) that the big file I put in Dropbox results from me updating (or maybe stepping back) a bit in terms of the input orbital elements for the satellite, in the Dropbox file not using a TLE update from about 23:15 UTC.

      However, it is true that the positions obtained from STK can vary by a little, depending on what sort of input/output is wanted. For example, the relative positions of x referred to y do not always correspond EXACTLY with what might be expected from the relative positions computed for y referred to x.

  12. Another one for the conspiracy enthusiasts (of which I am not one).

    You may have noticed that as a space scientist/astronomer I always give dates with the most-significant digit first. Thus today is 2014 June 02 and the time might follow as hours, minutes, seconds, decimals thereof. Doing it any other way makes as much sense to me as quoting the price of a packet of chips as 99 cents and two dollars.

    However, if one must put dates in a different order, then the only sensible way to do it ( 😎 ) is to be consistent in the order in terms of the magnitude of the units: thus day/month/year.

    One nation with which I am familiar does it differently, using month/day/year. Then again, in that country light switches go up to turn the light on, and in sports events they list the home team second (i.e. away versus home, rather than home versus away as most other peoples would think ‘natural’). It’s the USA I am talking about.

    If one takes a look at the cargo manifest for MH370, for example at http://www.thestar.com.my/News/Nation/2014/05/01/mh370-prelim-report-cockpit-tower-recordings-released/ ,
    one finds that the dating on the waybill for each cargo item is given as day/month/year. Except for one, in which the date is given as month/day/year. That item is the dispatch note for the lithium-ion batteries.

    1. That is quite an interesting little catch. I plan on taking a closer look at the manifest pages this evening and scouring for more discrepencies/items of interest.

      1. OK Luke, but don’t take my post there too seriously. BTW it was not me who caught that cold, but someone who wanted to remain anonymous.

    2. It also is the only waybill to have a different format of air waybill number, as it excludes the origin airport from the top left of the form:
      232 KUL 1200 7306
      232 PEN 10664905
      232-10677085 ****
      232 KUL 1202 2382
      232 KUL 1187 3632
      232 KUL 1202 2404
      232 KUL 12009141

      Maybe nothing- but there are now at least two characteristics present in which one air waybill is different from the other 6.

    3. Sadly no conspiracy there :)
      The manifest is printed by NNR Global Malaysia which is a branch office of NNR Global Logistics USA.
      Their operational IT systems, including their tracking system PowerNet, are US based and use the US date format.
      Therefore the lady (Andelyn Teoh) who printed the airway bill in Penang had no control over the date format generated by the US system.
      A bit of trivia: NNR refers to Nishi-Nippon Railroad Group located in Fukuoka, Japan. It owns NNR Global Logistics Japan (operated as a separate entity) and NNR Global Logistics USA.

    4. I agree with Duncan that the most likely (not to say more likely than not) scenario is lithium ion battery fire, but not, I suspect, from the batteries in the cargo. From what I have read from various sources, an example of which is the report from ICAO proceeding in April, 2014 quoted and linked below, I suspect that such a fire would have been catastrophic long before 00:19. Assuming, as I do, that the MH370 cargo batteries were wrapped in accordance with the ICAO requirements placed in effect in 2012, this information suggests that the majority of an ICAO committee thought that such wrapping “could not mitigate a fire.”

      “A Secretariat proposal to forbid the transport of lithium metal batteries as cargo on
      passenger aircraft was presented to the working group.
      . . .
      Although the majority supported the proposal to forbid the transport of lithium metal
      batteries as cargo on passenger aircraft, several members did not support it believing that a prohibition
      would result in an increase in non-compliance and have a negative effect on safety.
      . . .
      Those who supported the prohibition believed that allowing unlimited quantities of
      batteries on a passenger aircraft despite the known risks was unacceptable and that whether or not there
      had been any incidents involving shipments proven to be compliant was not a sufficient basis for
      determining appropriate safety standards. The potential for the batteries to auto-ignite, the fact that
      lithium metal batteries could serve as fuel for an independent fire, the fact that current packaging
      requirements could not mitigate a fire and the lack of an effective fire system necessitated proactive
      action.”

      http://www.icao.int/safety/DangerousGoods/Working%20Group%20of%20the%20Whole%20on%20Lithium%20Batteries%2020/DGPWGLB.2.WP.008.1.en.pdf

      To me, the more likely scenario would involve a crew or passenger personal electronic device battery fire.

      1. Such fires are not uncommon. http://www.runwaygirlnetwork.com/2014/02/27/ped-battery-fires-on-777s-prompt-call-for-action/

      2. Tests supposedly show that a single such battery (I am guessing a 9-cell laptop battery) could cause a serious cockpit fire:

      “Furthermore, the FAA tests found that:
      The testing showed that even with a very high ventilation rate of one air
      exchange per minute within the cockpit, a typical COTS [Commercial Off The Shelf] Li-ion battery could
      pose a significant smoke hazard within the flight deck environment. . The
      initial battery event occurred, at times, without warning (i.e. no visible smoke
      or audible event prior to failure). The battery cells failed in a very vigorous
      manner, at one point with enough pressure to forcefully push open the
      unlatched cockpit door. The most striking safety hazard however, was the
      volume and density of smoke that emanated from the failed battery cells.
      During one test in which only four of the nine battery cells went into thermal
      runaway, the installed smoke meter recorded greater than 10% light
      obscuration/ft for a period of greater than 5 minutes and a peak value of
      greater than 50% light obscuration/ft, resulting in severe lack of visibility within
      the flight deck.
      (Federal Aviation Administration, 2012)”

      http://aerosociety.com/Assets/Docs/Publications/SpecialistPapers/SAFITA__2013.pdf at pdf. 28

      3. I have not found an answer to Duncan’s question about what gas burning lithium ion batteries give off. But here are some hints suggestive to this non-chemist that other cabin materials that might have come into contact with a burning battery could give off toxic isocyanate gas:

      About 10% of a B777 structural weight is constructed of composite materials. Id. at pdf 40. In dealing with composite fires, “intense heat usually found at an accident site will decompose the resins bonding the fibres liberating toxic isocyanate
      fumes.” Id. at pdf 47.

      Apparently polyurethane foam when burned gives off toluene di-isocyanate fumes. Fighting a fire in a polyurethane foam factory in 1967, five firefighters exposed to toluene di-isocyanate fumes suffered “immediate” effects consisting of euphoria, ataxia [“lack of voluntary coordination of muscle movements”] and loss of consciousness.

      http://www.ncbi.nlm.nih.gov/pmc/articles/PMC1008107/?page=1

      4. LGH was tweeting last week about the comment at 13:01 in the 4 Corners documentary “that someone inside the cockpit began interfering with the inflight entertainment system.” That seemed to me like peculiarly obvious speculation at best in an otherwise sober documentary. But is it possible there was a basis for it, e.g., some passenger texted to complain about it after takeoff but while still in cell range? I only bring this up because in the case of one lithium battery fire on a 777-200, “a cabin crew member noticed a smell characteristic of an electrical fire at the level of seat 4F in Business Class. He turned off electrical power to the general video system, removed the seat covering and noticed the presence of flames.”

      http://www.runwaygirlnetwork.com/2014/02/27/ped-battery-fires-on-777s-prompt-call-for-action/

  13. Bill,

    That is a great summary. I have a minor comment:

    “1) The Inmarsat ‘Projected: South Track’ only matched 2 of the first 4 data points of the “Measured Data”. And, those are locations where we have exact ground locations and ADS-B data to accurately know the position and movements of the airplane. There is more uncertainty about what Inmarsat was projecting, then there is about what was measured.”

    We can match Inmarsat’s predictions for the first 4 data points if we ignore the effects of rate-of-climb (ROC), which is what Inmarsat seems to have done. Our best model includes the effect or ROC in calculating the actual L-band Doppler and assumes the AES correction algorithm neglects it. The Inmarsat predictions indicate that Inmarsat either included ROC in both places or neglected it in both places, so the effect of ROC on the residual offset is not present in their predictions.

    1. Victor,
      Thank you for checking my summary.
      Can I re-arrange your words in relation to the actual BFO data, and claim that we agree??
      1) The BFO measurements represented in the logs include the Doppler shift due to the airplane’s rate of climb (vertical movement) at the moment of measurement as a component of the overall BFO.
      2) the Inmarsat “Predicted” tracks do NOT correlate with the BFO measurements in the logs
      — The measured BFO values are roughly 20Hz (16:42) and 34Hz (16:56) higher than the predicted tracks.)
      3) The models that have been derived here accurately match the measured BFO for these data points (as well as the additional BFO data seen in the formatted Inmarsat logs). This is due to the proper inclusion of the rate of climb induced Doppler shift that was known to be present based on recorded ADS-B flight data from other sources.

      This is a key discovery that came out of group’s analysis of the Inmarsat data released to date. Our modelling indicates that the Inmarsat BFO model did not properly incorporate all known causes of Doppler Effect frequency shifts.
      – The ‘Rate of Climb’ (vertical airplane movement) is now believed to have been omitted

      Next questions:
      – Are there any other BFO components that appear to be incorrect in the Inmarsat model?
      – What is the impact of this quirk in the Inmarsat model ?

      My opinion –
      — The inability of the Inmarsat model to match the measured data (as seen on the original BFO chart) was the 2nd or 3rd red flag that raised concern regarding the technical ‘correctness’ of the Inmarsat model, and hence, the conclusions that have been made on it’s results.

      This BFO information following the release of concentric and perfectly circular arcs (elevation angle ‘ping’ rings), which implied that satellite movement was not included in the mathematical analysis of what we now know to call BTO data.
      Over a number of weeks (March-April) there were multiple refinements of the Inmarsat analysis, which indicated a laudable dedication and willingness to correct mistakes. Unfortunately, without a sufficient technical explanation for each, these updates worked to erode confidence in the good work of the Inmarsat team and their collaborators.

      -Bill

      1. Bill,
        I agree with your re-wording of my words. The exclusion of ROC in Inmarsat’s model is something we hypothesized before the new batch of data was released, but we do feel more strongly this is the case now. I am not aware of any other weaknesses in Inmarsat’s model, although it is hard to say for sure because we only have ground-truth for the first 4 points. Indeed we have to assume that Inmarsat’s model is correct in order for us to reverse-engineer the Drift/Offset values we use in our models. This is why it would be very useful to understand how these Drift/Offset values were obtained. If they were determined from other contemporaneous flights, I would feel much more comfortable with their model results than if they were obtained by matching the MH370 data by varying inputs (calibrations) to their model. This is a key question I continue to raise because it strikes at the precision of our (and their) BFO model. It is a subtle point, but it has big implications on our (and their) ability to make precise predictions.
        Victor

  14. The missing entries preceding the first entry shown in the 47 page document (Log-on/Log-off Acknowledge) would show that the plane had first logged on at Class or Level 3 ( capable of telephony services, packet-mode data services and optional circuit mode data services using a HGA) while the log on requests at 18.25 and 00.19 UTC were for Class 1 (packet mode data services only using a LGA). A Class 3 log on would include entries relating to C-Channels, the pertinent part of the Honeywell’s manual is set forth below:

    ” (6)…… The AES initiates the log on procedure by…….. and sending a log on request signal unit…… (8) The AES also informs the GES of the number of C-Channels the AES is equipped to handle, the bit rate/coding algorithm in use on the voice channels and the data bit rate capability for the R channels, P channels and T channels. Except for the number of C channels and the data bit rate capability, this information is repeated in the log on confirm signal unit for use by other GESs. (9) An AES having circuit mode data service capability and desiring allocation of circuit mode data capable channel units at the GES for every ground to air call, informs the GES of the type of interface required. The interface is either analog interconnect or digital interconnect. If the GES does not support circuit mode data service, it ignores the information. If the GES supports the service, it registers the information in its log on AES table and retransmits the information for use by other GESs. (10) The AES supplies the GES with its flight identification number at log on…..” .

    People can draw their own conclusions as to why these entries and the info on RX power, C/No, BER as well as the make up of the Satcom terminal, have not been disclosed to date.

    1. Alex,

      You are simply incorrect in the assertion that the log-on sessions were different, the characteristics of each session are the same.

      The C channel allocation is completed on demand, when it’s needed. See the four SUs at 18:39:52 and the later sequence at 23:13:58.

      A C channel is allocated to an AES in its entirety, it is not time shared with other AES terminals as the P, T and R channels are.

      Many of commenters have tried to help with your understanding of the reference material you obviously have to hand. I’m slightly exasperated that you’re still struggling to comprehend the operation of the satcom system, both conceptually and specifically.

      :Don

      1. Thanks Don. The unfortunate fact of the matter is that there are various facets here that people cannot assist with unless they have significant background knowledge and understanding. That’s why I have kept out of the BFO discussions/analysis, mostly, only supplying things like ground station to satellite distances and speeds for others to use in their investigations. That (the BFO decomposition) is one for the communications engineers to tackle, not me. All of us have limitations: I can’t even run a four-minute mile, or cook a souffle, or speak Russian.

  15. Bill,

    Can i ask how u arrived at the conclusion that the phone call at 18.39 UTC was acknowledged by the SDU?

    I note that it is stated that ” C-Channel messages have no BTO values”. Also the data show a C-Channel was assigned by the GES for both the 18.39 and 23.13 UTC telephone calls but i do not see any transmission from the SDU on the C-Channel following such assignments. Logically such transmissions from the SDU would have a BTO value.

    1. Alex, the best place to have inserted that query would have been as a reply to Bill’s comment. By inserting it as a separate comment Bill might well not see it. Plus it is orphaned and thus confusing for all. OK?

      1. Sorry, will do, I was thinking about posting a wider related question then, about how these BFO values could have come about, if there was no connection made with the aircraft terminal. Also quite strange that some C-Channel entries had BFO values while others do not, in a random sort of way.

      2. Alex,

        Nothing is ‘strange’. The C-channel TX SUs have no related BFO just as P-channel TX SUs don’t. The GES can only measure what it receives.

    2. Alex,
      The lack of a BTO value for the C-Channel entries is simply a fact of the data. The data that is recorded includes all of the relevant fields, including the BFO, and it appears to be consistent with the other data.

      The phone call at 18:39UT in the provided data logs starts with the GES (Perth ground station) using the P-Channel (P#10) to configure the C-Channel {SU types 0x20 and 0x33} (this is described in the communications protocol documentation that has recently been referenced on this site.) Then the AES (airplane) SDU (satellite data unit) responds on the assigned C-Channel (C#6), and proceeds to exchange a sequence of messages back and forth with the GES on the assigned C-Channel as the call attempt progresses. {SU type 0x30 ‘Call Progress – Test’, and 0x60}
      After receiving no answer, the call is terminated, and both the GES and AES properly terminate the use of the C-Channel {SU types 0x30 ‘Chanel Release’, and 0x60, and the P-10 0x30 ‘Channel Release’, and 0x30 ‘Channel Release’} [note: the text in ‘quotes’ is a text description of the subtype of the SU type field, to differentiate the multiple ways that the 0x30 SU type is used.]

      Of interest is that the SDU did not reject the call. If the SDU had hardware indications that there was no on-board physical phone available to which it could route the incoming phone call, then it would have rejected the call. (in the communications protocol, a number of conditions are described in which the call would be rejected with one of the available cause indications – all lines busy, no lines configured, etc.). Unfortunately, the error detection is not able to detect 100% of all possible conditions that would preclude the phone being answered. So, just knowing that there was no hardware indication of a problem at the SDU does not prove that the call rang through, or could have been noticed by anyone on the plane.
      We do not have the details of the data exchanged within the messages visible in the logs. The specific bits that provide sub-type and reason codes in the various progress and acknowledge messages is not provided in the released formatted subset of the ‘raw data’. But, by interpreting the overall sequencing and duration of the call attempt, and the detailed sequence and symmetry of the Test/Request/Acknowledge/status report/Channel Release messages, I conclude that from both the AES/SDU and GES perspectives, the call attempt was normal, just unanswered.

      If you look to the other call attempt at 23:14UT, you can see a much shorter sequence. We lack the detailed status and other indications contained in the many transactions, so I am unable to guess the specific reason for the shorter exchanges. It might be possible that the control center simply gave up sooner, terminating the call sooner. But, it is also possible that either the GES or the AES/SDU provided different details in the responses that changed the progress of the transactions. >> I would like to have the omitted ‘raw data’ to better understand the differences between these two calls.

      -Bill

      1. Bill, brilliantly expressed! Actually the first thing that caught my attention when browsing through this Inmarsat pdf, immediately when it had been put online, was in fact that unanswered call.
        As I am working in the telco business I am well aware of the difference of unanswered call and party not reachable as well as some basic signalling patterns and their interpretation.
        This is – as you explained so well – certainly an unanswered call!
        My first thought upon having drawn this conclusion was, “Gosh. Whoever made this call to the plane, he heard a ring tone and must have realized at that time: the plane has not crashed, it is still in the air!”
        In my understanding this is one more, out of only a few items, which we may assume as kind of confirmed or “most likely”.
        In my humble opinion this may rule out some theories about what was going on at that time of the call, while it raises some other questions.
        I am aware that Inmarsat is only obliged to collaborate with its business partners (in this case: MAS, Rolls Royce, SITA and maybe others involved we do not yet know) and the investigating authorities.
        There are surely NDAs and other agreements in place preventing them from disclosing details or data, which are not their own, without the permission of their business partners.
        However it would certainly be within their policy to answer general questions like:
        – Do you frequently see a disconnection of the Inmarsat link for 1h ?
        – Is the frequent log-off / log-on pattern commonly seen or rather an indication of a serious system failure on board ?
        And, oh yes, the question about how they determined the BFO and how they built their assessment model on it 😉
        However this may be a tough one as Inmarsat itself said their revelations are not designed to assist anyone in reverse engineering their conclusion (or kind of).
        I am not at all though familiar with the other satcom signalling flows and how they are to be properly interpreted.
        There is reason to assume that Inmarsat is knowledgable and its engineers would know or at least can boil down the possible technical problems by the signalling pattern to a limited number.
        Is it possible (or can it be ruled out) that maybe the pilots had to cope with a Flight Management System or Main Console electronic, which suddenly went berserk due to a software bug and that they ultimately tried to get in command again by disconnecting the power to it and reconnecting again?
        Regarding poisoning by CO:
        So, as this is seen as a possible cause, does this mean that there are no CO sensors in the cabin even though the air of the cabin is conditioned by heat exchangers using the exhaust fumes of the engines and any leakage there could also cause hypoxia by CO (e.g. in case of a tiny leak in the heat exchanger) ?

    3. Alex,

      “Logically such transmissions from the SDU would have a BTO value.”

      Logically? Using what process of logic?

      I believe you have the AMS(R)S manual, in that document you will find requirements for both the T and R channels to reply within a specific period on receipt of a P channel frame. T and R channels are time shared; the C channel is not, rather, its allocated on demand to an SDU and so there is no similar timing requirement.

      :Don

    4. The BTO/BFO values are like the crowd singing at a rock concert: take 72,000 fans watching Queen at Wembley Stadium during Freddie’s call-and-response routine:

      youtube.com/watch?v=iZqYOeYUhH8

      All the audience burst out, wishing that Freddie and his microphone on the stage pick up on the sound of the audience singing in perfect unison. Because of the size of the stadium some singers are heard a little early or a little late (BTO) compared to the “average” audience member, and everyone ends up slightly off-pitch anyway, either too high, or too low (BFO) because of variantions in hearing, training and vocal chord stability.

      Everyone sung when they thought would be the right moment, even the mathematicians who had looked up their seat-number knew the distance of the stage from their seat. They just wanted to do what Freddie wanted, and be heard in unison at the right slot—they even forgot about where the theoretical audience member, somewhere in the middle, was. After all it didn’t really matter for the purpose at hand.

      Each of the backing singers had made their own request for a dedicated microphone line (C-Channel) separate from the stadium audience. This meant that the backing singers didn’t have to worry timing: only being on-pitch, and so the sound engineer was only able to note down the frequency error in her logbook (BFO).

      The cleverest person on the day was the train driver speeding past on the Chiltern line through Wembley Stadium railway station. The driver knew the speed of the train from checking the speedometer, and so kept altering the frequency of the train’s horn in order that Freddie Mercury should hear the train horn correctly, even with the effects of doppler. The driver had to not only check the speed and direction of their train, but also to guess where Freddie Mercury would be standing at that particular moment (as the driver couldn’t see into the stadium). Freddie is just not the type of person who can keep still for more than five seconds and is always wandering and precessing back-and-forth across the stage when he should be in the middle. Despite the best efforts of the train driver to correct the frequency and avoid standing out from the crowd, it wasn’t quite good enough: the sound engineer noticed and wrote it down aswell.

      1. Oh no, Paul,
        I like this concert analogy much more than I should admit…
        -Bill

      2. Hi Paul,

        Nice analogy! And the concert promoters (In Main Stadium) just looked on and counted the money! In fact, they made so much money, they decided to give a free concert to help all those concert goers who sang a little bit late or a little bit off tune called the free tracking service!

        Richard

  16. Rekha and Dorothy:
    Thanks for your input regarding starting a petition to get all relevant data pertaining to MH370 released.

    As I noted in the comments after my previous (as opposed to this new one), a suitable short URL for that is:
    http://tinyurl.com/MH370-petition

    However, having just looked at that petition site you have set it up with the wrong target. The JACC is an agency or office of the Australian Federal Government, and is utterly irrelevant here. It is simply not the ‘head office’ for the investigation. That investigation is convened, as it should be, by the Malaysian Government. The Australian Government was just asked to assist with the Indian Ocean search.

    The target should therefore be the Malaysian Government. On the other hand, the satellite-derived information produced by Inmarsat has passed through the hands of the UK Government (per the AAIB). Apart from the satellite-derived information there is also other data derived from, for example, Malaysian radars.

    1. Dear Duncan,

      Many thanks for the tinyurl and review/suggestions. I have now fixed the “To” addressed to the Malaysian government. I found an email on their Call Center not that I expect them to read my email.

      I am conscious of the AAIB angle , let me see if I can petition more than one organization in the same request. Glad to tell you I have got 15 signatures so far, many of them I bet from this wonderful website of yours. In the coming days, I shall try to use other social media promote this.

      And thank you Dorothy, please continue to forward this, we need more people to press for this.

      -Rekha
      Thanks.

  17. The following is the reply by an Inmarsat employee to an enquiry from a member of the media, who asked what information/data had not been released by Inmarsat following comments received (from some contributors here) that the data/information release (the 47pp document) was not complete. Examples given of non-completeness include the first six lines which would show the initial login by the aircraft system to the satellite; information pertaining to the BFO composition; and the model used by Inmarsat engineers to deduce that the aircraft went south.

    ————————————————————————–
    Message content begins:
    The data communication logs that Inmarsat has from MH370 on the day of the flight are complete.

    In terms of the intention of this data release, I think this is explained in an interview our chief engineer did with Richard Quest (link below).

    The intention was to provide detail to enable other scientists to understand the approach, not to directly replicate it. That would require much more information than Inmarsat holds and was also an international effort involving world class experts in every relevant field, as drawn together by the Malaysian authorities.

    http://edition.cnn.com/2014/05/27/world/asia/malaysia-data-five-things/index.html?hpt=hp_t1
    Message content ends.

    1. I find it hard to give Inmarsat communications like this (including much of what McLaughlin has had to say) the benefit of the doubt. No one asked if the logs Inmarsat has are complete. No one asked what was the intention in releasing the data. Meanwhile the question actually asked goes unanswered.

      2. Paul, if I am not mistaken, you analyzed the distributed PDF document and found some deleted data, right? It seems that most of it is more or less redundant messages exchanged at the time of the takeoff. Perhaps this was edited out to make the file more readable… ? I suppose we must conclude that the following statement is accurate: “The data communication logs that Inmarsat has from MH370 on the day of the flight are complete.” Yes, THEY have the complete log, but apparently, we don’t!

        Bryan

    2. Hello
      Quote: “The intention was to provide detail to enable other scientists to understand the approach, not to directly replicate it. That would require much more information than Inmarsat holds” Unquote.

      If this is the case and Inmarsat does not hold all the information, does this mean that they were trying to do what many on here are trying to do and put a jigsaw together knowing pieces are missing? How does that work? Did Inmarsat design the other missing pieces with a Hypothesis ?

      Then we must be all shooting in the dark?
      Maybe I mis-understood, if so I stand corrected.

      Celtickiwi

  18. Thanks Duncan! I am not an expert. My guess is that a lot of readers/stakeholders on this site would like you to lead a plausible hypothesis of where the plane is or where search should be next. This site is by far the best lead for the real answer IMO.

    1. Hi Sophia, and welcome. I don’t think anyone here would claim to be an expert! Just folk doing their best.

      I understand what you are asking, but the problem with adopting a hypothesis for the whole flight is that if one does that, it can blind you to other possibilities.

      But, for what it’s worth, at this stage working on everything that has been discussed on this website, my best guess is that soon after 18:22 (perhaps at near 18:27 UTC) the aircraft’s autopilot took the flight in a broadly southerly direction at around 490 knots and at altitude 35,000 feet (or at least FL350) until it ran out of fuel much further south than the recent Indian Ocean search area. Previous to the above my best guess is that a fire on board (perhaps beginning slowly with the lithium-ion batteries in the cargo hold) producing CO incapacitated the crew and passengers, the crew turning the aircraft westwards in an attempt to get to Penang or another airfield nearby for an emergency landing but they ran out of oxygen or were otherwise unable to effect that landing.

      That is simply my best guess, as I said, based on everything I have seen and heard. There are many things stated that I simply do not take to be useful as ‘evidence’, a pertinent example being any country stating that the aircraft did not fly over their boundaries because they did not detect it with their radars, because I can think of many reasons why it could have been radar-detectable but might have been missed. On the other hand, various people have made claims about radars such as JORN, or sensors at Pine Gap or Diego Garcia, that I have very good reasons to dismiss (that is, on the basis of knowledge of sensor capabilities, I would not expect those to have been able to detect MH370).

      The scenario I described above might have as high a chance as 25 per cent of being correct. (That is not a serious numerical assessment; I am just trying to convey my level of confidence in it not being high, but not being negligible either.)

      1. The ‘I Think I Saw MH370’ item correlates with a fire on MH370 but also suggests a much lower flight level.

        Katherine Tee (aka SaucySailoress) reported seeing three planes in the sky at the same time where one of them appeared to be on fire … she looked away considered taking a picture and looked back again and the plane on fire moved from North of the stern of her boat (boat heading East) to South of the stern and kept going South (Port to Starboard). It was much lower than the other two aircraft that were both heading North at normal cruise levels. She reported being able to see the shape of the plane.

        Two interview questions :

        Q: What did it look like – colour, shape, sound, travelling fast, slow, high/low to the horizon?
        A: It looked like a plane! It caught my attention because I had never seen a plane with orange lights before, so wondered what they were. I could see the outline of the plane, it looked longer than planes usually do. There was what appeared to be a tail of black smoke coming from behind it.

        Q: Anything at all you can remember from that night.
        A: There were two other planes passing higher than it – moving the other way – at that time. They had normal nav lights. I recall thinking that if it was a plane on fire that I was seeing, the other aircraft would report it. And then I wondered again why it had such bright orange lights. They put me in mind of sodium lights. Or perhaps it was a UFO. Or a meteorite.

        Her boat tracking charts / diagrams :

        1: http://www.cruisersforum.com/forums/attachment.php?attachmentid=82132&d=1401546388
        2: http://www.cruisersforum.com/forums/attachment.php?attachmentid=82133&d=1401546388

        One Web Question:

        Q: What do you remember about the relative positions of the two other aircraft? IE. in front of each other, to the side, diagonal.

        A: Higher in the sky, I’d guess at the regular 30000 – 35000 ft. A higher trajectory than them, more than 50ish degrees from me. One looked as though it was directly behind the orange plane from me (at this time this was about 7’clock on my boat’s heading, and we can presume we were heading pretty much on course, cos we were using autopilot) and one was more to the North. Both travelling to the North.

        But I meant less than 50ish degrees. But higher than the orange one, above it in my field of vision, and in the same part of my vision.

        http://www.cruisersforum.com/forums/f108/i-think-i-saw-mh370-127132-5.html

        GPS Tracks : ARE AVAILABLE ON THAT WEBSITE.

        FYI

        Thanks for all the great efforts to all.

      2. Duncan,

        With great respect, what you are suggesting is possible but highly improbable. I would go so far a to place a decimal point and a couple of zeros in front of your probability.

        My understanding of lithium ion fires is that they burn very hot, expand rapidly, and are almost impossible to suppress once they get going. Aircraft made of relatively thin aluminium construction do not fare well under these circumstances and the fact that the aircraft managed to apparently remain airborne and flying for another 6 hours or more suggests that this was a very remote possibility.

        Autopilots do not fly aircraft anywhere. They do as they are told. For the sequence of events that we believe we know happened, the autopilot would have to be programmed to do, or told to do at the time of the instruction. This means that someone either pre-programmed the FMS to do what it did during a serious fire (for unknown reason), or was selecting these commands under a very intoxicated but slightly functional state (hypoxic?) at the time of the flight path changes under the scenario you describe.

        Let’s say the above actually happened. To get to this point, the fire starts in the hold but is not hot enough to set off the fire detection system. In a fairly short space of time it takes out the VHF and HF comms systems, the transponder, and the ACARS system. The satcom system remains intact, as well as the electrical bus that runs it, as do the autopilot and autothrottle systems. The hydraulics and FMS also seem to be unaffected. The crew are partially or totally incapacitated shortly thereafter, but program the FMS to fly to a bunch of waypoints around Indonesia before flying directly south into the Indian Ocean. The fire has been suppressed somehow, but everyone on board is now either dead or incapable of normal functioning. No one thinks to use a mobile or the aircraft sat-phone to alert anyone on the ground to the problem.

        If a fire in the cargo hold was detected, a pilot with the captain’s experience and knowledge of the dangerous cargo on board would have ditched the aircraft into the south china sea without delay. Trying to reach a runway over 30 minutes away on the other side of the Malaysian peninsular would be a suicide mission.

        Yes, I am a pilot but I don’t fly jets for a living. So don’t take my rantings as gospel – just rationally and objectively evaluate the evidence and come to your own conclusions.

      3. IMHO, those who are looking at a “mechanical failure” in this case will be disappointed/ There are simply too many inconsistencies in any mechanical failure scenario.

        Where is the evidence for “fuel exhaustion?” There is none.

      4. Your statement is false, John. The aircraft flew for rather precisely the length of time to be expected given the fuel load on board, and the timings of the last two pings (“partial” or not) are consistent with one engine running out of fuel, and then the other; further, the origination of those pings appears to be the loss of electrical power, again consistent with the engines stopping.

      5. I should add to my comment that I, myself, have been hypoxic. This was done deliberately in a Royal Australian Air Force hyperbaric chamber to enable pilots to experience and identify hypoxia. It was a lot like being drunk – total confidence in my own ability and absolutely no feeling of impairment of such – simple motor skills and cognitive reasoning somewhat absent. But the instinctive drive of self preservation was still totally intact (as it usually is in other forms of intoxication). When instructed to place my oxygen mask on, I was completely and totally aware of what I was doing. This instinct for self-preservation is not discountable. The pilots of MH370 had oxygen available and it would have lasted for hours if used. Admittedly CO poisoning is more insidious – but usually much quicker in rendering you unconscious.

      6. Ray, the information posted quite early on here from airline pilots/captains was that the oxygen supply for the flight crew in the cockpit would last about 20 minutes, and for the passengers a bit less. See an early post by AlainB, a B747 captain, who explained this; and gave a rather vivid description of a possible scenario resulting from a cockpit fire, the crew turning the aircraft west to try to get to an immediate emergency landing at an airport well-known to the captain (Langkawi), and their incapacitation before managing to get the aircraft down onto the ground. Apparently the intent of the emergency oxygen supply is to enable the crew to get the aircraft down to below 10,000 feet where there is adequate atmospheric oxygen content. However, one can imagine scenarios in which this might not be feasible, including a cockpit fire or some form of poisoning (CO poisoning essentially implies hypoxia even with an oxygen supply, because the CO limits the oxygen carriage in your blood).

      8. The possibility of a fire being the “triggering event” is interesting — fires on aircraft are sufficiently frequent to give them added consideration. To fit the facts in this case, a fire would likely have to have two characteristics: sufficient to initiate conditions which incapacitate the crew and passengers, perhaps from CO or other combustion product poisoning, or hypoxia, yet benign enough to allow the aircraft to more or less function normally until it ran out of fuel. Such a combination is initially not too obvious.

        However, one scenario that fits the bill is an event which causes a small-to-modest pressurization leak in combination with the production of some smoke. Perhaps a small quick fire that self-extinguishes doing little or no damage to flight systems and related functions, but does however affect pressurization such as a small crack in the fuselage, or other access point. For the conspiracy fans this might be caused by an explosion but I would guess could reasonably be from other sources. Anyway, a little smoke in the cabin causes the crew to begin an emergency change of course while commencing power shut-down procedures, ignoring for a few minutes the low pressurization condition. Hypoxia starts taking effect and the crew’s actions become increasingly compromised, so much so that after a certain point they become inexplicable.

        Too simple?

  19. Many thanks to Bryan for the link to Part 2 of ARINC 741. Does anyone have a link to Part 1? ARINC 741 is critical for a thorough analysis of the Inmarsat data.

    Don, it is stated in para 4.11 of the doc that in the event of failure in the HGA subsystem, the SDU “should switch to the LGA and perform a log on renewal at Class1″. Class 1 is defined at para 3.0.3.1 as …” a. Receive a P-channel, and b. Transmit a T-channel and an R-channel not necessarily simultaneously at channel rates of 600, 1200 and 2400 bps….. Commentary: An AES with Level 1 capability provides basic packet-mode data communications using one receive and one transmit channel. The initial system does not meet the level 1 requirements for 240 bps transmission. ” [Initial system to be compared to an enhanced/upgraded system down the track].

    The T-channel is requested by the AES but to be assigned by the GES . At para 4.5.3.2.1, as regards such assignment, it is stated that the “GES assigns data channels at the highest supportable bit rate…”. Thus if indeed the log on at 2.25am was a Class or Level 1 log on induced by a failure in the HGA subsystem triggering a switchover to the LGA, the T-channel should still be at 1200 bps, which it was.

    My original point was that all other things being equal, signals that bypassed the HPA and BSUs would have a shorter processing time than signals that had to go through the HPA and BSUs.

    Regarding my previous comment where i listed various info eg BFO, BTO and vz, there is a typo. Under para 4, it should read “z”, not “v”. “z” is the vertical distance of the satellite in km, with the values obtained from Duncan’s post on March 26. (I WILL CORRECT THAT IN THE POST – DS)

    1. Alex,
      HPA = amplifier
      BSU = beam steering unit
      The RF signal would not be ‘delayed’ by either of those components. While the propogation speed of the signal in ‘wires’ is slightly less than free space it’s totally insignificant in relation to the distance AES – I3-F1 – GES. The important timing parameter in the function of the AES is that the R or T channel burst ( a short burst of unmodulated carrier heading the reply frame ) is transmitted within 300us of a P channel frame being received. That’s what the BTO & BFO is derived from, it does not matter whether the AES employs an LGA, IGA or HGA.
      You should find, also, that Class 1 service precludes use of the C channel for voice. Two C channel connection attempts were processed by 9M-MRO’s AES during the second log-on session, after 18:25.
      Now, why was there ever a discussion of LGA vs HGA?
      Early in this discourse there were questions about the Service Bulletin applicable to 777s: that was discounted because there was no evidence of top-mount HGA radome for the SB to be relevant and no-one could explain where an HGA might be fitted: a number of possibilities were considered, none of which were feasible.
      There were questions about whether the signal strength might be something relevant and, therefore, the antenna type might influence that: signal strength wasn’t a factor, burst timing offset and burst frequency offset are the relevant parameters.
      There were questions about so little traffic on the datalink, why was there no evidence of satphone call attempts on the link? On the 30th Apr I recognised the Ball Airlink antenna patches confirming that 9M-MRO had HGAs, yet the Malaysian Preliminary Report still didn’t explicitly mention satphone call attempts and it wasn’t until the Signalling Unit log was released one week ago that emphatic proof of satphone call attempts became clear. The BFO from those signals can add something to the timeline. The Satcom call attempts over the C channel also prove the class of service in use.

      An absolute SDU type identification would be useful to help understand which doppler correction algorithm is involved but airlandseaman and others have some techniques to work around that.

      If any reader is travelling on a Malaysian Boeing 777-200ER, except 9M-MRP or 9M-MRQ, please ask the crew to tell you what Satcom unit is fitted & get back to us.

      If you are travelling on 9M-MRP or 9M-MRQ I trust the SB, now an Airworthiness Directive, has been implemented.

      :Don

    2. Alex,
      I believe that the key here is that when switching antennae, as when switching between satellites, or for any other change to the log-in parameters under normal protocol control ->> the AES would remain logged-in. Changing the log-in parameters is done in the context of the current log-in session. So, the command sequence to modify the connection would look quite different from a new log-in sequence.

      Specifically, as you quoted from the documentation, the SDU must “perform a log on renewal”. This is very different from initiating a completely new log-on request.

      What is seen in the logs at 18:25UT is a completely new log-on being initiated with no preceding log-off transaction. This is being interpreted to mean that the SDU was powered off unexpectedly sometime after the successful communications at 17:07 and before the failed communication attempts at 18:03. (i.e., the SDU was not commanded to turn off or commanded to cease communications, any normal shut-down procedure would have cause the SDU to go through a proper log-off sequence.)

      This is the same log-in sequence (without a preceding log-off) we see starting at 00:19UT. But, in that case, the sequence is different after the first few successful exchanges, when the SDU stops transmitting, and the AES starts sendy queries to see if the AES is still connected..

      -Bill

  20. I have written a summary of the results from the last week. Please let me know what I am getting wrong…

    Both the BTO and BFO values are mathematically abstracted numbers that represent time and frequency respectively. Neither, it turns out, are a simple measure of a physical parameter. Instead, they are each the result of measured signal parameters that are then compared to an expected value – the mathematically derived ‘difference’, or residual is what is logged. This is what has made the reverse engineering a technical challenge that remained open to many varied interpretations.
    For the BTO, the number is a representation of the difference in round trip time to the plane (earth-sat-airplane-sat-earth), and round trip time to a virtual ‘nominal terminal’. There is not indication of the specific ‘nominal terminal’ used, but it has been relatively simple to determine from the data at known locations (at the gate, and correlated to ADS-B recorded specific locations). The remaining surprise/uncertainty is that the algorithms used in recording the BTO make a simplification – the satellite is modeled as a stationary point in the sky, and idealized geostationary satellite. This leaves a slight mathematical ‘error’ term caused by the actual satellite position/motion in the BTO numbers. Backing out this term has been one of the most valuable outcomes of the Inmarsat data released last week. (thanks to Mike, Victor, Duncan, and others)

    The BFO is still a messy algorithm to work through from the limited data provided. In this case, the airplane Satellite subsystem is adjusting the frequency it transmits to pre-compensate for its own movement and orientation relative to the satellite. The complexity has been to determine how that algorithm works. Inmarsat had not published the specific algorithm used by the plane, or the algorithm used at the ground station as it calculates the frequency it is expecting. The BFO being the difference between the two…
    Some clues were provided in the notes that came with the Inmarsat data that have proven helpful. Also having significantly more data points has helped in coming to understand the details of the BFO calculations.
    – To some extent (still being explored if it ALWAYS true) the satellite is assumed to be stationary in an ideal geostationary orbit (like the BTO).
    – The airplane uses its lat/lon location, speed and heading but NOT it’s altitude or rate of climb – to pre-compensate its transmit frequency.
    >>> This is one of the MOST significant new facts to emerge from the analysis of the released data – Since the plane is pre-compensating for most if its own motion, the BFO is NOT a direct measure of the airplane movement (speed&heading).
    Rather, the BFO is a residual, comprised of:
    a) the Doppler effects due to the satellite motion relative to the Perth earth station, and
    b) the Doppler effects due to the satellite motion relative to the airplane), and
    c) the satellite position off of its ideal location (generates an error term in the airplane’s pre-compensation algorithm, and
    d) the Doppler effects due to the vertical velocity of the airplane (rate of climb), … if any.

    There has been significant progress isolating these various terms and correlating the results against both the actual released data, and the previously published ‘projected’ data on the BFO chart and the potential flight paths.

    The team’s results are still not quite matching the Inmarsat published information.

    But, contrast that with:
    1) The Inmarsat ‘Projected: South Track’ only matched 2 of the first 4 data points of the “Measured Data”. And, those are locations where we have exact ground locations and ADS-B data to accurately know the position and movements of the airplane. There is more uncertainty about what Inmarsat was projecting, then there is about what was measured.

    2) Where Inmarsat labelled ‘possible turn’ on the original BFO graph, the released data clearly shows that the extreme BFO values were the direct result of the satellite data unit (SDU), and possibly other gear, re-starting after having been off. It seems the SDU powered off at some unknown time (and for an unknown reason) between 17:07 (last ACARS transaction) and 18:03 (first satellite telephone call attempt that failed – no response from the airplane).
    At 18:25, the SDU powered back up and successfully logged back into the Inmarsat satellite-Perth communications network. The log-in sequence itself exchanged data between the airplane and the ground station. The content of those communications has not been released (or mentioned). But, there was not much data transferred from the airplane, thus it is still believed that the ACARS system and other components that might have used the satellite to communicate were not operating.

    3) The second telephone call attempt from MAS Ops at 18:39UT was acknowledged by the SDU, but did not connect (was not answered). There is not enough information in the released data to know the conditions of the plane’s voice communication system where the phone should have been ringing.

    4) The ‘partial handshake (ping)’ at 00:19UT as seen in the raw data, looks like a relatively normal log-in sequence that exchanged the initial log-in data between the airplane and the ground. The next part of the log-in sequence did not occur. The plane should have sent data after 2 minutes, not no further transmission from the plane occurs. After another two minutes, the ground station starts to query the airplane, but no response is received.

    Work still continues. The list of interpretations and assumptions for details not provided by Inmarsat and the Malaysian investigation body is a cause for concern. It is hoped that further details will be provided.

    So, I’d say the release of a trimmed subset of data, and the work of multiple people on here over the last week has significantly advanced the collective understanding of the Inmarsat analysis.

    -Bill

    1. Many thanks Bill, excellent summary. All should read it (although I recognise that many will say that details are not clear to them due to their own lack of background: that’s fine, but if you read it you will at least get the flavour of what is involved).

      Are there are significant omissions from Bill’s account that anyone else notices?

      1. Dear Duncan,

        just a tiny suggestion making this easier to follow, especially for newcomers: maybe you should include Bill’s summary in the actual post on top to make it more likely people are reading this.

        Thanks to you and the others for this most interesting discussion.

      3. Hi Duncan, Hi Bill,

        This is indeed a very good summary.

        In addition I would also say that the speed of MH370 is a major factor in determining the end point:

        1. Several commentators have noted the linear relationship of the BFO data vs time from 18:40 UTC until 00:10 UTC.

        2. We have aligned the ADS-B data and Radar trace with the new ping rings giving a speed at 18:22 UTC of 470 knots.

        3. Brian has proposed a method for determining the speed between 19:40 and 20:40 giving a speed of 482 knots.

        In general, we are now looking at a path with a fairly constant speed around the normal cruising speed and in a fairly constant direction (until fuel exhaustion).

        Richard

      4. Very good summary, if I might add a couple of points:

        2) After 17:07 the GES still considered the AES logged in, hence the attempt to send that message at 18:03. Even with a failed message send the GES wouldn’t forcibly terminate the AES log-in session.

        3) Two telephony call attempts, 18:39 and 23:13. Upstream of the SDU there is a CTU (cabin telecoms unit) acting as a local telephone switch. Analysis of payload of those C channel SUs would uncover whether that unit was operational, I suspect not.

        4) The GES recognised a successful login at 00:19, with only the channel allocation exchange suceeding. Hence, the final log-in verification check from the GES an hour later.

        The Malaysian attitude to information release has been, at best, haphazard if not ill-advised or worse. Key points were obviously missing from releases in March; the ‘Preliminary Report’ drafted in early April but only released on May 1st with its vague supplements did very little to fill in any gaps. Some of those gaps weren’t filled until 26th May with the SU Log release. It appears that the families group are no better informed than the general public. I’m still aghast.

      5. Do the BTOs really assume a stationary satellite? I don’t remember seeing any mention of this.

        The only stationary satellite assumption I’ve seen is Inmarsat’s comments that the AES terminal on the aircraft assumes a stationary satellite when calculating the L-band Doppler correction.

      6. Bill, Duncan,
        Yes, thanks for that, it’s become difficult to see the wood for the trees especially as I’m out of my depth anyway.

        Regarding: ” The Inmarsat ‘Projected: South Track’ only matched 2 of the first 4 data points of the “Measured Data””
        As you say, it’s probably (mostly) because their model didn’t include the effect of the missing ROC correction in the AES algorithm.

        http://www.duncansteel.com/archives/763#comment-4740

        Which begs the question why didn’t they include it as it would have made their “Predicted South Track” even better matched to the “Measured”? In fact only 2 out of the 12 (the 5th and 7th ) would not have closely matched.

        Regarding these 2, is it the current consensus that these remaining miss-matches can be completely explained by a reboot rather than the “possible turn” theory?
        I am wondering if it might also be one or two brief rapid ROC s such as was suggested in the media (though I don’t remember seeing a reliable source for that)?

        Also, there was an earlier suggestion and discussion (sorry I can’t find it) that the SATCOM did not receive the correct inputs during this latter phase and also that following the proposed reboot the SATCOMs calibration (determined from the BFO when stationary) may have shifted.
        Given that the last 5 measured BFO’s so very closely match the predicted southern track are these still necessary assumption for the southern route?

        I think the earlier suggestion that a re-run (as closely as possible matching all the conditions on the night) should help clarify some of the above. It would probably need more than one, to investigate all possibilities.

        All said and done, am I correct in thinking that the only useful information coming from the BFO data is that it does suggest that the most simple fit is a southern track?

    2. My thinking until now was that the AES self-calculated BFO is part of the raw data packet that is sent to the satellite and hence to the GES. Neither the satellite nor the GES would measure anything in this case and it would not be a residual but an absolute value.
      Had it been confirmed that this is not the case, but the BFO is actually outside the AES?

      1. do1jet,
        “Confirmed” is a bit strong. I’d like to see the Inmarsat team confirm the behavior as we have reverse engineered it from the data.
        I am certain that the BFO is not generated on the AES. It only exists at the ground station.
        – side comment:
        I believe that Inmarsat’s description of the BFO caused much confusion by describing it as a measure of the relative speed between the plane and the satellite. (and maybe too much emphasis on the train analogy in the press blurred the technical message.) In fact, we are seeing very little of the plane’s relative speed showing up in the BFO numbers. Inmarsat needed to understand that to come to the conclusion they did regarding North Vs. South. For it is the dominance of the satellite movement in the BFO values that drives the shape of all Southern routes (well South of the satellite) to be shaped roughly the same (a dip and then rising BFO values. A Northern path BFO line appears as an inverted (mirror image) curve (a bump up, then decreasing BFO values). This understanding is the key to arriving at the conclusion that a Northern flight path is ALMOST impossible. (as I have mentioned elsewhere, still working to understand how much wild flying around would be required to force different BFO numbers along a Northern path to make a BFO curve that would look like a Southern path.)
        The descriptions of BFO, the BFO chart, and how it drove the North Vs. South determination were (are) in direct conflict with what we have found in the data. And to many people who had the knowledge to understand these technical matters, the explanation did (does) not support the conclusion.
        —
        Back to your question:
        The BFO is derived purely by the GES (Perth in our case). The only input from the airplane is the arriving signal from the Satellite- which is simply a frequency shifted version of the signal from the airplane (AES). There is no sideband data exchanged with the transactions.
        On the AES side, the pre-compensation algorithm factors in the airplane’s lat/lon location, attitude and heading (all provided bu the inertial unit(s) through the SDU.)
        On the GES side, the ground station has all of the data regarding satellite position and its own position, and propagation delays between the two. From all of that, through a somewhat ‘opaque’ algorithm, the timing at the receiver is managed to maximize the available bandwidth on the links. When all of that is done, the receiver hunts around within a narrow band, and locks onto the actual received frequency. The BFO is the measure of the remaining error after both ends of the link did there best to minimize the offset.

        -Bill

Comments are closed.