Candidate MH370 paths starting from the same point at 18:02. (Click for a larger image.)
MH370’s SATCOM initiated a log-on to Inmarsat’s I3F1 satellite at 18:25:27, and after some exchange of data, completed that log-on at 18:28:15. (All times are UTC). The log-on process provides us with additional BTO and BFO data points which can help us to understand what the path and speed of the plane was at this time. Many of us have long assumed that the plane’s track just before the log-on was 296°T and the groundspeed was around 495 kn for two reasons:
- These values are consistent with the position and timing data that we extracted from the often-discussed Lido Hotel radar slide, which was presented to the NOK in Beijing on March 21, 2014. The slide shows radar captures of an unknown target (suspected to be MH370) up until 18:22 along the N571 airway traveling at about 495 kn.
- This combination of speed (495 kn) and track (296°T) matches the first and last BFO values (142-144 Hz) surprisingly well.
However, there are two problems with this theory:
- Between the initial and final values of around 143 Hz, the BFO peaks at 273 Hz and decays to intermediate values of around 174 Hz before returning to 144 Hz.
- If we assume the last recorded radar position at 18:22 is correct, then the BTO values during the log-on don’t match a plane traveling at a constant 495 kn along N571.
Back in July of 2015, some of us proposed an explanation that reconciled the radar, BTO, and BFO data: Soon after MH370’s SATCOM requested the 18:25 log-on to Inmarsat’s I3F1 satellite, the pilot initiated a 12-NM lateral offset manoeuver to the right of airway N571. (A pilot flying a leg of a route can program a lateral offset of a specified distance and the offset manoeuver will be automatically performed and the offset automatically maintained.) If the offset was timed just right, i.e., initiated just after 18:25:27 and completed just before 18:28:06, the BTO data matches, and all but the peak BFO value of 273 Hz can be explained. Most of us attributed this unexplained peak in frequency to a SATCOM anomaly that was not disclosed by its manufacturer (Honeywell Thales). With nothing better, we chose to ignore it.
We have gained more knowledge now that Ian Holland published his paper that discusses BFO behavior of a SATCOM as it logs-on to a satellite after it has been previously de-powered. Dr. Holland’s analysis suggests that the BFO sequence observed at 18:25 was not caused by a turn sequence taking place during the log-on. Rather, the BFO sequence is consistent with a SATCOM that has been de-powered for some time, warms-up, and logs-on to a satellite. As the oscillator crystal in the Satellite Data Unit (SDU) approaches it operating temperature, there is a peak in frequency followed by a decay to its final value. (Some like Mike Exner, Henrik Rydberg, and others have long suspected this.) So now the unexplained peak of 273 Hz is explained and verified as repeatable.
Although the warm-up transient adequately explains the BFO sequence at the 18:25 log-on, it still doesn’t explain the BTO sequence, which is not consistent with a path along N571 at 495 kn between 18:25:27 and 18:28:15 that includes the recorded radar position at 18:22.
We have some additional clues from the report on MH370 released in December 2015 by Australia’s Defense Science and Technology Group (DSTG). As part of the investigation of MH370’s disappearance, Malaysia supplied the ATSB with the raw radar data up until the last capture at 18:22:22 with a 10-second spacing. However, no radar data was supplied between 18:01:49 and 18:22:22, and no explanation was provided for the 20-minute gap. If we are to believe there were no radar captures in this period, we should also question the validity of the data shown in the Lido Hotel radar image. This in turn calls into question whether MH370 was following airway N571 at the time of and subsequent to the final radar capture.
If we remove the constraint that MH370 was following airway N571, we can consider other candidate paths using the following methodology:
- The path of MH370 that was captured by radar can be approximated by starting at a known position before 17:21 and integrating the groundspeed and track data provided graphically in the DSTG report. (Despite numerous requests, Malaysia refuses to release the actual radar data.)
- Starting at the radar-derived position at 18:02 and lasting through the 18:25 log-on, we assume that MH370 proceeded along a great circle path towards a selected waypoint at constant ground speed. The effect of variations in wind and temperature are ignored for now. (In fact, the temperature variation is small and the groundspeed differs from the true airspeed by at most several knots, which is within the margin of error of this analysis.) Several candidate waypoints are considered, each producing a different initial track at 18:02.
- For each initial track, a speed is determined by minimizing the RMS error of the BTO values at times 18:27:04 through 18:28:15 where the expected standard deviation is 29 μs. For the BTO at 18:25:27, the expected standard deviation is higher at 62 μs and was not used.
- For the BFO, only the BFO value at 18:28:15 is considered, as the prior values are distorted by the warm-up transient, as advised by Dr. Holland.
The candidate paths are shown in the figure above, and the results from the analysis are shown in table below. The paths fan outwards from the recorded radar position at 18:02. It can be seen in the figure that as the initial track rotates towards the north, the path length required to reach the 18:28 arc increases, which translates to higher speeds, and also higher BFOs. Therefore, not all of these paths satisfy speed and BFO criteria. A discussion of the candidate paths follows.
Case 1. Path towards the last radar point at 18:22 that minimizes BTO error
This is the baseline case considered in the DSTG report as the initial track of the path connecting the 18:02 and 18:22 radar positions is close to the observed radar track at 18:02 (around 289°T). The BTO error is minimized at a groundspeed of 459 kn, requiring a reduction in speed of about 59 kn, which is possible. (A pilot could choose to decelerate by climbing or using spoilers, which would drastically reduce the time to reach the new speed.) The BFO error at this speed is 6 Hz, which is acceptable by most measures. However, the distance and timing between the two radar points requires a minimum speed of around 499 kn, which would mean that the 18:22 radar point was in error by about 14 NM. So, considering this error and the absence of acknowledged radar data between 18:02 and 18:22, there is justification to completely ignore this last radar point, just as the DSTG chose to do in its analysis. Therefore, in the remaining cases analyzed, the last radar point at 18:22 is ignored, and we accept the 18:02 radar point as the last recorded position. Ignoring the last radar point doesn’t invalidate this path. It just makes it less special.
Of course, if we ignore the last radar capture, it once again begs the question that Malaysia refuses to answer: What data was actually shown to the NOK at the Lido Hotel in Beijing on March 21, 2014?
Cases 2,3,4,5. Paths towards airports that minimize BTO error
Recognizing that the radar data suggests that MH370 flew near (but not exactly over) Kota Bharu and later Penang Airports, we consider the possibility that after passing Penang, the plane was flown towards another airport in the region. We consider candidate paths towards Port Blair, Car Nicobar, Sabang, and Banda Aceh Airports, and for each path, find the speed that minimizes the BTO errors. As can be seen in the table, only the path towards Car Nicobar has an acceptable BFO error (3 Hz) and an acceptable speed (518 kn). This speed is consistent with what was observed by radar around 18:02. It’s also very fast compared to typical cruise conditions, corresponding to (no-wind conditions) of about Mach = 0.87 at FL350 at a temperature offset from standard conditions of around +10K. Although this Mach number is within the performance limitations of the plane, if MH370 flew along this path, it has important implications on the achievable endurance and range.
Case 6. Path that minimizes BTO error and exactly matches BFO
For this case, we allowed both the track angle and speed to vary as the BTO error was minimized and the BFO at 18:28:15 was constrained to match exactly. The calculated groundspeed is 499 kn, which is closer to a more typical speed that maximizes fuel efficiency. The path crosses the 18:28 arc about 33 NM to the north of the ATSB’s baseline path towards the 18:22 radar point.
Summary
The radar data presented to the NOK at the Lido Hotel in Beijing on March 21, 2014, has been used by independent investigators to justify a path along airway N571. Recognizing that the radar data has never been officially acknowledged by Malaysia, and also recognizing that the radar data from that image was never provided to the ATSB by Malaysia, we have to question its validity. Strangely, the final radar point at 18:22 from that image was provided to the ATSB, despite the 20-minute gap between it and the proceeding capture at 18:02. By choosing to ignore this final radar point, MH370 is much less likely to have followed N571, and other candidate paths along great circles can be found that satisfy the BFO and BTO data at the 18:25 log-on. The path that arguably best satisfies the satellite data crosses the 18:28 arc 33 NM to the north of the path that includes the 18:22 radar point. There is also an acceptable path that leads to Car Nicobar Airport, which requires a speed about the same as was observed before radar coverage was lost at 18:02.
Update on 2/22/2017: Incorporated some small edits based on private comments from Mike Exner.
Neils:
You are correct about Inmarsat’s JON Paper. They basically said they don’t know why the 00:19 BFO values were what they were, so they dismissed them without considering the obvious. BFO values contain a very strong vertical speed signal and a very weak horizontal signal. Hello! VERY bad decision. It resulted in wasting half of the search resources looking too far from the 7th arc (chasing nonsense theories) instead of looking further NE on more narrow +/- 20NM band close to the arc.
Joseph Coleman:
Thanks, but we (some of us) have had that document for 2.5 years. It is one of the few that have a tidbit of useful info.
@ALSM
I consider the JoN paper as a very useful and carefully composed source of information, and have the impression that Chris Ashton c.s. know very well what they are talking about. Of course insights may change, so I’m curious to know their current position on this.
@Gysbreght,
You said: “. . . the ACARS report cruise fuel flow could thus be 3.9% higher than nominal.”
Let me see if I understand your point correctly. You are estimating, based on the last ACARS fuel report, a total Fuel Flow then (at FL350 and M0.82) that is 3.9% higher than the LRC FCOM value after correcting for the 3% reduction in FF for the slower speed (M0.82 versus FCOM M0.84) and for the 3.4% increase due to elevatied temperature. So this is an estimate, in effect, for the average engine PDA in ECON (CI = 52) cruise.
You get 3.9% based on a snippet of one flight, but an important snippet that no one else has managed to do insofar as I know. I get 4.7 +/- 1.5% based on 25 flights. That’s close enough in my book.
To bound the range, if the left engine PDA is less than ~4% (say 2% at best), then the right engine is larger than 4% by the same difference (say 6%).
@TBill,
You said: “I do like the hypothesis of getting off N571 before power-up, but what consequences are you suggesting?”
I was suggesting that the last pilot action required to fully explain all the satellite data was to restore power to the SDU at 18:24:27. After that – no additional pilot actions are needed. That time is a full 15 minutes prior to the FMT and the unanswered phone call. Whatever happened then happened quickly, and it wasn’t good.
@Victor, reading through your latest post ‘Possible Paths of MH370 in the Malacca Strait’ compelled me to thank you for providing a blog site to properly present reasonable theories and concepts in a logical, well thought manner.
Thank you for all your efforts and level of excellence. Your posts help generate healthy technical conversations and new ideas.
@DrB: RE Yr post February 21, 2017 at 3:40 pm:
“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.”
The ACARS Position Reports give the Total Remaining Fuel quantity every 5 minutes. That is based on the fuel quantity transducers installed in each tank, totalled for all tanks. So it provides the total fuel quantity consumed by both engines together in each 5 minute period, rounded to 20 lb if you use the GWT values. It does not differentiate between left and right tank or engine.
The EHM messages are snapshots of a set of engine parameters at a particular time, for each engine individually. The fuel flow values are obtained from fuel flow transducers that have a nominal accuracy of +/- 1%. In performance flight tests conducted by a manufacturer these transducers are re-calibrated about once per month. In airline operation fuel flow is observed for anomalies that may indicate an engine problem, but its accuracy is not critical. Therefore those transducers may have been installed a long time without re-calibration. Their actual individual accuracy can only be checked by monitoring the fuel quantities loaded between flights in each tank separately over the last month or so.
RE Yr Post of 6:16 pm: I dont understand your sentence “So this is an estimate, in effect, for the average engine PDA in ECON (CI = 52) cruise.” That doesn’t come into it. I never considered ECON or CI, and M.82 is less than MRC (ECON CI=000).
You get 4.7 +/- 1.5% based on 25 flights. Unless you can describe how you arrive at that number it has little value in my book.
@Kenyon: Thanks for that. If I can help facilitate reasonable discussion, I will have succeeded.
@all
Just finished Nixon’s new book. Very disappointing. Nothing new to think about, and very many relevant issues not discussed at all.
@all
This latest Victor work is good, and I do appreciate it.
Having said that, it reinforces my own decision not to get involved with any analytics prior to 19:41. There is simply not enough information to draw any conclusions with confidence. Having said that I am very confident that the last known relatively well qualified information for the aircraft was at 18:25:27.
6.8N 95.9E 296T 510knots
Excellent post Victor!
Adjusting the BTO and BFO data as shown in the link below, results in a very good overall fit for your 297°T track at 499 knots and 35,000 feet from the last “10 second” radar data point 18:01:49 at 5.6248°N 99.0482°E:
https://www.dropbox.com/s/589sjtvh18bukgv/MH370%20Flight%20Path%20Model%20V16.0%20RG%201802%20Optimum.png?dl=0
Of course, a descent at 18:39 of 2,690 fpm is still required.
“The path that arguably best satisfies the satellite data crosses the 18:28 arc 33 NM to the north of the path that includes the 18:22 radar point. There is also an acceptable path that leads to Car Nicobar Airport, which requires a speed about the same as was observed before radar coverage was lost at 18:02.
A path that leads to VOCX and the ’10N’ point?
The ATSB position that MH370 must have crashed close to the 7th arc is based, in part, on simulations of uncontrolled descents that the ATSB asked Boeing to do in 2016. These were additional to simulations that had been conducted in 2015. We have to guess about the scenarios that these simulations represent: “Reasonable values were selected for the aircraft’s speed, fuel, electrical configuration and altitude, along with the turbulence level.”
Somewhat later they say: “In an electrical configuration where the loss of engine power from one engine resulted in the loss of autopilot (AP), the aircraft descended in both clockwise and anti-clockwise directions.” I wonder what that electrical configuration could be, and which of the ten simulations presented in Figure 6 represent that scenario.
If one numbers the trajectories shown in figure 6 at the top of the chart left to right, i.e. 1=light green, 2=yellow, 3=medium blue, etc, then trajectories 1 – 6 all turn left, remain in left turns while the radius decreases then increases, and end in wide, low bank angle turns.
Trajectories 7, 8, 9 and 10 follow a different pattern. Trajectories 7 and 8 initially seem to hesitate between turning left or right, then turn left while the turning radius decreases monotously, ending in what could be a spiral dive at high bank angle and rate of descent. Trajectories 9 and 10 turn right, the radius decreases until the end. The end of the white trajectory (no. 10) is so curious that it is difficult to understand that it is presented without comment. All trajectories 7 through 10 are noticeably shorter than 1 through 6.
Are perhaps all of the trajectories 7 through 10 in the electrical configuration where the loss of engine power from one engine resulted in the loss of autopilot (AP)? What exactly happened in that configuration? Just guessing, I suppose that the first engine that failed was the only source of generated electrical power. When it failed pitot heating would be lost, the flight control system went to secondary mode, and the autopilot therefore disengaged. The autothrottle would increase the thrust of the remaining engine to the maximum under the existing rating, and there would be no thrust asymmetry compensation or envelope protection. As the altitude reduced with one engine operating, the thrust asymmetry would increase, so it is not surprising that the bank angle continued to increase, the radius of turn decreased while airspeed and rate of descent increased in an ever tightening downward spiral.
Well, I’ve been mostly guessing, but is it acceptable that the ATSB presents these data without any explanation of the scenarios that they represent?
@DennisW
6.8N 95.9E ??
In SkyVector terms, am I correct in regarding that as 0648N09554E ?
That places as almost exactly on airway N571, however.
Gysbreght: Re Trajectories 1-10 and ATSB quotes: Please specify the document(s) you are referring to.
@Richard: Thank you for running the “best” path through your model and checking my results. As you can see, the fit is quite good without resorting to a lateral offset manoeuver after 18:22. But it also requires that we dismiss the association with airway N571. Perhaps we can somehow resolve this. I’m not sure how without Malaysia explaining what was shown in the Lido Hotel image.
@Don Thompson: If we compare the tracks at 18:02, the “best path” is 297 deg, the “10N path” is 298 deg, and the “VOCX path” is 300 deg. The BTOs, BFOs, and speeds for any of these paths are within acceptable limits. The BFO matches exactly for the “best path”.
@Niels: The JON paper is good, especially for when it was written, but I think later work supersedes it. With respect to vertical speed, I believe at the time the paper was written, the effect of uncompensated vertical speed was recognized, but this effect was inexplicably not incorporated into Inmarsat’s BFO model as illustrated by the poor BFO match during the climb out of KLIA.
@DrB: I’m sorry I didn’t sooner comment on your proposed path. I think we have to ask ourselves the basis for assuming MH370 was traveling along (or offset from) N571 and why the ATSB decided that it wasn’t. Remove that constraint, and the need disappears for a lateral offset after 18:22. Also, your path produces BTO values that are all lower than the R1200 data. Straight paths starting at 18:02 that minimize the BTO error all have near zero (less than 0.2 μs) average error. Nothing conclusive, but things to consider.
@ALSM: The ATSB document I am referring to is
ATSB Transport Safety Report
Aviation External Investigation
AE-2014-054
2 November 2016 “MH370 – Search and debris examination update”
@Victor
In your SUMMARY above you say “(LIDO) has been used by independent investigators to justify a path along airway N571”
But the FACTUAL INFORMATION says MH370 was apparently following N571 to MEKAR+10, and they show N571 flight path. So it wasn’t like the independent investigators were “mavericks” in thinking N571 was used. I seem to recall another document (ATSB?) that says MH370 may have followed N571 to IGOGU possibly out to LAGOG.
So to suggest N571 was not used is a true maverick idea. Of course, we could use a few new ideas around here.
@TBill: You are right that the FI from March 2015 referred to N571, although no radar data is presented. But then in December 2015, the ATSB/DSTG said there are no radar data points between 18:02 and 18:22, and they completely ignored the association with N571. So I’m not sure which is the maverick interpretation, especially in light of the lateral offset manoeuver required for the N571 interpretation to match the satellite data. This could all be easily resolved if Malaysia explained what is shown in the Lido Hotel image.
@DennisW,
If one chooses to believe the R1200 BTO of 12,600 (+/- 2*29) at 18:25:34 (which I do but others may not), your position at 18:25:27 is incompatible with it.
@Richard: “But it also requires that we dismiss the association with airway N571. Perhaps we can somehow resolve this. I’m not sure how without Malaysia explaining what was shown in the Lido Hotel image.”
@Victor: We may have to dismiss flight route N571 as an approximation and replace it with the evidence from the RMP report. 100636N0900402E (“10N”) sits on your proposed flight path.
https://www.dropbox.com/s/fo8dmoxv3wcppog/MH370%20Flight%20Path%20Model%20V16.0%20RG%201802%20Optimum%20%2B%2010N.png?dl=0
The Lido Hotel image was obviously pulled off the archives in true Malaysian fabrication fashion.
@DrB
Although the current deliberations take the 18:02 location as the
basis to hypothesize tracks, the position beneath Penang Island may be
more applicable. (Allowing for a small SLOP offset or ABEAM input of
2 Nm to the right, from waypoints,) if VAMPI, MEKAR, and NILAM were
deleted from a programmed flightpath, but IGOGU (which was probably
the end of LEG waypoint for that LEG of N571) remained, you have your
desired greater (resultant) separation from MEKAR of 10+ Nm (viewing
that distance as that measured at a right angle from the flightpath).
This flightpath is ~295° , so within the range that is being discussed.
Incidently, this passes almost over, slightly off to the right of,
Pulau Perak (and whoever the eyewitness was that saw an ‘overflying’
aircraft).
@Victor,
You said: “But then in December 2015, the ATSB/DSTG said there are no radar data points between 18:02 and 18:22,”
My recollection is different. I don’t remember ATSB ever saying there was no radar data between 18:02 and 18:22. I do recall DSTG saying they were only given those two points and nothing in between. However, that does not necessarily mean they don’t exist.
I think you will have a big hill to climb if you want to try and convince ATSB that N571 was not used, at least until ~18:22.
@buyerninety,
I have no desire other than producing a reasonable path between 18:22 and 18:40 that fits the satellite and radar data then and is consistent with a path southward that matches the satellite data from 18:40 – 00:19. The only path with a single FMT that is consistent with the BTO/BFO/wind/temp/PDA data is CTH at Best Holding. The only way I know of to get this strange combination is with simultaneous EOO/EOR errors. In addition, the southbound track has to be through ANOKO or some small distance to the right of it. The EOO error means there had to be an offset at ANOKO and therefore there must also have been one at IGOGU. I can’t see any need for an offset at MEKAR (and this would contradict the 18:22 radar position). An offset to the north is needed at or just beyond NILAM in order to match the BTOs.
I believe the eyewitness at Pulau Perak was at a military garrison, so they would probably have a watch going all night.
@Bobby
The DSTG Bayesian Methods in the Search for MH370 dated 30th November 2015 states:
“The radar data contains regular estimates of latitude, longitude and altitude at 10 second intervals from 16:42:27 to 18:01:49. A single additional latitude and longitude position was reported at 18:22:12.”
This means between 18:01:49 UTC and 18:22:12 UTC there were no reported radar data.
Interesting. From your post immediately preceding this, I take it
that the position of MH370 at 18:22 was basically as shown on the
Lido Hotel graphic, despite whatever other inaccuracies or markings
may be present in that graphic. No need to reply.
@DrB
“If one chooses to believe the R1200 BTO of 12,600 (+/- 2*29) at 18:25:34 (which I do but others may not), your position at 18:25:27 is incompatible with it.”
How did you determine the BTO value you are referring to above?
@Victor,
You said: “Straight paths starting at 18:02 that minimize the BTO error all have near zero (less than 0.2 μs) average error.”
As I am sure you know, any path with numerous BTOs that shows zero error cannot be the correct path. It must have a standard error of ~30 microseconds within the uncertainty of the estimated error. This is approximately given by the RMS divided by the square root of 2N, where N is the number of data points. From 18:25:27 to 18:28:15 there are N = 7 BTOs, so the uncertainty in estimating the standard error is roughly 0.3 / SQRT(2*7) = 0.08. Zero standard error is therefore 30/8 = 3.8 standard deviations away from the expected value, which is very, very, very unlikely.
@Gysbreght,
I have queried ATSB on the method for calculating fuel flows during prior flights. I will let you know the response.
Yes, CTH. You asked, to the effect, some months back, why TH would
be selected (at/about IGOGU). Perhaps another way to consider it, is
‘why would a pilot select TH at all’? MH370 had no near polar flights
recently, so Magnetic should have been the last selected
‘Heading’ mode used (if you take it as given that the MCP Heading mode
defaults to the last previously used).
Perhaps the question could be alternately be instead;
‘Why would a pilot have selected TH somewhat after IGARI’? (but
before the aircraft settled into LNAVing past Penang & along N571).
Degradation of the Required Navigation Performance, due to non-function
or damage to the navigational inputs (received by the FMC) or sensors,
could be a reason for that.
Cheers
@DennisW,
You said: ““If one chooses to believe the R1200 BTO of 12,600 (+/- 2*29) at 18:25:34 (which I do but others may not), your position at 18:25:27 is incompatible with it.”
How did you determine the BTO value you are referring to above?”
Both the log-on acknowledge BTOs at 18:25:34 and 00:19:37 BTOs include multiple increments of 7820 microseconds (per ATSB). It’s easy to figure out how many are needed to get in the ballpark. Use 5 for the first one and 4 for the second one. So 18:25:27 = 51,700 – 5*7820 = 12,600. At 00:19:37 I get 49,660 – 4*7820 = 18,380.
So, at 18:25:27 we have 12,520 +/- (2*62) and at 18:25:34 we have 12,600 +/- (2*29), using 2.0 standard errors. This pair is a good match.
At 00:19:29 we have 18,400 +/- (2*62) and at 00:19:37 we have 18,380 +/- (2*29), and this pair is also a good match.
The obvious reason for wanting good BTOs for the log-on acknowledge messages is that they are R1200 with only 29 microseconds standard error, whereas the log-on request messages are R600 with 62 microseconds standard error.
One result of using the 18:25:34 BTO is that it makes it more likely that a right turn off N571 was underway if not already completed. The large error bars on the 18:25:27 BTO don’t allow one to discriminate this without also using the 18:25:34 BTO.
@DrB: You have some misconceptions in your last posts:
1) You say, “I think you will have a big hill to climb if you want to try and convince ATSB that N571 was not used, at least until ~18:22.” Actually, there is no hill to climb because the DSTG uses no evidence related to airway N571. Their path reconstructions start with a “prior” (initial condition) using the filtered position, speed, and track from the 18:01:49 point, which is approximately 519 kn at 289.5 deg. They apply standard deviations of 0.5 NM to the position and 1 deg to the track, and do not use the last radar point at 18:22, nor the N571 airway. Any change in speed or autopilot heading/track requires a manoeuver, and the a priori distribution they use for the number of manoeuvers (turns and accelerations) is highly skewed towards fewer manoeuvers (see Figure 7.3). Using their methodology, it is clear that changing track to intercept the N571 airway and performing a lateral offset manoeuver would be rated as a lower probability than a straight path from 18:02 to 18:22, which is very consistent with the paths I generated.
2) You say, “Zero standard error is therefore 30/8 = 3.8 standard deviations away from the expected value, which is very, very, very unlikely.” You are confusing average error with RMS error. Look at the table above. The RMS errors of each path that I generated are 19-20 μs. However, the average BTO error is near zero, which you would expect if a proposed path accurately depicts reality, and the BTO measurements are approximately normally distributed about the true value. On the other hand, if you propose a path where the average BTO error during the 18:25 log-on is non-zero, it suggests a systematic error of some type.
@buyerninety
The heading mode is set by the Heading Reference Switch on the instrument panel NORM (magnetic) or TRUE. The pre-flight checklist contains the item:
HEADING REFERENCE switch………………………………….NORM
@VictorI
In the context of the discussion I was having with Mike the key question is if Inmarsat dismissed the second BFO in a logon sequence because of possible incomplete understanding of the contribution of vertical speed, or for a different reason. After rereading their par. 5.3 my interpretation is: because of a different reason. Again, it would be interesting to know their current position on this.
@DrB: Perhaps when you refer to “standard error” you mean the “standard error of the mean”. In any event, the “goodness” of the fit can be easily changed. For instance, for the “best fit” at 499 kn and 297 deg at 18:02 produces an RMS error of 19 μs and mean error of near zero. But decreasing the speed to 491 kn at the same track produces an RMS error of 29 μs and mean error of 22 μs. And increasing the speed to 507 kn at the same track produces an RMS error of 29 μs and mean error of -21 μs. So it is easy to choose a path that satisfies criteria for the expected values of the standard deviation and standard error of the mean.
@Niels: A lot has transpired since the JON article was written. If you chronologically read the papers written by the ATSB/DSTG, Inmarsat, and the Malaysian FI, you see an evolution of thought. I believe the ATSB, DSTG, Inmarsat, Honeywell-Thales, and Boeing all work as a cooperative team (within commercial and legal limits). As such, the most recent papers reflect their latest collective thoughts. That said, any of the parties are subject to make errors (such as when Ian Holland in his recent paper refers to the RAT powering the SATCOM) and can disagree on certain matters.
@ALSM,
@Don,
You have convinced me that low carrier to noise ratio is not a likely explanation for the unexpected BFO at 18:25:27.
For instance, all the BFOs from 16:40 to 17:07 have much lower received power levels (and thus probably lower carrier to noise ratios) and yet their BFOs all are in good agreement with the aircraft path then.
Mike, did you ever find out about the AGC? That would certainly affect the relationship between received power and C/N.
In addition, there are two other log-ons in Holland’s Table II which also have lower carrier to noise ratios, yet they are accepted as trustworthy and used by Holland to assist in characterizing the warm-up transient. Log-on #7 in Holland’s Table II (which is the 18:25:27 BFO), is the only one to occur in flight, but there is no apparent reason why the warm-up transient should be noticeably different in flight than on the tarmac. Perhaps it is just the timing of that occurrence, and that may depend on the oven temperature at power restoration.
Don has pointed out that the SDU must meet several criteria before it can transmit the log-on request. One of these is to receive the System Table, which requires ~12 seconds to load and which is broadcast repeatedly with some small variation in timing. Thus there will be timing jitter in the elapsed time from power restoration to log-on request (LOR) transmission of up to perhaps 12-14 seconds because of the asynchronous System Table availability. Perhaps for the 18:25:27 log-on the System Table delay was minimum and the log-on request message occurred sooner than for Holland’s other log-on examples. This unknown timing variability can also partially explain the different slopes seen in Holland’s Figure 9, where he aligned all the log-on examples in time using the log-on request message. If one adjusts the timing of each log-on sequence to better match a fixed shape of a warm-up transient model, the agreement is improved, although still far from perfect.
Don, does the System Table load occur while the temperature controller is heading to the operating band, or afterwards?
I think there is another significant source of timing variability – the time it takes to slew the OXCO temperature from its current start-up value to the vicinity of the operating temperature. This will depend, probably almost linearly, on that temperature difference since the servo will have a finite maximum slew rate. That means that cold starts take longer to reach the operating band, and to transmit a LOR, than warm starts. This is generally consistent with the range of warm-up times given by ATSB. Remember they started out (August 2014) using 2:40 from power-up to LOR. Then much later they changed to 1:00 (without an coherent explanation). I suspect the first number is valid for a typical gate start-up when the OXCO is near ambient temperature. The second number is much shorter and seems appropriate for a hot re-start such as what happened at 00:18 when the power was off only for about a minute. If my theory is correct, the elapsed time at the 18:25 LOR would be longer than at 00:19. Since the SDU power was off for about an hour at ~18:25, I would expect the time-to-LOR would be between 1:00 and 2:40. This means the SDU power restoration would occur more than one minute before the LOR, and thus before 18:24:27 and perhaps as early as 18:22:47.
Another implication of this theory is that the 7 LORs in Holland’s Table II may have large differences in time-to-LOR. That could explain why the observed slopes are so different. Perhaps the timing variation is sometimes a minute or more, not just 12 seconds.
Obviously, the reason I asked about the System Table load was that if it occurs while the temperature control servo is slewing, it may not matter in some or all cases, with the slew time variation being dominant.
Your thoughts?
@Victor,
You seem to consider that ATSB and DSTG are one and the same entity. They are not. The ATSB’s positions change with time as better understanding occurs. The DSTG book is a snapshot in time of what they were charged to do by ATSB in early-to-mid 2014. Their book does not reflect current understanding as of the date it was published. I take the ATSB’s statements at face value about the 18:22 radar and their Figure 2 and their association of the radar track with N571. I don’t consider that the decision to start the DSTG fitting at 18:02 indicates that the ATSB later considered the 18:22 position as being unreliable. I also don’t think ATSB cares at this point whether or not the DSTG assumptions were the same as what would be used today. ATSB is who you have to convince, not DSTG.
Regarding the fitting errors, you are correct that I misunderstood that the zero BTO error was a mean, not a standard deviation. That helps because as you point out, raising the 19 microseconds to 29’ish can be done with ground speed, but I would say that is only realistic, in my view, if it comports with LRC at cruise FL and the existing wind and temperature. A few knots is easy because the GDAS tailwind is not known better than ~6 knots anyway.
The mean BTO error over a few minutes time is not that meaningful in my opinion. As you point out, if we have the BTO bias correct (and it must be very close), then the mean BTO error over a long time period, such as a flight, should be close to zero. You can just take the calculated mean and see if it is zero within its error (which is the standard deviation divided by SQRT(N-1) or the RMS divided by SQRT(N).
The reason I use the RMS statistic is because it is a measure of the variation about a zero mean. The standard deviation is the variability about the mean of the samples, which may not be zero over say, the 3 minutes from 18:25 to 18:28. Thus the standard deviation of a brief sample of BTO errors (with a non-zero mean value) will be a lower limit to the true standard variation about a zero mean for a large population, which is the standard error. That is why I use the RMS statistic rather than the standard deviation – it uses a zero mean and therefore more accurately represents the variability we expect to see in a very long data sample.
No, I don’t mean the “standard error of the mean.” The term “standard error” is defined as “a measure of the statistical accuracy of an estimate, equal to the standard deviation of the theoretical distribution of a large population of such estimates.” In other words the standard error is the standard deviation of a very large ensemble. It is not the same quantity as a calculated standard deviation based on a small population, such as what you are doing. For instance, our best estimate of the standard error for R1200 BTOs is 29 microseconds. A calculated standard deviation of a small population is an approximation to the standard error. In this case, I believe the RMS of the small population is a better approximation to the standard error than is the standard deviation. That’s why I use RMS. It gives a slightly larger, but more accurate, result.
You said: “On the other hand, if you propose a path where the average BTO error during the 18:25 log-on is non-zero, it suggests a systematic error of some type.”
If the mean BTO error from 18:25 to 18:28 is more than two sigma away from zero), then I would worry. In this case I would calculate 2 sigma as 2*RMS/SQRT(N) where N is 7. That gives about 22 microseconds as a bound on the mean BTO error for the 18:25-18:28 BTOs. My lateral offset at 18:22 has a (weighted) mean error of -14 microseconds, so statistically it is OK. It is not large enough to indicate a likely systematic error.
Bobby: What you are suggesting now is what I have been saying. The time from power on to first transmission can vary depending on several factors. The thermal control system will drive the heater with full power until near setpoint, then switch to “tracking mode”. So the warmup is linear in time until the switch, then 2nd or 3rd order loop response. The 182527 login appears to be one case where the first transmission occurred a little earlier in the warm up settling, when the ok to TX flag was triggered by the ocxo flag. In other cases, Pcode sync or some other flag delayed the ok to TX flag.
@DrB: First, I am not trying to persuade either the ATSB or DSTG of anything. I understand the difference between the ATSB and the DSTG. But I have never seen a statement from either the ATSB or the DSTG that indicates they believe MH370 followed N571, nor a graphic that shows this, including Fig 2 from the ATSB’s report from June 2014, which shows a straight line between the 18:02 and 18:22 radar points. If you have evidence that the ATSB believes MH370 followed N571, please produce it because it would be very useful to have. The evidence that I know of MH370’s following N571 is the Lido Hotel image and the FI, both produced by the Malaysians.
Do you think it is likely that all of the BTO errors for your proposed path are the same sign?
@Victor
I finally found the quote “N571 toward IGOGU and possibly LAGOG”, it turns out not from ATSB, it turns out Richard Godfrey said that in his July 2016 paper “Where will MH370 be Found?” I like that paper as Richard gives some wind data in the flight path tables.
RG:
“According to the primary radar information (Figure 1 above), MH370 passed waypoints VAMPI and MEKAR and followed flight route N571 toward IGOGU and possibly LAGOG.”
@DrB: From the ATSB June 2014 report: “Primary radar data showed that the aircraft tracked along the Malacca Strait. During this time the aircraft passed close to waypoints VAMPI, MEKAR, NILAM and possibly IGOGU along a section of airway N571.”
Is that the reference you are referring to? Yes, the straight path between the 18:02 and 18:22 radar points passes close to these waypoints (as shown in my figure above), but the ATSB’s own Figure 2 does not show the path intercepting N571 at VAMPI and following N571.
Contrary to what it may seem, my purpose is to question the N571 assumption, not disprove it. Recall that back in the summer of 2015, at a time when you were considering contrails and a turn to the south at 18:25, I was proposing N571 and a lateral offset to the right to explain the BTO and BFO sequence of the 18:25 log-on. It certainly is a sensible possibility. But now that we don’t need a lateral offset to explain the BFO excursion, it is time to re-visit the assumption of N571 and the requirement of the lateral offset. And the evidence to support a track along N571 is in my opinion sparse. The only hard evidence I am aware of is a single radar capture at 18:22. For this reason, I question the N571 assumption. In my opinion, you should, too.
@TBill: The ATSB did refer to N571 in the reference I cite above. After all, the 18:22 point is close to N571. But the primary radar path shown in Figure 2 differs from the Lido Hotel image, which shows targets along N571 as opposed to the straight line between the 18:02 and 18:22 points shown in Figure 2.
@Victor
One thing of course we know EK343 was close behind MH370 and I assume EK343 was really on N571, so it feels more comfortable to me to be offset from N571 the whole time.
@Bobby
The OCXO provides the frequency reference for both the receive and transmit paths, it would not be logical to attempt to acquire the P/smc channel until the reference oscillator had stabilised.
@TBill
Separation is 3 dimensional, if there was a concern onboard 9M-MRO to maintain a ‘safe’ separation from other aircraft then a descent to FL290, or less, would have resolved that concern. Similarly, on the leg south, FL290 or below would ensure avoidance of traffic using the Aus Flex Tracks.
From p.7 of the Inmarsat paper:
“Each power up sequence starts
with a Logon Request message that has been found to have a fixed offset of 4600 μs
relative to the LOI message exchange by inspecting historical data for this aircraft
terminal. The subsequent messages during the logon sequence were found to have
unreliable delay and are believed to be an artefact of the terminal switching channel
and frequency during logon and so are not used in this analysis.”
Is there someone who understands this “terminal switching channel and frequency during logon” in more detail?
@Don Thompson
OK I know from FR24 they stack those planes closely on N571 only 1000-ft apart on altitude; but I am putting myself in the hypothetical pilot seat of a get-away flight inferring the PIC may have wanted to be totally invisible. Granted I do not have a pilot’s feel for how far away invisible is on a dark night, maybe 10 nM?
Was MH370 descending at -2900 FPM during the 18:40 phone call? No one can say for sure, but one can look at: a) the stability of the BFO during the minute-long attempt at completing the call(s); b) the stability of the BFO during the second phone call at 23:14; and c) typical flight paths of aircraft descending through comparable altitudes.
During the 18:40 phone call attempt, the BFO varied between 86 and 90 hz, with an rms of 1.2 hz. The pattern of this variation (peak-peak variations within a second of time) suggests that it is dominated by BFO noise, not real changes in descent rate. The slope is basically 0 (0.6 hz/min). For this portion of the flight, I estimate that a 1 hz change in BFO corresponds to a change in descent rate of order 230 FPM. Thus, the descent rate probably changed by less than 200 FPM, and likely less than 100 FPM during the timespan of a minute.
The BFO during the 23:14 phone call attempt is actually less well-behaved (slope 2.4 hz/min).
As a “representative” flight, I looked at the flightaware log for MH361 flying Beijing to Kuala Lumpur a couple of days ago (Monday, China time). At the end of the flight the plane descended more or less continuously from 40,000 feet all the way to landing. There was never a full minute of time when the descent rate was constant. During the descent to 30,0000 feet, the descent rate increased rougly linearly with time (roughly 300 FPMPM), and the rms about that linear rate was 275 FPM, jumping around on timescales of 30 seconds.
One can conclude that the descent profile of MH361 last Monday (admittedly, just one sample) could not have produced the BFO pattern of the 18:40 phone call attempt.
@Victor,
Yes, that is the reference to N571 that I was recalling. I believe that ATSB may have also referred at some time to the last radar contact location as “10 NM past MEKAR on N571”, but I don’t have that reference at hand. Maybe someone will know if ATSB used that one in one of their reports.
You said: “Do you think it is likely that all of the BTO errors for your proposed path are the same sign?”
No, but that is not the case. It’s easy to make the offset distance larger than the 10 NM I have been using so that the mean BTO error is closer to zero. There are two problems with doing this. First, the BTO errors begin to have a RMS that is too small, and second, the post-FMT route does not like to start that far west of ANOKO. The offset distance is a compromise I’m continuing to refine.
@Don,
Thanks for answering my question about when the System Table is loaded.
@ALSM,
You said: “The 182527 login appears to be one case where the first transmission occurred a little earlier in the warm up settling, when the ok to TX flag was triggered by the ocxo flag. In other cases, Pcode sync or some other flag delayed the ok to TX flag.”
Based on what Don just said, I don’t think the LOR (“OK to transmit flag”) can ever be triggered by the “OXCO flag”. The System Table load will always follow the OXCO flag, right? That said, you have confirmed that the time from power-up to OXCO flag will vary and will depend on the initial temperature relative to the setpoint. The next question is, is there any contribution from the thermal control system (i.e., other than the variation in System Table loading and the other syncs that must be achieved) that would affect when in the temperature step response the LOR occurs? I think what I am asking is whether there is any randomness in the thermal controller response once you have switched to the 2nd/3rd order loop? How repeatable is it?
I have not finished my model yet, but I am doubtful that 12-14 seconds of timing variation can produce such different frequency transients as seen in the 7 examples. It looks like you need something larger, maybe a minute or so. What could produce this?
@sk999: Welcome, and thank you for your comment.
The stability is a function of so many parameters that I think you can’t look at one flight and make any conclusions. The flight you cite was under ATC directive, and might have been adjusting descents according to successive altitude clearances, which could have changed the optimum flight path several times. But even if there was clearance to the final altitude, the steadiness of the vertical speed would be a function of the autopilot mode. If in FLCH or VNAV for the descent, then the engines were at idle and the elevator was automatically adjusted to achieve whatever speed was desired (via the MCP for FLCH or according to the ECON speed schedule if in VNAV), and the vertical speed would vary as the true airspeed varied with altitude. The same would occur if FPA was chosen–both the vertical speed and true airspeed would decrease during the descent. On the other hand, if VS and SPD were the modes, the vertical speed would be controlled by adjusting the elevator and the airspeed by adjusting engine thrust. At higher descent rates, the engine would be at idle, and VS would be controlled at the expense of speed up until Vmo. At 2600-3000 fpm and high altitude, I don’t see a problem with holding steady vertical speed in the VS pitch mode, especially at higher altitudes where the true airspeed is high.
I’ll check this with the FSX PMDG 777 model, which does pretty well modeling this kind of thing, but I don’t think holding steady vertical speed will be an issue.
DrB said “It’s easy to make the offset distance larger than the 10 NM I have been using so that the mean BTO error is closer to zero.”
In addition to the issues you cite, another problem is that the greater the offset distance, the longer the duration of the offset manoeuver, and the less the chance that it was squeezed in exactly after the last radar point at 18:22:22 and the log-on request at 18:25:27.
@DrB
from page 3 of the Factual Information released by Malaysia on 8 March 2015.
“The tracking by the Military continued as the radar return was observed to be heading towards waypoint MEKAR, a waypoint on Airways N571 when it disappeared abruptly at 1822:12 UTC [0222:12 MYT],10 nautical miles (Nm) after waypoint MEKAR.”
Using this information and the speed of ~500knots one derives the 6.8N 95.9E location I posted for 18:25:27. The 6.8N and 95.9E also happens to be where the 18:25:27 range ring intersects N571. I stand by my position estimate at 18:25:27.
Neils,
The quote you reference is poorly worded. The offsets describe timing relationships between channels, not the delay between specific messages.
The transmission of an R or T channel burst is synchronised with the P-channel that the SDU has acquired.
The Log On Request and the Log On Interrogation are specific types of message (burst). No frame sync (and, by implication, BTO) is implied by the type of message contained in a burst.
If you are concerned with the timing, channel switching and allocation:
9M-MRO’s AES-GES recorded correspondence shows that the Log On Request is transmitted on an R/smc channel (600bps data rate, 960ms burst duration, transmitted in a 1sec slot) while the AES is sync’ed to the forward P/smc channel (600bps data channel, continuous frames, 2sec frame period).
The P/smc channel is a fixed designation (bit rate and frequency) for each GES in the system. The AES, on startup, will acquire and sync the GES P/smc channel. Once it is receiving the P/smc broadcast it will verify the validity of its local copy of the System Table and, then, progress with the Log On. During the Log On the GES allocates forward (P/d) and return channels (R/d and T) to the AES.
After receiving channel allocations from the GES, a Log On Acknowledge (LOA) is transmitted by the AES on a just allocated R/d channel (1200bps data rate, 460ms burst duration, 500ms slot) while the AES remains sync’ed to the P/smc channel.
Once the AES transmits the LOA, it switches the receive channel to a just allocated P/d channel (10,500bps data rate, continuous frames, 500ms frame period) to receive the GES LOA.
If you are concerned about a channel’s carrier frequency, the ‘Channel Name’ field provided in the MH370 Data Communications Log defines the L-band (AES terminal) frequencies using a simple formula using the last four digits of that Channel Name, eg R/smc at 18:25:27.421 = ID 0x36E1 = 14049
Return L-band link: 1611.5 + (0.0025*Ch-ID) MHz
per above,
Return L-band link: 1611.5 + (0.0025*14049) = 1646.6225MHz
F’ward L-band link: 1510 + (0.0025*Ch-ID) MHz
Bobby,
Referring to my reply, above, to Niels & your comment at 7:00pm.
It’s not yet clear precisely what conditions predicate the SDU attaining a ‘steady state’ during power up. However, the maximum period allowed to achieve ‘steady state’ is quoted as 4 minutes.
Holland’s paper has not explored a correlation between the ‘off power’ time and the later elapsed time, after power restoration, to reach ‘steady state’ and then proceed to execute the Log On. The conclusion is simply that there is a decay after a transient overshoot.
Empirical data does exist to explore the correlation, there is no doubt about the existence of this data.
Victor,
Thank you for your most recent paper, insightful and thought provoking.
It has been my long held view that MH370’s flight back across the Malay Peninsula was consistent with a diversion from near IGARI back to nearest operational airport at that time of night, Penang. The flight path derived from the intermittent radar traces is broadly consistent with bank limited 25.6 mile diameter turn to the left at IGARI with a subsequent track towards KENDI, 12 nautical miles south-west of Penang. KENDI is the Intermediate Fix for ILS 04 and would be the logical place to track to for a landing on Runway 04.
I have contended that the turn away from Penang, either at or just before KENDI, was executed using MCP Track or Heading Select – a track of 290° provides a neat fit for a flight path through VAMPI and to the north of MEKAR. I have previously set aside the track derived from the Lido Slide plots (287°) because it necessitates an overflight of the island of Penang (ie it doesn’t align with a turn to the north-west from south of Penang).
Like you, I have tended to resolve flight paths to constant true tracks even though I believed that the use of MCP HDG SEL was the most likely option. I now see that I need to start plotting some actual tracks based on HDG SEL and the prevailing 40-odd knot easterlies.
I’d be keen to understand how the drifting track associated with a heading of say 295° might look in terms of BFOs between 18:25:27 and 18:28:15.
@Victor,
You said: “In addition to the issues you cite, another problem is that the greater the offset distance, the longer the duration of the offset manoeuver, and the less the chance that it was squeezed in exactly after the last radar point at 18:22:22 and the log-on request at 18:25:27.”
I don’t see any advantage to squeezing in the SLOP between 18:22:12 and 18:25:27. There may be some logic, as I described previously, if the SLOP is completed by the SDU power-up. We really don’t know when this occurred, but it appears to have been between 18:24:27 and roughly 100 seconds earlier.
Another obstacle in using SLOPs larger than 10 NM is getting to the FMT far enough west so that the west offset from ANOKO can be hit. With a 10 NM SLOP the 18:40 phone call is already in the middle of the FMT (which still fits OK). Larger SLOPs have a problem fitting the phone call BFOs because the FMT to hit ANOKO + SLOP doesn’t start until after the phone call begins, and you get a BFO mismatch at the front end of the call. It helps if you gain a little speed, but you need to get above FL360 to make that approach work. The post-FMT route likes 360 on the nose. So far I am getting a good fit with 10 NM SLOP and FL360. It is actually very tightly constrained if you don’t allow an altitude change after the FMT (which right now I don’t need). There is also the question of why a pilot would use a 12 NM SLOP. Why 12? You can ask why 10 also (but it is a nice round number), or why not 1 or 2?
@DennisW,
Your 18:25:27 position estimate is certainly very close to the 18:25:27 BTO arc, but this BTO has a larger error than all others (except 00:19:27). Two sigma is 124 microseconds, which encompasses both N571 and the SLOP route. If you plot the BTO arc for 18:25:34, which has 2 sigma of 58 microseconds, you will see that that excludes the N571 airway without an offset. Here is what I mean:
https://drive.google.com/file/d/0BzOIIFNlx2aUTGN2cjZmRFJ3WlE/view?usp=sharing
The caveat is that the 18:25:34 BTO does not have the “Good Housekeeping” gold seal of approval by ATSB/Inmarsat. But, then again that’s what they previously said about some of the other data they are now relying on. For both the cases for which we have data, the derived BTOs don’t appear unreasonable to me. You can choose to ignore the 18:25:34 BTO if you want, but you have to allow an error band more than twice as wide if you only use the 18:25:27 BTO.
@DrB
My estimate not only uses the BTO but the radar data (I provided the quote you asked for) and the extrapolation from the stated position at 18:22:12. It is completely compatible with the BTO, the aircraft speed, and the radar data. You can wave your arms around all you want to, but you are simply blowing smoke on the obvious IMO.
Frankly, I don’t have a dog in the fight you, Victor, and others are waging. I absolutely refuse to get involved in analytics between 18:25 and 19:41. I regard it as a waste of time.
@Victor @DrB
So I am thinking the best fit 297T from 18:02 hits SAMAK at right around 18:40.
SAMAK Options:
1) SAMAK is not far from DrB’s path at 18:40, so we could have SAMAK 180S to ANOKO or IGOGU possibly that works as a minor variation
2) For Iannello and Godfrey (and me) we probably have to be thinking MH370 descending at SAMAK to fly under Skyway L645 (SAMAK to DUBTA path),
or if we give up on NW radar point, turning west to DUBTA and descending less strongly to get under EK343 coming up from behind
And, of course, no sooner had I posted that that I realised your not going to see any significant drift in the course of just three minutes.
@all,
Does anyone know how the range of the 18:22 last radar contact from the suspected radar site compared to the maximum specified range? I was wondering if the loss of contact could be explained solely by increasing range, or is it possible that the aircraft turned in such a way that its RCS dropped enough for the radar to lose detection even though the aircraft was still (slightly) within the usual detection range?
@DrB
The loss of radar contact is compatible with the maximum range of the radar if it was Western Hill (which is still debatable). The radar cross section of a 777 is not a factor.
@Mick Gilbert: I have no real preference for constant track over constant heading, as magnetic heading is the most likely mode for a pilot to fly on autopilot when not using LNAV. I have generated paths with all the autopilot modes. In my post above, I assumed great circle (not constant track) paths because I was considering the case of “Direct To” navigation to the airport waypoints.
Regarding the HDG SEL mode, I would be very surprised if there wasn’t a range of values at 18:02 that matches the BTO and BFO values at 18:25-18:28, although I haven’t run the calculation yet.
Regarding the Lido Hotel slide, I think it is important to determine if this slide represents MH370 radar captures for many reasons, including the ones you mentioned.
DrB: I asked previously, “Do you think it is likely that all of the BTO errors for your proposed path are the same sign?” and you replied, “No, but that is not the case.”
Then I must not understand the figure you linked to with the title “MH370 – SLOP at 18:22:10”. The path-generated BTO line falls below every R1200 BTO point for the lateral offset you chose.
@TBill: I wouldn’t worry too much about the NW radar point. It represents a point of non-detection, not a radar capture. All the paths we think are likely are east of this point, so we are good.
DennisW says: “I regard it as a waste of time.”
Actually, it’s an addiction.
@Don Thompson
Don, many thanks for your explanation. If I understand the procedure correctly it is very unlikely that the channel selection procedure as such would influence the BFO measurements. The AES is at any time transmitting in a prescribed channel and the channel freq. spacing is such that in the unlikely case that it would not, you would probably not get a BFO measurement at all.
Of course on a detailed electronic level (frequency generation / switching) one has to be sure, but it takes away a significant part of the concerns I have regarding the second BFO values in the logon sequences.
Neils:
Absent some software glitch in the CU (rare if ever), if a transmission takes place at all, regardless of the channel, and the CU demodulates the SU (packet), then there will be a BFO measurement recorded. It is a byproduct of the demodulator code.
All:
Clarification to Don’s comment: “However, the maximum period allowed to achieve ‘steady state’ is quoted as 4 minutes.” The 4 minutes comes from the list of conditions precedent for the transmitter to be enabled following start-up. If none of the other conditions are met after 4 minutes, the algorithm transfers control to an error reporting/recovery routine and human or automatic action is required for problem resolution. At the time of the first transmission, the OCXO frequency will be close enough to SS to allow a transmission (looks like within ~150 Hz max), but it will not be at the longer term steady state frequency. That can take another 2-3 minutes, during which time the frequency continues to drop toward steady state as per the examples given in Ian’s paper.
@ALSM
I suppose the BFO is determined with respect to the “expected” frequency, so a transmission in a “wrong” channel would usually result in a weird / large value?
Neils:
No. If the AES transmitted in the wrong channel (virtually impossible), there would probably be no CU (demodulator) assigned to receive on that wrong channel, thus no demodulation and no BFO measurement.
@TBill. Couple of thoughts:
-If he wanted not to be seen by EK343 instead of diverting he could turn off his lights?
-Would he have known where EK343 was?
@Gysbreght. Those figure 6 flight paths; yes lots left unsaid. Some comments:
“Reasonable values” include fuel, so they were contemplating some left at the 7th arc. ‘Electrical configuration’ or the simulation itself might even stretch to windmilling of the dead engine, discussed recently, the autopilot remaining on and the RAT not deploying. Having IDGs off but a back-up generator running makes for more variation still as does APU start – and its run time. So various possibilities.
New electrical configurations might lead to suppression of the flaperon lift imbalance under RAT that I have raised before, ie that rolling the aircraft to the left. It remains a puzzle to me why that would not tighten the spirals when the RAT was operating alone, that being the configuration supposed in the earlier simulations and which should have a place still amongst the new.
Some of the spiral diameter increases could be due to phugoids maybe. Differing altitudes might influence flight duration and span since they allow different “values” for that now too.
@Victor. Your 21 Feb 1:58 post described your simulator cases 1 and 2. It is interesting to equate your rate of change of cabin pressure due to depressurisation with that of re-pressurisation, the airflow rates in and out for a given rate being the same though of opposite sign.
Flow rate will be proportional to cabin pressure change rate. So your 2500 ft/min is a direct measure of outwards flow, outlet valves open, packs off. In re-pressurisation, packs on, valves closed, you found cabin pressure rate change rate equal to the difference between cabin and ambient altitude, divided by 4.
Under the same conditions these two will be equal, from which it can be seen that the altitude difference at that point will be 10,000 ft. So in other words, if your memory is correct and the simulator about right, at 35,000 ft, outflow valves open but now with packs on, the cabin pressure will head towards a 25,000 ft asymptote, where inflow would equal outflow.
So far as I know there has been no method by which a figure could be placed on that before, so your simulator cases and TBill’s might have added utility of which you were unaware.
Obviously without pack air the asymptote would be ambient and the cabin would pass up through any altitude critical to hypoxia theories a good deal quicker.
Pack air selection/deselection by the way also selects trim air normally.
Victor,
As Richard alluded to much earlier in these comments there’s still the 18:39:55 – 18:40:56 UTC BFO data to account for. As I understand it that’s indicative of a 2,690 fpm descent or a turn – what are your thoughts on that?
@David: Thanks for your reply.
“Some of the spiral diameter increases could be due to phugoids maybe. ”
The trajectory with the most pronounced phugoid amplitude would be no.6, the one with the most southern terminus. The period looks about right (60 – 90 seconds, depending on TAS). The period of the large spiral diameter variations does not correspond to that of a phugoid.
@David: No, what I reported is what I observed in the simulation, and what makes logical sense. The flow into the cabin from the packs was nearly constant, producing a constant pressure altitude fall rate, and the flow out the valves was proportional to the difference in cabin and atmospheric pressure, producing a pressure altitude rise proportional to the pressure difference. (I imagine the bleed air is from a much higher pressure source, and not very sensitive to back pressure, whether or not the flow is choked.) I went back and found my notes. The constants I reported were a bit off. The time constant for depressurization out the valves is 6.67 min (not 4 min), i.e., the pressure rise (in ft/min) is 0.15 x [ambient pressure(ft) – cabin pressure(ft)] with packs off. With packs on and valves closed, the pressure altitude fall rate is 1200 ft/min (not 2500 ft/min). Also, it takes about 30 seconds to fully open the valves from their nominal position.
Yesterday, I did do some more tests in FSX similar to what you proposed, combining open valves and packs on. The results were not what I expected, i.e., superposition didn’t seem to hold, indicating a non-linearity somewhere. I wasn’t going to report back until I figured out what was going on, but your comment prompted me to say something now since there seems to be interest. Of course, the FSX simulation will provide only qualitative results.
@David: Sorry I shouldn’t have trusted my memory for the phugoid period. That is 23.31 seconds for 100 kt TAS, proportional to TAS. The distances between the kinks in trajectory no.6 correspond to about 280 kt TAS.
@Victor: thanks for questioning whether evidence paraded before us is authentic. We need more of this.
Two questions:
1. At what altitude is [the KTAS corresponding to 518 KGS] range-maximizing? I ask because FL350, after 17:06, is, I believe, merely an assumption.
2. To what does your required 59 knot speed reduction along N571 change if you plug in a time of 18:22:48 instead of 18:22:12, and 5 nmi past MEKAR instead of 10? I ask because moving this data point – within reasonable bounds of precision – in this direction serves to reduce the indicated speed prior to 18:22, and increase the speed after – both of which would eat into your 59 value from both directions. Perhaps significantly.
@VictorI
Want to support your blog with this comment.
I think it’s adding in its own way greatly.
Next to Jeff’s blog which has a different less limiting approuch IMO which I value a lot.
It’s good to stay open to many different views in this case.
But the always changing (interpretation of) current data and facts should guide the way.
Getting stuck in confirmation -bias is a dead end we all should know by now.
Mick Gilbert: You asked about my thoughts regarding the BFO at 18:40. It is hard to give a short answer. Let me first make three observations:
1. The plane was not found in area searched, which extends from 39.5S to 32.5S latitude at various distances away from the 7th arc.
2. The BFO values at 00:19 suggest a steep descent near the time the plane crossed the 7th arc.
3. Drift models such as those of CSIRO and Richard G.’s generally suggest that as you consider crash sites along the 7th and progress north of 32.5S latitude, there are increasing probabilities of the flaperon reaching La Reunion by July 2015, other debris reaching Eastern Africa by December 2015, and no debris reaching Western Australia.
So, I see three main possibilities:
1. The plane crashed in the area that was searched but it was not observed during the scanning of the seabed. The investigation officials tell us this is not likely.
2. The plane crashed along the 7th arc, but despite the BFO data suggesting a steep descent, the plane glided to a distance beyond what was searched. This becomes more probable if the crash was north of 36S latitude because the width of the search was more narrow.
3. At 18:40, the plane was still traveling northwest and it was descending. It turned to the south at some time after 18:40, perhaps after a loiter. The crash site is along the 7th arc but to the north of 32.5S.
Of these three possibilities, I rank (3) as most likely and (1) as least likely. I also freely admit, unlike many others, that is very difficult to assign even relative probabilities without more evidence.
If scenario (3) occurred, the range of possible crash sites becomes unmanageably large. Other evidence or assumptions, such as automated flight to a distant waypoint, has to be introduced to reduce the area to something reasonable. That is why I remain very interested in the simulator data found on the captain’s computer which many seem to completely dismiss. It could give us clues about the flight of MH370. You’ve seen one paper I wrote with Richard G. with the theory that McMurdo was the final waypoint of MH370, producing a crash site around 27S latitude. It is only a possibility. Richard in his more recent paper suggests a crash site around 30S.
My main objective in creating this blog was to encourage thoughtful discussion about reasonable scenarios.
@Brock: I hope you understand that I can’t respond to every request for calculations. I think you can do these calculations yourself.
The position and timing of the 18:22 radar point from the DSTG report is consistent with the position and timing of the Lido Hotel image, which includes many points. If the Lido Hotel image is valid, there is no justification to significantly move the 18:22 point in time or position. If the image isn’t valid, there is little reason to believe the single capture at 18:22 (after a 20-minute gap) was MH370 other than it is on a path extrapolated from the radar positions at 18:02. Frankly, I think it is disgusting that we are still debating this point today since Malaysia knows the answer very well.
@Ge Rijn: Welcome, and thank you for your comment.
@David
Good questions, not sure.
@VictorI
“Frankly, I think it is disgusting that we are still debating this point today since Malaysia knows the answer very well.”
The Malays provided the answer – 10nm past MEKAR on N571 at 18:22:12.
I believe this answer because it is reinforced by the BTO/BFO data at 18:25:27.
@Victor,
You said: “Then I must not understand the figure you linked to with the title “MH370 – SLOP at 18:22:10”. The path-generated BTO line falls below every R1200 BTO point for the lateral offset you chose.”
Why are you ignoring the R600 BTO at 18:25:27? Although it is noisier, there is no doubt about its reliability. It is below the offset path prediction. That’s why I said not all the BTOs were on the same side of the prediction.
@VictorI
Thanks for exepting me in the first place. You probably know by now I’m a more intuitive guy trying to keep hold on facts but derailed by emotions sometimes. My excuse is; persuing facts is driven by emotions. Often this is what drives us initialy isn’t it. But staying to facts and data is essential in this case I’m aware of.
Back to data. The Vietnamees Con Son Island radar data are not mentioned in the discussion.
Those data tell both SSR and primary radar data vanished at the same time (see the capture in the French documentary, I was not able to copy it).
In other words; what happened there around IGARI?
I mean also the Vietnamees Con Son Island radar data are important to get hold of too.
Just another cent in the basket.
@DennisW: The entire BTO sequence at 18:25 (not just the first), a track along N571 of 296T, and a constant speed of 500 kn can’t all be true. To reconcile the data, I introduced the possibility of a lateral offset manoeuver back in July 2015. Bobby continues to believe this is likely. I am questioning the N571 assumption as it is supported by only one official radar capture after a 20-minute gap. Without the N571 assumption, the need for the lateral offset disappears.
@Bobby asked, “Why are you ignoring the R600 BTO at 18:25:27? Although it is noisier, there is no doubt about its reliability. It is below the offset path prediction. That’s why I said not all the BTOs were on the same side of the prediction.”
Including the noisy R600 data point doesn’t eliminate the fact that the next 6 R1200 values, all more precise, all have the same sign error.
@Ge Rijn: No need to thank me for accepting you. All are welcome that are willing to constructively participate.
Can you provide a link to the video and a time so we can all look at it?
@VictorI
“I am questioning the N571 assumption as it is supported by only one official radar capture after a 20-minute gap. Without the N571 assumption, the need for the lateral offset disappears.”
Just to be clear, it is not an assumption. It is a statement. What you are doing is discarding it. It is supported by the 18:25:27 ISAT data. I believe it. We will simply have to disagree. No big deal. Carry on.
@DennisW: Look at it this way. Let’s accept the Malaysian statement that the location at 18:22 is on N571 and 10 NM past MEKAR. There is still no way you can maintain 296T, 500 kn, and match the entire BTO sequence. That’s what Bobby and I are saying. (Try it. You’ll see it requires a change in slope of the BTO v time curve, which in turn requires a change in groundspeed and/or track.) I proposed the lateral offset manoeuver because it became possible to explain both the BTO and BFO sequence. But we now think it is likely the BFO sequence is explained by the warm-up transient. We still have the BTO sequence to explain. Something has to give. What’s your proposal?
@Victor
I am still thinking about it. I remain very troubled by the 18:25:27 logon, and the associated BFO accuracy. I do not embrace ALSM’s explanation for that. BFO changed by 130Hz in between 18:25:27 and 18:25:34. That would imply a frequency change of a part in 10^7 over a seven second period.
I have asked the ASTB for the document Holland referred to multiple times in his recent paper –
[7] “Internal study regarding SATCOM ground-station logs,” MH370 Flight Path Reconstruction Group – SATCOM Subgroup. Presumably that paper is the reason Holland dismisses the 18:25:27 BFO as spurious. I would like to hear how that conclusion was reached.
The behavior of the AES at 18:25:27 and the following minutes simply does not follow the behavior of the other logon events reported by Holland, and no one seems appropriately troubled by that. Your approach is to trust the ISAT data. I am not so sure.
@DennisW: Let’s throw out the BFO data. The problem at this point is the BTO sequence. If we accept the radar position at 18:22, a track of 296T and a speed of 500 kn, you can match the first BTO value within an acceptable measurement error, but not the others without changing the speed and/or track. That’s why I say something has to give. Do you have reason to believe the BTO sequence is corrupted?
@Victor
Why do you suppose the DSTG is not bothered by your observations? The end of the link below highlights the ISAT data used by the DSTG.
http://tmex1.blogspot.com/2017/02/mh370-position-at-182527.html
@Dennis: By my calculation, for a speed of 500 kn and a track of 296T, the slope of the BTO is 50.5 μs/min. Over a course of 2.65 min, that’s a change of 134 μs. If you nearly exactly match the BTO at 18:25:27, you can’t match the BTO at 18:28:06 within the margin of error.
The DSTG is not bothered by my observations because they agree with them. Their baseline is my Case 1 above. The track at 18:25 is the same as their filtered track at 18:02 and it’s about 289T. Their baseline case does not follow N571.
@DrB, Ge Rijn, interested others.
A few miscellaneous notes:
The Malaysian Army does maintain a small detachment on Pulau Perak, two soldiers were lost in the sea at the island last October, and a ‘Nuri’ helicopter crash landed there in Dec 2013.
These guys must real ‘avgeeks’ if they can positively identify an aircraft type, flying at altitude, on a moonless night, at 02:00 local time. Landing lights, if turned on, can help night-time identification but only nav lights and strobes, not so much.
There is an operational lighthouse on the island’s peak. ‘Island’ is a misnomer, it’s just a big rock.
ANSP airspace surveillance: Vietnam operates an ADS-B station at Con Son island. The FI noted its data.
@Victor
Your last comment reminded me that in the 2014 Mar April timeframe, Inmarsat
initially told Jeff Wise that the ~ 18:30 BTO indicated the closest approach
to the satellite. It thereafter flew away from the satellite.
When the elevation graphic appeared in late April with the 19:41 and the
20:40 BTO now closer, Jeff tried to get an explanation from Inmarsat.
There was never any response. Perhaps these issues are related.
@Victor
I’ll have to check my BTO math. Please wait.
@Victor
Your response came in just as I was sitting down to lunch. Just a quick gut reaction – 289T would seem to aggravate the situation relative to 296T since it is more directly at the sub satellite point. In any case I will move from the back of an envelop to a complete vector representation including the change in satellite position relative to the GES.
@Victor, @all:
Here are all references to either “MEKAR” or “N571” in the “FACTUAL INFORMATION SAFETY INVESTIGATION FOR MH370” report published March 8, 2015 (at least the version Google gave me this afternoon):
P.3:
“The tracking by the Military continued as the radar return was observed to be heading towards waypoint MEKAR, a waypoint on Airways N571 when it disappeared abruptly at 1822:12 UTC [0222:12 MYT],10 nautical miles (Nm) after waypoint MEKAR.
P.7 (Fig.1.1B, footnote 10):
“The primary target ended at 10Nm after MEKAR at 1822.12 UTC [0222.12 MYT]”
I note that the only thing ever said about N571 is that waypoint MEKAR lies on it. (Nor is there any reference to MH370 being connected to ANY of the military radar returns – but this is another issue for another day.)
Also absent from the above statements is any clarity on what is meant by “past” MEKAR. However, there is one further reference to the 18:22 reported return: Footnote 9 of Fig.1.1B on P.7 states:
“The primary target (military radar) appeared to track west-northwest direction joining RNAV Route N571 at waypoint VAMPI then to 10Nm north MEKAR”
One could argue that “north MEKAR” means something other than “north of MEKAR” – but the Fig.1.1B map itself sure seems to depict the final military radar return as being 10 nmi north of MEKAR. DUE north.
If this is what was meant, then the radar return must now be plotted further west of where it would lie if an N571 path is forced. This alone serves to increase the distance folks here have concluded is too short to support constant speed. Because trig.
Furthermore, a straight line running from Pulau Perak through a point 10nmi due north of MEKAR is angled a few degrees further northward. This FURTHER increases the distance, and FURTHER eliminates the need to model a slowdown (or turn).
In fact, a quick calc suggests to me that the bearing could be well south of Katchall Is. with the BTO’s neither necessitating nor even suggesting a turn/slowdown/lateral offset. Because the pre 18:22 speed goes down, and the post-18:22 speed goes (way) up.
Map illustrating the basic geometry is here:
https://drive.google.com/file/d/0B-r3yuaF2p72Z2NfdzJ6VG9hZmc/view?usp=sharing
I have no dog in this fight. For years, I’ve questioned the veracity of ALL evidence held out to us as indicating MH370’s fate – growing concerns about the Lido Hotel image are, to me, a case of “throw it on the pile”. But I’d be shocked to learn that any decent analyst (inside or outside official search teams) who DID trust the military radar section of the FI report would continue, after reading it, to assume an N571 path.
All thoughts warmly welcomed. If this is a fair read of the FI report, then it would be very helpful to see how such an interpretation affects the solved-for speeds in the above chart. I am confident it would indicate a very different best-fit track.
Para 8: “plotted further west of where it would lie”: west should be EAST. Apologies.
@DennisW: I looked at your calculations more closely to resolve the discrepancy we have. I agree that the plane traveled 41 km during the 2.65 min @ 500 kn. But the change in range to the satellite is more like 21 km using real numbers. (I’m not sure how you got 4 km.) In rough numbers, the elevation angle is around 50 deg and the angle off the radial is about 34 deg (262 radial) so the component to the satellite is about 41 x cos(50) x cos(34) = 22 km, which is pretty close to the actual number. The BTO represents a round trip, so the change in BTO would be 22 / 3e5 x 2 = 147 μs, which is close to the more exact 134 μs I gave above, which includes the effect of satellite movement. Considering that the standard deviation of the R1200 data is only 29 μs, a track of 500 kn and 296T is extremely improbable. It represents an error of 134/29 = 4.6 standard deviations.
@Brock: Not that I’m blaming you, but this is going to get everybody confused very fast. You drew straight lines from the 18:02 point as I did above. But the N571 supporters draw the path as was presented in the Hotel Lido image, which produces a track of 296T after the last radar point at 18:22. And I don’t think you can use the cartoon in the FI to infer anything about actual positions.
If the Lido Hotel image shows targets that are MH370, there should not be much position or timing error in the 18:22:12 point depicted. The captures line up with some scatter along N571. And the time stamps match around 500 kn.
But in order to fit the BTO data, either there was a change in speed and/or track just after 18:22:12, or the Lido Hotel image is rubbish. And if the image is rubbish, there is little justification for concluding that sole capture on N571 after a 20-minute gap truly is MH370. It might be. But I’m less sure about it now than ever.
@Victor
Yes, you are correct, although I get a slightly different result of 115usec for the BTO difference between 18:25:27 and 18:28:06 at 296T and 500knots (added to link).
http://tmex1.blogspot.com/2017/02/mh370-position-at-182527.html
I used exact vector representations for the satellite, the GES, and the aircraft. (all WGS84)
@Victor
So help me out here. The standard deviation of the 18:28:06 measurement is 29usec. The standard deviation of the 18:25:27 measurement is 62usec. 29+62 = 91. There was a 20usec measurement difference i.e. 91+20 = 111usec. It seems to me that the error is within one standard deviation.
@DennisW: I didn’t check it, but the difference in delta BTO is probably from rounding, if you maintained the 0.1 deg resolution for the difference in coordinate positions. That’s about 11 km along orthogonal axes. Differential calculations over the time period of minutes need better precision.
More importantly, perhaps you now have a better appreciation of why we consider things like lateral offsets and the questioning of a path along N571. In my opinion, we are missing important pieces of the puzzle.
@DennisW: Let’s do this properly. Propose a starting position at 18:22:12, along with a groundspeed, and a track. Then we’ll calculate the error for each BTO measurement and see to see if the path satisfies a 2-sigma error criteria.
@VictorI @all
The video with the Vietnamees ConSon Island radar paragraph at 27:17
http://mobile.francetvinfo.fr/monde/asie/boeing-disparu/video-one-way-trip-for-the-unknown_2060246.html#xtref=https://t.co/N29p5EO7Em?t=1$cn=ZmxleGlibGVfcmVjcw%3D%3D$refsrc=email$iid=264c00b4994b4722b885ea9af9f649e6$uid=3932193797$nid=244+272699399
@Victor
I will do that, and post the results. There is no need to burden yourself. Right now I am going to kick back.
I will start at 18:22:12 at 500knots and a track of 296T. 18:22:12 position of 6.6N 96.3E.
It might be worthwhile to recheck the fit errors from IGARI
To see if the path really makes sense??
@Victor: I can make things really simple:
A cruising speed, great circle path starting from Pulau Perak and heading straight through (and beyond) VAMPI will fit the signal data as closely as does your great circle path from Pulau Perak to Car Nicobar Airport.
And the “VAMPI great circle” path has the advantage of agreeing to everything – pictures AND words – asserted about military radar in the FI report. Your Car Nicobar path doesn’t.
I do join you in bemoaning the opacity of search leaders – most notably on PDA/range limits, drift analysis, flaperon buoyancy testing, debris analysis, flight sim results, etc. And I consider the whole task of twisting the same data into a new path pretzel to be secondary to the task of holding search leadership accountable for how they spent the past three years.
But I’d like to think I’m scientist enough to stand up for academic rigour wherever we might find it lacking. It is one thing to chuck the Lido Hotel image – it is quite another to chuck the FI report. As my example shows, you don’t even have to.
@Dennis: By my calculations, for your proposed conditions, the BTO error at 18:25:27 is 12 μs (0.2 SD) and at 18:28:06 it is 124 μs (4.3 SD). It was the large errors for the BTO clusters at 18:27 and 18:28 that caused us to consider alternative paths (along with the BFO excursion, which we now ignore).
@Brock: It looks like the track for the path you propose is around 290T, which would make it close to Case 1 above.
Let’s make it so we are all doing the same calculation. Propose a time, position, track, and speed to start the path, and we’ll do the BTO and BFO calculations for the 18:25 log-on. Tell us how to treat the 18:02 and 18:22 radar points, if at all. Also, tell us if we should ignore N571.
@Ge Rijn: The document says that SSR and ADS-B symbols for MH370 dropped from the screens at HCM at the same time. It doesn’t say primary radar coverage was lost at this time.
@Victor. Yes, in concentrating on the equating I swapped the characteristics, though it makes no difference, the equating applying still.
For good measure I attach my theme expressed more in a quantitative way, the right way around now and using your revised figures. You will see the equilibrium altitude has changed from 25, 000 ft to 27,000.
https://www.dropbox.com/s/s1oenn9uh6tz33y/Depressurisation%20extent.pdf?dl=0
I go into this is in case depressurisation returns as a topic though right now it can be set aside as not the main game; which is route. Still, when you take a look again at your ‘packs on and outflow valves open’ non-linearity, it might help.
I should add one footnote, about trim air, since Don Thompson raised the possibility of one pack being turned off, both engines running. In that case trim air will be drawn from both engines even if one is not supplying pack air.
Thank you Victor, I appreciate the detailed response. We must be at the point where we’ve well and truly rung as much out of the available data as possible and now, quite logically, we’re re-evaluating the myriad assumptions. Your blog presents a wonderful mechanism for doing so in a collegiate and informed fashion (while clearly generating a lot of work for you), so again, thank you.
Like you, I rate the FMT sometime after 18:40 UTC as most likely and I’ve interpreted the 18:39:55 – 18:40:56 UTC BFO data as being a 61 second segment of a loiter that was repeated until around 19:23:30 – 19:25:00 UTC.
@Victor
So starting at 10nm past MEKAR on N571 and continuing (296T at 500knots) results in a location at 18:28:06 of 7.158N 95.558E.
Satellite to GES distance at 18:28:06 = 39271.9 km
Satellite to AES distance at 18:28:06 = 36884.1 km
Total distance x 2 = 152312 km
Calculated BTO is 12379usec
Measured BTO is 12500usec
BTO error is 121usec (too large to be considered).
So, you are correct and I am wrong. Reducing the speed after 18:25:27 is required. Did not calculate magnitude of needed speed reduction.
Calculations summarized at the end of this link:
http://tmex1.blogspot.com/2017/02/mh370-position-at-182527.html
@Victor:
Start from wherever you start from at 18:02. Fly straight at VAMPI. I can impute the required bearing for this if you absolutely need me to). If I’ve read DrB correctly, the required track is 291.6 – but if this misses VAMPI, then it’s not my path.
After reaching VAMPI, continue on exact same heading, to and thru the 18:25-18:28 arcs. Pick a speed that at least respects the signal data. My quick estimate is something in the 480-490 KGS range – but If it produces BTO values that are biased high or low vs. the log values, it’s not my speed.
I think you’ll find a hypothetical plane traveling in this manner would be roughly 10 nmi “past/north” MEKAR at 18:22:12.
To the extent this path grind gears with the Lido image, I really could care less. That is more of a general policy I have on “leaked” imagery held out to us as something official. Sounds like you are coming nearer to my views in this regard. But I would not be surprised if the above path actually came reasonably close to lining up with the blurs in that image.
One techie suggestion, likely not brand new: minimizing mean squared error is a technique which works best when the observations are a) large in number, and b) expected to produce errors which are mutually independent. For a process with a known “jitter” component – which may have embedded, e.g., sawtooth patterns – it may be more productive to compare the PATTERN of BTO errors to those of several benchmark error sets – each with a comparable number and timing of observations – sampled from a set of known variances. I don’t know whether the ATSB paper on jitter gives enough detail to extract such benchmarks – but it might.
If you can’t pick your modelled error set of of the crowd, you have a good fit.
@Brock
Minimizing such errors only apply to stationary and ergodic statistics. You should now know that is not what we are dealing with here.
@Dennis
Waypoint MEKAR is 6.503889°N 96.491111°E.
Waypoint NILAM is 6.756389°N 95.976389°E.
The track is 296.2829°T.
10 NM beyond MEKAR on Flight Route N571 is 6.5776°N 96.3408°E.
Continuing (296.2829°T at 500 knots and 35,000 feet) results in a location at 18:28:05.904 of 6.9401°N 95.6016°E.
Satellite to GES distance at 18:28:05.904 = 39272.1606 km.
Satellite to AES distance at 18:28:05.904 = 36885.9061 km.
Total distance x 2 = 152316.1334 km.
Calculated BTO is 12392.9322 µsec.
Measured BTO is 12500 µsec.
BTO error is 107.0678 µsec (too large to be considered).
BFO error is 0.498 Hz.
Reducing the average ground speed from 500 knots to 321.316 knots gives a BTO error of -0.2885 µsec and a position at 18:28:05.904 of 6.8106°N 95.8658°E.
However, the BFO error increases to 7.3495 Hz.
This is not the solution, we are looking for.
@Victor,
I understand your concern about the BTO errors being mostly one-sided with a 10 NM SLOP. I’m working on it, and I have an idea that may resolve it.
I finished modeling the warm-up transient. The results are surprisingly good. I am writing it up in a short paper, which I will post when it’s done.
@Brock McEwen,
You said: “One techie suggestion, likely not brand new: minimizing mean squared error is a technique which works best when the observations are a) large in number, and b) expected to produce errors which are mutually independent. For a process with a known “jitter” component – which may have embedded, e.g., sawtooth patterns – it may be more productive to compare the PATTERN of BTO errors to those of several benchmark error sets – each with a comparable number and timing of observations – sampled from a set of known variances. I don’t know whether the ATSB paper on jitter gives enough detail to extract such benchmarks – but it might.”
What I do is create an objective function that is minimized when the residual error statistics match their respective expected values. It does not minimize residuals; it gives them the desired (expected) RMS value and/or mean value. I use BTO error, BFO error, tailwind error, crosswind error, and PDA. In addition, my objective function terms are nonlinear in the difference between the error statistic and its expected value. Generally I set the objective function term to zero when the statistic is within the acceptable band, and to the signed square root of the difference when out of band. This form converges fairly rapidly, but with such little data, it is critical that the initial guesses for some of the parameter values be in the ballpark.
CORRECTION:
@David: Yesterday at 7:39 am I wrote:
“The trajectory with the most pronounced phugoid amplitude would be no.6, the one with the most southern terminus.”
For no.6 please read no.3 (both different shades of blue).
@Brock: There are many possible straight path solutions if you ignore the Lido Hotel radar image. That is one of the points I was trying to make in the post. If I start from the 18:02 point and point towards VAMPI as you suggest, the track is 291.09T. The speed to minimize the RMS error (20 μs) is 467 kn. The position at 18:22:12 is 6 NM to the northeast (44 deg) of MEKAR. If I increase the speed to 480 kn, the RMS error grows to 34 μs, which is probably okay. The position at 18:22:12 is 6 NM to the north (3 deg) of MEKAR.
On the other hand, if you assume that at 18:22:12, the plane was on N571 at 10 NM past MEKAR, traveling on a track of 296T and speed of 500 kn, in order to match the BTO sequence starting at 18:25:27, you have to incorporate a more complicated path after 18:22:12 than a constant speed and track.
If we had the raw radar data, we wouldn’t have to play this guessing game. The Lido Hotel radar image was shown to the NOK in a public setting with reporters present. It was used as proof at that time that MH370 traveled up the Malacca Strait. If this image is somehow false, and the only radar capture after 18:02 is the single point at 18:22 given to the ATSB by Malaysia, we have to ask how Malaysia associated this final capture with the targets captured 20 minutes earlier.
@VictorI
“we have to ask how Malaysia associated this final capture with the targets captured 20 minutes earlier.”
From the Inmarsat ping data? If I recall, wasn’t the Inmarsat ping ring data leading the way? I wonder if LIDO could have been based on an earlier draft version of the Inmarsat pings, they could have put 1822 point at the right space based on that, and then the ring placement changed a little bit. Then again we have the technical calculation of ping ring variation based on altitude. That’s why I let you guys handle that satellite stuff.
Do you like SAMAK? Holding pattern could have been at SAMAK somewhat similar to Mick Gilbert’s idea. In any case, I like how SAMAK comes up at 1840. I had seen this a few weeks ago with @Nederland’s path.
@David: Using the FSX PMDG 777 model, the cabin altitude does not asymptotically approach the steady state valve predicted by setting the rate equation to zero. I tested that some time ago and put things aside and move onto other things when I realize that I couldn’t superimpose the limiting cases, as I should have been able to do with a linear system.
I did some more tests yesterday and discovered the source of the discrepancy. In the model, the rate of decrease of the cabin altitude attributed to the air packs (and trim air) is a function of the outflow valve position. (This seems to not correspond with reality, but I can’t be sure because I don’t know how the air pack flow is controlled. As an aside, the duct pressure doesn’t seem to be affected by valve position.) With the valve positions closed, the cabin altitude falls at about 1300 ft/min due to the air pack flow. However, with the valves fully open, the air packs (and trim air) have no effect on the rise of cabin altitude. In fact, in the model, with the valves fully open, the cabin altitude rises asymptotically to the altitude.
If you want an equation, you can use this one:
d(CA)/dt = k(V^0.3)(A-CA) – (1-V^0.3)Q
where CA is the cabin altitude (ft)
A is the pressure altitude (ft)
k is 0.15/min
V is the valve position of both valves with V=1 indicating fully open
Q is the fall in cabin altitude from air pack flow = 1300 ft/min
The exponent of 0.3 is introduced to more accurately represent the actual valve position that I observe in the model for various conditions. You can ignore it if you don’t care about the true valve position.
Using this equation, you can find the steady state CA for a particular valve position and A. Or, if the valves are automatically controlled, you can estimate the valve position for a given CA and A.
Some other observations:
1) As you note, turning off one air pack doesn’t turn off the trim air on that side.
2) There is no trim air available without at least one air pack on.
3) The value of Q doesn’t seem to depend on whether one or two air packs are on or on the configuration of trim air. Q falls to zero by turning off both air packs or turning off bleed air from both engines.
4) Because of cross-connections, bleed air from one engine can maintain pressure in both ducts. Unless bleed air is turned off for both engines, the duct pressure remains around 50 psi.
I don’t see much point in taking this any further. The PMDG model is now relatively well described, whether or not it describes reality. The equations can be used to calculate depressurization and repressurization transients.
@Richard
I like your descriptive style, Richard. 🙂
The location you derive for 18:28:06 is very near to where the the 18:25:27 range ring crosses N571. No surprise at all there since the 18:25:27 BTO is 12520 and the 18:28:06 BTO is 12500.
I still like 500knots on N571 after 18:22:12 which does work out well for the BTO and BFO at 18:25:27.
It would appear that a maneuver to the North, virtually parallel to the 18:25:27 range ring, is about the only way to salvage the situation i.e. Victor’s lateral offset. Of course, tossing the 18:22:12 radar point and N571 in the trash which is now being considered is another approach.
I vowed not to get involved in the path modeling between 18:25:27 and 19:41 declaring it to be a waste of time. I was right.
@TBill: I doubt the 18:22 radar point is based on the ping arcs.
Here’s one possibility. Let’s suppose the 18:02 radar point was the last capture that could be associated with MH370 with high confidence. Let’s also assume that at any one time there are numerous “false” targets attributed to birds, weather conditions, reflections, etc. The algorithm used by the radar system might try to associate unknown targets with previously identified targets by extrapolating paths based on last estimated speed and track. So, a false target seen along the last estimated track at 18:02 might be associated with MH370 if it was along the same track and at a reasonable distance based on the last estimated speed. In that sense, our logic might be backwards. We tend to assume the last capture was MH370 because it falls on the same track. But in fact the algorithm might have chosen this particular target among many unknown targets because the track matched the last estimated track.
As for the path with SAMAK, I haven’t looked at it closely. There are many paths possible, and it is hard to select one over another.
@Victor: thanks for producing and reporting those figures. Personally, I would have grabbed the path you used at the VAMPI waypoint, and given it a 1-degree clockwise twist. This would have my 18:02 starting point match Dr.B’s (I’m guessing his 18:02 point is a couple of nmi south of yours), add a few knots to each of your reported speeds, and add three or four knots to the distance from MEKAR at 18:22. But please don’t bother re-running – we are on the same page.
I’m glad you agree many constant paths satisfy both 18:02 and the signal data. I hope you agree that some of these also satisfy the FI description of 18:22.
I am fully supportive of attempts to reconcile the evidence we’ve been given to the empty search box. But when such an attempt requires that we reject one shady bit of evidence – yet trust all the other shady bits – it is going to be a tough sell. Perhaps the WHOLE official narrative is as dodgy as the Lido image; that is certainly what the behaviour of search leadership would seem to suggest. Such a conclusion would also finally permit a plausible explanation for what happened to MH370: something that needed to be covered up.
I am in agreement with @Brock
“the WHOLE official narrative is as dodgy as the Lido image; that is certainly what the behaviour of search leadership would seem to suggest. “
Regarding the 1825 – 1828 BTO’S:
Before starting any detailed calculations I’ve plotted the BTO vs. Time for all values except 18:25:34. I extended the graph back to 18:22:12 by assigning a 12740 us value based on the 6.58, 96.34 assumed position. What I notice is that there is reasonable fit with a linear trend from 12740 @182212 to 12480 @182814, except for the 18:25:27 value. Based on the trend one would expect 12600 us. Not sure if an error of 80 us is acceptable? (Didn’t have time to study the BTO error statistics in detail yet)
So just at first glance I tend to examine this measurement point more closely.
@Niels: The BTO value at 18:25:27 is from an R600 channel. We are told the standard deviation for R600 data is 62 μs. For R1200 data, it is 29 μs. Your path meets the BTO criteria. But you also have to consider the BFO criteria. The slope of the BTO v time curve roughly varies as speed * cos(track – 262). The BFO value is roughly a constant + a term proportional to speed*cos(track). I think you’ll find you that paths that satisfy the BTO and BFO don’t align with 296T.
@Richard
http://tmex1.blogspot.com/2017/02/bto-error-scatter-plot.html
@Richard
Once again we are being misled by DSTG statistics. While they have fitted a Gaussian to the accumulated BTO data and claim a mean of 29usec, the data is, in fact, not Gaussian distributed. There are far more outliers than would be associated with a true Gaussian distribution.
Basically I am going back to my original thesis of a flight path from 18:22:12 to 18:28:06 at ~296T and 500 knots.
@DennisW: Looking at the figure in your blog, I count 20 points with greater than 100 μs error over the course of 5 days. That averages to one point every 6 hours.
Yet, if accept the 18:22:12 radar point and a constant path at 296T and 500 kn, of the 6 BTO values we have from an R1200 channel over the course of 71 seconds, I calculate that 3 measurements have errors greater than 100 μs, and all have errors greater than 2.5 sigma.
Unless there is systematic error of some type, that doesn’t seem very likely to me.
@Victor
“For R1200 data, it is 29 μs.”
Saying things like this is simply so wrong relative to modeling the problem. Suppose I take 100 samples of something and 90 samples have a value of 0 and 10 of them have a value of +/- 10. I can say that the standard deviation of the distribution is around 3. Is that a valid reason to discard a sample value of +10 or -10 because it is three times larger than the standard deviation?
You have gotten sucked in (again) by attributing properties to the BTO and BFO data that simply do not exist. It is reminiscent of the time when pins were being stuck in the map at 38S. This time you even sucked me in.
@DennisW: OK. Let’s put aside standard deviation. Just look at the occurrence of errors greater than 100 μs. The average rate is one every 6 hours based on previous data. Yet, for path with 296T and 500 kn, we have 3 in 71 seconds. That doesn’t seem very likely.
@Victor
All of the values were obtained after a logon request that no one is able to explain. It is very hard for me to take comfort and trust in data logged under these circumstances.
I really believe that there is substantial risk in creating a model based on this data.
BTW, your one every six hours metric assumes the aircraft is operating continuously over five days which it certainly was not.
@VictorI
The linear BTO trend corresponds to dr/dt = -107.7 m/s where r is the sat – ac distance. To get to 296T I have to combine this with a Doppler residual of 14 Hz (BFO 138 Hz). The corresponding GS is 418 kn. (Based on velocity vector calculation, level flight assumption)
18:22:12 pos. 6.58, 96.34
18:28:14 pos. 6.88, 95.71 (based on vector integration)
I think the BFO at first look is within error limits. However: a concern I have with this is the level flight assumption. The speed could indicate a descent was already ongoing, in which case the BFO error at 18:28:14 could be considerable.
@DennisW: You are free to discard the BTO data at 18:25 because you believe it is somehow corrupted. I am more inclined to accept the possibility of a lateral offset or problems with the radar data. The purpose of this blog is to explore other possibilities, not to persuade anybody of a particular scenario. I won’t chide you for sticking to your guns.
As for the statistics of BTO errors greater than 100 μs, let’s forget occurrences per unit time and just look at occurrences per number of measurements. There are 20 occurrences out of many (1000? probably many more) measurements. Yet, at 18:25, for the proposed path, we see 3 out of 6 measured values with errors greater than 100 μs. The rate of occurrence is still astronomically high. Either the path is wrong, or the SATCOM was functioning atypically.
@Niels: Once you accept errors of 14 Hz at 18:25 and the possibility of vertical speed, the combination of acceptable parameters becomes quite large, whether or not constrained to 296T. We have too many dials and not enough solid evidence.
@Victor
Fair enough. BTW, I am inclined to use the BTO and BFO at 18:25:27 since they are compatible with the last radar point at 18:22:12. I am mistrustful of the BTO at 18:28:06.
No matter. I am certainly not being critical of your approach. I simply do not buy into it.
@Victor: The 14 Hz is the Fup+Fcomp term I used. (Corresponding to BFO = 138 Hz)
Not sure how to compute BFO errors during the alleged thermal transient period..
So far I do not see direct need to throw out the last radar point.
I do see some potential issues regarding the accuracy of the first BTO in logon: there should be an additional error assigned to the 4600 us correction term. How large is it?
@Victor
Just for completeness…
“There are 20 occurrences out of many (1000? probably many more) measurements.”
A four sigma error is equivalent to 20 occurrences in 330,000 samples. The simple truth is that using a 29us sigma as a filter is not correct. The DSTG has fit a normal distribution to measured errors that are not normally distributed. Same with their BFO statistics.
@Niels: Supposedly, by the last data point at 18:28:15, there is little error due to the thermal transient, which causes the BTO to be high, not low.
I tried your radar position of 6.58,96.34 at 18:22:12 with a geometric altitude of 35,000 ft and ground speed of 418 kn. I get a BTO error at 18:25:27 of 35 μs, but the next 6 R1200 measurements have an RMS error of 55 μs, which seems high. A speed of 368 kn brings the RMS error to around 30 μs.
@Victor: I based my calculation on 10 km altitude. Not sure if that explains the 55 us, which indeed seems a bit high. I’ll re-check.
Would you know if there is an indicative relation known between TAS and steady altitude for B777, possibly for different weights? It would be helpful,to keep these kind of calculations somewhat self-consistent.
I’m not sure if you are aware of the theory that the transmission bit rate used by an Aircraft Earth Station, aka a SATCOM, during log on is different from that used during normal communications. According to the Malaysian Government’s “Factual Report” on the disappearance of 9M-MRO flying route MH370, when it first logged on to the Inmarsat system it did so using the Low Gain Antenna, and again when it transferred from the Inmarsat 3-F3 satellite over the Pacific to Inmarsat 3-F1 it used the Low Gain Antenna. The Factual Report doesn’t specifically state the LGA was used at the 18:25 log on sequence, nor at the 00:19 log on sequence, but the report doesn’t say it wasn’t, which could easily mean the LGA was actually used.
The LGA uses a different method of modulating the data to be sent from that used by the High Gain Antenna. According to the Factual Report the LGA uses a Class C amplifier, while the HGA uses a Class A amplifier. Two important differences between these two systems is the Class C amplifier has essentially a limited frequency range and basically one power output level, while the Class A amplifier has a wide frequency range and a wide power output range, so the Class A amplifier is better suited to higher bit rate transmission protocols, while the Class C amplifier is better suited to the low bit rate transmission protocols.
If a lower bit rate transmission protocol was used during log on then one would expect the BTO to be different from that used by the HGA, which it is.
@Niels: For a typical speed, you can assume Long Range Cruise (LRC) conditions, although more typically a pilot would choose ECON speed, which is similar, but has a Cost Index (CI) parameter to weigh the cost of fuel and time. (The ECON speed is also affected by wind.) Here is the link for an LRC table for the B777-200ER with RR Trent 892 engines. At 18:25, the weight was about 210 MT. If you choose a pressure altitude, you can find the LRC speed, expressed as Mach and Indicated Air Speed (IAS). That combined with a temperature offset from ISA of about 10K should give you the TAS.
@Gysbreght. Figure 6, p13 of the ATSB Search and debris examination paper again. Thanks for your comments on phugoids. They do say at their 5th dot point that, “In some simulations, the aircraft exhibited phugoid motion throughout the descent”. I assume therefore that they are not those where the spiral radii expand and contract, or that they are not illustrated in the figure.
Extending this discussion (main points at bottom, including the muddle about the 7th arc log-on):
https://www.dropbox.com/s/fceov6sty8ic5ii/Further%20comments%20on%20ATSB%20Search%20and%20debris%20examination%20update.docx?dl=0
@Victor @Dave
I attempted to check Depressurization rates- Simulator versus Theory.
B777 Cabin Pressure Altitude: 6000-ft
B777 Altitude: FL350
B777 Blend Air: None (I assumed no incoming air – is that possible?)
B777 Outlet Valves: 2
B777 Outlet Valve area/per valve: 90-square inches (found this need verify)
B777 Outlet Valve equiv. diam.: 5.25-in est.
B777 Outlet Valve % Open: 100%
B777 Air Volume: 47,000-ft3 (my est.)
I iterated every 30 secs. I calc’ed about 4800-ft/min almost a straight line to FL300 within 5 minutes.
The flow starts out choked/sonic. I assumed this on-line calculator was accurate (need to verify):
http://www.tlv.com/global/TI/calculator/air-flow-rate-through-orifice.html
(Link does provide depressurization equations)
I also guessed a polytropic exponent of 1.09 which cooled the cabin to about 28 deg F after 5 minutes, but temp did not seem to be a huge impact on the numbers.
@Victor. A short feedback on your modelling thank you.
• We have the same equation, outflow valves open, which could be expected if manually selected.
• The V^0.3 term is interesting though you may not mean to apply it to inflow Q, as it would with V<1. Inflow should be insensitive to outflow and earlier you noticed no sensitivity even to that integrated with time, ie back pressure.
• One pack will supply most needs I think so two would halve the load on each, Q then being unaffected. There are flow schedules which depend on the number of seats etc but from my earlier reading I recall no input to the controllers from outflow valve settings/cabin pressure. As I understand it the principle is that the packs and trim supply what air is needed for ventilation and heating/cooling, cabin pressure being left to the outflow valves, short of excesses.
• I agree that there is no more to be gained here.
The public spirited effort and expertise you are putting into running this focussed site while researching and discussing is salutary.
@TBill. Yours just in, thanks.
@TBill. Some thoughts on your cabin altitude post:
https://www.dropbox.com/s/52g5d9qrabjxhrp/TBill.docx?dl=0
@David: Thank you for your comments at 12:01 am today. First a general point about the ATSB’s comment on phugoids: “In some simulations, the aircraft exhibited phugoid motion throughout the descent”.
By definition, a phugoid is a slow pitch oscillation at constant angle of attack. Since the angle of attack is constant in an uncontrolled descent, in a sense all these descents are phugoids, but the amplitude of the oscillations is greater in some simulations than in others. That amplitude depends on the difference between the initial pitch attitude and the pitch attitude for a descent at constant speed. The period T of the phugoid is given by T = PI*2^0.5*V/g in consistent units, e.g. V in ft/s, g in ft/s^2 gives T in seconds.
Replying to your extended comments:
– Yes, all tracks are aligned to the point where they cross the 7th arc, which is two minutes after te loss of electrical power from the engine, about 25 km earlier, about halfway between the top of the chart and the point of alignment, where the tracks start to turn.
– Yes, the ATSB report does not state which engine fails. Apparently the one-engine-inoperative tracks are no.s 7, 8 and 10 (see chart below). I assume that no. 9 is with both engines failed, and the airplane trimmed for one engine inoperative.
– Yes, possibly.
– The only way I can explain the turn at the bottom of no.10 is if the flight path became nearly vertical, and in the final straight segment the airplane pulled out of the vertical dive with wings approximately level. Apparently this was accomplished while the simulator remained within its database. The database was exceeded only in tracks no. 3 and 7.
– Simulations 3, 7, 8, 9 and 10 “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.”
– I think the concluding dot point refers to uncertainties in the position of the 7th arc due to altitude and errors of measurement in the BTO values.
– On your last dot point I think the ATSB means that after the APU restarted and ran out fuel, it may have restarted a second time later in the descent. As I explained with my lorry analogy, I don’t think that is very likely to occur.
I have asked the ATSB which aspects of the scenario could explain that track no.3 is so special in comparison with others in the group 1 – 6.
Figure 6 of ATSB report of 2 November 2016:
https://www.dropbox.com/s/z02p174h4kdybad/BoeingSims.png?dl=0
@Victor: Many thanks for the LRC table and related info.
Concerning the BTOs between 18:22 and 18:28; I found an inaccuracy in my calculations (earth radius around equator should be 6378 km, not 6371 km.
It means I now assign a value of 12700 us to the 18:22:12 position (10 km altitude). The linear trend suggests an error of around 70 us in the 18:25:27 BTO.
Based on the linear trend I calculate dr/dt = – 91.1 m/s which should be matched with a D = 12 Hz to give 296T. The resulting GS is 354 kn, pretty close to the value that you suggested.
18:22:12 pos 6.58, 96.34
18:28:14 pos 6.84, 95.81 (based on velocity vector integration)
D = 12 Hz corresponds to a BFO of 136 Hz. As such the BFO error around 18:28 may still be acceptable. However: the rather low speed is not compatible with maintaining a high cruise altitude, so either a speed reduction started earlier, or the ac would be descending resulting in a larger BFO error, or the radar position + 296T straight assumption is not correct.
Actually I find the early descent hypothesis interesting to explore further in the context of (sudden) loss of radar contact.
Assumption 1: The last 10 second radar point at 18:01.49 UTC was 5.624829°N 99.048157°E.
Assumption 2: The BTO of 12,480 µs and BFO of 143 Hz are settled and accurate at 18:28:14.904 UTC, after 167.483 seconds from the start of the Log-In at 18:25:27.421 UTC.
Assumption 3: MH370 flew at a constant Ground Speed of 493.737 knots and a constant altitude of 35,000 feet on a constant track of 295.6630°T, between 18:01:49 UTC and 18:28:14.904 UTC.
Result: MH370 was at a position of 7.1937°N 95.7622°E at 18:28:14.904 UTC, which matches the BTO and BFO perfectly.
Here is a link to the flight path, which misses the 18:22:12 UTC radar point by 18.6 NM:
https://www.dropbox.com/s/t5doijxw8pv6eug/MH370%20Flight%20Path%20V16.0%20RG.pdf?dl=0
The Lido slide showed the radar point as “TIME 02:22H 295R 200 nm from Butterworth AB”.
At 18:22:12 UTC, MH370 appears to be tracking 289.6°R “R” for Relative to Butterworth AB at a distance 245.5 NM. MH370 appears to be tracking 295.6°A “A” for Absolute relative to True North.
The Malaysians got both the bearing and the distance wrong on the Lido slide. What else did they get wrong?
@SDU experts: Could cabine temperature be a factor in SDU ceasing operation after the turn back, and the restart around 18:25? The specified min. operating temp. I could find is -55 C for MCS7200.
@Richard
Nice. I will check your numbers later today, but do not expect to find anything amiss.
Our styles differ relative to precision (493.737 knots ??), but no matter. I also have no issues with 10nm here or there. If I can get within 50nm of the right position on the 19:41 ping arc, I will be delighted.
@Niels: First, if you want to compare your results with others here, I suggest you migrate towards the WGS84 description of the earth, including the proper conversions for LLA position and ENU speeds to ECEF coordinates. (It’s more complicated than just using the WGS84 radius with the geocentric equations.)
I think we finally have agreement that the following statements can’t both be true:
1. The plane followed a constant track of 296T and 500 kn along N571 from 18:22:12 through 18:28:15.
2. BTO errors during the log-on from 18:25:27 to 18:28:15 were typical.
People here have proposed the following possibilities for resolving this:
A. Some of the BTO values are not valid due to abnormal behavior of the SDU. (The BTO values were not typical.)
B. There was a lateral offset to the right of N571 completed by 18:28:15. (MH370 did not fly at constant track and speed.)
C. The plane followed a constant track and speed, but different than 296T and 500 kn. (MH370 was not following N571 during the 18:25 log-on.)
@TBill: Thank you. The choked flow equation will of course give the upper limit on flow.
@David: In the PMDG 777 model, there is definitely a dependency of the inflow from the air packs on the outflow valve position, as I represented in the equation. (I confirmed this by turning the inflow on and off for different cabin altitudes and valve positions. The change in cabin altitude rates between inflow on and inflow off was definitely a function of valve position. There was no change for valves fully open, and a difference or 1300 ft/min with valves fully closed.) Perhaps there is control logic associated with the air packs to achieve this. If there is no dependency of inflow on outflow valve position, the PMDG model is wrong. I am fairly certain I mathematically portrayed the PMDG model accurately.
Thank you for your comments about the blog. I hope it ultimately provides some benefit. It’s still early to make that determination.
@Richard
The other marking on that Lido graphic, the 279R 89Nm, is correct if,
again, ‘R’ is relative & the position of MH370 was a bit more than 4 Nm
North of Pulau Perak (which is still at a high enough angle for an
observer on the Island to consider it ‘above’), and the Butterworth
position is measured from the radar site, which appears to be slightly
east of the actual WMKB runway.
https://www.google.com.au/maps/@5.4720648,100.3946047,95m/data=!3m1!1e3
___________
The 295R 200Nm could be correct, if you regard the words “from
Butterworth” to be a attributational, rather than a locational,
reference – & consider the 295 is ‘Relative’ to the position of e.g.
a Singapore AWACS aircraft 200Nm further along N571, travelling SE
and offset (SLOP) 2Nm to the right (south) of N571.
away
@Victor: In principle you are of course right in your suggestion to implement the accurate earth description. However: for the explicit path generation tool it may be a hell of a job to do this, just to gain a few km precision. For most purposes, given the possible errors in the BFO and BTO data and unknown flight levels all this double digit precision coordinates suggest more accuracy than there is..
Despite my “sloppy” calculation I hope you appreciate my suggestion D:
Between 18:22 and 18:28 MH370 followed N571 (296T) however at significant lower speed than 500 kn. A descent may have preceded or finished somewhere within this time interval.
@Niels: I agree that the available “evidence precision” is much less than our “model precision”. I only made the suggestion if you want to be able to precisely compare your results with the results of others using more precise models. In the past, I have been able to find small errors (due to things like typos) by running tests and comparing to the results of others.
I would view your D. as a special case of C. You agree on track but not speed. Implicit is allowing a larger BFO error.
@VictorI
Indeed the ConSon island radar paragraph doesn’t mention primary radar.
The 270 miles range mentioned got me off guard assuming they where talking also about primary radar there.
Still makes me wonder what the Vietnamees primary radar data are.
Another thing. On the ‘Lido-image’ there’s not only this ~6 minutes gap after Pulau Perak till Vampi but also a ~same gap starting from Penang till 1:59am.
Assuming the ‘Lido-image’ actualy represents MH370 what could be the reason of this earlier gap?
I assume(d) it could be due to MH370 initially descending towards Penang flying low(er) altitude over Georgetown where the cellphone of the co-pilot was picked up (and nowhere else if we can believe the news).
Crossing the island on low(er) altitude and becoming visible again to primary radar only when it climbed back to higher altitude.
Other explanation available about this gap?
@DennisW,
Have a look at the RCS of a B777:
http://www.piers.org/piersonline/pdf/Vol5No4Page377to380.pdf
As shown in Figure 4, changes of 10-20 dB are guaranteed over a few degrees in angle, and you can get ~40 dB over 45 degrees. No wonder the radar tracking was spotty at long range. I think if a turn occurred near 18:22, that could have resulted in returns below the detection threshold.
@Victor
Consider the BTO values below:
BTO @18:25:27 = 12520
BTO @18:25:34 = 12600
80usec of difference in 7 seconds.
Now ask yourself how far a plane can travel in 7 seconds. At 926km/hr (500knots) it can travel 1.8km. If that distance was along a radial to the satellite (which it is not) the difference in round trip distance would be 3.6km. 3.6km divided by the speed of light is ~12usec.
Not only is the difference incorrect, but the 12600 value suggests the aircraft was farther from the satellite at 18:25:34 than at 18:25:27.
@Richard
I checked your values. They are spot on.
Regarding loss of radar contact:
I’ve estimated the critical altitude for dropping below horizon, if Western Hill was the radar involved.
Distance from Western Hill to last radar point: 452 km
Wester Hill altitude: 800 m
Using sqrt(2Rh): Western Hill to horizon 101 km
This leaves 351 km for MH370 to horizon
Again using sqrt(2Rh) this gives h = 9.7 km
IMO an indication that drop below horizon could be the cause of lost radar contact. Not conclusive with respect to the question if a descent was possibly involved.
@DrB
Your paper is a study at X-band.
I believe, on memory here, that the Western Hill radar is a RAT 31 DL operating at L-band. The radar cross sections are very different at L-band and X-band.
X-band is not favored for military radar because the attenuation in rain is severe. L-band (GPS for example) is normally used when atmospherics are important.
@ Dennis: Many thanks for checking my values. Nice that you agree!
@buyerninety: Assuming the Butterworth Radar to be located at 5.472116°N 100.3944586°E as shown in your Google map and in the French TV Envoye Special, then the flight path with a track 295.6630°T and average Ground Speed 493.737 knots from 5.624829°N 99.048157°E, almost fits the Lido slide regarding Pulau Perak which also contains the statement “TIME – 02:02H PERAK ISLAND 279R 89 nm from Butterworth AB”.
My track places MH370 at 18:02:41.874 UTC at 5.6771°N 98.9388°E, just off the southern tip of Pulau Perak.
This point is on a bearing of 278.1°T from the Butterworth Radar at a distance of 87.9 NM.
Interestingly, Bill Holland’s deciphering of the Lido slide, shows a time at Pulau Perak of 02:02:48 local.
So there appears to be a bit of rounding going on regarding the radar data points on the Lido slide, when compared with the labels.
Neils: An extremely low cabin temperature could have caused an additional 10-20 Hz BFO bias error, but it would have continued to work normally otherwise.
@David @Victor
Thank you for the depressurization comments.
@Victor
At the moment, I assume the calculator I used is correctly modeling the transition from choked flow to non-choked flow. If it was choked flow all the time, I would have tried to do that calc in Excel by myself.
Thus, pending further review, I am tentatively suggesting the equations in PMDG777 are not rigorous. More like typical curves, and curves for the case where bleed air is coming in. Of course, I am not yet sure about what I am suggesting.
@David
Part of the reason I am looking at this is, I have the air safety idea that the control logic of the outflow valve could possibly in the future be modified to disallow intentional depressuring above say FL200.
So I am looking at it from the perspective, is it possible for a hypothetical hijacker to go 100% open the outflow valves, and shut off the bleed air? I know I can flick the switches on the overhead panel on the PSS777 model, but the cabin pressure equations do not seem to show a true behavior. PMDG sounds a little better but also perhaps just directional not rigorous.
As far as temp drop on depressuring, I assume the airline industry may have complex models for that so I am just taking a stab at it. The real world case is very complex as we have adiabatic cooling offset by heat exchange with the surroundings and possibly warm bleed air.
@TBill: For this kind of slow depressurization, I think that isothermal expansion of the cabin air is more accurate than adiabatic. There is a lot of thermal mass and a lot of area for heat transfer.
@ALSM
Yes, I agree with your cabin temp comment which is why I do not believe a decompression event took place before 18:25. Could be wrong, but I don’t see anything to support a decompression either.
@Richard
I am OK with your path. Your 18:28 location is some 18nm above where I would have dropped a pin with a more casual analysis. I am not going to get excited by differences that small. To me, the important question is what happened in the next hour or so.
@DennisW: You have to apply measurement uncertainty to the two BTO values you cite before you can declare a path improbable. There are many acceptable solutions of straight paths from 18:02 through 18:28 that meet the BTO and BFO criteria during the 18:25 log-on. For instance, if you start at 18:02 at 500 kn on a track of 295.6 deg, the BTO error at 18:25:27 is 83 μs (1.3 sigma), and the RMS error for the next 6 BTO values is 30 μs. Meanwhile, the BFO error at 18:28:15 is zero.
@Victor
My bad, loose use of “adiabatic”…I agree totally. I think the correct word is isotropic, which is the middle ground somewhere between adiabatic and isothermal. Adiabatic cooling would be -85F.
@TBill: Polytropic works, I think.
@Victor
Yes polytropic is the correct word.
@Victor
Yes, we are in agreement. I want to move on, not beat the 18:02 to 18:28 issue anymore. Pick a spot at 18:28 that feels good, and consider what happens next. Please…
@Richard
So where is the pilot heading in your flight path?
I anticipate your answer is probably he entered Waypoint 1090E into the LNAV. So much for my idea (SAMAK). At least SAMAK at 18:40 I can envision making maneuver to fit the BFO. But wow 1090E sounds familiar from the home simulator cases.
@ALSM
Mike, thanks for your reply regarding cabin temp. effects. I have some questions about the crystal oscillator:
1. May we assume it crystal is SC cut?
2. What is the approx. operating temperature, is it where the slope of the freq.vs. temp. graph is zero?
3. How does a 1 ppm change in the 10.08 MHz (?) ref. freq. reflect in the (much higher) uplink frequency?
Neils:
1. Yes
2 75C
3. 1ppm @ 10.08 MHz results in 1ppm for all other clocks and LOs and the carrier frequency.
@ALSM
Mike, thanks, it corresponds with my expectation. But then, if I read the typical freq. vs. T curves correctly, your earlier statement (about 0.01 ppm changes in very cold ambient) translates in crystal temperature variations of about 1 degree max.. Is that indeed what is assumed / is there experimental evidence supporting this?
I’m not sure what to expect once the oven is at its power limit and ambient temperature drops further.
@DennisW,
1. The RCS paper was on a scale model aircraft at 9.4 GHz. The RCS measurements are the same as viwing the full-scale B777 at about 100 Mhz. I’ll look for some full-scale RCS data, if it exists.
2. The difference in the LOR and the LOA BTOs at 18:25 is 80 +/- 137 microseconds (2 sigma). They are both consistent with all values from 542-644 Hz.
The PID control means zero static temp error over the full operating temperature range. The 10-20 degree drift results from temperature gradients within the thermal envelope. IOW…there is zero error at the setpoint measurement point, but not everywhere inside the envelope.
I meant 10-20Hz.
@TBill
You asked “@Richard
So where is the pilot heading in your flight path?
I anticipate your answer is probably he entered Waypoint 1090E into the LNAV. So much for my idea (SAMAK). At least SAMAK at 18:40 I can envision making maneuver to fit the BFO. But wow 1090E sounds familiar from the home simulator cases.”
Indeed 1090E is close to the track.
The waypoint SAMAK is close to the track.
The 4th data point recovered from ZS home simulator (10.183126°N 90.224518°E) is close to the track.
The restricted area VOR-192 around Car Nicobar is on the track.
I think we have come full circle back to having to look seriously at the evidence from the RMP report regarding the home flight simulator of ZS.
So my answer is the final way point was YWKS as proposed in my paper entitled “The probable End Point of MH370” that Victor published in his previous post “More analyses of MH370 data”.
@Richard said;
“So there appears to be a bit of rounding going on regarding the radar data points on the Lido slide, when compared with the labels.”
Yes, I’ll agree it’s not unreasonable to assume that.
There is also actually some other details that tend to support your
theory that MH370 passed slightly to the SouthWest of Pulau Perak.
The ‘Folder Appendix (1).pdf’, appendix K-2, has a picture of the
postulated track of MH370 under Penang Island. The flagged locations
are probably plot points from the ‘uncalibrated radar’. The author of
the picture has done a simple ‘join the flag locations’ exercise, and
those straight lines where MH370 is represented as passing under
Penang Island, we could consider as actual slight curved lines.
(Also, the author has simply drawn the straight lines between the
bottom of the flags, rather from the base of the flags staves which is
where one would assume each individual radar plot would actually be
located.)
On the right of the picture is a flagged plot point that the author
has not bothered to draw a line to – instead (I assume) the author
decided to rather simplistically draw a straight line directly to
Pulau Perak.
Observing the other picture, which shows Pulau Perak, we see that the
author ignored a number of flagged plot points occuring after Penang
and again rather simplistically drew a straight line to Pulau Perak.
If we, however, consider that MH370 did approximately pass near those
(uncalibrated) plot points, as MH370 might have done as it proceeded,
banked, to fly-by waypoint KENDI at the 0.87 Mach setting, then
the general line of the ignored plot points suggest MH370 lessened and
concluded its bank & then straightened onto a course heading towards
VAMPI – such a course from about the last plot point would pass to the
South West of Pulau Perak.
________________
(There is also a minor clue that no-one has noticed which raises the
probability that the plots points are in their approximate true
position, {despite the ‘uncalibrated radar’}, which I will explain in
a future post.)
Cheers
@ALSM
Ok, clear, and this estimate holds all the way to -55C?
Neals: At least -55C.
@DrB
Good point. Perhaps the x-band scales with the model size, and everything comes out in the wash. Had not thought about that.
@DrB
Yes, sqrt(29^2 + 62^2) = 68.5 => 2 sigma = 137.
My point is that the BTO error bands are large enough to admit of many different paths. I don’t really believe it is possible to narrow it down all that much based on BTO fitting. I am happy with Richard’s path and a couple of other not too different paths. I am much more concerned with what happens between 18:28 and 19:41. My take on it is that the aircraft is definitely headed South by 18:40. Can’t reconcile the BFO at 18:40 with any other conclusion. If that is the case, then it would seem likely that a latitude value near 1N – 2N (or even further South) is likely at 19:40. I am not real happy with that result since it is harder to get paths above 32S at 00:11. I was hoping for a result that was more in tune with 7N – 8N at 19:41. I don’t see that happening.
@DennisW
Re: My take on it is that the aircraft is definitely headed South by 18:40. Can’t reconcile the BFO at 18:40 with any other conclusion.
Definitely heading south at 18:40 doesn’t necessarily mean that that segment of flight path definitely represents part of the final leg south; at 18:40 we could be looking at part of a loiter. A loiter opens up the possibility of FMTs much later than 18:40 which in turn allows for paths that terminate north of 32S.
@Mick G
Yes, I was thinking the same thing. Perhaps some kind of a loop.
Dennis W,
A “loop” means something entirely different in aeronautical language. Hard to imagine a loaded 777 doing that. On the other hand, an “orbit” [i.e. a circle in the horizontal plane] might be entirely possible. An orbit can use up time, a snapshot at a particular time [i.e. a BFO] can have the aircraft heading in almost any direction, and upon leaving the orbit after approximately (2n+1)*180 degrees of rotation to the left the aircraft can head off into the SIO.
It is possible to fit an orbit to almost any path in order to link the segment up the Malacca Strait with a more northerly latitude for the 19:41 BTO. I had some fitted to paths way back in mid 2014.
@Brian
I don’t have an aeronautical vernacular, and do not intend to cultivate one, so get off that shit. By loop I simply meant circling back North.
@DennisW
Yes, I understand what you mean; an orbit, a race-track or a figure 8 pattern are all reasonable fits, the latter pair in particular if you consider bank-limited turns.
@Gysbreght. Fig 6 simulations. Thank you for your responses: apparently you have obtained more information on this.
My concern remains though about whether the ATSB still sees an APU auto-start as what prompted the 7th arc log-on.
The full quote from the bottom paragraph, p14 of their, ‘Search and debris examination update’ is, “However, in a real aircraft, various aircraft attitudes may result in unusable fuel (usually below engine/APU inlets) becoming available to the fuel inlets for the APU/engines. If this resulted in APU start-up, it would re-energise the AC buses and some hydraulic systems”. That wording to me is unambiguous and gives no hint of it being a second start, that being after a first run had accomplished the log-on, as currently you think.
There are more reasons than just fuel availability though which make a second auto-start dubious at the least and why I would not expect them to have that in mind. Quite aside from whether auto-start would reset itself after the engine ran down, its fuel line now empty, there are the practicalities of sufficient battery capacity for that, then also the run down and start up time plus that for opening and closing the inlet door. Also, in shut down the APU normally takes time in a cooling off phase before actual shut down. This might invoke further delays in any restart.
I speculate that some months ago the ATSB realised that the log-on causation it had stuck to had become very uncertain. Thence for this reason and others it asked Boeing to simulate alternative electrical and other configurations. It is not at all apparent they found an alternative and what that might be – that is evident from the ‘if’ of that quote with nothing further offered.
Please forgive the repetition but this may be of general interest to the forum. Should you have a conduit to the ATSB you might consider asking about the implications of that ‘if’!
@DennisW
Here are some thoughts on how a loiter might have fitted the 18:28 and 18:40 data – it’s two extracts from a longer paper that was written before Ian Holland’s paper when the 18:25-18:28 data was thought to have been indicative of an offset. Apologies if the hypothesis piece is a bit non sequitur.
https://www.dropbox.com/s/46kixk8y4lbc8qd/MH370%20Research%20V3.14%20-%20Loiter%20excerpts.pdf?dl=0
@Mick Gilbert
How would you explain the sat-phone call was not answered during this hypothetical loiter?
Or why the crew not tried to make contact with the sat-phone after 18:40?
The 18:40 call ringing in the cockpit would have been proof to them connection was working still no one answered the call or tried to re-connect while there was plenty of time after 18:40 during this hypothetical loiter.
Ge Rijn said; “The 18:40 call ringing in the cockpit”…
http://jeffwise.net/2014/11/18/mh370-and-the-mystery-of-indonesian-radar/comment-page-2/#comment-59521
…”the Signalling Unit leg shows that 3 satphone calls were attempted:
two, simultaneously, at 18:39 and one at 23:13.”…
“It’s also inaccurate that many reports describe them as “unanswered”:
the channel setups never completed to a point where a call alert
would have chimed on the flight deck (or a cabin handset).”
@TBill, Victor. “I have the air safety idea that the control logic of the outflow valve could possibly in the future be modified to disallow intentional depressuring above say FL200”.
There is an automatic outflow valve closure in auto when cabin altitude X is exceeded. Unfortunately I have lost track of what X is.
That constraint could be applied to manual perhaps.
Couple of other observations:
Cabin altitude alert can be set as high as 15,000 ft.
The AMM describes how to fly with part or no pressurisation: set(to the requirement) or open fully the outflow valves for depressurised flight then pull the circuit breakers. I daresay there would be cockpit alerts.
@Victor. In passing.
Inflow normally is dependent on altitude, decreasing (typically 400 lbs/min at SL to 300 at 43,000ft). However naturally that does not affect the trend from your trials, when you changed altitudes just between trial increments.
There are cabin pressure rise rate maxima and minima in normal operation. With outflow valves in manual, will inflow be constrained by that? Not according to the fully open and closed outcomes.
I might take a further look for curiosity really, giving the FSX PMDG 777 the benefit of the doubt.
@Gd Rijn
There are any number of reasons why an incoming ground-to-air satellite call might not be answered; failure to hear the incoming call alert (it’s a one off “bing-bong” chime not a constant ringing alert like a phone), damage to the flight deck speakers, damage to the radio tuning panel and the associated centre display control unit (the visual alert for an incoming call appears on the CDCU) and/or damage to microphones.
@DennisW: I had a closer look at the 18:40 BFO’s. What I find quite remarkable is that these many values around 18:40 are so close together. It reinforces the idea that the BFO error histogram presented by DSTG is not valid at all times. The danger is that we take the BFOs around 18:40 “too literal”; we need to know the “drift” induced errors better if possible. Having said this, I agree that for level flight the BFOs indicate a mainly southerly direction. However, I would be careful with assigning a certain GS based on the BFOs.
@buyerninety
After the SDU re-booted I assume that cockpit sat-phone should work properly.
What could be (or was) the reason “the channel setups never completed to a point where a call alert would have chimed on the flight deck (or a cabin handset)”? Do you or someone else knows?
(besides the assumption of @Mick Gilbert of damage to equipment in the cockpit)
(@Ge Rijn, actually, since David responded to me weeks ago about a related matter, I’ve been
searching back over posts about similar matters. Perhaps we should ask ALSM or Guardedon.)
@Don Thompson, you said in July 10, 2015;
“The only timed log records that show the AES datalink was down/failed inoperative for a
period are the failed outbound (from the GES) adhoc ACARS msg at 18:03z and the 18:25z Log On.
There is actually no evidence that the AES was powered down.”
It is understood that for the MCS-6000 SATCOM, it will defer Log On for 30 minutes if it
loses the GES signal, or a ~10 second timer if the AES loses sync with the satellite
P-channel.
Since that time, what hard evidence have you encountered, that disallows the following
possibility;
1.) The AES (considering only the components in the E11 rack) never regarded itself as being
‘logged-off’ and therefore no ’30 minute timer’ was triggered, and the AES continued to
receive and kept sync with the satellite P-channel. (To state it simply; from the point of
view of the units in the E11 rack, there was no need to log on because the AES had never
logged-off, and continued to RX and maintain sync, at least until 18:25).
The 18:03 ACARS message was received, however it was not acknowledged or replied to, either
because the unit the message was forwarded to (the flightdeck printer, specifically) was
non-functional or the intervening connections or intervening connecting units were
non-functional. (Simply; equipment in the E11 rack may have attempted to forward what was
received to units outside the E11 rack, but no ‘acknowledgement or reply’ came from the
applicable units outside of and forward of the E11 rack, so for the E11 rack
component(s), there was no requirement to action any transmission or ACK …it was – NFA).
2.) Also, is there still no explanation from Immarsat, why the GES didn’t send a ‘Check
Log-on/Log-Off’ at 18:07, as the GES did at 19:41, 20:41, etc. ? (For example, perhaps
the hourly check log-on/ log-off only applies for lower Classes or levels of service, or
perhaps is not applicable for higher Classes or service levels).
@Victor. I wrote, “There are cabin pressure rise rate maxima and minima in normal operation”. What I mean tto say was .. rise and fall maxima in normal..”
@David: Thank you for your continued interest in the End-of-Flight simulations. Yes, I emailed the ATSB with three questions, and was pleasantly surprised to receive a prompt, albeit brief, reply to all my questions the same office day. I hope to get a reply to a couple of follow-on questions after the weekend.
You write: ”My concern remains though about whether the ATSB still sees an APU auto-start as what prompted the 7th arc log-on.”Does the Nov. 2 report leave any doubt about what caused the 7th arc log-on?
“The results of the simulation are presented in Figure 6. The results have all been aligned to the point two minutes after the loss of power from the engines. This is the theorised time at which the 7th arc transmissions would have been sent.”
I agree with you that a second auto-start of the APU is highly unlikely. However, the report also states: ”In the simulator, when the fuel tank is empty, zero fuel is available to all systems fed from the tank.” Therefore, the simulator operator must have manipulated the simulator in some way to obtain the intended sequence of main engine(s) flame-out(s), APU auto-start, and APU shut-down.
I have at least one more question regarding the Fig. 6 tracks. Perhaps you could ask a few APU-related questions? The ATSB address stated in the report is ATSBinfo@atsb.gov.au. My email got a reply from Daniel.O’Malley@atsb.gov.au, Communications Officer.
@Gysbreght: Did you happen to ask whether the left bus might have been powered by an IDG as an engine spool windmilled?
@Buyerninety, @Richard, others
Concerning radar head locations.
Western Hill, Penang Island: site of Royal Malaysian Air Force long range, air defence surveillance primary radar, RAT-31DL. Max range approx 250nm. Location: N5°25’30.00″ E100°15’3.60″
Butterworth Airbase: site of joint use DCA/RMAF air traffic control radar for terminal area & approach control WMKP and WMKB, Selex ATCR-33. Max range of primary radar 60nm (per DCA AIP). Location: N5º28’19.43″ E100º23’40.5″
Note that the first target depicted in the ‘Beijing Lido’ sequence is recorded at 00:00:02 MYT (18:00:02UTC). The location of that target is at the extremity of the range possible from the Butterworth ATCR-33 radar.
@Ge Rijn/@Buyerninety
The source of Buyerninety’s quote concerning flight deck call alerting was a draft note authored by me. JW included it in his ‘things we know’ compendium. It should be disregarded, it was a draft not intended for open distribution and was never finalised. Among other information, Inmarsat’s later Journal of Navigation release showed that the GES measured RxPwr was satisfactory at all measured log events, and that Inmarsat’s voice switching systems were configurable to define a call unanswered time-out to their requirement (60sec, rather than the more typical 300sec).
The C-channel sub-channel signalling shows that the channel was held for 61 seconds, allowing the call to announced & to be answered, and the AES and GES maintained sub-channel signalling every 10sec while the channel was held to the AES. The GES initiated the release after 61 seconds.
@buyerninety
I hope someone can give the answer. Possibly @GuardedDon can explain on the link you gave from his comment back then.
I always assumed the calls were not answered but now I learn they never got through to the cockpit.
Could it have to do with the IFE being switched off before the re-boot at 18:25?
Was there a complete re-boot at 18:25 including a IFE request and answer in the data?
@Niels
Good point on the 18:40 BFO’s – very consistent. Reinforces the notion that the DSTG histogram is the result of OCXO drift over time rather than noise in the measurement process itself.
@Victor Iannello:
I asked which tracks the 1st, 3rd and 4th bullet points on page 14 of the Nov. 2 report referred to. The reply gave the numbers of the tracks.
@Don
Whether you take Butterworth AB as stated on the Lido slide or Western Hill Radar, both the labels marked on the Lido slide at 02:02 Pulau Perak and 02:22 the last supposed radar point, are wrong.
Neither Butterworth AB nor Western Hill are 279R 89 nm from Pulau Perak or 295R 200 nm from the last radar point.
This Lido slide was not included in either the Factual Information or the RMP report for good reason.
The Lido slide was fabricated as a public relations stunt in my view.
@Gysbreght,
In response to my question, ATSB says the average Fuel Flows they previously provided me came from snapshots of Engine Health Monitoring cruise data. This uses the FF sensors in the engines, rather than differential fuel tank quantities at the start and end of cruise.
@Richard:
There is evidence to support the theory that the Lido Hotel slide shown to the NOK on March 21, 2014, was not true. Look at this slide that was presented to the NOK on April 29, 2014, at the same Lido Hotel in Beijing. The path in the Malacca Strait is shown. It looks as though there is a straight line between Pulau Perak and the last radar point as 18:22, suggesting no captures in the interim. This is the same path shown by the ATSB and the DSTG in their later reports, all derived from Malaysian radar data.
https://www.dropbox.com/s/l9h3brbdzr8lxfs/2014-04-29%20Lido%20Hotel%2C%20Beijing%2C%20Radar%20Path.jpg?dl=0
Now look at the path that is included in the RMP report. The path ends at Pulau Perak. Up until that point, the path looks the same as was presented in Beijing on April 29, 2014. So other than the single radar point at 18:22 and the straight line between Pulau Perak and this point, they are essentially the same. It also raises the question as to why the 18:22 radar point was ignored if there was high confidence that the final target was MH370.
https://www.dropbox.com/s/179tjwd9z4oxh1p/Radar%20Captures%20from%20RMP%20Report.png?dl=0
So, it seems that the Lido Hotel slide from March 21, 2014, is the outlier, and includes radar captures never again publicly shown and never supplied to the ATSB.
@Richard
When the Lido-slide was fabricated this would mean a major cover-up of what actualy happened.
Is this is what you are suggesting?
If Malaysian authorities fabricated this slide it implies they knew what happened and used it as a distraction.
It could still mean IMO they shot at MH370 around 18:22 cripling it, taking out an engine, suddenly vanishing from primary radar and forcing the reboot and ongoing strange flight.
IMO they tracked the plane real time over the Malaysian peninsula. The minister stated they saw it but not percieved it as a threat and therefore not scrambled yets. Is this true? He declared; ‘You think we shot the plane’? The interviewer replied; ‘That are your words not mine'”.
By the time it reached Penang, Butterworth had time enough to be alerted and scramble yets to intercept the plane above the Malacca straight.
Anyway, if the Lido-slide was fabricated there must have been a cover-up.
If this only could be proven by someone..
@DennisW,
You said: “My point is that the BTO error bands are large enough to admit of many different paths. I don’t really believe it is possible to narrow it down all that much based on BTO fitting.”
I don’t disagree, but the BTO data DO ELIMINATE a simple extension along N571.
A turn off N571 is required, and the separation must be significant by 18:27 if not before. It seems to me that is pretty useful information. The 18:28 BFO is consistent with a course roughly aligned with N571. That is helpful too, although there are several paths from 18:22 that are consistent with both the 18:25-18:28 BTOs and the 18:28 BFOs.
I am now of the opinion, based on my OXCO modelling, that the 18:25-18:28 BFOs are most consistent with NO CHANGE in bearing or speed during this period. Mike was right about the overshoot.
You also said: “Can’t reconcile the BFO at 18:40 with any other conclusion. If that is the case, then it would seem likely that a latitude value near 1N – 2N (or even further South) is likely at 19:40”
I get FMT starting at 18:38:40. My 19:41 latitude is 0.02S. No change in altitude after 17:30ish.
@DrB: Thanks for the heads-up. You said earlier the ATSB provided Mach numbers along with the fuel data. Did those generally confirm the CI=52 you are using, or rather the M.82 MH370 was cruising at?
regarding BFO accuracy, it is worth recalling a few facts.
1. The BFO measurement accuracy is limited by GES CU hardware and firmware, particularly the Square Peg CUs. Based on my demodulator design experience, I would estimate the BFO measurement accuracy to be OTOO 1-2 Hz.
2. The AES Doppler compensation has a quantification error of 4 Hz. That is, the algorithm effectively rounds off the correction to the nearest 4 Hz increment.
3. The BFO Bias may drift slightly over the time of an 8 hr flight, due to SDU OCXO drift. The drift over 8 hours is OTOO 5-10 Hz and it looks more like a random walk than a systematic drift. But The OCXO does not drift significantly over a period of seconds to a few minutes.
4. The C channel BFO data offer the best evidence of the effective BFO random noise (not drift) resulting from #1 and #2 above. There were 49 samples at 1840 in the range 86-90 Hz. The were 27 samples at 23:15 in the range 216-222 Hz.onsistent with the ATSB estimate (June 2014 Report) of 5 Hz SD.
regarding BFO accuracy, it is worth recalling a few facts.
1. The BFO measurement accuracy is limited by GES CU hardware and firmware, particularly the Square Peg CUs. Based on my demodulator design experience, I would estimate the BFO measurement accuracy to be OTOO 1-2 Hz.
2. The AES Doppler compensation has a quantification error of 4 Hz. That is, the algorithm effectively rounds off the correction to the nearest 4 Hz increment.
3. The BFO Bias may drift slightly over the time of an 8 hr flight, due to SDU OCXO drift. The drift over 8 hours is OTOO 5-10 Hz and it looks more like a random walk than a systematic drift. But The OCXO does not drift significantly over a period of seconds to a few minutes.
4. The C channel BFO data offer the best evidence of the effective BFO random noise (not drift) resulting from #1 and #2 above. There were 49 samples at 1840 in the range 86-90 Hz. The were 27 samples at 23:15 in the range 216-222 Hz.onsistent with the ATSB estimate (June 2014 Report) of 5 Hz SD.
@Victor
We possibly need logical options for the flight, but my “adopted” logic continues to be Ewan Wilson’s book Goodnight Malaysian 370, and Wilson felt there was probably an (1) intentional depressurization event at around IGARI. The other two options are: (2) Unintentional depressurization at IGARI, and (3) No depressurization took place.
Implications of intentional action? In my mind, the proposed descent at 1840 could optionally be explained by the PIC wanting to re-establish breathing air…presumably the outflow valves go to in-flow mode?
I do not feel we have a very good understanding of cabin temperature implications, and whether it is possible to manage cabin temperature during intentional depressurization by setting air conditioning temp higher. Even if cabin temperature is lower, not sure that impacts SDU because some electronic equipment actually over-heats with the low density air has less cooling capacity.
If depressurization (intentional or unintentional) does impact SDU, then we need to (assuming we know how to) factor those options into the Lido slide interpretation and path BFO data after 1822. Unfort we’d probably need a B777 test flight with test pilots to check out the possibilities, I assume.
The best early description of radar along the Strait of Malacca was provided by Daud on Wed, Mar 12 (Day 5):
https://www.youtube.com/watch?v=Pl0CW5m9OX0&nohtml5=False
He gives the last time (last plot of several intermediate primary plots) of 2:15, radial 295, 200 miles NW of Penang.
@ALSM
Interesting info on the BFO accuracy. It would perhaps be possible and useful to describe point 3 OCXO drift / “random walk” more in detail. Are you aware of any systematic studies into OCXO drift characteristics?
Regarding BTO errors:
I was reading chapter 10 of “Bayesian methods..” and found table 1 containing some interesting details. First of all it gives an error estimate for the R1200 messages, both normal and anomalous. Apparently a correction term exists for the 182534 and 001937 BTOs. Anyone knows the value?
Secondly it is stated that the R600 message error estimate includes the error of the correction term. Do we know a R600 BTO error estimate without the correction term?
To –
Independent Group et al IG
From – The ASOVE Team
RE – SIO FAILURE CONFIRMATION
As predicted, the entire SIO
search has ended in total failure.
Of note – Whilst continued time
is being wasted attempting to
give credibility to ever growing
levels of convuluted nonsense
associated with the disjointed
ISAT Data alleged to be MH370,
The People’s Republic of China
has dispatched a search vessel
equipped with a deep sea manned
submersible to engage in as of
yet unknown and or undisclosed
intentions into the very area
of The North Indian Ocean that
The ASOVE Team identified is
the actual location of MH370
The ASOVE Team
asove.net
@sk999: Daud repeated those coordinates several times, each time very emphatically. That is the same radial shown in the caption of the Lido Hotel image, except the caption there says 2:22 MYT, not 2:15 MYT. But plotting 200 NM at 295 deg from either Penang or Butterworth Airport is far from what is shown in the Lido Hotel slide.
What a mess.
@Niels: “From the ATSB report, June 2014: Each power up sequence starts with a Log-on Request message which has been found to have a fixed offset of 4600 μs relative to the LLA message exchange by inspecting historical data for this aircraft terminal.” The same information is given in Ashton et al.’s JON paper.
@TBill: In my opinion, I think the Lido Hotel slide is best ignored.
@DrB: Are you proposing that at 18:25:27, MH370 was flying parallel to N571 at a track of 296T and speed of 500 kn, and but had initiated and completed a lateral offset manoeuver between 18:22:12 and 18:25:27?
Niels:
For OCXO medium term drift (24 hrs), See Bayesian Book Figure 5.4
The BTO correction is 4600 usec.
See Inmarsat Updated log: “As the two message are from Channel R600, a 4,600 microseconds calibration needs to be subtracted (19380 – 4600 = 14780) when comparing with subsequent R1200 messages. This is the same as applied for the messages at 18:25:27 and 00:19:29. The remainder of this document is as previously released by Malaysia in May 2014.”
@Victor: The 4600 us I’m aware of; I get the impression they know how to treat the 51700 and 49660 us values.
I noted the APU question has come up again. We had extensive debate on this last year. I contacted ATSB about the fuel system issues David brought up at that time. ATSB reiterated that the fuel in the APU line would allow for the APU to start and run for up to 13 minutes (at least 3), regardless of what remained in the left tank or aircraft attitude. Regarding the simulator trails I conducted in Nov 2014, I reported then that we had APU starts after about 1 minute following FE on ALL trails we ran. In all trials, the attitude at that time remained near normal. Steep turns and phugoids had not started at the time the APU started.
@victor
This thought might be bolax, I won’t be offended if you think Im talking *hit and you don’t have to add this comment to your Forum. And I won’t continue to bother you.
If Lido slide was possibly made up for PR, the virtually straight path from 02:02 to 02:07 (502 Knots GS) and 02:13:36 to 02:2212 (prediction along a thought exact path on N571 including a small turn before MEKAR) could be EK343 path extrapolated deliberately into a virtually straight line. Hence the unexplained circle to cover what’s been done. And why EK343 was not included in the Lido Graphic.
@Niels
Quote from DrB below:
Both the log-on acknowledge BTOs at 18:25:34 and 00:19:37 BTOs include multiple increments of 7820 microseconds (per ATSB). It’s easy to figure out how many are needed to get in the ballpark. Use 5 for the first one and 4 for the second one. So 18:25:27 = 51,700 – 5*7820 = 12,600. At 00:19:37 I get 49,660 – 4*7820 = 18,380.
I meant *Vampi sorry.
Richard said;
“The Lido slide was fabricated as a public relations stunt in my view.”
“Neither Butterworth AB nor Western Hill are 279R 89 nm from Pulau Perak”…
I agree the slide was intended as a means to inform & placate the somewhat
rambunctious Chinese NOK – it was not intended as an exact representation
of the facts and it may contain incorrect information.
It is, however, approximately correct as to the bearing & distance of
Pulau Perak from Butterworth AB radar site, as anyone may see if they so desire;
279 degrees bearing Relative Pulau Perak, 89 Nautical Miles;
https://skyvector.com/?ll=5.680556,98.940833&chart=304&zoom=3&fpl=052819N1002341E%20054206N0985535E%20054050N0985627E
(Note; for the above link, symbol ‘+’ on the map is approximately the location
of Pulau Perak, some slight rounding by skyvectors representation may occur.)
(I take the view that the words Pulau Perak are meant to be read as merely
refering to the approximately closest landmark – whilst the bearing & distance
are meant to be read as the bearing & distance from a plot point of MH370.)
@Niels: From the DSTG report: “For some communication messages, typically during initial log-on, there was a very large difference between the measured BTO and the nominal delay. Analysis showed that rather than simple outliers, these anomalous BTO measurements could be corrected by a factor of N x 7,820μs where N is a positive integer. The origin of these anomalous BTO measurements has not been fully determined, but the empirical correction time is quite close to the transmission interrupt clock period of 7,812.5μs and the BTO collection process contains quantisation.”
Luckily, 7,820 μs is so big compared to the expected error that we can determine the single value of N that makes sense. For the value of 51,700 μs, if we apply N=5, we get 12,600 μs. For the value of 49,600 μs, if we apply N=4, we get 18,380 μs.
Richard & Victor,
Notable dates:
12th Mar: Daud states last primary radar target at “0215 local time […] after several intermittent primary […] 295R200nm off Penang”.
21st Mar 2014: Lt Gen Ackbal bin Haji Abdul Samad presentation, Military Radar Plot From Pulau Perak to Last Plot at 02:22H
5th April: See Hishammuddin Hussein’s Twitter timeline, “The Govt, in order to streamline & strengthen our ongoing efforts, has also established three ministerial committees...” These committees were tasked with overseeing Technical (investigation), Media (communications) and NoK (liaison) functions relating to MH370.
29th April: MAS representative, Subas Chandran, leads another delegation to Beijing Lido with a subtly different narrative.
During late March and early April 2014, communications were brought under some form of alignment. The military contribution is deprecated and, subsequently, is mentioned only in unspecific terms.
Malaysia’s capabilities for crisis (charade?) management are again in the spotlight: on 13th Feb Kim Jong Nam dies after apparent attack in KLIA2 terminal, 11 days later Malaysia authorities decide its time to perform a CBRNe investigation of the KLIA2 terminal. Eleven days of continued use by the public.
Note: Chandran’s LinkedIn entry lists “Malaysian Airlines ACARS/Iridium/Inmarsat Development Manager” as one of his functions.
@Joseph Coleman: I believe EK343 didn’t track so close to Penang. However, it did meet up with N571, although at a later time than depicted in the slide. It is hard to know what the Lido slide represents.
@Don Thompson: So the public information shows signs of being massaged by Malaysia officials. What part of what message do you think is truthful?
@DennisW: Thanks! Somehow I had missed that. Especially good to have some more data around 00:19. See also table 10.1 and fig. 10.7 of DSTG book.
@Victor: Thank you as well!
Question I’m still wondering: is there an BTO error assigned to R600 messages without the correction term. Or: how accurate is the 4600 us correction?
The main reason I’m interested is that I would like to assess the error in 7th arc definition.
@Niels
I also found the statement below from page 27 of the DSTG book to be interesting. I have been using estimated aircraft altitude and the nominal satellite altitude. I’ll run a test today and see how difference it makes in the Doppler residuals.
The modified position matrix H ̄ x selects only the horizontal location variables and sets the altitude to zero, and similarly for V ̄ x. The compensation also assumes a motionless satellite at its nominal satellite location of 64.5◦E. The satellite altitude used in the correction is 422 km higher than the nominal 35788.12 km value.
@ALSM: I think this is the question that @Gysbreght raises: In Boeing’s simulator, once a fuel tank is dry, anything fed by that tank has no additional fuel available. As you note, this might not reflect reality, but it is how Boeing’s simulator models the fuel system. On the other hand, in the simulations you witnessed, the APU starts after fuel to the engines is depleted. Do you think this occurred (APU autostart) because the simulator that you accessed has a different fuel system model than Boeing’s? Or was there manual intervention to force the APU to start and run for some period of time? Or are we misunderstanding something else?
@Ge Rijn
(GuardedDon = Don Thompson).
Therefore, he did answ…er, reply.
Unfortunately, his reply only indicates that the circa 18:39 call attempt
was received by the SDU, and at the GES it was marked as unanswered after 61 seconds.
No specific information that acts as evidence as to whether the call was passed
to any unit outside of the E11 rack was given, so that is still an unknown.
Interestingly, in regard to the statement “There is actually no evidence that the
AES was powered down” (meaning the period 17:07 to 18:25), no evidence was given
that disproves that statement either.
Regarding Stephen Crowsen’s post February 24, 2017 at 6:38 pm:
There were several statements in this post that are not correct, misleading, or “scrambled”.
Re: “The LGA uses a different method of modulating the data to be sent from that used by the High Gain Antenna.”
This statement is not correct. The modulation method (bi-phase, etc.) and data rate (600 b/s) are the same for an R600 channel regardless of the antenna used, which can be either, but is usually the LGA if there has been a long outage.
Re: “Two important differences between these two systems is the Class C amplifier has essentially a limited frequency range and basically one power output level…”
This is not correct. The bandwidth of the Class C HPA covers the full allocated BW. In addition, all AES HPAs have power agility.
1) AES issues Log On Request at a default EIRP (using R/smc 600 bps channel)
2) GES responds with Log On Confirm including an instruction for the AES to set an Initial EIRP, as below:
Initial EIRP (4 bits)
The EIRP value shall be equal to:
• (–1.5 + N) dBW for a Class 1 AES
• (–0.5 + N) dBW for Class 3/4 AES with intermediate gain antenna;
• (10.5 + N) dBW for Class 3/4 AES with high gain antenna;
where N is the value of this field (range 0 to 15).
That instruction for EIRP is based on the received power level measured during processing of the Log On Request burst.
Re: “…while the Class A amplifier has a wide frequency range and a wide power output range, so the Class A amplifier is better suited to higher bit rate transmission protocols, while the Class C amplifier is better suited to the low bit rate transmission protocols.”
This statement is not correct. The HGA uses a Class AB amplifier, not a Class A amplifier, but both are linear amplifiers, so not a big deal. A linear amplifier is required for multicarrier (multichannel) service, as implemented in the MCS-6000. It is power agile, like the LGA/HPA. Class C (saturated single carrier operation), Class A and Class AB (multi carrier linear operation) HPAs are all equally well suited for any modulation bit rate.
Re: “If a lower bit rate transmission protocol was used during log on then one would expect the BTO to be different from that used by the HGA, which it is.”
It has nothing to do with the HP used. The R600 BTO Bias is the same regardless of the antenna/HPA used, but it is different by 4600 usec from the R1200 BTO Bias as noted in a previous post here (February 26, 2017 at 1:27 pm).
The logon events were as follows (FI at 1.9.5.4):
1. 1250:19 – Prior to take-off, the SATCOM initiates a normal Log-On as Class 1 (data only capable) via the Pacific Ocean Region (POR) I-3 satellite, using the Low Gain Antenna (LGA) subsystem. No flight ID is sent to the GES at this time. This is the first SATCOM activity recorded at the GES since 0802:27.
NOTE: Crew is onboard and configuring system now.
2. 1555:57 – The SATCOM initiates a normal Log On Renewal as Class 1 (data only capable) via the POR I-3 satellite, using the LGA subsystem, this time with a valid Flight ID.
3. 1557:49 – The SATCOM initiates a normal Log-On as Class 3 (voice and data capable)
via the POR I-3 satellite, using the High Gain Antenna (HGA) subsystem, with a valid
Flight ID.
4. 1559:57 – The SACOM initiates a Log-On handover as Class 3 (voice and data capable)
to the IOR I-3 satellite, using the HGA subsystem, with a valid Flight ID.
5. 1825:27 – SATCOM Log-On, initiated from the aircraft terminal.
a. This is the first ‘handshake’.
b. This marks the end of the link lost period that began at sometime between 1707:48
and 1803:41.
NOTE: This logon event used the R600 channel, so a 4600 usec correction is required, regardless of the antenna used.
6. 0019:29 – SATCOM Log-On, initiated from the aircraft terminal. This is the seventh
‘handshake’.
NOTE: This logon event used the R600 channel, so a 4600 usec correction is required, regardless of the antenna used.
Victor:
Re: Fuel to the APU…I don’t know if the Boeing Engineering Simulator code is significantly different from the full motion Class D simulator I used. But regardless of the simulator codes, the actual aircraft has over 100 feet of fuel line between the Left tank and the APU. Therefor, the APU can run on fuel in the line for several minutes after the tank is dry.
@ALSM:
In the June, 2014 (updated aug !4) report the ATSB wrote:
“The APU is supplied with fuel from the same tank as the left engine. Operation of the APU, after the left engine flamed-out, would be unreliable and would be of short duration before it too flamed-out.”
In the December, 2015 Update the ATSB wrote:
“The APU fuel inlet is located in the left main tank. The APU is estimated to consume (when electrically-loaded) approximately 2 lb of fuel in 55 seconds. In a standard flight attitude (1° pitch), the difference in location between the left engine fuel inlet and the APU fuel inlet would result in approximately 30 lb of fuel being available to the APU after a left engine fuel exhaustion.
From this information, the APU had a maximum operating time of approximately 13 minutes and 45 seconds. The pitch attitude would have an effect on the usable fuel for the APU; …”.
Therefore I buy your “several minutes” for fuel in the fuel lin only. However, the 13 minutes is based on the unusable fuel in the left fuel tank at engine fuel-exhaustion, in a standard flight attitude (1° pitch).
That quantity of unusable fuel in the left tank is irrelevant if account is taken of the changes in longitudinal acceleration and/or pitch attitude after flame-out of the first, then the second engine.
Gysbreght:
I’m not sure what we are trying to resolve here. We can be virtually certain the APU started and ran for at least 1-2 minutes…long enough to make the 00:19:29 logon request. There should have been more than enough fuel in the line for the IFE logon too, about 90 seconds later, but that did not happen. Either the APU fuel ran out, or the plane hit the ocean, or the attitude precluded a link to the satellite at 00:21. But regardless of why there was no 00:21 IFE logon, other information (small size of debris, simulator trials, likely inflight separation of some control surfaces, etc.), all tells us the impact was within a few minutes of 00:19.
@ALSM: you wrote at 1:39 pm:
“In all trials, the attitude at that time remained near normal.”
The fuel level in a tank reflects the combination of attitude and acceleration. If the attitude remains constant at fuel exhaustion, the loss of thrust will cause a longitudinal acceleration equivalent to a change of pitch attitude of approximately 3.5 degrees nose-down.
@ALSM: We are discussing your statement about the amount of fuel available to the APU after main engine flame-out, and therefore the length of time the APU would have been able to run after autostarting.
@ALSM: “There should have been more than enough fuel in the line for the IFE logon too, about 90 seconds later, but that did not happen.”
Either the APU fuel ran out, or the plane hit the ocean, or the attitude precluded a link to the satellite at 00:21, or IFE was switched off
Gysbreght:
I’m still at a loss to understand why all this is being discussed again now. Are you questioning whether the POI was within ~+/-20 NM of the 7th arc? If you agree with that, regardless of the reasons, why revisit the APU fuel debate.
@ALSM: In your post of 5:09 you change the subject from the “APU fuel debate” to “POI was within ~+/-20 NM of the 7th arc”.
The latter statement depends primarily on whether or not human control is assumed in the End-of-Flight scenario. The state of the debris is not conclusive, nor is the last BFO.
@ALSM: I didn’t start the “APU fuel debate”, you did.
Victor,
“So the public information shows signs of being massaged by Malaysia officials. What part of what message do you think is truthful?”
At this point in time, each statement appears as (im)plausible as any other.
The data which Malaysia appears confident to share publicly, with written detail, ends at 1752:35UTC.
The DSTG Analysis relates that data provided to them included a last reliable fix at 18:01:49UTC.
However, consider the announcements in chronological order: 295R200 at 0215, per Daud on 12th Mar, lies on airway Y338 towards waypoint LEKIR. Is an intersect between a path towards that waypoint and the 18:25-18:28 arcs in any way credible?
In that press conference/video, Daud said “flight level 295” not “radial 295”. He also used the word “altitude” to describe the 295, see at 2.40 of the video.
@Gysbreght,
You said: “Thanks for the heads-up. You said earlier the ATSB provided Mach numbers along with the fuel data. Did those generally confirm the CI=52 you are using, or rather the M.82 MH370 was cruising at?”
The average Mach number I was given, along with average Flight Level, allowed me to estimate average Cost Index. It was slightly higher than 52. I suspect on some flights a CI higher than 52 was used.
@Gysbreght
If the IFE was switched off before 00:21 then it was switched off after the 18:25 – 18:28 log-on; we know it was on then because the IFE SMS/email and BITE applications set-up as expected.
@AlexSiew: I think you’re right. What we thought was “radial” is actually “flight level”.
Daud does appear to say ‘flight level’, he starts to utter it a second time but is interrupted.
So, 200nm range at 0215MYT. Yet another data point.
Something Daud picked up from a random conversation with all the collaborators & experts so as to have something to say at the PC?
@Gysbreght, Victor, ALSM. 7th arc log-on:
https://www.dropbox.com/s/dcqznic5q8ospyz/e-mail%20to%20the%20ATSB%20about%20APU%20fuelling.docx?dl=0
I will convey any outcome
@Gysbreght. “Therefore, the simulator operator must have manipulated the simulator in some way to obtain the intended sequence of main engine(s) flame-out(s), APU auto-start, and APU shut-down”. Yes, either that or it was an add-on to the simulations, which did not include the APU effects. Remember they say, “If this resulted in APU start-up, it would re-energise the AC buses and some hydraulic systems. This could affect the trajectory of the aircraft. Similarly, the left and right engines may also briefly restart, affecting the trajectory”. To me this means that these affects are supernumerary to the simulations.
@ALSM.”ATSB reiterated that the fuel in the APU line would allow for the APU to start and run for up to 13 minutes (at least 3), regardless of what remained in the left tank or aircraft attitude”. I was unaware of that. Would you confirm please? This fuel source is notably absent from their reports.
I have drafted my questions such that this does not affect them either way.
Daud said “200 miles”, not “200 nautical miles”.
@all
Relative to the aircraft/satellite altitude statement made on page 27 of “Bayesian methods…”
“The modified position matrix H ̄ x selects only the horizontal location variables and sets the altitude to zero, and similarly for V ̄ x. The compensation also assumes a motionless satellite at its nominal satellite location of 64.5◦E. The satellite altitude used in the correction is 422 km higher than the nominal 35788.12 km value.”
The Doppler residual at 19:40 changes by only +0.25Hz
The Doppler residual at 18:25:27 changes by -1.6Hz.
@Victor,
You said: “@DrB: Are you proposing that at 18:25:27, MH370 was flying parallel to N571 at a track of 296T and speed of 500 kn, and but had initiated and completed a lateral offset manoeuver between 18:22:12 and 18:25:27?”
Yes. 12 NM to right gives a good fit to the BTOs.
@Victor
Re: your candidate path graphic
I tried to work backwards with SkyVector to see what straight path connects up with @SK999’s digitized flight path from Penang to the 1802 point. What I seem to see is the straight path OPOVI IGOGU goes from south of Penang and also matches SK999’s data within a reasonable tolerance.
I found some other straight paths to SAMAK and 1090E but they do not seem to hook up well to the path prior to 1802.
Here is a more detailed SkyVector comparison of digitized path vs. OPOVI to IGOGU (for the record):
051442N1002050E 051339N1001544E 051309N1001041E 051315N1000542E 051401N1000048E 051524N0995601E 051717N0995120E 051925N0994641E 052139N0994202E 052351N0993723E 052558N0993244E 052800N0992804E 052956N0992322E 053147N0991836E 053333N0991347E 053520N0990855E 053726N0990302E MEKAR IGOGU 053729N0990254E OPOVI
@buyerninety @others
“No specific information that acts as evidence as to whether the call was passed to any unit outside of the E11 rack was given, so that is still an unknown”.
Thanks for clarifying.
Question offcourse remains what set-up could have blocked the call from passing outside the E11 rack and being announced in the cockpit?
The IFE switched off shortly after 18:28 maybe? Can the sat-phone be switched off in the cockpit? Any other intervention?
ZS would not have known EK343 was 38 NM behind him travelling at 493 knots and 34,000 feet, but he would have known the typical flight routes such as N571, the possible flight levels assigned and the usual times of traffic along N571.
I assume MH370 was flying without any navigation lights, otherwise it would have been seen by EK343.
We also know that the transponder was switched off and therefore the TCAS would not function. ZS would want to avoid using N571 without TCAS functioning.
Here is a link to a summary of the FlightAware and flightradar24 information on EK343:
https://www.dropbox.com/s/oa83bq5fhdtwv7x/EK343%20Position%20at%201822%20UTC.pdf?dl=0
Richard,
ZS would not have known EK343 was 38 NM behind him travelling at 493 knots and 34,000 feet
If the PIC onboard 9M-MRO listened to the KL FIR sector controller on the open VHF voice channel they would have been aware of other traffic in the area. A notable point in your EK343 track graphic: at approx 18:07, abeam TASEK, EK343 begins to track direct to MEKAR rather than follow N571 precisely. If E343’s filed route was GUNIP-VAMPI-MEKAR that slight deviation should have required permission from the controller.
@DennisW: Important check regarding the Doppler compensation calculation. I expect that the correction because of 422 km difference in sat. altitude is dominant in comparison with the neglected aircraft altitude, is that true?
@Don Thompson
“EK343 begins to track direct to MEKAR rather than follow N571 precisely”
That’s interesting to me! If you plug-into SkyVector the digitized MH370 flight path to 18:02 (posted above) it is a gentle curve, and I decided by my eyeball it seems to bend over to MEKAR rather than VAMPI.
@Neils
Yes, but neither one changes anything significantly. The difference is quite small. I did modify my Doppler residual calculator to reflect this information.
@Don Thompson: “So, 200nm range at 0215MYT”;
Don, would you think this 200 nm is distance from (Western Hill) radar, or from Butterworth?
@buyerninety @others
No answer yet but I like to mention if the Sat-phone call(s) did not come through to the cockpit for whatever reason this could be significant.
It’s a great difference if the call was not heard or seen by a pilot or just not anwsered.
If this would be clear we would know if there was an unconcious pilot at the controls at 18:40 or he (they) just ignored the call.
The same at 23:13.
Was the IFE switched on still at 23:13? Is data showing this?
@Niels
I think Daud didn’t make that clear.
Whichever way you interpret what Daud stated, he contradicts the Lido slide, the Malaysian Factual Information and (in my view) the Inmarsat satellite data at 18:28:14.904 UTC:
(1) From Western Hill, Penang at a distance of 200 nautical miles on a bearing of North West is a position 7.7801°N 97.8796°E between waypoint RUSET and PHUKET.
(2) From Western Hill, Penang at a distance of 200 nautical miles on a bearing of 295°T is a position 6.8324°N 97.2145°E on Flight Route Y338 between waypoint VAMPI and LEKIR.
(3) From Western Hill, Penang at a distance of 200 statute miles on a bearing of North West is a position 7.4715°N 98.1910°E just south of Phuket Airport.
(4) From Western Hill, Penang at a distance of 200 statute miles on a bearing of 295°T is a position 6.6480°N 97.6129°E between waypoint VAMPI and GIVAL.
(5) From Western Hill, Penang at a distance of 182.1 nautical miles on a bearing of 285.9933°T is a position 6.2602°N 97.3205°E at 02:15 local time on Flight Route N571.
(6) From Western Hill, Penang at a distance of 238.55 nautical miles on a bearing of 290.7876°T is a position 6.8347°N 96.5151°E at 02:22:12 local time on Flight Route N571.
None of these scenarios fit the Lido slide statement “295R 200 nm” from “Butterworth” (fictitious) or Western Hill (real), or, the Factual Information at 02:22:12 local time 10 NM beyond waypoint MEKAR on Flight Route N571.
Daud is dismissed as an unreliable witness, in my view.
Don,
ZS would not have known EK343 was 38 NM behind him travelling at 493 knots and 34,000 feet
“If the PIC onboard 9M-MRO listened to the KL FIR sector controller on the open VHF voice channel they would have been aware of other traffic in the area. A notable point in your EK343 track graphic: at approx 18:07, abeam TASEK, EK343 begins to track direct to MEKAR rather than follow N571 precisely. If E343’s filed route was GUNIP-VAMPI-MEKAR that slight deviation should have required permission from the controller.”
Ah ha! You have a good point about listening to the VHF radio.
So you think at least one of the 3 VHF radios was working, so ZS or the PIC could listen to the KL FIR sector controller. This is not Mick Gilbert’s scenario or similar, where all radio panels, microphones, headsets and loudspeakers were non operational.
If one of the 3 VHF or 2 HF radios was working, then the PIC did not declare an emergency, even after 1 hour of aviating, navigating, but not communicating.
In which case, ZS or the PIC is guilty as charged.
The deviation from the Flight Route N571 is based on estimated data from FlightAware, the flightradar24 at 18:22 UTC shows EK343 kept to the Flight Route N571 (please see following link):
https://www.dropbox.com/s/k50bj196seg3rgr/FlightRadar%20EK343%201822.jpg?dl=0
@Richard: A speculative interpretation as an “extra data point” and putting it on N571 at 200 nm from Western Hill could IMO fit the other (18:22:12 and BTO) data.
If you don’t buy this as any useful info I can perfectly understand..
@Niels
An “extra data point” on N571 at 200 NM from Western Hill would be at 06.3424°N 97.0318°E.
If the time at this location is 02:15 local time, then MH370 would have to slow to an average of 363 knots up until the supposed final radar point at 02:22:12 local time.
To then meet the BTO at 18:28:14.904 UTC, MH370 would have to speed up to 531 knots.
It could fit, but it is not obvious why the slowing up, followed by the speeding up takes place.
@Richard: What would be the 18:28:14.904 location in your estimate?
@Richard: I’m not sure why the speeding up would be needed to meet the 18:28:14.904 BTO. As discussed over the weekend, continue on N571 with a low speed (close to 360 kn) also would work to meet the 18:25 – 18:28 BTOs (though at the cost of a somewhat higher BFO error).
The path/scenario I had in mind before the “2:15” point came up is:
– slow down and possibly reduce flight level just before or around the last radar point (18:22:12)
– continu at N571 until a turn just before 18:40
– keep the low speed (around 360 kn) and the possibly reduced altitude all the way around the tip of Indonesia.
– Speed up and climb out (around N2 – N1) to meet the 19:41 arc around N 0.5 degree.
This is close to the “Inmarsat scenario”, with a slightly modified speed distribution.
Note: it has some possible BFO issues, to be discussed(18:28, 18:40)
Richard, thank you for the track for EK343. Can I just confirm that that is its track for the morning in question please? I only ask because I would have expected ghat EK343 should have been heading out of the top of the Strait at 18:22 UTC, not approaching MEKAR.
EK343’s conversation with Lumpur Ground is captured in the Factual Information Report radio transcripts; in it EK343 makes first contact with Lumpur Ground at 16:37:51 UTC (just after MH370 is handed over to Lumpur Tower on taxi) and they estimate their departure time to be 17:10 UTC (01:10 MYT). The transcripts for Lumpur Tower end at 17:02 UTC and EK343 isn’t out of the blocks then. Flight Stats (https://beta.flightstats.com/historical-flight/EK/343/2014/03/08) have EK343 departing 4 minutes late at 17:14 UTC (01:14 MYT). A departure from RWY 32 should not have caused any delay to their progress up the Strait. That being the case, EK343 should have been passing MEKAR at around 18:05 UTC, a good 15 minutes ahead of MH370.
Regarding our goood mate Daud, I don’t think that we can accuse him of contradicting facts and statements that weren’t then in evidence – the Lido slide wasn’t produced for another eight or nine days. That said, if you were to describe the flow of information in those first few weeks as a largely inconsistent rambling shambles, you’d get no argument from me.
@all,
Here is a paper on my interpretation of the 18:25 to 18:41 satellite data:
https://drive.google.com/file/d/0BzOIIFNlx2aUeDhxNFRrUU5DNE0/view?usp=sharing
Major findings are as follows:
1. Using a detailed OXCO model, I have demonstrated that the OXCO warm-up transient fully explains the unusual BFO pattern, including the 273 Hz.
2. The BFOs at 18:25 and 18:27 are significantly affected by the OXCO warm-up transient.
3. There do not appear to be any significant deviations during the time period 18:25–18:28 caused by course, speed, or altitude changes.
4. A lateral offset to the right side of N571 beginning at ~18:22, followed by a single FMT at 18:38:40, is consistent with all the 18:25-18:41 BTO and BFO data and the military radar track.
5. No speed or altitude changes are indicated in this time period from 18:22 to 18:41.
6. The 00:19 BFOs are hardly affected by the OXCO warm-up transient effect (by 0-7 Hz) because the depowered time was so short (~1 minute).
7. The Rates of Descent at 00:19 may be computed with very little error without correcting the BFOs for the OXCO warm-up transient.
Your comments, corrections, and questions are welcomed.
@VictorI – How does the heading of your “path of best BFO/BTO match” compare to the 10.1831/90.2245 location recovered for ZS’s simulator?
@Welcome, Lauren.
Starting from the 18:02 position, the 10N would be at a track of 298T, versus 297T for the “best match”. The 10N path would be acceptable.
@DrB
I am unable to copy paste from your paper. On page 6 you reference an 18:25:27 BFO of 138Hz. I have it at 142 Hz, but no matter. How one can deem this BFO as untrustworthy due to a warm up transient totally escapes me. The 142Hz is perfectly consistent with the aircraft speed, track, and location at that time.
There was obviously no impact from a BFO warmup transient. The BFO 7 seconds later of 273Hz is obviously grossly out of line with the speed and track, and was the result of some transient. There could be very little change in oven temperature over a 7 second time period.
Also, as I mentioned previously, your conclusion of position at 19:41 (while consistent with the analytics done here over the last week – seems like a month or more) is very disappointing relative to the generation of terminal locations above 34S-35S. I do not believe the aircraft flew straight South between 18:40 and 19:41.
Bobby: Excellent paper. Very well done. I am impressed to see not only the 18:25 event fit to the OCXO thermal transient I proposed, but all 7 documented by Holland. I think we have this one nailed. I sent several comments and minor corrections via email. ALSM
The following narrative is a bit of analysis, with some conjecture, regarding the provenance of the military primary radar data. Sorry for the length. I presume people know where to fetch the original source material – I will post links if necessary.
The flight path derived from the primary radar data can be divided into three sections: a first section from IGARI through the turnback to some location, a gap, a second section from after the gap, crossing the Peninsular Malyasia from Kota Bharu to Penang Island into the Strait of Malacca up to a time of 18:01:49, another (tiny) gap, and a third section from rougly Pulau Perak up the Strait of Malacca to the final point of radar contact. The final point itself has two variants: one at 18:15, and the other at 18:22:12.
The briefing provided by Daud on Day 5 gave a hint of what data exists, but it provided little detail (and let us put aside exactly what he did or did not say.)
The first image with any radar data was apparently a graphic released by “Jabatan Penerangan Malaysia” (a government information agency) showing the North and South corridors. The point labeled “Last Radar Contact with MH370” is at the 18:01:49 position.
The first Lido Hotel image of March 21 is the only figure we have seen with anything resembling raw data. It covers the tail end of the second section and the full third section of the radar path up to 18:22:12 (notwithstanding that the last point falls off the screen.)
The “Annex” to the AAIB report of March 25 (presenting the BFO analysis) contained a figure showing two possible paths to the SIO. The starting point appears to be the 18:22 position.
The April 29, 2014 seond Lido radar image shows sections 2 and 3 (including the tiny gap.) Section 3 is now drawn as a straight line without any raw data. The first section is absent, as is any secondary radar data from the beginning of the flight.
On May 1, 2014, three figures were posted to Hishammuddin Hussein’s Facebook site. In the second figure, for the first time, all three sections of the primary military radar path are shown, along with the secondary radar path from KL up to IGARI. The 18:01:49 point is identified and labeled as “Air Defense Radar Point 18:01:49”. The last radar point is identified as “Updated Last Air Defense Radar point 18:22:00”.
On May 6, 2014, the “Malaysia Communication and Multimedia Commission” (MCMC, aka SKMM) released two maps in Appendix K-2 to Folder 4 of the RMP Report. Both were created by the MCMC. The first shows the radar path consisting of section 2 of the military primary radar, the initial portion of the route as given by the filed flight plan (not the “direct IGARI” route actually flown), and a thin line showing the diversion from IGARI to the beginning of section 2, without any gap between the two. The first portion of section 2 deviates slightly to the South from all other version of this section. The source of this information was given as the RMP (aka PDRM). The second map is a blowup of the route around the South end of Penang Island. A “glitch”, consisting of an apparent deviation North, is seen just at the moment that the copilot’s cell phone made contact.
On May 26, 2014, the ATSB released “Considerations on defining the search area – MH370”, which is still on the ATSB website as a “Fact Sheet”. Figure 1 is essentially a copy of the May 1 figure, with less annotation. Interestingly, attribution is given as “Source: NTSB/Google”.
On June 26, 2014, the ATSB release “Definition of Underwater Search Areas”. Figure 2 repeats the same figure from May 26. The large gap between Sections 1 and 2 and the tiny gap bewteen sections 2 and 3 are visible, as is the glitch at the South end of Penang Island. A latitude-longitude grid was added. Attribution is now “JIT/Google”. Someone must have felt slighted.
On November 30, 2015, the DSTG released a draft of “Bayesian Methods”. Figure 4.1 is yet another rendition of the route, this time with all gaps filled in and a single color/line weight for the entire flight path (without attribution).
——————————
What can we conclude? Conjecture – someone (perhaps the NTSB) with access to the Malysian radar data constructed three KML files that have been used repeatedly to create various Google Earth renditions of the flight path. It is possible that some variant of these KML files is what was given to the DSTG. It is possible that the Malaysians themselves don’t have anything better.
Or not.
@Mick Gilbert
Re: EK343 Take Off
One thing we are missing is EK343 take off time. MH370 for example departed gate almost 10 minutes early at 00:27 but did not take off until 00:41. If we say EK343 departed gate 1:14 and took off around 1:30 MYT, and the point past VAMPI is about 370 nM from KLIA, I am thinking the location is about right. I presume the average speed for first 50 minutes includes slower speeds at take off and climb.
@DennisW
I converted the p.27/p.30 graphs in the Bayesian Methods book into CSV so that’s some data for checking the normality of BTO/BFO residual. The time precision is lost, but the order of points should be same as the original data the picture was generated from.
https://github.com/kprostyakov/svg2csv/tree/master/out
@TBill
Re: EK343
Yes, very good point, that would explain the difference. Thank you.
@sk999
Interesting background.
The straight section after Penang seems to me skirts VAMPI, MEKAR, NILAM and points directly to APASI. In this case to meet BTO/BFO, I think I am initiating a climb after MEKAR 1822 and slowing down during the process. Home simulator case I think hit FL400 at 1090E (if I recall). So that’s my rationale for that case.
@ALSM
Well, presumably the the ATSB and their collaborators have insights into all of these issues – the transient response of the oscillator including the power of the oven and the thermal mass of the assembly, and the transfer function between frequency and temperature. this information is missing from their reports. I wonder why that is. Do you wonder why that is?
I have had many disagreements with the ATSB and the IG over the years. I have been embarrassed by none of them. Your original statements regarding oscillator accuracy over the course of a flight are laughingly wrong, but you have no recollection of that. I have little regard for your opinions.
North Korea spy agency runs arms operation out of Malaysia, U.N. says | Reuters
“And it does have a business, the draft U.N. report says. Last July, an air shipment of North Korean military communications equipment, sent from China and bound for Eritrea, was intercepted in an unnamed country. The seized equipment included 45 boxes of battlefield radios … ”
http://mobile.reuters.com/article/idUSKBN1650YE?utm_source=The+Sinocism+China+Newsletter&utm_campaign=3e26916222-EMAIL_CAMPAIGN_2017_02_28&utm_medium=email&utm_term=0_171f237867-3e26916222-29700549&mc_cid=3e26916222&mc_eid=c51db42f86
@sk999. Nice work. I did a little digging on the RMP positions south of Penang with 1 minute spacing. It was a bit of a bugger to geolocate (as you also discovered) because the RMP plot is not north-up.
Assumed that the radial from radar head should be correct even if the range isn’t (radar experts: is that correct?). Then applied what we think is the GS based on the rest of the track. That allows you to impute a range (since radial change must now produce the appropriate distance over ground). Bottom line is that the RMP positions south of Penang are plotted a little too far “out” – not surprising given that they had attributed much higher altitude to these positions. Magnitude of range error doesn’t quite match the trig-derived horizontal range difference for FL447 vs FL350 and the relationship breaks down completely for the last position.
Still, it does at least allow us the following (I think – comments welcome):
– indirect confirmation that altitude interpretation on the radar was wrong
– nearly certain that the track passed a bit closer to Penang Is than indicated by RMP
– we should be able to derive a “solid” time/position when aircraft is “abeam” the radar
Similar conclusions apply to Kota Bharu. But in that case it looks to me as if the whole primary radar track has been geo-located a couple of miles out – partly because of apparent time offset, partly because the cone of silence is in the wrong place.
When I get around to tidying up and plotting these calcs I’ll share…
@Mick,
The source of the flightradar24 screenshot of EK343 was a post in the flightradar24 forum dated 22nd March 2014, which claims to be taken at 18:22 UTC 7th March 2014 (02:22 MYT 8th March 2014).
Please see the link below.
https://www.dropbox.com/s/8ohesc8t1hmiqtu/EK343%20Source%20Web%20SIte.png?dl=0
The original post is still available at the following link:
https://forum.flightradar24.com/threads/7146-Malaysia-Airlines-Flight-Goes-Missing-En-Route-to-China-Flight-MH370/page107
I have no reason to believe it was faked.
I have found proof that it was from 18:22 UTC and 2014, but not that it was from 7th March. A6-ECM was used on many different routes, but I have not found a record that it was used on the KUL-DXB route on that date.
@Mick
“Regarding our goood mate Daud, I don’t think that we can accuse him of contradicting facts and statements that weren’t then in evidence – the Lido slide wasn’t produced for another eight or nine days. That said, if you were to describe the flow of information in those first few weeks as a largely inconsistent rambling shambles, you’d get no argument from me.”
My point was, that Daud was subsequently contradicted by the Beijing Lido slide, Factual Information and in my view the Inmarsat satellite data.
What Daud said so emphatically on Day 5 does not align with what we have subsequently been told.
I agree with your summary “largely inconsistent rambling shambles”, but would go a step further and call it obfuscation.
@Niels
“@Richard: What would be the 18:28:14.904 location in your estimate?”
7.1937°N 95.7622°E on a track of 295.663°T at a ground speed of 493.737 knots and altitude of 35,000 feet, which gives a BTO error of 0.0059 km and BFO error of 0.0001 Hz.
This is based on the last known radar point from the 10 second radar data at 18:01:49 UTC of 5.624829°N 99.048157°E.
@Richard
“In which case, ZS or the PIC is guilty as charged.”
While I am far from an expert in either field, thankfully there are marked differences between science and law.
On the matter of our eavesdropping PIC, discerning EK343’s position from a direct MEKAR clearance would be somewhat problematic at the best of times. Moreover, being able to recieve doesn’t equate to being able to transmit.
To the extent that you could determine that you had traffic closing from behind, flying an offset probably wouldn’t be your preferred course of action if you were hoping to avoid being spotted; for starters, the turn allows the separation distance to close rather rapidly. You’re also turning your airplane into profile and having it track across the observers field of vision.
In fact, it would not be difficult to make the case that you might fly an offset in order to maximise the chances of being visually acquired. An orbit or loiter, offset to an airway with the landing lights on would the sort of course of action you might expect in the event of a complete comms failure.
Why didn’t EK343 see MH370? It would certainly have been possible to see another airplane with nav/anti-collision lights on some 39 nm away but, of course, you would need to looking. I’m not sure what sort of visual watch the flight crew on EK343 would have been keeping at that point of their flight.
With regards to nav/anti-collision lights, the sighting at Pulau Perak was apparently visual, so I’m guessing no attempt to hide the airplane by turning the lights off had been made at that point.
With regards to TCAS, you don’t need to turn the transponder off to make TCAS inoperative; if the transponder is in standby mode it will not respond to TCAS interrogations.
Thank you for the details on the EK343 track. I knew it was in the area on the night but I don’t think that I’ve ever seen it so close to MH370’s track and position.
@Paul Smithson
In regard of the mentioned radar-tracks and altitudes around Penang I think also the co-pilots cell-phone connection has to be considered.
His cell-phone was picked up only (if we believe the news) in a south-west suburb of Georgetown from a cellphone-tower downtown placed on a mall.
This cell-tower has a open view to the east and north-east but not to the south for in that direction it’s blocked by a hill-range of ~200m.
With a recieving range of perhaps max. ~20miles this cellphone-mast has a line of sight not over ~30.000ft altitude at his max. range in my estimates.
IMO this only can mean MH370 came in from the north-east towards Georgetown under 30.000ft near Georgetown crossing the island over land and not south from the island over seas. The co-pilot’s cell-phone would not have been picked up south of Penang by this station IMO.
There has been a lot of discussion about the finally confirmed co-pilot’s cell-phone connection I know but I never saw an explanation that could fit the known radar-data.
Is there any?
@GR A 200m hill is not going to produce any terrain masking until the aircraft is very low indeed. At normal cruise he is >10 kms up in the air – so at a range of ~20kms from the tower this is plenty high enough to avoid any terrain masking from nearby hills.
@DrB: Thank you for the new paper. I haven’t read it carefully yet, but I would make the following comments:
1. It would be interesting to find the mechanism that causes the overshoot. Yes, a feedback-controlled system may overshoot depending on the damping of the closed-loop response, and the amount of overshoot is proportion to the initial temperature error. But my guess is the setpoint temperature of the crystal is so high compared to the initial temperature that the heater is fully on until the temperature gets close to the setpoint. This would tend to mask the effect of the initial temperature condition. Factors that would contribute to overshoot are sensor lag caused by the thermal mass of the thermal sensor, and heater lag caused by the thermal mass of the heater.
2. I know you believe that there was a lateral offset manoeuver that was squeezed in between 18:22 and 18:25, and I also understand that this route offset is critical to your theory. Another possibility is that the 18:22 radar point is wrong, and the lateral offset manoeuver was performed before 18:22. This preserves your theory (lateral offset at an EOR), but it doesn’t force the lateral offset into a small time window. You really don’t have to decide which occurred because you are at the same position by 18:25.
@Manifest Reminder: Malaysia seems to be associated with lots of bad things. Just off the top of my head: MH370, MH17, 1MDB theft of funds, Scorpene submarine bribes, North Korean assassination, North Korean gun running, chemical weapons from China to Iran, polymer banknote bribes…
@Paul Smithson
It depends on where the mast is stationed. In this case the mast was quite near under this ~200m southern hills. A few hundred metres.
Those cellphone-mast sections are not pointed to the sky but to cover as much land as possible directed mainly to the earth surface.
Their angle of sight sending and recieving is quite narrow. They are not designed to also recieve messages of overflying planes at or above 30.000ft.
There are not there main customers offcourse.
Your answer also does not explain why and why only this station recieved the co-pilots call.
I’m not willing to make a stand but just something to consider relating to the radar-data around Penang.
@Kirill Prostyakov: Welcome, and thank you for making those files available.
@Ge Rijn: Don Thompson has geolocated the cell tower to be atop the St John Ambulance building at (5.405890, 100.298035). @sk999 has determined, using the map shown in the RMP report, that the coordinates of the cell phone connect are (5.220, 100.289). If you plot these on Google Earth, you will find that there are no hills to obstruct the view between these points.
The ground distance between these points is about 20 km, which is within range for the cell phone tower to register the cell phone. The path is roughly tangential to the LOS path, so the Doppler shift will be small. The elevation angle would be about 24 deg at 30,000 ft. Unfortunately, we don’t know the radiation pattern of the antenna to put bounds on what altitude might be possible for a cell phone to register at this distance. For instance, there could be a narrow lobe in the radiation pattern at this elevation.
@DennisW,
You said: “There was obviously no impact from a BFO warmup transient. The BFO 7 seconds later of 273Hz is obviously grossly out of line with the speed and track, and was the result of some transient. There could be very little change in oven temperature over a 7 second time period.”
I will remind you that the OXCO must heat the crystal from -55C to near +75C and settle and operate in less than 4 minutes. That is a maximum heating rate of at least 130C/240 s = 0.54C/s. In 7 seconds the crystal can be heated up to 7 s * 0.54C/s = 3.8C. That’s a whopping temperature change capability. The observed frequency rate is 130 Hz in 7 seconds, or 18.6 Hz/s. So we need at least 130 Hz per 3.8C = 34 Hz/C. At 1646 MHz uplink frequency, 34 Hz is .021 PPM. Thus we need to get a crystal frequency sensitivity of at least 34 Hz/C * (1 PPM/1646 Hz) = 0.021 PPM/C. That is easy to achieve when I look at the frequency versus temperature curves for SC-cut crystals. I think up to 0.100 PPM/C is possible.
@Victot Ianallo
I dispute this. The Farlim Air Item location is a pocket surrounded by hills.
No way only this station recorded the co-pilots cell-phone if MH370 was not coming in low from the north-east over Georgetown.
If it flew around south other cell-phone towers would have picked-up the call but but nit the Farlim station.
Album weergeven Voer hier de naam van het album in
Diavoorstelling weergeven Alles downloaden
Dit album bevat 1 foto en blijft beschikbaar op OneDrive tot 29-5-2017.
Klik hier of sleep foto’s naar dit venster om deze aan dit album op OneDrive toe te voegen.
KmlFile
normal
#pano_cluster0n
highlight
#pano_cluster0h
0.3
http://kh.google.com:80/flatfile?lf-0-icons/panoramio_cluster_n1.png
32
32
0
$[description]
ff000000
0
1
ff000000
0.5
http://kh.google.com:80/flatfile?lf-0-icons/panoramio_cluster_n1.png
32
32
$[description]
ff000000
0
1
ff000000
We are waiting…..
<![CDATA[Ayer Itam,Pulau Pinang,Malaysia]]>
#1052801
100.280457,5.375398,0
I managed to copy the Google earth capture at last. As you can see the cell tower is surrounded by hills to the south west and east.
@Ge Rijn: Did you plot the coordinates I presented using GE? If not, please do. Perhaps you are looking at a different cell tower than Don Thompson identified. Don looked for cell towers in the area operated by the particular cell carrier to arrive at the St John Ambulance building. For the coordinates I provided, there is no obstruction from hills.
@Kirill Prostyakov,
It’s good to hear you are still involved. I have two questions:
(1) Can you do the same trick on Figure 5.5 on Page 31? That’s the BFO errors histogram. What I really want to see is the time/BFO data pairs for each point making up the histogram. I don’t see how that could be embedded, but I thought I would ask.
(2) The first file (MH371_070314) has about 332 pairs of what looks like BTO errors. Which figure is this from? Can it possibly be Figure 5.2? What is the first column (5.010231 etc.)?
@Richard @Mick Gilbert
Does anybody know what the Flight coming behind EK343 to VAMPI was? Yellow aircraft on the EK343 1822 screen grab.
Another flight of interest to me is EK425 taking off from Perth to Dubai 6AM was potentially close to several of Richards Arc7 end points near 22S. I found that one by looking at recent FR24 flights at MH370 flight end time, and then confirmed it also flew 8-Mar-2014 by Flightstats.com. Then I ran quick FS9 simulation for approx. path timing. It probably hit 7th arc about right time on path L894.
The questions that these flight raise: Did anyone interview those EK pilots at the time? If not, why not? Also I give a months salary (but I am retired) to look at FR24 screen history details that day for the whole flight path. I suppose nothing available anymore?
@Victor,
Thanks for your comments on my paper. BTW, for completeness I am adding a section on the possibility of a descent at 18:40.
You said: “Yes, a feedback-controlled system may overshoot depending on the damping of the closed-loop response, and the amount of overshoot is proportion to the initial temperature error. But my guess is the setpoint temperature of the crystal is so high compared to the initial temperature that the heater is fully on until the temperature gets close to the setpoint. This would tend to mask the effect of the initial temperature condition. Factors that would contribute to overshoot are sensor lag caused by the thermal mass of the thermal sensor, and heater lag caused by the thermal mass of the heater.”
Yes, I agree that the heater will probably be full on when the OXCO is initially cold, and that it is likely the PI controller is just using P (= proportional) until the error is small enough to connect the integrator. For larger temperature error, the proportional output will be limited at the maximum heater output. The time to heat to the operating point is going to be pretty linear with the initial temperature error. That is what I have assumed in figuring the time-to-LOR, and it is not significantly affected by the overshoot characteristic.
Yes, the overshoot will depend on a number of factors, and the ones you mentioned would be compensated by the designer in selecting the damping factor and natural frequency. The overshoot amplitude depends on the temperature error when the integrator is switched on, and on the velocity (C/s) when that switching occurs. Even if the error is small, the velocity is not small when the integrator is enabled. That’s what makes overshoot in a PI controller. If you add a derivative (D) then you get a term that will reduce the velocity before you cross zero error, and this leads to lower or no overshoot. In a PI controller, the servo is integrating the error, and that integral cannot be reduced to zero except by integrating an error of the opposite sign (=overshoot). The velocity will depend on whether the heater is still full on or is already in the linear range, and this depends on the initial temperature. Thus the overshoot will still depend on the initial temperature even with the integrator switch. We can only speculate based on experience how the temperature servo actually works, but it is clear from the BFO data than overshoots happen, and they are not all the same amplitude. The ground-based overshoots are smaller than the in-flight case. The shorter depowered times have smaller overshoots. We also know from the BFO data that the overshoot amplitude roughly depends on the initial temperature error. We would need to know all the details of the servo design in order to accurately model it, but a generic PI model with a few fitted parameters seems to be consistent with all 7 events.
You also said: “. I know you believe that there was a lateral offset manoeuver that was squeezed in between 18:22 and 18:25, and I also understand that this route offset is critical to your theory. Another possibility is that the 18:22 radar point is wrong, and the lateral offset manoeuver was performed before 18:22. This preserves your theory (lateral offset at an EOR), but it doesn’t force the lateral offset into a small time window. You really don’t have to decide which occurred because you are at the same position by 18:25.”
I agree. The BTO data only require that the offset position be established by ~18:25 (or possibly a change in bearing occurred at an earlier time). If the 18:22 radar position is incorrect, the offset could have occurred prior to 18:22. However, the Lido slide shows a straight track from VAMPI to MEKAR with no evidence of an offset occurring before 18:22. You can decide to ignore it if you want, but I don’t think it was fabricated, just poorly annotated. Besides, I think that the 18:22 location is not quite outside the nominal maximum radar range (perhaps my memory of this is incorrect). If so, why was the contact lost? A turn perhaps? The RCS of a B777 varies rapidly with look angle. You can get 40 dB changes in a turn of tens of degrees. Maybe that’s why the radar track ended.
BTW, I tried allowing the 18:22 position to move along N571. I get an improved fit at 8.2 NM past MEKAR instead of 10.
If you leave the Beijing slide and the statement from Daud on one side for the moment there is still a lot of potential evidence to digest from the ATSB, DSTG, Inmarsat, Malaysian Factual Information and RMP:
1. 10 second Radar Data Points.
2. BBFARLIM2 Mobile Detection.
3. Eye Witness Pulau Perak.
4. Last Radar Point N571 MEKAR + 10 NM.
5. Inmarsat Satellite Data Point at 18:28:15 UTC, 2.8 minutes after reactivation.
6. N.W. Theoretical Point – Limit Line with waypoint IGREX.
7. ZS Home Flight Simulator recovered data point at 10.183126°N 90.224518°E.
8. The Arc at 19:41:03 UTC.
Here is a link to a plot of all these data points:
https://www.dropbox.com/s/dgqaeeuuykc4xw0/MH370%20Evidenced%20Flight%20Path.pdf?dl=0
None of the 8 items listed by Richard are ‘evidence’. No radar data has been produced by the authorities, other than illegible drawings of some intermittent dots in the FI. There were no actual ’10 second Radar Data Points’, only ‘estimates’, another word for ‘guesses’.
If indeed the co-pilot’s cell phone was detected near Penang, it would have been mentioned in the FI as such detection would constitute proof of the turnback. The FI never said anything about this alleged detection. The version of the RMP Report ‘leaked’ online is a doctored document, the part about the cell phone detection is a fabrication and does not appear in the real RMP Report. The Malaysian chief of police Khalid (ie head of RMP) effectively denied there was such detection when this story first emerged in April 2014. The Chief Minister of Penang at the same time, called for action to be taken against NST for making up this story.
What ‘Eye Witness Pulau Perak’? Was there ever a credible report of someone at Pulau Perak having seen MH370?
The rest of the items are just pins on a map. There is no evidence the plane was at any of these locations. Only theories.
@Alex: do you have a link either to the original RMP report (so we can compare) or to evidence/expert opinion that the leak was “doctored”?
Like all the other graphic images held out to us as “evidence”, I’ve been skeptical of that leak’s authenticity, but had not yet rejected it as fake.
Supporting the view that the leak is not authentic: its emergence at the end of the search, and the officially-purported cruising speed past Penang, which strongly points to cruising altitude – both of which strongly point to “zero bars” for all the many cell phones on board. But this is only indirect evidence of doctoring – you seemed to hint at direct evidence.
I agree this alleged event’s absence from the FI report is evidence of state deceit; but some still think (hope?) the leak was authentic, and the FI report was “doctored”. Until I see direct evidence one way or another, I cannot draw any firm conclusion. This is why I asked CNN’s Pamela Brown (who first reported the claim in the western media) to seek clarification from her anonymous source. I see nothing to suggest she has bothered to follow up on this critical point; I will ask her again.
@AlexSiew
You forgot to mention that the ATSB, DSTG and Inmarsat are also all dealing in lies and fakes.
@Richard said;
“The source of the flightradar24 screenshot of EK343 was a post in the flightradar24 forum”..(URL stated)
…”I have no reason to believe it was faked.”
I gave reasons back in early February why that screenshot should be,considered ‘suspect‘;
…should probably regard the screenshot you cited as ‘unproven’ – the
original {FlightRadar} poster ‘Beggarman’ sounds intelligent,and conceivably
might have retrieved a flight plot of EK343 in the 7 days after
MH370 went missing – but you should understand that the free ‘Basic’
Flightradar service only retrieves backwards for 7 days, and that that
Basic service has advertisements (which we see one of in the bottom
right of the screenshot). Therefore this screenshot was made using the
Basic service, not the ‘ad removed’, money-payable services that allow
retrieval greater than 7 days back. This screenshot was posted on
Flightradar forum on 22 Mar 14 … so, you can understand if the
screenshot is regarded with some scepticism…
https://web.archive.org/web/20140516212034/https://www.flightradar24.com/premium/
@Mick
I respect your well researched work and hypothesis of a cockpit fire. I personally think it unlikely that an aircraft continues to fly for around 7 hours after a cockpit fire. I appreciate your argument, that MH370 was an unusual case, that does not fit the statistics of previous in-flight cockpit fires, where aircraft lasted no longer than 20 minutes after a fire started.
You have noted my hypothesis is a murder-suicide by ZS.
Motive: Hold the Malaysian Government to ransom with the passengers, crew and aircraft, in order to free the opposition leader Anwar Ibrahim from jail, on what was widely viewed as a politically motivated trumped up charge.
Means: MH370, its passengers and crew held to ransom, whilst negotiations take place as the aircraft is in a holding pattern over Indian airspace around Car Nicobar.
Opportunity: The last training flight of a co-pilot with only 39 hours flying experience on a B777.
Intent: Shown by simulating a flight to the southern Indian Ocean on his home flight simulator and then deleting the files, in order to try and cover up.
@AlexSiew: You made a specific claim that “[t]he version of the RMP Report ‘leaked’ online is a doctored document, the part about the cell phone detection is a fabrication and does not appear in the real RMP Report.”
Please provide evidence supporting your claim. I will allow reasonable conjecture, and I encourage commenters to question past assumptions, but I won’t allow commenters to deliberately make false claims.
@Mick Gilbert @Buyerninety
Today I monitored N571. EK343 was earlier today by about 15 minutes or so, despite a similar gate departure time. It had a faster speed too 520 or so.
When EK343 hit the Nicobars about 18:40, also in the same time/vicinity were two incoming flights to KLIA and one flight jogged over to N571 from Thailand.
From 18:45 to 19:40 the N571/Nicobars was empty until two outbound Singapore flights came thru and one inbound flight came thru.
Nothing went over the Car Nicobar protected area, I guess @Richard and @Victor are saying that’s a possible place for MH370 to hangout.
Posted by Nederland on the JW site,
“MH370:final report expected by end of year
http://www.thesundaily.my/news/2178436“
@Richard
Thanks Richard, I’m the first to admit that my hypothesis is just that, a hypothesis – it might be right, in whole or in part, or it could be completely wrong. Being essentially a layman, my approach has been somewhat different to the IG’s to a certain extent in that I looked at potential vulnerabilities of the operating airplane first, constructed a narrative around those and then rolled that out over the data to see if there was a “fit”.
From the outset I have been constantly in awe of the work that you and the IG have turned out on a regular basis (anywhere from some to a lot of the content has been above my brain grade but the rationale and conclusions have always been very accessible); your most recent paper and Dr Ulich’s recent paper being two very good examples.
Thank you for laying out your hypothesis; I’d inferred that you had the Captain in the frame but I hadn’t understood the hostage/ransom angle. That does cast the behaviour of the Malaysian authorities in a different light, a very different light. That’s an intriguing possibility.
@Buyerninety: Back in 2014 you could change the date in the flight radar URL while in play-back mode and go back much further than 7 days. No need to pay.. It was a trick I posted on DS forum and I’m sure many people were using it at that time. In my memory this option stopped working somewhere in autumn of 2014.
@DennisW,
Your memory is good. The reported raw BFO was 142 Hz at 18:25:27.
I subtracted 4.2 Hz to correct the R8 channel offset. The 138 Hz is the one consistent with 150.27 Hz BFO bias, and that is what I use.
@DrB: Thanks for reminding us. Channels R4, R10, and R11 seem to have a bias of 150 Hz, and Channel R8 is 154 Hz. So, you can either have a channel-dependent bias, or keep the bias constant and make an adjustment in the value of the measured BFO, as you have done.
@Richard (Godfrey? What follows presumes this identity; if incorrect, my apologies):
Re: your response to @AlexSiew:
With your implied assertion that we be persuaded by facts & logic, not bias & mongering, I could not agree more.
With your implied assertion that we persuade using a tone that is smug, sarcastic, & derisive, I could not agree less.
The average emerging IG position on Lido/ISAT cross-compatibility is roughly 180° from the average position it took back in the spring and summer of 2014 – when it mattered:
1) April, 2014: grainy photos depicting radar & signal data tied to each other nicely
2) NONE of the following moved the IG needle on this enough to call for a major search box move:
– May, 2014 release of ISAT data log (nor subsequent release of supplemental tarmac records)
– my January, 2015 audit documenting significant deficiencies in search leadership accountability
– March, 2015 FI report which cast aspersions on Lido image
– my April, 2015 study showing inconsistency of @ALSM’s flight sim data and planned search box WIDTH
– my December, 2015 study showing inconsistency of de tie record and planned search box POSITION
Instead, we’ve been treated to a long series of papers, each breathlessly proclaiming that the search was sure to bear fruit if we simply expanded the search a scant few miles beyond its then-current boundaries.
I have nothing but the deepest admiration for all who have tried their very best to help find closure for next of kin. And nothing but the deepest respect for those whose “very best” has been as strong as we’ve seen from the IG in particular, and this forum’s denizens in general.
And for crystal clarity: I do not support @AlexSiew’s hypothesis on MH370’s fate. But when I see an IG member attempt a haughty smack-down on someone who, like me, has worked hard, and without hope of reward, to find closure – and who, like me (but UNlike the IG) has been CONSISTENTLY sounding alarm bells on evidentiary veracity for these past three years – I consider the above timeline, and cannot help but wonder why it is so hard for some members of the IG to summon so much as an OUNCE of humility.
Last list element above: “de tie” should be “debris”. Apologies.
While I have the mic: how do proponents of the “brief loiter, then straight & fast to Arc7 @ 30°S” scenario explain non-detection by Cocos (Keeling) Island residents – by any radar (military or civilian, in real time or on review of recorded data), nor by sight or sound? Your scenario passes very close to this island of 600 residents. And being an Australian installation, we have no reason to think the search wouldn’t have the full benefit of its military intelligence to help inform search strategy.
@Victor
1. I believe the IG received some volumes of the ‘RMP Report’ in pdf form in late 2015 or early 2016. Perhaps the IG can reveal how these pdfs were given to them and why the IG chose not to release these pdfs (despite pleas from the ‘MH370 community’)?
2. Just from a quick glance through, it is clear this purported report is a doctored document. So for example in Folder 4 (SKMM Analysis), the parts incriminating the crew (for eg the incriminating parts of the Executive Summary) were drafted by person or persons whose first language was English (specifically American English) while the bulk and non-incriminating parts of the document were drafted by person or persons whose first language was not English as evidenced by the numerous grammatical errors and non-standard forms of expression. To my knowledge, there are no Americans in the Royal Malaysian Police Force.
3. To cut to the chase, let’s take a look at a critical part of the Report, Appendix J-1 (Crew’s Activities in a Timeline Highlights) and Appendix J-1A (Crew’s Activities in a Timeline all in a Diagram) of Folder 4. First, Appendix J-1.
(a) The real ‘Page 1 of 11’ is missing.
(b) ‘Page 6 of 11’ has been doctored, in a clumsy manner. The bottom part (about a call from an aircraft engineer in FEBRUARY 2014) is not part of the original page but had been superimposed on the page later. The superimposition was not done properly, the bottom part ended up appearing below the page.
(c) ‘Page 7 of 11’ has likewise been doctored. The incriminating part about the purported WeChat log-in by the pilot at 12.40am (1 minute prior to takeoff) had been inserted onto the page at a later time. All genuine timestamps had the date first followed by time but for this entry it was time first followed by date and with the ‘AM’ missing.
(d) The real ‘Page 8 of 11’ has been redacted, so only the last entry on the real page with a time stamp of 3:06:00AM is showing. The person/s doing the doctoring did not want people to know what went on between 12:41AM (the last timestamp on ‘Page 7 of 11’) and 3:06:00AM. This is the period of time when supposedly the co-pilot’s phone was detected (1:52AM).
(e) So what is represented as ‘Page 8 of 11’ is actually the trailing part of Page 8 and most of Page 9.
(f) The next page ‘Page 9 of 11′ is actually the trailing part of the true page 9 and the whole of Page 10. For confirmation, the notation ’10’ can be seen (left bottom of page).
(g) Moving on to the next page, this page is stated as ‘Page 10 of 11′ but is actually page 11 of the true Appendix. See the notation ’12’ on bottom right.
(h) The next page is stated as ‘Page 11 of 11’ but contained timestamps beginning at 6:38:57 PM. The last timestamp on the preceding page was 8:13:51 AM.
So the true Appendix J-1 was more than 11 pages (at least 12 pages), certain (exculpatory) parts have been redacted and certain (incriminating) parts have been added to the doctored version leaked online.
@Brock: I am not aware of any air radar capability on Cocos Island. If you have found evidence to the contrary, please share it. As for residents not detecting the plane, there are plenty of possible routes that end north of the current search area that don’t pass over Cocos Island.
As for members of the IG recommending a new search area…the original search failed. We now have that as knowledge that we didn’t before the search. Some of us are re-examining assumptions. I haven’t heard any IG members express certainty about where to look next.
@Alex: You have one more chance. You made a specific claim that “[t]he version of the RMP Report ‘leaked’ online is a doctored document, the part about the cell phone detection is a fabrication and does not appear in the real RMP Report.” This implies you have access or knowledge about what you believe is the original RMP report. Please produce this evidence, or I will conclude that you are deliberately making false claims.
Hi Victor,
This will be my last post on this blog, so I would appreciate it if you allow this post.
1. To follow up on the analysis in the previous post, the relevant pages of the main document have also been doctored to suppress what went on (or did not occur) between 12.40AM and 3:06AM. See Page 18 of 24 of the main document in Folder 4. Once again, there is a gap (redaction) between 12:40AM and 3:06AM, same as for Appendix J-1. Likewise for the ‘Table of Contents’, there is a gap between ‘BEFORE DEPARTURE’ and ‘AFTER THE FLIGHT WAS ANNOUNCED MISSING’.
2. When a document’s (a) table of contents with its numbering system, (b) main text, and (c) appendices, all show signs of doctoring or tampering effected with a common intent, none of the contents of the document can be trusted in terms of veracity.
@Richard,
3. Not all the Inmarsat data are bogus. There was a log-on at 1825 UTC but all purported data from 2000 UTC are bogus. If there was any traffic/data after 2000 UTC, it would have been captured by SITA logs but SITA logs only showed activity between 1248 UTC and 2000 UTC. See the FI.
4. Inmarsat said they provided SITA within 4 hours of the announcement by the Malaysians that the plane had gone missing at 7.24am MYT (2324 UTC), the ground station logs but that these logs did not show the pings which were only ‘discovered’ a day later. All transmissions to and from the AES would have the AES ID, so Inmarsat’s story does not make sense if indeed the pings are genuine as these pings would show up on the logs. Even if we put aside the transmissions from the AES (on the R and T channels), there would also have been the corresponding transmissions from the GES to the AES on the P channel which also would have the AES ID. These transmissions from the GES would definitely show up in the ground station logs, for eg the log-on interrogations and the final log-off.
5. The best fit for the BTO and BFO data is for a final turn at 1936 UTC with the plane then heading directly south on a 180 degree heading. Also as you pointed out more than 2 years ago on Duncan’s blog, the BFO values at 1827 UTC ( of 170+Hz) indicate a heading of true north 360 degrees. It means the plane’s purported track is identical to the satellite’s track for the duration of the pings.
6. The BTO data correlated with the movement of the satellite on the Z axis.
7. Why was the BFO and BTO data fabricated in such a way as to align with the movement of the satellite? Answer: to provide a way out for Inmarsat in the event one day the plane is found at the South China Sea at which time Inmarsat can say they had mistakenly assumed the BFO and BTO data was from a moving plane/stationary satellite rather than a moving satellite/stationary plane.
8. The central premise of the BFO/BTO theory is that the AES assumes the satellite is stationary at a fixed orbital position. This is not true. The AES on board 9M-MRO, MCS-6000 was ARINC 741/AMS(R)S compliant which means the Doppler compensation would have been calculated with the movement of the satellite taken into consideration (satellite inclination and satellite ascending node).
@Dennis,
9. The BFO value of 142 Hz did not appear in the BFO chart released by Inmarsat/AAIB on March 25, 2014. It only emerged in late May, in the Inmarsat datalog. In my view, this value has been fabricated to match the purported track of MH370.
10. The high BER and ‘unusually low’ C/No and received signal strength
of the 1825 UTC log-on are indicative of signal transmission from the LGA on a non-standard source of power. The value for received signal strength for this log-on given in October 2014 in Inmarsat’s paper The Search for MH370 published in the Journal of navigation, is, in my view, a fabrication.
Thank you Victor, I look forward to engaging with you in other forums.
@Victor: re: IG changing its mind(s): I must have made my point poorly.
The search strategy did not just fail yesterday – my work tried to show that it had very likely failed after the interior 40nmi had been searched. I begged the IG to peer review my study. Though it wasn’t published until April, 2015, I believe you’d all been given drafts to review by early March, 2015 – fully two years ago.
The drift work that followed shortly thereafter also conflicted with the search box – the informed among us have known this for ~19 months, now. I begged the IG to critique my drift work, too. While I did receive strong support from you, Victor, for the December, 2015 meta-analysis – which I deeply appreciated – the IG response to the emerging evidence was generally antagonism, followed by months of silence, followed by co-option of the result.
I was encouraged, for example, to see @ALSM this week refer to search widths beyond 40nmi as a waste of time; my problem is that, when that width was hit – in February, 2015, I was trying to make precisely that point to him in personal correspondence; he patiently “corrected” me, claiming they were still only 40% done…
I’m not chastising the IG, or any of its members, for changing their minds in response to new data. I’m just frustrated by the ~20 month delay in accepting that the data was already in hand. To the extent you had the ATSB’s ear, that turned out to be a very costly delay.
DrB,
Thank you for your recent paper. While I am most assuredly not qualified to offer comment on the BTO/BFO analysis I was struck by the notion that the final leg south was “a Constant True Heading route at Best Holding speed until fuel exhaustion occurred at ~00:17:30”.
Can I check what speed you are using for Best Holding Speed please? My understanding is that it should be less than 300 knots (around 260 knots at the FMT reducing to 235 knots at fuel exhaustion).
@Brock
Re: the slumbering inhabitants of the Cocos Islands.
First up, a direct track from around ANOKO to around 30°S on the 7th arc passes around 40+ nm to the west of the Cocos Islands. That transit would have occurred around early o’clock (4am-ish). I don’t know if you have lived near a beach but the sound of waves breaking is pretty much incessant. Similarly, I don’t know if you have ever looked into the night sky from a very remote location but generally the starfield is spectacular. So, we have an airplane flying around 500 knots at the 35,000 feet 40 miles away at 4am in the morning with reasonable ambient noise levels and a fair degree of visual clutter.
Second, no one thought the airplane had made it out of the South China Sea/Andaman Sea for the first week and half after it went missing. Accordingly, in the unlikely event that a Cocossian had per chance heard or seen something that morning there was no prompt to join the dots for 10 days.
@DrB
Fig. 5.5 does not have time information inside the XML. Sorry.
The MH371_070314 file is from Fig. 5.3, shown as red crosses. This is mentioned in text on next book page. Numbers in CSV have same units as graph, 5.xxx is days since 2-Mar. The good thing about point graphs is that they store all datapoints, even the repeating ones in the XML, so you get more in CSV than you can see with eyes.
To make sense of this data, ADS-B information is needed. I’d be happy to chip in like 50$ to buy from FlightAware. Are there any alternatives?
@TBill
Re:EK343
What is the airplane tracking behind 343 in that screen shot? That screen shot is a composite of a Skyvector map showing airways, waypoints, etc overlaid on the FlightRadar24 map. I’m pretty sure the yellow airplane icon is in fact 343. Whoever has created the composite has taken the FlightRadar24 recording of 343 and rewound it to where the recording started which pulls the airplane icon back along its track. I can imagine that there would have been a bit of to’ing and fro’ing getting the Skyvector overlay sorted out and lining up 343’s position at 18:22.
Regarding 343 last night, that’s interesting. Emirates are now operating A380s on that route, a smidge faster at cruise than a B772. Departure runway at KL can make a difference too; 32 sets you up nicely for the run up the Strait, 14 not so much.
@Brock: There has always been a healthy diversity of opinion within the IG. The statements that were jointly signed by the collective members are the only opinions you can rightfully claim belong to the IG. This has been explained many times.
By December 2014, some of us were already questioning the probabilities of a successful search outcome. For me, that did not equate to questioning the sincerity of the ATSB. It simply meant that assumptions of the flight reconstructions needed to be re-visited, including our interpretation of the Inmarsat data. The failure (at that time) to find ANY debris was also greatly troubling. If you recall, I was writing papers about Northern routes and the technical basis for a spoof of the Inmarsat data. That changed when debris started showing up. For me, each new find provided greater proof that the plane crashed in the SIO. I still believe this is true.
You are free to question the validity of the sparse data we have. But somehow attributing the cost of the failed search to the IG because we had the “ATSB’s ear” is totally unfounded. We are a private group that volunteers its time, just as you do. The ATSB is free to accept or reject anything that we have published, be it collectively or individually, in the same way it does with anything else that is privately produced, including your work, as well as the work of others here. And some of what has been produced by individual members has questioned the wisdom of the ATSB, including a short paper written by Richard Godfrey and me on the heels of the publication of the DSTG’s Bayesian analysis.
@victor
Firstly, I am assuming that comments here are moderated. AS such this should be read before it posts – I didn’t want to mail info@ as I’m not certain I should be mailing an MH370 comment to a company address.
If I’m wrong on these assumptions, I apologise. Please also understand that the following is intended completely in a spirit of helpfulness, not pointing fingers in any way.
1) To introduce myself – I am an educated person but not in the fields that MH370 requires – I read all the papers I can produced by the IG and others and I can at least follow the gist of most of them, but I am completely unqualified to point out errors in the science or calculations – I am an interested observer at best.
2) I am in awe of both the effort many people have put in to this, presumably unpaid, and also the spirit in which your new blog is conducted – there has been some small bitching but mostly the collegiate spirit in which the debates are conducted has been uplifting, esp for a public blog in the modern age.
3) There is one small field in which I am qualified to comment and that is the english language. This is also where I might be misunderstood and/or reveal myself to be an idiot 😉 For a couple of days there has been a discussion on the blog that was bugging me – specificially in relation to the “NW point” and a mail / letter that was sent to Niels from the ATSB clarifying this alleged radar contact. .I clearly remember both the comment with details and 2-3 followup comments. I cannot now find them in the comment chain. This could be my tired incompetence, or they could have been on a previous comment chain (which I have only scanned) – but I’ve gone back through the 300+ comments on this thread multiple times and cannot find it.
4) this leads me to believe that the moderation of the comments is not only one -off, but in this case a comment (and followups) have been removed. This is of course your prerogative. If it is the case I further assume it’s because either Niels or the ATSB has asked for a private communication to be removed.
5) If it’s not, and the comment is still there and I’m just an idiot – could I ask for your indulgence to point me to the date and time of the comment. And also to accept my apologies!
6) The reason is I think there’s been a fundamental misunderstanding – while english is the first language of some of the IG I don’t think it is for all. And the comments that were posted afterwards lead me to believe this is still misunderstood. I think the NW point does not exist in the sense many people believe, as such it is of limited value both of finding MH370 and also in terms of supporting various theories about motives and actions of data release on the part of the authourities, for want of a better term. It is a misconception that should be removed from the debate.
7) If i am correct, and that data has been removed from your site / comments, could I ask you email it to me privately and allow me to comment – these comments also to be directed to yourself privately, for dissemination amongst the relevant parties of the IG and others as you see fit, to remove this from the discussion once and for all. I believe I have a valuable point to make but have no desire or need for anything except a misconception to be cleared up.
7) If posts here are not moderated, and / or the comments in question are still on your blog and I’ve just missed them even after multiple rereads, then I’m about to look like a complete twat. Here goes *clicks submit*
PS thanks again. The blog / commentators / work is all much appreciated.
@penguins4all: I have not removed any comments that have appeared here, so you must have missed something. I am not sure exactly which comment you can’t find. Perhaps look at comments under the post Singapore Radar and MH370 .
@ victor
Thank you for replying. As I say it’s entirely possible I missed it or given the fallibility of human memory…
I shall reread everything for the 10th time and try to find it.. then add my 4 penneth.
Thanks for your time.
@Mick Gilbert
OK thank you I wondered how he got the airways on there, I updated to Silver membership on FR24, and I thought maybe that was not good enough. At least yesterday, nothing else came up N571 for another hour.
Is there any reason to question EK343 on 8-March-2014? Obviously it is still a daily flight around the same time, and there is no particular significance to MH370 except as an example of regular air traffic on N571.
@Brock said, “While I did receive strong support from you, Victor, for the December, 2015 meta-analysis – which I deeply appreciated – the IG response to the emerging evidence was generally antagonism, followed by months of silence, followed by co-option of the result.”
I should have also been clear that if you believe that somebody in the IG co-opted your work by using your results without proper attribution, please provide details.
penguins4all: Again, we can’t help you look without knowing what you are looking for. Perhaps you are referring to this comment from Niels, as well as my response?
@Victor: believe me: I have always been keenly aware of the critical difference between signed joint statements, and the views/papers of individual members. My lament is for the LACK of any joint statement on
– conflict between Lido image and Inmarsat PDF (known since June, 2014)
– conflict between empty Oz shores and seabed scan (known since Dec, 2014)
– conflict between 00:19 BFO and search box width (known since March, 2015)
The debris discoveries – and their handling by authorities – should have increased your interest in spoof theories, not decreased it. There is a 14 month gap between French buoyancy testing on the flaperon and the Australians eventually getting around to discovering that those tests ruled out where they’d been searching the whole time; is this the 14-month period during which your suspicions were being allayed? The “Roy” piece is even more damning to the search box – ditto the incredibly large gaps between # items expected and # items found, and between # items found and # items for which we’ve seen a comprehensive published analysis.
The debris record – on balance – favours impact areas like IGARI over places like the SIO. The entire SIO theory in fact hangs on the sole thread of the Inmarsat PDF – ESPECIALLY if the Lido image conflicts with it, as you now argue. I think it is time to devote resources to investigating the possibility that the signal data is in fact the joker in the pack. You are free to disagree, but it is illogical to use the debris record to defend any such stance.
@ victor
Thank you again. I made two mistakes, the prime one being looking for a comment not reading the body text of the posts again, hence missing the statements I was looking for.
The second mistake of course was failing to use CTRL-F, which shows you … well, I’ll leave that for you all to decide 🙂
I found the points that were bugging me in the text of the “singapore radar post”
I’ve also just written, then deleted, a long comment pointing out the flaws in your logic in that post… as partway through my diatribe I realised I’d actually slightly misread your post and although Niels’ and others comments still implied this was a radar capture, or at least possibly one “The most prominent next step would perhaps be to definitely find out if the NW point was indeed based on a radar capture or a “non-capture”. Not sure how to do this, because as you explained we are probably dealing with “shielded” information.”.. the post itself from you makes clear you understand this was a theoretical boundary beyond which MH370 would have been detected had she proceeded on the last known path, not an actual radar capture at all. The inexactitude of the statement from the ATSB that she passed “near” this point is what has caused confusion, when in fact their reply to Niels makes it clear that given what is known about the radar capabilities in the region this is a theoretical max path before FMT and in no way a radar capture.
So my apologies for my incompetence. In my defence a) I’m an idiot b) I can at least make my argument to Niels, as his is the one comment that doesn’t still understand and c) for your post to then speculate about the exact nature of the radar source that failed to make a capture is somewhat over the top, given the ATSB comment said ” (mainly Singapore)” , not exclusively Singapore, from Singapore etc. I think to assume an awacs is a heck of a stretch from that statement given the points beyond that could well have been excluded by non-singapore assets.
Nonetheless, and crappy apologies notwithstanding – Mea culpa. I thought having made claims I should at least back them up or make suitable apology. So…
Sorry, and I shall now hide silently under a rock.
@Mick Gilbert,
You said:” Can I check what speed you are using for Best Holding Speed please? My understanding is that it should be less than 300 knots (around 260 knots at the FMT reducing to 235 knots at fuel exhaustion).”
The Best Holding speed began at 18:42 and was 256.2 KIAS. It slowly declined to 237.4 KIAS at 00:08 when the right engine flamed out. This of course, led to a very high INOP Holding Fuel Flow in the left engine for 9 minutes until main engines fuel exhaustion at ~00:17:29.
Here is a plot of TAS, Flight level, Best Holding KIAS, SAT, weight, Fuel Flow, and Fuel on Board from 17:07 to 00:19:
https://drive.google.com/file/d/0BzOIIFNlx2aUZU5iRzN5U19UZ00/view?usp=sharing
There are notes with the plot explaining the in-flight events affecting these parameters.
@Kirill Prostyakov,
Thanks for the clarification. I would love to get my hands on the BFOs versus time for previous flights and do a spectral analysis on them to see if separate noise components (read noise, saw-teeth, drift, etc.) are identifiable. Then one could do spectral filtering to measure the amplitudes of each component.
Have you done any more work on the underwater acoustic and seismic data looking for an 00:21 impact? You might try running 34.01S, 94.14E and see if anything pops up.
@DrB: “at 00:08 when the right engine flamed out. This of course, led to a very high INOP Holding Fuel Flow in the left engine for 9 minutes until main engines fuel exhaustion at ~00:17:29.”
Why does the total fuel flow increase when the right engine flames out, i.e. ceases to burn fuel?
@Victor,
This posting is a trial run to see if can make your suggested format for an embedded URL link works. My plot of seven flight parameters for my proposed route, for which I gave a full-length URL above in my response to Mick Gilbert, can also be found here .
The format is: comment
The second feature you suggested is inserting a symbol such as “mu” by typing “&” and “mu” and “;” run together, thusly μ .
@Brock: I am not arguing that the Lido image conflicts with the Inmarsat data. I said that the 18:22 radar point, the 18:25-28 log-on data, a constant track of 296T, and a speed of 500 kn can’t all be true. I am not aware of anybody disputing this. Hence, the SLOP theory that Bobby U. is pursuing (which I acknowledge is possible) and well as the possibility that the last radar data is wrong, as I have asked people to consider. Both are theories. Neither is proven. I have no emotional attachment to either one.
If we are now arguing about joint statements that the IG hasn’t written but in your opinion should have written, it’s time to move on.
@Victor,
I had a slight problem listing the format.
The format is: comment
Hmmm. Third try to display format:
The format is: “ text ”. Don’t type the quotes, just what is inside.
@Victor,
I can make the embedded URL feature work, but I can’t seem to make the text string display here so other people can see how it is done. Can you help? Thanks. It is a useful feature.
For those interested in embedding text with hyperlinks, just use the standard HTML tag as follows:
<a href=”http://www.google.com”>Best Search Engine</a>
which will appear as
Best Search Engine
@DrB
You might want to look into PCA or ICA techniques to decompose single time series into sum of several. Looks like only BFO error data for 2-Mar-14 Mumbai flight are available so far. Still, ADS-B position data are needed too to make sense of non-stationarity. I’d assume they factored out satellite shadowing and such – though that can be checked quite easily with orbital software.
I’m going back to both imagery and acoustics. For better results I need Inmarsat-derived constraints for position vs. time. First I’ve started with code to interpolate time and direction grids over SIO without explicit path assumptions.
@DrB
Thank you for your very detailed response, that all makes perfect sense.
@TBill
My initial query of Richard’s EK343 track was largely because I had not previously seen that it came within 40-odd nm of MH370.
@Richard
In the interests of clarity and courtesy, my comment about science and the law was not directed at your hypothesis; I just thought that you were reaching for the black cap a little early in proceedings.
@Victor:
Co-opt; verb; adopt (an idea or policy) for one’s own use.
I have never given – nor will I ever give – a rat’s rear about attribution. By co-opted, I meant the correct definition above.
While you have never done this yourself, Victor, some members of the IG have disparaged key RESULTS (again: I could care less if they disparaged me personally), then, several months later, used that key result to support an argument. This is problematic, for obvious reasons: we were trying to advance the science as best and as fast as we could, so that the search could be optimized. If the key results (beyond 40nm width was pointless, SW of S34 was pointless) were going to be co-opted eventually, it should have been done when the analysis supporting it first emerged. That is all I am saying.
The IG bears no legal or moral responsibility to publish joint statements. One or two in 2015 – addressing emerging evidence that counter-indicated the search box – would have been nice, is all.
@Gysbreght,
You said: “Why does the total fuel flow increase when the right engine flames out, i.e. ceases to burn fuel?”
If my understanding is correct, when one engine fails in auto-throttle, the fuel flow to the remaining engine increases to try to maintain the INOP speed profile. Generally this will be a slightly higher fuel flow than for both engines combined just prior to the loss of thrust from one engine. I believe when ALSM did the simulator runs, (in ECON mode) the FF for the remaining engine increased to ~114% of the combined fuel flows just prior to the engine shutdown.
I think the situation will be similar for one engine inoperative when at Best Holding speed as it is in ECON. If engine failure occurs when at Holding speed above FL250, the aircraft will be unable to maintain altitude and will at some point have to descend to FL250. I don’t know when this will occur, but I have assumed the aircraft will simply decelerate initially, and then descend when it must to avoid a stall.
The Holding INOP tables have entries from FL50-250. The speed at 180 MT is 209 KIAS. The Fuel Flow is about 4750 kg/hr for one engine at FL250 and 180 MT. I am assuming a higher initial fuel flow than 4750 because the aircraft is, in my case, at FL360, not FL250. I simply add 14% to the last 2-engine combined fuel flow (the same increment seen in the simulator run at ECON). I have assumed the aircraft will first try to maintain speed and then descend when it can’t. I may be wrong about this. It could immediately descend to FL250 and burn less fuel in the process.
Does anyone know what the FMC does if one engine fails in Holding above FL250?
@Kirill,
I’m glad you are going back to the imagery and acoustics. The SIO is a big place, and for that kind of work you need a reasonably small area within which to look. It is clear now there is a big area where not to look, and that helps make the data mining manageable.
@Brock. Good. Let’s move on.
@DrB:
”If my understanding is correct, when one engine fails in auto-throttle, the fuel flow to the remaining engine increases to try to maintain the INOP speed profile.”
When one engine fails in autothrottle (A/T), the A/T will increase the thrust of the remaining engine to that required to maintain the commanded speed, or to the maximum thrust for the active rating (maximum cruise thrust), whichever is less. At FL 360 the maximum cruise thrust is too low to maintain the commanded holding speed, so the airplane will decelerate, as indicated in your chart. The fuel flow of the remaining engine at maximum cruise thrust will be less than that of the two engines prior to the loss of thrust from one engine. The autopilot maintains altitude until the speed reaches a minimum value for the weight (presumably the minimum maneuver speed of 208 kIAS at 180MT). At that point the A/P pitch mode changes to SPD, and the airplane will decend to maintain maneuver speed).
”The Holding INOP tables have entries from FL50-250. The speed at 180 MT is 209 KIAS. The Fuel Flow is about 4750 kg/hr for one engine at FL250 and 180 MT.”
In the same condition with both engines operating the fuel flow is 2470 kg/hr per engine, or 4940 kg/hr total.
There is probably some additional drag due to the thrust asymmetry with one engine inoperative, but apparently that is more than compensated by the engine operating more efficiently at near-maximum thrust than at the relatively low thrust required for holding with both engines operating.
@DrB:
P.S. The holding speed is either the speed for minimum fuel flow, or the maneuver speed +1 kt, whichever is greater. The speed of 209 kIAS at 180 MT is actually constrained by the second criterion.
@DrB & @Gysbreght: In the FSX PMDG 777 model, in an INOP condition, altitude is maintained to stall speed. At that point, a descent is maintained at or near stall speed. Also, as @Gysbreght said, for a given level of thrust, the fuel flow should be less for one engine than two.
@Victor Iannello: I suspect the FSX PMDG 777 model is not correct regarding the minimum speed maintained by A/P & A/T, and I doubt the stall speed itself is accurately modelled.
@Victor: “In the FSX PMDG 777 model, in an INOP condition, altitude is maintained to stall speed.”
I wonder on what observation your statement is based. Do you really know the stall speed assumed in the model? When you reduce the speed, minimum speed indications appear along the speed tape on the PFD, indicated by a coloured or patterned ‘band’. The maneuver speed is the top of that ‘band’, and slightly below it is the stick-shaker “stall warning speed”. I don’t think the stall speed is indicated. The airplane should never be flown intentionally below the maneuver speed, or above the maximum operating speeds Vmo/Mmo.
@Gysbreght: The speed is reduced down until the stick shakes and a descent begins. I think it was around 160 KIAS, but I would have to check. That is well below the manoeuver speed, and if not the stall speed, it’s got to be quite close. I’ll run some experiments to be more precise.
(@Niels
Your post gives a reason why we may consider the FlightRadar graphic is not wrong.
Another {minor} reason you could have cited is that the poster ‘Beggarman’ joined the
Flightradar forum on 2014-03-15;)
https://forum.flightradar24.com/members/45167-Beggarman
_______________
I started to look at flight tracks a few days days (in regard to an unrelated question),
and although I think this EK343 matter is not of great interest to either of us, I
thought others might be interested in seeing a recent EK343 track transfered to Skyvector.
(This is an Airbus A380-800, not the 777’s that Emirates were flying on this route back
in 2014.)
https://flightaware.com/live/flight/UAE343/history/20170228/1710ZZ/WMKK/OMDB
https://flightaware.com/live/flight/UAE343/history/20170228/1710Z/WMKK/OMDB/tracklog
I only plotted an incomplete set of points on that section of the track that I thought
others would find of interest, and placed the points in a Skyvector ‘flight plan’.
(Conversion example;
4.4975 99.5318 converts to 4°29’51.0″N 99°31’54.5″E , for simplicity I then disregarded
all after the decimal point, giving 042951N0993154E .)
(Skyvector may actually do some further slight ’rounding’ to the below points.)
035120N1002002E 042626N0993610E 042951N0993154E 043230N0992841E 043504N0992532E 043838N0991758E 044025N0991412E 044240N0991041E 044520N0990731E 044908N0990358E 045426N0985839E 045710N0985416E 045930N0985040E 045930N0985040E 050152N0984703E 054330N0974226E 055716N0972059E 061006N0970057E 062700N0963433E 062908N0963112E 063326N0962255E 063905N0961127E 064438N0960009E 064958N0954916E
@Buyerninety
OK we got that EK343 flight of yesterday nailed.
I made a FR24 screenshot at about MEKAR during the flight.
I see from your data they cut the corner at VAMPI.
As a former 777 pilot, I concur with Gysbreght’s comments re fuel flow. The performance manual figure for all-engines holding at FL250 at a weight of 180T is 2470 kg/hr/eng, for a total of 4940 kg/hr. The one-engine inoperative figure for the same conditions is 4750 kg/hr.
At FL350, the published all-engines figure is 2600 kg/hr/eng, for a total of 5200 kg/hr. As DrB mentioned previously, there are no figures for one-engine inoperative holding at FL350 simply because the aircraft is unable to maintain that altitude on one engine.
In DrB’s scenario, the autothrottle system will increase thrust on the remaining engine to the thrust limit, in an attempt to maintain the best hold speed. At high level, the engine is already operating much closer to the thrust limit than is the case at FL250, so the thrust and fuel flow won’t increase by the same factor. I’m guessing here, but I suspect the one-engine fuel flow at FL350 will be somewhere in the range 3500-4000 kg/hr. It certainly won’t be anywhere near as high as the all-engines figure of 5200 kg/hr.
Regarding the autopilot behaviour, we demonstrate the aircraft’s envelope protection in the full flight simulator by reducing the thrust at high level and waiting to see what happens. The autopilot maintains altitude as the speed decreases and continues to do so until the speed is well below the minimum manoeuvring speed, but just above stick shaker activation. At that point the autopilot gives up maintaining altitude, as indicated by an AUTOPILOT EICAS caution and an amber line through the pitch mode annunciation. The aircraft then descends and accelerates back to the minimum manoeuvring speed and continues descending at that speed.
@Gysbreght,
Thanks. I have modified my fuel model so after R engine flames out it uses the Inoperative Holding fuel flow with corrections for no racetrack turns, temperature, and L engine PDA.
@penguins4all
I invite you to come out from under your rock and identify yourself.
Concerning the “NW point”: I think that most of the interpretation part of the ATSB message was done by native English speaker, so no, a language issue does not explain the possible confusion. Also the “ac passed close to a NW point” is not causing much confusion, as indeed this may be part of an assumption. IMO what triggered some of us is:
– Why mention Singapore in the first place in relation to this particular location. Would you have a suggestion?
– If indeed the ac would have been detected if continuing on its roughly NW course (BTW this seems to be an interpretation from your side which I not necessarily share), which (ground based) radar facility is capable of doing such detection beyond the location mentioned. Also here: Would you have a suggestion?
@DrB: “I have modified my fuel model so after R engine flames out it uses the Inoperative Holding fuel flow “
At which altitude?
@Niels: As commenters have pointed out, the mobile radar source that didn’t detect the NW point might not have been airborne.
@Andrew: First, welcome, and thank you for your comment. We are fortunate to have a former 777 pilot join us.
What you describe at reduced thrust is what I see in the FSX simulator. The manoeuver speed is around 220 KIAS. The A/P maintains altitude down to around 163 KIAS, at which time a descent begins. The stabilizer is trimmed to around 220 KIAS, and that speed is approached and maintained during the descent.
I agree that single engine thrust is not sufficient to maintain ECON speeds at cruise altitudes. I think the SOP would be for the pilot to initiate a drift down to a lower altitude, perhaps at the company speed using the ENG OUT menu in the FMC. But is that also true for holding speed? The PMDG model for the 777-200LR says at FL340 and 175 MT, there is sufficient thrust from one engine to maintain altitude and holding speed. Now, the -LR has engines with higher thrust than the -ER, but I wonder if it is possible to maintain holding speed at FL340, for instance, with one engine.
@Mick
“In the interests of clarity and courtesy, my comment about science and the law was not directed at your hypothesis; I just thought that you were reaching for the black cap a little early in proceedings.”
Many thanks for the clarification.
We have all been studying the MH370 case for just short of 3 years.
I hope this is not a hasty judgement.
@niels
I’d be more than happy to come out from my rock except as I said before I fully accept I have no expertise in most of the necessary fields. You wouldn’t have a clue who I am and rightly so. Victor has my email address through these posts, I am more than happy for him to pass that on to you so you can contact me directly should you wish. I am not an expert but sometimes people get caught up in things and points can be missed (i.e. 295R vs FL295 earlier in this thread) so I do not believe my lack of expertise should forbid me from commenting if I see something that I believe has been missed, or in this case misunderstood.
Your reply actually I think backs up my point.
“It is an assumed theoretical location”. This cannot be clearer. Assumed in this context is a synonym of supposed, i.e. believed to be possible but not proven.
Theoretical – i.e. speculative and / or hypothetical.
So we have a point that is defined by the atsb in their reply to yourself to be speculative and hypothetical..
“Initially chosen to provide clearance from the known radar sources”
I.e., the known radar sources cover area A. This theoretical, hypothetical point was chosen to provide clearance, to be in an area outside of A that would not be covered by known sources and their known capabilities.
mentioning native English speaking was not to denigrate non-native speakers, but the English language is incredibly rich in nuance and some of this nuance is difficult for non-native speakers to resolve. Again all I can say is I’m trying to help and not trying to have a fight…
But the statements above make it very clear that this is an assumed, calculated point. It is not a capture.
Why mention Singapore? Again, the description of the sources says “mainly singapore” – so the area that can be thought to have been covered includes but is not limited to Singaporean assets. It is entirely feasible that say, points in a 120 degree forward arc from the proposed theoretical location could have been covered by Singaporean naval assets, while points in the other 60 degrees (of a 180 forward span from that point) could have been covered by, say, Indian naval assets. Therefore the location would be “mainly singapore” without in any way needing a specific (awacs) asset to be in place, without suggesting that Singapore has any more knowledge of the route taken by mh370 than anyone else, or any other interpretation you care to place upon this.
A ground based asset is not implied or required so I don’t need to provide one. I openly admit I would not be able to give you details or proof of all naval assets.from any and all nations that may or may not have been operating in the area at the time. But a ground (land) station is an assumption on your part that is not necessitated by the reply you received from the atsb.
As.i say I’m glad you replied, as this means that at least I can hopefully clear up this misconception for you at least, so my interjection has not been entirely wasted. I have no desire or intention to impugn you personally, I’m well aware that you’ve contributed more to these debates than I have and ever will.
But if you still believe there is a possibility this is an actual radar capture- then you are fundamentally misunderstanding the language used. Which was my original point.
Feel free to contact me direct should you wish, victor had my full permission to provide you with my email address.
All the best, seriously.
@Andrew:
Thank you for your input. Your description agrees with the FCOM, Chapter 9.20 Flight Controls – Systems Description
Normal Mode Pitch Control
Pitch Envelope Protection, Stall Protection:
“The autothrottle can support stall protection if armed and not engaged. If speed decreases to near stick shaker activation, the autothrottle engages in the appropriate mode (SPD or THR REF) and advances thrust to maintain minimum maneuvering speed (approximately the top of the amber band) or the speed set in the mode control panel speed window, whichever is greater. The EICAS message AIRSPEED LOW is displayed.”
@Victor: Engine out performance data assume CON (maximum continuous) thrust limit. Normal thrust limit in cruise is CLB (maximum climb thrust with all engines operating). Changing the thrust limit from CLB to CON after the failure of one engine requires an action from the pilot, either by executing the engine INOP flight plan on the CDU, or by pushing the CLB/CON switch on the MCP.
@Gysbreght: My comments about maintaining holding speed at cruise altitude were relative to CLB thrust, not maximum thrust. I assumed no pilot input. For this case, I believe it was N1=95% (GE engines, not RR, so not EPR). I should add that if it is possible, it is barely possibly. Just by adding a little more weight (fuel), and the holding speed could not be maintained at altitude with one engine.
@Victor: “I should add that if it is possible, it is barely possibly.”
Agreed. The FCOM 777-200ER/TRENT892 Engine INOP Driftdown Speed/Level Off Altitude at Max Continuous Thrust, 100 ft/min residual rate of climb, level off weight 174,000 kg, ISA+10°C & below, gives 219 kIAS optimum driftdown speed and 29500 ft leveloff pressure altitude
@Andrew,
@Gysbreght,
Welcome Andrew! I believe you can make useful contributions to this blog and help us understand some of the “strange” behaviors implied by the satellite data.
I would like to address three questions here.
The first one is:
1. If INOP Holding occurred at right engine failure at ~00:08:30, what was the fuel flow to the left engine for the next ~9 minutes?
If I use the INOP HOLDING table, and assume exactly 180 MT just for convenience in this discussion, the highest Flight level in the table is 250, the FF there is 4750 kg/hr, and the speed is 209 KIAS. So I could assume the 4750 is also valid at FL360 and use the same number.
Andrew said: “I’m guessing here, but I suspect the one-engine fuel flow at FL350 will be somewhere in the range 3500-4000 kg/hr. It certainly won’t be anywhere near as high as the all-engines figure of 5200 kg/hr.”
Andrew, please enlighten me as to why you think the FF would be lower than 4750. I’m not understanding the cause.
Gysbreght, you seem to believe the remaining engine would go to maximum continuous thrust. Do you have a suggested FF value for this condition?
The second question is:
2. How long in advance of reaching the Holding pattern fix (at ANOKO) would the FMC (a) begin to reduce air speed from LRC to Best Holding speed, and (b) display the End of Offset error? I am guessing about 2 minutes for each.
The third question is:
3. Can anyone see anything wrong in my description of the sequence of pilot actions that would produce simultaneous End of Offset and End of Route errors at ~18:44 at a fix ~10 NM to the right (west) of ANOKO?
A description of this can be found in a notional timeline here.
@DrB: “If I use the INOP HOLDING table, and assume exactly 180 MT just for convenience in this discussion, the highest Flight level in the table is 250, the FF there is 4750 kg/hr, and the speed is 209 KIAS. So I could assume the 4750 is also valid at FL360 and use the same number.”
There is about a 22K difference in temperature between FL360 and FL250. Lower temperature improves the engine efficiency (as the total temperature is reduced) and reduces the drag (due to Reynolds number effects). My guess is the fuel flow is lower at the higher altitude at 209 KIAS. The Mach number effect on drag is probably not noticeable at M=0.64 at FL360 and M=0.51 at FL250.
@DrB: “Gysbreght, you seem to believe the remaining engine would go to maximum continuous thrust. Do you have a suggested FF value for this condition?”
No, more recently (on reflection, after rechecking the FCOM) I said that the thrust limit after the first flame-out is CLB, until the pilot selects CON. Therefore CON is not available in an “unresponsive crew” scenario.
Apologies if my earlier off-the-cuff comment on some of the ATSB’s end-of-flight simulation scenarios has caused confusion. I should have checked before writing that.
@Victor: I think you are bringing in second-order effects. The main difference from a performance perspective between FL360 and FL250 is the ambient pressure, which at FL360 is 60% of that at FL250. The maximum thrust available at FL360 is less than at FL250, and also the fuel flow at those thrust levels.
@penguins4all
It is perfectly fine to discuss the interpretation of the NW point and be critical on the options discussed.
The main reason I’m a bit grumpy about your messages is that you seem to put the interpretation of the explanation about the NW point being a radar capture on my shoulders, which I feel is not correct.
I regret I didn’t make my position on this more clear in my postings; in recent email (from before Victor’s article) I have been pretty clear and tried to warn for misinterpretation. If necessary I may contact you by email to provide some background.
I think we all agree we just don’t know if the radar(s) referred to are air or surface based. Concerning ground based: In the interpretation where the radar(s) should be to the N or W, the only possible candidate I can come up with is Port Blair, but I have great doubts about both the possible range and if it was operated at all that night.
@Gysbreght: I based my response on roughly equal IAS at both altitudes, which I believe was Bobby’s question. Perhaps I misunderstood him.
@Victor,
@Gysbreght,
@Andrew,
My intended question is slightly different. Let me try again. What I really want to know is what the left engine FF goes to when the right engine shuts down if it were previously at Best Holding. I suppose the FF might also change as the aircraft slows down to the speed where it descends. I’m not sure if that descent begins before the left engine flames out ~9 minutes later. Does anyone have a guess as to the rate of change of air speed while in INOP and before a descent begins? Right now I’m using 5 KTAS/min while in INOP and 19 KTAS/min after the left engine quits. These are just guesses on my part.
@VictorI
About the location of cellphone station recording of the co-pilot’s cellphone:
https://031c074.netsolhost.com/WordPress/wp-content/uploads/2016/11/CxBkXXmWQAANPza.jpg
Bandur Baru Air Itam is surrounded by hills to the east, south and west as you can see:
Sunshine Farlim Shopping Mall
<![CDATA[
Sunshine Farlim Shopping Mall
No. 294, Jalan Thein Teik, Bandar Baru Air Itam, 11500, Air Itam, Pulau Pinang
Malaysia
+60 4 8271111
http://www.suiwah.com.my/
]]>
http://mw1.google.com/mw-earth-vectordb/blaces/00037/root.kmz/default.kml#generic_poi
http://www.google.com/maps/gen_204?ct=google_earth:popup&oi=blaces-generic_poi-undefined._._._.3de26e5c5a4c40a4_en&cad=lat:5.3966318,lon:100.287286,quad:023000322120201,cc:MY
100.287286,5.3966318,0
Coördinates are included but it’s more easy to look up for yourself in GoogleEarth.
DrB
The observations of the deceleration following one engine out in the SIM trials conducted by ALSM showed a linear change in TAS of 19 knots per minute. I plotted the observed speeds in my April 2015 paper on “The last 15 minutes”. The linear trend continued, in these cases, to beyond 270 seconds, and in fact right until the second engine failed.
From my paper . . “Flight dynamics are such that although drag and the available thrust are lower at higher altitude, the minimum drag speed also increases. Hence, coincident with one engine failing, we would expect deceleration to commence immediately and a reduction in altitude to begin as the minimum drag speed is approached. This was not observed in the simulator trials commencing at FL350. In fact the speed continued to decrease [below the minimum drag speed] without a descent being automatically commenced, but the ensuing part of the trial was cut short with the failure of the 2nd engine. The speed at which MH370 would begin to descend in the simulator trial is therefore unknown.”
It is possible to make some very important observations using this information concerning the aircraft path between the 6th and the 7th arc. For example, it is debatable whether the 7th arc could be reached in a straight line. More likely, in my view, the 7th arc is reached while the aircraft is turning left after the 2nd engine failure.
@Victor: “I agree that single engine thrust is not sufficient to maintain ECON speeds at cruise altitudes. I think the SOP would be for the pilot to initiate a drift down to a lower altitude, perhaps at the company speed using the ENG OUT menu in the FMC. But is that also true for holding speed? The PMDG model for the 777-200LR says at FL340 and 175 MT, there is sufficient thrust from one engine to maintain altitude and holding speed. Now, the -LR has engines with higher thrust than the -ER, but I wonder if it is possible to maintain holding speed at FL340, for instance, with one engine.”
Thank you for your kind welcome. Yes, the SOP for an engine failure in the cruise would be for the pilot to execute a drift down descent to a lower altitude in the first instance. However, it requires pilot input to the FMC to execute the drift down, as you indicated. I’m assuming that DrB’s scenario involves an unresponsive crew, in which case the aircraft will attempt to maintain the altitude and programmed holding speed by increasing thrust. If the thrust isn’t sufficient, then the envelope protections will eventually kick in and the aircraft will descend of its own accord.
The -LR engines have much higher available thrust than the Trent engines fitted to the MH370 aircraft, so the one engine inoperative maximum altitude in the Trent aircraft will be lower. As a guide, the level off altitude for a driftdown following an engine failure at a weight of 180T is FL280 (ISA + 10°C) for a Trent powered aircraft.
@Gysbreght: “The autothrottle can support stall protection if armed and not engaged. If speed decreases to near stick shaker activation, the autothrottle engages in the appropriate mode (SPD or THR REF) and advances thrust to maintain minimum maneuvering speed (approximately the top of the amber band) or the speed set in the mode control panel speed window, whichever is greater. The EICAS message AIRSPEED LOW is displayed.”
That paragraph in the FCOM refers to the case where the autothrottle was not controlling the speed before the aircraft approached the stall. In that event, the autothrottle will ‘wake up’ and automatically increase thrust in an attempt to prevent the aircraft stalling. In DrB’s scenario, the autothrottle will have already increased thrust in an attempt to maintain the holding speed following the engine failure.
@DrB:
Thank you for your welcome. I’m about to step out the door to go to work, so unfortunately I don’t have time to answer your questions at the moment. I’ll work on them later this afternoon.
Cheers all.
@Brian Anderson:
I’ve yet to see any response from @ALSM – according to the model you reference, what is your best estimate of the earliest possible time of 1st engine flameout, such that a B777-200ER at FL350 would retain sufficient speed to traverse the Arc 6 –> Arc 7 gap via any BTO-respecting straight (until 2nd engine flameout) path?
I ask merely because I’d like to understand how much of the ATSB’s “15 minutes” of potential time between flameouts is academic, because the BTO values / end-flight dynamics forbid it.
Thanks in advance for your time and consideration of this topic.
@Ge Rijn: We have a disagreement about the location of the cell tower. As I mentioned, Don Thompson identified the tower based on the telecom operator and other criteria, not just using descriptive words which give the general area but don’t precisely locate the tower. Perhaps he can explain the details of why he selected the tower he did. (Don is very meticulous about this kind of thing. I also know he is busy with other matters right now so he might not respond quickly.)
Comments here are closed. Please continue the discussion under the new post.