Malaysian Airlines MH370 contact lost
Join Date: Jun 2009
Location: NNW of Antipodes
Age: 81
Posts: 1,330
Received 0 Likes
on
0 Posts
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.
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.
Join Date: Jun 2009
Location: NNW of Antipodes
Age: 81
Posts: 1,330
Received 0 Likes
on
0 Posts
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
Join Date: Aug 2009
Location: Germany
Age: 67
Posts: 1,777
Likes: 0
Received 0 Likes
on
0 Posts
That's a long and full discussion and many analyses on this blog ...
Duncan Steel | Space Scientist, Author & Broadcaster
Duncan Steel | Space Scientist, Author & Broadcaster
Join Date: Feb 2008
Location: UK
Posts: 66
Likes: 0
Received 0 Likes
on
0 Posts
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.
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.
Join Date: Jun 2009
Location: NNW of Antipodes
Age: 81
Posts: 1,330
Received 0 Likes
on
0 Posts
@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.
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.
Join Date: Oct 2007
Location: France
Posts: 136
Likes: 0
Received 0 Likes
on
0 Posts
@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.
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.
Join Date: Feb 2008
Location: UK
Posts: 66
Likes: 0
Received 0 Likes
on
0 Posts
- 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)?
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.
Join Date: Oct 2007
Location: France
Posts: 136
Likes: 0
Received 0 Likes
on
0 Posts
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?
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?
Join Date: Feb 2008
Location: UK
Posts: 66
Likes: 0
Received 0 Likes
on
0 Posts
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?
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:
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. 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?
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
Join Date: Mar 2014
Location: SW USA
Posts: 67
Likes: 0
Received 0 Likes
on
0 Posts
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
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
Join Date: Mar 2014
Location: SW USA
Posts: 67
Likes: 0
Received 0 Likes
on
0 Posts
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
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
Join Date: Oct 2007
Location: France
Posts: 136
Likes: 0
Received 0 Likes
on
0 Posts
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...).
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...).
Join Date: Jul 2008
Location: Only occasionally above FL50
Age: 71
Posts: 211
Likes: 0
Received 8 Likes
on
6 Posts
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
Join Date: Jun 2009
Location: NNW of Antipodes
Age: 81
Posts: 1,330
Received 0 Likes
on
0 Posts
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.
Join Date: Jun 2009
Location: in a plasma cocoon
Age: 53
Posts: 244
Likes: 0
Received 0 Likes
on
0 Posts
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.
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.
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.
Join Date: Jun 2009
Location: in a plasma cocoon
Age: 53
Posts: 244
Likes: 0
Received 0 Likes
on
0 Posts
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).
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.
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.
However it is reported that some have refused any payments.
Join Date: Jun 2009
Location: NNW of Antipodes
Age: 81
Posts: 1,330
Received 0 Likes
on
0 Posts
@ 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).
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).
Join Date: Jun 2009
Location: NNW of Antipodes
Age: 81
Posts: 1,330
Received 0 Likes
on
0 Posts
@ 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.
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.
Join Date: Jun 2010
Location: USA
Posts: 245
Likes: 0
Received 0 Likes
on
0 Posts
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
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