By Oleksandr N.
[Note: Oleksandr originally posted a link to this intriguing paper in the comments section, where it has generated a considerable amount of discussion. Oleksandr has developed one of the most intriguing hypotheses about the Inmarsat data to emerge in a long time. In a nutshell, he suggests that data that has long been viewed as spurious might in fact be an important clue as to what the plane was doing during two crucial and as-yet poorly understood periods of its final flight. — JW]
Introduction
There are two obviously abnormal BFO values of 273 Hz (18:25:34.461 UTC) and -2 Hz (00:19:37.443 UTC) recorded by Inmarsat. The first of them is inconsistent with the other BFO records in the same cluster of BFOs 18:25 – 18:27, and it is also inconsistent with the known heading and speed of the aircraft by 18:22.
The second abnormal BFO value of -2 Hz considerably differs from the BFO value of 182 Hz just 8 seconds earlier. Should this value be correct, it would imply an extreme descent rate (~15,000 ft /min).
While attempts took place to explain the BFO of 273 Hz as a result of some maneuver, such as a lateral offset, the second anomalous value of -2 Hz is widely believed to be erroneous.
This technical note provides an alternative view, suggesting that both the anomalous BTO values are valid, but they are the results of the inability of AES to apply Doppler compensation due to missing position/velocity data.
You can find the whole paper here.
airlandseaman:
1. Re: “The purpose of the AES Doppler compensation is to reduce the total carrier frequency offset at the satellite L band receive antenna to less than 200 Hz (see Rockwell patend), not 1kHz.”
I would bet the purpose is to reduce BFO to zero… But the largest “normal” BFO is 252 Hz in this case, all the 27 BFOs from the cluster 23:13:58-23:15:02 exceed 200 Hz, and the value of BFO 22:41:21 is 204 Hz. So, what the figure of 200 Hz is:
– Certification limit;
– Threshold limit, beyond which transaction can’t go through;
– Recommended limit.
2. Re “The AES will not transmit if it does not have valid NAV data on the 429 bus. See MCS7200 manual.”
Does it check validity of NAV data for each transaction?
3. Re: “There is no evidence that the AES Doppler compensation was not working normally for the entire flight.”
Is there any evidence of the opposite (after 17:22)?
4. Re “Unusually large and small values are more rationally explained by vertical speed…”
This rational explanation implies the coincidence with “Log-on acknowledge” events in the two of three cases. On top of it, I would like to remind that one of the essential assumptions for the AP trajectory is constant or nearly constant flight level. How 18:25 BFO of 273 Hz is consistent with it?
5. Re: “A high descent rate 4 minutes after fuel exhaustion is not only possible, it should be expected based on the evidence, experimental data and historical data for similar accidents.”
I did not say it is impossible. Anyhow, where are the life jackets?
6: Re “the most logical conclusion is that the plane went down close to the 7th arc, probably near S38.”
7th arc – agree. But where does it come from that S38? It requires a batch of assumptions, not even talking about the AP. And nothing is found there as far as I know.
7. Re: “The notions that BFO and BTO errors could have a “common reason” is inconsistent with the AES and CU designs. These observations have completely independent error sources and the measurements are performed by independent means. Thus, there is no connection whatsoever between BTO and BFO errors, bias, accuracy, etc.”
Big wow! So, we have two samples of abnormal BFOs in the set of N records, and two samples of abnormal BTOs in the set of M records. Assuming BFO and BTO are independent, as you say, what is the probability that the two abnormal BFOs pair with the two abnormal BTOs? I even don’t want to do cals…
sinux
Re: “I’m just trying to find alternate possibilities that would explain those oddities plus explain why :
– first BFO after powerup is closer to average of stabilised BFOs than subsequent ones.”
Thanks. Sure thing, there could and should be other explanations. We need to keep open mind. IG, for example, suggested discarding 273 Hz as unreliable (i.e. random) and take -2 Hz as the indication of a spiral dive. Although possible, I think it would be extremely unlikely.
@Oleksandr
I believe the 200Hz number is part of an error budget allocated to uncompensated aircraft Doppler. Not the total value of the BFO.
@StevanG
The current SIO search strategy is taking on the semblance of a conspiracy theory. To wit:
“Conspiracy theories and scientific theories attempt to explain the world around us. Both apply a filter of logic to the complexity of the universe, thereby transforming randomness into reason. Yet these two theoretical breeds differ in important ways. Scientific theories, by definition, must be falsifiable. That is, they must make reliable predictions about the world; and if those predictions turn out to be incorrect, the theory can be declared false. Conspiracy theories, on the other hand, are tough to disprove. Their proponents can make the theories increasingly elaborate to accommodate new observations.” – Scientific American 8 August 2013
The zombie hypothesis can never be falsified. The plane might always be just outside the search area no matter how much the search area is expanded. What could possibly constitute a “falsified” conclusion? I don’t expect an answer to that question by the SSWG or IG people.
There is enough intellectual and personal skin in the game that I am convinced the search will end there with negative results.
Oddly, there is not a shred of evidence (or even a vague notion of motive or causality) to suggest that the plane terminated in that location. All we have are some highly ambiguous BFO values and Occam’s Razor to point to that the location on the 7th arc (the 7th arc is golden, IMO).
Dennis – I had this whinge ages ago too – some people do not intend to let that go ever. If we are now pointing to some skinny gaps between the sweeps as the resting place of the plane I’d say the wheels are coming off.
Oleksandr – any means where BFO and BTO can be swayed together reopens the spoofing door?? Looks like we have a flaperon but we don’t have a crash site or any acoustic signature from an impact that turned a few hundred tonnes of 777 into “confetti” in less than a second. Or was it more like discreet plane disposal?
Kudos anyway for persisting when I thought there was nothing more to glean.
@Matty
Actually, we do have an obscure CI collaborating analysis. It never received widespread publication. I will be the first to admit that it seems weak. I have attempted to contact the author without a response.
http://mh370corner.blogspot.com/2015/07/coincidences-are-you-believer.html
@airlandseaman
“There is only one OCXO in the system, and it is mounted in the rear of the airplane on the l3eft side, above and behind the wing exit. Normally, the area is at near +23C and 0-7000 ft altitude.”
Then we have three possible scenarios :
1. Temperature dropped due to x (power failure, etc…) which led to instability of OCXO at startup. It is difficult to model the temperature transients (are you sure we couldn’t at least try something even with some assumptions see where it leads?) which means we can’t extract altitude changes from BFO!
2. Temperature didn’t drop and there was no other problems in the system. The BFO changes are only due to altitude changes. Which means the flight wasn’t on autopilot!
3. Temperature didn’t drop but there is an as of now unexplained reason that causes BFO instability.
Or am I missing something?
@Lauren H
“the BFO of the test flights are less accurate in predicting location as the planes approached the longitude of the satellite”
It’s the first time I hear about this reason…
I’m not sure it makes sense though. Anybody with deeper knowledge of BFO could comment?
@Oleksandr
“Does it check validity of NAV data for each transaction?”
Excellent question, I was wondering something similar :
How often does the SDU compute deltaFcomp?
For each transaction seems the safest but it would use a lot of processing power.
Less than that and the risk of having big BFOs increase…
It could be somewhere in the middle 😉
The unpiloted, straight path to the SIO was a theory based on a number of assumptions. Some of us have stated all along that theories can only be subjectively ranked based on the subjective strength of the evidence and other factors. And some of us have said that as more area is searched, the probability of this theory being correct progressively decreases. Obviously, within the IG, there is a range of confidence levels that members place in this theory.
My opinion is that if the search is completed north to 33S latitude, and to 17 nm within the arc, and without success, the probability of ever finding the aircraft in the SIO becomes very unlikely. Already, the probability is low.
I have been a strong advocate of exploring other theories, be it different interpretations of the satellite data, different operational modes of the aircraft, or different motivational factors for the incident. It is not necessary to ridicule the IG in order to propose something different. And it is not necessary to persuade everybody here of the “absolute truth” of a particular theory in order for it to be worth considering.
I have yet to see a theory proposed that does not have serious shortcomings. My guess is that this incident involves multiple levels of deception, either during or after the incident, that makes it hard to reconstruct after the fact. Yet we should continue to try because the official investigation to date has produced nothing.
@Sinux
“How often does the SDU compute deltaFcomp?”
A companion question is how often are the navigation parameters updated by the aircraft sensors. Navigation data is computed using various update rates. For example, inexpensive GPS receivers typically update at a once per second rate. This rate would lead to substantial errors during an aircraft turn depending on when the data is used relative to when the data was computed. Of course, it may be that the AES waits for a sensor update prior to computing deltaFcomp. I really don’t know that level of detail.
Relative to your question, my guess would be that deltaFcomp would be computed just prior to an AES transmission. However, that says nothing about how current the parameters used for that calculation might be.
I tried to quantify the magnitude of the potential error here:
http://mh370corner.blogspot.com/2015/04/bfo-errors-again.html
@Victor
No one is ridiculing the IG. The work done by that group has served as template for virtually all the analytics associated with the flight path of 9M-MRO. That does not mean that the IG, or anyone else, is above criticism.
I have had two primary issues with the SSWG and IG analytics from the get-go.
1) show me the test data
There are hundreds of daily flights using the ISAT system. Apart from some graphics in an ATSB report, I have never seen any attempt to quantify the accuracy that might be expected from this data. I find this very unsettling. Having an ensemble of representative flight BTO/BFO data sets and the companion ACARS data would at least allow us to have an idea of what is reasonable to expect. As it is we are performing calculations that have no sanity check.
2) flight path assumptions
No need to amplify this issue. It has been beaten to death.
It is for the above reasons, that I have misgivings about the pins the IG has stuck in a map. I don’t have a clue relative to a confidence level. My own approach is to regard the ISAT as a qualifier, not a predictor. We don’t have anything to support what the predictive usefulness is.
@DennisW: Yes, we all want more data so we can compare actual and predicted paths and understand discrepancies. Everybody here is in agreement.
Regarding flight path assumptions, there is little need to argue whether or not the IG’s assumptions were justified. Either the plane will be found along the arc in the current search area or it won’t. It’s looking like it won’t. We’ll see.
Regarding a crash close to Christmas Island, in my mind that scenario has its own set of problems which I have stated. You feel differently. Vive la difference. I hope you continue to develop your theory as more facts surface because you may be right.
@sinux
I made a stupid statement above. The AES cannot wait for a current sensor update before calculating deltaFcomp. If that were the case, the BTO values would be severely compromised. The AES responds with a relatively fixed latency so the sensor data latency is whatever it is.
Regarding update rates, Table A-10 of the MCS7200 manual gives “ARINC 429 Data Requirements”. Orientation parameters (track, heading, pitch, roll) require updates rates no slower than 40-55 msec per update (depending on parameter). Presumably this is to keep the antenna pointed during a turn. One presumes that if the navigation data are interrupted, the AES will know about it right away. Given the way that the SATCOM protocol is written and the way that the MCS7200 operation is described, one gets the impression that if the AES cannot guarantee that its transmissions will be within spec, it will not transmit.
@SK999
Good information. That update rate could result in BFO errors on the order of a Hz or so for a rate one turn (3 degrees per second) – in the domain of negligible.
http://www.ibtimes.com/flight-mh370-update-malaysia-proposes-tripartite-meeting-discuss-next-step-search-2128403
4th paragraph??? The 1st 3 are the same propaganda released Monday
@Victor: thank you for sticking your neck out, and quoting a northern terminus and “distance from arc” you feel would falsify the working assumptions which drove the priority search area’s formation. Quick questions:
1. Do you have a southern terminus that differs from the area already searched?
2. Whence springs 17nmi?
@Brock McEwen: I am not sticking my neck out. The facts will fall where they may. I never said I was certain the aircraft was in the SIO on the 7th arc. Rather, I believed at the time that was the best place to start the search based on a series of assumptions which seemed reasonable and produced a search area that was achievable.
The 33S latitude is simply based on the area that was surveyed and the 17 nm within the arc corresponds to my estimate of what has been searched to the south, using Richard Cole’s maps as a reference.
I don’t think it is likely the aircraft is resting further south along the arc than what was already searched as the flaperon would not have drifted to La Reunion.
Susie – the story makes little sense. A way forward? More like a way out. I thought it was already telegraphed that outside the current area there was no plan?
@Oleksandr: If BTO and BFO errors were independently and randomly distributed among the N records, Pr(2 BTO & 2 BFO anomalies would be contained to the same 2 records) is 1 in “N choose 2”, or 1 in N!/[2!(N-2)!] = 1 in N(N-1)/2.
If N=10, Pr(alignment) = 1 in 45.
If N=100, Pr(alignment) = 1 in 4,950.
I’ve never counted the records, and don’t plan to.
(For the record: burying our heads in MATHgeek minutiae: perfectly acceptable.)
Impressive paper, by the way. It has generated interesting discussion. I just want our attempt to band together to force fuller disclosure (which Victor’s radar questions have invigourated) to proceed concurrent with – not subsequent to – all further attempts to wring the last drops of information out of sparse (and dubious) data.
How does the BEA, and whatever brigade of acronyms, escape mass scrutiny for their stifled flaperon report?
They assumed responsibility for the ONLY piece of physical evidence from the ONLY time in world history that a plane full of hundreds of people vanished, still
without explanation of where or why after 19 months.
If people started threatening to boycott the airlines, demanding continuity and transparency perhaps this would expedite the process.
Right now, there is no reason to assume this could not happen anywhere, anytime, any place with any airline and THAT should be very alarming to people
@Matty – Perth
If this meeting took place in Beijing last week with significant involvement from major players, why didn’t anyone report it? To me it feels like the normal Malaysia smoke and mirrors reporting erred this time by being untruthful rather than opaque
@Matty – Perth
Know anyone in Sydney, it might be interesting
https://www.pacific2015.com.au/associated-conferences/IndPac-2015.asp
Susie – they(French) are under absolutely no pressure. I tell you it’s been a charade for a long time. China has considerable muscle but is apparently using none of it. They just send someone along to a meeting that really means bugger all. This is why my mind wanders all the time and I get called a conspiricist. But it isn’t right, and I never really believed the Chinese govt gave much of a crap. They were just avoiding a domestic image problem.
Yes well, it’s getting to the point if one is not a “conspiracist” then one is an idiot. I use to occasionally throw that label on others with condescension but with this, you begin to lose perspective of normal protocol until you realize this is nowhere close. You have been a trooper Matty and there from the beginning so it’s okay to let your mind wander now and then
My mind wandering again. Scary but inevitable – why terrorists would want a 777. And what about that cargo?
http://www.watoday.com.au/world/nuclear-smugglers-shopping-arsenal-around-to-terrorists-20151007-gk34jd.html
@Susie & Matty
“IndPac 2015 – The Mystery Flight: Reviewing the Search and Recovery Operation for Flight MH370”
Curtin Uni, Perth, 8th Oct.
@all
while I appreciate your effort in analysing BFO data the thing is that data is very limited/unreliable and we simply have to introduce another variable otherwise it’s just chasing own tail
In essence, that is precisely what Oleksandr’s hypothesis is attempting to do for the end-of-flight scenario.
@StevanG: If we ignore the BFO data to avoid “chasing [our] own tail” and rely only on the BTO data, then the satellite data would shown no preference for southern paths over northern paths. I don’t think is wise. If we include the BFO data in our analysis, then northern paths are allowed only if the BFO data were manipulated. In this way, an assessment of the likelihood of a northern path can be made based on the likelihood of the manipulation of the BFO data. Or we can simply reject northern paths based on the flaperon evidence. Unfortunately, the discovery of the flaperon seems to have raised more questions than it has answered.
I share the frustration expressed by many here about reluctance for France to release the results of its flaperon investigation. Unfortunately, Malaysia is an important customer for French military systems, and I fear that the guarded statements from the French are at least in part due to this relationship.
It is perhaps somewhat simplistic to treat “the French” as a monolith and to insinuate sinister motives.
“The French”, as an “Accredited Representative” to the ICAO Annex 13 Safety Investigation conducted by Malaysia, are obliged to leave the publication of any findings to Malaysia’s Safety Investigation Team for MH370.
@Gysbreght
Yes, but it is more fun to pick on the French.
@StevenG
Steven, there really is no such thing as “bad” data. In a Kalman sense, it is the weighting that is important. Unfortunately, we don’t have much to guide us in this regard. Of the many things that could be released to help us, ISAT data from known flight paths, and the raw radar data top my list.
@Gysbreght: The French have not been silent in accordance with Annex 13. They have simply been selective in the content and timing of their statements. I never said their actions were “sinister”. I only point out that they have a vested interest in maintaining a good relationship with the Malaysians, and this could be a factor in what information is released. The French are also tainted by the past scandal regarding bribes for Scorpene submarines.
I stand corrected, there was a meeting last Tuesday in Beijing.
http://malaysiandigest.com/news/571488-malaysia-china-australia-still-committed-to-locate-mh370-says-dca-d-g.html
sk999,
Re: “…one gets the impression that if the AES cannot guarantee that its transmissions will be within spec, it will not transmit”
How can AES guarantee that its transmissions will be within spec if it does not account for vertical velocity component?
I believe the French judiciary have some freedom of action relative to obligations undertaken by the French government under Annex 13 (separation of powers?), but they also have to tread carefully in order not to jeopardize the French position as a representative in present and future Annex 13 investigations.
Gysbreght,
Not only end-of-flight, but also 18:25-18:27.
I’ve just realized that if the disappearance from radar 18:22 was caused by the drop in altitude due to dual flameout, it would take approximately 4 minutes to reach the log-on stage of AES. In other words 18:25 log-on may not be coincidental with the disappearance 18:22: both are the results of the dual flameout. Don’t ask me intentional or not.
@Oleksandr
If both engines failed and automatically re-started, wouldn’t the re-start have to happen with 1 minute 25-30 seconds to allow for signal transmission to process the logon and stay within the 4 (I though it was 3) minute time frame, could it happen that quickly?
Re BFO and Fcomp, here’s a question to Electronics/Comms whizzards on this blog:
Given that we are talking about known frequency bands, how difficult would it be to design and build a small receiver to detect and record SATCOM transmissions?
If that is not a big deal, we could try to crowd source BFO logs from known flights and would not have to wait for ISAT to release such logs from other flights, if they ever do.
Analysis of such logs would possibly allow to determine actual performance of the compensation algorithm rather than rely on what the specs state.
For example, from memory, altitude data is available, but according to spec, “not used” in the frequency compensation. I always wondered, whether the algorithm developer would not go that extra little step and make use of that available data and produce a “better than spec” algorithm. It’s in a developer’s blood to do such a thing. I often did in my developer days, when the opportunity arose.
If someone here can design such a thing, someone else build it, then send it to Matty in Perth, who could place it next to ISATs GES antenna, we’d quickly build up a nice big log. Publish that and the data analysis experts here could decipher the signals and build AES specific logs. These could then be matched up with FlightRadar type data for known flights (position, velocity, altitude, etc.).
If such a device can be small and energy efficient enough, we could have a few built and sent to people who are about to fly on 777s and record from on board, which might make it easier to isolate the transmission and associate with the particular flight they are on. In this latter case, the need for deciphering the transmission content (AES ID) would possibly not be needed and recorded frequency bursts would be enough to analyse how the Fcomp of that particular AES works.
Any takers ;o)?
Cheers
Will
MuOne – my ute is ready!!
The French – they are doing their own thing and noone cares. Victor has made the link with France-Malaysia defense contracts but there are some other players too. To not care about MH370 is to know what happened to it.
Oleksandr,
“How can AES guarantee that its transmissions will be within spec if it does not account for vertical velocity component?”
I think you can answer this. The specification calls for an accuracy of +/- 383 hz, which amounts to 14,000 feet per minute if entirely due to ROC projected onto the LOS of the satellite from the aircraft. That is obviously well outside the normal operation range of an aircraft. If there were no compensation for Doppler, however, it would correspond to 140 knots projected onto the LOS, which could obviously be achieved routinely. So presumably the SATCOM designers felt they could ignore the former but not the latter.
@sk999
“Regarding update rates, Table A-10 of the MCS7200 manual gives “ARINC 429 Data Requirements”. Orientation parameters (track, heading, pitch, roll) require updates rates no slower than 40-55 msec per update (depending on parameter).”
You forgot to mention from the same table that the minimum rate for latitude and longitude is 334ms. And for ground speed 125ms.
@all
Interesting quote from FI :
“1.6E.14.1 Global Positioning System (GPS)
Left and right GPS receivers are independent and supply very accurate position data to the FMC. GPS tuning is automatic. If the Air Data Inertial Reference Unit (ADIRU) becomes inoperative during flight, the EICAS displays the message NAV ADIRU INERTIAL and the FMC uses only GPS data to navigate.”
Now what happens if this “very accurate position data” is removed, becomes invalid or is even spoofed?
We know SDU needs position data to compute deltaFcomp, from ARINC 429. Does GPS provide FMC over ARINC 429 too?
@sinux
The 300ms number corresponds to what a usually reliable third party told me. Shame on me for not checking it against available documentation. That value would produce heading lags on the order of a degree for a standard rate turn – not negligible. The 300ms number is what motivated me to look at the phenomenon in the first place.
Of course relative to the speculated spiral descent after flameout, much higher turn rates would be anticipated. A substantial Doppler contribution from sensor lag should be anticipated in that case.
@Dennisw
We must still remember that 334ms is a minimum rate. In this case maximum rate is 67ms.
What is the typical rate?
Not that anything about this case is typical…
Still speculating about spiral dives? Have a look at ALSM’s simulator test. The log-on request comes 3m40s after 2nd engine flame-out.
https://www.dropbox.com/s/6xyjfremawns542/ALSM-lateral.jpg?dl=0
Also a standard rate turn is appropriate for holding speeds and altitudes. At cruise speeds and altitudes a typical rate of turn is 1 deg/sec.
The dFcomp is most sensitive to turn rate on tangential headings, and least sensitive on a radial heading. A few days ago ALSM has pointed out that to traverse the distance between the 6th and 7th arcs in 8 minutes, the airplane cannot have been far off a radial heading.
@Gysbreght
No spiral dive speculation emanating from me. I have carefully avoided end of flight scenario pondering. When you are thousands of kilometers off at 0:11 it does not matter much what happened at 0:19. 🙂
Susie,
Re: “If both engines failed…”
ATSB Report, p33: “The APU would take approximately one minute to start-up”
ATSB Report, p33: “After power became available, the SDU would take approximately 2 minutes and 40 seconds to reach the log-on stage”.
By adding, we have 3 minutes and 40 seconds. If the APU was “ON” and SDU was also “ON”, there would not be power interruption, and thus no log-on event 18:25:27.
The last radar fix was at 18:22:12 and the aircraft disappeared “abruptly” according to FI. That means dual flameout could occur at 18:21:47 or earlier, and correspondently we have at least 25 seconds of descent. Add on top of it the period of radar scan. If the descent was as violent as ALSM suggests for the end-of-flight, the aircraft could loose about 3 km of altitude within this interval. This would be quite consistent with the Phuket radar range (see figure above for its location).
sk999,
If I were a designer, I would probably assume the effect of max certified ROC(ROD) on top of the compensated BFO. Have you ever tried to estimate the maximum (over the IO region and assuming moving satellite) compensated BFO at zero ROC?
sinux,
Re: “Left and right GPS receivers…”.
Specifically due to this, I suggested an explanation related to GPS in my TN. There is also description how these GPS are powered. Only one of them is on standby power, which can use the battery. But in a rare event of dual flameout, would it be powered as an essential tool? Or ADIRU would be considered as sufficient (ADIRU is a primary source) for 1 minute, during which APU is supposed to start?
Victor,
Re: “The range calculations were solely based on the line-of-sight between the target aircraft and the radar head, including any obstruction caused by terrain features such as hills and mountains”.
Could you estimate the minimum altitudes, at which the aircraft would be captured by radars from your list at 18:22 accounting for the terrain features?
@Oleksandr: There were no terrain obstructions for the range limits of Phuket and Penang Island radar installations for an aircraft at the assumed 18:22 position. The coordinates of the radar installations are:
Penang Island: 5.425,100.251, H = 812 m
Phuket: 7.881,98.316, H = 509 m
The radar range due to horizon obstruction is given by:
d = sqrt(2RA) + sqrt(2RH)
where R is the earth’s radius, A is the altitude, and H is the radar height, all in consistent units, of course.
Using this equation, and knowing the position at 18:22, you should be able to calculate whatever you wish.