Malaysian Airlines MH370 contact lost

[mm43]

Originally Posted by jimjim1

... 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.

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.

[mm43]

Originally Posted by Shadoko

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

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.

[jcjeant]

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

[RichardC10]

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.

[mm43]

@RichardC10

Thanks for giving that well thought out explanation.

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.

[Shadoko]

@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.

[RichardC10]

- 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)?

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.

- 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.

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.

[Shadoko]

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

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?

[RichardC10]

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?

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.

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?

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.

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

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

[Vinnie Boombatz]

Some Other On-Line Analyses

First, a big H/T to mm43 for setting up this thread.

One of the first posts on pprune on trying to replicate the earliest released INMARSAT data was by hamster3null on 28 Mar 2014 at 02:13:

http://www.pprune.org/rumours-news/5...ml#post8405984

He links to his own spreadsheet, very nicely organized, that calculates both aircraft and satellite Doppler at "ping" times along several hypothesized flight paths. He invites users to download spreadsheet and modify as desired.

At that time, hamster3null and many others of us were taking the INMARSAT graph to represent Doppler resulting purely from dividing line of sight rate by appropriate L-band wavelength (about 0.2 m). The trends were similar, but there was an obvious scaling problem.

Mike Exner has apparently explained and reconciled the burst frequency offset (BFO) data with the line of sight rates (see below).

An analysis by John Zweck, an Australian with a Ph.D. in mathematics, now teaching in the US:

https://www.siam.org/news/news.php?id=2151

Links to older Zweck material on MH370 on this page:

John Zweck

Zweck's updated spreadsheets and other analyses:

Aqqa on MH370

In the "Freq" worksheet in his latest 10 MB spreadsheet (http://www.aqqa.org/MH370/models/Dop...84_v6-6-9.xlsx), Zweck says he is using INMARSAT position data provided by Shadoko, and Dopper data derived from BFO data by Mike Exner (airlandseaman):

Background Information on the Pinging of MH370 by Inmarsat-3F1 | Duncan Steel

Exner links to other MH370 material on his Twitter account:

https://twitter.com/Airlandseaman

Michael Exner | LinkedIn

[Vinnie Boombatz]

Satellite Orbits

For those who want to calculate INMARSAT 3-F1 position and velocity themselves:

AGI markets a number of software packages that calculate satellite orbits

AGI Blog

You can download a free version of STK here (note that the free version doesn't have all the bells and whistles of the pay version, but still has a lot of utility):

AGI - software to model, analyze and visualize space, defense and intelligence systems

Dr. T.S. Kelso also provides freeware in several languages for use with two-line element sets (TLE), along with the TLE data.

CelesTrak: Satellite Tracking Software by T.S. Kelso

TLE format is described on this page:

CelesTrak: NORAD Two-Line Element Set Format

with more explanation here:

CelesTrak: "FAQs: Two-Line Element Set Format"

(I have never used Kelso's freeware, but have used his TLE data on occasion and converted it to use with other software and spreadsheets. He cautions strongly against using other than his recommended software. I take that to heart, but was too lazy to try to learn to use a new tool.)

Kelso posts a lot of useful information, such as this discussion of geosynchronous orbits:

CelesTrak: "Basics of the Geostationary Orbit"

TLE data for 7 Mar 2014 can be obtained from (registration required, but free):

https://www.space-track.org/

Here is their TLE data for 7 Mar 2014 (Day 66 of year 2014, or 14066):

1 23839U 96020A 14066.96754476 -.00000012 00000-0 10000-3 0 2640
2 23839 001.6371 073.1994 0005326 270.3614 234.8362 01.00274124 65669

[Shadoko]

Two line element (TLE)

If you want to use the two-line element (TLE) data provided above, you have to pay very high attention to the structure of the lines, at least if you use it with the TS Kelso software (I don't know about others).

Each line have to show 69 columns, and, unfortunately, this forum (as many others) automatically suppressed some spaces. I have copied the TLE above with spaces replaced by "s" for the first line where there have to be multiple spaces between some data (and in a courrier font where each digit or letter have the same width). There is no problem with the second line where there is no place with more than one space:

3F1-2014-03-07
1s23839Us96020Asss14066.96754476s-.00000012ss00000-0ss10000-3s0ss2640
2 23839 001.6371 073.1994 0005326 270.3614 234.8362 01.00274124 65669
Note the difference with (even if I did have inserted the right number of spaces):
1 23839U 96020A 14066.96754476 -.00000012 00000-0 10000-3 0 2640
2 23839 001.6371 073.1994 0005326 270.3614 234.8362 01.00274124 65669

With TS Kelso software TRACKSTAR.EXE, you have results even with the faulty lines (the software doesn't crash), but they are wrong.
For a TLE explanation (and needed stucture), see Two-line element set - Wikipedia, the free encyclopedia, with a scheme on French page and excellent Deutsh page for those who can read it...).

[Andrewgr2]

Insurance Payouts

BBC reporting that Malaysia Has started making payouts of $50,000 to families with potential payouts of $175,000. Details for UK users here BBC News - Malaysian plane MH370: families get $50,000 payments

[mm43]

Originally Posted by Gysbreght

If the earth is a perfect sphere, aircraft and satellite are at constant altitudes, and the satellite is at constant longitude, a relation can be derived between the theoretical BFO and speeds of airplane and satellite.

I assume you have created a spreadsheet to test this theory? If so, would you give a link to the file on some website, or dropBox, googleDocs etc..

Worth having a look at, though I have some concerns regarding the aircraft's actual heading as opposed to the aircraft/satellite vector on which the Doppler is relevant.

[Hyperveloce]

Originally Posted by Gysbreght

Hi mm43,
no, sorry, I have not made that spreadsheet yet and I doubt that it would be worth the effort. My intent was to get a qualitative understanding of the mechanism. We do not have sufficient data to allow a quantitative analysis based on the published BFO values. Looking at the BFO while the airplane was stationary indicates that the AES frequency bias and the GES AFC could be quite significant.

I don't understand why the available data do not allow a quantitative analysis of the BFO.

Even if we don't know the AES specific frequency bias and how the GES compensates for the D3 doppler shifts, if you model the BFO as

BFO = D1 + D2 + D3 + D1_AES + D3_GES + FreqBias _AES

where D1_AES is the D1 doppler estimated using a stationnary 3F1 satellite (above 64.5°E-0°N), FreqBias_AES is constant throughout the flight (neglecting the oscillators frequency drifts).

... you can still analyse the time serie BFO - (D1+D1_AES + D2) versus D3 and it will appear that the varied data points (the varied handshakes) are more or less scattered along a line, suggesting a simple linear regression (of BFO - (D1+D1_AES + D2) versus D3) enables to estimate:
- the FreqBias _AES (around 160 Hz) and
- a constant, partial compensation of D3 as D3_GES ~ -0.7*D3 (70 % of D3 compensated by the Perth GES) will do the job (replicating Inmarsat's predicted BFOs for north and south trajectories).

https://drive.google.com/file/d/0B3s...it?usp=sharing (for a south terminal leg at 470 kts)
https://drive.google.com/file/d/0B3s...it?usp=sharing (for a south terminal leg at 350kts, one of the trajectories is a north one)
These are the 10 000 simulated flights of a MonteCarlo simulation, the green plot is the closest flight to the BFO data (red), the blue-grey enveloppe gathers all the simulated flights around a reference trajectory. It seems that higher terminal speeds (470 kts versus 350 kts) allow a tighter fit to the data.

[Hyperveloce]

Originally Posted by Gysbreght

Hi Hyperveloce,
It is not entirely clear to me how your Monte Carlo simulation is set up. Some explanation would be helpful, in particular how you derive the AES frequency bias of 160 Hz and the GES partial compensation.

the varied trajectories are randomized versions of a mother/reference trajectory.
A trajectory is a timed sequence of speed, bearing, altitude changes (this timed sequence is the genom/DNA of a trajectory).
The gaussian randomization includes the timing itself of these speed, bearing and altitude changes.
I use the sigma values: 15 kts, 3°, 0 ft (no altitude randomization).
1000 flights are first generated through this randomization of a reference trajectory which in turn generate an offspring with a probability which is a function of their fit to both the measured angles of elev. & BFO values. After 5000 simulated flights, the randomization (mutations) goes hand in hand with crossing over the DNA of the best fit trajectories.

This process is independant from the BFO model I previously mentionned.

The frequency bias (a constant frequency specific to the AES) and the GES partial frequency compensation are estimated via a linear regression between the time series BFO - (D1+D1_AES+D2) and D3 (since there seems to be a linear relationship between the two). This suggests that the partial compensation implemented by the Perth GES can be a constant fraction of D3 (D3_GES ~ - 0.7 D3).

Originally Posted by Gysbreght

Can you do a similar analysis for the Pre-Takeoff period between 16:00Z and 16:30Z ?

I would have to modify my Inmarsat 3F1 motion model (to enable it to run before 16:30) but it's completely feasible.

Originally Posted by Gysbreght

Where is the airplane at the time of the first ping-arc at 18:28?

The 350 kts trajectory I used is roughtly the same as the lowest speed trajectory in the interim report (see the superposition here, the 350 kts trajectory is in green. It was leading in the vincinity of the area where the pinger was supposedly detected).
https://drive.google.com/file/d/0B3s...it?usp=sharing
So that at 18:28 the A/C is around 300 NM and 293° from Penang.

[susier]

Relatives have been given initial compensation

Malaysia Airlines: MH370 relatives get initial compensation | euronews, world news


However it is reported that some have refused any payments.

[mm43]

@ Gysbreght

Thanks for posting a spreadsheet. I'm currently going through it, and hopefully working towards getting a meaningful result from the final calibration point, i.e.

17:07:15 UTC 5°20.4'N 102°49.5'E 025°T 469 KTS GS FL350

The above position from FR24 is effectively the last reliable 'steady state' one. The average BFO around +/ 15 secs of the above time as reported by Inmarsat is 134.6 Hz (135).

[mm43]

@ Gysbreght

I happened to notice that you had changed the SS, so have had another look at the 17:07 calibration point I mentioned.

The result is:-

BFO 134.6 Hz
BFO bias 165.4 Hz
Vra -207.1 kt
Vya = -468.8 kt

Will look more closely into the AES fixed frequency offset.

[MountainBear]

Originally Posted by Shadoko
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

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

Is this a guess or has this actually been confirmed by a real world test?