” When the aircraft is not logged into an ACARS server, the EICAS message DATALINK LOST is displayed.”

Thank you for that…we can’t see that on MS/PMDG flight sim, right? I am thinking we do not have ACARS logon selection screen like a real B777.

@ventus45

I tend to agree ZS could have been partially knowledeagble of the Inmarsat communications. Here is an Inmarsat website primer on ACARS/SATCOM operations, issued shortly after the loss of MH370.

https://www.inmarsat.com/news/faq-inmarsat-aircraft-safety-communications-services/

]]>To be honest, I don’t know, but I guess they’re trying to kill many birds with one stone, as it were. Toggling the cutout switches in the first instance would stop the runaway every time, but it’s probably an overkill for failure scenarios where simply ‘blipping’ the trim in the opposite direction might be enough to stop the runaway. The regulators would no doubt insist on a common procedure across all the different versions of the 737, so a change to the runaway trim procedure for the MAX would require a change for all 737s.

That said, the first step in the stabiliser checklist on the B777 is “STAB cutout switches (both) ………. CUTOUT”, so perhaps they will go down that route if this problem proves too hard to solve.

]]>It is simply a “disconnect” between the procedures and the cure. Wny not just toggle the trim cutout switches?

]]>More speculation from this recent development.

Lion 610 had nose downs (including ASI/Alt misreads and stick shaking) with two successive AoA sensors. Question is whether one became defective in service and its replacement misread (defective or maladjusted) or whether both nose downs resulted from processing, this microprocessor fault being a possibility.

It could be that the Lion difficulties stemmed from a different problem to the Ethiopian.

]]>RE: *“Is there not a fundamental flaw in the design of the 737 Max? This design fault necessitates software to correct it when the plane stalls and the nose dives and so on.
Boeing engineers trying to make the software 100% effective when the design of the plane (engines placed further forward than the 737s 800 to save fuel for example) lets the pilots down, have not managed to correct the MCAS and other software. Will they ever be able to since it’s not the software which is the basic problem but the design of the plane?”*

The change in engine location was necessitated by the increased size of the LEAP engines. Without a major re-design of the landing gear and wing, the only way to achieve the required ground clearance was to mount the engines further forward, which allowed them to be mounted slightly higher relative to the wing. However, during flight testing it was found that under a specific set of flight conditions the new engine location changed the relationship between the stick-force applied by the pilot and the load factor. The changed relationship made it easier for the pilot to stall the aircraft under that specific set of flight conditions, which was unacceptable. The solution to the problem was MCAS, which was intended to ‘fix’ the stick-force/g relationship at high angles of attack.

It’s not the first time that artificial measures have been taken to fix aerodynamic problems. If you have the time, there’s an interesting set of interviews with D.P. Davies (a renowned former CAA test pilot) on the Royal Aeronautical Society website (https://www.aerosociety.com/search?keywords=D.%20P.%20Davies&page=1). In those interviews, he discusses the various problems that were found during British certification of aircraft such as the Trident and B707, and the backlash he faced from the manufacturers and even the regulators.

I suspect that without a major re-design, Boeing has pretty much tweaked the 50-year old B737 as far as it can go with the MAX series. The B737 MAX problems are, I think, related to commercial pressures that Boeing faced, rather than a fundamental design flaw that can’t be resolved. The investigations are obviously ongoing, but it seems the design and implementation of MCAS was rushed in a bid to bring the aircraft to market as quickly as possible.

]]>My read suggests the electric trim was unacceptably slow to respond.

]]>RE: *“At first glance that or a like microprocessor might be fitted on earlier models therefore. If so at low altitude there could be a hazard in those from the same fault even should symptoms not be identical.”*

It’s not entirely clear, but the problem seems to be related to the interaction between Boeing’s revised software and the flight control computer (FCC). I doubt the earlier models have the same FCC and they certainly wouldn’t have the same software.

It’s also not clear why this particular failure slowed the test pilot’s response, as was reported. One of the first steps in the Runaway Stabiliser NNC is to try controlling the pitch attitude with the control column and electric trim. If the runaway continues, the next step is to deactivate the trim via the STAB TRIM CUTOUT switches. I don’t understand why this new issue would slow down that process. Perhaps there’s more to the story.

]]>Your comments can be applied to your own circumstances.

https://www.thetruthaboutcars.com/2006/08/killer-abs-abs-braking-increases-rollover-risk-by-51/

The reality is we are all impacted by a tidal wave of digital intrusion (as recently pointed out by George Gilder in “Life After Google”). I am actually enjoying it. Amazon’s AI often suggests things that I did not know I needed, and regularly buy.

]]>The same can be said about his knowledge of the radar and defense capabilities of Malaysia and Indonesia. Was he aware that Malaysia was unlikely to respond with an intercept as he flew towards and past Butterworth? Was he aware that Indonesia doesn’t operate military radar at night? Or did he falsely believe that one of the countries would respond to the intrusion?

]]>To say “It is highly unlikely that a pilot …” was intended as an expression of probability, not an expression of opinion.

Contriving that a weaving path could be likely, after the FMT, requires a belief that the perpetrator was some polymath with substantial knowledge of everything, not only of the protocol specification for Inmarsat’s AMS(R)S but the proprietary detail of the Ground Earth Station implementation developed and delivered by Inmarsat’s sub-contractor in 2013.

]]>Boeing engineers trying to make the software 100% effective when the design of the plane (engines placed further forward than the 737s 800 to save fuel for example) lets the pilots down, have not managed to correct the MCAS and other software. Will they ever be able to since it’s not the software which is the basic problem but the design of the plane?

Chelsey Sullenberger says the 737 MAX is fatally flawed. ]]>

At first glance that or a like microprocessor might be fitted on earlier models therefore. If so at low altitude there could be a hazard in those from the same fault even should symptoms not be identical.

Since no mention has been made of such wider implications I presume that first glance is misleading. ]]>

“… sort of like a ship zig-zagging down a baseline course”

The probability of the aircraft’s heading and ground speed matching the expected residuals derived from the BFO’s associated with each of the BTO’s would be so low, that the average bookie wouldn’t need to worry about keeping a “float” to cover his payouts.

I know I am being rather dismissive, but I doubt that even if Z was aware that the AES SDU had logged back on with the GES, the likelihood of him being aware of the GES to AES hourly (approx.) interrogation ‘pings’ is IMHO very remote. Yes, the unanswered incoming ‘phone calls were likely noted by whoever remained on the Flight Deck, and that at the time only the originator of those calls may have gleaned that the aircraft was still flying.

]]>FAA and Boeing initially disagreed on severity of “catastrophic” 737 Max software glitch

]]>“It is highly unlikely that a pilot …..”

I keep seeing this line of “dismissal” in one form or another.

Any police detective will tell you, that it is dangerous to assume, imply, let alone assert, that the suspect (in this case the pilot) “did not know ….(whatever)….” and thereby close off “lines of enquiry”. This form of “investigatory stupidity” has lead to many unsolved cases. In this case, we know that the guy was a tech nerd, he could have found out, and thus “know, anything that he wanted to know”.

Even at the most basic level, he had flow for years with SATCOM. He knew it logged on at power-up at the gate, and he knew that it stays logged on for the whole flight, until shut down at the arrival gate. He knew that it is “available” as in “on line” for use at all times in flight, for incoming and outgoing ACARS (if it was selected) and Sat-calls. He did not need to know “the specifics” of the underlying network bearer functions, just like the rest of us don’t need to know “the specifics” of how our mobile phones stay logged on and “available” as we move about and our phones get switched from tower to tower. All we need to know, and all “he” needed to know, was that our coms system is “available” or “no service”.

Now, the receipt of the first phone call (unanswered), almost immediately after bus power up, told him (if Z was still alive and did it deliberately) “with certainty” that SATCOM “was available * now*“, irrespective of whether or not he had previously intended that it was shut down deliberately by disabling the power bus.

If we assume that Z had intended that SATCOM “remain disabled”, and now knowing that it was active again, and presumably being “unable to disable it again”, because he needed the re-powered configuration for some other reason, it is reasonable to assume that this “issue” might have forced Z to “modify” (on the fly) whatever his original plan was. That introduces the possibility of Z deciding on deliberate course changes from his original plan, sort of like a ship zig-zaging down a baseline course, in an attempt to thwart torpedo attacks. ArthurC has a valid point.

]]>The ‘pings’, specifically the Log On Interrogation between the SATCOM Ground Earth Station (GES) & the AES, are *not* part of the ACARS protocol.

The Log On Interrogation is a SATCOM datalink function, it is inappropriate to term that a “*secondary*” function. ACARS is a communications service that is carried across the SATCOM datalink. No ACARS traffic tranversed the SATCOM datalink after the diversion at 17:21UTC.

It is highly unlikely that a pilot, even if familiar with ACARS, would be familiar with the low level functions of the SATCOM datalink protocol, including that the Log On Interrogation occurred after the SATCOM datalink was idle for 60 minutes.

]]>I was trying to be ambiguous so as to not perpetrate theories, but I had a specific scenario in mind when I asked the question.

Would a pilot be aware of the ACARS pings? From what I read, pings are a “secondary” function, so if the system is off or logged off, could the pilot still be aware of the pings?

Aware of their timing also, possibly maneuvering the aircraft in between those pings. (that’s the theory…)

Is it possible for the pilot so see/monitor ACARS activity, like logons?

]]>@Barry Carlson

@Peter Norton

RE: *“The FAA has made a new statement regarding the 737 Max problem…”*

Aviation Week reported:

*The issue came to light within the last week during tests in Boeing’s MAX engineering flight simulator, or e-cab, a source with knowledge of the situation confirmed. The pilots were simulating a runaway stabilizer scenario and running through the requisite emergency-response checklist. A key early step is to use control column-mounted electric-trim switches to command horizontal stabilizer movement to counter the runaway. A subsequent step, if needed, is to toggle cutout switches that disable the trim motors.*

According to the source, the FAA pilots found response to the electric-trim inputs took too long. “They had a difficult time quickly resolving the situation,” the source explained.

*The issue has been traced to how quickly a specific flight control computer chip is processing data, the source said. What is not clear: whether the chip itself needs to be changed, or if a software update will address the issue. A second industry source said that a software fix is possible—and certainly would be preferable for Boeing, which suggested in a statement that a software modification will be sufficient. Changing chips could further delay the MAX’s return to service, as it would likely require new chip architecture as well as changing chips on nearly more than 500 MAXs in airline fleets or ready to be delivered.*

http://www.usatoday.com/story/news/nation/2019/06/26/boeing-737-max-new-potential-risk-could-delay-jets-return-skies/1577597001/

After so much Boeing testing, the discovery of new flaws that Boeing missed isn’t really confidence-inspiring.

“Long before the Max disasters, Boeing had a history of failing to fix safety problems”

https://beta.washingtonpost.com/local/trafficandcommuting/long-before-the-max-disasters-boeing-had-a-history-of-failing-to-fix-safety-problems/2019/06/26/b4f5f720-86ee-11e9-a870-b9c411dc4312_story.html

I agree. This article demonstrates the craziness that is now dominating Malaysian politics. It is very unlikely that MH370 is on the radar.

]]>https://twitter.com/FAANews/status/1143985330951008257

**#FAA Statement on the @Boeing #737Max.**

“The Federal Aviation Administration (FAA) is following a thorough process, not a prescribed timeline, for returning the Boeing 737 Max to passenger service. The FAA will lift the aircraft’s prohibition order when we deem it is safe to do so. We continue to evaluate Boeing’s software modification to the MCAS and are still developing necessary training requirements. We also are responding to recommendations received from the Technical Advisory Board. The TAB is an independent review panel we have asked to review our work regarding 737 Max return to service. On the most recent issue, the FAA’s process is designed to discover and highlight potential risks. The FAA recently found a potential risk that Boeing must mitigate.

1:52 PM – 26 Jun 2019”

———————

Note; there is nothing specific re the *potential new risk*.

I’ll let others weigh in on your intuition, but I am not signing up for it.

]]>re coriolis pseudoforce

My intuition says that that as an inertial force it simply could not be felt at all.

]]>It is not simple to hand someone a piece of code written for personal use. There is no manual, no instructions, various nuances,…

Turning a piece of working code into something usable by a third party takes more work than actually writing the code. Even using code I have previously written takes me awhile to remember how to actually use it if I have not done so for a couple months or so.

]]>So I’m not able to analyse a few million flight paths even for my own personal interest? I would very much like to concentrate the minds of those who believe there were many turns after the final turn and without access to this model I am unable to do so. Begging mode engaged.

]]>re: coriolis force sensing by MEMS

I don’t know. My intuition says it would be lost in the noise.

]]>Would there be any Inmarsat data for this flight (or something similar) from March 2014?

And if there is, could it be used to analyze and possibly validate the values for MH370?

Not sure if it adds any value, though…

]]>Thank you for your analysis of the BEBIM to NZPG path. I agree end of flight becomes a question. Is it possible to explain somehow: (1) that the fuel was lower than we think, or (2) alternatively the fuel was OK but somehow Arc7 happened when there was still some fuel to spare for more distance? or (3) there was another heading change, eg due to 2314 telcon.

Right now that is my personal proposal, MH370 hopped onto the actual home simulator flight path at about BEBIM.

]]>Thanks for your insight into IRU error over an 8 hours flight without GPS aiding.

I would appreciate your view on whether the coriolis pseudoforce would get felt at all by say, a MEMS accelerometer?

]]>Re: *The Seattle Times* article.

The legal eagles at Boeing will be under a fair bit of pressure, and the lid hasn’t yet been put on the pot.

The rather duplicitous actions described in the article permeating throughout the design, engineering, testing, certification and managerial levels of the organization; seemingly at the behest of the executive, can only be described as “chilling”.

And the excuse; not to let Airbus gain the lead in the short / medium haul market.

]]>The inside story of MCAS: How Boeing’s 737 MAX system gained power and lost safeguards ]]>

Mahathir raised the possibility of a remote take over shortly after MH370 disappeared, when he also accused the CIA of withholding information:

CIA withholding information on flight MH370, says former Malaysian PM Mahathir Mohamad

Many years ago, the former Australian prime minister, Paul Keating, labeled Mahathir Mohamad as a ‘recalcitrant’ and he is well known for his antipathy towards Western countries. For example, it was reported in *The Australian* that Mahathir once *speculated that the 9/11 events were staged by the US “as an excuse to mount attacks on the Muslim world”*:

CIA ‘role’ alleged in plane mystery

This comes on the heels of his claim that there is no proof that Russia downed MH17.

]]>I echo Richard’s sentiments. Thank you for your offer, but I believe our combined ROI search efforts over the past several years are adequate.

@TBill,

@DennisW,

Regarding “But I am having trouble seeing how active flight paths might not be (a) better fit”, I will say that, from a statistical point of view, no active route can be SUPERIOR to the LNAV 180 route through BEDAX.

It’s easy to create maneuvers during “active” routes which result in smaller BTO and BFO residuals, but that does not mean they are more likely. In fact, the smaller the residuals are than their expected values, the LESS likely is the route.

The LNAV 180 BEDAX route appears to be the only passive route which is fully consistent with statistical expectations. One can create active routes which are EQUALLY likely, but not significantly MORE likely.

@David,

You asked: “Do we know the accuracy boundaries for wind, temperature and density altitude data on the different routes, particularly in the remote regions?”

The simple answer is, not as well as we would like to know them.

Richard has compared a limited set of temperature and wind measurements made by 9M-MRO during MH371 with GDAS data. This will be reported in our next paper. Roughly, the temperature differences were about 1-2 C and the wind differences were about a knot in speed and several degrees in direction. I note that this latter result is superior to the expected GDAS global wind errors. It indicates that with our 4-D GDAS route models, we can predict the ground speed with systematic errors in the range of 1 to several knots, and this is most useful in discriminating routes. It is an integral part of my new route fitting method, because synthesizing small ground speed errors for each leg (mostly caused by GDAS errors), is the only way to segregate the systematic route errors from the random BTO reading errors using the MH370 data set.

]]>There are four varieties of statistical analyses which I employ in my new method of MH370 route fitting.

To review, a list of the statistics I use is:

1. Mean BTOR (mu_s = 0, sigma_s = 12.97 microsec, 5 samples)

2. STDEV BTOR (mu_s = 27.30, sigma_s = 9.90 microsec, 5 samples)

3. STDEV BFOR (mu_s = 3.90, sigma_s = 1.73 Hz, 5 samples)

4. Pearson’s correlation coefficient r for Leg Start BTOR to Leg End BTOR (mu_s = -0.237, sigma_s = 0.447, 4 sample pairs)

5. r for Leg Start BFOR to Leg End BFOR (mu_s = -0.237, sigma_s = 0.447, 4 sample pairs)

6. r for BTOR to BFOR (mu_s = 0, sigma_s = 0.50, 5 sample pairs)

7. r for BTOR to Time (mu_s = 0, sigma_s = 0.50, 5 sample pairs)

8. r for BFOR to Time (mu_s = 0, sigma_s = 0.50, 5 sample pairs)

9. r for BTOR to Along-Track Position Error (mu_s = 0, sigma_s = 0.50, 5 sample pairs)

10. PDA (mu_s = +1.5% or -0.8%, whichever is closer, sigma_s = 0.67%, 1 sample)

11. r for BTOR to Cross-Track Position Error (mu_s = 0, sigma_s = 0.50, 5 sample pairs)

12. r for Along-Track Position Error to Cross-Track Position Error (mu_s = 0, sigma_s = 0.50, 5 sample pairs)

In this list, I use the subscript “s” to denote “sample” statistical values, as opposed to “population” values. The sample standard deviations are smaller than the population standard deviations. Generally speaking, there are 5 samples (and in two cases of autocorrelation there are 4 pairs of samples). I denote the expected values by “mu” and the standard deviations by “sigma”. BTOR is BTO residual. BFOR is BFO residual.

1. The first category of statistics used in my new MH370 route fitter is the simplest. It applies to normal random variables, such as the Mean BTOR (my statistic #1 in the list above) and STDEV BTOR (#2). In this case we know that for the True Route the mu_BTOR = 0 and the population sigma is 29 microseconds. The expected value of the calculated sample mean BTOR (with N = 5) is zero, and 100,000 random trial sets of BTORs gave a mean of -0.07 microseconds. The sample standard deviation of the mean BTOR with 5 samples is expected to be 29/SQRT(5) = 12.97 microseconds. The 100,000 trial sets gave an average (sample mean) standard deviation value of 12.98 microseconds. So, the trials match the expected statistical values very closely for the BTORs.

The sample BTOR standard deviation is less than the population standard deviation of 29 microseconds, because of the limited number of samples. 100.000 trial sets had an average value of 27.30 Hz. The observed standard deviation of the sample BTOR standard deviation was expected to be 29*SQRT(1-9*PI()/32) = 9.90 microseconds, and the 100,000 trials gave an average of 9.90 microseconds.

So, the mean and standard deviation BTOR statistics appear to behave as expected.

In this category we simply find the Z transformation statistic as:

Z = ( Value – average sample mean) / sample standard deviation

and we find the percentile P (in EXCEL) from:

P = 2*NORM.S.DIST(-ABS(Z),1)

where the factor of 2 is needed because of the cumulative single-tailed normal distribution function used in EXCEL. We must use the absolute value of Z because we don’t know its sign. Here P is the percentile of random trials which are worse than the current fit, assuming the route is True.

I also treat the Performance Degradation Allowance (PDA, #10 in the list above) as a normal random variable and use the same analysis method. Recall that the PDA is determined by adjusting it so that Main Engines Fuel Exhaustion is predicted to occur at 00:17:30 UTC. The PDA is not a random variable in the strictest sense, but it has the same characteristics of interest in this problem. The expected value of the PDA is nominally the MH370 Flight Plan value of 1.50% (average of both engines in cruise). However, because we cannot rule out the possibility that the air packs were turned off at Diversion, the effective value could be much less averaged over the remainder of the flight. The impact of the air packs being off is about 2.3% in fuel savings, or an equivalent PDA of -0.8%. So, to allow for this possibility, I allow the PDA expected value to be either +1.5% or -0.8%, whichever is closer to the best-fit value. The uncertainty in the PDA is caused by the errors in the fuel consumption model. Based on comparisons with previous flights and with Boeing fuel flow tables, I have previously estimated that uncertainty to be 2.0% at the 3-sigma level. Thus one sigma is 0.67% in PDA. Treating the PDA in this fashion allows me to estimate a probability that the route being fitted matches the expected PDA. It also allows me to incorporate PDA as one of numerous statistics being evaluated to produce a single overall figure of merit for the fitted route. The PDA percentile is calculated as described above for the BTOR statistics using the Z transformation and the normal distribution.

2. A second category of statistical analysis is the STDEV BFOR (#3 in my list above).

I use an empirical method to match the DSTG’s empirical density function of the BFO reading errors. This involves generating normal random values having a zero mean and a population standard deviation that itself is a uniform random variable from 1 to 7 Hz. The average value of 100,000 trial sets of 5 BFORs was 0.004 Hz and the average population standard deviation was 4.35 Hz. This is in agreement with the DSTG estimate for BFO reading errors with outliers excluded. To find the percentile value, I find the Z transformation as follows:

Z = (value – average sample BFOR standard deviation ) / standard deviation of sample BFOR standard deviation

The average value of the sample BFOR standard deviation was empirically found to be 3.90 Hz using 100,000 trial sets of BFORs. This is in agreement with the theoretical value of 4.35*SQRT[ (5-1) / 5 ] = 3.89 Hz. The second factor in this equation is the reduction in the population standard deviation to the sample standard deviation. When we have a limited number of samples, there is a bias to a lower expected value than the population sigma. The standard deviation of the sample BFOR standard deviation was found to be 1.73 Hz. Then, using the equation above, I find Z and then the percentile P.

Using this method, the RMS errors in the percentiles from 1%-99% is low, being only 0.7%. Thus, my statistical model for the BFO standard deviation is accurate over the range of percentile values of interest.

3. The next two classes of analyses deal with correlation coefficients – those with zero expected value and those with a non-zero expected value.

Recall that the Pearson correlation coefficient r is given by:

r = S_xy / (S_x * S_y) = [SUM(xy)/N] / SQRT{ [SUM(x^2)/N]*[SUM(y^2)/N] }.

When the expected value of r is zero, the correlation coefficients are analyzed statistically using Student’s distribution, employing the t transformation:

t = r*SQRT[(N-2)/(1-r^2)],

where N = 5 pairs. The number of degrees of freedom is thus N – 2 = 3. Now “t” is approximately normally distributed, and the percentiles are found using the two-tailed cumulative Student’s distribution with 3 degrees of freedom. In EXCEL, this is:

P = T.DIST.2T[ABS(t),3].

Note the absolute value of t is used, since we don’t know the expected sign of t, and we must allow for both the positive and negative tails.

Using 600,000 sets of 5 pairs of uncorrelated random values, I get an expected value of -0.0009 (i.e., zero) and a standard deviation of 0.5005 (i.e., 50%) for r. The standard deviation is high because both variables are random and the number of pairs is small. For 600,000 trials of t, I get an expected value of 0.004 and a standard deviation of 1.723. The observed percentiles match the expected fractional percentages within 0.15% RMS for percentiles from 1% to 99%, so the statistical model is actually quite accurate. This method of analysis applies to those correlation coefficients which have an expected value of zero, which are # 6-9, 11, & 12 from the list above.

4. For the two autocorrelation cases of BTOR w.r.t. BTOR and BFOR w.r.t. BFOR, N = 4 (pairs) and the expected value is not zero. This applies to the statistics #4 and 5 in my list above. Using 200,000 random trials for this case, the expected value of r was mu_r = -0.237 (i.e., -23.7%) and the standard deviation was sigma_r = 0.446 (i.e., 44.6%).

Fisher’s F transformation is used in this case to obtain an approximately symmetric normal distribution from the asymmetric r distribution:

F = (1/2)*ln[(1+r)/(1-r)] = arctanh(r).

Due to the nonlinear transformation, the mean of F is slightly different than the mean of r (mu_F = -0.311).

Next we find the normalized Z-score:

Z = [F – mu_F] / sigma_r.

Note that in the equation above for Z above I use sigma_r, not sigma_F, because I found this substantially improved the accuracy of the predicted percentiles. The percentile is then found from the Z statistic using the two-tailed cumulative Student’s distribution (the same as in the zero-mean case above):

P = T.DIST.2T[ABS(Z),3].

The number of degrees of freedom in this case is N – 1 = 3 with N = 4 pairs of variables. The observed percentiles using 200,000 trials matched the expected percentages within 0.7% RMS from 1%-99%. The predicted percentiles with non-zero mean r are not quite as accurate as the zero-mean r case because the r distribution is asymmetric. Two transformations (F and Z) are needed to obtain an approximately symmetric distribution with the correct shape to match a standard distribution (like normal, chi squared, or Student’s). Still, the accuracy is more than adequate for the problem at hand.

Combined Percentile

Once the P-values for all 12 statistics (10 in the case of LNAV) are calculated, the last step is to combine them into a single percentile estimate. Fisher’s method of combining percentiles first finds chi squared:

X^2 = -2*SUM[ ln(P_i) ]

The number of degrees of freedom which is compared to chi squared is twice the number of statistics (2N = 2*10 or 2*12 depending on the lateral navigation method). Finally, the combined percentile is found using the chi-squared distribution. In EXCEL:

P = 1 – CHISQ.DIST(X^2, 2N, 1).

Again, the (combined) P-value is the percentage of random trials, assuming the route is True, that would be expected to fit the data worse than the current route. One can think of the P-value as being the probability that the route is True, and ratios of P-value therefore represent relative probabilities that the route is True.. The combined percentile is used in my objective function and is maximized by my route fitter. The expected value for the combined percentile is 50% for the True route. Half the trials would fit worse, and half would fit better. A combined P-value above 50% can occur half the time. If a fit has a P-value well above 50%, that implies either that (a) an additional degree of freedom in the route model (beyond the seven minimally required) is being fitted (thereby artificially reducing the residuals), and/or (b) the MH370 Inmarsat data have somewhat smaller-than-average scatter. To test this situation, I have embedded a means to inject random BTO and BFO reading errors into my route fitting program. When I do that for a fairly large number of trials using the one best-fit route (LNAV 180 through BEDAX), the average combined P-value is close to 50%. From this result I conclude that the excess in best-fit combined P-value (it is close to 80%) for that one route using the actual MH370 data is more likely to be caused by the actual MH370 data set than by over-fitting the route.

]]>Modern inertial reference systems are good for about 30nm of error over an 8 hours flight without GPS aiding. A 30nm position error would have a negligible effect on Doppler compensation.

]]>@TBill stated “Nederland and I both feel there seems to be a possible nominal “low and slow” 400 knot path from Arc4 (near BEBIM) to NZPG.” and “Admittedly I and Nederland would welcome further IG review of that proposal.”

In your linked paper, you state “it appears that MH370 could have instead flown due south, perhaps from BEDAX to BEBIM, in effect taking a shortcut down to the flight sim pathway” and “working backwards from Arc7 suggests waypoint BEBIM might have been the focal point for the pilot to change heading to fly towards McMurdo Station (NZPG), assuming an approximate 400 knot ground speed.”

You describe the test flight conditions that you applied:

Atmosphere: Set to 80 deg F at Sea Level

Winds: 0

Altitude: FL250 = approx. 25,000-ft

Heading: 168 deg South (True)

Ground Speed: 400 knots

True Air Speed: 400 knots = Mach 0.65

Indicated Air Speed: 275 knots

Flight Path: ISBIX to BEBIM to 78S67 (NZPG)

(1) BEDAX is at longitude 93.787575°E, ISBIX is at longitude 93.675108°E and BEBIM is at longitude 93.835000°E, so this route is not quite due south. I took waypoint BEBIM for the turn to NZPG, which I estimate was reached at 21:26:45 UTC.

(2) NZPG is at -77.963333°S 166.524444°E, which is close to your 78S67 waypoint. The initial bearing from BEBIM to NZPG is 168.12019548°T (Vicenty).

(3) FL250 at your surface temperature of 80°F (26.7°C) and a surface pressure of 1012 mB gives an air pressure at FL250 of 376.0041 hPa and a geometric altitude of 25,986 feet.

(4) I applied your Mach 0.65, but included the effect of air temperature and winds at FL250. In order to reach your latitude of 28.911°S at 00:11:00 UTC precisely, I slightly reduced the Mach after waypoint BEBIM to 0.642856.

The BTO and BFO results are excellent. My only concern is the high PDA at 00:17:30 UTC of 3.861% (nominal 1.5%), which represents around 1,470 kg fuel remaining at MEFE.

Here is a link to a detailed flight path report:

]]>Does the coriolis pseudo force get felt by say a micro mechanical accelerometer?

In the case of MH370 the GPS apparently corrects the IRU with notional accelerations.

However if the GPS were somehow disabled by the pilot and if the IRU actually did drift then the pre-comp calculation could be off.

]]>I look forward to your (collective) forthcoming paper that describes your method for generating and evaluating each path versus the particle filter Monte Carlo approach taken by BSTG as described in their book.

It seems that you select an exact navigation model and setup with maybe random winds aloft and then evaluate that profile using the arc crossing data to assign a probability for that model.

I had issues with the dynamic model used by DSTG to generate the “infinite” flight paths. Although I assume their PDF for the “infinite” flight paths may bear some relationship to the more likely explicitly programmed paths in your set of cases.

@DennisW noted “An active flight path can always be created that is a better fit. That is not the point of the exercise.”

“I still wonder whether one simple profile could exist where an active pilot could have flown to fuel exhaustion north of 25 S on arc 7 and “perfectly” met the arc crossing data constraints. Maybe it is not remotely possible?

]]>Thank you for your kind offer, but what you are suggesting has already been done. Bobby, Victor and I have performed a systematic study during the last 4 months of all possible flight paths and are soon to publish the results.

In total 1,372 flight paths have been analysed, of which 828 flight paths since the start of this systematic study on 17th February 2019. Start latitudes from 16.0°N to 4.3°S have been covered and the start longitudes were unconstrained. Start times from 18:41:00 UTC to 19:32:00 UTC, but the final major turn had to be completed before the 2nd Arc at 19:41:03 UTC was reached.

Systematic initial bearings from 155°T to 195°T in steps of 1°T were analysed, plus some exotic cases in steps of 0.1°T. All navigation methods were : LNAV, CTT, CTH, CMT and CMH, all speed modes: Constant Mach 0.80 to 0.85, LRC 0.7047 to 0.8408, MRC, ECON CI52 and all flight levels: from FL290 to FL430. The fuel endurance was allowed to vary around 00:17:30 UTC and the resulting PDA was noted. The PDA was allowed to vary from the nominal 1.5% and the possibility that the bleed air was shut off for part or all of the time was considered.

You may have seen in the comments above, that I have in addition run a number of candidate flight paths from @TBill, @Niels and @Hank.

]]>@TBill stated “@Richard Nederland and I both feel there seems to be a possible nominal “low and slow” 400 knot path from Arc4 (near BEBIM) to NZPG.” and “Admittedly I and Nederland would welcome further IG review of that proposal.”

@Niels stated “@Richard I have optimized “case C”. It has a much straighter track after 21:11 (more than ten times smaller variance) compared to “case A” and “Could you perhaps help to evaluate the proposed route (21:11:02 onwards)?”

I have noted both requests and will get to running the flight paths suggested through my model in the coming week.

I am very busy at the moment, helping to prepare the next paper that Bobby, Victor and I will publish here soon, describing the wide area scan of the Southern Indian Ocean.

]]>@DennisW

@Victor Ianello

@Richard

I have effectively limitless computing capacity at my disposure for about three months. I just want to throw this model at everything that, no matter how unlikely, could potentially have happened and rule out 99.99% of the ridiculous flight paths and EOF locations. Please, let’s just get it done?

]]>