PPRuNe Forums

PPRuNe Forums (https://www.pprune.org/)
-   Rumours & News (https://www.pprune.org/rumours-news-13/)
-   -   Malaysian Airlines MH370 contact lost (https://www.pprune.org/rumours-news/535538-malaysian-airlines-mh370-contact-lost.html)

Vinnie Boombatz 12th Jun 2014 19:40

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 12th Jun 2014 19:54

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 12th Jun 2014 22:54

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 13th Jun 2014 07:36

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 13th Jun 2014 23:36


Originally Posted by Gysbreght (Post 8520099)
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 14th Jun 2014 12:23


Originally Posted by Gysbreght (Post 8521116)
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 14th Jun 2014 14:36


Originally Posted by Gysbreght (Post 8521369)
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 (Post 8521369)
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 (Post 8521369)
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 14th Jun 2014 16:47

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 15th Jun 2014 03:57

@ 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 15th Jun 2014 22:10

@ 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 16th Jun 2014 05:29


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?

edmundronald 16th Jun 2014 09:02

About 50M to pay out for 239 passengers. Sounds like a bargain by western standards. Certainly not something that will hurt the bottom line of the insurers. I wonder whether the airline also gets a similar discount for the plane?

I feel really sad for the relatives, they got shoddy treatment from beginning to end, no hard information, no closure, laughable compensation. Let's hope their government doesn't retaliate in kind if something similar happens on their territory.

HeavyMetallist 16th Jun 2014 12:55

$50k is (as the title says) just an interim payment. The Montreal Convention limit is $175k, but unlimited if Malaysian can't prove it wasn't their fault (reverse burden of proof).

SAMPUBLIUS 17th Jun 2014 00:59

Inmarast confident in Hot spot
 
BBC News - Malaysian MH370: Inmarsat confident on crash 'hotspot'

The UK satellite company Inmarsat has told the BBC that the search for the missing Malaysia Airlines jet has yet to go to the area its scientists think is the plane's most likely crash site.

Inmarsat's communications with the aircraft are seen as the best clues to the whereabouts of Flight MH370.

The hunt for the lost jet is currently taking a short break while ships map the Indian Ocean floor.

When the search resumes, the Inmarsat "hotspot" will be a key focus.

But so too will a number of areas being fed into the investigation by other groups.

Australian authorities are expected to announce where these are shortly.

--- goes on . . .:cool:

Vinnie Boombatz 17th Jun 2014 02:10

INMARSAT Claim
 
BBC News - Malaysian MH370: Inmarsat confident on crash 'hotspot'

"The UK satellite company Inmarsat has told the BBC that the search for the missing Malaysia Airlines jet has yet to go to the area its scientists think is the plane's most likely crash site."

" the Ocean Shield ship never got to the Inmarsat hotspot because it picked up signals some distance away that it thought were coming from the jet's flight recorders."

"By modelling a flight with a constant speed and a constant heading consistent with the plane being flown by autopilot - the team found one flight path that lined up with all its data.

'We can identify a path that matches exactly with all those frequency measurements and with the timing measurements and lands on the final arc at a particular location, which then gives us a sort of a hotspot area on the final arc where we believe the most likely area is," said Mr Ashton."


The article doesn't provide coordinates of the alleged "hotspot".

Shadoko 17th Jun 2014 02:45

If the similitude is from a log-on, and you are probably right, why the first happened? The second have been associated with a possible flame-out and the start of the APU for a time long enough for the AES to come on line. But then, if the Satcom had been shut down sometimes after 17:07 (failed for any raison, or shut down to "fly in silence"?), what could have been the raison of the unit to go live again?

I understand from what happened later, that a "ping" was due around 08:07 (because the one hour timer). Was this "Log Control - Log-on Interrogation" (from the GES) canceled because there was no answer to other requests around 18:03? Or it is because someone tried to join the aircraft by the Satphone that THE "pings" happened?

Another consideration: from the graph below, one can see that the BTOs of R-Channel and T-Channel are, for each, very consistent, whatever unit is used:
http://i39.servimg.com/u/f39/14/14/01/64/btos_c10.jpg

And there is a ~5000 microseconds difference between them (4987 is the average of the BTO differences of each time the RX alternate between R and T along the timeline).
The BTO for T-Channel when the aircraft was in KL (9800 microseconds at 16:00:28) is too small for a signal could reach any point on a line below the satellite (at this time, it takes ~13560 microseconds for the light between KL and and a point at Earth surface below 3F1). Could the published BTOs for T-Channel be computed in another way that R-Channel?

OK, enough questions...

Propduffer 17th Jun 2014 02:51

I would love to know what speed they believe it flew at.

When I plot a track from POVUS to the area of the Ocean Shield search I come up with a ground speed of about 300kts.

Shadoko 17th Jun 2014 04:09

When the "Raw data" were published, there was also some maps with speeds indicated for each path. There is a copy of the different documents there:
https://drive.google.com/folderview?...kk&usp=sharing
The original doc was named "MH370 - Maps.pdf" and the only other info in the doc is the "name" of the author : UUU.

MG23 17th Jun 2014 04:30


Originally Posted by Shadoko (Post 8524814)
Could the published BTOs for T-Channel be computed in another way that R-Channel?

I think so. I believe the aircraft can transmit at any time on the R-channel, but is assigned specific timeslots on the T-channel (you can see T-channel assignment messages in the logs). So the logged offset is probably the offset from the assigned timeslot, and the logs presumably show the aircraft transmitting a few milliseconds before it was supposed to.

enjineerin 17th Jun 2014 04:51

R-Channel and T-Channel
 
The Inmarsat notes state that they only used the R-Channel BTO values. But, as you look through the Released Data, there and many many more data points that were ignored. If you plot all of the R-Channel BTO values, along with all of the (T-Channel BTO + 5000uSec), they line up extremely well.
With all of the data plotted on a chart you will also see the jitter, or noise, at each point in time is a spread of 60uSec to 80uSec with one especially noisy period with a spread of 120uSec (16:06-16:09UT sitting at the gate...). Keep that in mind when considering what resolution we should expect after converting signal latency to a ring, arc, or even a specific physical location.

The BTO numbers are offset (reference to the 'nominal terminal' in the notes). The key is simply to calibrate the measured time to the known location(s) at the gate (16:00-16:30 or even 16:41) and while ADS-B data is available (16:42-17:07UT). The BTO reflects the round trip time GES-satellite-AES, after subtracting the time to the nominal terminal location (GES-satellite-NomTerm).


{for those into the details, the 1st tricky part is that the earth is not round... So, converting from BTO to elevation angle and then to 'ping rings' gets complicated bu the true 'flattened' shape of the earth}

{The second tricky part is deciding where the 'real' satellite is used Vs. where the idealized fixed representation of the satellite is used... Because that affects the calculated elevation angle }
-Bill

<<edited to correct the sign in my equation above. - T-Channel BTO values are lower than R-Channel BTO by 5mS, so to align them, I should have written (T-Channel BTO + 5000uSec).>>


All times are GMT. The time now is 18:40.


Copyright © 2024 MH Sub I, LLC dba Internet Brands. All rights reserved. Use of this site indicates your consent to the Terms of Use.