Experts from all over the world have converged in Perth, Australia, to meet Seabed Constructor, the exploration vessel tasked with finding the wreckage of MH370, after its first stint in the search area. Technical experts and government officials are having meetings and dinners, touring the ship, and doing photo ops. Everything glitters and spirits are high.
Lost in this excited hubub is the fact that the latest search effort has already invalidated the expert analysis that got it launched in the first place.
In a 2016 document entitled “MH370–First Principles Review,” the ATSB explained that, given the absence of wreckage in the orginal 120,000 sq km search, MH370 most likely wound up somewhere near the 7th arc between 33 degrees and 36 degrees south. A subsequent document by the CSIRO entitled “The search for MH370 and ocean surface drift–Part III” narrowed the target area considerably. “We think it is possible to identify a most-likely location of the aircraft, with unprecedented precision and certainty,” it stated. “This location is 35.6°S, 92.8°E. Other nearby (within about 50km essentially parallel to the 7th arc) locations east of the 7th arc are also certainly possible, as are (with lower likelihood) a range of locations on the western side of the 7th arc, near 34.7°S 92.6°E and 35.3°S 91.8°E.”
The wording is important, because as the original search area was winding down, Australia, China and Malaysia said that it would only be extended if “credible new information” came to light. The CSIRO’s language sounded like an attempt to make the case that this condition had been met. And indeed, the three specified points were all included the “Primary Search Area” that Seabed Constructor recently focused its efforts on.
However, that area has now been searched. And once again, the plane was not where it was supposed to be. The CSIRO’s “unprecedented precision and certainty” was a mirage.
How is that, time and time again, officials heading up the search for MH370 exude great confidence and then come up empty handed? How can we account for four years of relentless failure?
The answer, it seems to me, is quite simple. Investigators have resolutely failed to grapple with the single most salient clue: The fact that the Satellite Data Unit (SDU) was rebooted. This electronic component is the part of the 777’s sat com system that generated the Inmarsat data that has been the basis of the entire search. There is no known way that it could accidentally turn off and back on again.
If one has no idea how the SDU turned on, then one can have no confidence in the integrity of the data that it generated.
The ATSB has never publicly expressed a theory about what could have caused the reboot, except to say that most likely the power had been turned off and back on again. There was always the possibility that, behind the scenes, they had figured out a way that this could plausibly happen other than being deliberately tampered with.
Just today, however, I received confirmation that the ATSB is in fact befuddled. Mike Exner is a stalwart of the Independent Group who is currently visiting Perth, where he has had dinner with employees of Ocean Infinity and Fugro, as well as members of the ATSB and the DSTG. In response to my assertion that investigators “had never stopped to ask how on earth the SDU… came to be turned back on,” Exner tweeted that “Everyone is well aware of the question. We have all asked ourselves and others how it happened.” However, Mike writes, “no one has the answer.”
One might forgive the expenditure of vast wealth and manpower based on data of dubious provenance if there was other evidence that independently supported it. But the contrary is the case: debris collected in the western Indian Ocean shows no signs of having drifted from the search zone, as I wrote in my previous post. It is increasingly clear that the plane did not go where the Inmarsat data suggests it did. The fishiness of the Inmarsat data, and the fishiness of the SDU reboot that created it, are all of a piece.
Soon, Seabed Constructor will return to the search area; some weeks or months after that, it will leave again, empty handed. When it does, people all over the world will ask: How could they have failed yet again?
The answer will be simple. It is this: Investigators never established the provenance of the evidence that they based their search on.
@Michael John
…believe it is Ping Ring Arc5 goes past KLIA at 22:41 but the flight lasted over an hour an a half more
@TBill
Yes my mistake. ARC 6 was 00.11 & ARC 7 00.19am.
I was thinking about the -2 in a previous comment. Wasn’t that dismissed as being erroneous?
8/03/2014 00:19:37.443 IOR-R1200-0-36F6 IOR 305 10 R-Channel RX 0x15 – Log-on/Log-off Acknowledge (-2) (49660)
The true 1s I believe were:
8/03/2014 00:10:59.928 IOR-R1200-0-36ED IOR 305 4 R-Channel RX 0x15 – Log-on/Log-off Acknowledge (252) (18040)
00:19:29 – Log-On Request (reported as a Partial Handshake), initiated from the aircraft terminal:
8/03/2014 00:19:29.416 IOR-R600-0-36F8 IOR 305 10 R-Channel RX 0x10 – Log-on Request (ISU)/Log-on Flight Information
(SSU) (182) (23000)
@Brian,
You’re making excuses.
You are saying that the total trip length was logged. That’s new information because the reported log values were on the order of 9,000 to 22,000us, while the trip time was in the neighborhood of 500,000us.
Which is it? How did it get from total trip time to a 4-5 digit value?
And no, it’s not reasonable to begin logging for location purposes and then round by 20us. (Yes – thanks – I’m aware it’s only a slice of a sphere, not a point.) If the equipment had precision below 20us, it should have been logged. If it did not have the precision, you shouldn’t be using it to define rings.
I’ll add one other point – the reason you all are taking so much criticism from the peanut gallery is simple. You’ve thrust yourselves into the public spotlight, provided contorted explanations, congratulated yourselves on the fine work you’ve done in finding the plane, and then found no more than a rotting wooden boat. Then, when the going got tough, you harp on everyone else’s lack of knowledge.
@JS
Your exchange with @Brian Anderson reminded me of this.
The paragraph in italics below
From Victor Ianello’s blog 6/12/17.
“The Unredacted Inmarsat Satellite Data for MH370” 6/12/17
“The satellite data was shared with me by a relative of a Chinese passenger on MH370. The data was given to him by Malaysia Airlines with the following email text:”
“…The Malaysian Investigation team does not have any experts to translate these data into any meaningful information….”
@Michael John
“I was thinking about the -2 in a previous comment. Wasn’t that dismissed as being erroneous?”
My understanding after some review ATSB/IG/etc. finally decided -2 BFO was valid. It is the -2 BFO at the very end that suggests a nominal 15000-ft/min descent that looks like the end of the flight. Although as mentioned by @Gysbreght, that “dive” is not quite so severe as it might sound…you could probably pull out and glide further if you wanted to, assuming a certain altitude. But since all communications ended then, it looks like it might be the flight’s end.
As far as quality of BTO/BFO we are extremely fortunate to have the 18:25 SDU logon close to 18:22 last radar, to the point where we can actually map out an apparent flight path out to 18:28. Other than that keep in mind BTO is a time ping, so that is more solid.
Conceivably BFO has some drift as it comes from a quartz crystal which has some drift in frequency etc. So BFO accuracy is a question. Working with the data, I see no problem with it though.
We do not know the BFO calibration of the sat calls at 18:40 and 23:14 as that is a different channel – one thing I keep an eye on is how people handle that in their papers.
@Susie Crowe,
Thank you, and that’s very interesting. If the log contained simple times in nanoseconds (or any other unit of time) there’s nothing to translate – it’s speed of light math that a 5th grader can do.
“Translate” is probably a word that got lost in translation and may have meant “processed” or something but I still find it odd that Malaysia couldn’t do a ping ring calculation. Most of us can do “how far is the lightning” using speed of sound. This is the same math with a few additional values pulled from the internet.
@JS,
Nope, no excuses, just reiterating for you a few [inconvenient] facts.
Many people have correctly calculated the LOS distance from the satellite to the aircraft, and then translated that into arc distances from the sub-satellite position, over the last 3 or so years.
Rather than arguing with you, i’ll leave it to you to do the calculation yourself, perhaps with the following help:
Let TD_C be the transit time for the C band link [Perth to satellite],
Let TD_L be the transit time for the L Band link [satellite to aircraft]
Then, BTO = 2*TD_C +2*TD_L + K
You ought to conclude that TC_C is about 130mS, TD_L is about 124mS, the constant [determined by ATSB and many others is about -495mS, and hence the LOS distance from the satellite to the aircraft is about 37,000 km.
I don’t know why Inmarsat chose to round or truncate the BTO values. Who cares. It is what it is. The effect is that the position of the arc is known to within about +or-5 km.
By the way, I post under my proper name. Your . . “You’ve thrust yourselves into the public spotlight, provided contorted explanations, . . . and similar, comments are just B.S. Get over yourself !
@Brian Anderson
The calculations are widely known and relatively simple. Let me have some questions though. While responses to my questions can be somewhere I can’t recall them (I browse these threads since years, but could’ve missed something).
First – the aggregated bias (K). With what certainty was it calculated?
Second – was the data compared to other data from other planes (reference data) to narrow down error distribution?
Third – what precision of values the devices in question provide and how they adjust values with different precision than default (to be clear – adjustments can introduce additional error that can build up)? To me this rounding is also weird, especially because of strange base – 20. Which can depend on 1/5th precision of something, but would be nice to know for sure.
@Brian Anderson
The IG has offered assistance to various wings of the investigation, much of it publicly displayed.
Part of that display included grandiose comments to individuals from a few IGers, comments unnecessarily tailored to belittle or imply inferiority, laced with arrogrance and sarcasm.
Having zero tolerance for pious behavior its difficult now to look at the work of the IG without seeing it as a veiled sense of entitlement.
We should all be on the same page, finding answers to end this story with a proper conclusion. Achieving this without notoriety, the non IG contributions are also significant.
(Yes, Susie Crowe is correct, unfortunately too much disagreement is
expressed disagreeably.)
_____________
Recently, elsewhere,
David says:
February 20, 2018 at 4:14 pm
@TBill. “…..at what point in the continuum of loss of normal electric systems
does the Flight Data Recorder finally stop recording?”
Good point. The manuals show it powered by the right AC transfer bus,
so it will stop recording on AC power loss. To power and restore it in the air
an IDG, backup generator or APU would need to be on line.
________________________
This was a reasonable assumption above by David, and I have not come across anything
that would indicate to me that the Right AC Transfer Bus was depowered.
UNfortunately… there are nuances.
CAL_Training_Manual_B777-200_WB371.pdf , 31-41-00, page 47, shows how the
‘AIMS – ARINC 717 BUS INTERFACES’ connect to the FDR. It represents the ARINC
717 wiring connections as travelling from the Right AIMS, to the LEFT AIMS,
then via a relay represented as internal to the LEFT AIMS, then to the FDR.
In my theory, there was probably arcing and a fire, proximate to the LRUs on
the E3-2 shelf. The Left AIMS sits on the E3-1 shelf, above E3-2. Therefore,
the possiblity should be noted, that regardless of whether the state of that
aforementioned relay was to connect the FDR to either the Left AIMS or the
Right AIMS, if the ARINC 717 wiring connection from the relay at that
Left AIMS was damaged by a arcing or fire, there may be no ARINC 717 data
recorded by the FDR, from the time any arcing or fire may have affected the
ARINC 717 wiring connection.
(It is known that the Left AIMS supplies the Flight ID to the SDU. Some people
therefore, may also consider it as an indicator of Left AIMS non-operation or
damage, the FI mentioned fact that “No Flight ID was sent to the GES during the
Log-On” about 18:25 UTC.)
I leave it to others to investigate what, if any, other data the FDR may be able
to receive from non-ARINC 717 (AIMS) sources.
One incidental point comes to mind – The ADIRU is located on the E3-3 shelf, under
the E3-2 shelf. Wouldn’t arcing or fire damage the ADIRU or its connections?
CAL_Training_Manual_B777-200_WB371.pdf , 34-20-00, page 27, has a representation
of the ADIRU and following pages state installation instructions. It can be seen
that ARINC 629 and power connect via the front of the ADIRU, rather than its rear.
Also, representations of the E3-3 shelf in the aforementioned document, appear to
show that shelf as posssibly not extending as far rearwards (perhaps only two thirds
depth?) as the shelves above it, therefore I consider that arcing or fire would not
necessarily have affected the ADIRU or connections to the ADIRU (and it must be said,
the ADIRU has multiple redundancies in regard to connections for signal and power.)
If readers do not have the above mentioned document to hand, the following webpage
may be helpful;
https://www.pprune.org/tech-log/542785-boeing-777-fdrs-cvrs-informational.html
Cheers
@SteveBarrat
Hallo Stevbe, hope i didnt cuase a misunderstanding: i did not talk about the machanics of inhale and exhale at high altitudes, but about the chemical process of diffusion of gases in the alveoli in the lungs. At FL350 the diffusion of oxygen into the blood is impossible without pressurized oxygen supply. So the masks of the flight deck have pressurized oxygen, but dont need to support the musculare inhale/exhale process.
Test
://i2-prod.mirror.co.uk/
://hk.on.cc/
@Susie Crowe – its not confined to this forum.
Seems to be seatback monitor casing/-Vs-/chassis wars over at the other place.
References to seatbacks of other crashed aircraft such as Asiana 214, or say,
to BA 38 (1-2010_G-YMMM.pdf, figure 39) are not particularly helpful, as these seem to be different model seats to those used by MAS in MH370.
I don’t intend to express an opinion.
These pics may be helpful, though. : (Insert http at the start of the URL’s below)
MAS, MH370;
://i2-prod.mirror.co.uk/incoming/article8154452.ece/ALTERNATES/s615/New-MH370-debris-found-on-Madagascar-beach.jpg
MAS, MH17;
://hk.on.cc/tw/bkn/cnt/news/20140720/photo/bknint-20140720145051425-0720_17011_001_01p.jpg
https://www.youtube.com/watch?v=QfbhClMkybY
@Brian,
I’m not disputing the equation with you. It’s speed of light/line of sight math.
I’m disputing the thoroughness of any explanation of the log value.
If BTO was indeed 2*TD_C +2*TD_L + K, then K must be known at the time of logging. If K was not known at the time of logging, the log value cannot be trusted at all without an explanation of why K was not known. That’s the part that everybody took for granted. They said K of -495 fits a few points in the fight so it must be a constant, with no explanation of why it would be a constant in the first place.
You say “who cares” about the rounding. One question for you: how many millions of dollars is an additiona error of +/- 5km worth? It is not a trivial value, and I’m amazed that you just shrug off a decision to round a number going into a log file. It is twice indefensible – first that the rounding was done, and second that it is not discussed with a skeptical eye.
Seems to me these are stones left unturned. I’ll take it you disagree and you believe nothing further can be questioned about these BTO values.
@JS
No one is disagreeing (Brian or anyone else) with the notion that the ISAT could be flawed in some way. What is fundamentally incorrect is believing that the data is flawed because the aircraft has not been found. The data could be perfectly correct, and still result in a “not found” situation. You might well be right, but it would be for the wrong reason.
@Dennis,
I’m not saying that at all. I am saying that the neither the data nor the methodology can be considered correct until the plane is found where the data said it would be found.
I have to also disagree with you on the point that no one is doubting that the data could be flawed.
Brian himself writes:
“Many people have correctly calculated the LOS distance from the satellite…”
That statement implicitly assumes the data is not flawed and further assumes that the calculations yielding distance are correct. There is neither an allowance for flawed data nor an allowance for inaccurate constants.
@JS and @Mark
“. . then K must be known at the time of logging . . ”
No, that is quite incorrect. All that is logged is the time delay [the Offset] from a point in the TDMA frame structure for a particular channel transmission until the the expected response arrives. None of the components making up that delay are known, but some can be subsequently derived.
The constant “K” is the component that accounts for all delays in the electronics within the AES and the Perth earth station relative to measuring the Offset.
A reasonable number of BTO numbers logged while the aircraft was on the ground at KL, during takeoff, and for the first 30 minutes or so of flight have enabled other IG members to carry out a proper statistical analysis for the derivation of “K”.
See here . . . http://www.aqqa.org/MH370/models/bto_constant/Calibration_Mean_BTO_Constant_BSMGH_MLE.pdf
@Brian,
I will acknowledge that some components of K are unknown, but i maintain that a large part of it, on the order of 500ms, was or should have been known.
But let me try to get clarity on one point. A log value of 22,000, for example, cannot be the total trip time. How did the computer writing the log come up with this value? Let’s say we have T_1, the slot start time, and T_2, the arrival time. Is this not on the order of 517ms for a plane in the SIO? If so, how did it get measured at 517ms or so, and logged as 22,000?
@Brian Anderson
Thanks for answer. But it still does not address the three points I enumerated (questions).
So, there is an offset that was measured. Said offset comprises of three values, one of them is K (accumulated biases). Furthermore, said biases were estimated based on one set of data obtained from the fragment of data when the plane started its journey (so before reset). Is it right?
I assume from your answer that there were no other data sources taken into consideration for comparison. Is it right?
Please relate also to my last question.
@JS,
The BTO is logged, full stop. The values for this particular flight range from about 11,000 to 18,000 usecs. The number clearly depends on when you start the measurement from [and hence how you define your T_1].
@Mark,
There has ben a deal written, and investigated, over the last 3 1/2 years, by Inmarsat, ATSB, DSTG, and a variety of individuals. I’m not going to continue this discussion. I suggest you catch up by investigating the history yourself.
@Brian Anderson
Either you don’t know or don’t want to answer. Tertium non datur?
I did a research and thus I wanted to supplement what I know.
Nevertheless, after being stalled this way I wouldn’t trust your answer. And therefore I won’t continue this discuss either, as it would be pointless.
@all
As I couldn’t get any valuable answer from Brian Anderson maybe someone else here could point me to them?
@Brian,
I’m sorry. This is junk science. You have a value in the log that you call the BTO. You provide no explanation of how it got there, just that “full stop” it got logged – another non-answer.
You cite to an article which likewise makes no attempt to confirm the source of the value.
In fact, the article doesn’t even mention a log, except in the context of an ADS-B log. The article just assumes, like you do, that K must be determined in order to make BTO back into a complete trip time, with no consideration of how K got removed on its way into the log in the first place.
After all, your equation reduces to this:
Total_time_measured + K + Rounding = Logged_value.
For Logged_value to even exist, the equation had to have been solved. There were zero unknowns. There is also no error component. This is strictly the recording of a measured value adjusted by a computer according to pre-programmed rules – rules which necessarily define K as a constant.
For all the hours and days and YEARS spent refining the calculations this way or that way, there has not (publicly) been a single critical analysis on how the values were logged.
Was the code tested? Were the values subject to any unusual truncation or overflow issues? Is the number rounded up, down, or to the nearest?
Nobody knows. You all went straight into doing statistical analysis without doing any work on the source of your data.
This is what junk science looks like.
@JS
What would be your answers to my questions, just out of curiosity?
@JS,
You should address your concerns to Inmarsat. Clearly you understand little about the BTO measurements, and you are still mis-interpreting the formula and “K”.
The logged value exists because it is a direct measure of a time interval, a number determined by Inmarsat some years ago to be potentially useful in future.
Having recorded that value, one can look at the other values in the equation. The “rounding” is known [by Inmarsat], the value TD_C can be calculated once the precise position of the satellite has been determined, the value of TD_L can be determined from known aircraft position data, and hence the value of “K” can be calculated.
I turns out of course that “K” is indeed a [statistically relevant] constant, confirmed by tests over more than a handful of recorded values in the Inmarsat log.
As far as I know Inmarsat has never released details on precisely how the BTO value is logged. It would be interesting to know, but there has been sufficient other statistical work done on the data in the Inmarsat log for this flight, and comparisons with other flights to understand that it is a useful measure. And, as Dennis remarked, it is one of the few concrete pieces of data available.
@Mark,
You are free to believe whatever you like, but I am not obligated to answer your questions. I can give you some one-word answers, like:
1) . . read the paper I linked, as one example. ATSB and DTSG and Inmarsat will, I’m sure, have made their assessments too.
2). . Yes
3) . . I think only Inmarsat can answer that.
I’ve got better things to do than to respond to a succession of pretty dumb questions from people who haven’t taken the time to research the subject matter themselves.
@Brian Anderson
As I said – there is no point to continue discuss with you. While your infantile arrogance can be irritating, the most important is that you are just unable to discuss in civilized manner (argumentum ad personam works well in a public house and even this to a certain point).
1. I’ve read all of them;
2. links to raw sources?;
3. right.
When you grow up – let me know.
@ Mark,
And it’s the infantile personal attacks from people like you who caused me to leave this blog before. Hopefully I can resist the temptation to comment here again.
@Brian Anderson
Just curious – could you point out to place where I attacked you in my posts? I politely asked – you un-politely responded. Trying to blame me for your own rude behavior is silly.
@Brian,
Sorry about all the heat in the kitchen, but you know, some of us are annoyed that so many millions of dollars found only a few (empty!) beer cans in the SIO.
I’ll quote the part of your response I think is relevant, trimming out the attacks and other nonsense:
“As far as I know Inmarsat has never released details on precisely how the BTO value is logged. It would be interesting to know, but there has been sufficient other statistical work done on the data in the Inmarsat log for this flight, and comparisons with other flights to understand that it is a useful measure. And, as Dennis remarked, it is one of the few concrete pieces of data available.”
Boom. It’s not concrete. It’s black box. That may very well be why we’re still here and I’m not sure why you would defend such a lack of transparency. Nevertheless, the above paragraph sums up the sand that the IG built its castle on.
As for the formula, I think you might be contradicting yourself, but I’m willing to listen. Here is your formula:
BTO = 2*TD_C +2*TD_L + K
There are exactly four variables in this formula. Which specific variable is the observed value? Not inferred, not derived, not “statistically relevant” but specifically observed by the computer?
You can correct me if I’m mis-summarizing your posts, but I believe you are now saying that the only observed value in that formula is BTO.
We are at odds on this point. You believe, I think, that the BTO was observed, even though it is not the round trip time. This would involve the time from a different frame time than the one the signal began in – as you previously seemed to acknowledge, T_1 isn’t necessarily defined.
I instead believe that ISAT observed a complete round trip time and then reduced it programmatically prior to logging for any number of reasons.
I don’t believe you can prove either position from the data.
@buyerninety
I said
“Achieving this without notoriety, the non IG contributions are also significant.”
You are a prime example of this.
Your methodical comments also, consistently reflect objectivity, not an easy feat.
@Susie Crowe – “its not confined to this forum.”
GR has been knocked around quite a bit and remains undeterred.
It seems to me that ISAT has stated they have the answer to where Mh370 is (7th ARC) & we all have been faithful to that statement. Whilst there is still a way to go & of course there does appear to be small variables to be examined & considers (possibilities of glide etc) but after all the failures to date to produce any conclusive results surely should give a degree of doubt over the reliability of the Data or formula. The fact the Data is corroborated against other known flights tells me that something with the data in regards to Mh370 is suspect. What I don’t understand is why very few people also see that. We have to remember the ATSB (amongs others) invested a lot of money into the 1st search because they were led to believe that the data was solid & the location of 9M-MRO was dead cert. The new search by OI has passed the hot spot & now they are back to taking pot shots in the dark. We are all hoping that they will strike lucky. But I just don’t think the confidence is there. Some members of the IG are already dropping their success percentages like hot stones. This is not helping that confidence. Much akin to rats abandoning a sinking ship!. I still believe that the only way we will know what happened to Mh370 is by starting the entire investigation from the beginning but this time getting full transparency from all parties.
@Jeff Wise said February 19, 2018 at 8:09 AM:
I would say that the BFO data does not fit any endpoint south of 30 degrees south, assuming the log values are accurate with zero error.
The BTO and BFO data exhibit a smooth progression with time between 19:41:03 (Arc 2) and 00:11:00 (Arc 6). Using expressions for the variation of BTO and BFO versus time, it is possible to define the airplane’s groundspeed in magnitude and direction at arbitrary times and locations between 19:41:03 and 00:11:00. The graphic below shows this for a few points halfway between 22:41:22 (Arc 5) and 23:14:03 (the unanswered phone call). The arrows represent the distance travelled in one hour at constant speed and heading.
https://www.dropbox.com/s/ushomp7s6w25io3/Arc225743.pdf?dl=0
@Michael John, It’s interesting to watch the pivot of the default viewpoint (meaning, the viewpoint that the IG and its allies would have us believe that all reasonable people hold) from “the Inmarsat data is rock solid, and it tells us where the plane went” to “the Inmarsat data is rock solid and is consistent with an endpoint in all sorts of places.”
@Gysbreght
First of all, isn’t @sk999 saying that the June_2014 report was in error? I thought that was good information from sk. Many of us favor the June_2014 model approach, because it does not make assumptions of flight path before Arc2, but we do not have an update (or do we? – see below link)
Secondly, aren’t you on “thin ice” using the 2314 sat call? We do not have calibration data for that BFO. I do not currently see any proof of 30S&north in the raw data. I see descent possibly starting before 23:14 so also if you are assuming level flight I am not on board.
I also feel smoothing the data removes some of the bumps, those bumps may tend to prove an effect of the winds (eg; CTH or CMH heading modes) and descents etc.
Not to say there is no value in trying to look at the data in different ways…there is value.
Note in the more recent “The data behind the search for MH370” (believe you have the link) the graphic version they have there shows paths down to 39S, so that seems to be a better representation of what ATSB is trying to communicate from the June_2014 approach.
https://geoscience-au.maps.arcgis.com/apps/Cascade/index.html?appid=038a72439bfa4d28b3dde81cc6ff3214
@Jeff Wise
I wait for a pivot like “Hmmm, there never was any actual data, only its transcription”. But I’m sure it will never happen.
The data provided by Inmarsat is questionable in many aspects. That’s why I asked my questions while knowing answers.
The main issue is that it was never raw. This wouldn’t be a big problem, as long as we’d know exact transformations applied to raw data and methods used in data acquisition. Which we don’t.
What actually strikes me is arbitrary precision that has no explanation. I analyze data. When an analog signal is routed via several devices it’s usually quantized on each of them (to be properly categorized, packed in some protocols, etc.). Quantization introduces some loss of data, as analog (linear) values must be turned into digital representation.
Quantization is achieved via sampling – the meter scans several ranges on input. If the actual value falls in previous sample but isn’t in next, then, depending on algorithm one of three strategies is applied – taking lower value (floor), taking higher value (ceiling) or taking average. Taking floor is most computationally effective, as it can be done by simple bit shift. The problem arises when two or more devices applying different sampling strategies are coupled together. Then error accumulates. While accumulation can be spotted in some circumstances if there are several factors involved, symptoms of accumulation can vanish in noise and the data will look like correct.
Above applies to analog data being quantized. There is also another area in which errors can be introduced – digital protocols conversions. While ideally all devices should use the same set of protocols, due to different manufacturers and their preferences there are points where conversion must be performed. Also here some roundings can be introduced, as allowed frame size of next protocol can force the data from previous protocol to be compressed with data loss (rounded).
The last step where some misalignement between original broadcast and transcript can occur is transcription of stored, probably binary, data and what was actually published. Most probably stored data was in format that shows BFO in twenties microseconds (1 unit – 20 µs). But it’s only an assumption.
Let me tell you all a fascinating story from my childhood.
I was in a cooking class once, we had a fantastic cook that had years of experience & faultless credibility. This cook decided to bake us a fabulous cake from a unique recipe. The cook even though nutritionists in to agree what a fabolous cake we was going to see. So the ingredients were mixed together & that mixture went into a cake tin which went into the oven. But No cake appeared!!!
A short time later we had the same cook & nutritionists who again told us the ingredients were a sure fire success. Although they had now altered the mixture slightly but the ingredients were essentially the same. So the mixture went into the cake tin & back into the oven. We were promised…. No assured we would see early signs of a cake forming. We waited & waited & sure enough No cake!!!! I turned to my fellow students & pointed out that there was clearly a problem with the ingredients of the application of those ingredients. But I wasn’t a cook… Or even a Nutritionist so what the Hell would I know about baking a cake!!! In fact some said I was *Conspiring* to make the cake fail! Branded a conspiracist just for pointing out the obvious….
I’m still waiting for that cake today. A part of me hopes that I will be wrong & this fabulous cake will appear…..
@All:
I found an error in the calculation and am in the process of revising the graphic I posted.
@TBill:
“First of all, isn’t @sk999 saying that the June_2014 report was in error?”
I’m not sure I can entirely agree with what @sk999 said. I believe the main change after June 2014 was the assumption that the turn south occurred before 18:40.
“Secondly, aren’t you on “thin ice” using the 2314 sat call? “
No, I don’t think so. ATSB or DSTG reported somewhere that they did tests and found no difference in the BFO calibration for the channel used in phone calls compared to the ‘ping’ BFO’s. Yes, my interpretation of the BFO’s assumes level flight at 22:41 and 23:14.
I’m not aware of “The data behind …”.
@Michael John,
Was the oven on?
@Gysbreght
DrB derives an adjusted BFO bias for 2314 by assuming level flight at 23:14 (iffy assumption for me) and he then applies that to the 1840 FMT BFO (another iffy assumption for me). In short DrB is adding +4 to the reported BFO’s for the sat phone calls.
@All:
I have revised the graphic I posted this morning at 7:06 AM, and I withdraw the statement in that post that the BFO data do not fit endpoints south of 30 degrees south.
Apologies for any inconvenience that I may have caused.
@JS
I’m sure it was on at 1st. Then it went off. Then we were told it came back on. Maybe that’s why the cake failed to form. The cooker didn’t come back on…..
That would be conspiracy thinking though. We have been shown through the method that despite the problems the oven was definitely switched on after it switched itself off…. Maybe the cake is just a slow burner & will appear soon….
@JS
Come to think of it I thought the oven may have malfunctioned. My mate Jeff thought someone had tampered with it. Although the cook & nutritionists swear blind everything was working perfectly. Me & Jeff are still a bit confused. If the ingredients & mixture were right & the oven definitely worked as it should then by rights we should have seen the cake by now…
TBill,
The story of Inmarsat’s struggles with what we call the “sat+afc” correction is documented in various places in the ATSB Final Report, particular Appendix 3 (and see also Appendix 2). They developed three families of models (OAMS, Eclipse, and Unified), each with multiple variants. The exact details are not described, but by reverse engineering some of the figures and text in the appendices, one can infer that the first two sets of modes had serious errors that led to predictions of final positions along the 7th arc that were too far North. All of the flight path reconstruction figures in the June 2014 ATSB report were prepared using the Eclipse model. They are all invalid. The Unified Model (which is far more robust) was not released until June 19. It was used for the calculations in Appendix G of the June report only.
I may have some details wrong but think the basic story is correct.
@sk999,
RE “sat+afc” BFO correction, maybe you can share your view on the the following points on Inmarsat data that i struggle with also:
C. Ashton paper stated “The AFC receiver was not designed to handle a GES located south of the equator, and so to make it work it was configured with a positive GES latitude rather than a negative one. This means that the receiver did not behave as intended, and that its Doppler compensation algorithm did not accurately remove the C Band component
of Doppler present in the signal. Fortunately Inmarsat monitors the received
frequency of the Pilot signal after it has passed through the frequency conversion at
the GES and it is possible to calculate the frequency conversion applied by the receive
chain so that it can be calibrated out in the BFO calculation.”
* I am particularly intrigued by this.
– Does it implies the measured BFO is faulty in a first place based on this design fault?
– For the calculated BFO,
— what if doppler for this component (it seems one of the largest droppler component) had its sign reversed intentionally/mistakenly?
— would it impact the droppler bias?
— imply a number of manoeuvers and different end points?
— Do we have the actual values (which seems to have been discarded from the calculations)?
* Second, the Yap model/BFO predictions seems to use Figure 11 as the basis for all calculations for this component based on this whole issue. Was this Figure 11, independently validated or taken at face value?
* Third, the paper indicated that the BTO was introduced for geolocation purpose. With hourly intevals, fate irony it seems.
HB,
You note that Ashton said, “The AFC receiver was not designed to handle a GES located south of the equator …”
ALSM tracked down the root cause – it was a stupid bug in the software. Easily fixed, but Inmarsat decided to let it be, since the system still worked.
However, Ashton also said, “Fortunately Inmarsat monitors the received frequency of the Pilot signal after it has passed through the frequency conversion at the GES …”
“Fortunately” is an understatement. The system was designed with a different purpose in mind. However, the fact that the pilot signal from Burum passed through the same signal chain as the MH370 signal before either was digitized means that the pilot signal is able to neutralize the impact of that bug along with many other factors, including the sat+afc effect. No one here will appreciate it, but for our purposes, that design is utterly brilliant. If I could change it, I would not touch a thing.
As a consequence, the BFO is far from faulty – it is rock solid, at least with respect to all the effects that Ashton described.
I would argue that the whole issue with the ISAT BFO is that there appears to be a problem with recording the bias between recording the aircraft’s location in relation to satellites geo stationary position. What I mean by that is when you convert the figures to graph form the picture is only viewable from left to right. If you are a savvy enough to disect that graph into time frames & work it alongside the BTO you can get an over all picture that is more accurate. Although trying to get the IG to see or even understand this is nigh on impossible. I can demonstrate perfectly how my theory on this works….. & yes it does work. Although I would argue that it does point towards Mh370 being closer to Christmas Island than the current search location. (I think the aircraft is off Northern Sumatra so I have nothing to gain from this).
@sk999,
This is quite confusing, the paper states that the pilot signal was used in the subsequent calculations ie the BFO model (it does not mention the measured values C Band values were not affected nor the %error it would produce), seeming to imply that the logged BFO (I pressume at the GES) could possibly be affected and the BFO is not the value orgininally intended to be calculated. If this is the case, one would expect the BFO model to make the inverse corrections to be compared with the measured values. I think this is the meaning of Figure 11 which it all appear to be a manual correction and not a system automatically adjusting cancelling the error.
It would be good to elaborate how this “neutralisation before digitisation” works (for both measured values and for the BFO model) and what were the erroneous values produced by the AFC to compare with. As you said the %error may be negligible but how can one say that without knowing the magnitude of produced AFC values and the time history of the signal produced by Burum and whether Burum is fault free.
This brings to the other question as whether this Figure 11 which is used in the BFO model(s) was independently verified and validated? and also whether that information is available in the leaked raw data set?
Do you know whether there has been an official position on this topic?