Predicted location of debris in July 2015 from a crash site of 30S latitude along 7th arc
In the past week, there were two serious technical papers released that discuss evidence surrounding MH370 and with implications on where it may have crashed along the 7th arc. The two papers demonstrate that there is still significant disagreement about how to interpret some critical technical data.
In the first paper, entitled “The Probable End Point of MH370”, IG member Richard Godfrey concludes that MH370 most likely crashed along the 7th arc at 30S latitude, which is well north of where the seabed was searched. Richard uses the extensive drifter data from the Global Drifter Program to develop a comprehensive drift model. He organizes and analyzes the drifter data, which includes the position, speed, direction, and water temperature measured by the drifters at 6-hour intervals, and he groups the data by position and calendar month. By introducing an “efficiency factor”, Richard relates the straight-line distance traversed by a drifter over 60 days compared to the total path length calculated from the 6-hour data and integrated over the same 60 days. Richard uses the derived speeds, directions, and efficiency factors to estimate the trajectory of debris that originates from the 7th arc in March. By incorporating the variability of efficiency factor that was experienced by the drifters, Richard calculates and presents the considerable dispersion of debris released from the same starting position along the 7th arc. Richard also relates the predicted temperature history of the debris to the observed barnacle populations on the debris. Richard concludes:
The drift analysis appears to support a probable end point of MH370 around 30°S near the 7th Arc. This fits with a late final major turn south at 19:36 UTC and a flight at the normal cruise speed of 0.84 Mach until fuel exhaustion. There is a good fit to the satellite data and a good fit to a great circle path toward Wilkins Runway (YWKS) as the final waypoint.
The drift analysis also explains the reason why MH370 floating debris originating around 30°S near the 7th Arc could end up in Reunion and South Africa with barnacles via tracks that pass through sea water between 19°C and 25°C and end up in Madagascar, Mozambique and Tanzania without barnacles via tracks that pass through sea water above 25°C.
The second paper, authored by Ian Holland of Australia’s Defense, Science, and Technology Group (DSTG), is entitled “The Use of Burst Frequency Offsets in the Search for MH370”. The paper presents the general methods used to calculate the BFO for reconstructed paths, but the real importance of the paper lies in the conclusions drawn from the BFO sequence at three critical times, which I paraphrase as the following:
The BFO sequence at the log-on at around 18:25Z is consistent with the BFO sequence that was measured for six previous log-ons of the 9M-MRO aircraft after a power down of 35 minutes or more. For MH370, the BFO values starting at 18:25:27Z and ending at 18:28:15Z were 142, 273, 176, 175, 172, 144, and 143 Hz. The decay from 273 Hz to 143 Hz is consistent with the decay in BFO values observed six previous log-ons, while the first value of 142 Hz is not. The author advises us to reject the initial value of 142 Hz because of the lower carrier-to-noise density ratio (C/No) and the non-zero bit error for that data point, which suggests that MH370 was flying at constant speed, track, and altitude during the log-on sequence. It also implies that the statistical equivalence of the first and last values is coincidental. No attempt is made in the paper to reconcile the measured BTO sequence with this interpretation of the BFO sequence (constant speed, track, and altitude).
MH370 should lie close to the 7th arc because the BFO sequence at the final log-on at around 00:19Z is consistent with a steep descent. Two hypothetical cases were considered: A log-on after a power down of several minutes, and a log-on after the SATCOM experienced an outage of communication not related to a loss of power. Considering these two cases, and also accounting for the possible contributions to BFO error caused by the decay in BFO values after a power down and the BFO error caused by drift of the SATCOM’s oscillator, the upper and lower bounds on the descent rate of MH370 were estimated. At 00:19:29Z, the descent rate is bounded between 2,900 and 6,800 fpm. At 00:19:37Z, the descent rate is bounded between 13,800 and 17,600 fpm.
The BFO values at the time of the call attempt at 18:40 suggests the aircraft had already turned to the south. As shown in the figure below, the BFO sequence between 19:41Z and 00:11Z, inclusive, matches a trend line that is consistent with straight and level flight. If this line is extrapolated back to 18:40Z, the author says there is rough agreement with the BFO value at 18:40, which implies that at this time, the plane was already on its straight and level path to the south. The author makes this conclusion despite the approximate 10-Hz discrepancy between the trend line and the BFO value, which is left unexplained.
Measured BFO from MH370 flight showing linear trend
The two recent papers demonstrate two sensible but different interpretations of the same set of data. If we are to accept the conclusions in Ian Holland’s paper, then the range of latitudes of the underwater search area was properly defined, and the aircraft should have been found close to the 7th arc. Why the aircraft was not found remains unexplained. On the other hand, Richard Godfrey, both in his recent paper and in a previous paper he co-authored with me, challenges the assertion that the BFO at 18:40Z unequivocally demonstrates that MH370 was flying south at that time.
As we attempt to explain why the underwater search has failed, the two papers demonstrate the importance of challenging some long-held assumptions. The difference in interpretations of the two authors is yet another demonstration of why it is imperative that the authorities release all the available information related to this case.
Update on 2/18/17: The deviation from the trend line was corrected to 10 Hz.
@Victor
I did email Dr. Holland with my issues, and also asked for the ISAT and ACARS data for the 20 previous flights of 9M-MRO used in his paper.
@VictorI
Yes, 24Hz is not trivial. It could easily amount to a track error assumption of close to 90 degrees.
@TBill: Many people accept that the Indonesian radar stations are not normally operational at night, and this would have been known by the pilot.
@DennisW: Thank you for contacting Ian Holland. Please let us know if he responds.
As for the 24-Hz deviation from the linear trend, one could argue that this proves that MH370 was not flying level at the same speed and track at 18:40Z as the later BFO values suggest, which is exactly opposite to Ian Holland’s conclusion.
@VictorI
“@DennisW: Thank you for contacting Ian Holland. Please let us know if he responds.”
Yes. I will even let you know how he responds unless, of course, it makes me look stupid. Just kidding.
It has long been apparent, even to a relatively unskilled observer such as myself, that the geometry of the flight path around the final turn is critical to a correct determination of the endpoint.
My own view has always been that the endpoint lay somewhat to the North of the official search area and I am glad that skilled people are still actively pursuing the question.
@Ulric: Welcome and thank you for your post.
The plane wasn’t found in the area that was searched. The BFO values at 00:19 say the plane should be close to the 7th arc. That means either the plane is along the 7th arc either to the north or south of the searched area. Go south and you run into problems with fuel and timing of the flaperon to reach La Reunion in July 2015. That means the plane is to the north of the search area. The question is how far north. It will be hard to use only drift analyses to make that determination, so we are obligated to better understand the path between 18:28Z and 19:41Z.
The two sets of findings presented by Holland in Table V and Table VII are very valuable. However, it would be very useful to differentiate further which hypothesis is the more likely.
Briefly, my primary concerns for the analysis are :
1) misconception of BTO characteristics, as is evident in the second paragraph of II. Review of SATCOM Model;
2) a consideration for a trend in BFO measurements over the flight, post 18:25, as in Fig 6. I suggest it’s very tenuous to draw conclusions for a trend, in a parameter that derives from an instantaneous dynamic state, over such a temporal range ;
3) its determination of SDU state prior to the in-flight Log Ons, power cycle or not? Did they even look at the ‘Satellite ID (previous)’ field of the SDU’s Log On Request SU or the GES’ Log On Confirm SU? This data field will show either the Region ID, 00-07, or 077 (octal). If 077, what is indicated by this value?;
4) its comparison of in-flight Log Ons, at 18:25UTC and 00:19UTC, with ground Log Ons, as listed in Table III, Log-on 1 thru 5. The Log On event described by Table III, Log-on 5 was described in previous MH370 material: it was processed by the SDU using the AES Low Gain Antenna signal path at a time when the doppler compensation was idle/ineffective as the ADIRU was not initialised. I suspect the same conditions existed at each of Log On events listed in Table III, Log-on 1 thru 5 (supported by 9M-MRO block times & a/c location as listed in MAS’ records, re RMP Folder 5 Aircraft Records).
5) interpretation of received signal level at 18:25 and 00:19. The SDU issues its Log On request burst using a default ‘initial EIRP’ level to set the HPA gain, subsequently the “AES will adjust its channel unit power levels according to the EIRP value received in [..] the log-on confirm” response. At 18:25 and 00:19 the GES recorded -52.3dBm and -53.7dBm for the received power level of the Log On Rqst burst. It’s to be expected that the GES received power level recorded for the Log On Request burst is ‘anomalous’ to the bursts received during the Log On session. The recorded C/No and BER data do warrant interest but the analysis presents few other similar instances, and the coincident aircraft dynamic conditions, to draw solid conclusions.
Thanks, Don. One comment: You say, “The Log On event described by Table III, Log-on 5 was described in previous MH370 material: it was processed by the SDU using the AES Low Gain Antenna signal path at a time when the doppler compensation was idle/ineffective as the ADIRU was not initialized.” I agree that without the ADIRU, there is no antenna steering capability and therefore the LGA must be used. But since the aircraft speed was zero, there would be no Doppler compensation as satellite velocity is ignored in the compensation algorithm, so I don’t think that affected the BFO.
@Victor:
Having reached consensus that the reasonableness of the ‘descent’ interpretation of the 18:40 BFO is largely a result of once-better interpretations having now been eliminated, please allow me to trot out the oft-cited “lost car keys” analogy:
Suppose you’ve lost your car keys. You have data that gives you 80% confidence that they are somewhere in your 3-room house. You do an assessment of the three rooms, and decide that, GIVEN they are in the house, the odds they are in each of rooms A, B, & C are 75, 20, & 5% respectively. Since you only have time to search 1 room, you search Room A. Not finding them, you reassess.
Well, GIVEN that they are in the house, the probabilities for rooms B and C are 80 and 20%, respectively. But in the larger context, the probabilities were originally:
Not in house: 20%
Room A: 75×80=60%
Room B: 20×80=16%
Room C: 05×80=04%
Having eliminated A, we redistribute the remaining probabilities, and arrive at:
Not in house: 50%
Room B: 40%
Room C: 10%
What is my point? Where you are perfectly justified in assessing relative probabilities between B and C – and Dennis has the right to assert (wrongly) that those probabilities were never determinable – and others have the right to assert (wrongly) that Room A wasn’t searched carefully enough, and should be re-scanned – the fact remains that “outside of the (ISAT) house” has risen geometrically in Bayesian probability.
For some readers, this will be a geometric increase in a tiny number, which results in a number that is still too small to consider seriously. If so, so be it.
But for some of us – many of us, in fact – the number was not so tiny to begin with. Once a ‘second tier’ interpretation of the evidence before us, it has increased steadily over time – especially in light of obfuscation, evidence-hiding, and search dysfunction.
Others may concede this is now a high probability, but would rather we give up the search for our keys, given the vastness of the search area outside our ‘house’. However, I submit that the required places to search are actually quite limited: the suspects are those who had the opportunity to fudge the signal data, by intent or by accident, either before, during, or after its processing by Inmarsat.
@Brock McEwen: In July 2014, we had no recovered debris, and we had no simulator data. Today we do, and the evidence is consistent with a crash in the SIO. Looking at all the facts, I believe that today there is a much higher probability of a crash site in the SIO than in July 2014.
@Victor: since our respective definitions of “SIO” may differ, it is vital to clarify that the debris evidence, by itself, COUNTER-indicates a crash on/near Arc 7. If one does not constrain the debris studies to an Arc 7 impact to BEGIN with, one gets an impact distribution centered far from that arc – much closer to the equator, in fact – and a region of intersection that is distressingly sparse. Looking at this evidence from a purely Bayesian perspective, it serves to reduce confidence in Arc 7, and increase confidence in the “ISAT data is invalid” family of scenarios. (Unless one has already arrogantly set the a priori probability of a spoof or cover-up to zero, being “sure” such things could not possibly happen.)
Yes, we have also been treated to further bits of grainy digital imagery, which some choose to call “evidence”. Since you and I agree these 5th-hand “leaks” support theories both inside (if authentic) and outside (if planted) the house, then I’d expect you and I to agree that they do nothing whatsoever to help us distinguish between the two. The timing and manner of these shadowy images’ arrival on our doorstep is so suspicious – and bereft of accountability – as to make me wonder why anyone would choose to trust them.
Also since July 2014 have been observed several instances in which search leaders have seemed determined to search both shorelines and sea-beds which are COUNTER-indicated by their own data and models. We’ve recorded a large gap between when the ATSB was first informed of the error in GEMS’ study, and when they claim to have been informed. Incrementally, we’ve seen a large gap between the date of this claim and the date the error was finally announced to the public. If shoreline debris, as has been reported, was kindling bonfires on Réunion Island in the interim, then we are looking at a suspiciously appalling dereliction in search leadership’s duty to properly inform the public.
We’ve also seen a 14 month delay between flaperon flotation tests (as confirmed in the recent French documentary) and their results finally informing CSIRO’s drift model. This 14-month delay caused the final 15 months of the search to take place in a place these results say is ruled out. This delay is inexcusable even in isolation – that most of this time was spent searching the lowest-probability outer extremities of the deep-south search box (see next para) makes the decision to stay there even more concerning.
We’ve also seen the search box width extended out wider than either the 00:19 BFO values or @ALSM’s flight sim data can possibly support. Without proper explanation.
I submit that such conduct is more consistent with efforts to minimize search efficiency than with efforts to maximize it.
For these reasons – and others – I believe we need to audit search decision support. Something smells.
@Brock
“What is my point?”
I was wondering that myself.
@Brock
“the fact remains that “outside of the (ISAT) house” has risen geometrically in Bayesian probability.”
Not at all. You are starting to sound like Wise. There is no reason to doubt the ISAT data just as there was no reason to believe you could use it to predict a terminus. The simple truth as I have stated many many times is that the ISAT can only be used to exclude terminal locations such as Bay of Bengal, Maldives, Northern Hemisphere,…
@Brock
OK , you pushed me over the edge with your comments. This investigation has truly become the “Theatre of the Absurd”. I am done with it. Time to move on to other things far more interesting.
Actual empirical results that support Godfreys analysis are surely that the person who found and reported 15 pieces of MH370 debris followed the advice of Oceanographer Professor Charitha Pattiaratchi who said that the most likely crash area was between 28 and 32 degrees south.
@Victor: “As for the 24-Hz deviation from the linear trend, …”.
Is there any reason for the BFO’s to exhibit a linear trend versus time?
Two interesting papers addressed in the current article. Regrettably, not enough time to digest them fully so far..
Regarding the Holland paper two first remarks:
Fig.6; I find the use of the linear trend line tricky, as the BFO is a summation of “non-linear” components, which just happen to give a more or less linear appearance in a certain time interval. I doubt there is a solid analytical base justifying for example extrapolation of the trendline.
Fig. 2; I would very much like to have access to the raw data behind fig. 2. Main points I would like to clarify are related to the strange asymmetric tail of the distribution and oscillator drift characteristics. Concerning the tail: is it possible there has been an eclipse / sat. temperature effect in other flights as well and has it been accounted for?
@Gysbreght: Welcome and thank you for your comment.
@Gysbreght and @Niels: I agree. A straight flight over that duration does not necessarily translate to a linear trend in the BFO. I was simply challenging his assertion that the BFO at 18:40 fits the linear trend he attributes to later points.
@Marion Ravenwood: Welcome and thank you for commenting.
Was Dr. Pattiaratchi’s estimation that the crash occurred between 28S and 32S latitude explained in a technical paper you can direct us to? Or was the comment from an informal conversation with Blaine Gibson? The technical basis for this claim would be of interest.
Dr Pattiaratchi told Blaine Gibson in September 2015 in person which is how Blaine knew where to go. You can of course ask Dr Pattiaratchi for any paper he has on the subject.
@Brock McEwen: Richard Godfrey’s paper suggests that there are crash locations along the 7th arc close to 30S latitude which are consistent with the timing and location of recovered debris. You may disagree with the methods he used in his analysis, but without a doubt his analysis is consistent with the hypothesis of a crash in the SIO along the 7th arc. If you throw out the BTO data, the fact there are many other crash locations that are consistent with the debris data does not invalidate his conclusions. In a similar way, his drift analysis alone does not validate the BTO data. All you can say is one does not contraindicate the other. If both are valid, it helps to narrow the possible location of the plane, which is what some of us are trying to do.
@Marion Ravenwood: By the way, with a pseudonym like yours, you must have a real affinity for Indiana Jones. Are you trying to tell us something?
A question to the satellite experts: Is it possible that a satellite eclipse happened roughly every 24 hours in early March 2014 / could we estimate the time of occurrence on different days before 7 March 2014? As a start March 2nd could be interesting, regarding the example Mumbai – KLIA flight (fig. 5.4 in “Bayesians Methods…”)
Note on 18:40 BFO delta:
The “excess” BFO at 18:40 compared to a straight line fit through the 19:41 – 00:11 BFO data may indicate a change in direction or speed between 18:40 and 19:41.
Here is a plot of the relevant BFO data:
https://drive.google.com/file/d/0BzOIIFNlx2aUejhDU2FjZUlzLVU/view?usp=sharing
My linear fit (the dashed black line) to the offset-corrected (i.e., “calibrated”) BFO data indicates about 15 Hz “excess” at 18:40.
I believe the cause of the “excess” BFO at 18:40 is a reduction in speed between 18:40 and 19:41.
The red and green lines are my most recent route fit with Constant True Heading and Best Holding speed. This uses 4-D weather data and a new post-FMT stepwise path integrator. In this fit the FMT (to 180.0 degrees true track) is completed during the 18:40 phone call while still at LRC. About two minutes later the speed is reduced from LRC to (variable) Best Holding. The TAS drops from ~492 kts during the FMT to 450 kts by 19:41 and then to 400 kts at 00:11. The track after the FMT meanders between 173-185 degrees true due to crosswinds. You can see this route is quite consistent with the BFO data, all the data being within 4 Hz. I should emphasize that only the 18:40 BFO has any significant influence on the best-fit post-FMT route. The dominant constraints then come from BTO and wind. After the FMT, the BFO is simply telling us the plane went south.
@Gysbreght,
Virtually all of the individual BFO terms during this time period show linear trends. These include the Uplink Doppler of the satellite moving toward the aircraft, the uplink Doppler of the aircraft moving toward the satellite, the downlink Doppler, the df(sat) + df(AFC) term, and the df comp term. One should not be surprised that the BFO shows a linear trend since all of its components (except the bias term) show linear trends. This linear trend in BFO would still be present even if the aircraft were stationary.
@DrBobbyUlich: That’s interesting. Thank you for sharing.
@DrBobbyuUlich: The relation between the aircraft groundspeed and the BFO depends on the position of the satellite relative to its nominally geostationary position, which varies with time in a non-linear manner. The BFO is insensitive to aircraft movement when the sub-satellite point passes the equator, and is most sensitive when its latitude is greatest.
@DrUlich
Concerning this linear trend: it is interesting to split the BFO into Fup+Fcomp and Fbias+Fdown+Fsat+Fafc
The first sum is ac motion related, the second isn’t. Both sums I would not fit a linear trendline (it is especially the 1941 value that indicates differently). Perhaps an interesting exercise we could try: To plot predicted Fup+Fcomp for a given realistic straight, level, constant GS path from 18:40 onwards. I would be surprised if the result is linear in time.
@Gysbreght Sorry I didn’t address you. Again your message appeared while I was typing. It seems we agree on this!
@Gysbreght,DrUlich
Please see:
https://www.dropbox.com/s/y0amzgo7ttk1cjw/BFOLinearTrend.xlsx?dl=0
@Niels: “Perhaps an interesting exercise we could try: To plot predicted Fup+Fcomp for a given realistic straight, level, constant GS path from 18:40 onwards.”
I agree that would be a nice illustration of the point you and I are both making.
The linear BFO fit is not a coincidence. It is indicative of a generally consistent path (heading, speed and altitude), either a straight line or one with a slowly changing heading (or speed or altitude or combination thereof) resulting in a path to the South or SSW, with perhaps some small curvature. But it is not consistent with a complex path with several significant turns such as course reversal or circling. That leaves open a wide range of possible end points on the 7th arc, depending on all the variable assumptions we are stuck with.
Remember the case of Steve Fossett. His plane was found in the area first searched within a week after his disappearance, but it was not found at that time. It was found about 1 1/2 years later after exhausting many other search areas without success. After not finding the plane where they first expected to find it, they were distracted by “new theories” that proved wrong in the end. Hikers finally found the plane debris-field and some of Fossett’s remains where they originally expected to find it.
I remind us of the Fossett story because there may be some parallel’s here. The area around S37-S38 remains well supported by all the available data and analysis of other information and circumstances. This first guess remains highly creditable. There is at least a 5% chance it was missed. Let’s keep that and Fossett in mind as we start considering alternative scenarios. (BTW…Steve was a member of the Soaring Society of Boulder for a while.)
All that said, the debris drift analysis is pointing us further NE on the arc, and the plane was not found around S37-S38, so it makes sense to focus now of what really happened between 18:25 and 19:41. The 18:40 BFO values certainly could be the result of a turn to ~186 degrees as originally assumed, or they could be the result of a ~2500 ft/min descent on a continuation of the ~295 heading or it could be some combination of a turn and descent at 18:40. The only other data we have to help sort this out is the BTO values between 18:25 and 18:29. Contrary to what Holland states in his new paper, those values show a significant reduction in radial speed towards the satellite (~330 kts if on a 295 heading). Clearly, something other than only a turn to 186 at 18:40 was going on. What was it?
Correction: “…South or SSW…” should read “…South or SSE…”.
@Marion: yes, work by experts like Dr. Pattiarachi suggest Arc 7 near 30s is consistent with Mr. Gibson’s finds. But if Arc 7 passed near Sumatra – or Diego Garcia – and Blaine asked him where to search in 2016, I expect Chari would have told him to look in the exact same place. I encourage you to try it yourself: pick an impact location at, say, one of the acoustic event detections near the equator on March 8. Run, eg, the adrift.org.au model forward for two years. You will find debris on Madagascar and East Africa. Current-wise, these shores are “downhill”.
So if the task is to determine whether Arc 7 near 30s is indicated or counter-indicated by the debris Blaine found, the answer is “neutral – both on and (way) off Arc 7 near 30s are plausible”.
Now, let’s go beyond the shores you mention, and examine others:
Arc 7 near 30s is inconsistent with zero debris on Australian shorelines by ending 2014. Equatorial-area impacts are entirely consistent with empty Oz shores. This is a critical point.
Arc 7 near 30s is inconsistent with the supposed photograph taken of the “Roy” piece in December 15, on a beach in SA – it would take, according to drift experts, longer than 21.5 months to journey counterclockwise around the IO, and arrive on a beach that far SW. Impact points significantly – SIGNIFICANTLY – more counterclockwise of Arc 7 near 30s are indicated by this photograph. This, too, is a critical point.
So if you look at the full set of debris – and the full set of shoreline predictions with careful attention to the timing of discoveries – it is difficult to escape the conclusion that the debris record counter-indicates the Arc.
And that is before one even begins to consider the ramifications of the appalling gap between what the drift data was saying, and where the search remained to the bitter end (near 39S).
Victor, Niels, ALSM:
Regarding the BFO regressions. I believe there may be a strong (cross) correlation between the compensator output signal + fixed bias, and the GS received BFO value.
There appears to be a nonlinear relationship between the two variables.
I have constructed a non-linear variable bias model (or a input-output model).
I have done some rough estimates based on the Fig 5.4 trend data, and some rough estimates of the satellite dynamics for March 2. I have used YAP’s calculator and had to make some assumptions regarding the data.
For small compensator outputs the transmit frequency (or bias value is about 146 hz). For large compensator outputs the transmit frequency (or bias value is about 168 hz). There is still a random component to the BFOs (+/- 3 hz).
For path re-construction of MH370, I assumed that at 18:40, MH370 was dropping in altitude (~1500 fpm), and continued with the same heading until 19:00 (~10N) when the FMT occurred. Using the above variable bias model and the measured BFOs, and YAP’s calculator, I get a curved path to ~ 20 S 104 E at 380 knots (~ 20,000 – 24,000ft ). (3-5 deg per hour, 180 -> 155 degrees).
I believe, there was a ~ 25 knot wind from 240 degrees. This is most likely a ‘ghost’ flight from ~ 19:00 onwards.
Also note the CSIRO drogued drifter data for 20 S 104 E.
@Greg Yorke: Welcome Greg, and thanks for commenting.
I would be very surprised if the AES bias frequency was dependent on the AES frequency compensation. One is determined by the frequency drift of the crystal. The other is related to the compensation algorithm. Perhaps you are seeing another effect.
Victor:
My description of the ‘variable’ bias model might be confusing.
What I really mean is that there appears to be a deterministic non-linear
error between the measured BFO (transmit frequency ???) value and
the compensator output signal. When the compensator wants 0 hz , the
transmit frequency is correct. When the compensator wants ~ 600 hz,
the transmit frequency appears to be in error by 22 hz.
@Niels
“Concerning this linear trend: it is interesting to split the BFO into Fup+Fcomp and Fbias+Fdown+Fsat+Fafc
The first sum is ac motion related, the second isn’t. Both sums I would not fit a linear trendline (it is especially the 1941 value that indicates differently). Perhaps an interesting exercise we could try: To plot predicted Fup+Fcomp for a given realistic straight, level, constant GS path from 18:40 onwards. I would be surprised if the result is linear in time.”
Anyone skilled in the art would do the calculations exactly as you suggest. The difference between the measured BFO and group of terms you site is what I call the Doppler residual in all my analytics. It only needs to be computed once. It does not change with the aircraft flight path.
The Doppler residual is then the target for the term (Fup + Fcomp.)
As you requested I graphed the Doppler residual computed for my path to the Cocos which was at a fixed track of 169 degrees and a ground speed of 480knots. Draw your own conclusions as to whether or not it qualifies as a straight line. Frankly, I fail to see the point of this whole conversation.
http://tmex1.blogspot.com/2017/02/doppler-residual-fup-fcomp-vs-time.html
@ALSM,
You said: “The area around S37-S38 remains well supported by all the available data and analysis of other information and circumstances. This first guess remains highly creditable (sic). ”
You also said: “The only other data we have to help sort this out is the BTO values between 18:25 and 18:29.”
I would respectfully disagree on both counts. We also know precisely when fuel exhaustion occurred. 9M-MRO was not capable of reaching the 7th arc south of ~35.5 degree S. The combination of high temperature and aged engines adds a penalty of about 8% in fuel (3.2% for temperature and ~4.7% in PDA). It simply could not reach 36S, much less 37-38S. The only speed mode capable of sufficient endurance to match the satellite data is (variable) Best Holding, and its range is limited because of the reduced air speed.
Back in April 2015, when I first proposed the lateral offset manoeuver to reconcile the BTO and BFO data, I came to the conclusion that it is impossible that the plane start at what we believe is the 18:22:22 radar point, travel at any path of constant speed and track, and be within 50us of all the measured BTO values between 18:25:27 and 18:28:15. The BTO values are essentially flat during the log-on interval. Independent of Ian Holland’s explanation of the BFO sequence due to a warm-up transient, a manoeuver of some sort had to occur between 18:22:22 and 18:28:15 in order to explain the BTO. That, or the radar point is bad. It is unfortunate that Dr. Holland did not attempt to reconcile the last the radar point with the BTO and the BFO data and propose a coherent path.
@DennisW
Thanks, Dennis, for this example. As these are “predicted” values (no big error bars involved) I think it speaks for itself. I will work out another example to show what happens if you start the calculation at 18:40.
IMO one point of the discussion is that by defining enormous min/max error bars for BFO as DSTG/Holland seems to be doing and by suggesting linear relations where this is wrong from analytical point of view, indeed BFO becomes rather useless. I feel with all data made available to them, DSTG possibly missed some opportunities.
@Gysbreght,
Here is a plot of all the BFO terms except the constant bias:
https://drive.google.com/file/d/0BzOIIFNlx2aUdk9uRFdBNXc3eVk/view?usp=sharing
They are all fairly linear (i.e., “quasi-linear”) to my eye, but of course some have noticeable curvature also.
@DrBobbyUlich: I can appreciate your argument about fuel endurance, although I question your value of PDA. But another possibility is that the plane was for some period of time at a fuel-conserving speed and altitude (such as FL200 and holding speed) before again climbing and continuing at cruise speed and altitude.
@Victor,
I agree that a maneuver near or shortly after 18:25 is needed to reconcile the BTO and BFO data. I am currently writing up a comparison of the arguments for and against the various theories that have been put forth to explain this. It’s too bad Dr. Holland did not do something similar. I’ll post it late tonight or tomorrow.
@Victor,
You said: “I can appreciate your argument about fuel endurance, although I question your value of PDA. But another possibility is that the plane was for some period of time at a fuel-conserving speed and altitude (such as FL200 and holding speed) before again climbing and continuing at cruise speed and altitude.”
That PDA estimate is derived by me from other (confidential) information provided me by ATSB. I believe it is reliable.
Yes, it is possible that a loiter at lower altitude could allow a reduced time at a higher speed afterwards. However, that still won’t get the plane south of 35.5 S. All of the +/- 40 NM wide area is unreachable.
Bobby: Re your 2 comments at February 18, 2017 at 5:15 pm
You stated “We also know precisely when fuel exhaustion occurred. 9M-MRO was not capable of reaching the 7th arc south of ~35.5 degree S.” I find this statement odd in light of the fact that you insisted the POI was ITVO S40 for a long time before changing to your current opinion. I’m not aware of any fuel or performance data that precludes possible end points NE of ~S39.
Besides, I was not even referring to fuel or 7th arc end points. I was referring to what happened much earlier in the flight (between 18:25 and 19:41). My point was that the only data other than BFO data during that time was the BTO data between 18:25-18:29. Fuel has nothing to do with what happened during this period, but the BTO data clearly shows that the plane did not continue on a 295 heading at 495 kts as Holland claimed. It slowed to something like 330 kts. I don’t claim to know whether there was an offset maneuver or loiter or descent or turns, but something changed during this time. IOW…If we want to figure out where the plane is, we need to figure out what happened during this earlier period.
Re: the “24 Hz error” emphasized in the above chart:
I plotted the 18:39 – 00:11 BFOs from R. Godfrey’s model version 13.1. (I used his single “key point” BFO values of 88 and 88.83 at 18:39 and 18:40, respectively, which I presume are averages of the many values clustered around those times.) I then fit linear trend lines:
Method 1: If I include all data points, I get BFO = 29.26914t – 461.66839,
Where t = decimal time in hours (per the file itself). This yields a linear vs. actual error of 3.3 Hz at 18:39:55.664.
Method 2: If I exclude all pre-19:41 BFO values, I get BFO = 30.89749x – 498.82587. This yields a linear vs actual error of 10.1 Hz at 18:39:55.664.
Which method did the paper use? Seemingly, Method 2: When I overlay the above graphic on my chart, and align the axes precisely, I get a perfect match not only on the BFO actuals, but also on the trend line.
I make three observations:
1) it is irrelevant whether the pattern is linear or not – version 13.1 itself shows that standard flight path proposals predict a BFO pattern which is close to, but NOT linear in time. This is because the BFO is a complex function of both position AND speed relative to the satellite – neither of which are linear in time, even for a flight at constant ground speed. So it seems a spurious exercise to test a fit to something cruder.
2) If you insist on doing 1), you should do it properly, by fitting two trend lines: one including and one excluding the end-point being tested. If the answers diverge materially, you have no statistical basis for concluding anything about whether the end point “belongs” in the set.
3) If you insist on doing 1) and 2), at least calculate the error correctly. Even a cursory inspection of the graph above tells us the error could not possibly be 24 Hz. I’m guessing a basic computational error was made somewhere along the way, and that a corrected version of the analysis will show an error more like the 10 or 11 Hz I’ve computed. Well within the tolerances I’ve heard bandied about over the years.
All data points and charts are available upon request.
(I’m guessing the miscalculation was caused by an attempt to use the y-axis to guesstimate the difference in line heights at 18:40, without noticing that the x-axis intersects the y-axis at ~60 Hz, not zero.)
I estimated 13.8 Hz.
https://www.dropbox.com/s/umfqve8kkqxukfs/2014-12-17_Trend%20Line%20Calibration.JPG?dl=0
@ALSM:
Re: your Feb 18 1:14pm post, last para:
If a plane is at the point & time reported to be the primary radar fix at 18:22 – and it maintains, say, constant 499 KGS, constant FL350 altitude, and constant 291 bearing, then at what rate (in micro-seconds per minute, say) do you EXPECT the BTOs to be dropping over the 7-minute segment between 18:22 and 18:29?
Thanks in advance for your time and consideration.
@Brock McEwen: You are correct that the deviation from the trend line that was shown in the figure should be 10 Hz. I have corrected the figure and the text. Thank you.
Brock:
Using GE to measure the distance from the 18:22:12 point to each of the 7 arcs between 18:25 and 18:29 produces the following pattern. The first BTO value implies about 550 kts, bout all the others together suggest about 330 kts.
https://goo.gl/XOPqEa
@ALSM: It’s not quite that easy. The calculated BTO has to be within the error margin for each BTO data point. For a maximum error of 50 us, there is no way to achieve this with a single line starting at 18:22:17, regardless of the speed and track combination. I’ll try to put something together to illustrate this tomorrow.
@ALSM: thanks.
There are a few error bars to put on that graph, are there not?
I thought we had about 50 microseconds’ worth of error bars to put on each BTO to achieve 95% confidence – and, per our prior discussion, shouldn’t this be even higher for logons (e.g. 18:25), given the incremental estimation and rounding error?
It is also unclear to me whether the 50 microsecond tolerance in the ATSB paper includes ANY tolerance for rounding.
FYI, it looks like the 18:22:12 return is exactly 18.37 hours. Precisely. This suggests we may need error bars on the TIMING of this data point; If the actual time was rounded down from 19.375, for example, the actual time would have been 18:22:30 – fully 18 seconds later.
It looks like the POSITION of the primary radar return may also need error bars. Do we have anything more precise than “10 nautical miles past MEKAR on N571”? If not, this suggests to me it could have been anything from 5 to 15 nmi.
Finally: while BTO error bars relate linearly to “distance to sat” error bars, the translation of these into errors in horizontal position are further magnified the closer a plane is to being directly under the sat. In other words, BTO error matters less for Arc 7 accuracy, but considerably more for positional accuracy near Sumatra.
Given that you are using data points as closely spaced as 6 minutes apart, I suggest we put proper error bars on all data points prior to drawing conclusions. Any speed imputed from such tiny differentials could be dramatically leveraged by a few microseconds’ worth of jitter.
I stand by the estimate. The average of 6 observations is not in error by 50 usec.
@Victor:
I think you’ll find that fitting becomes easier if you put appropriate error bars on the reported primary radar fix.
In the attached, I’ve represented uncertainty of +0.005 of an hour – and +/-5 nmi (converted to BTO microsecs) in the radar data point as a diagonal line running from the minimum to the maximum value for each. As long as a path hits the rectangle specified by that diagonal, it is hard to argue that the path is inconsistent with the (alleged) 18:22 radar return.
In the attached, I’ve used 43 microsecs per the ATSB paper on measured BTO jitter (95% confidence level), plus 10 microsecs rounding error per term in the equation (so, 20 for the logon, 10 for the rest). I then converted a few representative paths into time/coordinate combinations, which I then converted into BTOs using Yap’s BTO calculator.
I can make paths fit at speeds anywhere from 220 to 485 KGS.
I’m not claiming this analysis is perfect – I composed it very quickly. Nor do I claim this is THE way to do such an assessment. Nor am I suggesting that inferring a turn/slow-down from this data is absurd.
I just think readers should have context in front of them prior to drawing conclusions about Mike’s 332 knot claim. He is free to stand by such a claim – as long as he adds “plus or minus ~150 knots”.
https://drive.google.com/file/d/0B-r3yuaF2p72SGxZVnEtMElpcU0/view?usp=sharing
I should have mentioned that the basic track whose speed I varied was per Version 13.1 of R. Godfrey’s flight path model – which had a track of between 291 & 296 degrees over that period.
@ALSM: your trend line will match mine (and Holland’s, it seems though this may be a fluke) if you first add in 2 more BFO data points:
23:14:00.904 = 216.00
23:15:02.032 = 218.20
…per “key points” tab of Godfrey’s V13.1.
@DrBobbyUlich:
You wrote: “That PDA estimate is derived by me from other (confidential) information provided me by ATSB.”
I find it very strange that the ATSB leaks confidential information to private indidividuals. Why is that information confidential?
Having beaten figure 6 of Dr. Holland’s report to death, perhaps we could address figures 7, 8 and 9, i.e Section IV. “Effect of SDU Startup on the BFO”.
This section discusses the BFO drift after SDU power-up due to the warming up of the OCXO. I submit for discussion that none of the log-ons 1 through 6 really supports the log-on 7 shown in Figure 7. The total BFO decay was of the order of 30 Hz in Log-ons 2 trough 5, 65 Hz in log-on 1, and 130 Hz in log-ons 6 and 7. Log-on no.6 on 7th Mar. 12:50Z is somewhat suggestively shown in Figure 9 by drawing a straight line connecting two points that are separated by 135 seconds, and the actual decay may well have been quite different from log-on no.7 at 18:25Z.
@Gysbreght,
ATSB has certain non-disclosure agreements (NDAs)with other parties involved in the search. From time to time ATSB will provide to third parties some “derived” information based on (i.e., derived from) materials covered under their NDAs. In my case they have required me to sign a NDA in order to receive the “derived” information. This prevents me from disclosing that information (under penalty of incarceration). However, in some cases I can use the ATSB information, along with other publicly available information, to derive additional parameter values using my own analysis methods. These I can disclose.
@DrBobbyUlich: Thanks for enlightening me on NDA’s.
@Brock McEwen,
@ALSM,
Extending the radar track at 492 KTAS at 296 degrees true (parallel to N571), the BTO slope is almost exactly -50 microseconds per minute. See this plot:
https://drive.google.com/file/d/0BzOIIFNlx2aUWFFJSXRUR21fRUU/view?usp=sharing
The error bars in this plot are 65 microseconds, but you can pick whatever you want to use.
The red line is the SLOP. The dashed black line is the extended track with no course or speed changes. The dashed blue line is a reduction in TAS to 330 KTAS at 18:23:30. It fits the BTOs fairly well, but this did not happen. First, it is inconsistent with the 18:27 BFOs. Second, 330 KTAS is about the stall speed at cruise altitude.
@ALSM,
Mike, thank you for your comments and questions.
I certainly agree that understanding the 18:25-18:28 data is very important. I will post my thoughts on the various theories later today.
You said: “You stated “We also know precisely when fuel exhaustion occurred. 9M-MRO was not capable of reaching the 7th arc south of ~35.5 degree S.” I find this statement odd in light of the fact that you insisted the POI was ITVO S40 for a long time before changing to your current opinion. I’m not aware of any fuel or performance data that precludes possible end points NE of ~S39.”
I don’t follow that last line about “NE of S39”. Perhaps you might restate it.
My best guess as to 9M-MRO’s terminus has evolved. At first I simply used a straight track and a constant TAS. This gives about 39S. The fit to the BTOs is astoundingly good – too good, in fact, to be true. There are three main issues with this approach. First, you can’t fly a B777 with constant TAS. The second issue is the BFOs. The BFO errors are slightly too large (Interestingly, Holland makes the point that the BFO errors must be positive in the lower half of the southbound track. On this point he is correct, I believe.). The third issue is fuel. Is there enough? First I tried using the Boeing range tables, but these are not very accurate. The best method is to use the LRC Fuel Flow table for the RR engines. Following Victor’s success in creating a fuel usage model using small steps in time, I created my own model. Various refinements have been added over time, including bicubic interpolation, and an ECON model that scales Mach and FF for a given CI from the LRC values. I also added climb and descent FF equations depending on weight and ROC, as well as INOP and Holding tables. Although I entered into fuel modeling in an attempt to justify a 39S terminus, the fuel model indicated this was not possible (by several % in range, even using PDAs of 1-3%).
My next route model used ECON mode and the integrating fuel flow model. That moves the terminus to the NE near the center of the ATSB search area. The BTO and BFO fits here are acceptable. However, I then discovered that Boeing left off some important information in the Rolls Royce Fuel Flow tables that is shown explicitly in the Boeing tables for the GE engines. That factor is the 3%/10C TAT temperature effect on Fuel Flow. This factor must exist for all turbofan engines. ATSB has confirmed to me that the GE factor should be used for the RR engines (it is more a question of physics, not detailed engine design). Now the question is, what were the temperatures on the night in question? The answer is, on average, a temperature 10 C above ISAT for the whole route except for the last bit south of about 30S. My fuel model computes the average temperature effect as 3.2%. This result makes the routes to 37-38S infeasible. They have good fits to BTO/BFO but there is insufficient fuel to get there. That is, fuel exhaustion will occur prior to 00:17. That result effectively eliminates most of the +/- 40 NM wide search area.
The next fuel effect is the PDA. Based on info I have received from ATSB under a NDA, and other information I have, I have estimated the average engine PDA in cruise as 4.7% +/- 1.5% maximum error. I was also quite surprised to find out how different the engines are.
Now, including the temperature effect and the new PDA estimate (which combined results in 8% higher FF), here is what my fuel model predicts:
https://drive.google.com/file/d/0BzOIIFNlx2aUdUMyczdwbFcwZGs/view?usp=sharing
This plot demonstrates there is insufficient fuel to achieve the known endurance (to 00:17:29 flame-out) at LRC, MRC, and even Fixed Holding speed. Only the variable Best Holding speed mode has sufficient endurance.
There is one, and only one insofar as I can tell, single-FMT navigation solution (at Best Holding), and that is constant true heading (after EOO/EOR errors) ending near 34S. I am in the process of writing this up.
In the spirit of what Brock McEwen suggested, I looked for a straight, steady-speed path that satisfies the BTO and BFO. Recognizing that the BFO is satisfied with a speed of 495 kn and track of 296T, I allowed the initial position at 18:22:17 to vary by 10 NM from the captured radar position, which we estimate as (6.5485,96.3472). Also, the DSTG recommends that the SD for R1200 messages is 29 us, but 62 us for R600 messages. Allowing a 2-sigma (95% confidence) limit, there is a straight path that meets the criteria starting at (6.5723,96.5122) at 18:22:17. But again, it requires a 10 NM tolerance on the radar position. It also assumes, of course, that the BFO excursion is explained by the power-up transient that Ian Holland describes.
The BTO plot is shown here .
@VictorI
“It also assumes, of course, that the BFO excursion is explained by the power-up transient that Ian Holland describes.”
Please. The power-up transient is horrible flawed i.e. starts with a BFO value that is virtually perfect. You want to discard that as serendipity?
BTW, Holland has neither responded to my questions nor acknowledged them.
@Gysbreght,
I have made a list of reasons why I believe Dr. Holland’s explanation of the 18:25-18:28 BFOs as being due to a thermal transient in the OXCO may be incorrect:
1. The SDU log-on may not have been caused by power restoration. Other causes are possible, including (please correct me if I get this wrong, Don) loss of P-channel synchronicity, and possibly loss/restoration of ADIRU data?
2. Even if the log-on was caused by power loss and restoration, we don’t know how long the power was off. Holland makes an assumption it began at 17:22. What if it began at 18:23? In that case, the thermal effect on BFO would be nil.
3. The low C/N (by ~4 dB I think) may be affected by design for the first log-on transmission. Does the SDU receive a measured value of the received power at the ground station when it replies? And then does it adjust the transmitter power to raise it on the next transmission (the log-on acknowledgement) if it is a bit low? My point here is that this may the normal course of events, not an indication of a problem.
4. Two of the log-ons in Table III (#1 and #6) also had non-zero BERs, but they were deemed trustworthy by Holland, while #7 was not. Why is that? It seems that their (#1,#6) BFOs were considered valid because they “did not appear to be outliers”, whereas #7 was discarded because it did not match expectations. This subjective editing can lead to confirmation bias in the result. I say keep them all or throw them all out.
5. It appears to me (and we need to query Dr. Holland on this point) based on the lengthy power outages, that all the log-ons #1-6 were done when the aircraft was on the ground. Only #7 was with the aircraft flying. That may be important in understanding the 273 Hz.
6. There appear to be two unique features of #7 not shared by #1-6: (a) #7 was in the air, and (b) #7 had a log-on BFO 135 Hz LOWER than the log-on acknowledge BFO. All the others (#1-6) had log-on BFOs that were 0 to 12 Hz HIGHER than the log-on acknowledge BFO. Why is that? I submit it is because the ground-based log-ons #1-6 did indeed show the transient thermal warm-up effect, but #7 did not. The ONLY evidence for a possible transient thermal effect in #7 is the 273 Hz BFO at log-on acknowledge. All the other BFOs are fully explainable with the lateral offset maneuver. Could there be another issue affecting only the log-on acknowledge BFO, and then then only noticeable in flight?
7. Implicit in Holland’s analysis of the 18:25-18:28 BFOs is the assumption that there was no change in course, speed, or altitude from the 18:22 values. We know this is not true because of the simultaneous BTO data which indicate a significant course change (which is best fit by a lateral offset maneuver). Taking the offset maneuver into account for the BFOs, there is only one difference needing explanation, and that is the 273 Hz. I believe this odd result is caused by a different effect than a thermal transient in the OXCO, one that manifests itself when the aircraft is flying (perhaps a difference in how the frequency compensation term is calculated). I also note that the frequency compensation term drops by 80-100 Hz in 7 seconds during the first right-hand turn of the SLOP. Using the log-on request value of frequency compensation would INCREASE the measured BFO at log-on acknowledge by 80-100 Hz. That’s not quite there, since we need an increase of 135 Hz to get to 273 Hz, but it’s in the ballpark. You need a 9-10 second latency in the log-on acknowledge frequency compensation to get a +135 Hz error at 18:25:34.
@DrB
“2. Even if the log-on was caused by power loss and restoration, we don’t know how long the power was off. Holland makes an assumption it began at 17:22. What if it began at 18:23? In that case, the thermal effect on BFO would be nil.
3. The low C/N (by ~4 dB I think) may be affected by design for the first log-on transmission. Does the SDU receive a measured value of the received power at the ground station when it replies? And then does it adjust the transmitter power to raise it on the next transmission (the log-on acknowledgement) if it is a bit low? My point here is that this may the normal course of events, not an indication of a problem.”
Strongly agree with both of your points above.
@Gysbreght,
Oops. For my item 7 above, a latency in frequency compensation would decrease the BFO in a right-hand turn, not increase it.
I suspect that whatever is affecting the log-on acknowledge BFO in flight, it affects both the 18:25:34 and the 00:19:37 BFOs. The latter is also miscorrected by Holland, in my opinion. I don’t disagree that there was a power restoration then causing the log-on. I do object to applying the same transient frequency correction seen with lengthy power outages of many hours to an event where it seems the power was only off for 1 minute. In my opinion (please weigh in here, Dennis), there would be no discernible affect on BFO with only one minute of power outage to the OXCO.
Responding to DrB, February 19, 2017 at 11:52 am:
This is possible but seems unlikely, a) we’re emphatically told that these is no evidence for a Log On via another region (that would have caused a returning Log On to IOR at 18:25), and b) even if ADIRU update had been lost a Log On via the alternate LGA signal path would have been possible.
The AES issues its Log On request over an R/smc channel at a default EIRP. In the Log On Confirm response from the GES, it is advised of apower level adjustment. This process also occurs during a C-channel sub-band signalling. I have charted the RxPwr levels here (note: the tightly spaced sequence of values at approx 16:42 are derived from my transcription of a portion of the SU log from the CNN/Quest Inmarsat interview)
@DrB
Certainly there would be virtually negligible thermal impact. There is, however, some random transient behavior just power cycling an oscillator. It is usually quite small, however. Thermal effects dominate.
To complicate matters further, this is what Inmarsat wrote in the JoN paper:
“5.3. Refinement of BFO Samples. Detailed analysis of BFO samples taken from other flights showed a high degree of consistency for the signalling message frequencies, with the exception of those that were performed immediately after the initial logon process. This called into question the BFO measurements after the log-on sequences at 18:25 and 00:19. However it was also determined (by the same method)that the first message transmitted by the aircraft in the logon sequence, the LogonRequest message, did provide a consistent and accurate BFO measurement. This means that we can use the Logon Request message information from 18:25:27 and 00:19:29, but it is prudent to discount the measurements between 18:25:34 and 18:28:15 inclusive, and the one at 00:19:37.”
Remember also that the 18:25:34 BFO is accompanied by a strange BTO value.
What I don’t understand in this whole story: There is a party who actually designs, builds and supplies the equipment. Shouldn’t they be the ones who would need to understand and explain the behavior of their systems in detail; why leave that to outsiders who have to rely on phenomenological analyses?
Dr.Bobby said, “Even if the log-on was caused by power loss and restoration, we don’t know how long the power was off. Holland makes an assumption it began at 17:22. What if it began at 18:23? In that case, the thermal effect on BFO would be nil.”
We know there was no link at 18:03, so the link was lost at some point between 17:07 and 18:03. It is not unreasonable to assume that was from a power-down.
@DennisW: We have two theories we are evaluating. The lateral offset manoeuver hypothesis does not explain the 272 Hz BFO value. The power up transient with straight flight hypothesis requires a coincidental “good” value at 18:25:27 and inaccuracy of what we believe is the last radar point. Regardless of my own thoughts, I’m trying to give a proper airing to each theory so people smarter than me can weigh in.
@DrBobbyUlich: What is your opinion as to why the ATSB recommended a search area that is not possible from fuel considerations?
@DrBobbyUlich: Thank you for your list of reasons. RE your item 2 Inmarsat reports that the AES did not respond to the GES at 18:03:41Z.
@Victor:
I like your approach: back-solve for implied primary radar imprecision, and noodle over its reasonableness.
I note you are still treating the TIME of the alleged return as accurate to the second. I have no way to judge how this may have been originally recorded; nor have I spent much time scanning the record, looking for confirmation of precision.
All I’m qualified to say is that a time expressed as hh:mm:ss converts to decimal hh.xx000000 only once every 36 seconds. This would seem to me to be long enough odds to at least wonder whether the reported precision might be analogous to the “16.1 km south of Brainerd” effect; we all know what the quote was before the editor’s conversion software got a hold of it.
IF the primary radar was originally recorded merely as 18.37 hours, then your vertical line representing the the radar fix on your graph should be so “thick” as to cover a 36 second span. If the recorded time was rounded, this 36-second-wide line is centred on 18:22:12. If it was truncated, it is centred on 18:22:30.
This might significantly reduce the required error in position.
The other thing to explore is heading. I get that the N571 reference is generally thought to pin this down – but it would be interesting to see how a 15-degree sensitivity test in each direction affects the 10 nmi required error.
A few comments on the thread.
First, I agree with Victor’s chart above showing how a theoretical 10 mile (or 2 minute) error in the last radar point could be consistent with a continuation of the radar derived 505 kt speed at 295 degrees. In fact, I sent an email to Victor yesterday noting that observation. However, I don’t believe there was a 10 NM (or 2 minute) error at 18:22:12 because all of the radar points from 18:02 to 18:22 show a consistent pattern and nearly constant average speed of 505 kts. Are we to believe that all of the radar points are off by two minutes? The 18:22:12 position may be off slightly, but I have a hard time believing it and all the rest were off by 10 NM. This is what leads me to believe the RADIAL speed slowed. Some readers may have missed the point that I was referring to radial speed (speed component roughly toward the s/c at 295). A significant turn from 295 could also have caused the 7 arcs between 18:25 and 18:29 to indicate a reduced (radial) speed. Put another way, I was never arguing that the aircraft speed must have slowed to 320 kts. I was arguing that there must have been some maneuver, either slowing or turning, to explain the apparent drop in radial speed.
Second, concerning the report that a few transmissions were recorded with a non-zero BER and slightly lower C/N0… it turns out I have some direct experience with demod design for thin route satellite communications systems, including the design of the first GOES DCPRS demod’s (circa 1975) with performance monitoring capability to record the “BFO” and C/N0 for DCPs. (We installed some of these at the Inmarsat GES in New England back in 1984). Over all my experience, I have never observed a case where it was possible to get carrier phase-lock, bit sync, and frame sync…all prerequisites for demodulation and a BER test, and not get an accurate frequency measurement. The fact that the BER was non-zero and the C/N0 was 4 dB lower might introduce some small frequency measurement error, but nothing significant. The instantaneous LO frequency can be off no more than the tracking BW of the carrier tracking loop, typically 5-10% of the symbol rate. But that instantaneous worse case error is averaged over the packet time (~.5 sec) to produce a BFO value. Bottom line, I don’t believe a non-zero BER or low C/N0 value means that the BFO value is bogus. If the packet was demodulated, regardless of the BER, the BFO value should be within 1-2 Hz of what it would be with high C/N0.
Regarding:
Don Thompson says:
February 19, 2017 at 12:27 pm
Thanks for the plot Don. One comment worth noting: It is very unfortunate that Malaysia has redacted the C/N0 data contained in the original Inmarsat log. The receive signal level is the only data we have, but it is not 100% equivalent to C/N0. The reason is that the transponder gain in an SCPC system may change with loading (number of carriers present). If the transponder gain changed over the flight (some transponders react in real-time using an AGC feedback), then the GES receive signal level can change while the C/N0 remains nearly constant. It depends on the which link is dominant, up or down. Typically, the C band links will be operated at a high enough S/N that they contribute very little to the composite end to end C/N0. In other words, the inbound uplink C/N0 at the transponder is preserved in the relay to the GES. So as the transponder loading changes, and the transponder gain is adjusted to prevent the transponder from going into saturation, the inbound downlink (C band) power per carrier goes down, while the C/N0 stays nearly constant. I will try to find out if the I3F1 transponders have AGC.
@Brock & @ALSM: The reason I chose 495 kn and 296T is because that it is based on prior speeds, aligns with N571, and it fits the BFO almost exactly. Of course, this could all be a coincidence. If we relax the required match on the BFO and allow the track to vary, we can follow a path at 495 kn and 319T, which does not require any adjustment to the radar position to match the BTO. As the radial track is close to 82-262 and the tangent is 172-352, turning to 319T will reduce the slope of the BTO but increase the BFO, which produces a BFO deviation of about 13 Hz from the measured value.
@ASLM said, “I don’t believe there was a 10 NM (or 2 minute) error at 18:22:12 because all of the radar points from 18:02 to 18:22 show a consistent pattern and nearly constant average speed of 505 kts. Are we to believe that all of the radar points are off by two minutes?”
Unfortunately, we can’t be sure of that radar data between 18:02 and 18:22, as Malaysia has never acknowledged the radar data in the Lido Hotel slide, and never supplied that data to the ATSB. The ATSB says that the capture at 18:22 is of questionable accuracy. This again highlights the importance of releasing all radar data.
Dr.B,
The IG sought information from ATSB on the engine PDAs very early on. Unfortunately nothing was forthcoming. It was expected at that time that the PDA information may have helped determine which engine might have failed first. Later information enabled the answer to that question to be determined without resorting to PDAs.
At that time however, advice from experienced B777 captains suggested that PDAs might fall in the range of 2 to 3 %, and that 5% would be regarded as extreme. The PDA relates to an individual engine ( not the aircraft), and is used during flight planning to determine the additional fuel that ought to be provided for that engine compared to a nominal new engine. The PDA would be expected to increase over time as the engine aged, and depending on manufacturing tolerances and maintenance in service. It is an allowance that might apply to the typical engine power requirements for a typical flight profile, i.e. At different power settings one would expect the differences in fuel flows to be accentuated or diminished.
It surprises me therefore that you find that the average PDA, at 4.7% in cruise ( averaged for both engines, and at a reduced power setting) to be right at the upper end of the normally expected range.
Question for pilots: assuming ~490 KTAS and ~FL350, and flight near the equator, what is a typical range of KGS fluctuation due to fluctuation in wind speed?
Question for those who have studied wind speeds March 7 at 18:22 UTC in the Malacca Strait between FL300 and FL400 particularly strong/light? Intermittent/steady?
@ALSM: thanks for clarifying what you meant by radial speed. I was once told the Factual Information report failed to actually list any radar returns other than the one circa 18:22. Are you referring to values graphically estimated from the Lido Hotel image? (Apologies; I’d simply deferred to IG expertise in 2014, and had trusted their “it all dovetails together just fine” assurances, so I’m afraid I’m playing catch up, here.)
As promised I’ve made a BFO calculation of a straight level constant GS path, from 18:25 to 00:11. It goes straight south at 93E (I did not care about BTO fit). As you will see the two sums (Fup+Fcomp) and (Fdown+Fbias+Fsat+Fafc) are strongly curved as a function of time. The resulting BFO curve has a linear appearance (IMO a coincidence for the specific time and location of the accident flight), except for the 18:25 point. The suggestion from this calculation is that the 10 Hz “error” in the graph from Dr. Holland’s fig. 6 could perhaps be explained as a “normal” aspect of a straight and level flight path, related to the strong curvature of the (Fup+Fcomp) graph for times around and before 19:41.
https://www.dropbox.com/s/onixm0e5stgogyn/BFOstraight180.pdf?dl=0
@Neils
Your plots look virtually identical to mine. I updated my posting to include a second order fit to the Fcomp + Fup. Also added the same data as Holland’s Figure 6. Nothing remarkable there. I agree with Victor’s estimate of ~10Hz at 18:40.
http://tmex1.blogspot.com/2017/02/doppler-residual-fup-fcomp-vs-time.html
@Neils
As a sidebar starting at 18:25 as your data does imparts significant curvature which reinforces ALSM’s heuristic that straight paths would tend to have a fairly linear BFO signature. The aircraft was heading at ~295T at 18:25, IMO.
@DennisW
Would have been nicer to start at 1840 indeed. I was a bit lazy: didn’t have the sat. vel. & pos. at hand for 18:40..
Agreed that for the specific conditions (after 1941 and for a flight into the SIO on March 7 2014) the heuristic seems to work quite well. One should be careful with the reverse: we know there are strongly curved paths that fit to the same BFOs as well.
@Neils
I have avoided noodling what occurred between 18:25 and 19:40. Could be a lot of different things, and you have heard them all. Having said that, if I were forced to venture an opinion it seems like a turn South was in progress at ~18:40. 220T to 225T at a ground speed ~490 knots lines up fairly well, although it produces a 19:41 position further South than I would like. I really want Victor’s version of events to work out.
@Brian,
Thank you for commenting on the PDA value. I, too, was surprised by how bad one engine was, but they have 40,000 operating hours and we seem to agree that the PDA will not be smaller than 2-3% in the best case. I can’t say how different they are in cruise, but it is no surprise the right engine ran out of fuel fairly long before the left. You may recall the ATSB statement:”Analysis of the expected fuel load has determined that this event occurred up to 15 minutes prior to the left engine flaming out.” You can do the math to convert 15 minutes differential flying time to (up to) 3.5% difference in the L/R PDAs. By the way, my fuel model includes allowances for the difference in L-R engine PDA in cruise so it predicts the onset of INOP as well as fuel exhaustion. In addition, I have concluded that the differences in take-off and climb FFs (< 2%) is apparently not an accurate indicator of relative cruise FFs.
It is likely that the right engine flamed out before 00:11, and that a slowing followed by a descent was underway, since a B777 cannot maintain altitude above FL290 on one engine. No significant ROD is seen in the 00:11 BFO, so I suspect the first few minutes before 00:11 were a slowing and the descent did not begin until after 00:11 and it certainly was well underway before 00:19. My modeling of the slowing prior to 00:11 indicates the impact on the average leg speed (over that 90 minute leg) is actually small compared to the tailwind error.
@DrB
“It is likely that the right engine flamed out before 00:11, and that a slowing followed by a descent was underway”
The ISAT data supports that notion as well. A negative ROC is indicated to be occurring at 00:11.
@Brock Mcewen,
Here is a link to see the 18:00 winds at FL340 (250 hPa) on 7 March 2014:
https://earth.nullschool.net/#2014/03/08/0000Z/wind/isobaric/250hPa/overlay=temp/equirectangular=100.55,0.52,990/loc=96.300,6.600
Just click on the screen to see the wind and temperature at any desired location.
@Victor,
I don’t know what to think about why ATSB has searched in a zone the aircraft cannot reach. I am fairly sure they depended primarily on Boeing to estimate endurance and range. Either I am wrong, and Boeing got it right, or the other way around. It’s too bad those Boeing range calculations (I mean the method used, not just the result) have never been published. You can always do a fuel model and see if you agree with me.
Here is a back of the envelope calculation anyone can do with a calculator to confirm my results:
Assume LRC at FL350:
From the Boeing table for new engines at ISAT, LRC Fuel Flow is 3372 kg/hr/eng at W = 220 MT, 3085 at 200 MT, 2770 at 180 MT, and 2449 at 160 MT.
Next interpolate to get the FFs at the 17:07 and 00:17 aircraft weights:
At 17:07 the Fuel Load was 43.8 MT, the aircraft W = 218.17 MT, and FF = 3348 kg/hr/eng.
At 00:17 the Fuel Load was zero and the aircraft W = 174.37 MT, and FF = 2679 kg/hr/eng.
Next assume the Fuel Flow is a linear function of aircraft weight. You can plot the first list of numbers above and see that it is linear within ½%. This makes the calculation easy. All you have to do is average the starting and ending Fuel Flows.
Now calculate how long you can fly with 2 new engines using the average of the starting and ending Fuel Flows:
Predicted Endurance =( 43.8 MT*1000 kg/MT) / (2*AVERAGE(3348,2679) ) = 7.27 hours.
Measured endurance = (24:17 – 17:07) = 7.167 hours.
Thus Predicted endurance = 1.4% higher than Measured Endurance, but we still have to correct for the temperature effect by subtracting 3.2% for ~10C average above ISAT:
Predicted Endurance Corrected for temperature effect = 1.4% -3.2% = -1.8% = Average engine PDA to achieve the known endurance (it is negative, meaning you need an engine more fuel efficient than a new engine, which is infeasible).
My PDA plot I posted using the full-up fuel model shows the same -1.8% PDA for LRC at FL350. Since the 9M-MRO engines have an average PDA of about +4.7%, the difference in average fuel flow is 4.7 – (-1.8) = 6.5%. That is, you need a speed mode that is about 6.5% more fuel efficient than LRC in order to match the known endurance.
This all seems very straightforward to me now (3 years on). I really don’t know how Boeing got it so wrong. Perhaps they started out by trying to bound the maximum range and assumed new engines and forgot to include the temperature effect.
All you need is one table from Boeing, a rough idea of the temperature, a knowledge that the Boeing table lacked the footnote for the temperature coefficient (that is the one thing that took me the longest time to discover), and a calculator, and you can demonstrate that the normal cruise speeds cannot match the known endurance. LRC falls short in endurance and range by 6.5% (that’s roughly 200 NM).
If anyone can find fault with this result, please let me know why you think that may be the case.
As I said earlier, ATSB has also confirmed to me that the GE temperature coefficient is appropriate to use with the RR engines.
ALSM,
To accompany that earlier chart, another showing RxPwr vs C/No for the burst sequence around 16:42.
The required C/No (dBHz)for the 1200bps R and T channels is 38.1 to 36.0dBHz.
The R/smc channel used to initiate the 18:25 Log On was IOR-R600-0-36E1 (1646.6225MHZ), if there was a servicability issue on that specific CU demodulator to cause high BER on all received bursts CU I’d certainly expect Inmarsat operations to notice it.
@DennisW,
Thank you for confirming the impact of 1 brief (1 minute) power outage on the BFO would be begligible.
@Gysbreght,
@Victor,
Thanks for reminding me about the failed 18:03 communication attempt.
@Don,
Thanks for the additional details regarding the 18:25 log-on and the plot of received power. My take on it was that all the BFOs prior to 18:25 had even lower power levels but yet provided reliable BFOs. Based on that result and on ALSM’s comments, I don’t believe Holland had a good reason for declaring the 18:25:27 BFO as untrustworthy except that it did not match his expectation.
But how can we reconcile the SDU power being off before 18:03 (an assumption), and the appearance that the 18:25:27 BFO shows no evidence of thermal warm-up? Is there any other reason for a log-on at 18:25 besides a power restoration, or is there any way the OXCO could have been powered up for several minutes (not one) before the log-on request message went out?
@DrB
“But how can we reconcile the SDU power being off before 18:03 (an assumption), and the appearance that the 18:25:27 BFO shows no evidence of thermal warm-up? Is there any other reason for a log-on at 18:25 besides a power restoration, or is there any way the OXCO could have been powered up for several minutes (not one) before the log-on request message went out?”
I have been wracking my brain over that question for some time now. The accuracy of the 18:25:27 BFO and then the following warmup signature is vexing. I have no good ideas. I wish we had the benefit of the study Holland refers to (several times). Maybe it would not clarify, but I would like to see what is concluded.
@DrB: If the PDAs are as high as you think they are, it is almost certain that the plane was flying at slower speeds than LRC for at least portions of the flight after 18:22, and the search area was wrong (too far south). As for temperature effects, it was Barry Martin that first advised me and others to use the GE temperature correction for the RR engines, and also to use TAT instead of SAT in the correction formula.
Can you please help us to better understand how you estimate the PDAs? I know you say you are under an NDA, but surely you can tell us more.
DennisW:
I don’t think it is a mystery how the first BFO observation following a cold start could be close to the steady state BFO frequency. The 3rd order PID thermal control loop causes the frequency to “overshoot” briefly. For the OCXO in 9M-MRO, the output always starts from a low frequency, increasing towards the SS frequency as the oven stabilizes, but it overshoots, peaks, then settles down to the steady state frequency. It is not only possible, but likely that the first transmission will happen the first time the frequency shoots through the zero error frequency (actually, a band around the nominal). See the example here: https://goo.gl/HQA8Ju
@ALSM
Sorry, Mike, I am not following your logic. On the other hand, I have had a long day. Will take a longer look tomorrow. Don’t respond until I have had a chance to digest what you are saying.
@Victor. Please can you enlighten me why the R-600 BTO on your chart “BTO at 1825 no SLOP” has a 2-sigma of about 120 while the other BTOs have two sigma of about 50? If we believe that there is a 4600 microsecond offset for this channel (+/- some fairly small uncertainty on the value of the offset) should we not have the same sigma as for R1200 points?
@ALSM,
@DennisW,
If the OXCO warm-up pattern was an initial undershoot followed by overshoot and then settling, wouldn’t we see this in the six other log-ons listed by Holland in Table III and plotted in Figures 8 and 9?
His data do not show this. They show for examples #1-#6 that the log-on request BFO is always 0-12 Hz HIGHER than the the log-on acknowledge BFO 7 seconds later. In other words, the frequency is decreasing with time at the first log-on request BFO. That behavior is totally inconsistent with the 18:25 MH370 data where the log-on request BFO is 135 Hz LOWER than the log-on acknowledge BFO.
@Victor,
ATSB would not provide fuel flow data for individual prior flights. They did provide fuel flows for each engine in cruise averaged over ~25 flights, along with average flight level and average Mach. That’s it, and those are numbers I cannot disclose. I calculated the difference in PDAs from the ratio of fuel flows. Using the ECON speed equation, I then found the average Cost Index from the average FL and average Mach. Then, using the ECON fuel flow equation, I found the nominal fuel flow for ISAT and new engines. Then I assumed the same average temperature effect as occurred on MH370 also occurred on the prior flights. They apparently did not have temperature data they could average. Then I solved for the average engine PDA using the sum of the measured fuel flows. There is some uncertainty in this process (especially the temperature correction), which is why I put a 1.5% error bound on the estimate of the average PDA (an upper limit, not a standard deviation).
Dr.B,
It still surprises me that ATSB will not disclose the actual PDA numbers for each engine. What is so secret about these numbers? They will be known to MAS Ops, and by RR. They are provided to the flight deck crew so that flight plan fuel calculations can be performed. It means that the numbers will also be known by each crew which managed 9M-MRO on recent flights prior to 7 March. It is strange that the numbers were not released with all the other FI data.
Bobby:
If you recall, Brian A and I published some fuel analysis based on the fuel weights as reported in the FI before the flight, and in the 5 minute ACARS messages. Those data indicated a 2.0 % higher Right engine fuel consumption at take-off, but dropping to only 0.8% higher after reaching FL350. The calculations come from the FI fuel data for the accident flight, not hypothetical calculations. How do these numbers square with your results?
Bobby:
Re the OCXO cold start transient:
I believe all of Holland’s data is consistent with the theory that I suggested. Every case is a little different as far as when the first transmission came during the warmup period. In some cases, it happened before the transient peak, while the frequency was going up (including once when it was near the SS frequency on the way up). In most cases, it happened after the peak on the way down from the peak.
The exact time of the first transmission is controlled by an SDU algorithm that requires several conditions to be met (OCXO state, HPA temp, power supply state, etc.) before the the transmitter can be used. Depending on which condition is met last determines whether the first transmission occurs before of after the warm-up transient peak.
@DrBobbyUlich: Did the ATSB explain the source of the fuel flow data? I mean were these momentary fuel flows indicated by the emgine fuel flow transducers recorded at certain intervals, or fuel quantity consumed in a longer period? Did they look at fuel quantities in each tank before and after flight, and fuel quantities loaded between flights per tank?
@DrB@ALSM
“If the OXCO warm-up pattern was an initial undershoot followed by overshoot and then settling, wouldn’t we see this in the six other log-ons listed by Holland in Table III and plotted in Figures 8 and 9?”
Actually I don’t even know where to begin on this bizarre explanation. First of all, we don’t even know if PID control is used. Secondly, we don’t know how the PID controller (if used) is tuned. Thirdly, as DrB points out, none of the other logins exhibit this behavior.
@ALSM would have us believe that an initially cold oven oscillator somehow produces an output that is on frequency, and then attributes the frequency error to an overshoot in the heating control element. The reality is the “decay” or more accurately the return to nominal frequency is a result of the oven responding to the heating element and gradually being restored to its set point.
Good grief. Grabbing a graph off Wikipedia and overlaying it on a frequency response curve is equivalent to concluding that eating organic food causes autism.
http://tmex1.blogspot.com/2017/02/correlations.html
The 18:25:27 behavior remains a mystery to me.
@DennisW, Re your 5:36 pm (19th) posting
While we all know there are many different possibilities for what happened between 18:22 and 19:41 I find it an interesting remark. I’m actually thinking in similar direction.
In recent months I have been working on a procedure to find straight paths using my explicit path generation tool. Basically I try to minimize the variance in track between 19:41 and 00:11 by variation of the 19:41 position. It gives a unique solution: N0.5 degrees at 19:41 and S33.9 at 00:11. Of course the solution is sensitive to BFO errors; under the boundary condition of straight paths this is about 0.8 degree latitude per 1 Hz offset in all Doppler residuals. Interestingly the “0 Hz offset” solution ends in the area indicated by CSIRO’s analysis and in terms of 00:11 position is pretty close to Dr. Ulich’s recent path proposals. I’ll try to post a summary soon.
Going back to you remark: I think that a 19:41 position around N0.5 is fairly consistent with a turn to the south around 18:40.
@Niels
I think your 19:41 position near 0.5N is consistent with terminal locations near 34S. I have been looking at terminal locations closer to 27S which are consistent with a 19:41 position further North. Perhaps Victor et. al. will provide additional insights here. As it stands, I think you are looking sound.
ALSM, Bobby,
Mike describes the conditions that the AES must achieve before readiness to transmit (some level of OCXO stability, HPA temp, etc).
In addition, and asynchronous to meeting those conditions in its internal state, the AES will not transmit its Log On Request until it receives a complete copy of the System Table broadcast from the GES.
The System Table broadcast is transmitted regularly by the GES. Regularly, but not a deterministic rate due to other traffic interleaved on the channel. The minimum period for the complete System Table broadcast is 12 seconds (a 600bps chl is slooo-oo-o-w), so the additional delay to issue its Log On request burst after internal stabilisation will vary from 12-24 seconds.
Neither Holland’s Fig 8 or Fig 9 reflects the System Table update delay but mapping Mike’s reference for freq-time through the OCXO stabilisation does explain the differing slopes that are evident in Fig 9.
Therefore, the rising phase (evident in Table III, Log-on 7) of the OCXO stablisation may not always be reflected in the Log On exchange.
Fig 9 is the wrong ‘match’, the required match is decay slope exhibited during Log-on 1 thru 7, vs typical decay slope for the OCXO.
Don
@all
FWIW, the DST Group did respond to my queries.
First, with respect to the release of additional data, I was directed to contact the ATSB.
Secondly, the lack of stationarity and ergodicity relative to the oscillator behavior was acknowledged, and the use of BFO as a discriminator of ground track angle is appropriately weighted in their models.
Lastly, the initial “on frequency” BFO output at 18:25:27 is considered an outlier resulting from low C/No as stated on page 6 of the Dr. Holland paper.
@all
BTW, I did share the DTSG response with Victor, and asked him to comment on any nuances that I may have missed. It was not a long response.
@DonT
The pedigree of the oscillator in the AES is not known. At least I could find nothing resembling a part number. My understanding is that it is in the single oven temperature compensated class. As such, it is most likely an SC-cut 5MHz oscillator frequency doubled to 10MHz. It is well-known that the physical size required for 5MHz is a very good choice relative to fabrication tolerances, and most very high quality oscillators run at 5MHz for that reason. The SC-cut choice is virtually always used in oven oscillators because the turnover point of an AT-cut is at too low a temperature for oven control use (see link below).
In any case, whether the cut is AT or SC does not matter. Both cuts exhibit higher frequency output at temperatures below their turnover points (sometimes called inflection points). A higher frequency output is consistent with the observed BFO errors in the period following a power restoration event. The PID controller overshoot explanation is incorrect. The higher frequency output is associated with an under temperature condition not an over temperature condition associated with a controller overshoot.
http://tmex1.blogspot.com/2017/02/crystal-oscillator-frequency-vs.html
@DennisW: I think you hit the high points of the response. Although Dr. Holland did not explicitly state it, based on his response, he views the near equivalence of the first BFO value at 18:25:27 (142 Hz) with the last values at 18:28:06 (144 Hz) and 18:28:15 (143 Hz) to be a coincidence.
@VictorI
Yes, I think that (coincidence) is the implication.
I will mention, for completeness sake, that the DSTG seems fond of the term “structured bias”. It appears they apply this descriptor to any process which is characterized by “non-white” noise. In the case of oscillator behavior I would tend to use the more common vernacular “drift”. Some people use the term “random walk”, and while oscillators can be modeled by a random walk it is not completely accurate. Having said that, I use the random walk model all the time.
@Niels and @DennisW: I think you will find that if you start your calculation at 19:41 and ignore what might have occurred before that point, there are many “straight-path” solutions due to the relatively small inclination of the satellite, which leads to near concentric ping arcs, and rotational symmetry. For constant M solutions, the BTO and BFO errors vary somewhat depending on the starting location at 19:41, but many paths are within the error bounds.
@Paul Smithson asked, “Please can you enlighten me why the R-600 BTO on your chart “BTO at 1825 no SLOP” has a 2-sigma of about 120 while the other BTOs have two sigma of about 50?”
I used 2-sigma error bars. From the DSTG Bayesian analysis, p.25: “For the R1200 messages, the empirically derived standard deviation of the measurement noise [wBTO(k)] is 29 μs, and for R600 messages, 62 μs.”
@Niels and @DennisW: I should add that satellite inclination, earth eccentricity, and the wind and temperature fields all contribute to the distortion of the rotational symmetry, but the trend is still there.
DennisW, others
I do understand that the specific OCXO type used in a Racal/Honeywell MCS6000 hasn’t been identified. I’ve been party to a lot of discussion on the issue but there is a typical or common characteristic.
My observation, above, is that Holland attempts to determine a common point for matching/comparing the frequency variation exhibited during each of the 7 Log-ons based on a fixed relationship between the OCXO meeting an operationally acceptable temperature and a delay to the Log On Request or Log On burst from the AES. There is no fixed relationship. Subsequent to the OCXO satisfying the temperature requirement, the SDU must acquire the GES P/smc channel, receive & decode a full System Table sequence(12-26+ seconds), and only then can it transmit that Log On Request burst on the R/smc channel.
The temporal relationship depicted in Holland’s figure 9 is misleading. Without the original data for those events I can only approximate a revised relationship by image edit(very roughly depicted, overlaid w ALSM’s suggested OCXO response curve).
@Don T
I think trying to back into the information you are seeking will be very difficult to do with any degree of accuracy.
As far as the 18:25:27 event is concerned, I am leaning toward Holland’s explanation – a coincidence. There is some temperature below the turnover point where the oscillator will be “on frequency” (see my frequency vs temp link). Perhaps the logon request just happened at that temperature, and then the oscillator frequency increased as the oven brought it back to the turnover point where it became “on frequency” again. I can’t think of any other explanation that makes any sense at all.
@VictorI
Yes, I agree with your comments. That has been my position from just about the get-go. Hence, the appeal of some LNAV scenario such as you proposed or something similar.
Dennis:
Regarding your comments starting with “Actually I don’t even know where to begin on this bizarre explanation. “…
The explanation is the opposite of bizarre. It is perfectly reasonable for anyone skilled in the trade. I’ve worked with thousands of TCXOs and OCXOs. I’ve designed them, purchased them, tested them, and used them in satellite communications equipment over decades. From hands-on experience, I know that nearly all OCXOs have grossly similar thermal control loops. The loop gain and damping factor are always tuned for the shortest time to nominal stability (frequency within a specified error band), which requires a Kp value around 1.0. The general pattern of frequency response is also similar.
Factors such as power, weight and volume budgets vary depending on the mission. These factors can result in different time constants for different OCXO designs, but they all have a little overshoot on warm-up with minimal ringing thereafter. It is just the nature of the beast. That is why I am very confident in the explanation. To me it is obvious what is going on.
I did track down the OCXO part number. Unfortunately, the manufacturer has been out of business for some time and I was not successful finding any old data sheets. It is a 10 MHz standard.
As to ATSB/Holland’s statements, I agree with them, and they are consistent with what I am saying. He states the first BFO value is “untrustworthy”. It is untrustworthy because the OCXO is still settling at the time of the first transmission, IF the last “OK to transmit” condition to be met is the frequency stability flag from the OCXO (sse manual excerpts below).
The following is from the AES Manual:
“The correct operation of much of the internal circuitry of the SDU depends
on clocks derived from the high-stability frequency reference generated by
the oven-controlled crystal oscillator (OCXO). Therefore, it is inappropriate to
perform BITE tests until this clock frequency has achieved gross stability. If
the SDU is powered on after having stabilized at a cold external temperature
(e.g., –55° C), it can take several tens of seconds for the frequency drift rate
to be low enough before the phase locked oscillators (PLO) that derive the
dependent clocks can lock onto the OCXO frequency reference.
The SDU defers testing of sensitive equipment until a positive indication of
settling is detected, or sufficient time passes so the lack of settling itself can
be classified as a failure. Deferral of these sections of POST also result in
normal operation being deferred, including access to the user interfaces
(SCDU, CFDS, and CMT) and all automatic calibration processing.
Consequently, the SDU suspends POST until the SDU detects the first of
the following conditions:
• OCXO heater monitor indicates it has achieved operating temperature.
• Power supply unit (PSU) temperature sensor indicates a reading above
25 °C.
• Channel filter module transmit and receive PLO lock detectors both
indicate that lock has been achieved.
• More than 4 minutes have elapsed since primary power was applied.”
Here is paper describing the typical thermal and frequency response: https://www.dropbox.com/s/ym5i5ncmo8qi0wv/ocxo.pdf?dl=0
@Mike
Sure oven oscillators have a control loop which needs to be considered. My heartburn has to do with the way you are considering it. What you presented earlier (PID response function overlaid on Holland’s frequency graph) is just plain wrong. My assumption, although you did not label it, is that the PID transfer function you presented is for temperature, the controlled variable. The implication being that the temperature overshoot of the control loop is responsible for the BFO error (which is in the direction of higher frequency than nominal).
If you look at Figure 7 of your last link you will notice that for all cuts of crystals, (AT, IT, and SC) the frequency is actually lower than nominal as the temperature goes above the turnover point. That is not what is happening. The action is taking place below the turnover point – the frequency is increasing as the oven controller brings the temperature back to the turnover point. In all of Holland’s plots the trend from turn on is from a higher frequency to the lower desired frequency.
What your original post suggested, and what I strenuously objected to, is comparing a temperature transfer function to an output frequency. It completely neglects an important additional transfer function – that is the relationship between oscillator frequency and temperature.
There is little doubt that what is happening is accurately portrayed in your most recent Figure 7 (and in the similar curves I linked). That is the temperature is trending in the direction from higher than nominal to nominal as the temperature of the oven reaches the turnover point.
In any case, we have a long history of arguing about oscillators and their performance going back to the early Duncan days and the bias error that might be expected over the flight duration of MH370.
My own oscillator background is not in SATCOM, but in GPS and its use in TELCOM, in particular base station clocks. I have struggled with oscillators over a good portion of my career, and characterizing them and tricking them into performing better than the underlying physics has been a large component of that struggle.
@Mike
“temperature is trending…” above should be “frequency is trending…”
@Don Thompson,
If Log-on #7 was in in flight, and #1-6 were on the ground, might that affect (in a systematic way) the relative time from power restoration until the log-on request was transmitted? I’m trying to understand why, if #7 was due to a power restoration, its log-on request BFO is so different from the other examples. If Mike is correct about the temperature controller response, then I think the log-on request for #7 must happen SOONER than for the other examples. Is there any reason to think the conditions for transmitting would be satisfied more quickly in flight than on the ground after a power restoration? Maybe it is just the luck of the draw, but six similar examples without any one showing a lower BFO for the log-on request than for the log-on acknowledge looks pretty systematic to me.
@all,
Does anyone have an explanation as to why the initial log-on at the gate did not show the warm-up transient? Could the SDU have been powered up long enough for the OXCO temperature to settle while waiting for other equipment to provide data needed by the SDU for making a log-on request?
Dennis:
Sorry you are struggling with this. I understand. It is complicated, and in brief blog exchanges, it is hard to communicate everything precisely.
Yes, of course there is a second transfer function. But it is quasi-linear for temperatures close to the set point (deltaF=k*deltaT). Therefore, I tend to refer to the temperature vs. time and frequency vs. time interchangeably wrt the shape of the curves. IOW…the frequency error vs. time curve will always look nearly identical to the temperature error vs. time curve (for small deltaT).
k in the equation above can be positive or negative depending on the crystal cut and the exact oven set point temperature relative to the turn over temperature. As you know, the OCXO designer tries to select an oven setpoint temp that is equal to the turnover temperature to achieve the lowest possible residual error. This is where k=0. But inevitably, k ends up being non-zero and positive in some OCXOs and negative in others, depending on which side of the curve the set point lands on. But it is repeatable in any given oscillator. For 9M-MRO, we know k is positive from Holland’s data. We know that because we know the temperature peaks (overshoots) then decays toward the SS temperature, and we see in Hollands data that the frequency also is dropping with time as the error reaches SS after a few minutes.
Bobby:
The SDU was powered up for hours before the 1600 reboot. The OCXO was stable at the time.
DrB wrote on February 19, 2017 at 10:04 am:
“The dashed blue line is a reduction in TAS to 330 KTAS at 18:23:30. It fits the BTOs fairly well, but this did not happen. First, it is inconsistent with the 18:27 BFOs. Second, 330 KTAS is about the stall speed at cruise altitude.”
On the other hand, the Maneuver Speed at a weight of 210 MT is 220 kt IAS, 328 kt TAS at FL250, ISA+10°C.
The Maneuver speed is also the Holding speed at that weight and altitude, and is also displayed on the PFD along the right edge of the airspeed tape as a minimum airspeed.
@ALSM
I am not struggling at all.
Your statement:
“the frequency error vs. time curve will always look nearly identical to the temperature error vs. time curve (for small deltaT).”
is what I disagree with. Look at figure 7 on page 6 of your last link. Small changes in temperature going above the turnover point produce a lower frequency, not a higher frequency. Conversely temperatures going below the turnover point produce a higher frequency not a lower frequency. There is an inverse relationship between temperature and frequency in the region of the turnover point. You have it exactly backwards. Holland’s data shows a consistent trend from a higher frequency to a lower frequency. That would imply that the temperature is approaching the turnover point from below. It is not the result of a temperature overshoot.
Bobby:
Here is a more complete list of the boot up events on March 7/8.
12:50:xx UTC Cold boot after at least 228 minutes with power off.
15:59:55 UTC Warm re-boot; no power interruption since 12:50:xx
18:25:27 UTC Cold Boot after power off for 20-78 minutes (probably 62 minutes)
00:19:29 UTC quasi warm reboot; power off for ~ 1 minute
Dennis:
OMG! Yes, of course the transfer function is very non-linear over the full warm up temperature range. I was referring to the relationship for very small deltaT (within a few tenths of a degree) AND after the peak. What goes on at a deltaT of 30C is of no interest. We are only interested in what happens after the AES starts transmitting, which means after the deltaT is known to already be very small.
@ALSM
I am not talking about temperatures far from the turnover point which is where the controller is trying to steer the oven. I am talking about small temperature deltas near the turnover point where the change in frequency vs temperature is quite linear and has a negative slope. Look at your figure 7 for god’s sake.
Hi,
Excellent blog Victor.
I pretty much stopped going to Jeff’s site because of the conspiracy theorists.
Is there a way to post equations with Greek symbols in a post or do I have to provide a link to a document in a dropbox?
Thanx in advance.
Dennis:
As stated earlier, k can be either positive or negative for a given OCXO, depending on which side of the exact turnover temperature the set-point temperature happens to be.
Regarding Figure 7, the oven temp was very close to the set point temp at the time of observation 1 (and rising rapidly), thus the coincidental nearly zero BFO Bias drift error then. For the next 6 observations, the temperature peaked around observation time 2, probably within 1-2C above the setpoint and obs 3-7 occurred when the oven temp was decaying toward SS, all probably within 1C of the setpoint (on the high side). Since the temp and frequency were both dropping for 3-7, I define that to be a positive value of k.
@ALSM
“As stated earlier, k can be either positive or negative for a given OCXO, depending on which side of the exact turnover temperature the set-point temperature happens to be.”
That is rubbish.
k can only be negative. The set point temperature is at the turnover point where the change in frequency vs temperature is minimized.
The relationship between temperature and frequency of an oscillator near the turn over point (which is where the oven temperature is normally set) has a negative slope for ALL classes of oscillators as your own reference clearly shows.
I give up at this point.
@VictorI, DennisW
The path generation tool automatically generates paths that in terms of BTO and BFO errors are as good as the input functions (polynomial interpolations to the sparse data points). By minimizing track variance I more or less opt for constant true course paths.
In the reverse procedure it is probably close to chosing the straight path having the lowest RMS (?) BFO error.
It gives a unique solution. The question is how relevant it is. I see two main aspects: 1. Is a constant track a relevant path in terms how the ac could have flown 2. minimizing the BFO errors like this is probably ok if the BFO errors are random with a symmetric distribution. For example oscillator drift may spoil a lot. Therefore my strong interest in having more detailed data and understanding of the BFO errors from the previous flights of 9M-MRO.
Once the BFO errors are well characterized an interesting study could be to “feed” artificial error content into the input function and generate a path or end-point distribution.
As a first step towards this I’m applying global offsets to all Doppler residuals.
Dennis:
The setpoint temp is rarely (if ever) exactly equal to the turnover temp. Nor is it important to get it exact. It’s OK as long as it is within a few degrees.
Manufacturing tolerances are not that exact. Both the setpoint temp for a given OCXO oven and the turnover temp for a given crystal vary slightly from unit to unit. The operating point inevitably ends up slightly to the low or high side of the locally parabolic shaped crystal frequency vs. temp curve. Of course, if the two were theoretically identical, you would be correct. In that case, k=o at the setpoint and the transfer function would be parabolic in shape, not quasi linear. But in real life, they are rarely within 0.1C. The Holland data tells me the 9M-MRO OCXO kad a positive value of k.
@Niels
The BFO errors are random and symmetric from an ensemble standpoint. By that I mean if one were to conduct 20 flights and collect that data, you would get something very much like the distribution Holland shows in Figure 2 of his recent paper. However, any single flight would yield different statistics which is at the root of the non-ergodicity I have mentioned before, and which the DSTG has acknowledged.
As Victor points out, and I certainly agree with, there are an infinity of “straight paths” which can satisfy the ISAT data when the BFO error constraints are relaxed to the values we now know to be representative. I really think the key element in path estimation at this moment is the determination of where the aircraft was on the 19:41 range ring.
@DennisW
Yes I understand the point of the non-ergodicity, however I think we don’t know the “degree” of it. So I would be very happy to see the BFO error vs. time graphs for all previous flights used to construct the distribution function, not just one (fig. 5.4 in the book).
Furthermore, I agree there are “infinite” number of “straight paths” however they all have different probabilities, which could possibly be assigned if we properly understand the error statistics. Shouldn’t we look for the most probable one for a start?
@Niels: Is zero drift the most probable? I am not asking that rhetorically. I don’t know the answer.
@ALSM
I see you have still not looked at your figure 7. There is a broad linear region around the turnover point. Yes, there are many degrees +/-5C typically relative to where the set point can be placed within the linear region. It is never placed near the parabolic region (above and below turnover) of the transfer function.
I have no idea where you are getting the notion that the set point is anywhere the parabolic regions of the temp vs frequency curve.
@George Tilton: Thank you for comment, and welcome. As far as Greek symbols, most HTML tags should work, so you can try that. Or, you can try typing the equation with Greek symbols in your favorite document editor, and the cut and paste into the window here. If something doesn’t work, I can always repair the damage, so don’t worry too much about making a mess.
Dennis:
I am very familiar with Figure 7. You seem to be conflating the OCXO frequency vs. time “parabolic shaped peak” with the quasi parabolic shape of the crystal frequency vs. temperature curve at the turnover point. If you want to reconcile these misunderstandings, give me a call. I think we have exhausted our GB for this subject on this blog.
@Niels
I would run with the ensemble probability distribution computed by Holland, and presented in his figure 2. Most languages have a built in function call for generating random “normally” distributed samples. In this case a zero mean and sigma of 4.3Hz (Holland value).
@ALSM
I can only imagine that we are disconnecting relative to where the turnover point is on the oscillator frequency vs temperature curve. I have labeled my understanding of the term in the link below. The actual curves were taken from figure 7 of your reference.
http://tmex1.blogspot.com/2017/02/turnover-point-ocxo.html
Dennis: No. The turnover point is point B or C in your drawing. The inflection point you point to is the worst possible operating point, where k=max.
@ALSM
Finally we have converged. I knew we had to have been having a terminology disconnect problem.
I agree with what you are saying for OCXO’s, that is the temperature set point is at one of the two parabolic points of the curve. What we are dealing with here (my understanding) is a TCOCXO – temperature compensated oven oscillator. In this design the temperature set point is almost always at the inflection point (what I have labeled as the turnover point in my previous link).
Please take the time to read the link below. It is a short read.
http://www.radio-electronics.com/info/data/crystals/tcxo.php
@VictorI, DennisW
Difficult to say anything about the drift without seeing more data. Fig. 5.4 of “Bayesian Methods” in combination with the distribution function fig. 5.5 raises more questions then it answers.
One could speculate that the drift goes back and forth but a major question is on what timescale. The ensemble distribution can only be applied to the roughly hourly datapoints if the drift goes back and forth at sufficient short timescale.
Another reason to ask for all data is the asymmetry and long negative tail in the histogram. It suggests something has been overlooked in the analysis. I’m thinking about satellite eclipse in some of the other flights (The dip in fig. 5.4 is approx. at the right moment), but obviously this needs further and careful study of all data.
@Niels
I would not be certain that seeing the data from all 20 flights would provide additional clarity relative to your particular question. As I stated earlier, my strong suspicion is that most of these flights resemble figure 5.4, but with smaller overall excursions. I think the flight corresponding to figure 5.4 was probably cherry picked as a worst case. I can see no reason to assume that the bias variations associated with any flight would be symmetrically distributed about the mean value computed at the gate before the flight started.
BTW, I did request that data along with the paper Holland referenced often, “Internal Study Regarding the SATCOM Ground Station Logs”, from the ATSB. We shall if either request is granted.
It is an OCXO, not a temperature compensated crystal oscillator. The TCXO has an operating temperature range, not a single operating temperature. Over the operating temperature range the frequency is adjusted using a network that applies a frequency control signal that is the opposite function as the measured natural frequency vs temp.
@ALSM,
I don’t believe there is any inconsistency in the measured relative R/L fuel flows in take-off, climb, and cruise for 9M-MRO. What is faulty is our expecting a straight line through the take-off and climb ratios to pass through the cruise ratio. The FI did not contain data that allowed direct determination of cruise fuel flow ratio (since there was no fuel report after first reaching FL350). We just fit a line to two points and extrapolated it to the cruise fuel flow. Apparently that is not even close to the correct ratio.
@ALSM, @DennisW,
I have two very simple questions for you, referring to Figure 6 in the Vectron Application Note:
1. Do you thing the SDU warm-up looks like this curve, or could it be inverted? This is basically asking the question of whether, on initial turn on, the frequency rises or falls.
2. On which side of the “peak of the overshoot” (between T3 and T4) do you think the SDU OXCO operates for the log-on acknowledge transmission?
@ALSM, @DennisW, @DrB: Looking at Fig 7 in the Vectron note, if the crystal cut is SC, and if the setpoint temperature is just higher than the turnover frequency (which for this cut is a relative maximum on the frequency-temperature curve), then if the temperature monotonically increases to the setpoint temperature, the frequency will overshoot high as it passes the turnover temperature. The frequency will then fall towards the final value as the setpoint temperature is approached. This frequency overshoot occurs without any temperature overshoot. Perhaps that is what we are seeing.
@ALSM
Yes, I knew an ovenized oscillator was used.
I was lead to believe (cannot find the source with a quick search) that it was both temperature compensated as well as housed in an oven. The idea being that the combination would result in much faster warmup periods to usability with the oven providing the long term stability desired.
@ALSM, @DennisW,
Regarding your discussion of the frequency – temperature curves: Do you have any typical numbers for the two inflection points on the curves ?
(in hz and degC)
To a first approximation – are these curves sinusoidal ?
Are there any other frequency conversions involved ?
For normal operation – if the compensator wants a 500 hz change, what is the required temperature change ?
Also, I noticed in the documentation that temperature control loop indicated Proportional Control only. Without Integral Control – the loop would not be able to completely remove any external temperature disturbances.
Victor:
If you consider the frequency response for the extreme case of a cold starting ambient temperature of say -40C, the frequency may pass through the zero error point (rapidly) 2 or 3 times before reaching the final setpoint temperature. But the AES logic won’t let the TX go until the setpoint temperature is within a small temperature error band (controller has know way of knowing what the frequency error is), probably +/- 0.5C. The temperature control response looks like a classic PID servo response. Thus, it is only for the final 100-200 seconds of the full warm-up process that we ever see BFO observations. By that time, the oscillator is in the quasi liner TC range and the thermal loop is crossing the zero point for the final time.
Greg:
Yes, the loop filter can be 2nd or third order. I’ve used both. In modern OCXOs with embedded processors doing everything digitally, the algorithm can be quite clever. But it is always preferred to have the integrator in the loop, required to zero out all static error. IOW…you need the integrator to compensate for the RATE of heat loss, which varies proportionally with the difference between the set point and ambient. I’m sure the OCXO used in 9M-MRO had the classic analog implementation.
There is no compensation circuit in the OCXO (only TCXO, not used here). The accuracy and stability performance depends only on a good crystal with near zero TC around +75C and a good thermal control system to hold the deck temperature = setpoint temperature precisely at a temperature near the low TC turnover pont.
@Greg Yorke
When you say compensator I assume you are referring to the Doppler compensation performed by the AES. The oscillator frequency itself is not changed to accomplish this compensation. An implementation known as a numerically controlled oscillator or synthesizer is used. The crystal frequency itself is not changed.
@Victor
“This frequency overshoot occurs without any temperature overshoot. Perhaps that is what we are seeing.”
That is possible, IMO.
Dennis,
Thanks for that description. I have been trying to get that info for a long time. Do you have any links for the information on the numerically controlled oscillator or synthesizer ?
Does the numerically controlled oscillator-synthesizer use the crystal frequency error (if any) as part of the algorithm ?
The reason for these questions are,
A have noticed a nonlinear correlation between the transmit frequency
and the AES compensator which has a similar relationship/curve to that of the
frequency-temperature curves that you have been discussing here.
That is, if the AES compensator wants 0 hz there is no apparent BFO error.
If the AES compensator wants 500 hz there is a 24 hz BFO error.
@Greg Y
There is no way to know the actual error of the AES oscillator. I do not have a link for the specific implementation used in the 9M-MRO AES, but Wiki has a good description of a generic implementation.
https://en.wikipedia.org/wiki/Numerically_controlled_oscillator
Dr.B,
“.. expecting a straight line through the takeoff and climb ratios to pass through the cruise ratio”…
We didn’t have that expectation. The ACARS data was used to determine the climb ratio, but the cruise ratio was determined by calculation, knowing the fuel out times, and the approximate cruise duration from after reaching FL350.
If I recall correctly ALSM and I derived numbers independently, and when we compared results there was very close agreement.
Just to be clear, the 0.8% number was the difference in fuel burn while in cruise, and hence effectively the difference in the respective PDAs.
Misc. OCXO background:
Honeywell Frequency Reference Oscillator (OCXO) Assembly 81771-MBE
Honeywell Frequency Reference Oscillator Schematic 81771-WDME
Racal part number 81771-MBE
In a different document…
“4.3.5 Reference Oscillator
SC cut crystal ovenized oscillator manufactured by CQE.”
Also…
“4.3.10 Reference Oscillator
An oven controlled high stability reference oscillator (Racal part number 81771-MBE located
in the Satellite Data Unit) is used as the primary frequency reference for:
• Radio Frequency Module Local Oscillators and Synthesized Channel Local Oscillators
• Modem Sample Rate Clocks
• Voice Codec Bit Rate Clock”
“The crystal oscillator provides good stability versus temperature, power supply voltage and load variations. The output frequency is 10.08 MHz and has sufficient mechanical adjustment range to compensate for ten years of aging. The reference oscillator frequency is sent to the Radio Frequency Module (RFM) where it is buffered and routed to each Modem. The oscillator also outputs a logic signal directly coupled to the SDUs Main Processor Module to indicate the oven temperature stabilization.”
Racal was purchased by Thales in 2002
https://en.wikipedia.org/wiki/Racal
ICYMI…
10.08 MHz
SC Cut
The debate over the OCXO start up characteristics is interesting, but do we even know for certain that it follows a power outage of unknown duration?
Holland’s paper identifies previous Satcom outages of significant duration for 9M-MRO in Table III
– are these peculiar to this airframe
– do similar outages occur on other B777s flying out of KUL
– does 9M-MRO have a longer history of similar outages
– are the outages indicative of some intermittent fault with the Satcom system
– are the outages indicative of a more significant intermittent electrical system failure developing
It’s a pity that no further information on the outages has been made available.
Brian: My understanding is that the outages are due to the plane being parked with the power off. We should verify.
Brian, ALSM
After correlating the Holland paper, Table III, to the RMP Aircraft Records, etc, report which lists 9M-MRO’s actual block times & locations, it’s clear that Log-ons 1-6 occurred on the ground at KUL prior during normal lay-overs.
@Brian Anderson:
If you suspect the L/R fuel flow difference to be due to a shift in the fuel flow transducer calibrations, it would be appropriate to extrapolate on the basis of fuel flow. The fuel flow transducer calibration is a function of fuel flow and fuel density/temperature.
If you suspect that fuel flow difference is due to engine performance differences, you should extrapolate on the basis of a parameter that reflects the thermodynamic operating point of the engine, such as corrected fuel flow, corrected rpm, or EPR.
“Corrected” means corrected for altitude, temperature, and Mach, as explained in any engine performance introductory textbook, and also in Boeing’s Jet Transport Performance Methods (ask Victor Iannello, he’s familiar with it).
@Brian,
No one knows the fuel exhaustion time for the first engine flame-out (not even you), so you cannot possibly compute the relative PDAs in cruise from that nonexistent data. We only know the second engine flame-out time (00:17:29).
ATSB (and I) have estimated the R engine flame-out time knowing the average relative cruise fuel flows from the prior flights.
Hello Victor,
This for DrBobbyUlich and Brian Anderson if I may.
On causes for incremental changes in fuel consumption, bleed air could be another if depressurisation is in the mix.
For the Trent 892-B17, at page 6 below are some bleed airflows:
https://www.easa.europa.eu/system/files/dfu/EASA-TCDS-E.047_Rolls–Royce_plc_RB211_Trent_800_series_engines-02-10102013.pdf
I do not have figures on the fuel consumption/bleed air relationship but that indicative 5% of IP airflow will cause substantial lost power in my opinion. Also you will note that 0.8% of fan air is diverted to the pre-cooler.
My recollection is that at altitude, HP air is tapped; and like the IP compressor, after its last stage.
So air deselection to increase depessurisation rate and extent above those from opening the outflow valves alone would, incidentally, save fuel. The time deselected might be constrained by the cold. That would depend on how long anyone remained.
If on the other hand the outflow valves were opened and bleed air left on, I would expect its rate to increase, lifting fuel flow.
So depressurisation could have an incremental effect on fuel flow, one way or another. I doubt any books would quantify that though simulators might.
@Mike
The document you are quoting is the Engineering Specification for the Satellite Data Unit SD-700 (Honeywell part number 7516118), which is part of the Honeywell/Racal Multichannel Satcom system MCS-7000 (please see link below).
9M-MRO used the MCS-6000, which incorporates the SD-600 (Honeywell part number 7516100).
Although it is a reasonable assumption, that the SD-600 uses a SC cut crystal ovenized oscillator manufactured by CQE and the output frequency is 10.08 MHz, just as the SD-700, do you know for sure?
https://www.dropbox.com/s/hqiwr2t01l2sxsz/Honeywell%20SDU700%20Technical%20Description.pdf?dl=0
@David: Welcome and thank you for your comment.
Richard
Yes, the source documents relate to the 4200 and 7200, but the 6000 was part of the same family. I believe the OCXO is the same for all of them. But no, I am not certain. One reason I posted this information was to get the few scraps we do have out for others to research. I have not been successful finding much on these PNs.
@Brian Anderson:
I wrote:
Here are the EHM fuel flow delta’s plotted against corrected fuel flow:
https://www.dropbox.com/s/n48mwiwqonj1fpq/EHMdeltaFF.pdf?dl=0
The ACARS data contained fuel weights every 5 minutes, not flow rates. Why can’t these weights and weight differences wrt time provide accurate flow rates in lbs/hr, regardless of temperature? The ratios derived from these weights show that the right engine was burning fuel (lbs/hr) at a rate 2% higher during takeoff, 1.2% higher during the climb and 0.8% higher during the cruise at FL350.
Bobby, Brian,
Fuel consumption disparity between engines: could the operation of a single aircon pack, rather than both, be the source of increased fuel flow from the bleed air supplying engine?
Does the left engine exhibit the higher fuel consumption? Left Aircon Pack normally supplies flight deck directly, so I’d guess a decision to shutdown a pack for economy reasons would apply to the right pack.
If a ‘pack’ is set to OFF, rather than AUTO, the Flow Control Valves into the pack from the engine pneumatic system are closed. While BLEED AIR controls remain in AUTO, & both engines operate, there is no pneumatic crossfeed.
@ALSM
“One reason I posted this information was to get the few scraps we do have out for others to research. I have not been successful finding much on these PNs.”
Spent a great deal of time yesterday both online and with a couple of corporate libraries. Nothing at all. Very strange. Perhaps contacting CQE, who seems to be the actual manufacturer? I will try that later today.
Dennis,
CQE -> Temex -> Rakon is the corporate evolution.
Don
@David @all
Courtesy of @Nederland over on JW site, a new book is available by retired pilot James Nixon, “The Crash of MH370”. It costs $2.50 for ebook over on Amazon. Reportedly the book discusses, among other things, depressurization scenario and suggests that is hard to accomplish due to slowness of depressuring and plenty of air available (not sure I agree, but it is good to question practical considerations).
“Richard
Yes, the source documents relate to the 4200 and 7200, but the 6000 was part of the same family. I believe the OCXO is the same for all of them. But no, I am not certain. One reason I posted this information was to get the few scraps we do have out for others to research. I have not been successful finding much on these PNs.”
@Mike
I have searched extensively as has Dennis. Nothing much!
There are several SD-600 and SD-700 on the market 2nd hand however.
I can only assume that the Thales purchase of Racal means, that the old documentation is no longer available.
As you mentioned:
Racal was purchased by Thales in 2002
https://en.wikipedia.org/wiki/Racal
@David @all
The Nixon book above does not speak for me re: MH370. But I am interested in how fast an intentional depressurization could be accomplished on a B777. I have done the experiment on the FS9 PSS777 model, but I suspect that model is not highly accurate.
@ALSM:
The Engine Health Monitoring (EHM) data transmitted via ACARS showed the indicated fuel flow of the right engine to be 1.9% higher than the left engine at take-off, and 1.3% higher in climb. Extrapolated to Long Range Cruise (LRC) on the basis of corrected fuel flow the L/R difference would be 2.05%, and 4.4% extrapolated on the basis of EPR.
If the right engine failed 15 minutes before the left engine (as estimated by the ATSB on the basis of 9M-MRO historical fuel consumption data), its fuel consumption rate would have been 3% higher than the left engine.
The ACARS Position Reports do not differentiate between engines. They show the total remaining fuel (TOTFW) every 5 minutes, rounded to the nearest 100 kg. Slightly more accurate is the Gross Weight (GWT) rounded to 20 lbs. The GWT reduces by 1280 lb (581 kg) in the lat 5 minutes, at the rate of 6972 kg/h. The conditions are GWT 481240 lb (218265 kg), 0.82 Mach, FL350, ISA+10.5°C.
The FCOM LRC table gives a total Fuel Flow of 6694 kg/h for GW 218265 kg, 0.84 Mach, FL350, ISA.
I’m trying to catch up on the SDU start-up discussion. For the moment I have four questions:
– Has it been confirmed that only log-on 7 was in flight?
– Has it been explained why there are two log-ons with a rather small decay in BFO (3 and 5) while some others show much larger decay?
– If there is such a large variation in the decay, how can you use it reliably to predict a (range) of decays, as is needed to predict an off-set for the 00:19 BFO’s, noting in addition that the assumed power outage at 00:19 was so much different from the previous flights?
– May we assume that the Doppler compensation is established instantaneously (or before the log-on request), IOW are we sure we are not looking at a mix of different start-up effects, especially for the in-flight cases?
@all
Just for completeness link below is the full questions/responses text from the DST Search Team. Black text is mine. Red text is the response.
http://tmex1.blogspot.com/2017/02/full-response-from-dst-mh370-search-team.html
Neils:
Yes, 1-6 were on the ground and 7 was in flight. Don confirmed it by checking 9M-MRO Block times.
Yes. They all have similar decay rates near the end of the stabilization period. The plots are confusing because they all start with the time of the first transmission, which is not correlated with the time power came on. So in some cases, the power had been on longer before the first transmission.
The error at 00:19 will be very small because the power off time was only 1-4 minutes, depending on which report you believe. In any case, the OCXO temp would not have dropped significantly and the BFO Bias would have been close to steady state. The error would have been small compared to the vertical signal, so not too important to get exactly right. Much more important to get the bias corrections at 1825-1829 right, if possible.
Yes, the Doppler compensation is app[lied before all transmissions.
@ALSM,
Mike, there is no ACARS data from which to directly compute relative fuel flows, only take-off and climb.
@Don,
The right engine consumes considerably more fuel than the left engine.
@ALSM,
My post above should read “. . . there is no ACARS data from which to directly compute relative fuel flows for CRUISE, only take-off and climb.”
Bobby:
Yes, I should know better than to go on (my) memory. I checked the spreadsheets Brian and I put together many months ago, and indeed they are based on using fuel flow to calculate fuel weights, not the other way around. Sorry for the confusion. You should have that spreadsheet. I’m sure I sent it to you.
@Victor,
The BTO at 18:25:34 can also be used. It is 12,600 microsec (= 51,700– 5*7820) and one sigma is 29 microsec since it is R1200.
Once you decide that the 18:25 and 18:27 BFOs are contaminated by the warm-up OXCO transient (I am now convinced they were), then the only BFO remaining here to assist in defining the route is the 18:28. It implies no change in speed or heading. However, it is far enough in time from 18:22 that a lateral offset could easily have been completed in between. Without the 18:25 and 18:27 BFOs, we no longer have any constraint on when the offset occurred within that window.
I also noticed an interesting fact that the elapsed time of a 10 NM offset maneuver (about 138 seconds) is close to the elapsed time between last radar contact (18:22:12) and SDU power-up (18:24:27). Suppose the lateral maneuver was just underway at 18:22:12. Could that turning (still probably to the right) affect the radar cross-section and the strength of the radar return? Perhaps it decreased below the detection threshold causing the radar track to end then. Next the lateral offset is completed at about 18:24:18, and the power-up begins a few seconds later.
In this scenario, the offset maneuver may have facilitated the end of the radar track, and the power restoration occurred immediately AFTER the offset was completed. If correct, this looks as if they may have wanted to be well away from N571 BEFORE they restored power, perhaps being concerned about the consequences (with good reason in hindsight).
Here are plots of BTO and BFO:
https://drive.google.com/file/d/0BzOIIFNlx2aUTGN2cjZmRFJ3WlE/view?usp=sharing
Your thoughts?
Further to my last post, an article in the Boeing AERO MAGAZINE (AERO_Q407_article5.pdf) shows specific range data versus Mach for an unspecified airplane, which could well be a B777 at GW 240,000 kg, FL350. For that condition the fuel flow at M.82 is 97% of that at M.84.
Adjusting the FCOM value for that difference, and applying DrB’s correction for ambient temperature, the nominal fuel flow at the conditions of MH370’s last ACARS position report would then be 6694*0.97*1.034 = 6711 kg/h.
With the caviats mentioned, the ACARS report cruise fuel flow could thus be 3.9% higher than nominal.
@Niels
My tuppence worth:
1) Yes, Table III Log-on 7 was the only inflight event. Logo-on 1 thru 6 all recorded when the aircraft was on the ground & I assume to be via LGA signal chain.
2) My interpretation is that Holland’s translation of the BFO characteristics overlooks two issues as he translates the ‘view’ from Fig 8 to Fig 9. a) Temporally, it’s not possible to align the bursts (either at time of Log On Reqst or Log On Ack) in the way he suggests; b) somewhat similarly, it’s not valid to translate each Log On in the vertical scale as he has.
3) It’s feasible that there is not a large variation in the decay. The few bursts that, in essence, are sampling the overshoot and decay occur in a sequence with varying delays from the ‘stable (enough) state’ that initiates the SDU operation.
4) a) for the ‘on ground’ Log On, I assume that they are all as per Log On #6: using the LGA so no doppler compensation applied (ADIRU not yet initialised). b) It would be useful to know the processing rate for doppler comp in the SDU, I’d expect it to be 20Hz, and I’d expect it to be compensation established before any transmit burst occurs.
Where I have noted assumptions above, a recorded status is available to the ATSB’s working groups. Full access to the Inmarsat GES logs will inform if the Log On was via the LGA or HGA. Honeywell/Thales should be forthcoming with typical profiles for the OCXO overshoot-decay characteristic, etc.
@DrB: Your work is interesting, as always. I have a somewhat different scenario that I would like people to consider. It’ll be the subject of my next post, which I should be completing soon.
@DennisW
“signal level and carrier-to-noise density ratio (C/N0) were also unusually low”
And there is no curiosity why?
If the L-band up-link experienced this then the P command/control channel on the L-band down link also was affected.
This can result in P channel degradation which can result in loss of P channel synchronization. The AMS(R)S prescribes that the SDU should initiate a log-on process if it takes enough ‘hits’ on the P channel in a 3 minute period.
This might explain why there was no warm-up drift…
L-Band isn’t as susceptible to rain so we can discard MH370 flying thru a thunderstorm…but something was going on.
For me the only really important BFO issue is not the BFO’s at 1825-1829, nor that at 00:19:29.
The real issue is the BFO of -2 Hz at 00:19:37, and the high rate of descent that it implies, if trustworthy.
The Inmarsat article in the Journal of Navigation states: “5.3. Refinement of BFO Samples. Detailed analysis of BFO samples taken from
other flights showed a high degree of consistency for the signalling message
frequencies, with the exception of those that were performed immediately after the
initial logon process. This called into question the BFO measurements after the log-on
sequences at 18:25 and 00:19. However it was also determined (by the same method)
that the first message transmitted by the aircraft in the logon sequence, the Logon
Request message, did provide a consistent and accurate BFO measurement.”
The Inmarsat statement is limited to MH370, but is based on observations of other flights. Dr. Holland’s paper counters that by explaining the 1825-1829 BFO’s from the OCXO warm-up. The purpose of that explanation is to ‘prove’ that the BFO of -2 Hz at 00:19:37 is valid, and because of the high rate of descent that it implies, the airplane must have crashed close to the 7th arc.
The ATSB claims that in additional Boeing simulations of end-of-flight scenarios “Some of the simulated scenarios recorded descent rates that equalled or exceeded values derived from the final SATCOM transmission. Similarly, the increase in descent rates across an 8 second period (as per the two final BFO values) equalled or exceeded those derived from the SATCOM transmissions.” But in the trajectories shown this could only have occurred at the end of some simulations, never near the 7th arc.
@George
“This might explain why there was no warm-up drift…”
I remain perplexed by the 18:25:27 BFO value (spot on frequency followed by a reboot signature). If it was a result of oven controller transient behavior of some sort (don’t want to reopen that discussion) it would be extremely serendipitous.
Apologies for a typo. Please read “The Inmarsat statement is not limited to MH370, …”
@TBill: Regarding depressurization/repressurization. I did some experiments with the PMDG 777. I was planning to document the results and got distracted. I’ll see if I can put my hands on the exact results, but these numbers should be in the ballpark:
Case 1–Depressurization: Outflow valves fully open, air packs off. The pressure altitude increases at a rate equal to (altitude minus cabin pressure altitude) divided by a time constant of about 4 minutes, which of course describes an exponential decay of pressure (increase in pressure altitude).
Case 2–Repressurization: Outflow valves fully closed, air packs on. The pressure altitude decreases at a near constant 2500 ft per minute.
I’ll see if I can get my hands on the exact numbers, although I doubt these numbers are very far off.
@DrBobbyU
“If correct, this looks as if they may have wanted to be well away from N571 BEFORE they restored power, perhaps being concerned about the consequences (with good reason in hindsight).”
I do like the hypothesis of getting off N571 before power-up, but what consequences are you suggesting? I know we had another aircraft EK343 coming up fairly close from behind.
Beware interpretation of fuel flow between last two ACARS and delta GW. I am told that fuel flow at top of climb is higher than normal because the exhaust gas temperatures are higher than during settled cruise conditions. We should therefore expect the fuel consumed per minute in the 5 mins to 1707 to be an over-estimate of typical FF value for an aircraft at that weight and pressure altitude.
@ALSM, Don Thompson
Thanks, Mike and Don, for your replies and explanations. If I read it correctly, you both seem to suggest, for slightly different reasons, that with the 33 to 130/142 Hz correction to the 00:19 BFO we might be on thin ice.
I agree with Gysbreght that irrespective of temperature effects (which may be small at 00:19), the validity of the -2 Hz value is a crucial question, and that the DSTG approach seems to contradict with earlier Inmarsat statements.
A worry I have in this respect is the strange BTO value in connection to the 00:19:37 BFO. Can this value be explained, and can it be excluded that the apparent atypical signal processing affects the BFO?
Heils:
The ATSB public statements about the 00:19:29 and 37 BFO values were “conservative” in early reports, But in private emails, ATSB agreed with my early assessment that they indicated a high rate of decent, not an anomaly. Eventually they went public with that acknowledgement. Now ATSB, DST Group, Holland are all on the same page (with us). Holland’s paper does the best job so far in deriving thoughtful worst case error bars for all possible cases at 00:19.
There is no large power-on correction required for the 00:19 BFO values because the power outage was only OTOO 1 minute, and the vertical signal was much larger than any possible error at that time. This is essentially what Holland says too.
@Gysbreght,
You said: “Did the ATSB explain the source of the fuel flow data? I mean were these momentary fuel flows indicated by the emgine fuel flow transducers recorded at certain intervals, or fuel quantity consumed in a longer period? Did they look at fuel quantities in each tank before and after flight, and fuel quantities loaded between flights per tank?”
I was not provided any details, but I got the impression they were based on averaging over a considerable length of time during each flight (probably using sequences of ACARS Fuel Reports). I don’t think they were instantaneous readings. They did not include any climb or descent phases.
@Brian,
You said:” It still surprises me that ATSB will not disclose the actual PDA numbers for each engine.”
It surprises me, too. That’s what I asked for. I was told they “were not available.” I don’t know for sure whether that meant they did not have them or that they had them but could not release them. If I had to guess, I would say the former, but I really don’t know.
@ALSM
Mike, I understand that you, ATSB and DSTG are in essence on the same page and accept that the ATSB has been perhaps “conservative” in their earlier treatment of the 00:19 BFO’s.
However, the statements from Inmarsat in the JoN article regarding the second BTO/BFO combi in the logon sequence cannot be qualified as just conservative.
Again:A worry I have in this respect is the strange BTO value in connection to the 00:19:37 BFO. Can this value be explained, and can it be excluded that the apparent atypical signal processing affects the BFO?
Paul Smithson wrote at 2:59 pm: “I am told that fuel flow at top of climb is higher than normal because the exhaust gas temperatures are higher than during settled cruise conditions.”
The progress of climb in the ACARS position reports indicates that FL350 was reached at about 17:00:45, and MH370 reported maintaining FL350 at 17:01:17 UTC.
@Dennis W
@Richard
@ALSM
Hope this helps
https://fccid.io/document.php?id=228372
Comments here are closed. Please continue the discussion under the new post.