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 |
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 |
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...). |
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
|
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.
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. |
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. 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. |
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. 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 ?
Originally Posted by Gysbreght
(Post 8521369)
Where is the airplane at the time of the first ping-arc at 18:28?
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. |
@ 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). |
@ 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. |
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 |
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. |
$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).
|
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: |
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". |
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... |
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. |
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. |
Originally Posted by Shadoko
(Post 8524814)
Could the published BTOs for T-Channel be computed in another way that R-Channel?
|
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.