MH370 - Resolving the Inmarsat Data
 

On 29 May 2014 the Malaysian DCA released on behalf of Inmarsat an abreviated Communications Log providing both the BFO and BTO data they logged for transactions through their IOR 3-F1 satellite to and from 9M-MRO on its last flight.

There has been a lot a discussion about what this data means, and whether it is possible to draw any definitive conclusions over the path the aircraft took from what is purported to be a Malaysian PSR contact at 1822z on 8 March 2014 near way-point MEKAR in the NW Malacca Strait.

To get the subject away from the speculative nature of the current thread in R&N, will hopefully result in some meaningful discussion.

There has been a thread established in the Tech Log in which those who have an interest in resolving the issues surrounding the Inmarsat data release are invited to participate.

BFO values
 

1)With one exception, all the published BFO values are positive numbers. Has there been any verified explanation of the "-2" BFO?

2) From an engineering prespective, I would have always expressed an offset as a positive value, regardless of the actual computation (leading to a positive or negative result). However in this case if the required frequency shift was positive, that implies one possibility; if the shift were negative that has contrary implications.

So, has it been verified that all the shifts are positive? Or has this been also left to speculation?

Raw data BTO
 

Thanks for the opening of this thread!

I have some problem understanding the BTO values published in the "Raw data" PDF (http://www.dca.gov.my/mainpage/MH370...ion%20Logs.pdf)
Perhaps there is a big thing I don't see, but I am looking at those values for a moment without a clue...

On page 1, we can read (bold from me):
All this seems perfectly clear, and I understand that the BTO is the sum of the round trip of the message (at light speed) and some delay from processing times in the different units.
And because of these processing times, the BTO have to be longer than the time (at light speed) from Perth (ground Inmarsat station) to Inmarsat 3F1 (the satellite) then to the aircraft and all the way back.
How long is this travel? It has to be longer than four times the height of 3F1, which is around 36000 km above the equator, that is about 144000 km, say 150,000 km, which is the distance the light travels in half a second (some maths gives ~159,100 km at 16:00 UTC when the aircraft was on the ground in Kuala Lumpur, so a ~0.5307 second travel time).

But all the BTO values given (for the "R" channel) in the PDF are between 14740 and 14920 microseconds (that is repeated on each page in the column title) when the aircraft was on the ground in KL between 16:00 and 16:30 UTC. Between these times 3F1 moved slightly away from KL : from ~37294 to ~37296 km, that is, in time at light speed, 124399 to 124406 microseconds. For this segment only, the travel time is thus near ten times the given BFO (and ~35 times for the round trip).

So, which distance are those microseconds values given in the "raw data" related to?

Could it be in relation with the distance between a point at sea level under 3F1? At 16:00 UTC, the point at sea level under 3F1 is 13560 microseconds away from KL airport in straight line and ~13790 microseconds along Earth surface. So in the same magnitude order of the "raw data" BTO (14820). But which magic brand could give this kind of "raw data"? Is some unit in the system making this computation, and only this result is filed?

Or I misunderstand all this stuff?



PS: From deleted post of the "main" thread, a "sub"question is: what is the "terminal at a nominal fixed location" (last line of "Raw data" page 1), question which came along with the post of a Canadian whose pseudo is something like ??23 (sorry for forgetting). I supposed it was the ground station near Perth, or, may be, the theoretical position of 3F1, but this obviously erroneous from the published BTO.

MG23
 

Copy of MG23's R&N post

Only if the aircraft is in one piece and not hiding behind a hill or in a canyon. The resolution of this ocean-bed survey is not suited to finding bits if an aircraft.

Massive Survey With Very Little Time
 

60,000 sq km is a very ambitious undertaking which must be at least close to completion before the side-scan search begins again in August.
Fugro and the Chinese survey ship Zhu Kezhen will have their hands full to get his done in time. Zhu Kezhen has already done several weeks of survey, but is currently in Fremantle for repairs to their multibeam echo sounder.
Two state-of-the-art survey ships can possibly get it done in tine, but only without weather or technical problems.

The BFO/BTO values have been calculated from a "nominal terminal" outside of the satellite, and this enables the movement of both the SAT and the AES to be taken into account, while ignoring the SAT - GES C-Band link. This "nominal terminal" appears to provide the positive offset.

In the -2Hz BFO case, either the offset is not enough or the figure is a result of an incomplete handshake; the later being more probable. The BTO associated also looks "off".

AMSA have issed a time line (with a click for details) covering their involment and related news from17/3/>31/3

Search for flight MH370 - Timeline of AMSA's involvement

Crumble - apple or rhubarb?
 

The whole Inmarsat edifice seems to be crumbling. Sadly.

They have previously stated that they have round trip times for the signals. This I understand very well as I am a data network engineer as my day job. I have been measuring network delays (let's call them) for decades.

Now they appear to be saying that they do not have those times. They only have the "offset" times. These are the differences between the times expected of a notional satellite and a notional aircraft and the actual times measured.

As far as I recall they have not released the position of the notional (I refuse to use the inexplicable 'nominal') satellite. They have not stated how they think they know the position of the notional aircraft.

They of course know where the notional satellite was. But they do not appear to know where the notional aircraft was. So any offset from the round trip time from the notional satellite and via the notional aircraft is meaningless without further information about the location of the notional aircraft.

I of course must be missing something - hopefully.

At present I have no inclination to even start on the BFO.

Hope this "nominal" thing will be resolved... Just a thought: the first things Inmarsat published were "arcs" which seemed based on angles. Perhaps this angle was found using arctangent from satellite altitude and BTO "converted" to distance (after taking away some time constant)?

Another remark. Just looking at the data, there is a strange similitude between the last data and the ones of 18:25. And they show the two highest BTO values:
and

There has been a deal of work done by others on reverse engineering the original BFO data, and it was successful in confirming a baseline when the aircraft was on the ramp at KUL. Though what those who did the work originally didn't realize, was that the AES was only correcting for the aircraft position and motion, and that the residual of 88/89Hz on the ramp was in fact the SAT motion Doppler on account of its orbital eccentricity.

Likewise, it is now possible to compare the BTO data and get a match, though the AES 'pass-through delays' vary with the bit rate of the channel in use. The released data identifies the bit/s e.g. 600/1200/10500. The common rate is 1200 and 180~200uSecs looks like the delay to use.

As for the "nominal terminal", my understanding is that it is outside the SAT and on the ground (surface) at 0° 64.5°E. This allows the L-band stuff to be dealt with, while ignoring the C-band SAT ~ GES effects. I hope to get a graphic together in the near future to demonstrate the principles described.

Yes, they are in each case an effect caused by the AES SDU starting up (after a power loss), e.g. the X'tal oscillator and/or Phase Locked Loop (PLL) not stable or locked.

That's a long and full discussion and many analyses on this blog ... :ok:
Duncan Steel | Space Scientist, Author & Broadcaster

Using the BTO data to get the ping rings
 

Here is my explanation of the Nominal Terminal concept, why it is used in the calculating the log values and how to utilise it with it in data analysis.

The Inmarsat notes say: “The BTO is a value (in microseconds) relative to a terminal at a nominal fixed location.”

It is the difference between a) the round trip from the ground station to the aircraft and b) the round trip from the ground station to the Nominal Terminal at some fixed location (with respect to the Earth). So:

BTO = 2 x [ (ground station to aircraft path) – (ground station to Nominal Terminal path) ]

As the Inmarsat notes say, each of those paths involves a ground station to satellite leg, and a satellite to terminal leg. The legs between ground station to satellite cancel in the calculation above (as they are the same for any single time), hence:

BTO = 2 x [ (satellite to aircraft path) – (satellite to Nominal Terminal path) ]

It has been stated by Inmarsat that the reason for logging BTO numbers was to assist in locating aircraft, so a measure that includes the ground station to satellite link delay element would be counter-productive. To be clear, the Nominal Terminal is a ‘virtual’ terminal which just exists in the Inmarsat processing system to allow them to log (in real-time) some meaningful (and short) numbers. The simplest assumption is the Nominal Terminal is at a fixed altitude above the equator at longitude 64.5E. I show a schematic of the Nominal Terminal idea below. The length of the green line segment in the diagram is that determined by the individual BTO values as shown.

https://www.dropbox.com/s/85ymzzaj6i...l_terminal.jpg

BTO values so defined can be used immediately to give a rough ping-arc using just the average satellite position. With the actual position of the satellite the full accuracy is possible. If only the full round-trip time to the aircraft was logged then more processing would be needed to get even a rough ping-arc, particular for aircraft positions close to the sub-satellite point at 64.5E.

The distance of the Nominal Terminal from the satellite can be calculated from the pings before take-off (where we know the aircraft position and hence the satellite to aircraft distance) using the formula above; this gives the satellite to Nominal Terminal distance as 35079km and hence a Nominal Terminal altitude of 718km. The choice of this altitude value is entirely at the convenience of Inmarsat. It can’t be zero as that would give negative BTO values for aircraft overflying the sub-satellite point. Also they would want some margin to allow for noisy measurements without giving negative BTO numbers.

On this basis, the fixed Nominal Terminal position determined as above (including the fixed altitude) has to be used in calculating the satellite to aircraft ranges from the later BTO values, allowing for the changing position of the satellite. There must be a small constant term in the BTO calculation that corresponds to the response time of the aircraft terminal but that can’t be differentiated from the altitude of the Nominal Terminal determined earlier.

The ping-arcs derived from this technique match those that follow from the ‘fuzzy’ photo of a satellite elevation graph shown to the families some months ago. The distances on the ground of the key ping-rings are as follows, using a 'average' aircraft height of 15000ft:

18:29UT 3630km
19:41UT 3375km
20:41UT 3436km
21:41UT 3692km
22:41UT 4096km
00:11UT 4819km

The Nominal Terminal concept does not apply to the BFO data.

@RichardC10

Thanks for giving that well thought out explanation.:ok:

I'm sure that many questions will arise from it, but the basis of the "nominal terminal" concept is out in the open.

I have mentioned earlier that the BFO and the BTO values can be matched up, and will plot the ping arcs/elevation angles together when charted.

@RichardC10 Thanks again for publishing a detailed explanation about this very interesting stuff.

And yes, questions, as suspected by mm43...
- I buy your "shorter" data consideration, but then how to explain that one negative value was stored if the height of the nominal terminal was chosen high enough to "forbid" negative values (the fact it was perhaps a corrupted data can't make "space" for the sign if not anticipated)?
- IMHO, I don't think that the localization of the nominal terminal can improve the accuracy: when the aircraft is in the area under under the satellite, any incertitude about the time gives a very high incertitude about the position: it is not like there was a physical mirror (for the signal) in this place. You can't use a "percentage incertitude" when subtracting the time of the known legs from the "total" time: you have to use the absolute incertitude.

There is one negative BFO number in the log, but no negative BTO numbers. The nominal terminal concept does not apply to the BFO data. For the BFO the standard is the frequency of the response expected, presumably the frequency of the assigned communications channel at that time.

If that negative BFO value at 00:19 is a valid measurement (rather than a noise/synchronisation issue), one explanation is a very high rate of descent, apparently 13000ft/min.

I agree. My point there, which may not be very important, is that until the ground station to satellite element is removed the round-trip time has a large variable offset (due to the change in ground station to satellite range over the orbit) which means it is not immediately useful for positioning the ping-ring at any level of accuracy. Of course, full identification of the satellite position at the moment of the ping is needed to get complete ping-arc accuracy.

Thanks for your answer and ... sorry for the stupid first question :O

About the -2 BFO: if valid, is not the (3D) direction of the descent playing a big role? Or the value given (13000'/min) is the minimum in the most efficient direction?

One more question...:
Is the way the AES compensate from its own speed and direction trully established? And, first, does it compensate always anything? Or only if the BFO value could be too high?

I have read it compensates:
- not using a measured Doppler from a signal from 3F1 (logical, if not, no pro rata BFO)
- relatively to the theoretical position of 3F1,
- only for horizontal speed and direction,
- using the ADIRU.
Are all these statements established or just deduced or guessed?

It seems the aircraft terminal compensates for the aircraft speed and direction of travel, but not rate of climb/descent. This can be seen in the BFO values between 16.30 and 17:15 where the initial climb rate is in the BFO signal, then the level-off. If a descent rate of 13000'/min is put into the model at 00:19, I get -2Hz at the predicted BFO. But in that extreme situation how the compensation algorithm works is a matter of conjecture.

It works for the first few pings with the rate of climb established from the ADS-B data. By extension it seems to be active at all times. The Doppler due to an uncompensated aircraft velocity would be huge, which is not seen in the BFO data at any time.

1. There is a mode (it seems) where an aircraft satellite terminal uses a single channel continuously to monitor a pilot frequency from the satellite which has a known frequency. The measured offset is then an exact measure of the Doppler and the terminal can compensate precisely. However, this uses one of a limited number of channels the terminal has available, so the pre-compensation method was used on the terminal design in MH370. This is stated in the Inmarsat notes and an example terminal manual (see below).

2. As stated in the Inmarsat notes, it uses the average position of the satellite, not the exact position. This is adequate for the purpose of keeping the transmit frequency inside the legal limits, but not perfect.

3. Yes, as stated above. This is not documented but can be observed in the MH370 data.

4. The manual for an example Honeywell terminal says that the navigation data can come from the aircraft IRU or from a GPS system attached directly to the terminal. We don't know which applied to 9M-MRO.

SDIM MSC7200 23-20-35 rev 1

regards