03.24.14
Understanding the “satellite ping” conclusion…
Over the last week a great deal of useful data has been accumulating in the comments section of my previous blog post on locating satellite pings from MH370 and I’ve greatly enjoyed all the input from many dedicated contributors across various fields of engineering and aviation. If you’re visiting for the first time then you might want to read my original primer on pings first.
In this post I’m going to try to distill this information and explain what we’ve been told today, since there is still plenty of confusion out there, and address one thing that we haven’t yet been told, but which should be able to be determined from the analysis that has been conducted. Note that the diagrams shown below aren’t mine – I’ve provided links to original sources in the supporting text.
Almost immediately after the plane disappeared, Inmarsat discovered that the satellite terminal on the plane had continued sending “pings” to the satellite every hour. This was in response to the Inmarsat network checking in with each terminal that it had not seen traffic from, in order to check that it was still connected to the network, just like the cellular network checks every so often that your phone is connected. In technical terms (from the Classic Aero specification), commenter GuardedDon described it well:
The ‘ping’ is a component of the Aero-L [or Aero-H] protocol where the GES [Inmarsat's Gateway Earth Station] attempts to check the ‘log-on’ state of previously logged on but apparently idle AES [the plane's Airborne Earth Station]. The GES determines the AES to be idle if a timer ‘tG6′ expires, tG6 is obviously the hourly period.
The GES transmits to the AES over the P channel & receives over the R channel. The initial response burst on the R channel is the timing datum transmitted by the AES ±300 ?s of receiving the incoming frame on the P channel. All very deterministic to give us the range to AES from satellite using the Round Trip Timing.
The delay can be measured fairly accurately, since as noted above, the timing is specified to within ±300 ?s. This calculation, from PPRUNE [Professional Pilots Rumor Network], shows that the difference in round trip delay between ping arcs 1 degree apart is around 600 ?s at the relevant angle for MH370. Thus the location of each arc is known to within 1 or 2 degrees, depending on whether the satellite actually measures the round trip or one way delay to the aircraft.
The arc information was released to the public on March 15 and there was some confusion at that point about why part of the arc close to Malaysia was excluded. Possibilities included:
1) that the area had been checked by radar
2) that the plane’s minimum speed would have meant it could not have been that close to Malaysia
3) that another Inmarsat satellite over the Pacific would have received the signals in this excluded part of the arc.
This issue has still not been clarified, but of these it appears that a combination of the first and second explanations is the most plausible.
Inmarsat measured the arc positions each hour from 2.11am to 8.11am and the possible routes taken by MH370 can be estimated by assuming that the plane was flying at a constant cruise speed, and then noting that the distance between the points at which the plane crossed each successive arc is equal to the distance the plane traveled in one hour. That led to the NTSB’s two potential tracks for the southern route, published by AMSA on March 18, which included two different assumptions for the speed at which the plane was flying.
Several news organization have published purported ping arcs for the intermediate ping times, including CNN and the Washington Post. However, its important to realize that these arcs are not based on real data, and are purely illustrative, like the chart produced by Scott Henderson.
What was not stated initially by Inmarsat or the investigators was that each of the hourly arcs is further away from the satellite than the previous one. In other words the plane was moving away from the satellite continuously from sometime soon after the 2.11am ping. This statement was made by Inmarsat on Friday (and I have also confirmed it). Once this sequence becomes clear, then it becomes impossible for the plane to have flown out over the Indian Ocean and later have returned to the vicinity of Malaysia. It also has significance for additional reasons that will be discussed below. As Jeff Wise noted, this means that the plane flew only between the green arc (the pink dot where it was at 2.11am) out towards the red arc where the last ping was recorded.
To be more precise, since Inmarsat has indicated that the plane was outside the green arc by 3.11am, the plane did not continue on its northwesterly course for long at all after contact was lost by Malaysian military radar at 2.22am (enabling it to return outside the green arc before the 3.11am ping). That would be consistent with avoiding Malaysian radar, but heading south the plane would have very likely crossed Indonesian radar coverage (something that the Indonesians have denied).
This sequence of ping arcs led inexorably to either a northern or a southern track, but there was still some uncertainty about which one was correct. The analysis that Inmarsat undertook over the last week took into account that the I3F1 satellite is in a slightly inclined orbit, which moves north and south of the equator each day. In other words it is only station-kept in the east-west direction, not north-south. While this situation is often the case for old FSS satellites, where the fuel is nearly exhausted, even new MSS geostationary satellites do not use strict north-south stationkeeping because the beam width of a small L-band antenna is pretty wide and so accurate pointing is not required.
DuncanSteel noted that the satellite was actually north of the equator at the time in question and Inmarsat was able to use the fact that the satellite was moving relative to the aircraft to calculate the resulting Doppler effect that shifted the frequency of the ping as measured at the satellite. If the satellite was moving towards the south, then the frequency of pings from airplanes flying in the southern hemisphere would be shifted up in frequency, while the frequency of pings from airplanes in the northern hemisphere would be shifted slightly down in frequency.
Last week Inmarsat performed an analysis of pings received from other aircraft flying in the Indian Ocean region to confirm that this effect is consistent across all of these planes and therefore concluded that MH370 must have been to the south of the satellite at the time of the last ping, not to its north. This led up to today’s announcement that the plane must have crashed in the Southern Ocean.
Now for an interesting piece of information that does not appear to have been considered in detail. A pilot on PPRUNE pointed out that there are two different modes of operation of the 777 flight management computer. A programmed route will take a straight line (great circle) route to the next programmed waypoint, but if there is no longer any waypoint in the computer, then the plane will fly on a magnetic bearing. While this is not material around Malaysia, it becomes highly significant in the Southern Ocean.
As a result, a magnetic heading would need to start out going significantly further west (and would also fly much further) to end up at the same point as a great circle route.
It is easy to see that in combination with Jeff Wise’s chart of the ping lines, a magnetic bearing heading is highly unlikely to have resulted in the 3.11am ping arc lying outside the 2.11am ping arc. Once this is realized, the hypothesis that the plane suffered an accident that left it flying on autopilot becomes rather less likely than the plane being deliberately directed towards a part of the southern ocean where presumably whoever was in charge believed the aircraft would never be found.
Indeed the NTSB tracks appear to implicitly assume an absolute not a magnetic heading, so would require the plane to be flying in a pre-programmed direction. Of course we need to see the ping arcs themselves (or at least get absolute confirmation about the trend in the ping arcs) before reaching a definitive conclusion, but this issue appears quite significant for any assessment of what might have happened onboard MH370.
UPDATE (Mar25): The Malaysia government has just released this full picture of the potential southern route tracks. The red track appears to be a magnetic bearing heading which would have required a slower speed (400 knots) and would result in a location far to the northeast of previous estimates. The yellow track is apparently the originally assumed programmed heading at cruising speed of 450 knots and is consistent with the current search area. There is clearly an enormous difference in where the plane ended up.
UPDATE (Mar25): The Doppler shift data release by the Malaysian government gives full details of the ping times (note that they are in UTC so add 8 hours for local Malaysian time which is used above). Several pings were received at just before 2.30am, then at 3.40am, 4.40am, 5.40am, 6.40am and 8.11am, not at 2.11am, 3.11am, etc as surmised above.
It seems clear from the Doppler information that the plane made a sharp turn very shortly after it was lost from Malaysian radar coverage at 2.22am. There is also much more time for the plane to move outside the 2.30am arc by 3.40am so this does not impose as much of a constraint on the possible routes of the plane.
The question has been raised about the apparent “partial” ping shortly after the 8.11am ping was recorded. Was that a partial ping because the plane lost power during the course of that handshake? Its hard to tell, but I note that there were several pings quite close together around 2.30am after the “possible turn”. Those appear to have occurred for a different reason than the regular pings (and also from the more frequent earlier handshakes after take off which I assume relate to regular ACARS messages being transferred).
So an understanding of why those occurred is likely to shed some light on why a ping might have been attempted so soon after 8.11am. In particular, could it have been initiated from the plane’s terminal rather than the satellite network? And if so why – for example, could it be due to the plane’s terminal trying to re-establish contact with the satellite after a sharp change in direction?
Alex Siew said,
March 24, 2014 at 10:45 pm
Has anyone considered the theory that the plane was struck by lightning. There was a report on PPRUNE post 120 page 6 by a pilot flying westbound to southern vietnam passing MOXON at 1.20am that “it was a beautiful NE monsoon night, though there was some limited scattered lightning visible way off to the SW” which would be the region MH370 was flying through.
MH370 went off radars at around 1.20am. Lightning strikes in clear skies and in higher altitudes could point to “positive lightning”, with such strikes reportedly up to 10 times more powerful than the much more common “negative lightning” strikes. According to Wikipedia “At the present time, aircraft are not designed to withstand such [positive lightning] strikes since their existence was unknown at the time standards were set….” .
It was also reported that a pilot on another MH plane flying 30 minutes ahead bound for Narita (MH88?) managed to establish emergency radio contact with MH370 and this other pilot heard a lot of static and interference as well as “mumbling” from who he thought was the co pilot of MH370 [New Straits Times March 9, 2014].
The static, interference and difficulty in establishing radio contact are consistent with MH370 having been struck by lightning, as lightning would cause electro magnetization of radio waves.
Such a lightning strike would cause also electrical failure, which would explain why the transponder stopped transmitting at around 1.20am.
If this theory is correct, the plane would have crashed at the South China Sea, south or south east of Vietnam.
The arc calculated from the final ping crosses the South China Sea south east of Vietnam. No one has explained why this portion of the arc is being excluded from the search.
The plane went off radars at 1.20am near IGARI. There is no evidence to show the plane crossed peninsular Malaysia. If the final arc is correct, it would mean the other 6 arcs would be between IGARI and the final arc,inclusive. So far Inmarsat has declined to disclose the data for the other 6 arcs or measurements for the RT timings.
Could it be that the 6 arcs are more or less the same as the final arcs, or within the margins possibly caused by the movement of the satellite or changing signal latency due to changing atmospheric conditions? If so, it could mean the 7 pings were transmitted from around the same location ie the plane had crashed by the time of the first or second ping.
Could the plane have emitted the 7 pings if it had crashed from the outset? It could have, if the satellite terminal on board had UPS (Uninterruptible Power Supply) ie battery backup arrangement, and the antenna on top of the plane remained above water for a period of time.
Alex Siew
duncansteel said,
March 24, 2014 at 10:46 pm
Does anyone have an ORIGINAL set of putative aircraft tracks from the NTSB and the ping rings on which they are based? The reason I ask is this. The graphic in the Washington Post that gives these tracks…
http://www.washingtonpost.com/national/health-science/satellite-locates-malaysian-flight-370-still-flying-seven-hours-after-takeoff/2014/03/15/96627a24-ac86-11e3-a06a-e3230a43d6cb_graphic.html
… has ping rings for different times that (a) Are concentric [which they should not be because the satellite shifts]; and (b) Are apparently centred on a sub-satellite point at close to 2 deg SOUTH and 56 deg East; whereas the satellite was, across the duration of the flight of MH370, both north of the equator and at close to longitude 64.5 deg East (not the 56 where it appears in that graphic).
This may be simply a result of poor drafting at the Washington Post; or it might be a stuff-up by the NTSB, which has resulted in all the searches in the Indian Ocean being in the wrong area.
So, to repeat: does anyone have the predicted aircraft tracks directly from the NTSB?
Thanks,
Duncan Steel
duncansteel.com
GuardedDon said,
March 25, 2014 at 12:47 am
I understand that the AFDS uses a gyrocompass so that its nav is independent of the earth’s magnetic field. The HDG SEL input has a NORM or TRUE option, typically used for over pole flight.
Back to question I posed to qualify my thoughts: is doppler shift part of the telemetry from the sat?
Representations of the MH370 Ping Rings in the Media | Duncan Steel said,
March 25, 2014 at 3:07 am
[...] The following graphic/map was published by the Washington Post on March 15th. It contains various errors. (For completeness I should also say that various other media sources have shown similar graphics that are somewhat misleading, for example CNN. These should be considered as being “purely illustrative???.) [...]
Nullhyp said,
March 25, 2014 at 3:11 am
What was the wind speed and direction for this corridor at the expected flight altitude, March 8? I understand there is a strong SE trade wind year round for most of the route.
Fitzcarraldo said,
March 25, 2014 at 3:17 am
@ duncansteel (your post March 24, 2014 at 10:46 pm)
Nobody has the original set of hourly arcs. They were never published, which was hugely frustrating for many of us. After a lot of discussion in the comments section of Tim Farrar’s preceding blog post (03.17.14 Locating “satellite pings???…), it appears the 7:11, 6:11 and 5:11 arcs on the Washington Post graphic were schematic/illustrative only and were not in the correct position.
You were correct about the first Inmarsat analysis (the graphic released by the Malaysian government on 15 March showed 3F1 on the Equator), but in the latest analysis, which showed the aircraft must have flown south, not north, Inmarsat did take the changing position of the satellite into account. Apparently that was part of the reason why they were able to conclude the plane flew south, not north. Below is a quote from the following newspaper article by the Daily Telegraph (UK) on 24 March:
http://www.telegraph.co.uk/news/worldnews/asia/malaysia/10720009/MH370-Britain-finds-itself-at-centre-of-blame-game-over-crucial-delays.html
“On March 19, Malaysia Airlines told SITA to use the AAIB as the main analyst of the Inmarsat data. The AAIB, part of the Department for Transport, passed on its own interpretation to Malaysia, but it was not until Sunday, March 23 that a further calculation by Inmarsat convinced the Malaysians of the aircraft’s whereabouts.
Analysts realised that their calculations had not taken into account the geostationary satellite’s very slight movements in relation to the earth. Once that was factored in, the northern corridor was ruled out completely. The calculations were sent off to be checked over the weekend before being passed to Malaysia on Sunday.???
duncansteel said,
March 25, 2014 at 3:53 am
One statement, one question…
I have put up another post on my website (duncansteel.com) with regard to the precision of the various graphics that have appeared in the media showing ping arcs and the range of possible routes depicted in maps from AMSA, apparently based on information from the NTSB. It turns out that the media graphics seem good in some respects (e.g. the locations of those possible routes) but not in others (the Washington Post graphic puts the satellite 2 deg SOUTH of the equator when in fact it was north of the equator throughout the flight of MH370; but an even larger error is that the WP graphic puts the sub-satellite point at about 56 deg East rather than the nominal 64.5 deg East, an error of over eight degrees).
Now my question. Has anyone considered how the real curvature of the Earth must affect the curvature of the ping arcs? The point is this. (For simplicity, let me assume that the satellite is truly geostationary and not drifting during the times of the aircraft flight.) The ping time delays (whatever their values might be) give a range to the aircraft, which can be drawn as a curve across the Earth, presumably at an altitude around 35,000 feet above MSL (which is what I have used). Simple geometry can be used to turn that derived range (from satellite to aircraft) into an angle: I have thought of it as being an elevation angle from the aircraft to the satellite, others in terms of the angle between the downward vertical from the satellite and the direction of the aircraft. But, but, but… One can calculate that angle if one assumes (say) that the aircraft were above the equator and so at a distance from Earth’s centre of 6,378.137 km plus 35,000 feet (i.e. Earth’s equatorial radius plus aircraft altitude), from the geometry given that one also knows the satellite altitude. That renders some angle, let me call it alpha=40 degrees (precisely). However, as you move away from the equator the Earth’s radius (at any latitude) reduces. For an identical range (identical time delay) this has the effect of INCREASING the calculated angle alpha, so it becomes greater than 40 degrees. (As I have written previously, the ping arcs cannot be circles, because the Earth is not spherical.) What this implies is that ALL graphics showing ping arcs as ‘equal angle’ arcs are flawed.
An implication of this is as follows. As the arc (for any particular ping time delay) moves away from the equator its angle alpha increases, and the curvature of the arc then increases. Looking at the way in which the NTSB derived the ‘possible routes’ this would mean that, if Earth’s curvature were not accommodated (which is a good guess given the ping curves have widely been mis-labelled as equal-angle circles), the path taken by MH370 would be further west than indicated by the NTSB routes, and so the search areas covered so far (and planned) are too far east.
My question: does anyone know if this (effect of non-spherical Earth) has indeed been accommodated in the ping time delay analysis?
Cheers,
Duncan Steel
weedenbc said,
March 25, 2014 at 5:10 am
The Malaysian government has been sending reporters a much more detailed explanation of how the calculation was done. A copy of their explanation is posted here (minus some of the graphics they provided):
http://www.themalaymailonline.com/what-you-think/article/information-provided-to-mh370-investigation-by-uk-aaib
It confirms that the initial arcs were derived from the time it took the aircraft to respond to the pings from the ground system, and that the Doppler shift enabled them to calculate the burst frequency offset which is what ruled out the northern route. These calculations and predictions were tested against 6 other B777s flying that same day “in various directions”
It also says that they used ACARS communications with the plane while it was on the ground and during the early stages of the flight to calibrate the calculations.
However, the posting does raise one loose end. Apparently there was an attempted ping from MH370 at 0019 UTC that was not part of these hourly handshakes and is currently unexplained.
jimcarrier said,
March 25, 2014 at 5:34 am
As a layman journalist (and calculus dropout) interested in the history of navigation, I find it noteworthy that the conclusion of MH370 was written using three of the oldest forms of navigation. 1) distance = time x speed (the circles), 2) dead reckoning (NTSB), and 3) the Doppler effect (the southern route)
Regarding 3) it was two physicists at the Johns Hopkins’ Applied Physics Lab in Maryland, George Weiffenbach and Bill Guier, who noted the Doppler effect of Sputnuk in 1957. They were soon able to predict the time and path of Sputnik’s 96-minute orbit. Six months later, their boss, Frank McClure, asked them if they could invert the data from a known orbit to find the position of the lab. They figured it out in two days, with an accuracy of one-tenth of a mile. The lab won a Navy contract to build Doppler-tone satellites to communicate with Polaris submarines. The first handmade satellites, launched in 1959, formed the Transit system, the first step toward satellite navigation. (From my little eBook HERE WE ARE: The History, Meaning and Magic of GPS.)
Thank you all for showing the way.
Jim Carrier
Hans said,
March 25, 2014 at 6:19 am
https://www.facebook.com/permalink.php?story_fbid=740971779281171&id=178566888854999&stream_ref=10
The Malaysian governments facebookpage contains some graphics supporting their new conclusions.
Including a burst frequency offset for all the handshakes, in a graph compared to possible the north and south corridor.
meadows.st said,
March 25, 2014 at 7:00 am
Thanks for the link Hans.
Apparently the burst frequency offset was only between 100 & 300 Hz. The southern route is indeed an incredibly good fit to the measurements.
GuardedDon said,
March 25, 2014 at 7:59 am
So the ‘burst frequency offset’ relates to the doppler diff on the initial phase of the ‘R’ channel response, a unmodulated burst of the carrier freq (from the AMS doc). If so, it’s positive at all times. As Chris McLaughlin said, it was always travelling away from the satellite. Pity they didn’t release the associated propogation delays for each msg. Not that it changes the outcome for final location but could that ‘turn back’ have been to starboard not port? Therefore, one turn south from the middle of Gulf of Thailand. Haven’t got time this afternoon to try that.
Fitzcarraldo said,
March 25, 2014 at 8:15 am
@ timfarrar
I have always favoured the hypothesis of a southern rather than a northern route. However, I am still struggling to understand what that precise route southern route actually was.
You have posted a schematic diagram by Jeff Wise, and a Google Earth image by a PPRUNE poster (Capt Kremin). Here again is the link to a Google Earth image I posted in a comment (March 23, 2014 at 11:09 pm) on your previous blog post:
http://i2.photobucket.com/albums/y9/imageuser/circle_for_2h22_with_3F1_at_correct_coords.jpg
The circle shown has its centre at the position of Inmarsat 3-F1 as given to me by Duncan Steel in his comment on March 23, 2014 at 9:58 pm in your previous blog post:
Time Lat (deg) Long (deg) Alt (km)
2014/03/07 18:22:00.000 UTC 1.556 64.532 35806.4
The circumference passes through the last recorded location of MH370 by the Malaysian military at 02:22 MYT, 200 nm from Butterworth Air Base on a bearing 295 degrees (indicated by the red line of length 200 nm). As shown on the Malaysian government’s slide in Beijing on 21 March, that final recorded location was close to the MEKAR waypoint.
Now, one thing I have learned over the last few days is that Google Earth is inaccurate (it represents the Earth as a perfect sphere). For example, the Malaysian government’s 200 nm vector plotted on SkyVector shows the last recorded position a little further west than Google Earth does. So I have replotted the 02:22 circle on Google Earth but adjusted the radius so that the circle traverses Sumatra more realistically visually:
http://i2.photobucket.com/albums/y9/imageuser/circle_for_2h22_adjusted_to_cut_Sumatra_at_correct_location.jpg
(The three placemarks in the south Indian Ocean are three of the locations where debris was found.)
Given Jeff Wise’s quote of an Inmarsat spokesman, MH370 was not inside the 2:11 circle at 3:11, nor at 4:11, nor at 5:11, … nor at 8:11. In which case it was not inside the 2:22 circle at those precise times either, because the 2:22 circle lies to the west of the aircraft’s position at 2:11. To reiterate, at 2:11, at 3:11, at 4:11, at 5:11, at 6:11, at 7:11 and at 8:11 the aircraft must have been outside the circle shown on the Google Earth image I am posting now. Do you agree with that conclusion?
The routes in the Malaysian MOT image ‘Example Southern Tracks’ published on 25 March do not fall exclusively outside the 2:22 circle. If at precisely 03:11 (and 04:11, 05:11 etc.) the aircraft on those postulated routes would be inside the 2:22 circle then those routes cannot be entirely correct. To fall outside the 2:22 circle at precisely 3:11, 4:11, 5:11, 6:11 and 7:11, the route flown must have curved further eastward initially.
To recap, please compare this image:
https://fbcdn-sphotos-e-a.akamaihd.net/hphotos-ak-ash3/t1.0-9/1525257_740971732614509_298214666_n.png
with this image:
http://i2.photobucket.com/albums/y9/imageuser/circle_for_2h22_adjusted_to_cut_Sumatra_at_correct_location.jpg
Having said all that, the aircraft was flying westwards when the Malaysian government lost track of it at 2:22 MYT (cf. the slide shown in Beijing on 21 March), so common sense would dictate a route more to the west initially, as portrayed in the Malaysian MOT image. But the analysis, predicated on the statement by an Inmarsat spokesman that ““the ping timings got longer??? don’t appear to support that. It is this that I’m struggling with, even though I am sure the aircraft ended up in the south Indian Ocean.
A more-accurate virtual globe than Google Earth is needed to plot the 2:22 circle together with the various routes postulated by PPRUNE poster Capt Kremin (your post refers) and the routes postulated by the Malaysian MOT, to show whether, at precisely 3:11 (and 4:11 etc.), the aircraft would likely have been outside the circle assuming feasible air speed since 2:22 MYT.
Once (if) MH370 wreckage is found (fragments on the surface or sea bed, or the ‘black box’) many people may think the precise route is a moot point. However, I think it is still useful to try and establish more accurately the route, especially in the first hour after contact was lost.
meadows.st said,
March 25, 2014 at 8:39 am
@Fitzcarraldo
I think your visuals are great.
I have one point on your conclusion of the 2:22 location and the 2:11 vs 3:11 inside/outside arc conclusion as follows, 2:22 location could be inside 2:11 “ping arc contour” and the 3:11 ping arc contour could still be outside the 2:11 contour due to another turn (which we have always postulated had to happen for the Southern route to be correct). In short, MH370 was flying west, then performed a turn to port of >90 degrees and continued to fly East of South until it was back outside the 2:11 ping arc contour.
meadows.st said,
March 25, 2014 at 8:53 am
@timfarrar and @Duncansteel
I agree with @Fitzcarraldo that refining the possible flight path is advantageous so I have a few more points on which I would like everyone’s feedback (In part I am synthesizing a number of points made in this thread and the previous one and trying to summarize them here).
1) I am lead to believe that the Doppler shift model assumed a steady throttle position (I am postulating that this is one of the pieces of information they validated with Boeing) and type of automatic heading (I agree that the magnetic heading is unlikely given the data so far but I think one would have to test the two likely possibilities of mag heading and absolute (true) heading). Would it be possible to integrate a wind speed model and a more precise motion/instantaneous speed model of 3F1 to refine the relative direction that MH370 would have been flying at the time of the ping to refine the predicted model (and get it even closer to the measured positions)?
2) Could some more plausible flight paths in the hour between 2:11 and 3:11 be made using the 2:22 radar “fix” at 200nm NW of BWH and the 2:11 ping arc contour and the 3:11 ping arc contour that might refine the possible flight paths and allow better fit to the measured data (and a better estimate of the impact/alightment point (with introduced errors, it is )?
3) using 1 and 2 above, could the wind and wave model from the impact point/region allow calculation of a higher probability search region?
Regards,
Steve
Fitzcarraldo said,
March 25, 2014 at 10:04 am
@ meadows.st (your post of March 25, 2014 at 8:39 am)
Thank you for the complement regarding the Google Earth visualisations. I wish Google Earth was a more-accurate virtual Earth.
Regarding your comment:
“2:22 location could be inside 2:11 “ping arc contour??? and the 3:11 ping arc contour could still be outside the 2:11 contour due to another turn (which we have always postulated had to happen for the Southern route to be correct). In short, MH370 was flying west, then performed a turn to port of >90 degrees and continued to fly East of South until it was back outside the 2:11 ping arc contour.”
I of course know that would be possible in principle, but its feasibility in practice depends on the distances, aircraft speed and direction. It is this that I am trying to convey by showing the 2:22 circle on the Google Earth image. For example, the routes (‘tracks’) on the Malaysian MOT graphic seem to indicate the aircraft was still inside the 2:22 circle at precisely 3:11 if one assumes the stated speeds, but it’s difficult to tell from the low-quality MOT graphic and the imprecision of Google Earth. It would be useful to see a marker at each hourly interval (2:11, 3:11, 4:11, … 8:11) on those two MOT ‘tracks’, as they would all have to fall outside the 2:22 circle, given the Inmarsat spokesman’s statement that all ‘pings’ were further away from the satellite.
meadows.st said,
March 25, 2014 at 10:54 am
@Fitzcarraldo,
I agree that there are problems with the hypothesis of a drastic turn. I don’t think any of these problems are beyond the point of possible if we assume that MH370 overflew Indonesia.
To summarize my thoughts on the uncertainty of these data points/assumptions:
1) The 200nm at bearing 295 from BWH at 2:22 MYT may not be accurate either in terms of time (could be 2:15), distance or bearing (KeithLedgerwood was not particularly fond of the radar contacts displayed in the relevant photo (posted by Tim in this article)
2) The “all pings were outside the 2:11 ping” is not very precise and could mean that 3:11 was only outside the 2:11 ping contour by a degree or two?
3) The turn could have been quite sharp (but then why is there no further radar contact from Pulau?)
4) There is a lot of speculation that Indonesian radar coverage/management in the relevant area(s) is “less than ideal” so an overflight is possible but still suspect.
5) and finally, (to demonstrate my firm grasp of the obvious), we have no real data on the ping contours at any time.
ksgoodwin@gmail.com said,
March 25, 2014 at 11:46 am
I still question the extreme southern route. Still thinking of the Maldives eyewitness sighting of a low flying plane headed South East at 6:15 am. Question: As noted above “The GES transmits to the AES over the P channel & receives over the R channel.” Are there signal enhancement circuitry on either GES or AES that would enhance but subsequently cause a delay in either the down to a/p or up to the satellite signal transmission if the signal is weaker than expected due to the old style antenna(e.g. Stick antenna on MH370)? The eyewitness of the airplane heading South East would fit the doppler difference in the 8.11 ping. I am running out of logic to support Maldive. Note: I worked on the 777 & 787, worked on the FETS, (Flight Emulation Test System) that drives the airplane systems to ensure they perform as expected, worked on time of flight measurement systems (circuit delays can be an issue). Just thinking…………
GuardedDon said,
March 25, 2014 at 12:38 pm
@ksgoodwin
The spec for the system is very explicit, the response has to be initiated within the stated window: +/- 300usec. The Aero-L service was designed with the low gain antenna in mind.
@meadows.st
Are you suggesting the course change over the Gulf of Thailand was to the south, not west, and hence the aircraft tracked back across the Malaysian Peninsula and Sumatra? Obviously, that has implications for what was or wasn’t seen on military primary radar.
meadows.st said,
March 25, 2014 at 1:13 pm
@GuardedDon
No, I am just saying that MH370 would have had to turn to port from a heading of ~290 to a heading of <180 for about 45 minutes until around 3:11 then head south. See: this hypothetical flight path to illustrate what I mean.
This hypothetical flight path would take the aircraft over the island East of Banda Aceh and then slightly further East over the next 40 minutes until the heading becomes mostly southern. This conjecture would keep the 3:11 and later ping contours outside the 2:11 ping contour (even if just slightly for 3:11 and 4:11 and keep the distances within the 495kn cruising speed.
XocoLatte said,
March 25, 2014 at 2:11 pm
I was fascinated by the professionality of both the content and tone of this dispute. I also read through Jeff Wise’s post and its comments just to find a very troubling post by some user called airlandseaman who referred to the AAIB report given to the Malay goverment. I am sorry if this is not welcomed here but still I feel an urge to paraphrase:
airlandseaman
Posted March 25, 2014 at 12:37 PM
“It looks like all the “hourly ping??? reports were another urban myth. Here’s what AAIB reported to the MH370 Investigation team.
1. 00:30 ACARS Message
2. 00:43 ACARS Message
3. 00:55 ACARS Message
4. 01:07 ACARS Message
5. GAP in ACARS and Handshakes
6. 02:25 ACARS Message?
7. 02:27 ACARS Message?
8. 02:29 ACARS Message?
9. GAP > 1 hour in ACARS and Handshakes
10. 03:40 First Handshake Ping
11. 04:40 Second Handshake Ping
12. 05:40 Third Handshake Ping
13. 06:40 Fourth Handshake Ping
14. GAP >1 hour in ACARS and Handshakes
15. 08:11 Final Ping (or partial transmission?)
Note: There have been many conflicting reports about whether RR received engine data after 01:07. Engine data is reported via ACARS, not Pings. The new time line above raises the question: Were the 3 closely spaced transmissions just prior to 02:30 the last ACARS messages, containing some engine data?”
I believe ALL reports, calculations and charts/graphs have been based on the hourly handshake pings occuring at exactly 11 minutes after the hour. It looks as if this was just all bollocks?
I would really like to hear an explanation from Inmarsat or AAIB….
XocoLatte said,
March 25, 2014 at 2:14 pm
Oh, I forgot to add to the above the link to the post quoted:
http://jeffwise.net/2014/03/22/why-we-now-understand-the-missing-malaysian-airliners-flight-route/comment-page-4/#comments
meadows.st said,
March 25, 2014 at 2:39 pm
@XocoLatte
The timelines you just posted correspond better to the times posted on the Doppler shift analysis chart that was posted Mar 25. I wondered why the “pings” did not line up to 11 minutes after the hour like most of our assumptions in this thread have held.
GuardedDon said,
March 25, 2014 at 2:59 pm
@XocoLatte
I’m somewhat perplexed(?) by the timings of the msgs indicated on the Burst Frequency Offset Analysis graph released by the Ministry of Transport Malaysia (MoTM).
http://bit.ly/1dsMWgH
I don’t believe the hourly ‘pings’ are an urban myth, Tim linked the doc that describes the protocol & it clearly describes an inactivity timer that, on expiration, initiates the log-in check to the AES terminal. I also alludes to doppler shift determination & compensation within the AES terminal.
There ARE four msgs spaced at the hour intervals (approx 40 minute past) the penultimate four, while the last is timed at 00:11 UTC – I’d accept that the timings might reset at 00:00 UTC, it’s an arbitary check anyway.
The graph would have been better illustrated as a simple bar chart, the offset at each sample (msg) point isn’t necessarily linked to offset at the next.
That leaves the timing of the “possible turn” that’s coincident with the 3 closely spaced msgs plus the gaps, greater than an hour, each side. I hesitate to speculate what’s going on there, I have an idea but I’m not prepared to voice it yet. I haven’t read any other analysis yet.
It would be much clearer if MoTM would simply publish the co-ordinates that have now been established using Inmarsat’s analysis at the instance of each message.
So, I believe those commenting and posting here are on the right path. If MoTM posted the co-ordinates determined for each msg then the chapter describing the path 9M-MRO followed to the southern Indian Ocean would be closed. Why, of course, would still remain until the FDR is recovered.
meadows.st said,
March 25, 2014 at 3:10 pm
@XocoLatte
I have added comments based on the messages you posted above after looking at the freq offset analysis (ping.png file linked above). I believe that if the offsets have the same sign then the relative velocities are either all away from the sat or all towards the sat (We know the first phase of flight is away from the sat so we have to assume that all the relative velocities as calculated from the freq offsets are all away from the sat). For the delta between one offset and the next to be greater then the relative velocity was more radially away from the satellite (or the relative velocity increased in some other way – plane increased its speed or had a tail wind, etc.). If we assume that after 03:40, the aircraft was on a constant heading and at constant power (throttle position was fixed) then the plotted frequency offsets seem to be reasonable (see below for details). From the assumed heading between IGARI and VAMPI, there is a small component of the vector that is away from the sat.
1. 00:30 ACARS Message
2. 00:43 ACARS Message – frequency offset delta increase -> increase in component away from Sat
3. 00:55 ACARS Message – frequency offset delta increase -> increase in component away from Sat
4. 01:07 ACARS Message – freq offset delta decrease -> decrease in component away from sat (thus turn to port had already happened or was in the process of happening)
5. GAP in ACARS and Handshakes –
6. 02:25 ACARS Message? – right around the last posted Radar return plot – freq offset delta much larger so aircraft should be moving away more quickly from satellite (@Duncansteel’s posted position for 3F1 shows it moving north between 17:00 UTC and 18:00 UTC but there should still be a relative component of velocity away from sat)
7. 02:27 ACARS Message? – freq offset delta decreasing -> moving more slowly away from sat
8. 02:29 ACARS Message? – freq offset delta decreasing -> moving more slowly away from sat
9. GAP > 1 hour in ACARS and Handshakes – freq offset delta decreased from 02:29 -> moving more slowly away from sat
10. 03:40 First Handshake Ping – freq offset delta increasing -> moving more quickly away from sat. *** Start of nearly linear increases in freq offset
11. 04:40 Second Handshake Ping – freq offset delta increasing -> moving more quickly away from sat.
12. 05:40 Third Handshake Ping – freq offset delta increasing -> moving more quickly away from sat.
13. 06:40 Fourth Handshake Ping – freq offset delta increasing -> moving more quickly away from sat.
14. GAP >1 hour in ACARS and Handshakes
15. 08:11 Final Ping (or partial transmission?) – freq offset delta increasing -> moving more quickly away from sat.
The very close match between the predicted (South track) and the measured values is remarkable.
meadows.st said,
March 25, 2014 at 3:29 pm
NOTE: when I write “moving more quickly away” I mean I have chosen the sat as the frame of reference and there will be a tangential component and a radial component therefore, if the radial component of the velocity is away from the sat, the value is positive and “more quickly” = larger scalar value but still pointed away from the sat, “more slowly” means the scalar value of the radial component is smaller.
GuardedDon said,
March 25, 2014 at 3:34 pm
@meadows.st
The last complete handshake at 00:11 UTC was, I believe, the only one openly discussed by the investigation – any extrapolation back to earlier ones was conjecture based on graphics presented in the press that were attributed to NTSB information. We can be sure the NTSB will have been giving Inmarsat’s findings credence from the outset. Neither was the conjecture detrimental.
I’m quite satisfied that inactivity on that data link should result in a ‘log-in’ interrogation, the commonly termed ‘ping’. The inactivity period leading to the interrogation is defined in the spec (para 4.10..4.3.4 and 4.10.4.3.4.2 and pg 239/Appdx A).
Inmarsat has taken 2 weeks to validate their findings, the Malaysians if’ed and but’ed over the military radar tracks in the first week – could there be a conflict now over the initial flight path prior to 9M-MRO getting out over the Indian Ocean? That doesn’t affect the outcome (assured by msg at 00:11 UTC) but it sure puts the first week of MoTM communications and disaster management in disarray.
meadows.st said,
March 25, 2014 at 3:44 pm
@GuardedDon said, March 25, 2014 at 3:34 pm “The last complete handshake at 00:11 UTC was, I believe, the only one openly discussed by the investigation…”
I agree. I didn’t mean to imply anything negative by my comment. What I meant was “Yay! Actual data!” – although I have not confirmed the source other than to compare the times with the Ping.png file plot which lines up perfectly with the timeframe referenced by @XocoLatte.
Fitzcarraldo said,
March 25, 2014 at 3:57 pm
@ XocoLatte
Thank you for posting. Very interesting. Frustrating, actually!
@ meadows.st
Thank you for pointing out the times on the graph released on 25 March by the Malaysian MOT (‘MH370 measured data against predicted tracks’). The twelve event times listed by XocoLatte appear to correspond exactly to the event times on the graph, not just ‘better’.
Well, here we are with yet another twist to the story. An hourly ‘ping’, the last one at 08:11 MYT, could, I suppose have been a simplification concocted by Inmarsat to convey the concept more easily to the public. It was simple to explain at a press conference, and easier for a non-technical person to digest. It would also explain why Inmarsat never published arcs for 07:11, 06:11, 05:11, etc.
Anyway, whatever the reason, I would like to see the circles for at least eight of the latest times that the UK AAIB (from Inmarsat) plotted: 02:25, 02:27, 02:29, 03:40, 04:40, 05:40, 06:40, 08:11.
Even if Inmarsat has not plotted circles for those times, even the calculated distance from Inmarsat 3-F1 would suffice: Duncan Steel could calculate the coordinates of 3-F1 at those times, or we could get the coordinates from Web sites such as the following:
http://www.n2yo.com/?s=23839
GuardedDon said,
March 25, 2014 at 4:17 pm
I apologise for this without hard data, but I don’t understand why positional data is not being released.
Msg timings/events
1. 00:30 ACARS Message – Login? Still on ground
2. 00:43 ACARS Message – Departure
3. 00:55 ACARS Message – In climb
4. 01:07 ACARS Message – Top of Climb (ref ADS-B broadcasts)
GAP in ACARS and Handshakes – Contradicts protocol
5. 02:25 ACARS Message? – Coincident with a turn, incorporates strong easterly vector, at this time still in low latitudes.
6. 02:27 ACARS Message? – Consistent with progress of turn
7. 02:29 ACARS Message? – As above
GAP > 1 hour in ACARS and Handshakes – Contradicts protocol
8. 03:40 First Handshake Ping
9. 04:40 Second Handshake Ping
10. 05:40 Third Handshake Ping
11. 06:40 (22:40 UTC) Fourth Handshake Ping
12. 08:11 (00:11 UTC) Final Ping – Contradicts protocol but possibly due to end of day UTC.
The aircraft didn’t fly west & wasn’t picked up by RMAF radar. Over the Gulf of Thailand it turned south, through a distinct vector away from the satellite, when an in flight event occurred coincident with the msgs 5, 6 & 7 above. However, it’s the latter data points in the sequence that really matter for the aircraft crash location, they are not in contention. To avoid conflicting with the radar stories at this time (lack of primary radar intercepts when they’d have been expected), the release of information necessitated the real timings for 5, 6 & 7 to be ‘moved’ right in the timeline to the slot presented on the graph (at about an hour later than they should be) and the intervening log-in interrogation ping that would be expected prior to event 8 ignored.
MtKlimber said,
March 25, 2014 at 5:27 pm
GuardedDon:
In a graphical way, positional data was released with the Doppler data:
http://tmfassociates.com/blog/wp-content/uploads/2014/03/Malaysia-full-tracks-Mar25.png
shows the full tracks using all the Inmarsat range data and assuming various constant speeds.
GuardedDon said,
March 25, 2014 at 5:48 pm
That only shows the 00:11 arc and two speculated tracks & intersections.
timfarrar said,
March 25, 2014 at 5:53 pm
GuardedDon,
You could place the ping arcs on that chart for each time period, since you know the assumed speed associated with each track and that the point of the southwards turn was at ~2.30am. As noted in my update above, the rapid pings around 2.30am aren’t ACARS messages (or we would know the position beyond doubt) but may be some attempt by the plane to re-establish contact after the sharp turn.
duncansteel said,
March 25, 2014 at 6:35 pm
All:
It was asked/stated:
“Anyway, whatever the reason, I would like to see the circles for at least eight of the latest times that the UK AAIB (from Inmarsat) plotted: 02:25, 02:27, 02:29, 03:40, 04:40, 05:40, 06:40, 08:11.Even if Inmarsat has not plotted circles for those times, even the calculated distance from Inmarsat 3-F1 would suffice…”
I will do the calculations for Inmarsat positions at those times in a while and post them here; meantime anyone can read them off my graphic posted here: http://www.duncansteel.com/archives/362
Could I say the following again:
(a) The ping rings/arcs for equal time delays are not properly circular because the Earth is not a sphere (beware of Google Earth);
(b) Because the satellite shifts from ping to ping, the ping rings one gets for different pings/different times are not concentric (if you’ve done the calculations correctly).
Cheers,
Duncan Steel
Scott Henderson said,
March 25, 2014 at 6:40 pm
There was a reference to the nature of the assumed/tested speed in the MalayOnline piece (I can’t quite figure out the source, but it implies AAIB) that they used constant *groundspeed*.
This would suggest that there is further refinement possible, as from what I know of aerial navigation it would be better to assume constant *airspeed*. As briefly mentioned in an earlier comment, to calculate the resultant ground speed at any point to plot/test again the sat data you would need to make an allowance for a wind vector.
This would result in a different “normal cruising speed” track to what we have perhaps seen so far. I did however however hope that the NTSB tracks had allowed for this. It appears Inmarsat / AAIB were primarily testing the North/South route problem rather than specific determination of the highest probability track.
I think @meadows.st asked if I had any of this wind data for the time MH370 disappeared – and I can say I do not. My guess it would require serious number crunching to do this level of refinement on the probable track.
Fitzcarraldo said,
March 25, 2014 at 7:44 pm
timfarrar wrote: “It seems clear from the Doppler information that the plane made a sharp turn very shortly after it was lost from Malaysian radar coverage at 2.22am. There is also much more time for the plane to move outside the 2.30am arc by 3.40am so this does not impose as much of a constraint on the possible routes of the plane.”
The new event times published by the Malaysian MOT on 25 March relax the constraint a little, but the aircraft would still have had to move outside the ~02:30 MYT circle at latest approximately 1000 km south of where it made the turn. If: a) the Inmarsat spokesman’s statement is still applicable; b) the turn was initiated at 2:25 MYT (the first of the cluster of three contacts); c) the next contact was the 3:40 handshake; d) the aircraft was travelling at 450 knots as stated on the graph released by the Malaysian MOT; the aircraft would have covered approximately 1000 km. Therefore the furthest south that it would have had to cross the 2:25 circle is shown on the Google Earth image at the link below:
http://i2.photobucket.com/albums/y9/imageuser/Approx_lowest_exit_point_of_2h22_circle.jpg
As in my previous post, the red line indicates the vector coordinate of the last Malaysian military radar contact at 2:22, and the white arc is the 2:22 circle centred on Inmarsat 3-F1. The straight yellow line is approximately 1000 km long and its southern end therefore indicates approximately the lowest point where the aircraft would have to go outside the ~2:30 circle. If the aircraft flew around the northern tip of Sumatra it would of course have to exit the circle further north than that. In any event, I do not see how the two routes (‘tracks’) shown on the ‘Example Southern Tracks’ image published by the Malaysian MOT could have occurred based on what we have been told.
airlandseaman said,
March 25, 2014 at 7:48 pm
My first post here. Wish I had known about this blog earlier.
The “new time line” reveals that most of the previous assumptions about the location and timing of the LOPs was grossly oversimplified for public consumption. It also raises many questions. Here are few:
1. The more I ponder this, the less confident I am in the NTSB/Inmarsat location. It would only take a 50-100 kt error in the speed ASSUMPTION to throw off the path by many 100′s of miles. If the speed was reduced to 200-250 kts, it goes much more towards the east.
2. It is critical to get Inmarsat to explain the paper released today. Way too many questions. The details in the charts are quite different from what we have heard in the news, and far more reviling.
3. What were the assumptions behind the so called Predicted North Path and Predicted South Path. The labels make no sense. How do you predict something about which you have no knowledge? It is a misnomer at best. Did they simply assume it flew a specific route, based on an assumed endpoint, or what? Why? What’s the basis?
4. As noted by others, it is imperative to see the slant range numbers (LOP circles) corresponding to all 12 or 13 of the transmissions from which they derived a Doppler observation. Depending on the LOP diameters, there is even a scenario where the plane could have been circling after 03:00….as in a holding pattern. The steady increase in the Burst Frequency Offset after 03:40 could be due to a plane headed in a straight line, or a plane circling. If it was circling, and there was a harmonic relationship between the turn rate and the ping rate such that the “beat frequency??? happened to be steady, you could see the same increasing Doppler pattern. The range data will resolve that. I’m just throwing that out to show how critical the speed and path assumptions are to the results. We are so conditioned to subconsciously bias our math with assumptions like “It could not have been circling because radar would have seen it.??? Well, what if it was circling outside the range of the radars, or they simply missed it?
5. What caused 3 handshakes in rapid succession between 02:25 and 02:30? That is not consistent with the ACARS rep rate, or the Ping rep rate. Looks more like 3 unscheduled emergency transmissions. Did these 3 transmissions contain any ACARS data? Maybe there is another explanation, but it does not fit the pattern.
6. What is the reason for the last 2 handshakes (06:40 and 08:11) being ~ 90 minutes apart instead of the expected 60 minutes? I heard from Miles O’Brien tonight that the 08???11 transmission was initiated by the aircraft end, thus not a “ping???.
7. What exactly do they mean about the “partial ping??? at 08:19?
8. Why was the time of the last attempted handshake 09:15? If hourly, why wasn’t it at 09:11?
9. What IOR beam or beams were used for each of the 12 connections?
10. Were the beams used to help resolve positions or direction by comparing signal strength in each beam, over time?
11. Has any attempt been made to find the pings in the 142.5E satellite data? Could they be expected there? Did that NOC have the required baseband gear?
12. Explain how the earth shape can have any effect on the North South argument? Did they mean they exploited the orbital inclination, which is influenced by the shape and density inhomogeneity of the earth, but to make it simple for the public, left that detail out?
NOTE: The vertical axis in the “Burst Frequency Offset??? graphic is not the Aircraft Doppler with a constant bias. It is apparently the combined spacecraft and aircraft Dopple, plus an unknown constant system bias. We know MH370 was not moving at 00:40 (first Doppler observation), thus we can say the total system offset including spacecraft Doppler, at that time, was +87 Hz. That’s probably a good number for an hour or so, but it changes smoothly with spacecraft movement. How much? I’m too old to do that math from orbital elements, but they are on the web. In any event, if the s/c Doppler is relatively small, it can be seen from the graph that the Doppler for all 12 points was positive, indicating movement away from the spacecraft (in the radial direction), since it is known that MH370 headed slight away from the satellite after takeoff. I was probably going west during at least part of the 01:07 -02:30 gap, but the Doppler was indicating movement to the east at all observation times (if the spacecraft Doppler does not drive it below the 87 HZ bias). I find this interesting. Would sure like to see the Doppler with all spacecraft and other system bias removed.
Solo said,
March 25, 2014 at 8:19 pm
This site has been one of the best online resources for understanding the satellite pings. My thanks to the bloghost, Tim Farrar, and all of you who have posted comments on this blog over the past ten days or so.
Referring to the plot of the Burst Frequency Offset, the following issues are IMHO puzzling:
1. The two gaps:
a. the first between 01:07 and 02:25
b. the second between 02:29 and 03:40
2. The data associated with the three pings at 02:25, 02:27, and 02:29.
a. The large measured frequency offset associated with 02:25 would appear to be inconsistent with a location of the MH370 as reported by the Malaysian authorities.
b. The rate of change in the measured frequency offset over these three pings, would appear to be indicative of abrupt turn/increase in the radial velocity of the MH370 towards the INMARSAT satellite i.e a turn westward, not south.
This turn westward could have been undertaken either at 02:25 or at some time between 01:07 and 02:25.
XocoLatte said,
March 25, 2014 at 10:02 pm
Even though handshake ping protocol would make the satellite attempt to get a reply from the aircraft after 60 minutes of period without transmission, the two gaps are indeed interesting, so to speak. Perhaps they could be explained, releasing them without any explanation from Inmersat truly creates further space for speculations. Actually the second gap is the big red herring, 91 minutes after a steady hourly transmission is really troubling. How is that no 07:40 ping? According to protocol, at least an attempt by the satellite must have been made. Under what circumstances would the ping reply suddenly stop being transmitted by the aircraft? Even IF the last 08:11 handshake was rather connected with first-of-the-day attempt (by UTC), I would really want to hear Inmersat explanation of the apparent lack of 07:40 handshake.
I also think releasing the perceived positional data alongside this timeline would be more than, well, timely…
duncansteel said,
March 25, 2014 at 10:19 pm
As promised I have now calculated the positions and velocities of the Inmarsat-3F1 satellite at the twelve times indicated in the ‘doppler shift’ graph from Inmarsat issued by the Malaysian Government on March 24th.
The information I have posted here…
http://www.duncansteel.com/archives/397
…as a set of screen grabs from my STK scenario. Anyone who wants to transpose all those numbers into machine-readable form, please do go ahead and post the numbers here for others to use.
You will see that for each of the dozen times I give three sets of information:
(a) The orbital elements of the satellite (yes, they do change hour by hour);
(b) The positions and velocities of the satellite in x,y,z coordinates;
(c) positions and velocities of the satellite in terms of altitude, latitude and longitude.
Cheers,
Duncan Steel
duncansteel said,
March 26, 2014 at 2:50 am
A few notes on the satellite speed (and thus doppler shifts of that origin):
(a) Apologies that I wrote something daft about the satellite drift speeds (relative to a geostationary point) in an earlier post here.
(b) In my set of satellite positions and velocities…
http://www.duncansteel.com/archives/397
…the quantities vx, vy, vz show the three velocity components, and for a true geostationary orbit these would all be zero all the time.
(c) The values of vx and vy remain small at all times, whereas vz is larger and (over an orbit) oscillates between maximum and minimum values of +/-0.088 km/sec (equivalent to 171 knots); that is, the satellite is travelling at 171 knots as it crosses the equator going in either direction.
(d) Throughout the flight of MH370 the satellite was north of the equator, as shown here: http://www.duncansteel.com/archives/362 At the time of take-off of MH370 the satellite was moving north; then it reached its most northerly position (when vz=0.0) at just before 19:36 UTC, after which it was moving south (vz negative).
(e) A speed vz=0.05 km/sec is close to 100 knots, and the satellite had this speed moving north at around 17:30 UTC, and then moving south at around 22:00 UTC.
(f) The component of the satellite’s velocity contributing to any measured doppler shift between the satellite and the aircraft will depend upon the angle between the satellite’s velocity vector and the position of the aircraft at any time; because I am neglecting vx and vy as being smaller than vz, generally, and we have from elsewhere a position angle for the aircraft from the satellite of about 50 degrees (the complement of 40 degrees elevation), I will estimate the angle needed to be about 45 degrees; thus the satellite’s contribution to the doppler shift is about vz cos 45 deg, or around 0.7 vz.
(g) The above, coupled with the satellite speeds that I have given, will enable anyone to make a reasonable estimate of the contribution of the satellite’s movement to the doppler shift.
(h) I hesitate to point the following out, because I have some confidence that Inmarsat have now worked things out properly. HOWEVER… Looking at the graph headed “MH370: Burst Frequency Offset Analysis (450 knots)” as issued by the Malaysian Government on March 24th (this is the first chart I gave at http://www.duncansteel.com/archives/397 ) I note that the start of the near-parallel trends between the blue line (measured doppler shift) and the green line (predicted doppler shift for the aircraft south track) starts at 19:40, which is just after the satellite stopped moving north (vz=0) and started moving south (vz negative). The satellite rather quickly attains a southerly speed (vz negative) of about 100 knots, and then at the time of the final ping (00:11 UTC) it is about 150 knots. The components of these along the satellite-aircraft line-of-sight would be about MINUS 70 and 100 knots (based on my assumed angle of 45 degrees). Someone please, please tell me that Inmarsat allowed for this satellite-caused component of the doppler shift, and so it it not the origin of the near-consistent (negative) offset between the blue and the green lines in that graph. Please.
Regards,
Duncan Steel
GuardedDon said,
March 26, 2014 at 4:35 am
A little more related to the communications shown on the BRO graph from MoTM.
At this stage I expect that published information is consciously being limited & while that’s frustrating for those on this thread, it sufficient to keep the media satisfied and ‘on message’.
The ‘pings’ we have been discussing are Inmarsat initiated GES traffic, the log-in ‘Direct Verification’, initiated after a specific idle interval in order to determine if the aircraft satcom unit still requires service. They’re the evenly spaced sequence of comms 03:40 to 06:40.
ACARS data is aircraft or ground initiated traffic, routed via SITA over Inmarsat’s data link: the subject of the messsages is wide and varied to support the airline operations. Not all messages carry positional data, most are very short. There’s a discussion of the message labels & some examples here: http://bit.ly/1llKJ9p
The 08:11 communication may not have been an Inmarsat log-in Direct Verification but an ACARS query message from Malaysian Flight Ops to the aircraft, similarly, the incomplete 08:19 message. Again, why no log-in DV at 07:40? Other messages may have been exchanged given the aircraft was overdue by the time an 06:40 login DV was due from Inmarsat.
Reconsidering those first few messages shown on the BRO timings charts from MoTM, I’d suggest that
1. 00:30 ACARS Message Passenger doors closed, ie push back
2. 00:43 ACARS Message Ldg gear doors closed, ie departed
3. 00:55 ACARS Message In climb/engine data report/??
4. 01:07 ACARS Message Top of Climb, ie cruise established and ETA advice from ops can be more precise.
Those are all very short messages, no positional data, relayed over the Inmarsat network, via SITA’s service, to Malaysian’s ops centre. Malaysia Airlines, according to a SITA press release subscribe to weather updates for 40 aircraft in their fleet, discounting the 737s that corresponds to the total numbers of A380s, A330s and B777s in the fleet. One of those early messages could be a enroute winds update to 9M-MROs FMC.
Too many unknowns remain except that the southern Indian Ocean is the target search location. Looking back at AF447′s loss, there was much more accurate location data available as the aircraft was completely serviceable until it impacted with the ocean. We, of course, know key systems on 9M-MRO, or their connections to the outside world via satcoms, weren’t serviceable. One point to note on that – the AES terminal unit is located towards the rear of the fuselage, not in the Main Equipment Center under the main deck near the cockpit.
Again, thanks to all contributors at http://tmfassociates.com/blog – a great amount of interesting information is being shared that helps everyone understand the comms environment supporting modern airline operations.
GuardedDon said,
March 26, 2014 at 5:12 am
@ Duncan, reference your point (h)
The AMS(R)S manual describes that the AES user terminal design must detect doppler shift on its received signal and it must compensate in transmission back to the satellite:
Receiver Doppler rate. The receiver shall be capable of acquiring and maintaining performance per [demodulator performance] with a rate of change of frequency of 30 Hz per second.
Transmitter Doppler rate. The maximum rate of change of the frequency of the transmitted signal when compensated for aircraft acceleration in the direction of the satellite shall not exceed 15 Hz per second. The Doppler adjustment resolution shall not exceed 10 Hz and the associated frequency changes shall be made without introducing phase discontinuity into the transmitted signal.
Is that helpful?
greebo said,
March 26, 2014 at 5:12 am
Thanks for the fascinating write up!
Forgive my ignorance but what does it mean when you say the plane would revert to a magnetic bearing if a waypoint was not entered?
Does that mean the plane would literally fly towards magnetic north/south?
timfarrar said,
March 26, 2014 at 6:12 am
Greebo,
The magnetic bearing heading is what the PPRUNE post suggests. That means that if you are heading on bearing 190 (it doesn’t have to be south), that is relative to magnetic north/south not true north/south. Thus, as you head further southwest from Malaysia the magnetic declination will increase and your true path will change from southwest to south to (eventually) southeast.
I’m told that the red “example” southern track was calculated by Inmarsat based purely on how quickly the ping arcs were crossed at the assumed speed. It is not assumed to be a constant magnetic bearing, though it is clearly much closer to that than the yellow track, which has a significant change in magnetic bearing and thus apparently must relate to either a specifically selected non-magnetic bearing or a track towards a selected waypoint.
timfarrar said,
March 26, 2014 at 6:33 am
DuncanSteel,
Your data analysis got a shout out on this WSJ explanatory video: http://t.co/JP8wz7neEw
But I think they misunderstood the extent of the variation?
timfarrar said,
March 26, 2014 at 6:59 am
DuncanSteel and GuardedDon,
As Don points out, there is Doppler correction going on in the terminal (indeed the Malaysian explanatory chart specifically calls out the correction that’s already happening for the speed of the plane), and it appears what we are seeing is a “residual” component. This residual component has been predicted for the north and southern tracks and is the basis of the comparison.
There is asymmetry because of the satellite movement, but I wouldn’t give any weight to the absolute magnitude of the Doppler shift because of the compensation being applied. However, a sharp relative change in the shift is very likely to be associated with a change in the direction of the aircraft (the 2.30am effect and the smaller earlier change associated with the turn back).
GuardedDon said,
March 26, 2014 at 7:11 am
“[air] transport category airplanes (with onboard inertial reference systems) provide true-referenced data; calculate corresponding magnetic data; and use or output data in either or both reference frames. These airplane systems do not need magnetic sensor data because of the onboard inertial systems (such as IRS, IRU, ADIRU). These inertial systems contain magnetic variation coefficient databases, and derive magnetic values from these databases to support displays and other airplane systems requirements.”
http://1.usa.gov/1hY6eYr
pg 7, 2-b
hal said,
March 26, 2014 at 8:13 am
New here, and really enjoying the technical discussion. A few comments/questions:
1 – @Alex re lightning. That’s a suggestion I’ve not heard before.
2 – @duncansteele re satellite movement. My understanding is that north-south satellite movement is all they needed to rule out the northern route using doppler. Given that figured prominently in the solution, I doubt they’d forget to figure it into their graph. Though it might not show up correctly in the publicized graphs.
3 – what does earth curvature add to this analysis? Finding the true path, maybe. Don’t think it’s needed to rule out northern route.
4 – plane speed has a huge impact on path. Do they know it was 400-450 knots or are they assuming it? If you know satellite speed, doppler shift, and general southerly direction, can you compute plane speed exactly? If not, there are lot of possible paths and you’d have to go to some kind of comparison of other airplanes. They’ve mentioned using other planes for calibration but I haven’t seen anything specific about it.
5 – ditto the assumption of straight and level flight. Is there any way to know or are they just assuming?
DrewKat said,
March 26, 2014 at 8:16 am
Timfarrar,
You may have hit on something by noticing the predicted paths were based on assumptions for constant speed, and how that assumed speed fits the crossing of the ping arcs, without regard to a constant bearing.
Problem is, without knowing the speed, I’m guessing theres a different path that fits the ping arcs for every mile/hr., and it have followed any of them.
I wonder if they could iterate on the assumed speed, until they find a constant speed that crosses the ping arcs, and turns out a path that does follow a constant bearing (be it magnetic or not), or waypoint? If this speed could be found, that would be the most likely solution. (Unless the plane was constantly being turned somehow? )
timfarrar said,
March 26, 2014 at 9:44 am
DrewKat,
That’s exactly what I think – an iterated calculation with an assumption of constant speed that matches the crossing points. You would normally assume a constant heading as well, but it’s unclear how this was referenced to magnetic vs absolute bearings, perhaps just the latter.
Fitzcarraldo said,
March 26, 2014 at 12:01 pm
The coordinates for the Magnetic South Pole move, but were 64.497°S 137.684°E in 2007 according to Wikipedia, and are approximately 63°30′S 138°0′E according to http://www.findlatitudeandlongitude.com/?loc=magnetic+south+pole.
The red ‘track’ (flight path) published by the Malaysian MOT is the path to reach each ‘ping’ arc if speed between each arc was 400 knots (that speed being an assumption); that path does not lead to the Magnetic South Pole.
Had the arcs been concentric, the slower the speed the more the flight path would curve further eastward and less southward. This is because the distance travelled between each contact (‘ping’) would have been shorter and the shortest distance between concentric arcs is along their radius. Now, Duncan Steel has pointed out that the contact arcs are not concentric and not on perfect circles. Nevertheless, the principle still applies… The circumferences of the off-centre circles are closer together towards the north, and further apart towards the south. You can see this effect in Google Earth if you plot a series of arbitrary circles with increasing radius, each centred on the correct location of Inmarsat 3-F1 from 19:40 to 00:11 UTC (see coordinates listed below).
The coordinates (in degrees) of Inmarsat 3-F1 at the contact times provided by Duncan Steel on 26 March are as follows:
UTC Latitude Longitude
16:30 1.129 64.551
16:43 1.194 64.549
16:55 1.252 64.547
17:07 1.306 64.545
18:25 1.563 64.531
18:27 1.567 64.531
18:29 1.571 64.531
19:40 1.640 64.520
20:40 1.576 64.510
21:40 1.404 64.500
22:40 1.136 64.490
00:11 0.589 64.491
meadows.st said,
March 26, 2014 at 1:36 pm
@DuncanSteel, @GuardedDon, @TimFarrar, @KeithLedgerwood and @Fitzcarraldo (et al)
timfarrar said on March 26, 2014 at 9:44 am
“an iterated calculation with an assumption of constant speed that matches the crossing points. You would normally assume a constant heading as well, but it’s unclear how this was referenced to magnetic vs absolute bearings, perhaps just the latter.”
I am working on an analysis that attempts to work out the relative bearing between the satellite and MH370 after the 02:25 DV comms but haven’t had any time to work on it today. I am attempting an iterative/circular reference approach to determine the radial component of the aircraft and sat speeds (and thus their relative position and angles) at the time of each communication. Of course I have to assume air speed of MH370 (which requires some assumptions for average wind speeds in each interval – or at the least instantaneously during the communications) to get “absolute” relative speed w.r.t. the satellite so there will be introduced error that may be large (someone had referenced the “roaring 40′s) so that will add or subtract a significant error in the calculated angle with respect to a parallel of latitude. It strikes me that there are really only two most highly probable assumptions for the speed of the aircraft as follows: 1) throttle setting for max range (~ Mach .84); or 2) throttle setting for max endurance (= ~80% of Max Range power). I am not a pilot but it is my understanding that at a constant air density (thus flying at a constant altitude) power is directly proportional to air speed (angle of attack changes) and the autothrottle does not constantly change throttle position typically unless it is set in Speed mode (as opposed to thrust mode) (as a passenger, it would be pretty obvious if the aircraft were constantly changing throttle position). The autopilot on the other hand would adjust to local wind conditions to maintain heading (either magnetic or waypoint-track). Thus, I think the iteration should be in terms of various relative speeds (within the range of Max Range or Max Endurance settings but compensated for wind velocity at the assumed position – thus iterative analysis to achieve a best fit for all the dependent equations) but constant heading (one assumption for constant magnetic heading and one for fixed (true) waypoint heading).
One other thing struck me as I was starting to prepare my model and this is, has anyone looked at whether there is any waypoint on the far side of the south pole that could have been entered and for which the aircraft was steering. (I know this is off the wall but I am trying to determine what possible waypoint could have been entered in the FMS if the hypothesis of constant waypoint heading is true) – The only path takes the aircraft over the top portion of the preliminary search area is in southern Chile (Teniente Julio Gallardo) See: Southern Waypoint over S35E90
I know this is a stretch so please be kind.
If anyone else knows of a waypoint that would allow the autopilot to steer over or close to the initial search area, please let me know as I want my starting assumptions to at least have a shred of plausibility.
One other thing that occurs to me is I don’t know how the autopilot would react if the aircraft passed a waypoint without any additional waypoints.
meadows.st said,
March 26, 2014 at 1:43 pm
Note: I know that the instantaneous speed and direction relative to the motion of the satellite has an effect on the Doppler offset but if we can work out a better estimate for speed between “ping contours” assuming a constant heading (two alternatives, waypoint and magnetic) then we would have a better assessment of the fuel starvation point and thus the point to start calculating the search area. Perhaps Inmarsat has already performed this compensated calculation.
GuardedDon said,
March 26, 2014 at 3:21 pm
Polar route navigation: I came across this a few days ago in Boeing’s Aero magazine – http://bit.ly/1pz24sI
I’m not sure what happens when reaching the last waypoint, IIRC that Helios 737 went into a holding pattern until fuel exhaustion but that might have been part of the ‘company route’ pre-defined in the FMC.
The math sounds like a concentric arc/chord computation across the 4 consistent log-in DV message events plus the OO:11UTC message but the variations are myriad.
I was exploring a few ideas earlier and found the flight recordings at flightradar24.com v useful (it logs ADS-B broadcast data). Got to ‘database’, select ‘Airline Fleets’/enter Malaysia, select any 9M-MR* match for a B772 and pick a sector – there’s a replay control to ‘fly’ the route so you might get some insight there. They interpolate the gaps in ADS-B coverage.
Good luck!
timfarrar said,
March 26, 2014 at 3:47 pm
Meadows.st,
It is stated specifically that the assumptions for the red and yellow tracks are 400 knots and 450 knots respectively. Although the detail on the picture isn’t great, this alone along with the ping timings should allow the approximate locations of the arcs to be derived, based on the known timing of the turn and the distance traveled during each ping interval.
meadows.st said,
March 26, 2014 at 5:08 pm
Thanks @timfarrar,
Those lines are what I am planning to use for starting assumptions for the iterative calculations.
I am somewhat confused by the 450 knots though. Cruising speed is listed (on both Boeing’s site and Wikipedia) as 0.84 Mach and at 35kft, Mach 1.0 = between 302 and 305 m/s which puts 0.84 Mach at ~250 m/s ~ 490 knots. Perhaps these average speed assumptions are meant to incorporate a correction for wind speeds aloft? I have been trying to find some historical references for the assumed flight area to no avail. The next 8 days’ forecast though (the best info I have at the moment) shows wind speeds and directions are very variable at 35kft and range from 10 to 35 knots until you go below 30 degrees Lat. From the current 8 day forcast, these winds are very variable but I am planning to attempt a series of assumed wind patterns. From the Inmarsat assumptions, it seems like they were assuming a 40 knot headwind on average – I trust they had access to the winds aloft forecast in the area at the time – the assumptions for airspeed match on an order of magnitude basis in any event and I suspect they would have used a number of models and just simplified the charts for public consumption.
Alex Siew said,
March 26, 2014 at 7:00 pm
1. The assumption that the plane flew on for several hours based on the pings.
Further to my previous comment, below is an extract from PPRUNE (page 379 post#7568):
“…..the SATCOM installation which is above the economy section in B777 at the back of the aircraft could still have been pinging as wreckage in the ocean which subsequently sunk after 8.11…..The SATCOM installation in the B777 is totally autonomous to the rest of the avionics which are located in the pointed end of the jet. It has its own power, battery is close by Rack E10, SDU Satellite Data Unit, BSU Beam steering unit…….”
That the plane could still have been to ping even if it had crashed had been pointed out by aviation experts when the story about the pings first broke (see eg Oliver McGee, Mark Rosenker former NTSB chairman) but conveniently ignored by mainstream media thereafter.
2. The purported turn to the West
There is no real evidence to show the plane made a turn to the west or that the blip seen on primary radar at 2.15 or 2.22 near VAMPI or MEKAR was MH370.
When the plane disappeared off civilian radars at around 1.20, it had just made a turn from 25 degrees to 40 but this was reportedly in accordance with its normal flightpath. After a lot of conflicting statements, the Malaysian military could only confirm that a review of their military radar data showed that there was an unidentified blip 280 miles NW of Penang on the other coast (near VAMPI) at 2.15.
airlandseaman has interpreted the Doppler Effect chart as showing that the plane was at all ping times eastwards of its starting point. This is consistent with Inmarsat saying the RT timings were getting longer. Theoretically the plane could have flown westwards during any of the intervals between pings but it would mean the plane had to zig zag back eastwards before the next ping.
The statement accompanying the chart stated that there were 6 completed handshakes, presumably referring to 2.30, 3.40, 4.40, 5.40, 6.40 and 8.11. It would mean the 2.25 and 2.27 entries are anomalies much like the 8.19 half-ping. It may be a stretch to read those entries as suggesting a west turn. Interestingly, the reading for 4.40 was lower than 3.30.
The RT timings should be able to settle the debate as to whether the plane had crashed early on or was circling around or had flown in pretty much a straight or magnetic line at cruising speed and altitude for 8 hours to the Indian Ocean.
Alex Siew said,
March 26, 2014 at 7:33 pm
The 3.40 reading was lower than the 2.30 entry, correction
MtKlimber said,
March 26, 2014 at 8:22 pm
Meadows.st:
Kudos on your attempt at modeling various assumed tracks that match the reported Inmarsat range data.
While we know any ground track that matches the arcs is a strong function of assumed speed, it would be very interesting to see how sensitive the predicted “Burst Frequency Offset” (BFO) vs. time plot is to different ground speeds, assumed navigation mode (magnetic heading or direct to waypoint), etc. Presumably Inmarsat found that the predicted BFO vs. time plot for an assumed constant 450 knot ground speed gave the best fit to the observed BFO data (since that seems to be the only BFO prediction plot that has been shown to the public).
Regarding your questions (1:36 PM) about autopilot behavior, my understanding is that a pilot would not need any predetermined waypoint in order to track direct to the initial search area. He or she could simply enter a phantom waypoint (lat. and long.) and tell the autopilot to proceed direct to that point anywhere in the world. The autopilot would then fly a great circle route direct to that location.
I have been told by an experienced pilot (turboprop, not airline) that normal autopilot behavior after passing a waypoint, without any additional waypoints entered, is to continue (indefinitely) on the last magnetic heading that the autopilot had been tracking immediately prior to reaching the last waypoint. This means that the track will change from a great circle routing to magnetic heading in that circumstance. (Off topic: In cases where the crew becomes incapacitated in cruise flight, the plane overflies the destination and continues on a constant heading; “ghost” planes don’t make 90 degree turns – except if it was preprogrammed before decompression of the cabin.)
I’m sure there are exceptions, but I am told this is the most common default action for autopilots. Any airline pilots here – please correct me if I am wrong.
hal said,
March 26, 2014 at 8:32 pm
@meadows.st – Why not do your calcs for all possible speeds? Once you have the code written that should just be a parameter. Your output should be a family of trajectories. Given that the two published ones differ considerably for just a 50-knot speed difference, subtracting another 100 (down to 300) or 150 (down to 250) should produce interesting paths.
Did anyone see the CNN contributor describing the new debris field (122 separate pieces) as “too many pieces” to be a plane? This search could be way off.
It’s not appropriate to rule out anything on that southern route, as we must discount claims by Indonesia and other area countries claiming they didn’t see the plane on their radar. Too many reasons exist for them to not be forthcoming.
A disabled plane limping along at 250 knots could have ditched well east of the search areas they are considering now.
ideaswork said,
March 26, 2014 at 8:42 pm
I am a total amateur. I found this thread being the most substantive to finding the location of the MAS370. Although I was trained as a physicist and worked in tech fields for years, I am learning the satcom and all on the spot. Please pardon my ignorance.
I am not finding answers that the INMARSAT analysis has some obvious holes. Your help is greatly appreciated. Here are the points puzzled me:
1. The assumption from INMARSAT are not explainable by the data: INMARSAT appears to assume that the UTC 18:25 frequency offset spike is the “possible turn” and the rest of the “predicted path” appears to be based on this “possible turn”. What if it is not a turn but an altitude drop? What did ACARS transmitted, since this is not a “ping”? And what are the next two transmissions data show? This matters since the speed of the aircraft would be much lower that 450kt if the altitude is low and the direction would be different though still away from the 3F1 location.
2. Anyone has the time box shift data?
3. INMARSAT should also be able to predict the frequency shift between 16:30 (before takeoff) and 16:55 (ascending) and 17:07 (after leveling at cruising alt.) since the flight was under normal ascend and bearing. The chart doesn’t show any correlation during these times. I am not sure what this speaks to their prediction. Anyone here has the data that INMARSAT used to model? (According to their claim that 6 other flights were used)
Thanks!
duncansteel said,
March 26, 2014 at 8:59 pm
Just checking in…
Thanks everyone for comments and useful information. Strikes me that this is an example of a needed multi-disciplinary attack on a problem, which is great. I know next to nothing about aviation, but plenty about space. We need all sorts.
A kind lady named Annette in the UK transposed all the data in my STK screen grabs into an Excel spreadsheet so as to be machine-readable, and here they (the data) are:
Inmarsat-3F1 Classical Orbit Elements Inmarsat-3F1 Fixed Position Velocity Inmarsat-3F1 LLA Position
Date Time (UTCG) Semi-major Axis (km) Eccentricity Inclination (deg) RAAN (deg) Arc of Perigee (deg) True Anomaly (deg) Mean Anomaly (deg) x (km) y (km) z (km) vx (km/sec) vy (km/sec) vz (km/sec) Lat (deg) Long (deg) Alt (km) Lat Rate (deg/sec) Lon Rate (deg/sec) Alt Rate (km/sec)
1 7-Mar-14 16:30:00 42165.163724 0.000498 1.716 74.384 272.402 130.408 130.364 18120.879124 38078.783392 830.007688 0.001912 -0.001008 0.063780 1.129 64.551 35800.644581 0.000087 -0.000003 0.001168
2 7-Mar-14 16:43:00 42165.163061 0.000497 1.716 74.383 272.235 133.831 133.790 18122.400463 38077.953057 878.400582 0.001871 -0.001060 0.060240 1.194 64.549 35801.529630 0.000082 -0.000003 0.001103
3 7-Mar-14 16:55:00 42165.162450 0.000495 1.716 74.383 272.071 137.001 136.963 18123.776613 38077.155133 920.556533 0.001834 -0.001096 0.056800 1.252 64.547 35802.300465 0.000077 -0.000003 0.001040
4 7-Mar-14 17:07:00 42165.161842 0.000494 1.716 74.383 271.898 140.180 140.144 18125.125754 38076.335836 960.179297 0.001797 -0.001120 0.053204 1.306 64.545 35803.024823 0.000072 -0.000003 0.000974
5 7-Mar-14 18:25:00 42165.158040 0.000488 1.716 74.381 270.588 161.028 161.010 18133.346863 38071.003737 1149.165463 0.001627 -0.001042 0.026738 1.563 64.531 35806.475280 0.000036 -0.000003 0.000488
6 7-Mar-14 18:27:00 42165.157948 0.000487 1.716 74.381 270.551 161.566 161.548 18133.549045 38070.875519 1152.332469 0.001625 -0.001036 0.026005 1.567 64.531 35806.532956 0.000035 -0.000003 0.000475
7 7-Mar-14 18:29:00 42165.157856 0.000487 1.716 74.381 270.514 162.104 162.087 18133.751017 38070.748022 1155.411376 0.001624 -0.001030 0.025269 1.571 64.531 35806.589015 0.000034 -0.000003 0.000461
8 7-Mar-14 19:40:00 42165.154827 0.000486 1.716 74.380 269.148 181.252 181.253 18140.934782 38066.764468 1206.206412 0.001663 -0.000776 -0.001656 1.640 64.520 35807.506054 -0.000002 -0.000002 -0.000033
9 7-Mar-14 20:40:00 42165.152645 0.000487 1.716 74.378 267.995 197.432 197.449 18147.379654 38064.186790 1159.122617 0.001811 -0.000618 -0.024394 1.576 64.510 35806.630758 -0.000033 -0.000003 -0.000449
10 7-Mar-14 21:40:00 42165.150756 0.000491 1.716 74.377 266.946 213.510 213.541 18154.399609 38061.901891 1032.716137 0.001962 -0.000627 -0.045468 1.404 64.500 35804.302284 -0.000062 -0.000003 -0.000835
11 7-Mar-14 22:40:00 42165.149031 0.000498 1.717 74.376 266.084 229.402 229.445 18161.767618 38059.215141 835.616356 0.001981 -0.000841 -0.063437 1.136 64.490 35800.680224 -0.000086 -0.000003 -0.001164
12 8-Mar-14 00:11:00 42165.168646 0.000517 1.717 74.377 265.062 253.219 253.276 18173.906276 38051.980584 433.193954 0.001476 -0.001458 -0.082097 0.589 64.471 35793.321866 -0.000112 -0.000003 -0.001524
That looks a jumble, but is decipherable. If you’d like the Excel file, send me a message via my website (duncansteel.com).
What I am doing next is this. I am looking into how much the ‘proper’ ping rings for specified time delays differ from the ping rings as shown in many graphics (which are concentric and circular: wrong); I should put up a post within 6 or 7 hours, if my coding goes OK and then I get the calculations into STK OK.
It sure would be good if we had definitive ping time delays from Inmarsat or the AAIB or SITA or NTSB…
Immediately, here are some numbers that might be useful to some. Really quite simple. I have tried to back-calculate the ping time delay as at 00:11 UTC (2014 March 08) based on the information (wrong) in the March 15th graphic/map, which indicates a satellite above the equator at 35,800 km altitude and apparently-circular ping rings. Taking the Earth’s equatorial radius as 6378.137 km and assuming the Inmarsat engineers used that plus a spherical Earth model it is simple to back-calculate from any value of the satellite elevation angle to what the range was and so what the ping time delay was. I assume that they also assumed the aircraft to be at 35,000 feet above the equatorial radius given above. Then I get ranges and thus time delays (at the speed of light) as below for one-degree steps in elevation angle from 35 to 45 degrees:
Elevation angle (degrees); Range (km) satellite to aircraft at 35,000 ft; Time delay in milliseconds.
35.0 37126.025 123.839
36.0 37199.514 124.084
37.0 37274.640 124.335
38.0 37351.370 124.591
39.0 37429.671 124.852
40.0 37509.510 125.118
41.0 37590.851 125.390
42.0 37673.661 125.666
43.0 37757.905 125.947
44.0 37843.548 126.232
45.0 37930.554 126.523
At the ‘nominal’ 40 degree angle (as shown by the red arcs in the March 15th graphic) the time delay as measured must have been around 125.1 milliseconds. It has already been given on this thread that the uncertainty in the time delays is +/-0.3 millisec, thus 124.8 to 125.4 is the range of values. However, Inmarsat clearly rounded to that 40 degree angle, and so that range (in my present state of ignorance) must be relaxed a little. Thus I believe that Inmarsat’s time delay measurement at 00:11 UTC was between about 124.6 and 125.6 milliseconds, and the actual elevation angle between 38 and 42 degrees (as was arrived at on this thread a couple of days ago).
Cheers,
Duncan Steel
Salsero said,
March 27, 2014 at 3:05 am
To me this blog is highly interesting although I am not at all a specialist in this field – sorry if my posting here is not deemed very valuable.
I had the same idea as ideaswork – that the peak in the doppler shift at around 02:20 is caused by the plane at that point in time making a steep descent. If descending at about 5500 fpm, the distance to 3F1 increases at about the same rate as if flying radially away from it at 500 mph (roughly at the location at the northern end of Sumatra). During an emergency type descent actually 10000 fpm is well possible. So if at that time the plane was still on an approximate bearing of 290, the resulting shift would correspond to a shift that could also result from flying at about 500 mph in the opposite direction at constant altitude.
A steep descent like this may have actually caused the plane to disappear from the Butterworth radar. If flying around, e.g. not over, the northern tip of Sumatra, at around 03:40 the plane could have been crossing the equator with a bearing 180, causing a doppler shift almost as low as the value before take-off.
duncansteel said,
March 27, 2014 at 5:11 am
Apologies: mea maxima culpa. I made a silly mistake in my code in deriving the ranges and time delays above. That list should read:
Elevation angle (degrees); Range (km) satellite to aircraft at 35,000 ft; Time delay in milliseconds.
35.0 38187.733 127.381
36.0 38105.002 127.105
37.0 38023.504 126.833
38.0 37943.258 126.565
39.0 37864.281 126.302
40.0 37786.588 126.042
41.0 37710.196 125.788
42.0 37635.120 125.537
43.0 37561.376 125.291
44.0 37488.978 125.050
45.0 37417.941 124.813
Thus the ring arc at 40 degrees corresponds to a range of 37,786.6 km from the ‘model geosat’ at altitude 35,800 km directly above the equator, producing a time delay of about 126 milliseconds. That is, I think, the time delay that Inmarsat must have determined from the last ping. The angle range is as before.
Salsero said,
March 27, 2014 at 6:37 am
Having regard to the ACARS flight information manager settings for the 777 as explained at http://www.theairlinepilots.com/forum/viewtopic.php?p=1070&sid=033464f8b8ec8fce795962273f357ebc
it looks like the regular pinging via the Inmarsat 3F1 (first ping 03:40) may have been triggered by leaving the VHF ground station radio range (as I understand roughly 200 miles from air to ground) in ACARS auto mode. Could this be a reasonable explanation for the gap between 02:29 and 03:40 ?
Fitzcarraldo said,
March 27, 2014 at 7:43 am
Some of you have stated in previous posts that the aircraft turned to starboard, not port, over the South China Sea. Take a look at the following slide in the Beijing hotel where MAS and the Malaysian government briefed the passengers’ relatives:
http://multimedia.asiaone.com/sites/default/files/styles/500×400/public/original_images/Mar2014/mh370families-7.jpg?itok=0kg0aSeD
That shows the aircraft turning to starboard, circling clockwise and then heading NW, then SSW until it reached the east coast of peninsula Malaysia, then crossing to the west coast roughly over Butterworth and Pulau Penang.
The aforementioned slide is accessible from the following asiaone Malaysia Web page of 27 March:
http://news.asiaone.com/news/malaysia/mh370-accuracy-aaib-analysis-questioned
I believe that slide is from the briefing to family members on 19 March:
http://multimedia.asiaone.com/sites/default/files/styles/500×400/public/original_images/Mar2014/mh370angryfamily-14.jpg?itok=5ysOX55a
airlandseaman said,
March 27, 2014 at 7:45 am
To solve this problem…
We also need the last lat/lon/alt/time record obtained by the radars. I know, it won’t happen. But I hope we could at least get the final position. That would be a big help.
I’m starting to glean more from the Annex I Doppler graph. I am especially interested in the period between 01:07 and 03:40…a 2 ½ hour gap in the Inmarsat data, except for 3 rapid fire aircraft initiated emergency transmissions, probably triggered by an event in one of the engines, such as a rapid decrease in ambient pressure, fire, or something. Whatever triggered it, the message would have contained ambient pressure (altitude). We need verify and to squeeze Boeing and RR for those data, if it exists.
The military radars tracked the plane for the first half of the 01:07 -03:40 period. Some reports have said that the radar was lost at 02:15, others a bit later. It would be nice to know if either radar tracked the plane between 02:25 and 02:30, the period when we can see from the Doppler data that the plane was in trouble and turning from a generally east bound direction to either north or south direction (moving from a direction at 02:25 with relatively high radial velocity away from the satellite, to one nearly tangent to the radial).
The final period between 06:40 and 08:19 is also intriguing. Whatever happened during the 01:07-03:40 period, we know things settled down between 03:40 and 06:40, indicated by the smoothly increasing Doppler obtained from 4 sequential hourly Pings. There should have been another ping at 07:40, but it was not received. The next transmission was at 08:11, but we do not know for sure if it was another Ping or an aircraft initiated emergency message, like the 3 around 02:30. If it was an emergency initiated message at 08:11, and the rep rate on the first 3 emergency messages was ~2 minutes, then the 08:11 and 08:19 transmissions might have been 2 of 4 or more emergency messages…one complete and one partial. Bottom line…I suspect that the point of impact might have been at 08:11 or earlier, and the aircraft was trying to send messages every 2 minutes for at least 8 minutes after impact.
Fitzcarraldo said,
March 27, 2014 at 8:03 am
@ airlandseaman,
If you look at the slide shown by the Malaysian government to the families in Beijing (see Tim Farrar’s post):
http://tmfassociates.com/blog/wp-content/uploads/2014/03/Beijing-event.jpg
The Malaysian military lost track of the aircraft at 02:22 MYT 295 degrees 200 nm from Butterworth air base.
Salsero said,
March 27, 2014 at 8:34 am
@ airlandseaman
“turning from a generally east bound direction to either north or south direction (moving from a direction at 02:25 with relatively high radial velocity away from the satellite ….”
A ground speed of a plane flying at constant altitude translates into an “increase of distance to satellite”-speed of slightly over 10% of the ground speed. A change of altitude translates into only slightly below 100% change in the distance to the satellite.
So it could have been flying generally westward provided that at the same time it was descending. Maybe descending as quickly as in an emergency descent and that may have triggered the 3 aircraft initiated transmissions at 02:25.
Your explanation in respect of the 08:11 (and missing 07:40) transmission makes sense to me. So far down under connectivity with the satellite may be poorer.
airlandseaman said,
March 27, 2014 at 8:44 am
I would like to verify my interpretation of the Annex I Doppler data. As I understand it:
1. The vertical axis, “Burst Frequency Offset (Hz)”, is related to the sum of the satellite and aircraft Doppler (defined on page 1 of Annex I).
2. The first ACARS message at ~00:30 establishes the system bias = 87 Hz. Thus, the total s/c + aircraft Doppler can be derived by subtracting 87 Hz from all measurements, assuming zero bias drift.
3. The aircraft is known to have departed around 00:41 on a heading of 25 degrees, which would have been slightly away from the sub-satellite point. This establishes the sign (radial direction) for the vertical scale. It means increasing positive values greater than 87 Hz correspond to increasing radial velocity away from the sub-satellite point.
4. The apparent sign inversion, positive numbers corresponding to a lower Doppler frequency, is probably due to the the way the raw carrier frequency was processed in an IF stage, or similar. This is common in radio receiver architecture.
GuardedDon said,
March 27, 2014 at 10:13 am
Notes on recent comments:
@Alex Siew
re 1) satcom antenna install – the variant you describe is the high gain antenna variant (incl beam steering unit as it’s a phased array). 9M-MRO had low gain antenna.
@hal
Debris field – BEA, in the AF447 final report, describes recovering and cataloging 1000 pieces of floating debris.
@airlandseaman
re 2. 00:30MYT msg is likely to be the pushback/doors shut message via ACARS
re 3. 00:43MYT msg is likely to be the ldg gear door shut (i.e. actual departure time). At this time the aircraft heading will be in line with runway 7 WMKK’s runways are 326/146. They did depart to the north and then turn NE, the ADS-B data at flightaware/flightradar24 shows that.
I’ve been examining the available information around departure out to the first hour of the flight. I’m amazed to find that Malaysia has no ADS-B coverage, the nearest ADS-B GBTs (ground based terminals) are Singapore, Indonesia and Con Son Island/Vietnam. Malaysia’s two GBT stations are due later this year or next. There’s a gap in ADS-B receiver coverage for 9M-MROs route until it got into Con Son’s coverage. The flightaware/flightradar24 coverage is enthusiast supplied.
airlandseaman said,
March 27, 2014 at 10:19 am
Salsero:
I am skeptical about interpreting raw offset frequencies as indicative of a “dive???. A turn will change the Doppler much more than a dive. Even in a steep decent, the aircraft L/D would be >>1. For reference, at 5000/ft per minute and 450 kts the L/D would be 8.6.
That said, it would not be surprising to eventually learn that the aircraft made a steep decent at the same time it was tuning around 02:25. That would trigger the engine “emergency messages”.
AndRand said,
March 27, 2014 at 10:25 am
I have 2 questions:
1. Assuming for simplicity that relative speeds of plane and satellite cane vary from
- 144kmh (plane flying very close, perpendicular to radius plane-sat),
- thru 756kmh (plane flying north on radius plane-sat, along with sat movement)
- to 1044kmh (plane flying north on radius plane-sat, opposite to sat movement)
you receive respectively 0.02kHz, 1.05kHz and 1.45kHz frequency offset
http://www.ajdesigner.com/phpdoppler/doppler_equation_receding_receiver_new_frequency.php
Is it more than satellite’s receiver reading error?
2. If not – is still Ledgerwood version viable?
http://i59.tinypic.com/6e3fpt.png
XocoLatte said,
March 27, 2014 at 10:35 am
By having chosen the seemingly guesstimated 450/400 knots airspeed for possible ping locations and routes, Inmarsat had nothing else than comparison of burst freq shift values of other B777s on known trajectories, altitudes and speeds. I just postulate that the speed estimate was borne out of those comparisons.
Obviously, the scarcity of similar actual routes of known flights still provides a small and too solid basis for such estimations.
I just hope that they had a chance of comparing data originated from flights of 250 knots at lower altitudes, as well.
And just for being on the safe side, data of planes making circles as well…
(Any new measurement methods must be subjected to such extreme checks, otherwise there should remain a too big room for assumptions.)
XocoLatte said,
March 27, 2014 at 10:37 am
Correction of the above:
“Obviously, the scarcity of similar actual routes of known flights still provides a small and NOT too solid basis for such estimations.”
AndRand said,
March 27, 2014 at 10:50 am
I think it doesn’t matter at all.
You don’t need speed nor altitude nor position of the aircraft. If you get 1.45kHz offset when satellite is moving north than you know plane is going south and is positioned north of satellite.
Salsero said,
March 27, 2014 at 10:54 am
@airlandseaman
I am not a communications expert. Yet to me it appears that the Doppler effect that was talked about had to due with Signal compression. The Propagation direction of the signals is from the plane to the satellite, e.g along the hypothenusa of a triangle formed by the line from the satellite to the earth core until the Point where a line perpendicular to that line intersects with the Position of the plane.
That said, if the distance (as measured along that hypothenusa) between the plane and the satellite decreases, there is Signal compression, if it increases the Signal Stretches. In view of the height of the satellite relative to the distance to the plane along the perpendicular line referred to just now, an altitude Change translates almost to 100% in compression/stretching. The air Speed translates roughly only to 105 compression/stretching.
A 5000 fpm descent is not unusual for an aircraft like a 777
Salsero said,
March 27, 2014 at 10:56 am
please read 10% in stead of “105″
airlandseaman said,
March 27, 2014 at 11:17 am
Salsero:
Think of it this way. The horizontal speed is ~8 times the vertical speed in a steep “dive”. At an elevation angle of ~45 degrees, both the horizontal and vertical speeds are multiplied by root 2, so the geometry does not change the ratio much. If the aircraft was at the subsatellite point, all Doppler would be due to vertical motion. If the aircraft was on the horizon, all the Doppler would be due to horizontal motion. At a 45 degree elevation angle, its about equal. But the aircraft was moving 8 times faster in the horizontal, so most of the Doppler change would be due to horizontal motion.
I would really appreciate some feedback on my interpretation of Annex I page 2.
GuardedDon said,
March 27, 2014 at 12:01 pm
@airlandseaman,
In response to 4 points at 27 Mar 8:44
Re 1) I don’t believe anyone has defined whether that BRO data is the sum of doppler effect from I3-F3 and 9M-MRO or whether the known I3-F3 component has been calculated out. With Duncan’s data is it possible you run calcs for both?
Re 2) Aircraft stationary, doors closed & park brake off for pushback msg event, so yes it must be bias
Re 3) As per my reply above, the aircraft hdg at this event – I believe this to be wheels up/ldg gear door closed msg – will be that of the runway & I don’t at this time know if that was towards NW, I assume so but ground weather might inform.
Re 4) The L-Band return from the aircraft is multiplexed into a C-band downlink to GES. I’m assuming that telemetry (RTT measure, doppler shift) for individual AES transmissions is determined at the ground station.
GuardedDon said,
March 27, 2014 at 12:29 pm
@airlandseaman,
In response to 4 points at 27 Mar 8:44
Re 1) It must show the sum of both components as the satellite movement component is the differentiator.
AndRand said,
March 27, 2014 at 12:43 pm
Radius component derived from vector sum of airplane and satellite speed vectors relative to earth…
Salsero said,
March 27, 2014 at 2:31 pm
@airlandseaman
“If the aircraft was at the subsatellite point, all Doppler would be due to vertical motion. If the aircraft was on the horizon, all the Doppler would be due to horizontal Motion”
Yes, that is correct. But in the present case it is like the aircraft indeed being near the subsatellite Point. I do not have the numbers at Hand at the Moment, but from memory at earth Surface Level the arc between the subsatellite Point and the northern tip of Sumatra was pretty near 45 degrees, e.g. about 5000 km. With the satellite being at a height of about 35768 km, the angle between the line connecting the satellite with the centre of the earth and the line from the satellite to the North of Sumatra (at sea level) would be about atan(4515/(35768+1850)), e.g. about 6.8 degrees. So this does not mean “all Doppler is due to vertical Motion” but it does mean that the vertical Motion is pretty significant,
At the last Radar contact the plane was flying on a bearing of approximately 290. This was minutes before the 3 transmissions the first of which had a high shift. Instead of assuming that the aircraft had made an almost 180 degrees turn to fly east again in the small time span between loosing Radar contact and the first Transmission, to me it appears to be more Logical to assume that the aircraft started a steep descent (whether Pilot initiated or not), causing the transmissions and causing the loss of Radar contact.
Ole said,
March 27, 2014 at 2:35 pm
I think it’s possible to come up with a better accuracy for the round trip delay than the +/-300us required by the spec. McLaughlin of Imarsat said:
—————–
The engineers at Inmarsat were able to validate their estimates of the plane’s location by matching its position at 1:07 a.m., when it sent a burst of data through its Aircraft Communications and Reporting System, McLaughlin said. That final transmission on Acars included a GPS position that was used to calibrate the other estimates, he said.
——————
http://www.bloomberg.com/news/2014-03-21/missing-plane-flew-steady-speed-over-ocean-inmarsat-estimates.html
——————
The 1:07 transmission included an exact position. For that transmission the exact distance ground station->sat->aircraft is known. That can be used to calibrate the inherent response time of the transceiver. This should be possible for previous transmissions too, for transmissions from 0:30 until 1:07 as well as transmissions from previous flight, if the data is still in the logs.
With all this calibrated data points it should be feasible to establish the jitter in the transmitters response time. If the jitter is significant less than 300 us then that helps to get more accurate lines of position.
Salsero said,
March 27, 2014 at 2:51 pm
@airlandseaman
“If the aircraft was at the subsatellite point, all Doppler would be due to vertical motion. If the aircraft was on the horizon, all the Doppler would be due to horizontal Motion”
Yes, that is correct. And in the present case it is like the aircraft indeed being near the subsatellite Point. I do not have the numbers at hand at the moment, but from memory at sea level the arc between the subsatellite Point and the northern tip of Sumatra was pretty near 45 degrees, e.g. about 5000 km. With the satellite being at a height of about 35768 km, the angle between the line connecting the satellite with the centre of the earth and the line from the satellite to the North of Sumatra (at sea level) would be about atan(4515/(35768+1850)), e.g. about 6.8 degrees. So this does not mean “all Doppler is due to vertical Motion” but it does mean that the vertical motion is pretty significant,
At the last radar contact the plane was flying on a bearing of approximately 290. This was minutes before the 3 transmissions the first of which had a high shift. Instead of assuming that the aircraft had made an almost 180 degrees turn to fly east again in the very small time span between loosing radar contact and the first transmission, to me it appears to be more logical to assume that the aircraft started a steep descent (whether pilot initiated or not), causing the transmissions and the loss of Radar contact and explaining the doppler shift
Ole said,
March 27, 2014 at 2:57 pm
To my understanding, the Burst Frequency Offset is only that component of the doppler shift that results from the relative movement between sat and aircraft. There is no component attributed to the aircraft’s movement, because the transceiver already compensates that. So the depicted BFO imho only depends on whether the sat moves towards or away from the aircraft. Aircraft’s speed vector doesn’t matter because it’s already compensated for (imho). The only thing that matters is component D2 in this slides:
http://www.malaysiaairlines.com/content/dam/mas/master/en/pdf/Annex_I_images.pdf
Maybe the bigger frequency offsets around 18:25 utc indicate a failure of the transceiver to adequately compensate for the aircraft’s speed, so that a part of D1 becomes visible.
hal said,
March 27, 2014 at 4:01 pm
Fun things to do with the Burst Offset Chart:
1 – Sliding the graph down to align the starting point (pushback stationary) with y = 0, gets rid of the bias or built-in offset, and makes it easier to visualize the north-south difference.
2 – If all they have is doppler (relative velocities) and not loop time (proportional to distance) then there are many ways you camn slide the “north” plot over the “south” plot looking for equivalences.
Have fun!
airlandseaman said,
March 27, 2014 at 4:09 pm
I tracked down the Flight Aware data for SQ68 and MH370, and the radar data fro MH370. . Using the ADS-B data for the SQ68 flight and the radar data for MH370, it cane be shown that MH370 and SQ68 were both headed in the same direction at 02:22, but MH370 was 100 NM behind SQ68. In addition, MH370 was about 20 NM to the left of the SQ68 track.
UTC Local EST Lat Lon Heading Lat Lon Heading
18:02 2:02 01:02PM 6.6576 98.2648 312° 5° 41′ 28″ 98° 55″ 28 306.5
01:03PM 6.7386 98.1731 312°
01:04PM 6.8197 98.0814 312°
01:05PM 6.9007 97.9896 312°
01:06PM 6.9817 97.8979 312°
01:07PM 7.0627 97.8061 312°
01:08PM 7.1436 97.7142 312°
01:09PM 7.2245 97.6223 312°
01:10PM 7.3055 97.5304 312°
01:11PM 7.3864 97.4385 312°
01:12PM 7.4672 97.3465 312°
01:13PM 7.5481 97.2545 312°
01:14PM 7.629 97.1625 312°
01:15PM 7.7098 97.0704 312°
01:16PM 7.7906 96.9783 312°
01:17PM 7.8714 96.8861 312°
01:18PM 7.9521 96.7939 312°
01:19PM 8.0329 96.7017 311°
01:20PM 8.1136 96.6095 311°
01:21PM 8.1943 96.5172 311°
18:22 2:22 01:22PM 8.275 96.4248 311° 6° 52′ 03 97° 20′ 21 306.5
Alex Siew said,
March 27, 2014 at 4:10 pm
1. Antenna
GuardedDon, Tim had earlier indicated that MH370 was using Swift64 or Aero H/H+. These terminals/services use a high gain antenna, according to what is stated on the Inmarsat website. H in fact stands for high. Inmarsat also offers Aero I which uses an intermediate antenna and Aero L which uses a low gain antenna.
2. Pings
airlandseaman, the statement accompanying the doppler effect chart stated that there were 6 completed handshakes. The Malaysian authorities have gone on record to say that Boeing and Rolls Royce have confirmed to them that the last ACARS was at 1.07am. Reading the chart, it means one of the 2.25, 2.27 and 2.30 transmissions was a completed handshake, most likely the 2.30 transmission. Has anyone said anything about the 2.25 and 2.27 transmissions being initiated by the plane. It could have been the satellite trying to connect with the terminal on board and finally succeeding at 2.30.
Duncan has pointed out that the satellite was moving north until 3.36am when it began to descend southwards. The relative doppler effect readings for the 6 completed handshakes would not be inconsistent with a plane that had already crashed (the satellite was moving closer to the plane until 3.36 and moving away from the plane after that).
3. Inmarsat
In coming out with the northern and southern arcs, Inmarsat had apparently overlooked the fact that their satellite was not stationary and not directly above the equator. Hopefully they had not overlooked the possibility that the RT timings were getting longer not because the plane was moving away from the satellite but because the satellite was moving away from the plane. The RT timings, when released, should be able to tell which is which.
duncansteel said,
March 27, 2014 at 5:20 pm
Might I say something that surely is obvious, and yet no-one appears to have said it yet?
One way to interpret observational data (here: the time delays and the doppler shifts in the Inmarsat ping receipts) is to try to duplicate it in a simulation. I have tried doing that, to some extent, in an STK scenario (which uses a properly-shaped Earth, has a great physics engine, etc etc). However, that’s still just a software simulation.
So how about a hardware simulation?
That is, rather than flying search planes willy-nilly around the southern Indian Ocean, what might be really useful would be flying another jetliner equipped with the same gear across the same range of estimated routes of MH370, have Inmarsat-3F1 pinging it every minute, and see how the ping receipt data compares with the actual data from the flight of MH370.
One might also engage the civilian and military (if agreed) radars to see what they might, and might NOT, have detected early in the flight (the first few hours, before it apparently headed out over the ocean).
The flight(s) of this MH370-simulant would need to be phased against the orbit of Inmarsat-3F1 properly, rather than at the same times of day (UTC) as MH370, because geostationary satellites have orbital periods equal to a sidereal day rather than a mean solar day.
Call me a simpleton, but surely the above would cost less (and perhaps be quicker) than flying planes and sailing ships around the ocean with an ill-defined search region?
And I’d invite all readers to flag this suggestion to their local/national media.
Ciao,
Duncan Steel
airlandseaman said,
March 27, 2014 at 5:35 pm
Duncan:
At the end of the day, the most important question is: What was the airspeed? If that was known from any independent hard factual source, or if that could be computed from an improved model, instead of assuming a value, the analysis would be far more believable. Gotta get the data and do a global LSF of all the observables (and reasonable constrains), but without constraining the speed.
Fitzcarraldo said,
March 27, 2014 at 6:01 pm
This is very frustrating. All I want is for the Malaysians to publish a list giving the distance to the aircraft from Intelsat 3-F1 at the contact times 02:29, 03:40, 04:40, 05:40, 06:40 and 08:11 MYT. Duncan Steel has already provided the coordinates of Inmarsat 3-F1 at each of those times so, if we were given the distances, we could plot any speed scenario we wanted.
Anyway, in the absence of published distance data from the authorities, I have calculated, as best I can, distances from the satellite (i.e. the handshake arcs) by using the poor-quality graphic ‘Example Southern Tracks’ published by the Malaysian MOT on 25 March. Actually I don’t trust that graphic; I have a feeling it is more schematic than to-scale. Furthermore, the scale is too coarse, the tracks too thick and the lengths do not look correct to me. Furthermore, Google Earth does not represent the Globe correctly so coordinates and distances don’t correlate properly. So please treat the following Google Earth graphic I produced as very approximate:
http://i2.photobucket.com/albums/y9/imageuser/MH370_-_Rough_calculation_of_example_flight_paths.jpg
The white circles — which, as Duncan Steel pointed out previously, would not be perfect circles in reality — show the distance from the satellite at the time of the handshake (03:40, 04:40, 05:40, 06:40 and 08:11 MYT). I have centred each circle on the coordinates for the satellite at the time the handshake occurred.
I have assumed the aircraft turned south at circa 02:30 MYT and have plotted flight paths for speeds of 400 knots (orange), 420 knots (green) and 450 knots (red) from the turn south. The three yellow placemarks indicate the first three locations where possible debris was spotted.
Given that:
a) the contact times were not 03:11, 04:11, 05:11, 06:11, 07:11 and 08:11 as we were originally led to believe;
b) the first handshake was apparently at 03:40;
I have assumed the Inmarsat spokesman’s statement quoted by Jeff Wise applied only from 03:40 onwards, as the contacts from 03:40 onwards were handshakes and the contacts before 03:40 were not just handshakes.
If you look at the green flight path you could believe MH370 was heading for the Pole. Perhaps that’s what someone in the cockpit did: set the autopilot to head for the South Pole waypoint, knowing fuel starvation would occur at around 08:30 MYT and the aircraft would drop into the ocean somewhere below latitude S30°.
Regarding waypoints, the Boeing AERO magazine (see comment by GuardedDon on March 26, 2014 at 3:21 pm) mentions ’99SP’ and ‘S90EXXXXX’ or ‘S90WXXXXX’* as acceptable waypoint entries in the 777 FMC for the South Pole, although I notice Qatar Airways’ 777 training manual only mentions ‘S90EXXXXX’ and ‘S90WXXXXX’ (http://www.737ng.co.uk/B777%20FCTM%20Flight%20Crew%20Training%20Manual.pdf). Anyway, even if a waypoint name does not exist the flight crew can enter coordinates instead into the FMC.
* Replace ‘XXXXX’ with the actual coordinate, so the waypoint would be e.g. ‘S90E89000′.
Solo said,
March 27, 2014 at 7:35 pm
Search Zone Moved:
“The Australian-led search for missing Malaysia Airlines flight MH370 has shifted 1,100km to the north-east after investigators calculated the plane was going faster and using more fuel when it disappeared than previously thought.
The Australian Maritime Safety Authority (Amsa) said the analysis was based on the plane’s final radar contact between the South China Sea and the Strait of Malacca, and suggested the plane would have burned more fuel in the opening stages of its flight. It therefore would not have made it as far into the Indian Ocean before running out of fuel and crashing.”
From:
http://www.theguardian.com/world/2014/mar/28/flight-mh370-search-zone-moved-based-on-planes-fuel-consumption?commentpage=1
***********************
Perhaps the 01:22 to 03:40 narrative is still in flux
airlandseaman said,
March 27, 2014 at 7:38 pm
The new analysis verifies that they didn’t know what the speed was. Moreover, the CNN report stating that it was going faster than previously thought, and thus ended up 1000 km NE, is impossible. The lower the speed, the more the path clocks back to the east and north. The faster it went, the more the path will clock to the west (assuming fuel was available). They have it backwards. You can plainly see that on Page 3 of Annex I. Therefore, the latest report must be carefully scrutinized. It probably did go much further NE,but it did so because the speed was lower, not higher.
airlandseaman said,
March 27, 2014 at 7:42 pm
Jeff’s latest blog:
http://jeffwise.net/2014/03/27/why-did-australia-change-the-search-area/
meadows.st said,
March 27, 2014 at 8:36 pm
@airlandseaman
At first I agreed with your analysis then when I was looking at the Wind and Wave animated graphics for Mar 9 – Mar 26 at NYT article, you might have to Google to get access I realized that if the plane was on a heading of 180 (or close to it) at closer to cruising speed (490+ knots) then it may not have gone as far south and the currents and winds (consistently in excess of 40 knots and very consistently from the West) would have pushed the debris field substantially to the East (3 knots for 10 days = 720 nm). Note too that the NYT graphic shows very moderate winds over most of the area of the flight on Mar 9th and no substantial change in the wave patterns so wind patterns were likely fairly consistent on the 8th (ASSUMPTION based on evidence). So, even if the airplane had tracked further west (due to faster speed, less headwind than originally estimated) then the debris field could be substantially further East.
Still, I would feel better if they could get eyes on the two satellite-spotted sets of floating objects before devoting all search resources to the new area.
ideaswork said,
March 27, 2014 at 8:50 pm
@airlandseaman and Jeff wise
This media release showed the new search field is at the end of the 400 knot arc. Not higher speed, since previously were more aligned with 450kt.
https://s3-ap-southeast-2.amazonaws.com/asset.amsa.gov.au/MH370+Day+11/Charts/2014_03_28_cumulative_search_tv.pdf
Confusing.
ideaswork said,
March 27, 2014 at 9:09 pm
@meadows.st
Sorry I didn’t see your post before I posted the last comment.
I agree with your analysis. The new search box (of course) is for the debris, not crash site which could be west.
Noticed that the new 469 and 475 kt tracks.
hal said,
March 27, 2014 at 9:15 pm
The press release says it was traveling faster while being tracked by radar over the Malay peninsula, *not* after it turned south. So I don’t think it is a misstatement (accidentally saying “faster” when they meant “slower”).
Leaving the southward leg at 400-450 knots, the plane would’ve run out of fuel sooner and the search area should be shifted northward, not northeast.
BUT remember this plane has an appointment with destiny at 8:11 am, the last full ping. With less fuel at the moment of turning south it would not have enough fuel to be in the air until 8:11 am, so it must’ve slowed down for the southward leg.
So I’m guessing than when they learned the westward speed had to be adjusted upward, they adjusted then southward speed downward in order to hold constant the 8:11 am appointment with destiny.
Scott Henderson said,
March 27, 2014 at 9:41 pm
Hal watching the press conference live there was a very subtle suggestion also that the increased speed was for the radar tracked leg only. But it was far from explicit.
hal said,
March 27, 2014 at 10:26 pm
Hi Scott. I did not see the press conference but Jeff Wise quotes the press release as follows: “The search area for missing Malaysia Airlines flight MH370 has been updated after a new credible lead was provided to the Australian Maritime Safety Authority (AMSA)… The new information is based on continuing analysis of radar data between the South China Sea and the Strait of Malacca before radar contact was lost. It indicated that the aircraft was travelling faster than previously estimated, resulting in increased fuel usage and reducing the possible distance the aircraft travelled south into the Indian Ocean.”
It should also say “reduced the speed with which the aircraft travelled south into the Indian Ocean.” But perhaps that is just us geeks being picky. Not sure the average listener will have detected a problem at all … other than the constant change in what’s considered “credible.”
Scott Henderson said,
March 27, 2014 at 10:48 pm
The AMSAs tracks are now much shorter / further north. They would appear to barely touch the 8:11 arc. I read into this (perhaps too much of a stretch) that they don’t believe it was in the air for much longer after 8:11. Perhaps they think the 8:19 ping event was related to water impact?
I haven’t read all the posts above in depth, but am I correct in assuming all the arcs have moved north due to the satellite’s position above the equator during the flight-time?
duncansteel said,
March 27, 2014 at 10:51 pm
This is just to say that I have put up another post on my website, at
http://www.duncansteel.com/archives/419
…in which I look into the effect of using “equal-range” ping rings rather than “equal-elevation-angle” ping rings.
Conclusion:
“If the ping time delay uncertainties are as much as ±0.3 milliseconds then that uncertainty/imprecision limits the determination of the location of MH370 at the times of the pings via Inmarsat-3F1. Under that circumstance the real shape of the Earth makes only a minor difference to the ping ring determinations, in a comparative sense. If, however, the ping time delay uncertainties are rather smaller, as some have suggested to me, then analysis of the ping time delays aimed at deriving possible routes taken by MH370 must include the detailed shape of the Earth (plus, of course, the locations of the satellite at the times of the pings).”
Ciao,
Duncan Steel
Scott Henderson said,
March 27, 2014 at 11:07 pm
@Hal When I first heard the search area had moved north, but the aircraft’s speed was determined to be higher, the first thing that came to mind was they had determined there was a significant net headwind for the southerly heading component. However there is still no explicit evidence this has been factored in. Changing the airspeed along the track introduces a new variable – and I hoped this was not the case!
seanhelmi said,
March 27, 2014 at 11:08 pm
I understand that the ping transmission from the aircraft did not include any content not even a timestamp. Therefore how can the transmission time be accurately determined? The burst time offset would seem to require precisely fixed times of transmission by the aircraft, which in turn would seem to require a very precise clock onboard the aircraft, essentially an atomic clock– not so? Moreover the clock would have to be synchronized with the satellite clock — how is that done? Also I thought the satellite initiated the handshake by sending the first transmission to the plane, and the plane replies. That gives an RTT, however, what is the time between receipt of the transmission by the plane and transmission of the return? If this is a known fixed interval, then the transmission time from satellite to plane (from which distance can be determined after correction for relativity etc.) is the time onboard the satellite from transmission to receipt of return signal less the fixed interval. But that would also require a very accurate clock onboard the aircraft.
I have no expertise in this and have been unable to find a solution online. Any technical information would be greatly appreciated. Thank you.
timfarrar said,
March 27, 2014 at 11:19 pm
Seanhelmi,
The ping is initiated as a handshake by the satellite based on a timeout. The time is therefore known regardless of whether there is a timestamp embedded in the handshake itself. Furthermore, the time offset is estimated relative to the frame in which the transmission from the terminal should take place. That is the reference, not some absolute (atomic clock) timing.
timfarrar said,
March 27, 2014 at 11:29 pm
hal,
I think you are correct. As I read it, the speed/fuel consumption earlier was higher, so that in order to still be in the air at 8.11am, the plane must have traveled more slowly in the later period of the flight. As a result, it can’t have travelled as far. This has led to the northerly shift in the search area.
What concerns me now is that it is clear that the uncertainty in location along the ping arc is much greater than previously anticipated, because of the changing estimates of fuel, so the search area is correspondingly greater. I would also agree that it brings the magnetic bearing heading (and therefore the “ghost plane” hypothesis) back into play, though this hypothesis is unlikely to be consistent with the Malaysian military radar track (which is included in the calculation of potential travel time).
I think it is likely that the 8.19am partial ping relates to a final orientation change in the plane relative to the satellite. However, it now appears that the primary driver of uncertainty in the search area is the available fuel rather than the remaining flight time after the 8.11am ping.
GuardedDon said,
March 28, 2014 at 12:02 am
Ole: The +/-300 usec is spec’ed within the AES user terminal – it’s implicit in the data link layer of the comms and so it’s deterministic, any data messages from other systems traverse the application layer, they get to the Satellite Data Unit via a LAN & there’s nothing to validate such timings.
Alex Siew: Antenna type – I started out considering the antenna type as a consequence of Malaysia Airlines’ statement that 9M-MRO wasn’t subject to the structural AD. All photography I could find, even limiting image searches to this year, shows Malaysia Airlines B772 fleet 9M-MRA thru MRO with low gain antennas.
airlandseaman said,
March 28, 2014 at 12:08 am
The new math is more flawed that the original. It is simple vector math, really. If the speed assumption is reduced, the whole path moves to the east and ends up on the final LOP further north. If the speed was higher, it moves to the west. The new statements that the plane was traveling faster, burning fuel faster and ended up 1100 km NW on the final LOP at 08:11 or 08:19 is obviously impossible. Even a fool can see that you cant run out of gas an hour sooner and still fly for the same time, no matter where you end up. It’s completely ridiculous as reported.
airlandseaman said,
March 28, 2014 at 12:33 am
For those wondering about winds…there are readily available, and fairly accurate numerical models of the winds fields for any time, any Lat/lon and altitudes, globally. NCEP and ECMWF produce new models several times per day in near real time. Many universities and institutions like NCAR produce winds also. Moreover, winds are measured directly every 12 hours by radiosondes at about 1000 sites scattered around the world. You can download the winds for about 20 sites in the area March 7-8 here:
http://weather.uwyo.edu/upperair/sounding.html
The radiosond launced from Learmonth Airport at 12Z 07 Mar 2014 shows winds very light (10 kts typical) between 12,000 – 35,000 feet.
It is worth repeating here that the Phuket radiosonde showed three upper level temperature inversions, known to cause anomalous propagation at microwave frequencies, due to reflection and refraction. It has been my belief from the beginning that these temperature inversions are the most likely explanation for the confusing radar altitudes reported.
airlandseaman said,
March 28, 2014 at 12:53 am
Regarding the estimation range, obtained by estimating the free space propagation time between the spacecraft L band antenna and the aircraft L band antenna (range = single path delay/speed of light)…
This propagation time delay measurement is based on the direct, routine measurement of the time delay between a pulse sent from the ground station up to the satellite, repeated down to the aircraft radio, a return pulse that must be sent <300 usec after receipt of the downlink outbound pulse, relayed by a different transpnder back to the ground station. So, there are 4 paths ~ 23000 miles each in the round-trip. There are small delays in the earth-station T/R equipment, outbound transponder, aircraft radio, and the inbound transponder. But all these bias delays are very well calibrated. So the satellite-aircraft net delay is easily, and routinely measured. The accuracy of the measurement is probably on the order of 10 usec. The aircraft 300 usec Minimum spec is not indicative of the random noise on the measurement. It is simply a maximum to limit the search range. A given design might be 100 usec or 250 usec, but it changes very little from transmission to transmission.
Ole said,
March 28, 2014 at 1:36 am
airlandseaman said,
March 28, 2014 at 12:53 am
That is my understanding too. The limiting factors to the precision of measurement of propagation delay are the noise/jitter introduced by the AES, the up/down converters in the sat, and delays in the ground station. That should be largely deterministic and can be calibrated against previous pings to the same AES.
GSM requires the propagation delay to be known with a precision that equals 550 meters i.e. <4us (taking into account it's out and return). A precision in the range of 10-20 us (3-6km) seems imho realistic.
The precision to which the propagation delay is logged shouldn't be an issue either. With two bytes written to the log file, the hemisphere of the earth can be cut into 65536 slices. With an earth radius of 6371km that gives slices of ~100m. So with two bytes, slices of 100m can be addressed.
As all measurements are conducted in the ground station, it is more likely that the measurement equipment is updated to state of the art.
airlandseaman said,
March 28, 2014 at 1:44 am
Some have suggested that we should interpret the breaking news to mean that the aircraft was travelling faster only before radar loss, and by implication, slower than previously believed after radar loss, thus ending up 1100 km further NE. I could believe that. But if this is the case, it reveals something important. It means they are estimating speed from an assumption about the total fuel at TO and the integrated burn rate over the path. This in turn means they must be assuming a high altitude after 02:22 (or 03:40?). As I have noted, a slower speed at a lower altitude can give you about the same fuel exhaustion time. If the altitude assumption is wrong, the speed is also wrong.
XocoLatte said,
March 28, 2014 at 2:02 am
With this new search area the Aussie authorities actually told us that it is practically possible (with high certainty) to fly on a limited amount of fuel for the same period of time while covering a shorter range by flying more slowly.
Does this make any sense in terms of aviation principles?
One would need an approximately fixed starting location (let us call it the point of turning to the South/Southeast at about 02:30) from where it is indeed possible to draw multiple ranges to the 8:11 LOP line and obtain variable airspeed values. The slower the speed the shorter the range, i.e., the more Eastward and Northern the endpoint on the 8:11 LOP curve.
The major problem with this that it seems like they have no fcking clue about actual average airspeed (and altitude) of the airplane from this turning point, so from now, all and every covered range scenario should be given a chance within reasonable range of airspeed values, like above 250 knots.
XocoLatte said,
March 28, 2014 at 2:09 am
airlandseaman: how strict is the interrelationship between airspeed and altitude? If I understand your last comment you inferred that there is quite a limitation to save fuel (and thus increase effective range) by flying more slowly at any given altitude.
AndRand said,
March 28, 2014 at 3:00 am
duncansteel said,
March 27, 2014 at 10:51 pm
This is just to say that I have put up another post on my website, at
http://www.duncansteel.com/archives/419
…in which I look into the effect of using “equal-range??? ping rings rather than “equal-elevation-angle??? ping rings.
I am wondering why are you calculating equal-range rings?
I think it should be equal-elevation rings… but not of the satellite – of the aircraft, so more “equal-altitude rings” (which can be assumed as mean altitude 5-10km with 35k km distance from satellite).
duncansteel said,
March 28, 2014 at 3:36 am
Sorry, AndRand, you are misunderstanding the part of the problem I have been addressing.
The ring I have calculated is indeed a ring for equal-range (equal distance in three dimensions) from the satellite, and therefore equal values of the ping time delay. That ring therefore (for a given measurement of a ping time delay) delineates a set of loci of where the aircraft could have been at the time of the ping.
This has no connection with the flying range of the aircraft (except that the arc forming part of the ping ring is clipped at each end by the maximum flying range of the aircraft, given a speed and fuel availability).
To repeat what I think I wrote earlier: I am considering only the ‘space’ component of the problem, not the ‘aviation’ component.
Ole said,
March 28, 2014 at 4:02 am
I have the impression there are mainly two flight paths that can be fitted to the ping data.
One is the great circle which probably needs a higher fuel burn rate to be fitted to the ping arcs (including the unpublished arcs).
The second is the constant magnetic heading path which probably needs a lower fuel burn rate.
Because the total flight time is known (until 08:11), the fuel burn rate only depends on the fuel remaining at the point where MH370 turned south.
If all the points on the 8:11 arc had the same probability, then it wouldn’t make sense to shift the search area by 1000 km, just because of some new info on the available fuel when turning south.
Also the AAIB map seems to indicate that there are two high probability paths: yellow great circle and red constant magnetic heading. There may be no conceivable way for the aircraft to get to other points on the arcs in the given flight time. For math equations it’s normal that two possible solutions are not adjacent.
seanmcleod said,
March 28, 2014 at 4:40 am
Given the Doppler data and the satellite’s known velocity vector at each ping and then assuming an aircraft speed, e.g. 400kts, 450kts etc. presumably the angle of the aircraft’s track can be calculated for each speed along each point of each ping arc?
For example given the suggested 450kt and 400kt tracks when they hit the last ping arc do they both produce the same Doppler shift as what was recorded for the last ping?
GuardedDon said,
March 28, 2014 at 4:50 am
Another consideration from a view of the whole aircraft system:
I certainly agree that higher speed “en-route??? through the locations identified by the 4 equally timed log-in DV transmissions would result in a more extreme SW crash location and, conversely, slower speed takes that final location NE, back towards Australia. The heading demanded of the 777′s AFDS should be capable of interpolation from the RTT and UTC time for those comms events (facts known only to the investigation team).
Consider that the aircraft uses asymmetric thrust to maintain heading (it’s more aerodynamically efficient than rudder offset).
The fuel system is designed so that the centre tank fuel load is consumed first, its pumps can be switched off manually or there’s automatic shutdown after 15sec of low pressure. After the centre tank is exhausted each engine consumes fuel from its adjacent main tank in the wing. These tanks are filled with equal weight of fuel.
Now consider the electrical system: the normal is for both engines’ integrated drive generator (IDG) to share the electrical load. If an engine fails & IDG supply is lost then the system sheds load, cutting power to non-essential services (anything not essential to flying the aircraft). The satcom SDU is non-essential flight service. The flight crew procedure for an in-flight engine shutdown includes an air start of the APU to bring back supply capable of restoring all aircraft services (I recall that during B777 development and certification that air-start of a cold APU was essential, and a big challenge to meet, for ETOPS certification).
In the situation here, when one engine flamed out the APU would not have been started and the aircraft will have flown on without the satcom capability. It’ll be flying more slowly until the second engine flamed out.
So I expect the investigation team’s extrapolation to final location is based on constant speed (apparently 00:11UTC or maybe 00:18UTC ) until the first engine experienced fuel starvation then some assumption of lower speed based on the endurance of the other engine.
Given that this course appears close to due south from KUL I’d expect a load of modelling to be support the asymmetric thrust & fuel starvation points as its not a route that an airline would have data for.
GuardedDon said,
March 28, 2014 at 4:55 am
I omitted to mention how fuel crossfeed is handled: it’s a manual intervention. An ECAM warning of low fuel level and crew manually open the crossflow valves.
AndRand said,
March 28, 2014 at 5:00 am
duncansteel said,
March 28, 2014 at 3:36 am
To repeat what I think I wrote earlier: I am considering only the ‘space’ component of the problem, not the ‘aviation’ component.
I am not addressing ‘aviation’.
If you have a cone with satellite at given position at 10 668 km elevation, and aircraft at known distance (from response time) and known/assumed altitude (ie. 10km – it can be assumed almost earth surface) of aircraft I think you can have only one inclination for ping.
Thus I am wondering why you calculate several elevation angles while it can be only one at given distance and elevations of satellite and aircraft.
Plus/minus uncertainty.
I just wouldnt base calculations on elevation angle but on distance to 10km over surface level.
And this is what is shown in your equal-range calculations. I would say that with altitude assumed the Earth irregularities are neglible.
Ole said,
March 28, 2014 at 5:02 am
seanmcleod
to my understanding the doppler shift in the diagram is only the component of the doppler shift that results from the movement of the sat relative to the aircraft’s *position*. The aircraft’s speed is already compensated for by the terminal (AES), and thus no conclusions on the aircraft’s speed are possible.
The difference in predicted doppler shift for northern or southern route results from the aircraft being at different positions when taking one or the other route. The predicted difference does not result from the aircraft having different speed vectors on the routes.
If someone contradicts I’m happy to change my opinion.
seanmcleod said,
March 28, 2014 at 5:20 am
Ole
The released image – ‘Doppler correction contributions’ mentions the following for D2.
“D2 is a combination of the Doppler components due to the satellite motion, which is accurately known, and the aircraft heading and speed.”
Indicating that it’s both the satellite’s velocity vector and the aircraft’s velocity vector.
And given an assumed aircraft speed, e.g. 400kts, 450kts etc. then you should be able to work out the aircraft’s track (not heading as mentioned) for each ping.
Ole said,
March 28, 2014 at 5:47 am
seanmcleod,
you are right. But the formula
Total Doppler=D1+D2+D3
gives a different impression. Probably the terminal can only compensate D1 to a certain extend with some parts of the doppler component of the aircraft’s speed remaining. For predicting D2 one would then need a model of how the terminal compensates and what residual doppler component remains. With this model one could then calculate the predictions.
The question then is, what conclusions can be drawn from the doppler component of the aircraft’s speed which remains after compensation.
duncansteel said,
March 28, 2014 at 6:00 am
Sorry, AndRand, that is still not meshing against what I have done and what I have described on my website.
The satellite (at the time in question) was at a known position. We don’t know where the aircraft was (!), but I have assumed that it was at an altitude of 10.668 km (35 kft). I do not know a ping time delay, because Inmarsat has not released the data. I do know from a graphic issued on March 15th that the elevation angle from MH370 to a certain position in orbit was near 40 degrees, derived from the ping time delay. I can use that information to derive a time delay, in principle.
However, that ‘certain position’ was assumed, apparently by Inmarsat, to be 35,800 km directly above the equator at a longitude of 64.5 degrees. *I* now assume that the people doing the calculations also assumed that the aircraft was at 35kft and also above the equator (hence an Earth radius of 6,378.137 km). That gives me a triangle from which I can calculate a range from the fictitious satellite to the aircraft, and the answer is 37786.588 km and so the time delay was near 126 milliseconds.
Now, I use that as an evaluation of the measured time delay, because that specific information has not been made available directly. However, the measured time delay in reality is subject to some uncertainty, just as your height cannot be determined precisely: there’s always some error bar. From information posted earlier on this discussion thread I believe that the time delay measurement uncertainty is +/-0.3 milliseconds. I can factor that in and therefore get a range of possible elevation angles from the aircraft to the satellite, and the answer is 38 to 42 degrees, allowing reasonable bounds including the fact that Inmarsat apparently rounded its value to 40 degrees. Those extremal angles 38 and 42 degrees can also be represented as a range in km (37,635 and 37,943). The process there is: range of time delays gives me a range in satellite-aircraft ranges gives me a range of elevation angles (for the visualisation).
Now I turn to the real satellite. I know where it was at the time in question. Using the above ranges (37,635, 37,787 and 37,943 km) I can now calculate geographical locations (lat and lon) at which the aircraft (at 35 kft) fulfils the condition that it be at a certain range from the satellite. For the ‘nominal’ time delay of 126 milliseconds I did this in 1-degree steps in latitude from 35S to 35N, hence producing the 71 green dots/positions in my graphics (http://www.duncansteel.com/archives/419). I also did it at just one latitude (15S) for the time delays (or satellite-aircraft ranges) equivalent to elevation angles of 38, 39, 41 and 42 degrees, so as to show the spread in feasible values given the uncertainty of +/-0.3 milliseconds in the time delay value. Those I show as four red dots.
And that’s what my graphics show. At the time of the final ping the aircraft was somewhere near the green line in my graphics; the amount it could have been away from that green line is indicated by the spread of the red dots.
If Inmarsat would release the measured time delays for all six (or more) pings we could all plot similar lines giving possible aircraft positions at each of those times. And that might help in narrowing down the search region.
airlandseaman said,
March 28, 2014 at 6:17 am
XocoLatte:
Regarding fuel consumption, a Delta 777 manual contains the following. These data may not be exactly the same as for the MH370 aircraft, but the trends will be the same.
Altitude (ft) TAS (kts) Fuel Burn (PPH/Engine)
0 0 3000
12000 310 6600
18000 374 6300
24000 482 6800
30000 440 7200
36000 473 7100
41000 462 6700
From these data we can see that the often repeated statements that more fuel is burned at lower altitude is simply wrong, or at least highly misleading. Of course, more fuel may be burned as you go down, but only if the airspeed is maintained as high as possible for a given FL. One can certainly choose a TAS at 12000 or 18000 feet that results in the same fuel burn rate ar 41000 feet. But the aircraft will be going much slower (300-400 kts). This is crucial. There is no data I am aware of supporting the assumptions for speed after loss of radar (02:22 local). They seem to be assuming an altitude, from which they deduce a speed, from which they they derive the position at 08:11. IMHO, this is a high risk assumption. We know from the Doppler that there was some type of a relatively rapid change in speed and/or direction at ~02:25, which given the the uncertainty in the Annex I, pg 2 chart, might actually be at the same time as the loss of radar (02:22).
I am fairly confident that the working group has a good model at this point. I’m sure they have wind in the model. I’m sure they are considering both of the possible auto pilot headings (tracks). The physics are well known, and so is the vector math. Satellite geeks do this all the time. They may even be using a single Kalman filter to solve for everything at once now. But at the end of the day, even with a perfect model, they are assuming a speed model after loss of radar, which could still be way wrong, simply because they are assuming a cruise altitude.
AndRand said,
March 28, 2014 at 6:26 am
duncansteel said,
March 28, 2014 at 6:00 am
If Inmarsat would release the measured time delays for all six (or more) pings we could all plot similar lines giving possible aircraft positions at each of those times. And that might help in narrowing down the search region.
Now I get it that you were doing a walkaround.
It was bit awkward for me that knowing satellite position, distance from aircraft and its alltutude you generate several possible rings, while it can be calculated directly with slant range formulas.
airlandseaman said,
March 28, 2014 at 6:27 am
It would sure be nice to know what data, if any, was transmitted during those three “emergency engine report” around 02:25. If they did get ambient pressure from those 3 tweets, they would sure know much more than has been disclosed about the altitude and VAS at that point, without any dependence on radar.
hal said,
March 28, 2014 at 6:38 am
airlandseaman said: “But if this is the case, it reveals something important. It means they are estimating speed from an assumption about the total fuel at TO and the integrated burn rate over the path. This in turn means they must be assuming a high altitude after 02:22 (or 03:40?). As I have noted, a slower speed at a lower altitude can give you about the same fuel exhaustion time. If the altitude assumption is wrong, the speed is also wrong.”
xocolatte said: ” With this new search area the Aussie authorities actually told us that it is practically possible (with high certainty) to fly on a limited amount of fuel for the same period of time while covering a shorter range by flying more slowly. Does this make any sense in terms of aviation principles?”
The plane was tracked at 12000 feet over the Malay Peninsula. My guess is that they’ve simply left it at 12000 feet, in which case the simple additive model of speeds (westward and southward) holds. I don’t know the aviation aspects of this: What would cause a plane to climb? If human controlled, I believe they would keep it low to avoid other traffic AND in the hope that someone on the ground/sea sees them. If autopilot, it wouldn’t climb unless programmed in, correct?
@ole – My understanding is that doppler is the sum of the two motions. Consider the old Einstein thought experiments of people on trains.
Ole said,
March 28, 2014 at 6:46 am
hal,
“My understanding is that doppler is the sum of the two motions.”
But then what do they mean by D1 (which I understand as doppler due to aircraft location heading and speed ) ?
airlandseaman said,
March 28, 2014 at 7:03 am
hal: They must be assuming a high altitude, not 12K ft. That is the only way the model ends up so far south on the last LOP. If they were at 12,000 ft going slower, say 300 kts, they would end up way further northeast to make the radial and tangential speeds fit the Doppler.
thinker said,
March 28, 2014 at 7:22 am
My two cents…
I read some time ago that the frequency offset of the transmission was measured primarily as a health indication of the aircraft terminal, since the oscillator may have an offset or drift (e.g., if it is a crystal as is typical and is not locked to GPS). Neglecting for a moment the correction associated with the drifting of the satellite in orbit (which creates its own relative Doppler shift with respect to the aircraft (and, if it is merely a transponder, with respect to the ground station), the measured offset is the rate of (radial) slant range change between the aircraft and the satellite.
The first ping is when the plane is on the ground. So the measured frequency offset is the sum of any oscillator offset and the satellite motion with respect to the aircraft on the ground and the Inmarsat ground station). Since the plane is stationary at this point this represents zero Doppler shift due to the plane speed and can be considered the actual zero, from which the Doppler shift (which is a signed quantity) can vary from positive (away from the sub satellite point) and negative (towards the sub satellite point).
The Doppler shift as shown is inconsistent with the purported track of the plane which doubles back over Malaysia to reach the Indian Ocean. (The integral of the Doppler shift from start to finish represents the total change of range with respect to the sub satellite point and is shown as completely positive.) There must be a portion of the track having a negative Doppler shift. This would have occurred between the last ACARS message and the point annotated “possible turn”. That is probably a NEGATIVE Doppler shift since the plane was moving towards the sub satellite point. (I do not know if this error results from recording only the frequency shift and not its sign.)
Since the lack of data in that time period corresponds to the presumed skin track period, let us take the last 5 pings, where the integral of the Doppler shift (corrected for elevation angle so as to give slant range) from the last known position should place us on the last ping circle. This follows from the fact that the Doppler shift represents the slant range change only and is the radial (wrt the satellite) change in range only.)
Even if the time (range) circles that have been measured have poor accuracy or appear to be inconsistent, the data has value and ought to be released.
Fitzcarraldo said,
March 28, 2014 at 7:27 am
Does anyone know the coordinates of the ‘blue panel’ spotted on 28 March by the RNZAF Orion?
I have updated my Google Earth model to include the two new flight paths (469 and 475 knots) shown on the AMSA slide on 28 March, and also added some further placemarks for debris sightings (coordinates from the slide shown in Beijing on 27 or 28 March):
Fitzcarraldo said,
March 28, 2014 at 7:28 am
http://s2.photobucket.com/user/imageuser/media/MH370_-_Southern_Indian_Ocean_Graphic01_28_March.jpg.html
GuardedDon said,
March 28, 2014 at 7:58 am
Fitzcarraldo,
This illustrates the search area for 28th, I haven’t seen any lat/long yet.
http://bit.ly/1o7YKcA
airlandseaman said,
March 28, 2014 at 8:42 am
Jeff:
Please get CNN to stop saying that MH370 ran out of fuel earlier than previously thought. It’s flat wrong. The fuel burn to exhaustion has not changed since Inmarsat’s first crude analysis. Professionals know this. The 08:11 transmission makes that absolutely certain.
Ashley B just said it again! It’s so disturbing that this stuff gets so scrambled, misinterpreted and recycled by the time anchors try to explain it. It is not surprising that everyone who does not understand the math would be saying this. The official statements were certainly misleading, which is why I was so worked up at first. But it all makes sense if they meant to say it burned more fuel only early in the flight, not after the 02:22 events, and was actually moving slower after 02:22.
In any event, it’s definitely somewhere on or near the 08:11 or 08:19 southern arc. That is the one certain fact from the Inmarsat data. The slower it was flying the final hours, the further north east it ended up. If it was really slow, like 250-300 kts, it will be found east of Malaysia, south of Jakarta, perhaps near 15S, 105E. Until they find some way to validate the assumed altitude and TAS, the search area should include the southern arc up to Jakarta.
AndRand said,
March 28, 2014 at 10:02 am
thinker said,
March 28, 2014 at 7:22 am
The first ping is when the plane is on the ground. So the measured frequency offset is the sum of any oscillator offset and the satellite motion with respect to the aircraft on the ground and the Inmarsat ground station). Since the plane is stationary at this point this represents zero Doppler shift due to the plane speed and can be considered the actual zero
Well.. nope…
Doppler effect is used to determine area of the arc derived from N-S movement of the satellite. And this is independent from aircraft movement.
In theory it could be used to estimate radial component of satellite-aircraft movement, which could be helpful when matched with assumed route.
AndRand said,
March 28, 2014 at 12:16 pm
Anybody have seen anywhere real, measured data with delay (sat-airplane distance) and frequencies (for Doppler effect)? As far as I know these available in media and net are derived from several rings drown on map, as Duncan Steel did.
meadows.st said,
March 28, 2014 at 12:49 pm
@AndRand
The best data of which I am aware so far is only the Doppler Frequency offset graph that Tim has posted in this article (above).
The only ping range data of which I am aware is the “40 degree” arc that appears to have been released by the Malaysian government and is also posted at the top of this article. Various people (too numerous to name) on this thread (and the previous article’s thread) have attempted to convert this graph into an actual radial distance from the satellite but to my knowledge, all other publicly available “ping arc contours” are based on assumptions and not hard data. The only other data point regarding the ping arc contours is a quote that was attributed to a spokesperson from Inmarsat that stated that all ping arc contours after the “2PM” (MYT) contour that is closely related to the last purported military radar contact was outside the “2PM” contour. re: the “2PM contour”: from the Doppler Frequency Offset graph, it is clear that the last contact was between 02:25 and 02:29 but it is not known if any or all of these communications also included data for a ping range/distance metric – presumably at least one of these three communications contained RTT information.
airlandseaman said,
March 28, 2014 at 12:54 pm
I would like to launch a new line of thought here about the error analysis. How could they reduce the size of 08:11 (00:19) error box?
The error box depicted in all the graphics looks like a rectangle with nearly equal sides. But why that shape? It seems to me that we know the radial distance from the spacecraft with far greater certainty than we know the error in the other dimension, which is totally driven by the speed assumption.
The radial distance can and presumably is being measured with fairly high accuracy. It might be in the 1-10 usec range after correcting for all the bias, calibrated when MH370 was on the runway. We are potentially talking about 10m accuracy if the system had no errors, and the radial errors are very well characterized. They should be well known. Altitude uncertainty could change the radial arc width by a few km.
I have been relentless expressing concern about the magnitude of the error associated with a bad assumption on altitude/speed. It seems that nearly everyone gets it now. We can reasonably believe with very high confidence MH370 went down somewhere on or very near the “final arc”. This is based on hard data and proven physics. There is a high probability, based on the orbit inclination data that it went down on the southern arc. Moreover, it must be somewhere between the 250 kt intersection with the 08:11 circle (somewhere near Jakarta) and the 475 kt intersection.
Taken together, it suggests that the real “box of uncertainty” is more like a 5 mile wide arc about 2000 miles long. That’s only 10,000 square miles, smaller than some of the boxes they are looking in now. Sure, the debris may no longer be in the box, but the aircraft is.
AndRand said,
March 28, 2014 at 1:13 pm
I am asking about frequency offsets because I think they could be crucial to achieve this.
There is a spreadsheet linked at Duncan blog with Doppler offset calculated from satellite positioning and movements and aircraft route. With actual frequency offset data (which for now appeared I do not know how or from where) you can fine-tune aircraft route.
I didn’t check the formulas if they are exact for satellite X,Y,X speeds, distance form slant range formulas and so on.
With google account you can see it here https://docs.google.com/spreadsheet/pub?key=0AhvpxNRGOuapdG15UnlRNm9STVhtdFEzcElTOTFFR2c&output=html
If you have actual data for frequency offsets you can check several routes. For now, spreadsheet doesnt calculate positions from spreed and heading or opposite.
AndRand said,
March 28, 2014 at 1:19 pm
proper link
https://docs.google.com/spreadsheet/ccc?key=0AhvpxNRGOuapdG15UnlRNm9STVhtdFEzcElTOTFFR2c&usp=sharing
meadows.st said,
March 28, 2014 at 2:28 pm
@airlandseaman
Re: your data points for fuel consumption for Delta 777. Did the reference indicate if the fuel consumption was related to max endurance or max range? It is my understanding based on Power/Fuel Consumption/Range/Altitude charts that Max Range gives decreased time to fuel starvation but paradoxically (as the name suggests) greater range.
Is your max 250kn (this is stall speed at 35kft I believe) and 475kn range based on TAS or IAS and Max Range or Max Endurance power settings?
The way I read the current data, I make the following distinctions in maximum envelope for probable paths:
Scenario A – max range power, waypoint flight path through S35E89, 35kft altitude
Scenario B – max endurance power, waypoint flight path through S35E89, 35kft altitude
Scenario C – max range power, magnetic heading of 180, 35kft altitude
Scenario D – max endurance power, magnetic heading of 180, 35kft altitude
Given these assumptions (obviously you can assume a range of constant altitudes, speeds, headings and variations (assuming pilot in control) during the flight and the analysis gets infinitely more complex), I am working out starting points (lat/long) for the iterative analysis model I am developing by creating points along the assumed flight path. From the starting points for estimations I will iterate to find an instantaneous best fit for speed at each ping time then use those results to recalculate the next ping location. I am using DuncanSteel’s data for satellite position and speed and am hoping to see the results converge (day job is getting in the way of completing this analysis).
I don’t believe an average speed at just above stall speed is credible but I agree that this is the absolute lower bound for the analysis.
meadows.st said,
March 28, 2014 at 2:34 pm
@AndRand,
The starting point of my analysis is very similar to what you have posted in your googledoc spreadsheet except I have ignored the possible Northern Route (as much as I liked Keith’s original hypothesis, I couldn’t fit the available data (which decidedly is not great) to anything close to the SIA68 flight path). My chosen points are not identical to yours but they are close. I don’t think a precise location for starting point is necessary since the 0.3ms error in the ping distance equates to a difference on the order of 100 km plus or minus (E-W or N-S) given the relative position of the a/c and the sat.
airlandseaman said,
March 28, 2014 at 5:23 pm
AndRand:
1. SQ68 theory is busted. MH370 was 100 NM behind SQ68 at 02:22.
2. A good starting point could be:
02:22 loacal Lat = 06 deg 52 min N, Lon = 97 deg 20 min E
3. The propogation time error is not 300 usec. That is a spec for the maximum delay inside the radio. But it is quite deterministic, and there for drops out in the bias calibration. The preflight data on the ramp provides the means to eliminate nearly all bias. The accuracy is probably <10 usec.
meadows.st:
1. The airspeed values are TAS.
2. From contemporaneous radiosonde data, it is known that the upper level winds were very light, typically 0-10 kts between 12-35,000 feet.
3. The 250 kt and 475 kt figures simply correspond to the slowest and fastest they might have flown, consistent with the aircraft normal operating range. 250 kts is very slow, but they could have been in zombie mode at 12,000 feet and 250 kts. It does not matter at this point how much fuel they had. They went in around 08:11 (or possibly 08:19) on the final LOP. If they were going 250 kts, the only way they could end up on the arc would be to have headed much more easterly, ending up slightly south of Jakarta. Slower speeds require a grater radial velocity component, less tangential velocity to make the data fit. If they were at 35,000 feet and 450 kts, they still end up on the arc at 08:11, but much further south and west.
AndRand said,
March 28, 2014 at 5:27 pm
I can tune a route in googledoc with speed and headings while coordinates are calculated (with .kml script generated for GEarth review). However actual data is needed to match both Doppler offset and Slant Range (r in spreadsheet) so route could be more accurate.
airlandseaman said,
March 28, 2014 at 6:33 pm
As noted on Don Lemon tonight, the problem now is that the debris is no longer of much use for the purpose of locating the aircraft. Finding the debris is still very important for other reasons, but they need to refocus on the best possible Inmarsat range solutions (high confidence dimension in the search area box) and altitude assumptions (a dimension that is 100X less certain).
IOW, the focus really has to be on error analysis at this point. They must reduce the size of the aircraft search box (not necessarily the debris search area). The error box is for the aircraft location is a very long skinny arc now, not a box. They need to wake up and recognize this. They need to put a sharp pencil on the range error analysis, which should show that it is much smaller than the long altitude determined final point along the arc.
hal said,
March 28, 2014 at 8:03 pm
@airlandandseaman, that is a very good point. They could very well be doing that as we speak, and it’s just not making it into the MSM who are fixated on debris. At least I’d like to believe that the investigators are a step or two ahead of us. Not much evidence for it, I’ll admit.
airlandseaman said,
March 28, 2014 at 8:25 pm
I just heard on Anderson Cooper that now they are assuming it was at 12,000 feet, but going 400 kts at 12,000 feet. Wow! That’s a case I had not considered. Well, if red line at 12,000 feet is 400 kts, and they had enough fuel to bore a hole all the way to 08:11/08:19, that fits with the new search area. Ultimately, it is the speed, not the altitude. Just never seemed like a credible assumption to think they would be at 12,000 feet going that fast. But if they were in a “high dive” headed for 12,000, and red-line at 12,000 feet is 400 kts, and they turned into a ghost plane by the time they got there, the auto pilot leveled off and kept going, it just might make sense. If this is what happened, then I believe they are getting close on the search area.
Ole said,
March 28, 2014 at 11:33 pm
Don’t know what to make of it: The photo from the Beijin event of the radar screen suggests MH370 flew 111 nm in the last 20 min it was painted by Butterworth radar:
2:02 – 89 nm from Butterworth
2:22 – 200 nm from Butterworth
That gives a speed over ground of 333 knots while it was over Malacca Strait.
In the fuel consumption table provided by airlandseaman – March 28, 2014 at 6:17 am – 310 knots is the economical speed for 12000ft.
Does this coincidence in speeds(333 ~=310) somehow indicate MH370 was flying at that altitude?
duncansteel said,
March 29, 2014 at 12:08 am
People might wonder what the effect is upon the calculated values of the latitude and longitude of the aircraft on the basis of the ping time delays if it were flying at 12,000 feet (as suggested above) rather than 35,000 feet.
The answer is: not much. Taking the nominal one-leg time delay of slightly over 126 milliseconds and imagining the aircraft to be on the equator (latitude 0 degrees) the identical ping time delay renders:
Altitude 35,000 feet => longitude 107.8828 degrees East
Altitude 12,000 feet => longitude 107.8898 degrees East
The difference of 0.0070 degrees corresponds to a linear distance of 0.78 km. That is, there is no significant shift in the ping ring if the altitude is assumed to be at 12,000 feet rather than 35,000 feet.
Ciao,
Duncan Steel
duncansteel said,
March 29, 2014 at 12:17 am
A short while ago I posted the following comment on the website of The Guardian newspaper (London):
http://www.theguardian.com/world/2014/mar/29/flight-mh370-fresh-objects-found-in-new-indian-ocean-search-area#comment-33693085
(Start comment)
I repeat what I have already said several times in various places in the world’s media:
Inmarsat, please, please, please release the basic data from the pings. Specifically, make public the six (or more?) ping time delays so that people elsewhere with adequate expertise can try to determine the aircraft route. This is called “crowdsourcing”. It often works. You have already stuffed up badly (with your false assumptions leading to the Malaysian Government releasing on March 15th a graphic/map that was in error); don’t make it worse.
To keep these six numbers secret is unconscionable.
Make the six time delays public (that at the time of the final ping was, I think, about 126 milliseconds for one direction satellite-aircraft); and perhaps also be helpful by making public the measured doppler shifts.
UK Government (through various agencies such as the AAIB): you are colluding in a disgraceful episode, by not insisting that the above six numbers be released. Shame on you.
The Guardian: as a champion of free access to information, why are you not harassing Inmarsat and HMG to release the data? Shame on you, too.
(end of comment)
I should point out that I have been a Contributor to The Guardian since 1999, and if you were to search its archives you would find dozens of features and OpEds that I have written/published therein; similarly I wrote a weekly column for its erstwhile sister paper, the Manchester Evening News, for three years. The Guardian has made a big thing in recent times about being a champion of freedom of information (e.g. Wikileaks; NSA leaks) but in this case it is allowing an organisation barely a stone’s throw from its own offices in London to keep secret six numbers (the ping time delays) and in doing so is effectively colluding with the UK Government in hampering the search for MH370 (because, as readers of this thread will realise, there is expertise out there/here that could crowdsource a solution).
Again, I urge all readers to put pressure on local media to push Inmarsat to release the data. Shout, and shout loud.
Duncan Steel
andyhull said,
March 29, 2014 at 1:18 am
How close can we now get to estimating the unknown pings working with the assumptions made by Inmarsat, based on the tracks they have released so far, and their presumed methods for producing those tracks?
Ole said,
March 29, 2014 at 4:21 am
What do the published doppler shifts mean??
My degree in physics is a little corroded, so you are welcome to correct the following thoughts:
For speeds which are low compared to the speed of light the following approximation for the doppler shift can be made:
doppler_shift = (radial_speed / speed_of_light) * carrier_frequency
http://hyperphysics.phy-astr.gsu.edu/hbase/relativ/reldop3.html
Plugging in:
- speed_of_light : 3 * 10^8 m/s
- carrier_frequency : 1.6 * 10^9 Hz
we get 5.3 Hz for 1 m/s radial_speed or 533 Hz for 100 m/s radial_speed
So what doppler shift would result if at 2:25 the aircraft was heading west almost directly towards the subsatellite point with 330 knots = 165 /ms ?
Assume for simplicity the sat was visible at an angle of 45°, then the radial component of the aircrafts speed to the sat would have been
(165 m/s / sqrt 2) = 116 m/s
That should give a doppler shift of
~600 Hz.
————–
The diagram gets nowhere near this value, so I’m convinced the terminal does doppler compensate for most of the doppler shift attributed to it’s own speed. Modern Aero-C terminals do so by using GPS position and speed:
http://www.ttvms.com/sitecore/content/www,-d-,thrane,-d-,com/Aero/Products/Aero-C.aspx
Quote:
————————
The integrated GPS receiver calculates your exact position, altitude, speed and heading every second, used for automatic Doppler compensation …
————————
Conclusion : Without knowing how the doppler compensation works no conclusions can be drawn.
AndRand said,
March 29, 2014 at 5:01 am
andyhull said,
March 29, 2014 at 1:18 am
How close can we now get to estimating the unknown pings working with the assumptions made by Inmarsat, based on the tracks they have released so far, and their presumed methods for producing those tracks?
As far for now these are only guestimates.
We can guestimate delays/distance sat-airplane from rings drawn on the map shown by Malaysians or Inmarsat, and they could be quite accurate to present alternative route.
However, guestimates of doppler shifts are made of assumptions of guestimated route. So any diagrams showing matching of doppler effect based on that guestimated data is shear specuation. Until we get data from Inmarsat it is nothing more than that.
And as you can see here, with delays and doppler shifts provided estimation of the route could be very accurate:
https://docs.google.com/spreadsheet/ccc?key=0AhvpxNRGOuapdG15UnlRNm9STVhtdFEzcElTOTFFR2c&usp=drive_web#gid=0
Futhermore, it doesn’t look like SAR team have much more than that while they change their million dollars search areas by 1000nm.
GuardedDon said,
March 29, 2014 at 5:43 am
RE: Ole said (March 29, 2014 at 4:21 am)
The AES user terminal _does_ compensate for the aircraft speed relative to the satellite (an incoming doppler calc) . I pushed a comment on that, quoting the spec from the ICAO doc, the URL for which was published by Tim in an earlier comment.
I strongly believe that there’s been a selective release of the comms events to and from the aircraft. Inmarsat only initiated these hourly log-in Direct Verification pings – the rest are airline services traffic. Chris McLaughlin’s initial comments discussed only the hourly ‘pings’.
There are only 4 events spaced 60 minutes apart, certainly the Inmarsat log-in Direct Verifications at 19:40, 20:40, 21:40 and 22:40UTC. The graph displaying BRO information released shows only one subsequent event at 00:11UTC. There’s been additional commentary of a partially completed communication at 00:19UTC.
The scheduled arrival was 22:30UTC, I would expect that Malaysia Airlines would have used all available channels to try to contact 9M-MRO after that time passed including attempting to send ACARS messages, we know the Inmarsat datalink was still operational until at least 00:11 so the AES terminal would’ve received these resetting the timeout for another Inmarsat datalink log-in verification.
In summary: other message events occurred & have not been publicised as to do so would show when Malaysia Airlines attempted to contact the aircraft – publishing that data may be prejudicial to the airline at this time. Similarly the military radar information about the aircraft track has never been reported with absolute certainty.
AndRand said,
March 29, 2014 at 6:13 am
GuardedDon said,
March 29, 2014 at 5:43 am
The AES user terminal _does_ compensate for the aircraft speed relative to the satellite (an incoming doppler calc) . I pushed a comment on that, quoting the spec from the ICAO doc, the URL for which was published by Tim in an earlier comment.
Do you mean that AES reverses doppler shift it receives from satellite?
Therefore no conclusions on doppler effect can be made?
AndRand said,
March 29, 2014 at 6:16 am
GuardedDon said,
March 26, 2014 at 5:12 am
@ Duncan, reference your point (h)
The AMS(R)S manual describes that the AES user terminal design must detect doppler shift on its received signal and it must compensate in transmission back to the satellite:
Receiver Doppler rate. The receiver shall be capable of acquiring and maintaining performance per [demodulator performance] with a rate of change of frequency of 30 Hz per second.
Transmitter Doppler rate. The maximum rate of change of the frequency of the transmitted signal when compensated for aircraft acceleration in the direction of the satellite shall not exceed 15 Hz per second. The Doppler adjustment resolution shall not exceed 10 Hz and the associated frequency changes shall be made without introducing phase discontinuity into the transmitted signal.
AndRand said,
March 29, 2014 at 6:17 am
Estimated shifts exceed 20Hz up to 1.5kHz.
Ole said,
March 29, 2014 at 6:44 am
Again, correct me if I’m wrong (just thinking loud):
If the AES takes the sat’s signal as reference for dopper compensation then all the relative motion between sat and AES would be compensated for. But the idea of the BRO analysis was that the doppler shift attributed to the sat’s wobble remains uncompensated and is thus visible in the measured BRO. So it seems more plausible that the AES of MH370 did it’s compensation by GPS position or inertial reference from the ADIRUs of the aircraft.
Then it makes sense that the measured peak in doppler shift at 2:25 was caused by a rapidly changing speed vector (i.e. turn) of the aircraft which the AES compensation algorithm couldn’t follow immediately. Smarter people than me maybe even can estimate the turn rate from the measured BRO.
XocoLatte said,
March 29, 2014 at 7:02 am
Well, Duncan, I hate to say it, but what if, The Guardian, AAIB and Inmarsat inclusive, all are just useful tools in some cover-up game and however shameful their behavior looked like from one’s point of view, they cheerfully aligned to another’s.
What if this whole story about handshake pings, airspeed and flying altitude to guestimate these ping arcs and a possible crash site is just the ingredients of a very successful smokescreen?
It is almost inconceivable that military radar in the reported location of the point of plane-went-missing-from-radar had lost a flying-at-whatever-altitude B777 aircraft. The radar belongs to RMAF Butterworth an Air Force Station of the Royal Malaysian Air Force which is the headquarters of the Five Power Defence Arrangements (FPDA) Integrated Area Defence System for Malaysia and Singapore. We are to sincerely believe that, in the middle of the night, an unidentified B777 that was tracked by this military radar at this FPDA station in charge of the defense of that entire area, was allowed to fly right over the base itself and not be intercepted. Moreover, just minutes later the same plane in close vicinity of the RMAF Butterworth radar just dropped off radar. Is it a stretch to say that this is very unlikely for a civilian aircraft without some sort of cloaking technology or radar blocking? Unless, of course, if the aircraft was no longer in the airspace, meaning, crashed for whatever reasons. Most likely reason being, obviously, to be shot down by Malay military…
Ole said,
March 29, 2014 at 7:14 am
The contents of the comms to MH370 probably are intellectual property of Malaysia Airlines. I doubt INMARSAT plc has the right to publish them. They probably don’t even have the right to peek into them.
Some ICAO regulation says 30 days after the incident a preliminary report has to be issued. With AF447 that happened in the first days of July. Maybe this preliminary report for MH370 will have more details of the comms.
airlandseaman said,
March 29, 2014 at 7:33 am
The graph on page 2 of Annex I (the “Doppler Chart”) vertical axis should be read as the sum of three things:
Y = A/C Doppler + S/C Doppler + Calibrated System Bias
We don’t need to understand the fine details of how the equipment works. Inmarsat knows that part of the equation well. Even if the aircraft terminal measures incoming Doppler and compensates on the inbound link, the math for that is known and just becomes a component of the total system bias. There are several other components to the system bias. We don’t need to to know all of the sources as long as we have to way to calibrate the total system bias, and we are sure that bias has no significant drift.
airlandseaman said,
March 29, 2014 at 7:38 am
Forgot to remind, we have a valid system bias calibration at ~ 00:40 on the ramp, and we have 3 additional ACARS messages right after takeoff for which the ADS-B positions are available from Flight Aware. To be sure, the 00:40 zero speed bias calibration (+87 Hz) is the best, but not the only calibration point.
Alex Siew said,
March 29, 2014 at 7:48 am
DUNCAN, I believe the plane was hit by positive lightning causing it to crash into the South China Sea, that the rear upper part of the fuselage did not immediately sink after the crash but remained above water for several hours allowing the satellite terminal on board which had its own battery to emit the pings from its antenna on top of the rear fuselage until the battery ran out or the fuselage submerged some time after 8am, that the crash site would be around the intersection of the plane’s latest known flightpath (IGARI- 40 degree turn) and the arc from the final ping (see my first comment).
I suspect the Doppler Effect chart shows that the plane had crashed early on and that the readings for the 6 completed handshakes from 2.29 to 8.11 can be fully accounted for by the movement of the satellite. Are u able to do a model, based on the known info for the 8 explained entries on the chart (the ACARS transmissions at take-off and at 1.07 and the 6 completed handshakes) to prove or disprove this theory…much obliged
Skwosh said,
March 29, 2014 at 8:35 am
We don’t know what the Doppler compensation mechanism is – well, I certainly don’t anyway.
However, to do any kind of pre-emptive Doppler compensation for reception or transmission the aircraft must presumably have a fairly good idea of its own position/velocity and the satellite’s position/velocity.
Any shift inferred from the actual frequency of a signal recently received from the satellite may actually *not* be that useful, and could have a very short shelf-life (particularly if you are accelerating wrt satellite at the time) – so maybe the aircraft’s system doesn’t actually make use of the observed shifts on the received frequencies at all.
If the aircraft’s understanding of the positions and velocities of both itself and the satellite were both very good then in principle the Doppler compensation could be more or less perfect – but if the Doppler compensation only needs to be ‘good enough’ to keep the carriers centred to within a given tolerance then maybe the aircraft can get away with a very simple ‘model’ of the satellite as simply hanging stationary at a fixed point?
Then, if the aircraft is *imperfectly* adding/subtracting a Doppler compensation (not taking account of satellite motion and position) and then Nature is subtracting/adding the actual Doppler shifts, then we *would* expect to see frequency shifts in the aircraft’s transmissions as received at the satellite – and indeed we do.
So, if the Doppler compensation on the aircraft were based on a ‘good enough’ (and easy to implement) assumption that the satellite’s position is actually fixed, then the residual variation in the signal frequency is going to be at most of the order of the Doppler shift associated with the maximum satellite velocity (along the line of sight).
So maybe the observed shifts are something like:
Frequency_Observed(t) :=
FixedBias
– Doppler(P_plane(t),V_plane(t),P_satellite_fixed,0) // Compensation
+ Doppler(P_plane(t),V_plane(t),P_satellite(t),V_satellite(t)); // Nature
I guess this is falsifiable based on the first few released frequency shift data points because the positions and velocities of both the aircraft and satellite are (presumably) both known/guestimable at these times.
AndRand said,
March 29, 2014 at 9:00 am
Skwosh said,
March 29, 2014 at 8:35 am
However, to do any kind of pre-emptive Doppler compensation for reception or transmission the aircraft must presumably have a fairly good idea of its own position/velocity and the satellite’s position/velocity.
Isn’t it that with time reactions less than second it is sufficient to compensate doppler effect with reversed shift received from satellite? (ping frequency of the satellite is known)
AndRand said,
March 29, 2014 at 9:03 am
As I understand the purpose is just to minimize offset at receiver
Ole said,
March 29, 2014 at 9:20 am
Skwosh,
that is my understanding too. It seems doppler compensation is most imperfect when the plane is accelerating/turning. That would explain the varying offsets in the first phase of the flight, when the plane was accelerating/climbing/turning.
In the graph that is reflected as offset from the predicted doppler shift.
Nevertheless, it’s all conjecture until we have more information from INMARSAT.
airlandseaman said,
March 29, 2014 at 9:46 am
Getting lost in the weeds here. The Doppler compensation is for the sole purpose of minimizing the carrier and clock recovery PLL acquisition time at the ground station, thereby minimizing the time overhead in the TDMA channel. A time slot offset performs a similar function to position the packet in the middle of the allocated time slot. How all that is done is really irrelevant as long as you trust Inmarsat to know how the system works, and how to process the numbers to yield a net System Doppler + System Bias. That is the number in the chart.
duncansteel said,
March 29, 2014 at 10:43 am
Hi folks… Well, after saying I’d only look at the ‘space’ part of the problem I have actually taken a look at the aviation part.
In a new post on my website…
http://www.duncansteel.com/archives/438
…entitled “Possible Flight Paths of MH370″ I have used STK to follow great circle paths of a simulant MH370 southwards from a point just south of Pulau Perak (location of MH370 in the last radar detection, apparently) at speeds of 200, 250, 300, 350 and 400 knots to find where they intersect the ‘ping equal time delay arc’ at the required time (i.e. 00:11 UTC on 2014/03/08). That is, close to where MH370 apparently ran out of fuel.
Suggestions and criticisms welcome. Within reason.
Cheers,
Duncan Steel
AndRand said,
March 29, 2014 at 10:58 am
OK. So I made a route assuming that offsets provided in the diagrams showed measured doppler shifts in frequencies.
http://www.filesplat.com/.andrand/shared/NZPEESG4556NW4H8GHM040L6CTQL2SK1—-Route%20-%20Doppler%20effect.png
Spreadsheet with .kml available here:
https://docs.google.com/spreadsheet/ccc?key=0AhvpxNRGOuapdG15UnlRNm9STVhtdFEzcElTOTFFR2c&usp=sharing
AndRand said,
March 29, 2014 at 11:02 am
@Duncan:
Did you match the route with ping delays and ALSO doppler shifts?
Skwosh said,
March 29, 2014 at 12:15 pm
@airlandseman
I think the reason people here may be speculating about the Doppler compensation mechanism is because if they knew what that mechanism was then they (like Inmarsat) could make a stab at modelling it, and would then be able to make use the published frequency data to verify/falsify their own speculative flight paths.
Do you not also think that even some qualitative knowledge of the mechanism of the Doppler compensation might shed some light on:
1. The difference between the predicted and measured values at the start of the flight. Surely this is the part of the flight that is best understood, and yet there is seemingly quite a large inconsistency between Inmarsat’s predicted values and the actual frequencies measured.
2. The behaviour of the three closely spaced frequency measurements during the putative turn.
3. The fairy consistent difference between the predicted and observed measurements towards the end of the plot?
airlandseaman said,
March 29, 2014 at 1:07 pm
Excellent work, Duncan. Your MH370 routes are no doubt inexact if they do not also use the Doppler, but they are good enough to confirm the big picture (and all the pictures many of us have had in our heads all along).
In particular, I am pleased to see your results for low and slow (200 kts) match what I have been projecting for the last few days. Now it’s just a matter of finding some hard evidence for the speed, not just a theory. I think they may have a good theory now for the 12,000 foot and 400 kts scenario, but it is still only a theory as far as I know.
To fine tune the model, you could use the last radar contact as follows:
time: 02:22
lat: 06 52? 03?
lon: 97 20? 21
Average speed between 02:02 and 02:22 was 354 kts ground speed.
These were derived by plotting the Butterworth radar vectors in Goggle Earth.
12,000 foot wind was light at the time:
• Phuket: 10kts from 90 degrees.
• Learmonth Airport, NW Australia: 11kts from 125 degrees
hal said,
March 29, 2014 at 1:28 pm
Nice work, Duncan! I just left kudos on your web page as well.
I’m finding Alex’s suggestion about lightning and the South China Sea compelling. It is intuitively satisfying in a way that the long voyage into the south Indian Ocean can never be, dependent as that is on highly improbable events.
With the many missteps and self-reversals of Malaysian Airlines and the Malaysian government, together with the complete failure of the search for debris, I think it’s time to revisit some of the actions and decisions that were taken early on. For example, why was the search in the South China Sea abandoned so quickly?
A few days ago I opined that it would not be surprising to learn the plane was in the South China Sea precisely where the first oil slick was discovered. I said that partly out of frustration and partly out of a growing sense that the approach is failing.
Duncan can you run the sim that Alex requested?
airlandseaman said,
March 29, 2014 at 1:29 pm
Skwosh:
I think there is a lot of confusion about what the “Doppler compensation mechanism” is all about. They are estimating the Doppler value for the sole purpose of pre-setting the expected carrier frequency in the demodulators on both ends of the links. This saves a lot of bandwidth and speeds up the carrier acquisition time, saving more bandwidth. I know it sounds like there is uncertainty, but that uncertainty exists only prior to PLL carrier lock. Once the carrier is locked (to a GPS locked time-base), the exact Doppler is known.
BTW…I have some direct experience with this stuff for 40 years. I’ve forgotten a lot, and things have been modernized, but they are only better now. The demodulation is all done in DSPs now. GPS is the main thing that has revolutionized the communications systems. It provides the means to exploit independent clocks (frequency standards) on each end of the links. This provides extreme accuracy (essentially zero error).
It would be interesting to see if the 00:30 pre-flight Burst Frequency Offset (+87 Hz) is equal to the Satellite Doppler at that time. The sign and magnitude appear to be about right. If it is +87 Hz, that would mean the total system bias is actually zero.
GuardedDon said,
March 29, 2014 at 1:53 pm
Re: Alex Siew said, March 29, 2014 at 7:48 am
Have you a source for the battery backup idea on the B777 satcom install. The aircraft has a generator, the IDG, plus a backup gen on each engine and in case of single engine failure it has the APU. Batteries are heavy things to carry around if there’s redundant electric power generation esp if it’s only to power a non-flight critical system.
Also, lightning: an ATDnet/sferics system may have picked up but not localiized a “positive lightning” strike given the extreme energy – any positive reference you can find on that in the time frame 17:00-18:00UTC when 9M-MRO was out over the Gulf of Thailand?
airlandseaman said,
March 29, 2014 at 1:59 pm
BTW…It should be noted that the Doppler plotted in Annex I, Page 2 is the L band Inbound Doppler (Aircraft to Ground). In this direction, the uplink inbound carrier frequency is one in the 1626 to 1660 MHz band. We do not know the exact frequency assignment. It is assigned by the Groundstation dynamically. So an estimate is required. Not knowing this exact value, I would use 1643 MHz. Thus, the wavelength is ~ 0.1825 meters. +87 Hz would correspond to a radial speed of 15.87 m/s.
Skwosh said,
March 29, 2014 at 2:36 pm
@airlandseaman
Forgive me, but my simple non-expert view of this was as follows:
If I have one moving satellite and lots of moving aircraft then if my aircraft all know their positions and velocities relative to fixed earth co-ordinates (because they have GPS) and they also know the position and velocity of the Inmarsat satellite relative to the same fixed earth co-ordinates (because the satellite’s motion is a known predictable fact) then in theory all the aircraft *could* at all times dynamically and pretty well perfectly adjust their listening and transmit frequencies to exactly compensate for the Doppler effect to/from the satellite, so that the *satellite* could always send and listen at exactly the same fixed frequencies to each of them at all times (the satellite wouldn’t have to worry about Doppler compensating for anything at all).
Now, that may well *not* be how it actually works, and that may well not be what Doppler compensation is, but that’s was what I, in my ignorance, was thinking!
So, in this *perfect* compensation scenario I dreamed up (in which the aircraft do all the work) it would actually be impossible to deduce *anything* about the motion of any aircraft purely from the frequency of their transmissions as observed at the *satellite* because that frequency would always, by design, be invariant with respect to the aircraft’s motion (because in this scheme each aircraft is individually and perfectly dynamically red/blue shifting its transmit frequency to compensate for the aircraft-satellite relative velocity so that the signal received at the satellite is always bang on centre).
So, further, I was speculating that we would only be able to get anything useful out of observations of the aircraft transmit frequencies at the satellite if the Doppler compensation mechanism were actually a bit *imperfect*. Specifically, I was thinking, if the aircraft made the simplifying assumption that the satellite is actually truly geo-stationary (much easier to code!) then this would make the aircraft’s Doppler compensation imperfect, and that would provide some data.
I guess I have got the wrong end of the stick here in some kind of horrifyingly massive way?
Alex Siew said,
March 29, 2014 at 3:52 pm
1. Battery
@GuardedDon, i dont know if the satellite terminal on MH370 had battery backup arrangement or not. However, someone who appeared to be a pilot posted on PPRUNE about the satellite terminal on B777 having its own power and the location of its battery (see my earlier comment). Logically, the terminal would have UPS (Uninterruptible Power Supply) like other electrical gadgets with a clock function. Even if it did not have a clunky removable battery, it probably would have some sort of inbuilt residual battery, with enough power to emit the pings.
2. Lightning
@GuardedDon,I haven’t checked whether there is any recording or data showing positive lightning at that time, dont know where to look! A pilot did report seeing lightning in the area where MH370 was flying through (see my first comment).
It could also have been the more common and much less powerful negative lightning. This particular plane had its right wingtip broken off when it collided with another plane while taxiing at Shanghai airport in August 2012. A plane’s defence to lightning is premised on the Faraday Cage theory whereby the electrical charge from the lightning is dissipated quickly through the plane’s skin to exit points before it can penetrate the plane’s electrical circuits. The wingtips are reportedly favourite exit points for lightning. A B777 is said to use composite materials rather than aluminium as its skin and a mesh is inserted under the skin to help dissipate the charge. If there was a gap arising from the repairs to the right wingtip (this is pure speculation), it could have compromised the plane’s defences to lightning.
airlandseaman said,
March 29, 2014 at 4:40 pm
Skwosh:
“Thin Route” satellite communications systems like Inmarsat have a Network Operations Center (NOC) which allocates TDMA time slots and FDMA spectrum dynamically. I am no longer current on the specifics of the Inmarsat protocols of today, but the basics have not changed.
The Demand Assignment Multiple Access (DAMA) system typically monitors a random access channel for terminal requests for service. When a request for service is received, the DAMA system assigns an available FDMA (Frequency Division Multiple Access) channel and beam from a pool. Depending on the type of service request, a TDMA (Time Division Multiple Access) time slot may also be assigned. CDMA (Code Division Multiple Access) may also be used now days. The channel may be a TDMA packet channel or a dedicated voice or data channel on a specified frequency pair (up and down). When the communications is completed for that message, the channel goes back into a pool of available channels. It is similar to the way the analog Cellular system works.
The spectrum must be allocated dynamically because of the limited bandwidth available for the service, and the extremely high cost of the space segment (eirp). There is simply no possible way to assign one dedicated channel to every aircraft or one dedicated channel to every cell phone. These systems all share the very limited bandwidth available. It would not be uncommon for a single frequency pair to be shared by 100 terminals.
airlandseaman said,
March 29, 2014 at 5:07 pm
Skwosh:
Just reread you last post. Perhaps what is missing from your understanding is that the aircraft radio measures the outbound Doppler and offsets the inbound transmit frequency to compensate, but the offset value is communicated to the ground station as part of the channel set up handshake.
hamster3null said,
March 29, 2014 at 6:11 pm
Even though many things are unclear about the nature and the meaning of Inmarsat Doppler data, I think there are a few important facts that we can deduce.
* Aircraft speed is not compensated (subtracted) or else there would be no jumps in the data. Satellite moves slowly, vector from the satellite to the aircraft changes slowly as well.
* Were are looking at absolute values. Satellite-aircraft distance had to be decreasing at 18:25 UTC and increasing at 17:07 UTC. Both points for these times are on the same side of zero (+87 Hz.)
* According to Malaysian radars, the aircraft was headed almost due west at 18:22. Doppler indicates a sharp turn at about 18:27. After that, it would be going roughly north or south. Southern route would take it directly over Banda Aceh, Sabang and a military installation there. Northern route would take it into India. Therefore at least one military radar had to see it. If both India and Indonesia deny seeing it, one of them is lying.
* “Predicted northern track” refers to a specific track, It is not a mirror image of the southern track, because Doppler looks too different. It’s unclear what it is, but it likely leads either north-northwest or north-northeast from last known contact. (Roughly constant Doppler along “predicted northern track” would mean that the track is an expanding or a contracting spiral around 0N 64.5E. An expanding spiral would go north-northeast into Burma and then into China.)
* Whatever rationale Malaysians have for NOT looking to the north, it is not because that track somehow “disproves” that the aircraft went north.
* The spreadsheet linked above reconstructs a few possible northern routes. They look like mirror images of the southern route + adjustments due to satellite inclination, and terminate in Uzbekistan. (I should point out that they don’t match SQ68, they deviate to the northeast of SQ68 at all speeds.) I’d add one more: if we reduce the assumed speed to 400 knots, the northern route would shift further to the east and terminate in Tajikistan.
airlandseaman said,
March 29, 2014 at 6:13 pm
I don’t decommend trying to read this, but for those that just can’t get enough of the details…
http://www.mxmuhammad.com/papers/Future_Aeronautical_Communications.pdf
Alex Siew said,
March 29, 2014 at 6:21 pm
According to the authorities, the last ACARS transmission was at 1.07am and there were 6 completed handshakes (2.29, 3.40, 4.40, 5.40, 6.40 and 8.11am). There were also 3 unexplained signals, at 2.25, 2.27 and the reportedly aircraft initiated ‘half-ping’ at 8.19am.
On the theory that the plane had crashed early on but the upper rear fuselage (where the satellite terminal and its antenna were located) did not immediately sink after the crash but remained above water for several hours, the fuselage would be getting splashed and swept around by waves. The 2.25 and 2.27 signals were probably unsuccessful attempts to complete a handshake before a successful attempt at 2.29. At 3.29 the satellite would have tried again but a connection was only successful at 3.40, likewise for the delayed ping at 8.11. By 8.19 either the battery was running out or the fuselage was getting submerged or both, triggering the terminal to emit one last signal…
airlandseaman said,
March 29, 2014 at 6:31 pm
The Inmarsat data proves the early crash theory is impossible. The Doppler and prop delays are inconsistent with that theory.
airlandseaman said,
March 29, 2014 at 6:40 pm
Inmarsat range and Doppler data proves beyond doubt that the plane was flying until 08:11 or later.
hal said,
March 29, 2014 at 7:19 pm
Question for anyone up and reading tonight …
I’ve been looking mostly at the BurstFrequencyOffset plot after 18:27 and thought I had a good understanding of how and why the two predicted tracks differ. But now i’m looking at the pre-18:27 points and honestly not sure I understand how to interpret the MH370 data OR the two predicted tracks.
Both predicted tracks have a plane that takes off and moves away from the satellite, correct? But based on the graph, neither of them reverses direction and moves toward the sateliite as MH370. If that’s true, then neither predicted track is headed north (or south) at the same longitude as MH370 would have been. Thought of another way, neither of the predicted tracks could ever intersect the 8:11 ping circle.
Question 1: What headings were these predicted tracks actually flying? Has anyone published that on a world map? It looks like they fly approximately to the point where contact with MH370 was lost, then turn either north or south.
Question 2: This changes the range but would it affect the doppler shift enough to make these graphs look different?
Question 3: Has this been discussed already? If so, I wonder if someone might briefly summarize (accepting my apology for not having followed it closely enough).
Alex Siew said,
March 29, 2014 at 7:55 pm
@airlandseaman, not sure what u meant by ‘inmarsat range’ but the Doppler data may in fact prove that the plane was not flying anymore for all six completed handshakes (from 2.29 to 8.11)
Firstly, the arc from the final ping crosses the South China Sea but despite Tim’s best efforts, no one knows why this part of the arc has been excluded from consideration. My theory is that the plane crashed here, not far from the intersection between the plane’s last known flightpath (IGARI-40 degree turn) and the arc.
Secondly, Duncan has pointed out that the satellite was moving northwards until 3.36am when it began its southwards descent reaching speed of 100 knots increasing to 150 knots thereafter. If u look at the Doppler chart, the 2nd completed handshake at around 3.40am is lower than the first completed handshake at 2.29 and from 3.40 onwards the Doppler readings start increasing. Putting aside absolute values, the form of the chart would be consistent with a stationary plane for those 6 handshakes, since until 3.36am the satellite was moving to the plane while after 3.36am it was moving away from the plane at increasing speeds.
I have asked Duncan if he can do a model to prove or disprove the theory, using the known info for the 8 explained signals (the ACARS transmissions at take off and at 1.07am and the 6 completed handshakes), @Hal subsequently joined in the request, but so far Duncan has not responded.
hal said,
March 29, 2014 at 8:24 pm
Has anyone debunked this? Could be fake. However, it was posted very early on.
At about 3:18 in the video, a southwest-moving plane located east of MH370 switches to the “?” icon. After a few seconds, it reappears pointed in the opposite direction and flies northeast very fast.
I know this is a satellite forum not a crazy-theory forum, but if anyone has thoughts and/or can debunk this, I’d appreciate hearing.
hal said,
March 29, 2014 at 8:24 pm
And now the link …
http://www.youtube.com/watch?v=3JtYApCrUDY
duncansteel said,
March 29, 2014 at 8:42 pm
Hi folks:
Thanks for various comments from people. I have noted, quickly going through the comments, that there are various requests that I do x or y or z, but I am very methodical about my approach to any problem (being a badass scientist: tinyurl.com/DS-badass ) and so I need to do p, q and r first.
Right now (nearing 17:41 local time in NZ) I am about to start looking at the doppler aspects of the problem, having given it no real thought previously. When I am done, I will put up a post on my website and leave a message here. I mention the time simply because this has been made out to be terribly complex, needing a vast team of engineers working around the clock for many days. So, compare time stamps from now until my next message.
Ciao,
Duncan
duncansteel.com
hal said,
March 29, 2014 at 8:52 pm
@duncansteele, Ha ha, got it! It is 20:42 PDT here in the SF Bay Area. Thanks for taking the time to work this all out … your posts make for very interesting reading.
airlandseaman said,
March 29, 2014 at 8:57 pm
Alex:
By Inmarsat range, I was referring to the slant range from the s/c to the aircraft, derived from the free space time delay from the aircraft antenna to the s/c antenna, measured by Inmarsat. Range = delay*speed of light. It is these ranges that define the arcs on the earth surface. Inmarsat has not released these delays. Many of us have been trying to get them via various high level channels, but no joy so far. So we have to rely on the various statements and cartoons depicting the arcs. Although we don’t have the definitive data, we do know the ranges changed significantly. We also know the Doppler indicated a turn at ~02:25 from east to either North or South. Thus, it could not have crashed sooner.
hal said,
March 29, 2014 at 11:41 pm
@duncansteele – I’m having trouble squaring the satellite positions & velocities you posted a couple of days ago, with the Burst Frequency Offset (BFO) chart provided by the Malaysian govt. When you get a chance, I’d like your take on the plotted points for 19:40 UTC. At that point the satellite was essentially stationary (having reached its northernmost point) or moving southward slowly. The plot shows the South Track with a way smaller BFO than the North Track (110 hz versus 200 hz). If they assumed the plane is going same speed in both scenarios (lord let us hope) then the BFOs shouldn’t be very different and if anything the northern track should have a smaller BFO since one of its motion vectors is closing the distance with the satellite. I assume the plane had not already passed north of the satellite because if it had then the red plot wouldn’t bend downward at the end but would accelerate up. So I thought I understood this chart, but now not so much.
@alex – I have to agree with airlandseaman that the plot — if I understand it — rules out a stationary airplane at 19:40 UTC, the time of the second ghost ping. The satellite is stationary so if the airplane was also stationary then you’d get a lower BFO than at take-off.
Ole said,
March 30, 2014 at 12:13 am
Hi,
great discussion here, I think.
Doppler shift at 1.6Ghz is 5.33 Hz/(m/s) or 2.66 Hz/knot as per my post above.
The max doppler shift that could be induced by the aircraft’s speed of 450 knot is 1200 Hz the max doppler shift induced by the sat wobble of 150 knot could be 400 Hz.
Only the radial component of the speed matters, the actual doppler shift is smaller. Nevertheless the ranges of doppler shift in the BRO graph strongly indicate that only the doppler shift of the sat wobble is meant (maybe plus some fixed bias due to offset of the AES oscillator). The max delta in BRO is 160 Hz at the southernmost point of the flight !!
Maybe inmarsat has the doppler data of the aircraft’s speed, but then it is not yet published.
The aircraft cannot have stayed in the South China Sea because obviously the yet unpublished ping arc of 2:25 is only consistent with the aircraft being over western Malacca Strait.
Looking forward to Duncan’s analysis of the doppler data.
duncansteel said,
March 30, 2014 at 12:49 am
I have revised my calculations and maps for possible flight paths of MH370 based upon the comments from several people that the time and location of the final radar detection of the aircraft I had used previously were incorrect. The revised material is posted here:
http://www.duncansteel.com/archives/451
*Now* I can start on the doppler problem…
Cheers,
Duncan Steel
Skwosh said,
March 30, 2014 at 1:22 am
@airlanseaman
Ah! I think we may have been talking at cross-purposes.
When I said:
“…the satellite could always send and listen at exactly the same fixed frequencies to each of them at all times…”
What I meant was that the satellite could use the same (one) send and the same (one) listen frequency for *all* of the aircraft – I was already assuming some sort of time windowing arrangement. My thinking was that being restricted to using some sort of TDMA scheme on the same frequency for all the aircraft should be much *more* doable if the aircraft themselves handled the Doppler compensation – then the frequency offset for the received signals from the point of view of the satellite would be more or less zero for all of the aircraft (and similarly the satellite could simply transmit at zero offset as all the aircraft would be adjusting their listening frequency offsets in accordance with their positions and motion) – that is what I meant by “…the satellite wouldn’t have to worry about Doppler compensating for anything at all.”
@duncansteel
You are a machine!
GuardedDon said,
March 30, 2014 at 2:22 am
Re: hal at March 29, 2014 at 8:24 pm
FlightAware & FlightRadar24 get the ADS-B feeds (in this region) from enthusiasts running their own ADS-B 1090ES receivers. The MH370 track shown here was being extrapolated by the site before it even reached the coast. The info isn’t always accurate, I’ve watched aircraft approaching my local airport appear to continue in flight when I know they’ve landed.
Indonesia, Singapore and Vietnam ATC systems employ ADS-B receivers (ICAO reports on traffic management in the SE Asia area) but Malaysia doesn’t (source ICAO report stating Malaysia will deploy 2 ADS-B ground stations during this year and 2015).
Implication of those facts: MH370 was in range of Vietnam’s receiver before the transmissions from the aircraft ceased. Vietnam’s ADS-B station at Con Son has a range of approx 220nm, easily taking in the ‘IGARI’ waypoint.
Re: XocoLatte at March 29, 2014 at 7:02 am
The FPDA/Integrated Area Defence Command is a bureaucratic vehicle for managing liaison between Malaysia, UK, Aus, NZ & Singapore defence forces. Setting up exercises, etc, not an operational capability.
The Malaysian AF has a mixture of RaytheonThales GM400 (x1) and Alenia RAT-31DL (x1) plus RAT-31SL (x?) military radar systems for which they procured a command and control system from RaytheonThales that was commissioned in 2013 to integrate the disparate systems. Deployed locations unknown.
The westerly radar track is still unconfirmed with no MoTM release of evidence for it. To date, there’s been a press report by senior RMAF officer stating they’d tracked MH370, he then retracted the statement as mis-reporting.
Re: Alex Siew – verify info by locating B777 maint manual references describing power feeds for the SDU equipment. Note also, that the installation comprises a number of separate LRUs. They’ll have to remain powered and connected together with the antenna oriented as normal to continue transmitting for 6-7hrs. Onboard WX radar gives the crew excellent visibility of thunder clouds – usually avoided like a plague. As an example, recently, while waiting for a delayed flight at LAS, checking at FlightAware it was evident the inbound aircraft had taken a wide diversion around dense cloud formation (WX radar also shown on FlightAware’s US coverage).
Ole said,
March 30, 2014 at 2:23 am
hal said,
March 29, 2014 at 11:41 pm
————————————————
I’d like your take on the plotted points for 19:40 UTC. At that point the satellite was essentially stationary (having reached its northernmost point) or moving southward slowly.
————————————————
That is a good point. If the sat was almost stationary at 19:40 UTC that means the BFO at that time cannot have a doppler component attributed to the sat’s wobble. Nevertheless in the diagram there is a difference between predicted northbound and southbound path for 19:40.
Now that difference could be caused by an imperfect compensation algorithm of the AES as proposed by @Skwosh. At that time (19:40) the subsatellite point was ~1.5 degree north of the equator, but the compensation algorithm would assume the sat to be stationary right over the equator.
If at 19:40 the aircraft was between the equator and the actual latitude of the subsatellite point, then for a northbound track the compensation algorithm would think it was moving away from the satellite (the equator) whereas actually it was still moving toward the satellite (~1.5 degree north). The compensation would tune up the carrier frequency to compensate for moving away but because the algorithm is mistaken about the actual position of the sat, that compensation would add to the doppler shift that nature induces because the aircraft is actually moving towards the sat.
For a southbound tracks the compensation would do more or less a good job, because the aircraft would actually be moving away from the sat and tuning up the carrier frequency _does_ compensate large part of the doppler shift from nature.
BTW: Yes I think the solution to this is a littler deeper in the weeds. It wouldn’t make sense that inmarsat’s professionals need to weeks to work this out, and we as spectators understand it at first glance.
2una said,
March 30, 2014 at 2:54 am
@ Airlanseaman
………………..
To fine tune the model, you could use the last radar contact as follows:
time: 02:22
lat: 06 52? 03?
lon: 97 20? 21
Average speed between 02:02 and 02:22 was 354 kts ground speed.
………………
Plotting course from that pos above @ 180deg T on WGS1984 using GC routing.
1st pos = 6h x 354kts
2nd pos = 6h x 370kts
The route coming in from the East is a rough guess equaling what they posted for the 28th search area (1850km distance label)
https://farm8.staticflickr.com/7088/13507556795_2ae7ccb275_c.jpg
AndRand said,
March 30, 2014 at 3:56 am
Well, I don’t really believe compensation algorithm is that complicated – it means AES has to have satellite’s trajectory and coordinates in memory because it is not transmitted. I’d rather imagine something much simpler, not prone to error of bad satellite’s positioning.
ps. anybody knows where to find ping delays or distances sat-airplane?
alex370 said,
March 30, 2014 at 4:04 am
Hi Duncansteel,
You proposed paths for certain speeds of the plane look good, but the pictures lack the following info.
1. I assume the paths are the arcs of big circle, what means they are the shortest distances between any two points on the path
2. They assume constant speed of the airplane along the path
3. We have timing for all pings the airplane did.
For all those timings of the pings it would be nice to show the following information on your pictures
– the location of the airplane on the path at that moment of time. We have circles where the airplane was at the moment of each ping. This circle should be a path of your picture for each ping
– the coordinates of where the plane was during that ping, it should be both on the path and on the corresponding circle (part 1 of validation is the location of the plane on the path corresponds to intersection of the path with corresponding circle)
– the distance of this point of the ping from the previous point of ping. Because we assume the speed of the airplane was constant, those distances should be equal to speed times time from the previous ping. That is part 2 of validation.
– the radial speed of the airplane towards the satellite at that moment. You could calculate that because you know the locations of satellite at all those moments. You do not have Inmarsat Doppler data to compare those radial speeds to, but when it becomes available we would easily be able to do that. That is part 3 of validation
That will work as a validation of the calculated paths. “That” is three things – the plane passes the corresponding circles right at the moments of pings, verification of constant speed of the airplane and verification of radial speeds. When all three comply, we know the path is right.
Would you be able to do that?
Thanks
airlandseaman said,
March 30, 2014 at 4:24 am
A few points to be clarified:
1. Just because the s/c speed over ground went to 0 at 19:40 UTC does not mean the velocity was 0. The vertical velocity at that point is unknown (from the speed over ground chart). But it will soon be known when Duncan gets done.
2. I have been interpreting the “BFO” definition to be:
BFO = S/C Doppler + A/C Doppler + Total System Offset (TSO)
…where the TSO is a constant. But after rereading the definition of BFO on Page 1 of the Annex I multiple times, I am not sure how to interpret the definition. We have:
D1 = A/C Doppler we are trying to compute,
D2 = “measured frequency offset” (Not corrected by system)
D3 = S/C Doppler that can be computed from S/C velocity
D3 is easy to calculate if the Australian E/S position is known. But D2 is somewhat ambiguous. What exactly is meant by “expected received frequency”? One likely interpretation is: “expected received frequency” is the frequency expected if the A/C Doppler compensation was perfect. If that is the correct interpretation, then it may not be possible to derive the A/C Doppler from BFO on Page 2 because the A/C compensation is different for every transmission, and undisclosed so far. If this is the case, then the assumption that the TSO is constant is not valid. IOW, there is a new variable introduced. Inmarsat certainly knows what the A/C compensation was for each transmission. It must be sent to the E/S as part of the handshake information. But it is not known to the public.
The is a document on the Inmarsat site that discusses this Annex I here:
http://www.inmarsat.com/news/malaysian-government-publishes-mh370-details-uk-aaib/
airlandseaman said,
March 30, 2014 at 5:04 am
Trying to verify, but I believe the Australian LES referred to in Annex I, Page 1 is here:
31°48’16″S 115°53’13″E
GuardedDon said,
March 30, 2014 at 5:58 am
re: airlandseaman at March 30, 2014 at 5:04 am
Yes, the GES is the Stratos/Inmarsat site near Perth. I think I referred to it in an earlier comment. Your location is correct.
airlandseaman said,
March 30, 2014 at 6:18 am
BTW…It should be noted that, while the offset used by the aircraft transmitter is only an estimate, sufficient for the efficient use of spectrum, it is usually accurate to within 30 Hz, and in any event, the true transmit frequency can be accurately computed back at the LES using the measured Total Doppler, computed satellite Doppler, and the Tx offset value communicated to the LES as part of the handshake message.
If anyone on the inside at Inmarsat is reading this, for God’s sake, please stop the brain damage and share the net-net Aircraft Doppler so we can help!
AndRand said,
March 30, 2014 at 6:29 am
hamster3null said,
March 29, 2014 at 6:11 pm
* The spreadsheet linked above reconstructs a few possible northern routes. They look like mirror images of the southern route + adjustments due to satellite inclination, and terminate in Uzbekistan. (I should point out that they don’t match SQ68, they deviate to the northeast of SQ68 at all speeds.) I’d add one more: if we reduce the assumed speed to 400 knots, the northern route would shift further to the east and terminate in Tajikistan.
Well, for now your spreadsheet can be used to narrow track so it matches Doppler effect based on assumption that shown shifts (http://theaviationist.com/wp-content/uploads/2014/03/BFO-MH370.jpg) resulted strictly from relative velocities.
I also added straight line distance calculations to use it when delays/distances will be published (sent priv on PPRumNet) but need to verify figures.
Nevertheless, with distances assumed from one guestimated track I tried to create another guestimated track – and now with Doppler effect AND distances it significantly minimized possible alternative routes.
duncansteel said,
March 30, 2014 at 6:52 am
Whoever has their finger on the timer, stop now.
I have just posted my analysis of the Doppler shifts (i.e. line-of-sights speeds between Inmarsat-3F1 and putative routes and speeds for MH370) on my website at:
http://www.duncansteel.com/archives/467
Anyone who wants a copy of the Excel spreadsheets containing the data I have plotted in the above post, please let me know via my website and I will oblige when I am able (i.e. after catching some sleep).
Cheers,
Duncan Steel
AndRand said,
March 30, 2014 at 7:15 am
Here is what I obtained from matching distances and doppler shift:
http://oi60.tinypic.com/2prgyee.jpg
The light-red track is one matched to doppler effect only.
The mirror dark-red track is obtained by matching doppler shift as measured AND line-of-sight distances sat-aircraft (in km) resulted with first track.
You can also do it with alternative south route:
https://docs.google.com/spreadsheet/ccc?key=0AhvpxNRGOuapdG15UnlRNm9STVhtdFEzcElTOTFFR2c&usp=sharing
hal said,
March 30, 2014 at 7:20 am
@duncansteele – Wow that’s dedication.
@airlandseaman – You said ” Just because the s/c speed over ground went to 0 at 19:40 UTC does not mean the velocity was 0.”
The satellite has vertical velocity?
seanmcleod said,
March 30, 2014 at 7:23 am
Thanks Duncan.
So Duncan’s LOS (Line Of Sight) velocity all due to the satellite while the aircraft was stationary on the ground before take-off is 0.021km/s, so 21m/s.
Ole mentioned earlier that @1.6GHz we’re talking about 5.33Hz/(m/s) so with a satellite LOS velocity of 21m/s => 111.93Hz. Versus the 87Hz listed in the Burst Frequency Offset graph released by Inmarsat.
hal said,
March 30, 2014 at 7:33 am
@AndRand – If I’m interpreting your graph and tracks correctly then your track looks like the published ones early on but not after 3:40 am. Also your results appear to be same for north & south route. I have to assume the inmarsat folks know more than we do. What would you have to add to your model to get the northern track they have published?
AndRand said,
March 30, 2014 at 7:40 am
According to pilots info, one heading and speed could be strong assumption – you need ie. manually switch fueltanks when one is empty. Therefore changes of course are also to be taken into account.
Thus I advise you to use both doppler shifts and distances – those data have only one resulting route. As northern mirror track – there is almost no other possibility for northern track matching distances (not less than 5km) and doppler shifts.
AndRand said,
March 30, 2014 at 7:49 am
@hal:
As I described earlier:
- first track (light-red) was obtained (using hamster3null spreadsheet) matching doppler shifts as provided by malaysian authorities in diagram.
- with added line-of-sight distance calculation (3D slant ranges of sat-aircraft) I obtained second track matching doppler shifts and distances (as you can see on diagram attached)
This is only EXAMPLE – line-of-sight calculated distances were assumed from light-red track (which is guestimated).
With REAL measurements of distances it could be decisive.
hal said,
March 30, 2014 at 8:13 am
@AndRand – sorry but your responses are not parsible. In your 7:40 am note, what does “there is almost no other possibillity for northern track matching distances.” Are you saying the track you’ve plotted is precisely the same as the southern, or impossible?
In your 7:49 am note, I don’t see any answer to my question about a northern track. You plotted a northern track on your world map but not on your BFO graph.
Thanks
hal said,
March 30, 2014 at 8:14 am
@duncansteel – Great work, it’s nice seeing all the tracks on a single plot.
AndRand said,
March 30, 2014 at 8:17 am
@hal:
Are you saying the track you’ve plotted is precisely the same as the southern, or impossible?
Other northern tracks are implausible – the one showed is probably only one, ie. SIA68 route will not much distances or doppler shifts.
The same goes with southern tracks.
AndRand said,
March 30, 2014 at 8:19 am
It is like with 2 sources of ping delays: with 2 satellites pings you would obtain only 2 tracks.
Ole said,
March 30, 2014 at 8:33 am
Duncan, thanks for that.
If we assume constant speed the instant speeds you provide multiplied by 3600 – or whatever the time in seconds between the pings was – should give an idea of how far the ping arcs are separated.
@seanmcleod
the missing 25Hz on the ramp could be due to the residual error of the transceiver’s oscillator?
What i completely fail to understand is why the doppler shift never get’s smaller than the 87 Hz at the ramp. The freq up/down conversion in the sat and the demodulation may eliminate the sign of the doppler shift, but i would still expect the doppler shift to be smaller (closer to zero) than at the ramp at some point.
alex370 said,
March 30, 2014 at 8:34 am
To duncansteel
According to Inmarsat data, the Doppler frequency shift doubled between 19:00 and 00:00
According to your data, the radial speed doubled between those moments of time for speed of the airplane bout 300.
At the same time, they are proportional to each other, because
delta f / f = delta v /c
That is why delta f doubles when delta v doubles.
airlandseaman said,
March 30, 2014 at 8:52 am
hal:
Yes, the satellite is moving, relative to the center of the earth, in all 3 dimensions. The figure 8 is a 2 D projection of the lat/lon on the ground.
Ole said,
March 30, 2014 at 8:54 am
Duncan, would it be much work to separate the line of sight speed of the sat only?
If the published burst offset are attributed mainly to the sat’s motion then that would give a good comparison.
Skwosh said,
March 30, 2014 at 10:39 am
@Ole – agreed about the mystification!
I think it would be fantastically useful if Duncan could also add an approximation of the Inmarsat 450 knots southern route track to his model (though I appreciate he is only human (!) and that all he would have to go on is the image of Google earth with the yellow line on it in the press release).
However, if this were done then it becomes possible to test various hypotheses about what the burst frequency offset (BFO) graph is actually showing, and how the values for a given track might be calculated. This (southern track) is the only case where we have both a known (roughly from the yellow line on the image) track *and* also a known corresponding BFO plot. It might then be useful to focus on seeing if anyone can come up with a way of deriving the BFO values on the green line on that graph from the 450 knot Inmarsat southern track.
seanhelmi said,
March 30, 2014 at 10:40 am
I found the following post on a forum that explains the timing and how the RTT or time of transmission of signal can be measured accurately without synchronized clocks on the satellite and aircraft and without an atomic clock or equivalent on the aircraft. It looks like the aircraft utilizes the satellite’s own continous “tick-tick” beat to time the aircraft’s response transmission. Like a guitar player who knows to start playing on the drummer’s fifth beat without necessarily knowing or caring about the actual time interval between each drumbeat. The drummer, in turn, times the guitar music start against the drum’s own beats.
Based on this structure it is theoretically possible to determine the distance of the aircraft from the satellite (time offset of return signal) and the aircraft’s velocity relative to the satellite (frequency shift due to Doppler effect). Obviously there are unknown variables (such as altitude) that affect the result, but the basic theory is sound. Any fundamental criticism of the approach has to be based on something exogenous to the calculation, such the signal came from another aircraft and was mistaken for MH 370 (that would be a pretty fundamental mistake).
A very good check on all this would be to calculate the position of MH 370 as of the last ping before the transponder turned off, i.e., calculate the position and velocity based on the ping time offsets and compare this to the actual, known and verified position and velocity. I am surprised that Inmarsat reporting checking the calculation against other planes in the “arcs” but not against MH 370′s actual known position at an earlier point in the flight. Perhaps this has something to do with the “gap” in the north and south arcs?
Anyway below is the by “AT1″ on March 17, 2014 at http://www.pprune.org/rumours-news/535538-malaysian-airlines-mh370-contact-lost-356.html. Obvious I (Seanhelmi) take no credit for the post:
I am a telecoms engineer, nothing to do with aviation.
Pings – let’s see if we can sort this out.
The satellite is always transmitting. Think of it as a steady “tick??? from above. The receiver, not the ACARS system, or any other similar higher function in the plane, just the receiver is always listening to the tick. IN fact the receivers on all the planes and boats are listening to the “tick”. By clever encoding the “tick??? carries information to say “this is the start of my sequence of messages??? at defined intervals, and then it sends data intended for specific receivers in various time slots. Of course, all receivers “hear” all the messages, but they only actually “listen??? to the ones intended for them. But the background “tick??? keeps going all the time, so every receiver can synchronise itself all the time, keeping track of where the sequence of messages starts, just listening and waiting for a message from them. When a receiver recognises a message is for that particular receiver (i.e. plane), of course it “listens??? to the message and acts accordingly, passing the message on to the appropriate unit where necessary. But one of these messages it watches for is a message saying “are you still there???. When it gets that message the receiver has to reply in the correct “slot??? to say “still here???. So now the sat system on the plane has to transmit to reply. In this case the reply is effectively an automatic response from within the satellite receiver – nothing else needs to be involved.
But notice the response to the “are you still there??? message has to be sent in the correct time slot. Remember the receiver is listening to the “ticks??? from the satellite all the time – not just when there is data to exchange. All the time, so the plane has a “clock??? ticking at the same rate as the satellite’s clock. But, the plane’s clock is running late all the time as it takes time for the “tick??? sent out by the satellite to travel the 35,000 km to the receiver. The equipment on the plane then has to reply in the correct slot after it has received the “are you there??? message and so it replies. Now, the satellite has a problem. Because it does not know how far the plane is away, it actually does not know when the reply to its message is going to arrive. It cannot do what the plane has done and keep a “copy??? of the plane’s clock ticking away because, firstly, the plane is not transmitting its own “tick??? for the satellite to follow, and in any case it would need to have a similar clock running for every plane and ship using the service. In any case it does not need to.
What it does is allow a window for the return message to arrive. It has a petty good idea since it knows the earth is 35,000 Km away as a minimum, less the altitude of a plane, of course. It knows that the “receiver??? has to respond so many ticks after receipt of the request. It knows the receiver has a good clock tick signal – it is the very signal the satellite is transmitting. So it has a time window when a response can be expected. The reply will arrive at the early end of the window if the message is from a transmitter directly under the satellite, later from one at the edge of the coverage, earlier from a plane than from a ship etc.
Now, here is the bit I have not seen mentioned before. The “tick??? is related to the frequency of the satellite’s radio band. It has little to do with the relatively slow rate at which data can be sent over the communications channel. The frequency of Inmarsat C is around 1600 MHz. That is 1,600,000,000 “ticks??? a second. So the timing resolution the satellite can see is to an accuracy of 1/1600000000 of a second. Light is fast. But the amazing speed of electronics we now have is such that we can measure time with astonishing precision. Just think about those l@ser tape measures you can buy. You can measure a distance to a millimeter, and they work by timing pulses effectively, all in something you can buy for a few £/$/Eu. Think about a GPS set. An ordinary GPS set will give you a position with in a few metres, limited not by the ability of measure time, but by various vagaries in the transmission of the signals. A “pro??? surveying GPS set does clever things to reduce the vagaries, and while it may take a few minutes to give a good “fix??? they can give your position to typically 15mm accuracy. Given longer to analyse and process the signals, weeks in some cases, to an accuracy of considerably less than 1mm. Note, accuracy, not resolution. Absolute accuracy, and all without a fantastically expensive atomic clock at the “user end??? though there are several in each orbiting GPS satellite.
So, back to our satellite. It was expecting a response at “tick??? number XYZ and it actually arrives at “tick??? number XYZ + whatever. It knows, because it is in the standard, that the receiver on the plane is obliged to reply exactly N ticks after receipt of the request, so by subtracting N from XYZ + whatever it knows how long the message has taken to transit to the receiver and back again in “ticks???. Halve that and you have how many ticks away the plane is. One “tick??? is 1/1600000000 of a second. In a vacuum- and remember part of this journey is not in a vacuum – 3 x 10 to the eight metres. So, divide this by 1600000000 i.e. by 1.6 times 10 to the nine and you get about half a metre as the potential accuracy (the satellite will have a VERY accurate clock onboard) and resolution of ths measurement. In principle the satellite could determine how far away the responding receiver/transmitter was to a precision in the order of a metre. In practice there would be no point in measuring this accurately and in any case the presence of the atmosphere and variations in the precise timing in the receiver makes this rather “optimistic???. These are, after all, communications systems not navigation systems. The satellite does not need to know to this level anyway, it can work with signals arriving in the allocated window.
This is a very simplified explanation, not always desperately accurate, but basically shows how it works. For example the frequency used for the plane to reply is actually slightly lower, but it will be locked to the satellite’s transmission clock tick.
As a further explanation, think of a lighthouse flashing away constantly with a constant beat. It flashes white. You sit and watch holding a torch. You watch and watch and tap your foot to the beat of the white light. You are told that if the light flashes red you MUST flash your torch back three beats later. And you do exactly that, exactly three beats later. The man at the lighthouse is watching and from his point of view he sees a torch flash back not three beats later, but three and a bit beats later. The three beats if the time you have been allowed to wake up, get your finger on the flash button, the “and a bit??? is the time it has taken the light to get from his lighthouse to you plus the time it has taken your torch light to get back. Clearly in this case you could not measure the distance in this way, but you can see the principle.
As has already been shown, the satellites are at a very precisely known height over the earth, so equal distances from the satellite are where concentric cones intersect with the earth – circles on the earth’s surface representing equal elevations of the satellite.
My suspicion is, and I say no more than a suspicion, that the satellite’s system can also measure the frequency of the reply accurately and so have some estimate of the relative velocity of the plane relative to the satellite, but the geometry will limit how much use this would be. Clearly the plane’s altitude when transmitting is relevant; you would not be able to differentiate between a low plane nearer the point the satellite sits over and a higher plane further away.
I also suspect that the satellite would keep a log noting that it had received a response the “are you there??? messages at such and such times, but it would only keep the technical details of the latest transaction, as this would help in allocating its time slots efficiently. Remember, while memory to hold this sort of data is cheap, on a satellite power is the limiting factor all the time, and weight adds to the “delivery??? cost of getting these things up there. So the commercial birds would not want to retain data that they did not need to hold for longer than necessary. The logs may be downloaded to the ground too, but even downloading takes power.
Hope that helps. I have been reading all the posts since this thread opened. There are some on here that simply waste effort – and show complete disrespect, but there are some incredibly insightful and helpful posts here conveying real information. Not all are “hard??? facts, but many are fascinating, like the description of what it is really like in a search plane. Many thanks to the posters.
seanhelmi said,
March 30, 2014 at 10:52 am
Another check would be to fly a similarly equipped aircraft along the now-believed southern route and compare the satellite transmission/receipt data with the actual position of the aircraft, and then see how this compares with the data from MH370. Expensive to fly an aircraft to the middle of nowhere just to receive and reply to satellite transmissions, but small cost compared to the cost of just one debris search flight out of Perth.
alex370 said,
March 30, 2014 at 1:30 pm
Hm…
I take the predicted frequencies from Inmarsat data, with your minutes.
minutes Doppler shift
1180 115
1240 153
1300 180
1360 215
1450 265
Delta frequency should be proportional to delta radial speed (from your data), because delta frequency / frequency = delta v / c , and we know that frequency and c are both constants
Dividing delta speed for minute 1450 to delta speed for minute 1180 we get:
speed 200 knot – 1.52
250 – 2.00
300-2.89
350 – 4.87
400 – 12.33
For Inmarsat data in frequencies 265/115 = 2.33
That is between 250 and 300.
So, when I project linear portion of data, I see that the speed of the plane should be between 250 and 300, more close to 267.
If I do the same type of interpolation for other minutes points )1240, 1300, 1360) I get the speed of the plane is between 255 and 267 knots.
That is from Doppler data.
It would be also interesting to use data from other pings, and mark the location of the planes on the paths you provide at the very moments of pings, using circles New York Times provide for other pings. Then calculate the distances between points and validate that that complies with the speed of the plane.
seanhelmi said,
March 30, 2014 at 1:36 pm
According to a March 25, 2007 news report at:
http://news.xinhuanet.com/english/world/2014-03/25/c_133213331.htm
“Yet he [Malaysian spokesman] also mentioned that while on the ground at the Kuala Lumpur airport, and during the early stage of the flight, MH370 transmitted several messages. “At this stage the location of the aircraft and the satellite were known, so it was possible to calculate system characteristics for the aircraft, satellite, and ground station,” he said.”
So it appears Inmarsat did in fact run the calculation for transmissions at known locations earlier in the MH 370 flight. One assumes the results validated the formula before it was used on subsequent transmissions from (unknown) locations.
Still frustrating not to have the raw data. Is there a national security concern? Revealing the process and the nature of the data received already discloses everything an adversary would want to know about Inmarsat’s process and capabilities. As Mr. Farrar found, Inmarsat already has a patent on the process, which both discloses and legally protects the process from copying by others. So why not disclose the raw data and let others review and have a go? Once the basic process is disclosed, the rest is trigonometry and relativity albeit very complex. Failure to disclose leaves a “black box” impression that does not inspire the confidence to which Inmarsat may well be entitled.
hal said,
March 30, 2014 at 5:18 pm
@AndRand – Thanks for the clarification. The northern route was ruled out by inmarsat technicians using the graphs we’ve been discussing. If you feel that you have proved even ONE northern route is plausible, then it is important to communicate very clearly what your results are and how you got them.
hamster3null said,
March 30, 2014 at 6:07 pm
@hal,
Consider this puzzle. They have a wide range of plausible southern routes, so wide that their endpoints span the distance of more than 500 miles. If their data is in agreement with all these routes, how is it possible to rule out all northern routes at once?
And also this. Imagine Earth as seen by the Inmarsat satellite. Take any of their southern routes and do a mirror image from the satellite’s point of view. (This won’t be exactly the same as mirror image in the frame of reference where the Earth is motionless, but it will be close.) Is it apparent to you that the result would be an equally valid route with exactly the same travel times and Doppler delays, just headed north?
So why are they claiming to have ruled out anything?
Here’s my working theory. Investigators can’t rule out the northern theory completely just with ping delay and Doppler data. But there is a second piece of information. Investigators have been told by Indians and by Thais that MH370 has not been seen by their military radars. So they took this as a given and tried to plot a route that could take it to the north arc without being seen by either country. If you look at the map, there’s not a whole lot of options and MH370 would pretty much have to head straight north into Burma. It is that specific route that is marked on the Doppler chart as “predicted north track”. They have not ruled out all north tracks, because it’s impossible. They have ruled out the possibility of it flying into Burma.
Most if not all valid north route solutions (mirror image tracks) cross Andaman Islands and at least part of Indian mainland. Those are excluded by Malaysian authorities because Indians told them so and not because of any sciency stuff.
alex370 said,
March 30, 2014 at 6:19 pm
hamster3null,
Looks like you are either not familiar with what Doppler affect is or are not familiar with with the fact that the satellite is actually moving north ans south. The situation is not symmetrical at all. Northern theory is completely ruled out.
jcollins said,
March 30, 2014 at 6:19 pm
What I’m wondering is how the delta offset between 00:55 and 01.07, that is shown on the “burst frequency offset analysis” graph, is evidence of a “turn back”, considering that no such evidence of a “turn back” appears in the flightradar tracking data, which shows a steady track of 25 until MH70 turns to the right (?) on track 40 (the final record) and the transponder fails (or is switched off) at 1:21. I’ve always been under the impression that the turn-back occurred AFTER the transponder died some 14 minutes after the ACARS transmission at 1:07. Interesting that the altitude in this final record is shown as 0 (zero}. I wonder what is implies. Is it evidence of an impending transponder failure or some other more serious failure? The Malaysian Military radar shows a turn to the right (south) at the point of transponder failure, followed by a right turn to the NW, followed by a left turn to the SW, and a path back over the peninsula to the strait.
If ACARS was switched off (or failed) prior to 1:37 (the scheduled transmission) how can any of the “pings” after that be attributable to ACARS?
hamster3null said,
March 30, 2014 at 7:08 pm
@alex370,
From the point of view of the Earth, the satellite is moving. From the point of view of the satellite, the Earth is slowly rotating up and down. It does not prevent you from drawing a mirror route in that frame of reference.
Imagine that you’re standing still next to a two-way road and you hear a car driving in the distance. You can hear its engine noise which is Doppler-shifted by the speed of the car. Can you tell which way it is headed, just from the sound? No, you can’t, the situation is perfectly symmetrical. If you know the native frequency of the engine, you could figure out that it is approaching you at, say, 60 mph (you just don’t know the direction).
Now start walking along the road. You hear another car with the same frequency and the same Doppler shift. Can you tell which way it is headed now? No, you still can’t – the situation is still symmetrical. Now it might be coming towards you at 57 mph (relative to the ground) from the direction you’re going, or at 63 mph from the opposite direction.
duncansteel said,
March 30, 2014 at 10:08 pm
Hi All:
Just a few comments/responses here to things posted above.
(1) “The satellite has vertical velocity?” Yes, of course. Its vertical speed is only zero as it passes perigee and apogee in each orbit.
(2) “Thus I advise you to use both doppler shifts and distances”. Well, we’d love to do that. But we don’t have distances because the ping time delays have not been released.
(3) “According to Inmarsat data, the Doppler frequency shift doubled between 19:00 and 00:00. According to your data, the radial speed doubled between those moments of time for speed of the airplane bout 300.” The first sentence there is, I believe, incorrect. You have interpreted the Burst Frequency Offset as being *directly* a Doppler shift in frequency. It is an *offset*. That is, zero LOS speed does not necessarily correspond to a zero Burst Frequency Offset value. At 16:30 the aircraft was stationary on the ground at KL. The Burst Frequency Offset then was about 87 Hz, from the Inmarsat graph. I have calculated the LOS speed satellite to aircraft to have been about 0.021 km/sec then, due entirely to the satellite’s movement at that time. However, one cannot use that, I believe, to derive LOS speeds from other points in the graph. That is, one cannot say that 87 Hz is equivalent to 0.021 km/sec and then jump directly to other LOS speeds from the Burst Frequency Offset values. On this point, I would welcome elucidation from anyone who really understands this point/matter.
(4) “Yes, the satellite is moving, relative to the center of the earth, in all 3 dimensions. The figure 8 is a 2 D projection of the lat/lon on the ground.” Whilst that figure might be a figure-8 for some satellites with certain combinations of inclination, eccentricity and time of perigee compared to nodal crossings, in general the statement is not true. In the case of Inmarsat-3F1 the form of the motion of the sub-satellite point (i.e. the pattern on Earth’s surface) is a highly-elongated, slightly-asymmetric oval perpendicular to equator, as I showed in this post: http://www.duncansteel.com/archives/362
(5) Ole asked: “Duncan, would it be much work to separate the line of sight speed of the sat only? If the published burst offset are attributed mainly to the sat’s motion then that would give a good comparison.” First, on the second sentence: I would need to confirm it, but I believe that most of the Doppler shift (coded in a certain way in the Burst Frequency Offset) is due to the aircraft’s motion, not that of the satellite. But the definitive statement on that does indeed depend on the separate contributions to the LOS speed from (i) The satellite; and (ii) The aircraft. Thus I will see whether I can do the separation you request. (Well, I know I *can* – it’s a matter of how to go about it, and how long it will take.)
(6) “I think it would be fantastically useful if Duncan could also add an approximation of the Inmarsat 450 knots southern route track to his model (though I appreciate he is only human (!) and that all he would have to go on is the image of Google earth with the yellow line on it in the press release).”
If you compare my 450 knot track with the Inmarsat one (i.e. their yellow line) you will see that they are almost identical. Thus I might claim that I have already (unwittingly!) done what you suggest. However, you will note that the Inmarsat line for a 400 knot speed (their red line) does NOT correspond with my 400 knot line; my 400 knot line continues almost due south until it reaches the ping arc for 00:11 UTC, whereas the Inmarsat red line veers eastwards to terminate also on/near the ping arc but about 5 degress further north. The reason for this is seen at the start of the red track: the Inmarsat people have assumed the aircraft continued on a path headed WNW for a while, and it is the time taken in that segment of the overall red track that forces the eventual intersection with the 00:11 UTC ring arc to be further north and east than mine. That is, in their chart Inmarsat has compared apples and oranges. A proper comparison of possible routes based on assumed speeds must start from the same point! Oh dearie me.
(7) “It might then be useful to focus on seeing if anyone can come up with a way of deriving the BFO values on the green line on that graph from the 450 knot Inmarsat southern track.” Yes, I intend to attempt this ASAP.
(8) “Another check would be to fly a similarly equipped aircraft along the now-believed southern route and compare the satellite transmission/receipt data with the actual position of the aircraft, and then see how this compares with the data from MH370. Expensive to fly an aircraft to the middle of nowhere just to receive and reply to satellite transmissions, but small cost compared to the cost of just one debris search flight out of Perth.” Yes, this is precisely what I suggested on the Guardian website on 28th March:
http://www.theguardian.com/world/2014/mar/28/flight-mh370-search-zone-moved-based-on-planes-fuel-consumption#comment-33660918
…and I think I repeated it on this discussion thread. So I agree with you seanhelmi!
(9) “It would be also interesting to use data from other pings, and mark the location of the planes on the paths you provide at the very moments of pings, using circles New York Times provide for other pings.” No kidding it would be ‘interesting’! But we *don’t have the time delays from the other pings*. And the circles in the New York Times graphic were figments of someone’s imagination. We now know the times (UTC) of the pings from the Inmarsat BFO graph; but we do not know the time delays measured in each one. Again: shout and scream through you local media for those time delays to be released to the public.
That’s my responses to various posts.
Simply FYI, what I am doing next (meaning: the next several hours) is re-doing my Doppler shift/LOS speed analysis for some sample northerly routes. What I want to achieve with that is to verify that the northerly routes can indeed be excluded by the BFO information.
Cheers,
Duncan Steel
duncansteel said,
March 30, 2014 at 10:43 pm
I was about to start work on looking into the Doppler/LOS speeds for possible northerly routes when a query came in about the southerly route LOS speeds that I had posted earlier today. I believe that it might contain an important insight. You can find the comment and my response on my website, but here it is below for your convenience.
DS
————————————————
Dear Chong Meng,
Please forgive me if that is not the right way to address you.
Thanks for your message about my MH370 posts.
You wrote: “I noticed on Inmarsat’s burst frequency offset versus time plot revealed a drop in frequency approximately between 18:30(UTC) and 19:45(UTC). It seems to correlate with the timing of I-3 going round the northing tip of its track that you provided in an earlier post (that is if I counted the ticks correctly). If the change in Doppler between I-3 and aircraft motion was as significant as suggested by Inmarsat’s measurement, I would expect but did not notice similar variation in the Line of Sight Speed vs Time plots around those period . I appreciate it if you could enlighten me.”
I think that is potentially a very valuable and important observation. I posted my plots very soon after calculating them, and have yet to give them proper thought in terms of interpreting what is going on.
You are correct about the satellite reaching its most northerly point at about that time, and I think I pointed this out in a previous post.
The implication of that is that, apart from some vertical motion, the satellite is almost stationary relative to the aircraft and so contributed little to the Doppler shift at that time. However, I need to extract the two components of the LOS speed from each other (i.e. satellite component versus aircraft component) in order to understand this better. I have noted this elsewhere: http://tmfassociates.com/blog/2014/03/24/understanding-the-satellite-ping-conclusion/comment-page-5/#comment-21867
As you have noticed, however, for all the speeds of my simulant aircraft the LOS speed between 18:30 UTC (1110 minutes in the plots) and 19:45 (1185 minutes) are monotonically increasing, and so one would expect a steady increase in the burst frequency offset (assuming that an increase in the BFO implies an increase in the LOS speed/Doppler shift) whereas in fact a fall in the BFO appears in the Inmarsat graph between those times.
What does this mean? My immediate suspicion would be that the aircraft actually continued after 18:30 UTC for a while on a path such that the BFO dropped below 100 Hz (but there appear to be no data/no pings then) until 18:45 or even 19:00, and *then* turned onto its southerly path (resulting in a monotonically increasing BFO and LOS speed, which was first sampled with the ping at 19:40).
Does that make sense (in terms of the interpretation of the data) to you?
Kind regards,
Duncan Steel
Alex Siew said,
March 30, 2014 at 11:21 pm
Duncan,
Does my suggestion that the Doppler Effect chart shows that the plane was stationary (at somewhere north east of the satellite) at all 6 completed handshake times, make no sense to u whatsoever…..
Ole said,
March 31, 2014 at 12:04 am
Duncan,
@Skwosh proposed an algorithm for preemptive compensation that the AES might use to compensate/eliminate part of it’s own doppler contribution.
That algorithm would calculate the expected doppler contribution due to the plane’s speed vector, and preemptively tune the carrier frequency of the transceiver into the opposite direction of it’s calculated doppler contribution.
Because it would be difficult to constantly provide that algorithm with the ephemeris of the sat’s orbit, for simplicity that algorithm might assume the sat to be stationary above the equator.
*IF* this is the case, that algorithm would never compensate the doppler component contributed by the sat’s motion.
Furthermore this algorithm would introduce an intrinsic error: It cannot calculate correctly the LOS component of the plan’s speed vector, because it is mistaken about the sat’s position in space. This error – due to miscalculation of plane’s LOS speed – would be worst when:
a) the subsatellite point is furthest from the equator
b) the plane is closest to the equator
My suspicion is, the difference in predicted BFO and the minimum in measured BFO at 19:40 mainly result from a peak in error of compensation.
jcollins said,
March 31, 2014 at 12:12 am
@hamster3null,
This is fun! It’s true that, whether one is standing still or moving, one cannot tell in which direction a constant frequency sound source is traveling, on the basis of frequency only, unless one knows the “native” frequency, in which case one can determine whether the source is approaching or receding. However, it is precisely the varying frequency of the received signal from the satellite that the aircraft’s AES is measuring. It varies with the direction of travel and speed of the aircraft relative to the satellite. If an aircraft is traveling northward relative to a satellite which is traveling northward relative to the equator, the frequency of the signal received by the aircraft (the AES) will be shifted up relative to what it would be if the satellite were stationary. Similarly, an aircraft traveling southward of the northward traveling satellite will notice a downward shift in the frequency of the received signal as compared to that from a stationary satellite. It should be possible to compare the burst frequency offsets of the missing aircraft (flight 370) with those of similar aircraft flying similar “northern” and “southern” routes to determine which route the aircraft took.
Ole said,
March 31, 2014 at 12:17 am
Little correction to my previous point b):
The compensation error would be worst when:
a) the subsatellite point is furthest from the equator
b) the plane is closest to the _sat_
IMHO at 19:40 both these conditions apply.
seanmcleod said,
March 31, 2014 at 12:23 am
Alex Siew, so in the case of a stationary aircraft you’re assuming that the difference in ping delays was only due to the movement of the satellite?
Also Inmarsat have a ping within minutes of the last radar contact to the west of the Malaysian peninsula, and assuming the arc for that ping is fairly close to the last radar contact how does a stationary aircraft fit with the data Inmarsat have released for the last ping, i.e. the arc far to the east of the last radar contact?
seanmcleod said,
March 31, 2014 at 1:21 am
Duncan regarding your comments on the Inmarsat red track having a different starting point to the yellow track before they turn south maybe given the double constraints of the ping arc data and the Doppler data for each ping that was the only way they could get the 450kt and 400kt tracks to match both constraints.
Alex Siew said,
March 31, 2014 at 1:43 am
@seanmcleod,
As to your first question, yes, i suspect so. According to Duncan, the satellite reached its northern apex at 3.36am when it began to descend southwards reaching speed of 100 knots increasing thereafter to 150 knots. I am still waiting to see if Duncan would be inclined to have a look at the known info for the 8 explained entries (plane stationary at KL airport, 1.07 ACARS and the 6 completed handshakes) to prove or disprove this theory.
As to your second question, there is no evidence to show the plane turned west or that the unidentified blip seen on primary radar at 2.15 or 2.22 at VAMPI or MEKAR was MH370.
Skwosh said,
March 31, 2014 at 1:47 am
Duncan.
Your effort, feedback, and dedication continue to amaze and inspire me.
With regard to the Doppler data:
At present your working assumptions (not unreasonably) appear to be:
(1) The burst frequency offset (BFO) plot is the frequency (less a constant) of the aircraft’s transmissions as observed at the satellite.
(2) The aircraft is always transmitting at the same fixed frequency – call it f0.
Thus – entirely correctly, I believe, *given* the above assumptions – you are attributing the BFO plot entirely to the Doppler shift introduced by the variation in the satellite to aircraft relative velocity along their line of sight (LOS).
frequency_at_satellite = f0 + ( f0 * aircraft_to_satellite_LOS_velocity(t)/c )
However, I think you (like me, and I think Chong Meng, Ole and others) are now beginning to suspect that it is difficult to reconcile some of the features of the BFO plots with the above straightforward interpretation, particularly in the case of fairly ‘straight’ aircraft tracks.
This was why I suggested mocking up the Inmarsat 450 knot southern track to see if the above assumptions reproduce the green line on the BFO plot.
Were it to become clear that the above assumptions may be flawed I would suggest that some additional complication may be required.
How about broadening assumption (2) above:
(2) The aircraft is *not* always transmitting at the same fixed frequency and is instead applying some sort of dynamic correction to its transmission frequency – call it f0 + correction(t).
I would argue that we have reasonable evidence (given prior comments of people who are likely very well informed) to suspect that some sort of ongoing correction may have been being applied by the aircraft.
Then (assuming the correction is small) would expect the following:
frequency_at_satellite = f0 + correction(t) + ( f0 * aircraft_satellite_LOS_velocity(t)/c )
I do not know what this correction is (or indeed if it exists at all!)
However, as I have suggested previously, as a first guess it may be worth trying the following:
correction(t) = – f0 * aircraft_to_fixed_satellite_over_the_equator_LOS_velocity(t)/c
Regards – and respect!
seanmcleod said,
March 31, 2014 at 1:49 am
Ole in terms of preemptive Doppler compensation by the aircraft based on the satellite being completely geostationary then when the aircraft was on the ground before takeoff it’s Doppler compensation would’ve been zero given that it’s ground speed was zero and it assumes the satellite is stationary.
So in this case the burst frequency offset would be solely due to the satellite’s current position and it’s velocity vector.
Duncan computed this LOS as 21m/s which at 1.6GHz works out to 112Hz versus the published 87Hz.
Maybe the difference of 25Hz is some system bias component?
seanmcleod said,
March 31, 2014 at 2:02 am
Alex Siew, in terms of the unidentified radar blip west of the Malaysian peninsula round 2.15am there is an Inmarsat ping within a couple of minutes of that. Inmarsat given that ping would’ve calculated a distance/arc for that ping.
On the assumption that the plane never turned west then there would be a large distance between the radar position and the calculated arc for this ping.
Don’t you think Inmarsat would’ve noticed this discrepancy? As opposed to them being within a fairly close distance given the ping resolution?
And yes, if Inmarsat/accident investigators released all the ping data then we could double-check this.
sSquare said,
March 31, 2014 at 2:17 am
The routes currently assume constant heading and speed. Why are the constant magnetic heading routes not indicated?
The best minimum square error fit could indicate the correct assumptions.
Alex Siew said,
March 31, 2014 at 2:36 am
@seanmcleod,
Unfortunately there were 3 entries around that time, 2.25, 2.27 and 2.29am. Reading the statement accompanying the chart which referred to 6 completed handshakes, i assume that the 2.29am entry was the completed handshake (the first completed handshake followed by 3.40, 4.40, 5.40, 6.40 and 8.11)
The last ACARS transmission is said to be at 1.07am. That means the 2.25 and 2.27 entries were neither completed handshakes nor ACARS transmissions. No one has come out to say what these entries are. I suspect these entries were unsuccessful attempts by the satellite to complete a handshake before the successful attempt at 2.29.
As i have argued in a previous comment, since these 2 entries are apparently anomalies ( a bit like the ‘half-ping’ at 8.19am), it may not be prudent to draw too many conclusions from their offset readings. However, these entries do allow some wriggle room for those inclined to believe there was a turn at that time to the west, or north or south. I would read the Doppler chart as indicating that the plane was east of its original position at all ping times but theoretically the plane could have flown westwards in between any 2 pings but then turned back east before hitting the next ping.
Common sense would suggest that if the RT timings and arcs for the first 5 pings support Inmarsat’s theory of a turn west or that the plane flew in a magnetic or straight line to the Southern Indian Ocean, they would have released the data by now.
timfarrar said,
March 31, 2014 at 2:49 am
Skwosh,
I think you are correct – the plane does pre-correct for Doppler shift due to its own speed. My assumption is that this correction is (at least somewhat) quantized, and thus the residual in the Doppler shift is unpredictable – you can tell something has changed (like the possible turn on the diagram) but not exactly how much. That’s why it will probably be difficult if not impossible to find anything definitive from the absolute Doppler values (as opposed to the relative differences between the northern and southern tracks).
seanmcleod said,
March 31, 2014 at 3:34 am
Alex Siew, so even only working on the assumption that the 2:29am ping was a full handshake giving them enough data to calculate a distance/arc that’s only 14mins after the last radar contact. That would still allow them to determine whether the arc is to the west or east of the Malaysian peninsula and whether the distance from the last radar contact to this arc given the 14 minute interval is realistic.
Both Malaysian and Thai radar saw an unidentified aircraft heading west.
You mentioned:
“…the plane was stationary (at somewhere north east of the satellite) at all 6 completed handshake times…”
In that case the aircraft would have to have flown from the time the transponder was switched off to the last arc of 8:11am before the 1st of the last 6 pings.
Which is roughly 1hr I think, so what is the distance from the last transponder position to the 8:11am arc, could it be covered in 1hr?
duncansteel said,
March 31, 2014 at 4:49 am
Could someone confirm the take-off time of MH370 from KL?
I was asked to calculate the LOS speed from the satellite when the aircraft was on the ground at KL. This I did: about 0.021 km/sec at either 16:30 or 16:41.
Now the first time (16:30) has a measured BFO of about 87 Hz on the Inmarsat graph. However, at the second time (16:41) the BFO is 125 Hz.
In trying to calibrate that graph (i.e. move from a BFO to a Doppler shift) which one would you use for ‘zero speed’. Obviously the aircraft speed was small (compared to flight) while on the ground. But at the time of of 16:41 ping was it: (a) Stationary; (b) Moving slowly; or (c) Accelerating down the runway?
Thus affects whether there is *any* time across the Inmarsat graph at which the aircraft is moving towards the satellite.
If BFO=125 Hz (not 87 Hz) then I think that at 19:40 UTC the aircraft was moving (slowly) towards the satellite, and perhaps more quickly during the preceding hour (when there were no pings).
Any answers?
Thanks,
Duncan
airlandseaman said,
March 31, 2014 at 5:48 am
First, let me say a bit about qualifications. I have been a pilot and satellite commutations engineer for >40 years. I have considerable direct experience with mobile satellite systems in general, and the Inmarsat system in particular. I have designed aircraft transponders, experimental Inmarsat terminals, GPS receivers, earth stations, spacecraft payloads, been closely involved with the launch of both LEO and GEO satellites, flown payloads on Shuttle deployed spacecraft, etc. I say this not to toot my horn, but in the hope I can help separate a few more facts from some of the unnecessary speculation.
MH370 facts have been few and far between. It is a shame the Malaysian Government and Inmarsat have, so far, refused to release the RAW data needed for a “Crowd Solution”. But I heard this morning that the pressure to release the required data has reached the point that it might happen soon. So get your STK models, Kalman filters, LSFs and other math models ready.
So what data needed, and why this and not other data? We need for all 12 (or 13?) epochs (if it exists):
1. Free space propagation time delay from the AES L band antenna to the I3-F1 L band antenna.
2. Inbound up-link L band Doppler and carrier frequency (~1634 MHz), or better yet, the range-rate derived therefrom by Inmarsat.
3. Times for the above epochs.
By requesting the data in this form, we avoid all the speculation about how the system works and we can focus on what matters: the aircraft motion. I trust Inmarsat to know their system and derive *these* values. I don’t necessarily trust them to pick the best possible way to process these values to produce a path. Personally, I would use a single global Kalman filter (“a grand solution”) set up to pick the most likely solution. I am pretty sure STK can be used this way, but if not, there are plenty of orbit determination and navigation satellite position codes available to do it.
A note on the system: Much of the discussion here is based on unnecessary speculation and misunderstanding. For example:
1. It is well known among engineers familiar with the Inmarsat system that the AES does offset the up-link transmit frequency dynamically to center the carrier in the assigned channel as received at the LES (not the satellite). It is specified in detail in the standards. Those 12 values are known by Inmarsat, but not us.
2. It is also well known that the specific frequency (channel) and beam is assigned dynamically by the network control center on the ground.
3. Calculating range-rate or the associated Doppler is more complicated that most realize. The AES –> Satellite Doppler cannot be observed directly. There are 4 frequencies involved in the measurement, not one. Moreover, the satellite does not measure anything. The satellite has two bent pipe transponders, one outbound (6.4 GHz up/1.53 GHz down) and one inbound (1.63 GHz up/3.6 GHz down). It acts like a mirror in each direction, with a fixed (phase locked) frequency change . There are Doppler effects on all four links. The only observable is the in-bound down-link (3.6 GHz) Doppler and total double-hop delay. To figure out the net-net AES –> Satellite Doppler, one must first remove the effect of the up and down feeder link Doppler (using knowledge of the s/c ephemeris and LES position), and then take into account the dynamically adjusted AES delay. Bottom line, Inmarsat is in a much better position to do this part of the math since they know all the exact frequencies and offsets.
4. Regarding the BFO values, it is apparent from the analysis I have done and passed on to Duncan privately, that these values contain more terms than the sum of the single path satellite and aircraft L band Doppler plus a constant bias. Others have reached the same conclusion. Without a better definition of what the BFO values really mean, we are back in the realm of speculation trying to use this data for Doppler. That said, the 02:25, 02:27 and 02:29 transmissions are almost certainly indicative of on-board event driven transmissions, not Pings or ACARS triggered transmissions, and the rapid change is definitely indicative of a turn from generally east bound to either north or south.
Alex Siew said,
March 31, 2014 at 5:48 am
Duncan,
MH370′s reported take off time was 00.41am. The ping u were referring to was timed around 00.43am?
Ole said,
March 31, 2014 at 5:48 am
Duncan,
there is a transcript of the communication from MH370:
http://www.telegraph.co.uk/news/worldnews/asia/malaysia/10714907/Revealed-the-final-54-minutes-of-communication-from-MH370.html
It’s authenticity is disputed. From that transcript i read the clearance for take-off was issued at 0:40:38, in the following moments the pilot would have opened the throttles for the take off run.
Flight path data that has been recorded while it’s ads-b was active can be
found here:
https://flightaware.com/live/flight/MAS370/history/20140307/1635Z/WMKK/ZBAA/tracklog
airlandseaman said,
March 31, 2014 at 6:03 am
In the previous post, please note this correction:
“…and then take into account the dynamically adjusted AES delay…”
…should read
“…and then take into account the dynamically adjusted AES frequency offset…”.
andyhull said,
March 31, 2014 at 6:43 am
On the subject of debris, various sources have assumed the wind will move debris from an assumed crash in a set and predictable manner. i.e. if the wind is at x meters pre sec for y hours, the debris will travel x*y*360 meters in that time frame.
This may be true for a perfect sail boat, but is simply not the case for waterlogged items.
A better model of how the debris field is likely to move can be found by looking at analysis of larger debris fields.
http://marinedebris.noaa.gov/tsunamidebris/debris_model.html
A lot depends on how much of the item is out of the water acting as a sail. It would be an interesting idea to try to locate the same objects on different images for different days, even allowing for the fact that the vast majority of objects are likely to be unrelated to the flight.
This might yield a useful set of data for predicting currents and object movement in the area.
Historic satellite data for the area already exists. It might be worth thinking of the number crunching in terms of “machine vision problem” (i.e. computationally analysing these images) might be worth exploring.
Perhaps this would be a good use for all that spare storage and number crunching capacity the NSA now have in their server farms, now that they are supposedly no longer spying on the world.
GuardedDon said,
March 31, 2014 at 7:12 am
Re: airlandseaman, March 31, 2014 at 5:48 am
Agree with everything you’ve stated above, I was about to draft something similar to pull the context of discussion back. Apart from the Inmarsat derived information, MoTM haven’t released anything of consequence. Chris McLaughlin’s comment that the aircraft was moving further away from the satellite with each successive ‘ping’ can be taken into account. Pedantically, I’d first consider the four hourly spaced comms events (19:40-22:40UTC) to be the log-in verifcation handshakes initiated by the Inmarsat ground station that have become termed the ‘pings’.
That voice transcript is consistent with earlier comments that the comms events at 16:30 & 16:40 UTC are the push back and wheels off the ground transmissions from the aircraft back to operations.
Some clarity about the radar reports from RMAF’s RAT-31DL station on Penang Island ( http://bit.ly/1fGlU0t ) and whatever the Thai Air Force detected would be helpful to understand the extent of the “diversion” before heading south.
duncansteel said,
March 31, 2014 at 7:51 am
Ole wrote:
“Flight path data that has been recorded while it’s ads-b was active can be
found here:
https://flightaware.com/live/flight/MAS370/history/20140307/1635Z/WMKK/ZBAA/tracklog ”
Oh wow, I had not seen this previously. Working in my STK scenario to try to get a route which fits against the ‘pseudo-Doppler’ BFO in the Inmarsat graph, I put in a slight route change from near NE to NNE at around 17:00 UTC in order to explain the dip in the BFO from the 16:55 datum to that at 17:07.
And… the flight path data shows just this occurring, at 18:05 UTC.
I do now have a solution which qualitatively fits the BFO measurements (if I understand them correctly: in essence, Doppler shifts where zero LOS speed reads as a BFO of 125 Hz).
Cheers,
Duncan
duncansteel said,
March 31, 2014 at 7:52 am
Sorry, I meant:
And… the flight path data shows just this occurring, at 17:05 UTC.
airlandseaman said,
March 31, 2014 at 8:05 am
Thanks GuardedDon.
It would also be very helpful if the conflicting statements about RR engine data could be clarified. In particular, were the 3 transmissions at 02:25, 02:27 and 02:29 engine initiated “alert transmissions” sent directly via Inmarsat, not through the ACARS system? Did they contain ambient pressure (altitude) information that could confirm the conflicting radar altitude reports? Similarly, the final 08:11 and 08:19 transmissions do not fit the pattern of LES Pings or ACARS transmissions. Were they also engine initiated transmissions with pressure data? Were the 08:11 and 08:19 transmissions part of a series of 5 ore more 2 minute engine anomaly messages, fitting the same 2 minute pattern around 02:25, except that 08:13, 08:15, and 08:17 were unsuccessful due to the state of the aircraft at that time? Could the 08:11 message have been the “out of fuel message” and the 08:19 1/2 message been the attempt to report impact forces? If they were at 12,000 feet as now assumed, a final glide from 12,000 feet and 400 kts would take about 8 minutes.
airlandseaman said,
March 31, 2014 at 8:19 am
Duncan:
The aircraft was definitely on the ramp at 00:30 when the BFO was 87 Hz. Do you now believe it was taxiing then?
Skwosh said,
March 31, 2014 at 8:38 am
@airlandseaman
Sorry – this is going to annoy you.
I just can’t help, in my ignorance, trying to apply basic physical principles and reason.
You say:
“It is well known among engineers familiar with the Inmarsat system that the AES does offset the up-link transmit frequency dynamically to center the carrier in the assigned channel as received at the LES (not the satellite). It is specified in detail in the standards. Those 12 values are known by Inmarsat, but not us.”
You use a lot of TLAs. I guess that’s down to your qualifications.
I’m assuming ‘LES’ is the ground station and ‘AES’ is the aircraft.
So – my question is – which 12 values “are known by Inmarsat” – is that the 12 frequencies recorded at the ground station, or is that the 12 frequencies actually transmitted by the aircraft?
1. Inmarsat surely *must* know the frequency of the signal they received on the ground.
2. They can then use this to deduce the frequency of the signal that arrived at the satellite.
3. Then, *if* Inmarsat knew the exact position and velocity of the aircraft at the time they could use that to deduce the frequency at which the aircraft was transmitting. However, *if* Inmarsat knew the exact position and velocity of the aircraft at the time then there would be no mysteries here!
4. So – maybe, Inmarsat have some other independent way of knowing the frequency the aircraft was transmitting on at that instant? If they know those transmit frequencies for certain then they can deduce the aircraft-to-satellite Doppler for certain, and thus they would have the relative velocity of the aircraft and satellite along their line of sight. However, if that was the case, then why wouldn’t they just release a simple plot of that? You yourself have just verified that the burst frequency offset (BFO) graph can *not* simply a plot that is proportional to the aircraft-to-satellite relative velocity.
5. I put it to you that Inmarsat do not know what frequency the aircraft was transmitting on. I suspect that, instead, they have some sort of (probably very good) model for determining the transmit frequency of the aircraft that *depends* on the aircraft’s (unknown) position and velocity and possibly other internal state (of the aircraft) variables, some of which may be better or less well known.
If I am right then the true instantaneous velocity along the line of sight between the satellite and the aircraft is *not* know, even by Inmarsat, it is instead a quantity that can be derived (probably very accurately) by them *if* they are given an instantaneous position and velocity for the aircraft.
I repeat – if Inmarsat knew the true instantaneous velocity along the line of sight between the satellite and the aircraft (*independant* of the aircraft’s unknown track) then surely that is what they would have published already?
So – actually – I think from the point of view of public verification or ‘Crowd Solutions’ it would be necessary for Inmarsat to release the algorithm/model they’re using to convert a putative aircraft position and velocity into an aircraft transmit frequency – because if they don’t then no one can verify their own tracks against the BFO data without also knowing the algorithm.
So – I’m thinking your shopping list of data from Inmarsat is probably a bit deficient.
GuardedDon said,
March 31, 2014 at 8:38 am
@ airlandseaman & duncan
All that info would be interesting for sure. After the flight was overdue or I’d have expected Malaysia Arilines’ ops to attempt to contact the aircraft, including using ACARS msgs, any such msg would’ve ‘cancelled’ a further log-in verification handshake over the datalink from Inmarsat expected at 23:40UTC. MoTM may not be disclosing any ground/overdue initiated comms events as it may open them up for further difficult questions from China.
Regarding your descent consideration: AF447 hit the water at about 10,000fpm – a ~3 minute descent from cruise at ~30000ft. On fuel, there’d likely be an imbalance in consumption between the engines & one flame out first – the BA B777 that landed short at LHR had a small imbalance (source: accident reports). Two fold implication of single engine ops: dropping down to a single generator leaves most non-critical systems unpowered (procedures expect APU air start) including satcom & the aircraft slows. I’m discounting that warnings would be attended to. None of the reasons that it’s in the southern Indian Ocean square with someone reacting to ECAM warnings.
Further speed: I think 300knots would be the minimum expected. B777 docs say 275knots + a margin.
ADS-B recordings at flightaware, etc. In this region, these are relayed to the websites by enthusiasts, hence, the coverage is patchy. Singapore & Vietnam cover MH370′s route quite well but there’s an ADS-B blind spot out over the Gulf of Thailand as Malaysia hasn’t implemented their ground stations yet (sources: icao publs)
GuardedDon said,
March 31, 2014 at 8:47 am
@ Skowsh
TLA torment: we haven’t been that consistent with them I guess.
GES = Ground Earth Station – e.g. the Inmarsat facility at Perth. It transmit/receives to the satellite
LES = Land Earth Stations – a user terminal, often aircraft are referred to as one of these.
AES = Aircraft Earth Station – the aircraft user terminal.
AndRand said,
March 31, 2014 at 9:04 am
hal said,
March 30, 2014 at 5:18 pm
@AndRand – Thanks for the clarification. The northern route was ruled out by inmarsat technicians using the graphs we’ve been discussing. If you feel that you have proved even ONE northern route is plausible, then it is important to communicate very clearly what your results are and how you got them.
There are 2 things that make it not clear:
1. absolute doppler shifts – that make symmetrical northern and southern route possible. As hamster3null wrote here: when you walk south and hear sound with 10kHz shift, you can’t tell if it is going south or north. If you know it is -10kHz you can tell that there is southern radial component (vector sum of radial component and satellite’s speed vector) but you still can’t say if this is on your southern or northern side.
2. lack of measured distances – for now they are guestimated from rings and routes presented on diagrams. Distances would allow to rule out decisevely where the plane is – ie. it can’t both have radial component towards satellite and increase distance.
In my version of hamster3null’s spreadsheet I did prepare 2 pairs of tracks:
- one southern, matching doppler shifts (there is some confusion on that, with not known instrument response compensating doppler effect) and mirroring northern route to that (matching as closely as possible distances and doppler effect)
- one northern route (as with SIA68 theory which doesnt really match presented doppler effects) and mirroring southern route to that, matching distances and measured doppler effects as close as possible..
Fitzcarraldo said,
March 31, 2014 at 9:17 am
@ duncansteel
The contacts listed by XocoLatte a few days ago in these blog comments (his post on 25 March at 2:11 pm) were:
MYT Type
00:30 ACARS Message
00:43 ACARS Message
00:55 ACARS Message
01:07 ACARS Message
etc.
Those might be published approximate times (I have not seen the source), but, as the STD for MH370 on 8 March was 00:35 MYT, 00:30 MYT would likely have been ACARS OUTRP (Out Time: parking brakes off just prior to push-back) and 00:43 would be ACARS OFFRP (Off Time). The latter is triggered by sensors on the landing gear beams detecting the landing gear is in the airborne state. So the times given in the detailed (albeit unofficial) UK Daily Telegraph transcript of voice comms between the cockpit, tower and ATC is probably the better source for you to use (link in Ole’s comment on 31 March at 5:48 am). From that transcript, 00:42 MYT looks like a reasonable take-off time to use for the purpose of your calculations.
(By the way, IATA Standard Schedules Information Manual defines departure in terms of off-blocks time, not take-off time, and arrival as on-blocks time, not touch-down time.)
AndRand said,
March 31, 2014 at 9:18 am
airlandseaman said,
March 31, 2014 at 5:48 am
1. It is well known among engineers familiar with the Inmarsat system that the AES does offset the up-link transmit frequency dynamically to center the carrier in the assigned channel as received at the LES (not the satellite). It is specified in detail in the standards. Those 12 values are known by Inmarsat, but not us.
Well, that is the biggest source of confusion – that we do not know HOW it is dynamically compensated, even with shifts stripped of other sources of doppler effects (GES, LES).
AndRand said,
March 31, 2014 at 9:26 am
AndRand said,
March 31, 2014 at 9:04 am
“If you know it is -10kHz you can tell that there is southern radial component…”
southern net radial component
airlandseaman said,
March 31, 2014 at 9:30 am
Skwosh:
I was referring to the 12 transmissions for which BFOs were plotted on page 2 of Annex I, and the dynamically calculated AES transmit frequency offsets used for each. True Transmit Frequency = nominal frequency assigned + AES derived and applied offset. This offset value is sent as part of a header message to the Perth LES (AKA GES). So Inmarsat has the information required to compute the Transmit Frequency.
Regardless of the fine details, I know Inmarsat has a system and the know how to generate the required data. I think it would increase the probability of receiving data if the “Crowd” got behind a specific, definitive request. It only dilutes the force of the message if we are all over the map asking for proprietary details on the way everything works. This is why I am pushing for full disclosure of the AES –> S/C propagation delays and Dopplers (net of all system specific bias and adjustment).
I now have several of the CNN “expert guests” working their inside channels to get this specific data. Several people have been re-tweeting my #370Qs requests for the same. The more they hear the same message, the more likely we will get something.
Skwosh said,
March 31, 2014 at 10:01 am
@airlandseman
I think it would help the crowd to get behind the message if relevant information for answering the crowd’s legitimate and entirely sincere enquiries were revealed *early* by those taking part in this discussion (as you have now just done) – rather than such individuals just telling us all that it is *very* complicated and we shouldn’t bother trying to understand it.
Why in the name of everything that’s reasonable did you not mention this earlier!!!
“The aircraft compensates dynamically – it sends the magnitude of the compensation it is applying in the header of every transmission it makes to the satellite”
That is not difficult to understand.
That is not a difficult sentence for you to write.
We don’t need to be RF experts with years of experience to get our heads around the implications of that.
It is surely *highly* relevant to all the discussions we’ve been having, and yet you only think of mentioning it now?
airlandseaman said,
March 31, 2014 at 10:15 am
AndRand:
Regarding the AES transmit offset…I believe the precise method is left to the manufacturer. The standard only specifies the performance requirement. In modern designs, I am sure a GPS time/frequency standard is used to measure (estimate) the L band down-link Doppler and then compute the required offset for the return carrier frequency in order to hit the LES demodulater very close to the assigned channel center frequency. This offset is required because the spectrum assigned to AMSS(R) and AMSS is very little and the demand is very high. So every possible means is used to minimize the allocation of time and spectrum for “overhead”.
airlandseaman said,
March 31, 2014 at 10:18 am
Skwosh
I have explained this several times here and on other sites. Sorry you missed it.
ideaswork said,
March 31, 2014 at 10:24 am
Duncan et al,
Thanks for the great simulation. I think your simulation just showed that the Inmarsat south Indian Ocean theory is a bust. Here is how I reasoned it:
1. During 16:55 – 17:07 – 18:25 UTC time, if the sub-satellite positions are always south (~1.2 to 1.5 lat) and west (~64.5 long) of the airplane (somewhere about 4 to 6 lat, and 97 to 102 long), then the LOS velocity (delta v) has to cross 0 at some point of time for the plane to end up in south Indian Ocean. Duncan’s simulation showed exactly this.
2. Therefore, for the simulated LOS velocity being negative and Burst Frequency Offset staying positive to be away from the satellite (and above the takeoff offset), there must be a vertical velocity away from the satellite during the time that the simulated LOS velocity going negative?
3. Based on the simulation for various speeds, the shortest time period for negative LOS velocity is 59 minutes at 200knots. That’s a long time for the plane to be descending and not falling into the ocean. Additionally, the (instantaneous) vertical descent must be greater than 0.16 km/sec (or 31496 fpm!) at the peak negative LOS.
4. Since that required (instantaneous) vertical descent speed under this condition is impossible, there has to be a hole in this south Indian ocean hypothesis?
What am I missing?
So, what if the 18:22 radar (graph top of this thread http://tmfassociates.com/blog/wp-content/uploads/2014/03/Beijing-event.jpg) is not MH370? That puts the last known position of the plane back at 6.93, 103.59 heading 25 to 40 degrees at 472knots at 17:21 UTC.
AndRand said,
March 31, 2014 at 10:53 am
It looks like 15 posts just disappeared from here… :/
AndRand said,
March 31, 2014 at 11:01 am
sry for post above – some browser refresh issue
airlandseaman said,
March 31, 2014 at 10:15 am
AndRand:
I am sure a GPS time/frequency standard is used to measure (estimate) the L band down-link Doppler and then compute the required offset for the return carrier frequency in order to hit the LES demodulater very close to the assigned channel center frequency. This offset is required because the spectrum assigned to AMSS(R) and AMSS is very little and the demand is very high. So every possible means is used to minimize the allocation of time and spectrum for “overhead???.
So as I suspected, it is just reversing incoming offset (based on known sat transmitter frequency) because with up to 1.5kHz doppler shift it would exceed channel bandwidth (~35Hz).
Now the hope is: shown response is within some frequency change acceleration (ie. 20Hz/sec or min)… so it could be outside compensation range.
AndRand said,
March 31, 2014 at 11:12 am
ideaswork said,
March 31, 2014 at 10:24 am
Doppler shifts are presented as absolute figures, as I reckon.
Skwosh said,
March 31, 2014 at 11:27 am
@airlandseaman
Forgive me!
I’ve been re-reading your posts and I see it now! From your post on March 29, 2014 at 5:07 pm:
“Perhaps what is missing from your understanding is that the aircraft radio measures the outbound Doppler and offsets the inbound transmit frequency to compensate, but the offset value is communicated to the ground station as part of the channel set up handshake.”
I’m more of a digital guy – so I only fully twigged when you said ‘header’ just now!
Sorry for the misunderstanding.
Wow – so this is all very interesting.
They *do* know the instantaneous relative velocity along the line of sight (*whatever* the position was) at each ping. That is very interesting.
Having re-read all your posts I can now see that you were initially assuming that this was what they were showing us in the BFO graph… why wouldn’t you indeed.
I can also now understand why you were becoming increasingly edgy about your interpretation of the BFO graph!
I do like to understand what’s going on – and when I get the wrong end of the stick or miss something I can end up driving people round the bend until I do. Sorry again!
I do at least like to think I’m good a coping with being wrong though!
I’m like my dad, he was an aero engineer, and he did actually also spend some time doing accident investigations (though I’m not in that business at all myself). He was a man who always insisted on trying to understand what data actually was, where it actually came from and how it was derived – separating the ground truth from the deductions. To now know that at least someone somewhere has some ground truth (a digitally encoded report from the aircraft about the frequency offset it has applied) is, for me at least, hugely helpful in gaining a better understanding of what is going on here, the meaning and soundness of any data that might subsequently be released and what is knowable and not knowable.
I’m inclined to get very combative if someone tells me that details are irrelevant. I accept that the details may be un-knowable for various legitimate reasons, and/or that it may not be possible or sensible to ask for such details in some cases (and I absolutely take your point about that in this case).
Thanks you for putting up with me!
Skwosh said,
March 31, 2014 at 11:33 am
@ AndRand
Yes – yes – I understand now. You were right. According to @airlandseman that is what it does – the aircraft just uses the doppler from the incoming to set its shift for the outgoing. What I couldn’t understand was how, if that was the case, they could use the incoming frequency to deduce *anything* at all because the frequency correction would be virtually perfect! What I was missing was that the aircraft transmits the offset it has applied digitally in its response!
duncansteel said,
March 31, 2014 at 11:33 am
Thanks to all for various inputs.
I have just put up a post which has a revised set of LOS speeds (i.e. Doppler shifts) and which mesh against the BFO information, although I have to tune the paths taken by my simulant flights to achieve that. But the point is: it can be done.
Here is the URL: http://www.duncansteel.com/archives/485
A question above from ‘ideaswork’ concerned the vertical speed of the aircraft. The answer is that this has negligible effect on the LOS speed satellite-aircraft for any realistic geometry. Unless, of course, the aircraft were flying nose down at 400 knots… See the final plot in the above post.
The geometry (with the satellite at an altitude equivalent to between 5 and 6 Earth radii) is difficult for many to imagine. I have the advantage of familiarity, and also working in a 3D STK window within which I can scoot around. In all seriousness, it can be helpful to sit down with a globe and a piece of string with one end held up where the satellite is, and then move the other end of the string around possible locations for the aircraft. The angles are then obvious and you will see why the aircraft altitude is not really relevant in terms of the LOS speeds and various other matters; it (the altitude) only matters in the overall scheme of things in terms of plausible speeds for a B777 and fuel consumption rates, which are not my bailiwick.
Cheers,
Duncan Steel
duncansteel said,
March 31, 2014 at 11:35 am
I guess (actually, I know) that the altitude is also relevant in terms of radar detectability and maximum range from some radar installation. But the point remains valid.
meadows.st said,
March 31, 2014 at 11:37 am
All,
I have found this blog to be particularly helpful and it has attracted some talented, insightful, well informed, dedicated and knowledgeable contributors from varied backgrounds that I believe could have a beneficial effect on the search for MH370 and as a side benefit, would serve as a wonderful resource to any mainstream media types that want to find useful questions to ask their sources. I have transitioned from a frequent contributor to a lurker as obvious experts have joined the conversation and I sought to avoid adding to the noise. I encourage other readers to take a similar approach in order to keep the signal to noise(speculation) ratio very high – General rules of thumb: a) state your qualifications; b) state your assumptions; c) read the entire thread to avoid duplication; d) STAY FOCUSED; and e) quote anyone to whom you are responding.
For new readers that don’t have the time to review the three related TMF Associates web logs (and DuncanSteel’s comment threads) IMHO, the best contributors (and their areas of pertinent expertise – my apologies in advance for anything and anyone I miss) are as follows:
a) @Timfarrar (sat comms expert, summaries, analysis, and this blog);
b) @DuncanSteel (satellite motions, positions, simulations and visualizations via STK, analysis);
c) @Airlandseaman (pilot and satellite comms systems technical expert, analysis, resource for winds and flight information); d) @GuardedDon (communications expertise, analysis, specification documentation resource for Inmarsat comms, flight info resource);
d) @Fitzcarraldo (visualization, analysis); and
e) @KeithLedgerwood (pilot, original theories for flight paths and resource for flight information).
All five of the above listed contributors appear to read and dissect the essential elements of this investigation while avoiding idle speculation and wild theories (at least ones that are not founded on any data). I am sure there are a large number of other readers and potential contributors that can provide great input to this investigation and of course, raw data from Inmarsat, civilian and military radar contacts must be provided in order to leverage what has the potential to be a very effective crowd-sourced solution (or set of potential solutions) to assist the search for MH370.
Best regards.
ideaswork said,
March 31, 2014 at 11:40 am
AndRand said,
March 31, 2014 at 11:12 am
Doppler shifts are presented as absolute figures, as I reckon.
Do you mean absolute value or do you mean inverted sign? If the BFO is presented as absolute value, then how did Inmarsat deduce the plane is moving away (verses moving closer)?
AndRand said,
March 31, 2014 at 11:55 am
This is what they shown. I don’t know what they have.
GuardedDon said,
March 31, 2014 at 12:18 pm
@meadows,st
Steve, I appreciate the call out (as contributor ‘d:’), it continues to be a massively engaging interchange.
Don
GuardedDon said,
March 31, 2014 at 12:42 pm
@duncansteel
Did you get all you needed relating to the aircraft departure? I had commented a few days ago on the comms events shown on the MoTM issued BRO chart & the significance of the msg timings However, I hadn’t picked up on the ATC departure transcript & so wasn’t sure about the departure runway. So,
1. 00:30 ACARS Message Passenger doors closed, ie push back
No movement worth noting
2. 00:43 ACARS Message Ldg gear doors closed, ie departed
Climb established, speed (accelerating through) about 190kts on hdg 326deg.
3. 00:55 Msg ??, position as flightaware/flightradar24 ADS-B reports, 458kts and hdg 25deg.
airlandseaman said,
March 31, 2014 at 12:52 pm
regarding the sign of the BFO data…my interpretation is that increasing positive numbers correspond to an increasing radial velocity AWAY from the Satellite. I came to that view based on the observation that the value was increasing right after takeoff when the course is known to be ~25 degrees based on the MH370 ADS-B data. The latitude was about 5 degrees, so the direction of flight was away, not towards the satellite. At the time of the bias calibration on the ramp, the BFO was 87 HZ.
At first I interpreted Annex I page 1 to mean that BFO = S/C Doppler + A/C Doppler + System bias. I assumed the bias was a constant caused by differences in the frequency standards in the LES, satellite transponder local oscillators and the AES standard. Indeed, it would be very surprising to NOT have some bias in this type of measurement, but the bias is easily calibrated when the aircraft is on the ramp at speed = 0. Thus, I thought it was 87 Hz. Of course, it requires the assumption that the bias is nominally constant and low drift. I also assumed that the BFO was in reference to one of the two L band links, and the C band Feeder link Doppler had already been removed. Recall, the satellite does not measure anything. The only observable is the LES receive frequency, which is ~3.6 GHz, not 1.6 GHz. But this interpretation does not seem to fit the assumed path or Duncan’s first simulation, so now I’m not sure what the BFO values are. They are definitely related to the L band Doppler, but what does this mean: “Not corrected by system= measured frequency offset”. That is part of the BFO definition on page 1. Hopefully this will get straightened out soon.
David Soucie ??? @David_Soucie On CNN just now. He wasjust talking about the need for Inmarsat to release the L band data to the Crowd Solution experts. He is reading this blog. He and Jeff Wise are both pushing for the specific data we need. I know of others in DC doing the same. Hope it happens soon.
duncansteel said,
March 31, 2014 at 12:57 pm
GuardedDon asked:
“Did you get all you needed relating to the aircraft departure?”
Yes, thanks, I think. What I am really wanting from that perspective is: where is the zero in the BFO graph from Inmarsat? That is, is it BFO=87 Hz, or BFO=125 Hz? The point is that I’d like to find a path that fits against the known BFO values, but I’m unsure where they turn from negative to positive.
ideaswork said,
March 31, 2014 at 1:18 pm
In my opinion, this thread is by far the most meaningful discussions and probably has the best chance to narrow down the plane crash site. I am just going to say that my training is a physicist but been working in testing/validation for the last 20 years. I am a total novice to the detail of the satellite and aeronautics. I have read more aircraft and sitcom manuals online in the last two weeks than I ever dreamed. My view will be biased to “testing” the hypothesis.
1. I agree that re-tweet to get the original (“raw”) data is critical for this effort.
2. I agree that altitude doesn’t matter and vertical speed cannot possibly make a notable difference. However I remain that the assumptions of the 40 angle (from the NTSB slide) and last known location do matter. I will need to spend time to read Duncan’s last publication later.
Skwosh said,
March 31, 2014 at 1:23 pm
@meadows.st
Excellent remarks! Agree completely… and I’ll try to keep as quiet as possible from now on!
@airlandseaman
I can only re-iterate (I think shared!) puzzlement about the meaning of the burst frequency offset (BFO) graph.
I have spent so much time staring at that chart, and that D1 D2 D3 diagram.
If the Doppler compensation in the aircraft’s responses is more or less perfect, so that the actual *frequency* transmitted back by the aircraft has essentially no Doppler information in it at all (though the *data* does) then I’m wondering what on earth the frequency scale in the BFO graph is meant to be a ‘measure’ of?
Perhaps it is just an *exact* plot of that raw offset value that the aircraft was reporting it had applied. Then it would truly be sensible to describe it as a “burst frequency offset” – literally: the offset that was being applied by the aircraft when it sent its burst (perhaps corrected for different base frequencies if different frequencies were assigned for the different transmissions?).
It would then presumably correspond to the satellite-aircraft Doppler, and be proportional to their relative velocity along their line of sight (as I think you were initially very reasonably assuming it probably was).
This is certainly how Duncan appears to be interpreting the BFO plot (less an arbitrary offset) in his latest post (he is amazing!) – I’m still digesting his post, but he seems to be able to make this interpretation of the BFO work with his proposed tracks.
But then – as you say – there is that infuriatingly ambiguous “Not corrected by system= measured frequency offset” – and what is more that sentence is ‘stuck’ to the *satellite* in their diagram with a red circle around it!
It’s driving me round the bend!
I am still a bit interested to know if Inmarsat’s proposed 450 knot southern track can be made to fit the BFO graph using the straightforward (Duncan’s) interpretation of the BFO plot – though I absolutely agree that what is *really* required by all of us here in order to not die of brain ache is more raw data!
GuardedDon said,
March 31, 2014 at 1:27 pm
According to UK Daily Telegraph transcript the instruction was hold at A10 for departure on 32R, see http://bit.ly/1lyxQc6 pg 30 & 41.
airlandseaman said,
March 31, 2014 at 1:31 pm
I’ve been rereading and rereading the definition of BFO. If we take what is written literally, then the BFO is the difference between the expected LES C band frequency and the actual received C band frequency. I assume this means that the AES offset is already baked in, but the observation is a C-Band observation, not an L band observation. If that is correct, then we have what is needed to calculate AES—> S/C Doppler. I’ll take a hack at this and get back.
GuardedDon said,
March 31, 2014 at 1:51 pm
@aitlandseaman
Isn’t the timing based on the ‘burst’ of unmodulated L-band carrier from the AES, transmitted on the R channel, in response to the interrogation from the GES via the P-channel? That’s where the +/-300usec accuracy comes in.
That burst in the R-channel response is then multiplexed into the C-band downlink back to the GES where it’s measured (I’m not sure on the telemetry point but I’d expect it to be at the GES not in the space segment).
airlandseaman said,
March 31, 2014 at 2:17 pm
GuardedDon:
It depends on which type of transaction…Ping, ACARS, emergency message, etc. But yes, you have the basic picture. Wish I could post a diagram. That would save many pages!
The 300 usec spec has to do with centering the packet in the TDMA channel. The frequency offset centers the carrier in the FDMA channel. For the Doppler, we don’t care about the timing, only the frequency. The L band signal is not “multiplexed into the C-band downlink…”. Beam forming networks and sophisticated DSP hardware is used now days to up-convert the frequency, but basically it works like a classic bent pipe transponder that uses a classical mixer. The full bandwidth of the transponder is mixed with a stable local oscillator to yield an output that is the same spectrum, but moved up from L band to C band by a fixed difference (~1966 MZ). Thus, an input frequency of 1634 produces an output frequency = 1966+1634 = 3600 NHz. (I don’t know the exact frequencies, but these are good enough for an estimate of the Doppler.)
hal said,
March 31, 2014 at 2:47 pm
@AndRand – of course in principle there are many airplane positions and (satellite-relative) speeds that could generate any given doppler shift. I think we all understand that and do not need to have it explained.
However, our exercise is about applying known constraints to eliminate some of them. For example, why don’t you do the exercise of figuring out how fast a plane would have to be traveling, northward, in order to get the doppler shift WRT a northward-traveling satellite that matches perfectly the doppler shift of an airplaine moving southward at 450 knots WRT a northward-traveling satellite.
GuardedDon said,
March 31, 2014 at 3:34 pm
@airlandseaman & possibly, duncansteel
OK, got the concept of the transponder now, thanks. Net is that nothing is lost.
This getting into thin maths ground for me, but I’m holding the analogy that the burst frequency offset is akin to a vector – its indicating the speed of the target toward/away from I3-F1 (we seem to have all positives so always away, inline with Chris McLaughlin’s comment – the Inmarsat VP Ext Comms).
I don’t like that graph as released, as a line graph it alludes to a relationship between each successive point but there isn’t a relationship, each point in each series is entirely discrete telling us only what the ‘vector’ is at a given time. Does that make sense?
The first four msg events are useful in that:
1) should be stationary or at most taxiing
2) is just after wheels up so on a hdg straight off KUL 32R and speed about 180-220kts (that’s verifiable later)
3) in climb after initial turn NE (we know that from the web ADS-B data)
4) at TOC after another slight hdg change toward IGARI waypt (speed is 450kts and hdg can be estimated)
5,6,7) do these, so close together, indicate a turn? If so, which direction?
8,9,10,11,12) our 4 log-in verifications plus additional msg event. Consensus that they’re describing positions along the route to the south.
Skwosh said,
March 31, 2014 at 3:53 pm
@airlandseaman
OK. I think I’m following you now sir – more or less.
Outgoing journey (I know this is not on their diagram):
1. Ground transmits at frequency C0.
2. Satellite receives at C0 * (1 + v3/c)
Where v3 is line of sight relative velocity between ground station and satellite.
3. Satellite subtracts 1966 MHz and transmits to aircraft.
4. Aircraft receives at ((C0 * (1 + v3/c)) – 1966) * (1 + v2/c)
Where v2 is the line of sight relative velocity between satellite and aircraft.
If there were no Doppler shifts in the system the aircraft would be expecting C0 – 1966.
So let’s say the ‘offset’ the aircraft observes is:
O_incoming = (((C0 * (1 + v3/c)) – 1966) * (1 + v2/c)) – (C0 – 1966)
If my algebra and assumptions about small quantities are correct then:
O_incoming ~= (C0 * v3/c) + ((C0 + 1966)* v2/c)
So, the aircraft can’t deduce v3 *and* v2 *independently* from this, only their net effect. So when the aircraft transmits it has to make its best shot at adding an offset for a given requested reply base frequency so that this will arrive on the *ground* more or less as close to zero offset as possible – but without knowing v3 and v2 independently it can’t do this exactly.
You (not me!) presumably know how it chooses what offset to use. Presumably this is somehow based on O_incoming (though later I guess that it simply reverses this for the reply offset).
So now we do the return journey (as illustrated on their diagram):
Aircraft is told target on the ground frequency is C1.
5. Aircraft transmits on (C1 – 1966) + O_outgoing where O_outgoing is the offset it has decided to use for compensation.
So I think O_outgoing is basically D1 in the diagram.
6. Satellite receives ((C1 – 1966) + O_outgoing) * (1 + v2/c)
This is the D2 step in the diagram.
7. Satellite subtracts 1966 MHz and transmits to ground.
8. Ground receives C1_observed = (((C1 – 1966) + O_outgoing) * (1 + v2/c) – 1966) * (1 + v3/c)
This is the D3 step in the diagram.
9. The ground was hoping for C1 exactly.
The difference between this and what it actually gets *is* the BFO.
So BFO = C1_observed – C1
If my maths and assumptions about small quantities is right then this gives:
BFO ~= (C1 * (v3/c)) + ((C1 – 1966) * v2/c) + O_outgoing
These are the three parts of the BFO from the diagram:
D3 == (C1 * (v3/c))
D2 == ((C1 – 1966) * v2/c)
D1 == O_outgoing
BFO == D3 + D2 + D1
Now, in the case where the target frequency was the *same* as the transmit frequency – so C0 == C1 (I know this is a dodgy assumption… but my mind is starting to go AWOL)
And, also, assuming O_outgoing = – O_incoming (simple reverse offset compensation at the aircraft) then *magic* happens!
BFO ~= (C1 * (v3/c)) + ((C1 – 1966) * v2/c) – ((C1 * v3/c) + ((C1 + 1966)* v2/c))
= (2 * 1966) * v2/c !!!
Which very excitingly *only* includes the v2 component!
Oh my word!
Now – it is very late here – and my brain is exploding – and I think I’ve probably got some stuff wrong here – but basically this is showing that the BFO more or less *is* actually the aircraft to satellite Doppler (with these assumptions).
I know my assumption that C0 == C1 is dodgy.
Anyhow – must get sleep!
Think I see where you’re coming from anyway – and there’s probably a less algebraic way of getting all this…
Skwosh said,
March 31, 2014 at 3:59 pm
Actually that should be BFO ~= – (2 * 1966) * v2/c
It’s only a sign! Sorry – really is the last post form me for today (well past UK bedtime)!
Skwosh said,
March 31, 2014 at 4:13 pm
Sorry! Correction – on the return journey (stages 7 &
I should have said the satellite *adds* 1966 MHz – not that it subtracts 1966 MHz – but I think my later algebra and simplifications of the result do assume the correct frequency (positive) shift on the route down to ground. I’ll check it all more carefully when I’m less tired – assuming I haven’t been completely superseded and/or shown to be once again barking up the wrong tree and/or barking mad.
airlandseaman said,
March 31, 2014 at 4:18 pm
I have the BFO to L band Doppler spreadsheet finished. Just waiting for Duncan to supply range-rate data for LEAS-S/C.
Alex Siew said,
March 31, 2014 at 4:23 pm
Further to @meadows’s suggestion, i hereby state my qualifications: None, i am a layman.
From a layman’s interpretation of the Doppler chart, i had suggested that the chart shows that the plane was stationary at all 6 completed pings (2.29 to 8.11), in other words the Doppler effect for those 6 points in time was caused solely by the movement and speed of the satellite relative to the stationary plane.
For those mathematically inclined and with knowledge of the speed, angle and velocity of the satellite for that period of time , it should be relatively straightforward to prove or disprove this theory. The plane was stationary at KL at 00.30am with a given offset of 87 Hz, the relative offset for the other 6 completed pings can be worked out from this.
Unfortunately i am neither mathematically inclined nor do i know the various speeds, angles and velocities of the satellite for those points in time, so I am hoping Duncan or others with similar abilities, can crunch the numbers to test the theory.
Duncan, hoping u can take a look, when u have a few spare moments.
Skwosh said,
March 31, 2014 at 4:26 pm
No – I am completely wrong – I think it all actually cancels out to *zero*. Please disregard my previous post with all the maths (anyone moderating feel free to delete)! I need to not be completely brain-dead to do this. I should not have undertaken this so late this evening – but I was so enthusiastic at having seen a potential way forward. I think @landandseaman will likely sort all this out properly before I wake up! This really is my last post. I am switching my computer off right now.
airlandseaman said,
March 31, 2014 at 6:57 pm
Ok. I have a graph of L band Doppler. It looks very credible. 3 Hz on the ramp at 00:30. I’ll send the spreadsheet to Duncan and he can post the graph.
airlandseaman said,
March 31, 2014 at 7:01 pm
The following table contains what I believe to be the L band Doppler at 1634 MHz. All C band Doppler and AES Offsets removed from the so call BFO values. This makes sense to me.
Time L band Doppler (Hz)
0:30 3.782
0:43 45.877
0:55 85.548
1:07 60.076
2:25 236.651
2:27 139.588
2:29 111.524
3:40 109.748
4:40 170.484
5:40 223.890
6:40 282.201
8:11 351.474
hal said,
March 31, 2014 at 7:20 pm
@airlandseaman – For those of us who are slow, can you explain the significance of the numbers you just posted? I note that they are essentially what INMARSAT published, minus the 87 hz offset we already know is there. What is has your analysis shown us?
airlandseaman said,
March 31, 2014 at 7:32 pm
It is not the BFO -87 Hz. It is the L band Doppler, which can be converted to radial velocity (speed going away from the satellite) at each time. Radial velocity, AKA Range-Rate, is just the Doppler divided by the wavelenth (~0.01825 m). It was derived by removing the C-Band Doppler from the BFO values. I sent the spread sheet to Duncan. Perhaps he has a way to post it.
ideaswork said,
March 31, 2014 at 7:48 pm
Airlandseaman, do I understand correctly – these numbers are after all C band offset removed, these are the residue L band, or pure D2 in annex 1, Doppler shift numbers? With sign? Thanks
airlandseaman said,
March 31, 2014 at 8:35 pm
ideaswork: Yes.
Here’s a link to the Doppler converted to aircraft radial velocity.
http://t.co/dYjDufnPzF
duncansteel said,
March 31, 2014 at 9:03 pm
GuardedDon asked, with respect to the Inmarsat BFO graph:
“I don’t like that graph as released, as a line graph it alludes to a relationship between each successive point but there isn’t a relationship, each point in each series is entirely discrete telling us only what the ‘vector’ is at a given time. Does that make sense?”
YES: That is my interpretation. Ignore the lines joining the discrete points for the ‘Measured’ BFOs. That’s a silly slip, but understandable, in the Inmarsat BFO graph.
The same applies to the two ‘predicted’ tracks (red and green lines) in that graph; i.e. ignore the lines, just look at the discrete points as samples of an overall track.
However, joining the dots there (the green and red lines) by Inmarsat is inexcusable. Indeed, what they SHOULD have plotted was no dots, just curves. That is, they have hypothesized possible northerly and southerly tracks, and they can sample those tracks every minute or every second even in their software. So plot them! Then one might get a better idea as to what is going on.
For example, looking at the Inmarsat Google Earth graphic the yellow track is for 450 knots and one presumes this is the same track as that producing the green line in the BFO plot (southerly, 450 knots). Well, that yellow track indicates an extended interval during which the aircraft is moving towards the satellite and therefore a negative LOS speed (negative Doppler shift). That’s during the interval from 17:07 to 18:27. So, the green line (and the common, at that stage, red line for the eventually-northern predicted track) should go DOWN for much of that interval before shooting up again on the BFO graph. Instead Inmarsat has shown a line of constant slope going upwards, by joining the dots at 17:07 and 18:27 UTC. Dumb, dumb, dumb.
That’s like seeing a man having a coffee in a cafe in the morning, and again in the evening after work he’s there having a beer, and so you assume he’s been there all day; whereas in fact he’s driven 300 miles around the state making truck deliveries.
In the past, teaching at university, if a student did this sort of thing in a Physics 101 lab write-up I would cover the plot with red ink and give 1 out of 10. And Inmarsat has presented this plot to the Malaysian Government, which has presented it to the world as the basis for scouring the ocean!
I anticipate that MH370 is indeed in that ocean. But I am stunned at the ineptitude of the people in charge of analysing the available data.
Obviously I only have so much time in a day (24 hours like anyone else). Thus I would encourage all readers of this post to copy it to your local media. Inmarsat and the other plonkers involved need to be shamed into releasing the data.
Duncan Steel
airlandseaman said,
March 31, 2014 at 9:10 pm
Apologies. There is one final correction needed to compute aircraft velocity. The L band Doppler values are correct, but they still contain satellite motion induced Doppler on the L band link. To remove this component, we need the saellite to aircraft ranges (time delays). So we can’t get all the way to aircraft radial velocity from the sub satellite point. We are stuck with radial velocity relative to the satellite until we can get ranges. Getting late.
XocoLatte said,
March 31, 2014 at 10:58 pm
@Duncan: Again, well said, I could not agree more and fell for your frustration! I would add that if memory serves me right, Inmarsat was not handling any data directly to the Malays, AAIB had; therefore I doubt that hi-end pros @Inmarsat would inadvertently make such a gaffe — perhaps AAIB guys would have more ‘agenda’ to do so… Malay government people now discredited themselves to such an extreme that I would not take any word from them seriously.
I think the best approach is to still take Inmarsat data (and not plots) seriously and try to analyze each individual time point discretely. Create some equally possible deductions for each discrete data points, and finally try to delineate a common deduction, or rule of thumb for the subsequent data points.
Perhaps this way we cannot fall prey to the same error and assume a trend between discrete snapshots BEFORE the existence of that trend has been proven to exist based on the data.
If this strategy failed, one can still summarize that the only solid deduction is that the plane went to the South or North. Which is no much to begin with.
Ole said,
April 1, 2014 at 1:56 am
airlandseaman,
to my understanding all doppler shift contributed by the C-band link (GESsatellite) itself is summarized in D3 and thus already corrected by the system.
The point that I’m not 100% certain about is: What happens to the doppler shift from the L-Band during the frequency conversion to the C-Band?
To my best understanding the original doppler shift is just moved to the C-Band. The size in Hz of the doppler shift is *not* (imho) altered by the frequency conversion between L- and C-Band. The baseband bandwith is not altered by the frequency conversion, thus deltas within this baseband bandwith cannot be resized either. (Any input on this question would be highly appreciated !)
An *additional* doppler shift on the C-Band happens due to LOS speed satelliteGES, but that is already accounted for by D3.
If the doppler shift from LOS-speed aircraftsatellite was known by inmarsat, **why** then don’t they just plot that value ??? They may know what doppler compensation the AES had applied, but to me it’s obvious they don’t know what the real LOS-speed aircraftsatellite was, because that would be the most meaningful parameter to plot. Actually that parameter is what Duncan is calculating for conceivable tracks with his excellent work.
The red circle in the first slide of Annex I is quite clear: the measured (and thus plotted) frequency offset is the frequency offset that remains, after all corrections by the system (AES,satellite,GES) have been applied. The plotted value essentially is the residual error after all compensation. So without knowing (or assuming) how the correction/compensation works, no conclusion can be drawn from the plot.
BTW: Some methods to measure doppler shift just discriminate the direction. That could be a simple explanation, why the measured BFO never gets negative. See page 5-6(447-448) of the following:
http://www.acfr.usyd.edu.au/pdfs/training/sensorSystems/14%20Doppler%20Measurement.pdf
alex370 said,
April 1, 2014 at 2:53 am
duncansteel,
“You have interpreted the Burst Frequency Offset as being *directly* a Doppler shift in frequency. It is an *offset*”
What is the relationship between those two? What is the definition of BFO?
Thanks
AndRand said,
April 1, 2014 at 3:24 am
duncansteel said,
March 31, 2014 at 9:03 pm
That’s like seeing a man having a coffee in a cafe in the morning, and again in the evening after work he’s there having a beer, and so you assume he’s been there all day; whereas in fact he’s driven 300 miles around the state making truck deliveries.
Well, not exactly…
It is more like: when you see a man drinking first coffee in the morning, third in the noon and second beer in the evening you can say what his average rate is, and it would be accurate at your time points.
On your blog you have the track with finer time-resolution than hourly pings therefore that can be more correct on establishing correct route.
However… as I wrote you – you can have average track thru given points and it would be “average correct” (probably 0 – ~200nm)
hal said,
March 31, 2014 at 2:47 pm
@AndRand – of course in principle there are many airplane positions and (satellite-relative) speeds that could generate any given doppler shift. I think we all understand that and do not need to have it explained.
However, our exercise is about applying known constraints to eliminate some of them. For example, why don’t you do the exercise of figuring out how fast a plane would have to be traveling, northward, in order to get the doppler shift WRT a northward-traveling satellite that matches perfectly the doppler shift of an airplaine moving southward at 450 knots WRT a northward-traveling satellite.
Well, not really… However I assumed distances are more reliable than doppler shifts which, as we see can have a lot of errors from “decompensation”.
AndRand said,
April 1, 2014 at 3:37 am
One refreshing question on D1, D2, D3 – why do we assume transmitters on every station carry on received doppler shifts? In my understanding – the received frequency can be in logs but I dont really see why transmitted frequencies are to be subject of frequency shift?
Skwosh said,
April 1, 2014 at 4:01 am
@Ole
I’m still trying to get my head around what @airlanseaman has done – which I don’t think I have yet quite managed to do – but this is as far as I’ve got in trying to understand it (and explaining it ‘to myself’ as it were).
Unfortunately the link @airlanseaman posted (March 31, 2014 at 8:35 pm) doesn’t seem to be working for me. However, I think it is probably here: https://twitter.com/Airlandseaman/status/450832606204948480/photo/1/large
Terminology: when he uses terms like L-band and C-band these are names used by convention for various regions of radio spectrum (e.g. http://en.wikipedia.org/wiki/L_band and http://en.wikipedia.org/wiki/C_band )
He is assuming the aircraft is transmitting to the satellite at around 1634 MHz (this is a frequency in the L-band).
When the satellite passes the signal from the aircraft down to the ground station the satellite *adds* a fixed frequency of 1966 MHz (this puts the resulting frequency into the C-band). Assume this ‘floats all boats’ equally – so it adds the same fixed amount to all frequencies including any Doppler components.
If there were no Doppler shifts in the system then the frequency observed at the ground station as a result of a transmission from the aircraft at 1634 MHz would simply be:
F_Ground = 1634 + 1966
However, in reality, there are two Doppler shifts in the system.
[1] From aircraft to satellite.
[2] From satellite to ground station.
Let’s call the line of sight relative velocity between the aircraft and the satellite V_AS, and let’s call the line of sight relative velocity between the satellite and the ground station V_SG.
In the following I’m going to assume that these velocities are positive if the things are moving closer to each other along their line of sight, and also that these velocities are in units of the speed of light – so they are very small quantities.
So, when a 1634 MHz signal goes from the aircraft to the satellite it gains a Doppler shift of:
[1] 1634 * V_AS
The signal is then shifted up a constant 1966 MHz by the satellite and this shifted signal then gets transmitted to the ground station and gains an *additional* Doppler shift of:
[2] (1634 + 1966) * V_SG
The Doppler shifts themselves are teeny weeny compared to the bass frequencies (because the velocities of the satellite/aircraft are so small compared to the speed of light) – so although there should also be a ‘Doppler shift of the previous Doppler shift’ in here it is so super teeny weeny it can be safely neglected.
So, taking into account the two Doppler shifts on the route from aircraft to ground, we get the following frequency observed on the ground (from a transmission at 1634 MHz by the aircraft):
F_Ground = (1634 + 1966) + 1634*V_AS + (1634 + 1966)*V_SG
Aside: [What *actually* happens according to @airlandseaman though is that the aircraft will have also added some sort of correction to its 1634 MHz base transmission (of the same order of magnitude as the Doppler shifts) – we don't know what that correction was, but because the message sent from the aircraft includes information telling Inmarsat exactly what the correction was then they can subtract it off to get the above F_Ground figure. I think this is what @airlandseman means when he said (March 31, 2014 at 1:31 pm) "... I assume this means that the AES offset is already baked in"]
OK – so what I think @airlandseaman may be doing is this:
He is interpreting the burst frequency offset (BFO) values provided by Inmarsat as being the sum of the two Doppler shifts:
BFO = 1634*V_AS + (1634 + 1966)*V_SG
Or, put another way:
F_Ground = (1634 + 1966) + BFO
This is what I think he means when he talks about the BFO being a measurement in the C-band.
Now, we are interested in V_AS – the relative velocity along line of sight between the aircraft and the satellite – but the above interpretation of the BFO means it also includes a term involving V_SG (the relative velocity along line of sight between the satellite and the ground station).
However, we know V_SG exactly for a given time of day because we know exactly how the satellite moves, and we know where the ground station is, so we can calculate V_SG, and we can subtract the (1634 + 1966)*V_SG term from the BFO:
BFO – (1634 + 1966)*V_SG = 1634*V_AS
This is a term that is proportional to V_AS – the line of sight velocity between the aircraft and the satellite – and this is what we want to know (and this is also what many have been assuming the BFO was all along).
So, basically, I think the values in @airlandseaman’s table are something like:
BFO – (1634 + 1966)*V_SG
This is why @airlandseaman was waiting (March 31, 2014 at 4:18 pm) for Duncan to supply him with “range-rate data for LEAS-S/C” – in other words – he needed to know the line of sight velocity between the satellite and the ground station at each of the times in the BFO plot.
He describes his corrected values (March 31, 2014 at 7:32 pm) as “… the L band Doppler, which can be converted to radial velocity (speed going away from the satellite) at each time.”
However, this is what I do *not* understand:
Previously, Duncan has estimated that the satellite’s motion along the line of sight to the aircraft at the time of the first point on the graph (when we assume the aircraft was static on the ground) was ~ 21 m/s. I think this would give a Doppler of ~114 Hz on a signal at 1634 MHz. However, @airlandseaman ‘s corrected value at the start of the flight is now roughly zero (just a few Hz). Surely we would expect it to be non-zero (if it is indeed “… the L band Doppler, which can be converted to radial velocity (speed going away from the satellite) at each time.”) because surely satellite was moving with respect to the aircraft at this time?
Also I can’t quite believe that (1634 MHz + 1966 MHz)*V_SG was so close to 87 Hz at the start of the plot.
It would be very helpful if Duncan could share the values for V_SG that he sent to @airlandseaman.
I have most likely got something wrong here again. I am often wrong, as you may have noticed!
I’m sure @airlandseaman can clear all this up.
However, I am still inclined to agree with you (@Ole) that if Inmarsat basically had something from which they could easily get the relative aircraft to satellite velocity (V_AS) then why on earth didn’t they publish that rather than going all round the houses with the D1 D2 D3 stuff?
Fitzcarraldo said,
April 1, 2014 at 4:41 am
The official transcript of comms between aircraft and ATC has now been published on the Web:
http://www.scribd.com/doc/215667016/Audio-Transcript-MH370-Pilot-ATC-BIT#page=1
Just in case you cannot access it, here it is, warts and all (e.g. “MAS377″ in one place, which I assume is a transcription error by whoever transcribed it). I’ve written “..:..:..” when no time was given in the transcript.
MAS 370 (Kuala Lumpur to Beijing)
PILOT-ATC RADIO TELEPHONY TRANSCRIPT
Departure from KLIA: 8 March 2014
ATC DELIVERY
12:25:53 MAS370 “Delivery MAS 370 Good Morning”
12:26:02 ATC “MAS 370 Standby and Malaysia Six is cleared to Frankfurt via AGOSA Alpha Departure six thousand feet squawk two one zero six”
12:26:19 ATC “… MAS 370 request level”
12:26:21 MAS370 “MAS 370 we are ready requesting flight level three five zero to Beijing”
12:26:39 ATC “MAS 370 is cleared to Beijing via PIBOS A Departure Six Thousand Feet squawk two one five seven”
12:26:45 MAS370 “Beijing PIBOS A Six Thousand Squawk two one five seven, MAS 370 Thank You”
12:26:53 ATC “MAS 370 Welcome over to ground”
12:26:55 MAS370 “Good Day”
LUMPUR GROUND
12:27:27 MAS370 “Ground MAS370 Good morning Charlie One Requesting push and start”
12:27:34 ATC “MAS370 Lumpur Ground Morning Push back and start approved Runway 32 Right Exit via Sierra 4.”
12:27:40 MAS370 “Push back and start approved 32 Right Exit via Sierra 4 POB 239 Mike Romeo Oscar”
12:27:45 ATC “Copied”
12:32:13 MAS370 “MAS377 request taxi.”
12:32:26 ATC “MAS37….. (garbled) … standard route. Hold short Bravo”
12:32:30 MAS370 “Ground, MAS370. You are unreadable. Say again.”
12:32:38 ATC “MAS370 taxi to holding point Alfa 11 Runway 32 Right via standard route. Hold short of Bravo.”
12:32:42 MAS370 “Alfa 11 Standard route Hold short Bravo MAS370.”
12:35:53 ATC “MAS 370 Tower”
12:36:19 ATC “(garbled) … Tower … (garbled)”
..:..:.. MAS370 “1188 MAS370 Thank you”
LUMPUR TOWER
12:36:30 MAS370 “Tower MAS370 Morning”
12:36:38 ATC “MAS370 good morning. Lumpur Tower. Holding point.. [garbled]..10 32 Right”
12:36:50 MAS370 “Alfa 10 MAS370″
12:38:43 ATC “370 line up 32 Right Alfa 10.”
..:..:.. MAS370 “Line up 32 Right Alfa 10 MAS370.”
12:40:38 ATC “370 32 Right Cleared for take-off. Good night.”
..:..:.. MAS370 “32 Right Cleared for take-off MAS370. Thank you Bye.”
LUMPUR APPROACH
12:42:05 MAS370 “Departure Malaysian Three Seven Zero”
12:42:10 ATC “Malaysian Three Seven Zero selamat pagi identified. Climb flight level one eight zero cancel SID turn right direct to IGARI”
12:42:48 MAS370 “Okay level one eight zero direct IGARI Malaysian one err Three Seven Zero”
12:42:52 ATC “Malaysian Three Seven Zero contact Lumpur Radar One Three Two Six good night”
..:..:.. MAS370 “Night One Three Two Six Malaysian Three Seven Zero”
LUMPUR RADAR (AREA)
12:46:51 MAS370 “Lumpur Control Malaysian Three Seven Zero”
12:46:51 ATC “Malaysian Three Seven Zero Lumpur radar Good Morning climb flight level two five zero”
12:46:54 MAS370 “Morning level two five zero Malaysian Three Seven Zero”
12:50:06 ATC “Malaysian Three Seven Zero climb flight level three five zero”
12:50:09 MAS370 “Flight level three five zero Malaysian Three Seven Zero”
01:01:14 MAS370 “Malaysian Three Seven Zero maintaining level three five zero”
01:01:19 ATC “Malaysian Three Seven Zero”
01:07:55 MAS370 “Malaysian…Three Seven Zero maintaining level three five zero”
01:08:00 ATC “Malaysian Three Seven Zero”
01:19:24 ATC “Malaysian Three Seven Zero contact Ho Chi Minh 120 decimal 9 Good Night”
01:19:29 MAS370 “Good Night Malaysian Three Seven Zero”
AndRand said,
April 1, 2014 at 5:12 am
Skwosh said,
April 1, 2014 at 4:01 am
When the satellite passes the signal from the aircraft down to the ground station the satellite *adds* a fixed frequency of 1966 MHz (this puts the resulting frequency into the C-band). Assume this ‘floats all boats’ equally – so it adds the same fixed amount to all frequencies including any Doppler components.
I asked about that assumption of transmition frequency because it looks like nightmare for telecommunication engieneer: imagine transponder operating with one/couple of ground stations and several dozens/hundreds of airplanes. While doppler shifts GES-sat, sat-GES are the same each AES-sat is different and changes dynamically, going outband of prescribed channel.
Thus compensation should mean not passing frequency but compensating received doppler effect so it would be in 35Hz band of transponder channel.
Enlighten me, please, if the is not the case.
Skwosh said,
April 1, 2014 at 5:54 am
@AndRand
I am mostly trying to bring together the assumptions that I think are being made at the moment so that I can try to make sense of things. I have no domain specific expertise unlike @airlandseaman.
He has touched on this topic previously – in terms of the implementation at least (March 31, 2014 at 2:17 pm):
“… Beam forming networks and sophisticated DSP hardware is used now days to up-convert the frequency, but basically it works like a classic bent pipe transponder that uses a classical mixer. The full bandwidth of the transponder is mixed with a stable local oscillator to yield an output that is the same spectrum, but moved up from L band to C band by a fixed difference (~1966 MZ). Thus, an input frequency of 1634 produces an output frequency = 1966+1634 = 3600 MHz…”
I think I understand about what he means by a ‘classical mixer’ – some sort of non-linear combination that gives you a component you can filter out which will have the up-shifted frequency you want – and I also understand that in the world of DSP you can do anything you want (well… almost anything that is causal anyway!)
As I understand it, in reality, the aircraft are somehow dynamically compensating (perhaps based on the Doppler deduced from an earlier incoming signal) so that there is little or no Doppler in their transmitted signals when they transmit back to the satellite (that’s what I was trying to address in my ‘Aside’ above).
However, I’m not sure if this addresses your point – though I think much confusion still exists for many of us (me included!) over the question of whether or not the burst frequency offset is an *actual* measurable frequency that really exists at any point in the system, or if it is a derived value (after the apparently known aircraft compensations have been subtracted off by Inmarsat), and whether on not this derived value is what is being presented by Inmarsat in an attempt to simplify their presentation – though it may actually be generating much confusion.
Ole said,
April 1, 2014 at 6:16 am
@Skwosh
That was more or less my understanding too.
The term (1634 + 1966)*V_SG is D3.
Slide 1 of Annex 1 says that D3 is not part of the measured BFO. It can be regarded as “noise” which adds to the L-Band doppler of the aircraft. This “noise” was eliminated before plotting the BFO, so it makes no sense to calculate it back in?
@Duncan
I think your work already comes closes to being super human.
Nevertheless should there be a free time slot, it would be great if you could calculate the LOS speed of the satellite at 0:11UTC towards the endpoint of your 450 knot track. My suspicion is that at that point the BFO was almost only due to the contribution of the doppler from the sat’s velocity. Then there should be a pretty good _quantitative_ match between the 250-270Hz from the diagram and the doppler from the sat’s LOS velocity. The LOS velocity of the sat at that time would be in the range of 47-51 m/s.
AndRand said,
April 1, 2014 at 6:29 am
My point is that we are have strong assumptions on that creating accurate possible routes – and that is the goal. Before doing that it is good to know what possible error can be.
I will use the new shifts as shown here:
airlandseaman said,
March 31, 2014 at 7:01 pm
and I expect huge differences when based on doppler shifts only. I know this is the topic of this discussion but in my opinion delays should be primary source in the modelling and doppler shifts secondary while it is mostly guestimated.
GuardedDon said,
April 1, 2014 at 7:08 am
I hope that’s the start of some openness & clarity about some incontrovertible facts.
To follow: the Inmarsat login verification handshake times; any late ADS-B broadcasts from 9M-MRO that may have been received by the Vietnamese GBT on Con Son Island (or ATC radar on their mainland); and the track recorded by the RMAF of an unidentifiable aircraft around 18:00-19:00 UTC on 7th March?
airlandseaman said,
April 1, 2014 at 7:13 am
AndRand:
The delays are definately the most important of the two, but Doppler can provide a strong constraint on where the AER was on the arc.
The BFO to Doppler spreadsheet has been tuned with the help of Ari and Duncan. It’s very close to final. Will post updated data ASAP.
hal said,
April 1, 2014 at 7:37 am
@duncansteel said “However, joining the dots there (the green and red lines) by Inmarsat is inexcusable. Indeed, what they SHOULD have plotted was no dots, just curves. That is, they have hypothesized possible northerly and southerly tracks, and they can sample those tracks every minute or every second even in their software. So plot them! Then one might get a better idea as to what is going on.”
Precisely what I said several postings up. Or maybe it was on Jeff’s blog.
Anyway, the fundamental assumption underlying this exercise is that there is some relationship between the plotted doppler offsets and where the plane went. If they’re going to show plotted doppler offsets for two hypothetical north and south tracks, it would be most helpful to know where those hypothetical planes went.
As for all the reverse engineering going on, with the clear exception of Duncan Steel’s excellent (and not over-reaching) analysis, I haven’t learned much from the many deep dives into signaling technologies. All you guys with such technical prowess, could one of you first explain, in terms a layman with no more than high-school physics can understand?
@airlandseaman – I understand that you computed C-doppler or doppler-C or whatever, and that’s great. But you do realize, right, that your numbers correspond almost exactly to inmarsat’s BFO – 87 hz. Was your calculation intended to be a check on their numbers, so that you now can conclude they plotted the right thing? Or was your calculation intended to be an explanation of the 87 hz offset in their numbers (pre-take-off is not at zero). Or … what exactly?
I’m struggling here to get value from all the numerical analyses.
hal said,
April 1, 2014 at 7:43 am
That is “…could one of you first explain, in terms a layman with no more than high-school physics can understand, what the BFO plot purports to show?
airlandseaman said,
April 1, 2014 at 8:09 am
Because the LOPs or delays are still not known, except for the first three points (derived from ADS-B), these estimates are still based on some approximations. But we are getting very close. The remaining errors due to approximations are quite small at this point. If you plot these values you see that that it is starting to make sense.
Time (Local Malaysian) AER induced L-band Doppler (Hz) Aircraft radial velocity for 40 deg el angle (kts)
0:30 -1.858773092 -0.863645049
0:43 40.56853642 18.84943127
0:55 81.40616159 37.82388973
1:07 55.08302527 25.59332405
2:25 233.5768068 108.5272074
2:27 136.5679591 63.45381388
2:29 108.5591115 50.44001315
3:40 108.8539538 50.57700628
4:40 171.2631178 79.57428717
5:40 226.0755986 105.0419077
6:40 285.411716 132.6113535
8:11 355.6103902 165.2278884
airlandseaman said,
April 1, 2014 at 8:15 am
hal:
The definition of BFO is on page 1 of the Annex 1. It is the difference between the expected and actual (measured) frequency of the C band (3600 GHz) received carrier at the Perth LES. To get the L band Doppler out of this takes several steps. First, the C band Doppler is removed using STK derived Range rates for the C band link. Then the Total L band Doppler is computed. Then the satellite induced L band Doppler is removed. Then the AER induced L band Doppler is converted to L band Range rate from a “fixed satellite”. Then this rate is mapped to the earth surface by dividing by the cos (el angle).
duncansteel said,
April 1, 2014 at 8:16 am
Well, I have just put up a new post. I think that readers of this thread will likely find it interesting. Its title is:
The Inmarsat-3F1 Doppler Data Do Not Exclude a Northerly Flight Path for MH370
http://www.duncansteel.com/archives/507
Skwosh said,
April 1, 2014 at 9:40 am
@airlanseaman
Hello!
I think your reply to @hal has given me a little more insight into what you have been doing.
I’m still not quite with you – but thanks for revealing a little more of the process you’ve used – and please forgive my plodding – but I’m still a bit stuck and would appreciate guidance.
I am *very* keen to see a run-down of your calculation process.
However, as a first question, am I right in thinking the following:
The inputs to your process are (please correct if wrong):
* A BFO value.
* Duncan’s value for the line-of-sight relative velocity between the satellite and the ground station at the time corresponding to the BFO value.
The assumed constants in your process are:
* The up/down shift in the satellite of 1966MHz.
* The base frequency transmitted from the aircraft to the satellite of 1634MHz.
The output of our process is:
* A value that is proportional to the line of sight velocity of the aircraft with respect to a *stationary* satellite position.
So, to be clear, you are clearly stating that your output is *not* a value that is proportional to the line of sight *relative* velocity of the aircraft and the moving satellite?
Skwosh said,
April 1, 2014 at 9:50 am
@airlandseaman
Ah! I see a qualifier has appeared on your graph since the last time I looked:
“Note: satellite induced Doppler on L band link only removed from the first three points, estimated for the others using airport range rates, but the corrections are relatively small compared to AER Doppler”
This is making me think I wasn’t so crazy when I couldn’t work out how you could possibly subtract the ‘satellite Doppler’ independently unless you knew where the aircraft was and how fast it was moving!
AndRand said,
April 1, 2014 at 9:56 am
Well, I don’t know why I didn’t do it earilier as I should have done it at the beginning: here is comparison of Doppler shift (BFO) as provided by Inmarsat, as provided by AirLandSea today and as calculated on shear LOS sat-A/C speed Doppler Effect:
http://oi62.tinypic.com/ng54sg.jpg
airlandseaman said,
April 1, 2014 at 10:00 am
The latest Doppler is as good as the frequency assumptions (1634 and 3600 MHz). STK provides accurate rage rates, so I am confident we have good Doppler now. If those frequencies were known exactly, this model would produce essential exact Doppler with no other material assumptions or error.
https://twitter.com/Airlandseaman
AndRand said,
April 1, 2014 at 10:36 am
…and as calculated on shear LOS sat-A/C speed Doppler Effect:..
I think I should’ve added: “from recorded actual flight track log”.
and here are doppler shifts from ie. this track:
http://oi59.tinypic.com/vomq81.jpg
What to say? We need distances.
AndRand said,
April 1, 2014 at 11:01 am
Here is something interesting – when I tried to match previous track after 2 sharp turns with doppler effect only (without matching distances at all) and then turn south I obtained something like this:
http://oi58.tinypic.com/5d9vkx.jpg
Last part to match doppler needed quite strange turn:
Latitude Longitude Speed Heading
3 , 102 0 0
3.00 , 102.00 454 25
4.33 , 102.62 454 18
7.01 , 103.50 300 230
4.14 , 100.08 380 270
4.14 , 99.67 400 330
11.22 , 95.50 400 180
5.29 , 95.50 400 200
-0.80 , 93.29 400 229
-5.04 , 88.39 400 280
-3.29 , 78.81 700 110
AndRand said,
April 1, 2014 at 11:21 am
I think I have to re-check formulas… I don’t like the doppler shift increasing while moving towards satellite… hmm…
Skwosh said,
April 1, 2014 at 12:31 pm
@airlandseaman
Could I just ask you to confirm or refute the following regarding your basic calculation procedure – I’m not trying to attack your idea – I am simply trying to make sure that I understand it properly so that I can reason properly regarding your results.
I think it is *very* important – if we are going to get into the area of refuting Inmarsat’s analysis (as Duncan is doing) – that we are all 100% clear about where these numbers that you have produced are coming from, *exactly* how they have been calculated, and on what principles the calculations have been made.
To the extent that there is a common endeavour here it is perhaps to take a *multi-disciplinary* approach to trying to address a difficult and important problem. I have no doubts about your expertise and your competence – but I do not think that it is unreasonable of me to suggest that there are probably quite a few people hear, who’s expertise may well be in different domains to yours, who are still unsure of how you have got your numbers, and what they represent.
I really want to make this as easy for you as possible – so I am going to try to give as succinct a description of what *I* think you are doing, and then you can blow holes in it at your leisure.
Please understand – I am not critiquing your approach – I am simply trying to understand the full details of the calculations you have performed that allowed you to get your numbers from the numbers that we already have.
This is what I think your *calculation* process is (I will explain my notation subsequently – and I’m trying to express things in fairly general ‘physicsy’ terminology):
Calculate V_AS as follows:
V_AS = (BFO – (3600MHz * V_SG)) / 1634MHz
where:
[1] BFO is the published burst frequency offset value on Inmarsat’s graph
[2] V_SG is the relative velocity (in units of c) along the line of sight between the satellite and the ground station at the date and time corresponding to the BFO data point (and V_SG was provided by Duncan using STK).
[3] V_AS is the *result* of the calculation
V_AS is interpreted by you as the *relative* velocity (in units of c) along the line of sight between the satellite and the aircraft.
So – If you multiply V_AS by the speed of light you get the *relative* velocity of the aircraft and satellite along their line of sight.
This is as far as you can get if you don’t have any further info about the aircraft’s actual position at that time.
However, if you *do* know the aircraft’s *position* at the time then you know what the line of sight (vector between the satellite and the aircraft) actually was at that time, so you can calculate the component of the satellite’s velocity along that vector relative to fixed earth co-ordinates and so, by simply subtracting from the relative velocity previously calculated, you can determine the component of the aircraft’s velocity along that vector relative to fixed earth co-ordinates too (and will thus have eliminated dependence on the satellite’s velocity, though not in its position).
You have taken this subsequent step (removing dependency on satellite velocity) for the first few points on your graph because we have a pretty good idea of where the aircraft actually was at those times.
Is this correct?
I am very prone to errors myself – and often get things wrong – being dyslexic (I would be sunk without spell checkers!) – so there is likely much in the above that is wrong – but I usually get there in the end.
airlandseaman said,
April 1, 2014 at 12:49 pm
Skwosh:
C band Doppler can be removed without knowledge of the aircraft slant range, but the L band Doppler caused by the satellite can not be removed without an estimate of the slant range to the aircraft. That said, the L band satellite Doppler component is a small part of the Total satellite – aircraft Doppler, so even a good rough guess gives you very good approximations. The spreadsheet is set up to be easily modified using global parameters where possible. For example, the up/dn frequencies can be changed and the whole matrix recomputes. The first three ranges are known, and we have close estimates for the ranges up to 02:29 based on radar.
If anyone wants the spreadsheet to play with, send me an email:
airlandseaman@earthlinknet
AndRand said,
April 1, 2014 at 12:50 pm
I think it is easier as hamster3null did in spreadsheet – other way around – from speed, heading to doppler, distance:
- you calculate A/C movement and coordinates in 3D coordinates (0,0,0 earth center)
- calculate satellite movement from geostationary point
- calculate relative movements and distance
- in the end radial velocity component and doppler effect
Skwosh said,
April 1, 2014 at 1:09 pm
@airlandseaman
OK – cheers for the quick reply – may well take you up on the spreadsheet offer!
I have another musing which I’d appreciate your thoughts on:
Maybe I should be addressing this to Duncan – but with regard to Duncan’s plots in general – I think that all he wants – indeed all he has *ever* wanted – is a reliable measure of the *relative* velocity of the satellite and aircraft along their line of sight.
As far as I am aware this *is* what he is calculating in his velocity graphs, and this is what he has been comparing with the raw BFO values in the hope that this is indeed what those raw BFO values might represent (less some unknown bias) even though we all (including him) have become increasingly unsure.
I would say that he specifically *does* *not* want the satellite velocity components subtracting off from these values if all he is doing is a simple comparisons with his velocity numbers (given the way that he has been calculating them up to this point)?
Surely all he needs then, to use my notation, is something proportional to V_AS – or – I think in your terminology – the raw L-band Doppler value?
Or am I back to front again?
Ole said,
April 1, 2014 at 1:45 pm
airlandseaman,
how is the doppler compensation by the AES included in your calculation? The compensation values the AES sent in a header to the ground station are unknown to us.
Do you assume those compensation values were already added into the published BFO values? That would mean inmarsat is inaccurate when they say the BFO is what is measured at the land earth station, because the compensation values are not measured there.
airlandseaman said,
April 1, 2014 at 2:00 pm
Ole :
I interpret the Inmarsat definition of BFO litterally, which is the expected (nominal center frequency) – observed frequency on the inbound down link at Perth (~3600 MHz). This value by definition includes the AER offset. So BFO + 3.6 GHz = the observation.
hal said,
April 1, 2014 at 3:12 pm
@duncansteel – Thank you for keeping your eye on the ball, here, and always providing meaningful interpretations of your results. I”m headed over to your site right now to check out what you have on a possible northern route.
Skwosh said,
April 1, 2014 at 3:12 pm
@Ole Good point to clarify – not *quite* the answer I was expecting. Think I need to go and have a bit of a lie-down.
hal said,
April 1, 2014 at 3:26 pm
@duncansteel – Nice work with the new northern route analysis. You communicate like a scientist! In order for me to buy your analysis, though, I need to understand why the inmarsat northern route was not a straight line on the BFO plot. Your doppler plots and inmarsat’s southern route were straight lines, but their northern route saturated, you might say (stopped increasing) and crossed over the southern route’s doppler points.
What do you believe they did differently?
hal said,
April 1, 2014 at 3:27 pm
@skwosh – I think you should give up your present line of inquiry, and go visit Duncan Steel’s site.
airlandseaman said,
April 1, 2014 at 5:43 pm
Latest Doppler:
http://t.co/XeYfEFXx47
jcollins said,
April 1, 2014 at 6:19 pm
engineer here…
FYI: The flightaware flight history for MAS370 for 7 Mar, 2014 is incomplete, probably because most of the flight occurred outside its coverage area. The last ADS-B record is for 12:02 PM EST (16:02 UTC and it’s incomplete (fpm is missing); it shows a NE (25 degree) heading. The next record (at 12:05 PM), and all subsequent records, is/are ESTIMATED; it shows a N (18 degree) heading)_ The flight history at FlightRadar24 has evidently been deleted (I couldn’t access it today)..I do have a few records (screenshots) which I saved from earlier. The last FR24 record, presumably at 17:22 UTC (times aren’t listed) shows a track of 40 degrees. The record which immediately precedes it shows a track of 25 degrees. FlightRadar24 tracked mh370 until the transponder died and ADS-B conked out. I read somewhere that the flight plan specified a jog to starboard at or near IGARI and that the NE (25) bearing was to resume as the flight neared Viet Nam (turn to port). If anyone has a complete ADS-B record of the flight, I’d be pleased to see it. The same goes for the complete flight plan for the Beijing flight.
Regarding the Burst frequency offset plot: RMAF radar lost contact with the flight (mh370?) at 18:22 UTC on a NW bearing in the Strait of Malacca some 200 nm LOS from Butterworth AB (Penang). I’ve been trying to reconcile the aforementioned bearing with the “Doppler” information in the plot at 18:25, 18:27, and 18:29 which suggest a substantial turn. How is it that the aircraft was flying NW at 18:22, toward the satellite and at 18:25,.3 minutes later,is moving rapidly away from the satellite, and at 18:27 substantially less rapidly, and at 18:29 even less rapidly, suggesting a turn, not to port but to starboard? Am I safe in assuming it was a tight turn?
Can anyone confirm or lay to rest the “rumor” that the engines could report directly to Rolls-Royce et al via the satellite and ground station without the involvement of ACARS? Since I’ve read that ACARS periodically reports engine performance data, I’m wondering what the nature of any such non-ACARS data would be.
Finally (for now), if the aircraft ACARS isn’t working (has been switched off or has failed), and the airline attempts to use ACARS to contact the aircraft, will the “pings” and the associated Doppler/Burst data be recorded nonetheless?
Thanks
Alex Siew said,
April 1, 2014 at 6:33 pm
@hal,
Sorry i missed one of your earlier comments, part of which was addressed to me.
According to Duncan, the satellite reached its northern apex just before 3.36am, then it turned southwards attaining speed ‘rather quickly’.
The Doppler effect for just before 3.36am would be zero (assuming a stationary plane). However, the Doppler effect for 3.40am, the time for the second completed ping 4 minutes later would not be zero as at such time the satellite was already moving southwards, away from the plane.
Someone posting as “sid” postulated in his comments on Duncan’s website that the Doppler readings for 00.30am (plane stationary at tarmac) and for the first ping at 2.29am should be negative, rather than positive as shown on the chart. I am not sure of the basis for his argument but presumably the fact that the satellite was moving towards the plane before 3.36am and moving away from the plane thereafter, may have something to do with it.
If what he says is correct, the revised chart would seem to make a lot of sense with a reading of negative 85Hz at 00.30am, zero at 3.36am and positive readings thereafter.
hal said,
April 1, 2014 at 8:33 pm
@alex – Not sure if your first two paragraphs were addressed to my questions, but I do have a couple of concerns about what you said. You say the doppler effect when the satellite is stationary would be zero, but doppler measures relative velocities so a moving plane should create a doppler shift with a stationary satellite. Secondly, in your last sentence you refer to the satellite moving southwards away from the plane. Not sure what scenario you’re referring to. In the ‘official’ one (Malaysian govt and INMARSAT), the plane was south of the satellite at 3:40 so a southward-moving satellite would be moving toward, not away from, the plane.
hal said,
April 1, 2014 at 8:50 pm
@jcollins – Welcome! Statistician here. I think it’s safe to say that no one here understands that BFO chart. Or if someone does they’re not sharing.
A few facts we’ve established through discussions here, based on logic or analysis or statements by INMARSAT (group feel free to correct anything that’s wrong):
1 – The plane and satellite never moved toward one another (assertion by Malaysian government or INMARSAT).
2 – The 87 hz BFO at takeoff is unexplained.
3 -The high BFO at 18:27 might’ve been related to a dive (speculation)
4 – INMARSAT has not released what their “Predicted Tracks” look like over ground.
5 – No one has explained why there is a 1 hr 30 minute gap during which no pings were received as the plane traversed the Malaysian Peninsula headed west.
6 – The satellite drifts north and south in its orbit.
* At takeoff it was moving north at about 130 kt
* At 1:07 am (last ACARS) it was moving north at about 100 kt
* At 2:40 am (first ghost ping) it was moving north at about 50 kt
* At 3:40 am (second ghost pint) it was approximately stationary at its northermost position, or had turned and was headed south.
* At 4:40 am it’s headed south at about 50 kt
* At 5:50 am it’s headed south at about 100 kt
* At 8:11 am (the last ping) it’s headed south at about 150 kt
These speeds are from data provided by Duncan Steel.
As you enter the rabbit hole, you will find a sandwich in a greasy bag sitting on a table. Good luck on your ‘adventure!’
hamster3null said,
April 1, 2014 at 9:05 pm
@airlandseaman,
This breakdown is interesting, but it actually makes the fit much worse for me than the naive assumption of fixed delta of +87 Hz. Generally speaking, it is inconsistent with known search areas in the Indian Ocean.
Look at it this way. We have the aircraft starting north of the equator and headed roughly south. It needs to have very low delta-v both at 18:30 and 19:45. On the original chart, if you backpredict the line connecting 19:45 and subsequent points, it actually goes below +87 Hz at 18:30. This is all as expected.
In your breakdown, Doppler is consistently large for 18:30, 19:45 and above, and the backpredicted trend line never crosses zero. It means that the aircraft is no longer moving south, it’s moving southeast at some significant angle to the lines of longitude.
If I plug your adjusted data into my spreadsheet, best-fit headings become 160 degrees at 450 knots and 150-155 degrees at 400 knots. First option puts the aircraft only a couple of hundred miles off the coast of Australia, and second option puts it _in_ Australia.
Alex Siew said,
April 1, 2014 at 9:11 pm
@hal,
Sorry, i was referring to your comment made on March 29, 2014 at 11.41. The scenario i was referring to is the plane being stationary at all 6 completed handshakes, ie a crash early on.
meadows.st said,
April 1, 2014 at 9:21 pm
All,
Since there are a lot of conversations, new people joining this multi-discipline analysis and domain experts that may want a centralized repository for their results, I created a simple spreadsheet that can be found on Google Docs and you only need the link and you should be able to access the workbook. I will endeavor to keep this list current but if you want to edit the document, let me know via this forum and I will add you to the list of editors.
I am also in the process of reaching out to my network to see if I can get us some additional data.
hamster3null said,
April 1, 2014 at 9:27 pm
@hal,
“I need to understand why the inmarsat northern route was not a straight line on the BFO plot”
I’m not Duncan Steel, but I’ve been thinking about this for a while and I tried to come up with a route that would produce BFOs matching their “predicted north”. There is essentially only one way to draw a northbound route with these BFOs. It would have to go from Strait of Malacca north across Burma. (There are a few options what to do next, it could keep going till it crosses China, or, with some creativity, it could be drawn to make a 90 degree turn and follow the Himalayas.) I suspect that someone at Inmarsat tried to draw a route that would get MH370 to the northern corridor without being seen by either Indian or Thai military radars (naturally, assuming 100% vigilance on the part of both militaries).
meadows.st said,
April 1, 2014 at 9:31 pm
Correction: Probably best if this is maintained as a Google Sheet – link is This is the Google Sheet link . The original link in my previous post was an Excel workbook.
AndRand said,
April 2, 2014 at 12:28 am
hal said,
April 1, 2014 at 8:50 pm
1 – The plane and satellite never moved toward one another (assertion by Malaysian government or INMARSAT).
Actually, it did – just following first turn.
Anyway – if, IF the pilot(s)’s intention was to make the plane disappear (in ocean, taklamakan dessert or worigirmarosivistan), he made it. And if further, it was to spectaculary appear, he failed.
jcollins said,
April 2, 2014 at 12:52 am
@hal,
Thanks for the welcome! As to item #1: My understanding is that INMARSAT asserted that the plane was discovered (calculated) to have been farther from the satellite with each successive ping. If so, that wouldn’t preclude the possibility that it moved closer to the satellite from time to time during the inter-ping intervals. If the plane followed a NW path along the strait and out toward the Andaman Sea, it did indeed travel in the direction of the satellite, unless the satellite moved in the opposite direction at sufficient speed to make the net radial speed positive (away from the satellite), which I doubt. I suppose, rather than saying that the plane moved toward or away from the satellite, or that the satellite moved toward or away from the plane, we should observe that the distance between the satellite and the plane increased or decreased. The problem is one of choosing a convenient frame of reference. All motion is relative. My assertion is that at the instant that the plane disappeared from military radar at 2:22 MYT, the distance between it and the satellite was decreasing; but, was it the missing Malaysian airliner?
As to item #2: As I’m sure you know, the BFO is a measure of the Doppler shift in the signal transmitted from the satellite. That’s the simple answer. The full, precise answer is too detailed for me to tackle at 2:46 AM. The 87 HZ is owing to the movement of the satellite relative to the Earth…plus a constant…that varies. It’s all to ensure that when the signal from the AES is received by the satellite (which signal will, itself, be Doppler shifted), it will be within bounds as to frequency and bandwidth. This is a means of extending the range of the satellite and conserving bandwidth.
As to item #3: The dive…if so, what was the rate and duration? Further, what was the purpose? In what direction…other than down?
As to item #4: Why are they withholding that information, do you suppose? IOW, they haven’t published all the ping arcs? I’ve been wanting to see those from day one.
As to item #5: Yes…headed west toward the satellite…darn! 1:07 to 2:25 = 1 hr and 18 min. There were three such gaps in all. Are they all inexplicable? A problem in the satellite timer? Weather?
As to item #6: Thanks for this info…it’s just what I needed. The first “ghost ping” at 2:40? I don’t see it on the BOF graph/chart/plot; but, no wonder–it’s a ghost. What are the maximum north/south east/west velocities.? There’s a chart in here somewhere..by Steel, I think.
While in pursuit of philosophy, I revisited Carroll…a genius, I think. So, what does the sandwich in the bag symbolize? I’ll bite.
Ole said,
April 2, 2014 at 1:00 am
airlandseaman said,
April 1, 2014 at 5:43 pm
Latest Doppler:
http://t.co/XeYfEFXx47
Thanks for posting the update.
I would expect the sign of the doppler shift to be positive when transmitter and receiver are closing in on each other (freq becoming higher) and to be negative when transmitter and receiver are moving away from each other (freq becoming lower). Positive doppler shift at the end of the flight would then mean the aircraft was closing in on the satellite.
How do you derive the C-Band doppler shift? According to Duncan at 0:30 the LOS-velocity aircraft-satellite was 21 m/s (distance becoming smaller). At that time the absolute LOS-velocity Perth-satellite (distance becoming bigger) must have been greater than those 21 m/s, because Perth is much farther away from the satellite and the direction Perth -Satellite is more in the direction of the sat velocity.
If we assume 3.6 Ghz for the C-Band then we get a doppler shift of :
3.6*10^9 Hz / 3*10^8 = 12 Hz/(m/s)
At 0:30 the LOS-velocity perth-satellite was greater than 21 m/s, so the doppler shift in the C-Band must have been _greater_ than 12*21=252 Hz. In your diagram the C-Band doppler at that time was only 87Hz.
Did you scale the C-Band doppler such that the aircraft doppler at 0:30 becomes zero?
duncansteel said,
April 2, 2014 at 2:00 am
Some wonderful person (GlobusMax) has reverse-engineered the ping time delays hence ping ring arc positions (or, vice-versa). See
http://www.reddit.com/r/MH370/comments/21jla4/mh370_flight_waypoints_timing_and_speed/
and previous posts there.
More later; much later.
Duncan
alex370 said,
April 2, 2014 at 4:56 am
“I created a simple spreadsheet that can be found on Google Docs and you only need the link and you should be able to access the workbook.” I do not want to edit the document, I just want to read it, but it needs a permission, without it it does not show me the spreadsheet
meadows.st said,
April 2, 2014 at 5:47 am
alex370 said,
April 2, 2014 at 4:56 am
“, I just want to read it, but it needs a permission, without it it does not show me the spreadsheet”
See my corrected link below that post. The excel doc did not allow collaboration easily so I converted it to a google sheet.
alex370 said,
April 2, 2014 at 6:49 am
Thank you
hal said,
April 2, 2014 at 6:50 am
@hamster3null – Thanks for your thoughts! Based on INMARSAT’s assertion that the plane moved farther from the satellite with each successive ping, I’ve been reading the BFO graph to mean that BFO and relative velocity are proportional. I.e., plane moving away from satellite (relatively) produces BFO that is larger than plane moving toward satellite.
We’ve also learned that the satellite was moving north until about 3:40 am, then started accelerating southward. This means that the last three plotted red points occurred at a time when the satellite was accelerating southward.
If these assumptions are correct, then the points plotted in red (northern route) tell us the plane was moving away from the satellite at a higher velocity as the satellite moved north, than it was as the satellite moved south. In order to visualize this, I’m having to assume changing airplane velocity or a significant turn westward in the northern route. Is that the 90-degree turn you refer to? How do you work it out without the 90-degree turn?
Or … what am I missing?
hal said,
April 2, 2014 at 6:59 am
@alex – Thanks for clearing that up. So you would argue that the small positive increment at 3:40 (relative to BFO at takeoff) could be due to the satellite already accelerating south. That could be, but I’d ask the numbers guys to compute the expected value if that’s true. The early-crash theory based on equipment failure has a lot of allure, given: a) their abject inability to find anything in the southern Indian Ocean; b) the fact they’ve found nothing to implicate the pilots: c) the fact that there is no ground chatter to suggest terrorism; d) the oil rig worker’s report of seeing a plane on fire; e) China’s early find of an oil slick.
hal said,
April 2, 2014 at 7:13 am
@AndRand – Good correction. I was sloppy in my wording. As @jcollins has also pointed out, the assertion is that the plane and satellite moved farther apart with each successive ping.
airlandseaman said,
April 2, 2014 at 7:31 am
There have been many comments on the BFO chart, and my analysis over the last day. I get the impression there is still a lot of confusion, so I will try to provide some help understanding the meaning of the BFO chart, and Doppler.
1. The Inmarsat definition of BFO is ” …the difference (due to the Doppler contributions) between the expected receive frequency and that actually measured.”
2. The received frequency is not the frequency transmitted by the AER (aircraft radio). It is the inbound downlink frequency from the satellite, as received at the Perth LES. This frequency is ~3615 MHz for an inbound uplink frequency of ~1643MHz. The satellite transponder mixes a fixed local oscillator signal (1972 MHz) with the 1643 MHz signal to generate the downlink signal. All inbound uplink signals received by the satellite are translated to the downlink using this constant 1972 MHz value. (all frequencies are estimated, but within ~1%).
3. The raw BFO frequency cannot be interpreted as Doppler + offset or similar simple formula. It is more complicated than that, as explained below.
4. The satellite motion induces Doppler on both the uplink and downlink carriers. Because the frequencies are different, the satellite induced Doppler on the downlink is much greater (~ X 2.2) for a the uplink (assuming the same geometry).
5. The observation, received frequency at Perth, contains AER induced Doppler, satellite L band Doppler and satellite C band Doppler.
6. To calculate the net AER Doppler, both the L band and C band Doppler induced by satellite motion must be subtracted from the observation.
7. If the “expected frequency” (nominal assigned channel center frequency) is 3615.000000 GHz, and the BFO frequency is, say, +200 Hz, then the observed frequency is 3614.999800 MHz.
8. The satellite induced Doppler on the downlink frequency is removed by using the satellite ephemeris and LES position to compute the “range rate” (rate at which the satellite is moving towards or away from the LES antenna). The Doppler frequency is simply the range rate divided by the wavelength (.08293 m). This component of the observed frequency is a significant. It varied from -82 Hz to +100 Hz during the MH370 flight.
9. Once the downlink Doppler is removed, we have the Total L band Doppler as it would be observed if measured at the satellite. (Nothing is actually observable at the satellite.)
10. The AER component of the Total L band Doppler is calculated by subtracting the satellite induced part of the L band Doppler. This uplink calculation is more complicated than the downlink calculation due to the fact that the AER is moving, but the LES is not. Because the AES is moving, the range rate is changing due to both satellite motion and changing geometry, complicating life. Since we do not have the Inmarsat delays (free space propagation times between the AER and satellite antennas), we are forced to use estimates. But the estimates must assume a path, and that is where we have to be careful. Fortunately, the geometry was such that the L band satellite induced component of the total L band Doppler was fairly small compared to the AER component, so rough approximations for the aircraft path do not significantly change the estimate of AER L band Doppler.
11. Once the AER Doppler component is separated from all the other components and corrections embedded in the BFO frequency, the relative velocity can be computed = AER Doppler*wavelength=AER Doppler*0.1824m.
12. The relative velocity can be mapped to the local horizontal plain by dividing by COS (elevation angle).
Clearly, the raw BFO frequency by itself is not that helpful, but it does make possible the fairly exact calculation of the AER Doppler, and with the addition of an STK Model, it can provide a far better estimate of where the aircraft ended up on the 08:11 arc.
hal said,
April 2, 2014 at 7:32 am
@jcollins – Thanks for your correction of my sloppy language. Clearly the ‘official’ account has the plane moving toward the satellite as it crossed over the Malay Peninsula. Oddly, there happen to be no ping points associated with that part of the route. I’ve not seen any explanation for this.
You ask “but, was it the missing Malaysian airliner?” What’s your theory on that? We’re a technical bunch but also entertain far-out theories given that none of the standard ones seem to be working in this instance.
#2 – Regarding the 87 hz offset, your explanation makes sense in a way that the many computational details posted previous do not. But you might want to read back through those (especially posts by @airlandseaman) and verify that their work fits your understanding.
#3 – The “dive” refers to some discussion earlier about the descent from 35k feet to 12k feet, and that depending on when that happened relative to these pings, the change in elevation is also a change in satellite-plane distance.
#4 – No one here seems to know but some are pushing for it. Another site you might want to visit (there is much cross talk) is http://www.jeffwise.net. Jeff has appeared numerous times on CNN and is also pushing INMARSAT to be more forthcoming. Jeff I hope this is a correct description.
#5 – Suspicious and not explained by INMARSAT as far as I know.
#6 – The time is approximately 2:40, not exactly. And by ghost ping, I mean the first normal-looking ping for which we have no other airplane data (ACARS and transponder contacts have been lost). This is the point at which, by some accounts, the plane became a ghost ship flying untended into the Indian Ocean. And yes, @DuncanSteel posted the satellite speeds. I believe he has peak speed of 170 kt as it crosses the equator.
Greasy bag – sorry this was a reference to an ancient online game called “adventure” back in the early days of unix before any kind of graphical interface. By typing stuff on the command line you could take a trip down into a land of twisty windy tunnels trying to find treasure. A room near the beginning always had that sandwich in a greasy bag.
Maybe I should stop posting late at night!
hal said,
April 2, 2014 at 7:43 am
History of the Adventure game on unix:
http://rickadams.org/adventure/a_history.html
AndRand said,
April 2, 2014 at 8:08 am
duncansteel said,
April 2, 2014 at 2:00 am
Some wonderful person (GlobusMax) has reverse-engineered the ping time delays hence ping ring arc positions (or, vice-versa).
I rushed for new data like hungry for new fresh sandwich
But the question is: how did you obtained those figures
http://i.imgur.com/8NVLaqV.png
Where they come from?
As I reckon they are results for aircraft position, not distances estimated on pings.
AndRand said,
April 2, 2014 at 8:21 am
Recently I compared distance calculations using x,y,z with geostationary satellite position (with offsets) and slant range formulas (cosinus theorem) and they differ veeery significantly (probably due to not accurate coordinates).
First uses earth center as (0,0,0) and satellites geostationary as (0,0,42163.59) satellite’s position ((perigee+apogee)/2+earth radius). Then applies only NS position change (km) and movement (kmh) to calculate distances from airplane positions – ~37K km.
Second uses slant range formulas (cosinus theorem) with SatLng-ACLng and SatLat-ACLat as alpha… ~49K NS, ~41K WE km…
Quite a difference.
GuardedDon said,
April 2, 2014 at 8:21 am
Duncan, Airlandseaman,
I believe there’s an alternate to discriminate N vs S tracks from the verifiable information we now have to hand, i.e. the known track from WMKK, the BRO & doppler data describing I3-F1 to a/c radial velocity, the IGARI wayoint, the satellite position. What I’ve figured fits both the BRO chart on Appdx 1 pg2 and Exner_BRO_Model_2014-04-02.xlsx
Duncan agreed with me that the BRO graph (pg 2 of the appdx PDF) is presented very badly – rather than simply joining the dots, it should be a simple scatter plot. However, if anything improves it, a smoothed or trended interpolation between the plotted events is important.
The BRO & doppler data indicate when the aircraft to satellite radial speed is 0 – e.g. the first point in the Appdx I/pg2 series (assumed to be the ‘push-back from gate’ event ACARS transmission). I’ll call that radial velocity (rv) = null. That null condition will also be evident when the aircraft is travelling on a course perpendicular to the radial from the satellite (tangential to that all important arc).
I’m assuming a straight course (either the AFDS using HDG Sel or FMC programmed direct to waypoint) after the last turn, that seems to be consensus & consistent with the radial velocity implied by the workings. So interpolating a ‘nice’ smoothed curve, in reverse, from the measured and predicted southbound points shows that RV = null in the 18:30-18:45 UTC time frame.
That timing means that its last, and only significant, turn was to south from a point not far beyond IGARI.
I realise that conflicts with the generally accepted hypothesis that 9M-MRO’s divergence, from the normal flight plan, occurred between 17:11 and 17:30 with an initial turn west towards Penang Island and ultimately south. On such a course the ETA, on a southerly track, at that null point would be much later. To be clear, I cannot find *anything* to reliably substantiate the alleged military radar sightings.
I’m working on adding the interpolation to the shared information & will post later this evening (BST).
Skwosh said,
April 2, 2014 at 8:23 am
@airlandseman
Thanks very much for the more detailed description of your procedure.
I have one quick point of clarification:
You say:
“9. Once the downlink Doppler is removed, we have the Total L band Doppler as it would be observed if measured at the satellite. (Nothing is actually observable at the satellite.)”
Could you just confirm that this means, in your interpretation, that the “Total L band Doppler” you refer to here – and as calculated from the BFO in the way you describe – is proportional to the instantaneous relative velocity of the satellite and the aircraft along their line of sight (or, as I think it would be in your terminology, proportional to the relative AES to satellite range-rate)?
I am guessing the answer to this must be a “yes” given that you state in your next section 10 that “… because the AES is moving, the range rate is changing due to both satellite motion and changing geometry, complicating life…”
Cheers!
airlandseaman said,
April 2, 2014 at 9:37 am
Skwosh : YES. Total L band Doppler means the Doppler along the LOS path caused by the satellite antenna and the AER antenna relative motion.
AndRand said,
April 2, 2014 at 10:27 am
Here are the distances, prolly reverse-engineered from Inmarst diagrams.
THX Duncan, THX KR
http://i.imgur.com/R5r3OhD.png
AndRand said,
April 2, 2014 at 10:27 am
Here are the distances, prolly reverse-engineered from Inmarst diagrams.
THX Duncan, THX KR
http://i.imgur.com/R5r3OhD.png
Let’s go to the spreadsheet…
Skwosh said,
April 2, 2014 at 11:02 am
@airlandseaman
Thanks very much for the clarification. Sorry to keep bombarding you with questions!
Having digested your recent post further and I have made the following summary of your claims/interpretations using my physicsy notation:
[1] BFO = (Actual frequency observed at ground station) – 3.615GHz
[2] BFO – (3.615GHz * V_SG) = 1.634GHz * V_AS
Where V_SG is the relative velocity of the satellite and ground station along their line of sight and V_AS is the relative velocity of the aircraft and satellite along their line of sight (both in units of the speed of light).
I hope this is correct, and I would very much appreciate if you could confirm that you agree with this as a summary of your current position on the meaning and interpretation of the BFO (I appreciate that this does *not* cover any of your later discussion regarding how to remove the satellite component from V_AS).
Many thanks.
hamster3null said,
April 2, 2014 at 11:22 am
@hal
“We’ve also learned that the satellite was moving north until about 3:40 am, then started accelerating southward. This means that the last three plotted red points occurred at a time when the satellite was accelerating southward.”
The satellite was at the furthest point to the north somewhere around 18:00 UTC. It was moving south for most of the duration of the flight.
On the “predicted southern” track at 18:30 and 19:45, the satellite is moving south and the aircraft is moving south parallel to the satellite, giving us low Doppler.
On the “predicted northern” track at the same time, we have high Doppler because now the aircraft is flying in the opposite direction. Since the satellite is near the equator, the aircraft starts at 7 deg N at 18:30 and it would be somewhere around 15 deg N by 19:45, heading due north actually means moving away from the satellite.
“True” northern track like the one Duncan Steel drew would compensate high Doppler due to flying away from the equator and due to moving in the opposite direction from the aircraft by adding a westward component to the speed, turning the aircraft towards India.
Let’s forget about a 90 degree turn, it’s less important and requires further conjecture. All that matters is that the first few points (19:45 and 20:45) of “Inmarsat: predicted north track” are most consistent with the route into Burma.
airlandseaman said,
April 2, 2014 at 12:00 pm
Skwosh:
[1] As I read it now, BFO=Expected – Observed (opposite from your [1]. This is what the document states. Note that this interpretation is consistent with the convention for positive Doppler (not BFO) values meaning a faster closing rate.
[2] I don’t think this equation makes any sense. The BFO value is in Hz and the other two terms of your equation would be meters per second squared…an acceleration… so this doesn’t seem to make sense to me.
GuardedDon said,
April 2, 2014 at 12:01 pm
FYI:
A post earlier noted that Flightradar24 had expired MH370; they haven’t, it’s pinned, see – http://www.flightradar24.com/data/pinned/
Flightaware still shows it if you have login access, not paid, simply as registered user.
Skwosh said,
April 2, 2014 at 12:16 pm
@airlandseaman
Ah, thanks for the feedback. Sorry – my terminology was unclear:
When I say my V_SG and V_AG are in units of the speed of light what I mean is:
V_SG = relative_vel_of_sat_to_ground / speed_of_light
V_AG = relative_vel_of_aircraft_to_sat / speed_of_light
So these quantities are *dimensionless*.
So, let me re-write my summary again:
[1] BFO = 3.615GHz – (Actual frequency observed at ground station)
[2] BFO – (3.615GHz * V_SG) = 1.634GHz * V_AS
Where V_SG is the relative velocity of the satellite and ground station along their line of sight divided by the speed of light and V_AS is the relative velocity of the aircraft and satellite along their line of sight divided by the speed of light.
Is this OK now?
GuardedDon said,
April 2, 2014 at 12:25 pm
The last location tracked by Flightradar24 is
Time UTC: 17:21:03
Lat: 6.97
Lon: 103.63
Alt: 35000
Speed: 471 knots
Heading: 40
“Between 17:19 and 17:20 the aircraft was changing heading from 25 to 40 degrees, which is probably completely according to flight plan as MH370 on both 4 March and 8 March did the same at the same position. Last 2 signals are both showing that the aircraft is heading in direction 40 degrees.” fr24.com
That position is the IGARI waypoint.
hamster3null said,
April 2, 2014 at 12:52 pm
@airlandseaman
Is BFO signed or unsigned?
AndRand said,
April 2, 2014 at 12:59 pm
airlandseaman said,
April 2, 2014 at 7:31 am
Thanks for good explanation of consecutive steps in GES-LES-AER communication.
Still the question is – what is the BFO presented by Inmarsat as it was showed with D1 and D2 removed from equation?
I still don’t knw how to match those BFOs with real track while doppler shifts calculated for 3.6GHz are:
LOS radial component V Doppler shift
-3.55 -0.01
-191.11 -0.64
-223.96 -0.75
-216.52 -0.73
-305.48 -1.02
4.81 0.02
1.75 0.01
10.81 0.04
10.97 0.04
8.80 0.03
5.26 0.02
hal said,
April 2, 2014 at 1:06 pm
@hamster3null said “The satellite was at the furthest point to the north somewhere around 18:00 UTC. It was moving south for most of the duration of the flight.”
That is not correct. At least not according to the information DuncanSteel posted here. As show below, the northernmost position occurred at or near 19:40 UTC or 3:40 am local time:
UTC Latitude Longitude
16:30 1.129 64.551
16:43 1.194 64.549
16:55 1.252 64.547
17:07 1.306 64.545
18:25 1.563 64.531
18:27 1.567 64.531
18:29 1.571 64.531
19:40 1.640 64.520
20:40 1.576 64.510
21:40 1.404 64.500
22:40 1.136 64.490
00:11 0.589 64.491
airlandseaman said,
April 2, 2014 at 1:17 pm
hamster3null:
Yes, it is a signed value. Note that the sign of the BFO and Doppler can be the same or different depending on satellite and aircraft motion.
Sorry, I can’t answer every question. Headed out to single digit latitudes. But I am happy to share my work and take suggestions for improvements. Send you request to:
airlandseaman@earthlink.net
…and I will reply with the spreadsheet containing all the math and assumptions.
Mike
jcollins said,
April 2, 2014 at 1:21 pm
@hal,
Your language was fine. I just wanted to be sure of my interpretation.
There were three gaps (intervals > 1 hour) in ACARS messages and pings. That there were no ACARS messages beyond 1:07 has been explained, correct? No explanation for the lack of pings at expected times though. Maybe the satellite was busy…or, if it is the case that the timer resides at the GES, the GES was busy. What does the timer-controlled “ping manager” do if the AES doesn’t reply? Does the GES keep a record of the attempt? I guess we’d have to be intimately familiar with the intricacies of the system in order to understand it all. While I’m thinking about it, what’s your opinion the “joy ride” hypothesis, now that malicious mischief has been ruled out? While I’m thinking about it, how does one rule something IN?
I have no “far out” theories about the disappearance of flight MH370. I’m a down-to-earth kinda guy. There was some speculation early on that the plane seen on military radar might have been another plane that was flying incognito in the area at the time.
I think it was reported that the oil slicks were tested for jet fuel and none found. I wonder if it was a proper laboratory test.
I really feel for the families of the missing; especially for that Lee Kim Fatt fellow–husband of the flight attendant; wish there were something I could do to ease their pain.
Thanks for your advice re the offset discussion. Evidently it’s an absolute value; no sign (negative or positive). The offsets in the BFO graph should all reflect negative shifts?
I was under the impression that the descent from 35K ft. to 12K ft. occurred during the “turnback” from IGARI. There was a lot of discussion about that on CNN.
Yes, I’ve seen and listened to Jeff innumerable times. He seems to be better informed and have a better grasp than most of the commentators/guests on CNN and other channels
The question remains what the GES (or the satellite) does in the event of no response to its query. Does it continue to poll for a while (hours) or does it scratch the AES off the list immediately? The question also remains whether (or not, if you prefer) the engines report directly to the satellite (and, hence GES) when trouble develops, or whether they continue to attempt to report via the ACARS, or whether they ever, under any circumstance, utilize the ACARS; in short, how are engine parameters and performance anomalies reported to the GES/Rolls-Royce? These are things I’d expect Jeff to know. I’m not one to be easily convinced.
Well, I’m intrigued by the ghost ping now, and the possibility that the plane became autonomous at that point and remained autonomous from then on. The time was approximately 2:40?…or 2:30?..or precisely 2:25? Chasing a ghost here; hope he’s friendly. (: The 170 kt max speed for the satellite: is that LOS from the aircraft or ground speed?
Treasures in tunnels: Freud would have a field day with that one. Maybe you should post more late a night.
Skwosh said,
April 2, 2014 at 1:30 pm
@airlandseaman
I think my summary of what you are asserting is actually quite simple and quite easy to understand compared to a spreadsheet.
I think a *public* confirmation from you in *this* *forum* that my summary is correct (or your refutation until I get it right) would be *very* helpful for everyone else.
From your last reply it seemed like we were *almost* there. I really would appreciate your confirmation.
To reiterate, in light of your last post, my two line summary of your position regarding BFO is as follows:
[1] BFO = 3.615GHz – (Actual frequency observed at ground station)
[2] BFO – (3.615GHz * V_SG) = 1.634GHz * V_AS
Where V_SG is the relative velocity of the satellite and ground station along their line of sight divided by the speed of light and V_AS is the relative velocity of the aircraft and satellite along their line of sight divided by the speed of light.
Is this now correct?
AndRand said,
April 2, 2014 at 1:32 pm
hal said,
April 2, 2014 at 1:06 pm
That is not correct. At least not according to the information DuncanSteel posted here. As show below, the northernmost position occurred at or near 19:40 UTC or 3:40 am local time
I don’t think they are much usable – at 35,000km altitude usage of surface coordinates will generate big errors.
Also matching doppler shifts is doubtful – these calculated for recorded track corelate lineary divided by 4 with those presented in Annex… why? It is impossible to say not knowing what Inmarsat showed as BFOs. :/
AndRand said,
April 2, 2014 at 1:36 pm
9Ghz…?
GuardedDon said,
April 2, 2014 at 2:14 pm
In reply to ‘jcollins said, April 2, 2014 at 1:21 pm
Aircraft data comms:
The flight operational datacom service is provided by SITA for Malaysia Airlines. SITA’s service can be delivered over terrestrial radio links but satcoms adoption has increased to maintain updates over log over-water sectors. Inmarsat is typically the satcom provider. the evidence here suggests that Malaysia Airlines define a manual selection of satcom over VHF (the SITA VHF coverage over the Malaysian peninsula is good according to SITA’s publications.
ACARS is more a messaging protocol. SITA will route the messages between the airline ops centre and the aircraft. They’re very terse! Additional services, like the RR engine monitoring and Boeing’s AHM can be delivered also but they are passed through the SITA hub.
‘pings’ – there’s one message from the GES, as part of Inmarsat’s data link management, that is a ‘direct verification’ of the AES ‘log-in’ status. It’s initiated if there’s no activity on the datalink within a certain time, if the AES replies then the timeout is re-set. Any other msg will cause the timer to reset. Hence 4 regular comms events 19:40 thru 22:40 UTC. Becasue there’s gaps > 1hr, on the original Appdx 1 BRO charts published by MoTM, I suspect that MoTM is are withholding information of other msgs that haven’t been discussed in public (if so, they’ve shot themselves in the foot as the AMS(R)S spec states the ‘direct verification’ happens with a fixed timeout).
We did cover a lot of this earlier in comments among Tim’s three posts but I appreciate it’s hard to follow hundreds of comments.
Don
Alex Siew said,
April 2, 2014 at 3:01 pm
@GuardedDon,
Thank you for your analysis. You said ” RV=null in the 18.30-18.45 UTC time frame”.
Can i as u whether your analysis also shows RV= null after 18.45 right up to the last ping?
meadows.st said,
April 2, 2014 at 3:04 pm
All – re: my summary workbook on: Google Docs Link
I have turned on comments (sorry, I thought they were already on) so if you spot any errors, mis-characterizations, inaccuracies, incorrect or incomplete attributions, incomplete thoughts, typos etc. please let me know via this forum or via comments on the document. I am attempting to keep the workbook up to date but the day job comes first. If anyone wants to be a co-editor (I would like to keep the number of editors to less than 5 for practical reasons), please let me know via email.
GuardedDon said,
April 2, 2014 at 3:17 pm
In reply to Alex Siew, April 2, 2014 at 3:01 pm
No Alex, it doesn’t. There’s only three places the radial velocity, relative to I3-F1, can be possible a) when it’s on the ground at WMKK, b) as passes a point on the arc where the tangent is perpendicular to the radial; and c) where it was ultimately lost in the ocean. I don’t subscribe to the diversion around the north-west of Sumatra track.
Did you find anything to suggest that the satcom installation has its own battery supply?
airlandseaman said,
April 2, 2014 at 3:27 pm
Duncan:
Regarding statement in spreadsheet: “Accuracy is within +/- 0.3ms, speed of light = 300,000 km/s. There is a reference (need source) that the ping ranges after the 2am MYT location were all further from the s/c.”
Please note the calibrated accuracy is much better than 300usec. The aircraft equipment delay must be better than 300usec, but it is quite deterministic, and therefore just one more bias component that can be calibrated out with a measurement on the ramp, which we have. So accuracy relative to the calibration point is probably 1-10 usec.
Alex Siew said,
April 2, 2014 at 3:41 pm
@GuardedDon,
No, nothing so far other than what had posted earlier, as regards the battery issue. Dont actually know anything about the transceiver on the plane, not even the brand. MAS did issue a statement to say the plane was using Aero H.
As regards lightning, here are some extracts from the net:
” A positive lightning bolt can strike…. often in areas experiencing clear or slightly cloudy skies; they are also known as ‘bolts from the blue’ for this reason ” [wikipedia]
” Approximately 42% of lightning strikes reported by airline pilots were experienced with no thunderstorms reported in the immediate area by the pilots ” [Boeing's website]
meadows.st said,
April 2, 2014 at 3:53 pm
airlandseaman said,
April 2, 2014 at 3:27 pm
“Duncan:”
Please note that any errors in spreadsheet are my (meadows.st) fault and if there is any credit to be given (for information that is error-free, accurate and brilliant) I endeavor to provide accurate references and links to source materials if possible (in other words, the blame is mine and the credit is not)
.
Alex Siew said,
April 2, 2014 at 5:30 pm
@jcollins,
You said “oil slicks were tested for jet fuel and none found”. Unfortunately one of the oil slicks sighted was not recovered for it to be tested.
On March 10, 2014, the crew from a Cathay Pacific flight reported sighting debris south east off the coast of Vietnam. The crew apparently photographed the debris and noted its coordinates (N9.72, E107.42). One of the pictures is on the internet. This picture shows debris and a long streak of what appears to be a yellowly fluid. The colour is consistent with the reported colour of jetfuel being yellow or strawlike.
Aviation Herald has a report on the follow up to the sighting:
” A Thai cargo ship in the area was asked for assistance and has set course to the area but did not find anything unusual so far. A second vessel asked for assistance did find some debris. Following this finding Vietnam’s Maritime Search & Rescue Services dispatched a ship to the debris field…… Vietnam’s Search & Rescue Center later announced the border guard vessel arriving at the position of the debris field did not find any objects. There were high winds and large waves, the debris possibly drifted away…”
This area off south east of Vietnam in the South China Sea is also not far from the area where a New Zealander on an oil rig reported seeing an object burning in the sky on the night MH370 went missing.
Both these spots are close to or are on the South China Sea part of the arc calculated from the final ping.
This part of the arc has been excluded from the ongoing search for reasons only known to the investigation team and Inmarsat.
AndRand said,
April 3, 2014 at 12:41 am
GuardedDon said,
April 2, 2014 at 3:17 pm
No Alex, it doesn’t. There’s only three places the radial velocity, relative to I3-F1, can be possible a) when it’s on the ground at WMKK, b) as passes a point on the arc where the tangent is perpendicular to the radial; and c) where it was ultimately lost in the ocean. I don’t subscribe to the diversion around the north-west of Sumatra track.
I messed up with zeros, but if you use 900Mhz of AES frequency to calculate doppler shift it quite matches the BFOs from the recorded part of track.
duncansteel said,
April 3, 2014 at 2:19 am
On my website
http://www.duncansteel.com/
I have just put up a post concerning background information on the subject of this thread, including information and graphs covering the conversion from BFO to Doppler shifts as derived most skilfully by @airlandseaman with some assistance from Ari Schulman and myself.
Duncan Steel
Skwosh said,
April 3, 2014 at 2:44 am
@Ole I’m guessing you’ve either given up, or you are busy hacking something together yourself!
Skwosh said,
April 3, 2014 at 2:56 am
@airlandseman
If I understand your method correctly, then if the aircraft is applying *any* Doppler correction to its transmissions then I think your method must be flawed.
[1] You tell us that any Doppler correction that the aircraft may have been applying is reported (digitally) in its transmission and would be known to Inmarsat. However, you also say that you believe that the burst frequency offset (BFO) data published by Inmarsat corresponds to an actual raw measurement of frequency on the ground – so in your view the BFO must still *include* any aircraft Doppler correction.
[2] How, then, can you use this number (the published BFO) to calculate anything if you believe that the BFO still includes an *unknown* (to us) Doppler correction?
[3] If instead you believe that Inmarsat have already removed the aircraft’s Doppler correction before presenting us with the BFO then your interpretation of the BFO as an actual raw frequency *measurement* at the ground surely cannot be correct.
[4] The only way that I can reconcile your assumption about the BFO as a raw frequency measurement with the very simple method that you are using to calculate the aircraft-satellite relative Doppler (D2 in the Inmarsat diagram) is to conclude that you *must* be assuming that the aircraft is not applying *any* Doppler compensation at all.
Are you indeed assuming that the aircraft is not applying any Doppler corrections to its transmissions?
Any thoughts you have on this that could help me understand better would be much appreciated.
Annette said,
April 3, 2014 at 3:01 am
Please note that the table of ping times & co-ords posted by Fitzcarraldo on March 26th & repeated by Hal on April 2nd contains an error. The longitude for the last ping time (oo:11 UTC) is 64.471. Duncan’s original post on March 26th contains the correct value.
Skwosh said,
April 3, 2014 at 3:47 am
Sorry – another very long post.
I have some thoughts (well, to be exact six numbered thoughts!) regarding interpretation of the Inmarsat ‘D1 D2 D3′ diagram – the diagram can be found, among other places, here : http://www.inmarsat.com/news/malaysian-government-publishes-mh370-details-uk-aaib/ .
All feedback – including engineers explaining to me why I’m being an idiot etc. entirely welcome. I am reasonably good at coping with being wrong because it happens to me all the time!
[Thought 1]: I think the aircraft is actively trying to correct for the Doppler shift that occurs between itself and the satellite (so it is trying to correct for D2 in the Inmarsat diagram).
Justification: There is surely some sort of *correction* going on in the system because the word “correction” is used in the red circle on the Inmarsat diagram. We also have several claims by contributors that the aircraft do indeed make active Doppler corrections to the signals that they transmit.
Presumably the whole point of having the aircraft do active correction in the system is so that the frequencies incoming to the satellite (from the aircraft) will all be as close as possible to the target channel base frequency irrespective of how the transmitting aircraft are moving – the smaller the variation in the incoming frequencies the smaller the amount of bandwidth that has to be devoted to a single channel (hope my terminology is OK here – I’m thinking ‘band’ is a bit of available spectrum which is then divvied up into ‘channels’ – the more channels you can fit in the better).
In further support of the idea that there is active correction by the aircraft I’ll quote the following earlier comments:
@timfarrar said (March 26, 2014 at 6:33 am): “[...] As Don points out, there is Doppler correction going on in the terminal (indeed the Malaysian explanatory chart specifically calls out the correction that’s already happening for the speed of the plane) [...]”
@Ole said (March 29, 2014 at 4:21 am): “[...] Modern Aero-C terminals do [Doppler compensation] by using GPS position and speed: http://www.ttvms.com/sitecore/content/www,-d-,thrane,-d-,com/Aero/Products/Aero-C.aspx Quote: ‘The integrated GPS receiver calculates your exact position, altitude, speed and heading every second, used for automatic Doppler compensation …’ [...]”
[Thought 2]: I suspect that D1 in the diagram doesn’t actually represent a Doppler shift – I think it may instead represent the (above proposed) active frequency correction that is being applied by the aircraft in order to try to compensate for the subsequent actual Doppler shift in the system.
Justification: D1 in the diagram does not make sense as an actual physical Doppler shift because a Doppler shift happens when a signal is transmitted *from* a transmitter *to* a receiver, and the size and sign of a Doppler shift depends on the relative velocity along the line of sight between the transmitter and the receiver. It is meaningless to say that a moving transmitter (the aircraft in the case of the diagram) ‘has’ a Doppler shift all by itself – you can only say what the Doppler shift will be when you specify *where* the receiver is and how the receiver is *moving*. I think there are only *two* actual Doppler shifts illustrated in the diagram (because there are only two transmission *paths* in the diagram) and these two Doppler shifts are D2 and D3.
[Thought 3]: I think the Inmarsat diagram is (sensibly) glossing over the fixed frequency shift (the L-band to C-band conversion) that the satellite applies when relaying to the ground.
Justification: This allows the diagram to refer to D1 + D2 + D3 as a meaningful quantity. In their simplified scheme the bass frequency transmitted by the aircraft will have been shifted by D1 (aircraft correction before transmission) + D2 (Doppler from aircraft to satellite) + D3 (Doppler from satellite to ground station).
[Thought 4]: I don’t think there is really any need for the aircraft to also try to actively correct for the satellite to ground Doppler (D3).
Justification: If the satellite to ground Doppler (D3) component is well understood and completely predictable (as we all believe it is) then there is no point in adding extra complication to the systems on the aircraft to try to correct for it. The D3 corrections could presumably all be built into the ground station because the D3 Doppler shift is known and will be linear across the frequency spectrum (F->F*(1+D)).
[Thought 5]: I think the corrections the aircraft are making are good, but that they are *not* perfect.
Justification: If the correction by the aircraft for the Doppler along the path between the satellite and the aircraft (D2) were *perfect* then all signals arriving at the satellite (from the aircraft) would be bang on channel centre and the only measurable frequency variation in the system would be at the ground, and that would be entirely due to D3 and would contain *no* useful information about the motion of the aircraft.
It also seems to me that much of the *point* of the Inmarsat diagram is to illustrate that (a) the *imperfectness* of the corrections is leaving some useful information about the aircraft velocity in an actual *measurable* frequency somewhere in the system that was recorded (hence the phrase “not corrected by system = *measured* frequency offset” in the red circle) and (b) the imperfection of the correction is in some way related to the fact that the satellite moves.
[Thought 6]: I think that if we do not know the correction the aircraft was making then unfortunately we can’t make much use of the published burst frequency offset (BFO) values if they still include these unknown corrections.
Justification: More or less self-evident. If the BFO (which is the only number we have) includes an *unknown* correction that was added by the aircraft in addition to the D2 and D3 Doppler offsets then we can’t deduce anything very much at all from the BFO about D2 without knowing what the unknown aircraft correction might have been.
—
OK – that’s my long ranty list of thoughts.
My bottom line here though – at the moment – is that unless we are prepared to make a *guess* at what the aircraft Doppler correction process is then we can’t make much use of the BFO data.
MtKlimber said,
April 3, 2014 at 5:00 am
If I am reading the chart correctly, the Doppler plot attributed to Airlandseaman and reproduced by duncansteel (See link April 3, 2014 at 2:19 am) shows the Doppler due to spacecraft motion to be essentially negligible compared to the Doppler due to aircraft motion.
If this is true, then I would think spacecraft motion would induce negligible asymmetry in the Doppler signal patterns for north and south tracks. Yet Inmarsat says there is a large asymmetry. Who is correct?
Can someone with the savvy to do so please do an independent order-of-magnitude check on Airlandseaman’s Doppler due to spacecraft motion?
Annette said,
April 3, 2014 at 5:03 am
Please note that the table of ping times & satellite co-ords posted by Fitzcarraldo on March 26th & repeated by Hal on April 2nd contains an error. The longitude for the last ping time (00:11 UTC) is 64.471. Duncan’s original post on March 26th contains the correct value.
Skwosh said,
April 3, 2014 at 8:26 am
@MtKlimber
Agreed absolutely.
I think it would be very helpful if @duncansteel could release a table of the line-of-sight velocities between the ground station and the satellite (for the relevant times) using his excellent STK model.
I believe he has already provided this information to @airlandseaman (my apologies to Duncan if he has already put this information in the public domain and I missed it.)
AndRand said,
April 3, 2014 at 8:28 am
AndRand said,
April 3, 2014 at 12:41 am
if you use 900Mhz of AES frequency to calculate doppler shift it quite matches the BFOs from the recorded part of track.
I have to update this statement: it fits the planned flightlog https://flightaware.com/live/flight/MAS370/history/20140307/1635Z/WMKK/ZBAA/tracklog
With flightlog updated to this guestimation http://skyvector.com/?ll=4.746514696181505,98.71435545889493&chart=302&zoom=9&plan=A.WM.WMKK:F.WM.GUNBO:G.5.7530039670591675,103.1850585976314:F.WS.IGARI:F.WM.GUNIP:F.WM.VAMPI there is significant difference:
[img]http://i.imgur.com/LAUjjoR.png[/img]
My version of Hamster3null spreadshet here: https://docs.google.com/spreadsheet/ccc?key=0AhvpxNRGOuapdERwQ0hPdzlnVDE4djRBWVM2dURVMXc&usp=sharing
AndRand said,
April 3, 2014 at 8:55 am
btw. co-editing – I vote for another blog post to start new thread of comments :thumbup:
Ole said,
April 3, 2014 at 9:10 am
@Skwosh
not given up yet. I posted the following on Duncan’s site, put being in NZ he’s probably asleep so my comment is awaiting his moderation:
———————————————————–
Hi,
I’m puzzled ….
My understanding of Mike Exners charts is that the BFO in the inmarsat graph actually represent the Total Doppler. From there Mike subtracts D3 (C-Band Doppler) and D2 (S/C induced L-Band Doppler) and gets to D1. The red circle in the inmarsat slide suggests somehow that only D2 is plotted in the inmarsat graph while actually the Total Doppler appears to be plotted.
The D2 contribution (S/C induced L-Band Doppler) is very small i.e. in the range of 5Hz. With my primitive vector algebra and the sat position/velocity data Duncan provided, I calculated LOS speed (S/C) – (position of A/C) :
a) 0.0010 km/s at 16:30 at the ramp in KUL (=> 5Hz L-Band doppler)
b) -0.0087 km/s at 0:11 at an estimated final position -32° 92° somewhere close to the Australian search area west of Perth.
b) also is a good match for the LOS velocity S/C – Perth at 0:11 which I calculate as -0.0084 km/s. That LOS velocity matches the C-Band doppler of 100Hz Mike puts for that time in his graph.
Maybe Duncan and Mike can double check the absolute LOS velocity of the S/C in the direction of the aircraft’s estimated position for times after 19:30 UTC (3:30 local). According to my calculations the S/C induced L-Band doppler should rise to ~40Hz and not to only ~5Hz as per Mike’s graph. That is backed up by the consideration that the C-Band doppler rises to 100Hz (=>8.4 m/s LOS velocity). Because at the end of the flight aircraft position is close to Perth, the LOS velocity (S/C )- (position of A/C) should be similar to LOS velocity S/C – Perth .
The next mystery: According to Mike’s conclusions the asymmetries between north and south track can only be introduced by the S/C motion and position. Everything else is independent of the aircraft’s position. At the times when the S/C induced L-Band Doppler is smallest in Mike’s graph, the asymmetries between predicted north and south track are biggest. How can that be?
Regards
Ole
P.S.:
My way to calculate the LOS velocities of the S/C is:
- Convert lat,long,alt to ECEF =>pos vector
- get LOS vector by subtracting pos vector from sat_pos vector in ECEF coordinates
- normalize LOS vector
- calculate inner product of normalized LOS_vector * sat_velocity vector.
——————————————————-
The bottom line is Mike’s calculation somehow make sense, yet IMHO it is the exact opposite of what Inmarsat describes in their first slide on how they were doing their analysis. And it makes no sense not to remove the C-Band doppler from that BFO-chart and the slight asymmetries introduced by the sat’s motion can IMHO not account for the asymmetries in predicted north/south part. OTOH my model, that the BFO at the end of the flight is mainly attributed to the (uncompensated) motion of the satellite doesn’t hold water either.
From my calculations I doubt the LOS speed sat- aircraft at the ramp in KUL had been 21m/s. Imagine the dimension :
-earth radius ~ 6000 km
-orbit radius ~ 42000 km
From the sat velocity in z-direction (north-south) you will never see more than ~6000/42000=1/7 as LOS velocity on the ground.
I can get a grasp on the geometry when I imagine cutting a tomato into slices. Imagine the tomato (earth) on the extreme left of the cutting board and the sat on the extreme right. The cuts through the tomato represent rings of equal distance to the sat (ping arcs). For me it’s easier to imagine the motion of the sat as the sat being stationary and slightly turning the tomato to the left or right. Now I can imagine which parts of the rings/slices move faster and which slower.
airlandseaman said,
April 3, 2014 at 9:43 am
The frequency is 1643 up and 3615 down. There is no 900 MHz involved.
I ahve also been skeptical of the s/c induced L band Doppler. It should be a bit larger, I think. But it is based on rough assumptions in the spreadsheet that can be replaced with real numbers, as soon as Duncan drops them in from his model. In any event, STK does not need to use these values. It only needs the S/C to A/C RR, which the Total L band provides. That part is solid.
Mike
duncansteel said,
April 3, 2014 at 9:48 am
@MyKlimber:
“If I am reading the chart correctly, the Doppler plot attributed to Airlandseaman and reproduced by duncansteel (See link April 3, 2014 at 2:19 am) shows the Doppler due to spacecraft motion to be essentially negligible compared to the Doppler due to aircraft motion.”
That is true when the aircraft is close to the equator, only.
Once the aircraft moves north or south after 18:30 or so, because the satellite is moving south consistently through to 00:11 (and accelerating N-S all that time) the satellite’s speed either adds to the aircraft speed if it were heading north; or subtracts from the aircraft speed if it were heading south; in terms of LOS speeds hence Doppler shifts. Get it? As I’ve noted elsewhere, the aircraft was either moving northwards at a low-ish speed, or moving south at a high-ish speed; say 250 knots and 450 knots as ballpark figures. Hence the asymmetry.
Duncan
duncansteel said,
April 3, 2014 at 9:53 am
It was asked:
“I think it would be very helpful if @duncansteel could release a table of the line-of-sight velocities between the ground station and the satellite (for the relevant times) using his excellent STK model.”
Here are the AER positions Inmarsat-3F1 to Perth ground station; email me via my website telling me your email address for a .csv file.
Velocities follow this message/comment.
01 Apr 2014 18:56:01
Satellite-Inmarsat-3F1-To-Place-Perth_LES: Inview Azimuth, Elevation, & Range
Inmarsat-3F1-To-Perth_LES – AER reported in the object’s default AER frame
————————————————————————–
Time (UTCG) Azimuth (deg) Elevation (deg) Range (km)
———————– ————- ————— ————
7 Mar 2014 16:41:00.000 39.975 -82.032 39238.646835
7 Mar 2014 16:42:00.000 39.972 -82.032 39239.043483
7 Mar 2014 16:43:00.000 39.969 -82.032 39239.438388
7 Mar 2014 16:44:00.000 39.966 -82.031 39239.831542
7 Mar 2014 16:45:00.000 39.963 -82.031 39240.222938
7 Mar 2014 16:46:00.000 39.960 -82.031 39240.612569
7 Mar 2014 16:47:00.000 39.957 -82.031 39241.000425
7 Mar 2014 16:48:00.000 39.954 -82.031 39241.386500
7 Mar 2014 16:49:00.000 39.951 -82.031 39241.770786
7 Mar 2014 16:50:00.000 39.948 -82.030 39242.153275
7 Mar 2014 16:51:00.000 39.944 -82.030 39242.533959
7 Mar 2014 16:52:00.000 39.941 -82.030 39242.912832
7 Mar 2014 16:53:00.000 39.938 -82.030 39243.289886
7 Mar 2014 16:54:00.000 39.935 -82.030 39243.665112
7 Mar 2014 16:55:00.000 39.931 -82.029 39244.038505
7 Mar 2014 16:56:00.000 39.928 -82.029 39244.410055
7 Mar 2014 16:57:00.000 39.925 -82.029 39244.779757
7 Mar 2014 16:58:00.000 39.921 -82.029 39245.147602
7 Mar 2014 16:59:00.000 39.918 -82.029 39245.513584
7 Mar 2014 17:00:00.000 39.914 -82.028 39245.877695
7 Mar 2014 17:01:00.000 39.911 -82.028 39246.239928
7 Mar 2014 17:02:00.000 39.907 -82.028 39246.600276
7 Mar 2014 17:03:00.000 39.904 -82.028 39246.958731
7 Mar 2014 17:04:00.000 39.900 -82.028 39247.315287
7 Mar 2014 17:05:00.000 39.896 -82.028 39247.669937
7 Mar 2014 17:06:00.000 39.893 -82.027 39248.022674
7 Mar 2014 17:07:00.000 39.889 -82.027 39248.373490
7 Mar 2014 17:08:00.000 39.885 -82.027 39248.722379
7 Mar 2014 17:09:00.000 39.881 -82.027 39249.069335
7 Mar 2014 17:10:00.000 39.878 -82.027 39249.414349
7 Mar 2014 17:11:00.000 39.874 -82.027 39249.757415
7 Mar 2014 17:12:00.000 39.870 -82.026 39250.098528
7 Mar 2014 17:13:00.000 39.866 -82.026 39250.437679
7 Mar 2014 17:14:00.000 39.862 -82.026 39250.774863
7 Mar 2014 17:15:00.000 39.858 -82.026 39251.110072
7 Mar 2014 17:16:00.000 39.854 -82.026 39251.443301
7 Mar 2014 17:17:00.000 39.850 -82.026 39251.774542
7 Mar 2014 17:18:00.000 39.846 -82.025 39252.103789
7 Mar 2014 17:19:00.000 39.842 -82.025 39252.431036
7 Mar 2014 17:20:00.000 39.838 -82.025 39252.756277
7 Mar 2014 17:21:00.000 39.834 -82.025 39253.079504
7 Mar 2014 17:22:00.000 39.830 -82.025 39253.400712
7 Mar 2014 17:23:00.000 39.826 -82.025 39253.719894
7 Mar 2014 17:24:00.000 39.821 -82.024 39254.037045
7 Mar 2014 17:25:00.000 39.817 -82.024 39254.352158
7 Mar 2014 17:26:00.000 39.813 -82.024 39254.665227
7 Mar 2014 17:27:00.000 39.808 -82.024 39254.976245
7 Mar 2014 17:28:00.000 39.804 -82.024 39255.285207
7 Mar 2014 17:29:00.000 39.800 -82.024 39255.592107
7 Mar 2014 17:30:00.000 39.795 -82.024 39255.896939
7 Mar 2014 17:31:00.000 39.791 -82.023 39256.199697
7 Mar 2014 17:32:00.000 39.786 -82.023 39256.500374
7 Mar 2014 17:33:00.000 39.782 -82.023 39256.798966
7 Mar 2014 17:34:00.000 39.777 -82.023 39257.095467
7 Mar 2014 17:35:00.000 39.773 -82.023 39257.389870
7 Mar 2014 17:36:00.000 39.768 -82.023 39257.682170
7 Mar 2014 17:37:00.000 39.764 -82.023 39257.972361
7 Mar 2014 17:38:00.000 39.759 -82.022 39258.260439
7 Mar 2014 17:39:00.000 39.754 -82.022 39258.546396
7 Mar 2014 17:40:00.000 39.750 -82.022 39258.830228
7 Mar 2014 17:41:00.000 39.745 -82.022 39259.111930
7 Mar 2014 17:42:00.000 39.740 -82.022 39259.391495
7 Mar 2014 17:43:00.000 39.736 -82.022 39259.668919
7 Mar 2014 17:44:00.000 39.731 -82.022 39259.944196
7 Mar 2014 17:45:00.000 39.726 -82.021 39260.217321
7 Mar 2014 17:46:00.000 39.721 -82.021 39260.488289
7 Mar 2014 17:47:00.000 39.716 -82.021 39260.757095
7 Mar 2014 17:48:00.000 39.711 -82.021 39261.023732
7 Mar 2014 17:49:00.000 39.706 -82.021 39261.288197
7 Mar 2014 17:50:00.000 39.701 -82.021 39261.550484
7 Mar 2014 17:51:00.000 39.696 -82.021 39261.810589
7 Mar 2014 17:52:00.000 39.691 -82.021 39262.068505
7 Mar 2014 17:53:00.000 39.686 -82.020 39262.324229
7 Mar 2014 17:54:00.000 39.681 -82.020 39262.577756
7 Mar 2014 17:55:00.000 39.676 -82.020 39262.829080
7 Mar 2014 17:56:00.000 39.671 -82.020 39263.078197
7 Mar 2014 17:57:00.000 39.666 -82.020 39263.325103
7 Mar 2014 17:58:00.000 39.661 -82.020 39263.569791
7 Mar 2014 17:59:00.000 39.656 -82.020 39263.812259
7 Mar 2014 18:00:00.000 39.650 -82.020 39264.052502
7 Mar 2014 18:01:00.000 39.645 -82.019 39264.290514
7 Mar 2014 18:02:00.000 39.640 -82.019 39264.526291
7 Mar 2014 18:03:00.000 39.634 -82.019 39264.759829
7 Mar 2014 18:04:00.000 39.629 -82.019 39264.991125
7 Mar 2014 18:05:00.000 39.624 -82.019 39265.220172
7 Mar 2014 18:06:00.000 39.618 -82.019 39265.446967
7 Mar 2014 18:07:00.000 39.613 -82.019 39265.671506
7 Mar 2014 18:08:00.000 39.608 -82.019 39265.893784
7 Mar 2014 18:09:00.000 39.602 -82.019 39266.113798
7 Mar 2014 18:10:00.000 39.597 -82.018 39266.331543
7 Mar 2014 18:11:00.000 39.591 -82.018 39266.547015
7 Mar 2014 18:12:00.000 39.586 -82.018 39266.760210
7 Mar 2014 18:13:00.000 39.580 -82.018 39266.971125
7 Mar 2014 18:14:00.000 39.574 -82.018 39267.179754
7 Mar 2014 18:15:00.000 39.569 -82.018 39267.386096
7 Mar 2014 18:16:00.000 39.563 -82.018 39267.590145
7 Mar 2014 18:17:00.000 39.557 -82.018 39267.791898
7 Mar 2014 18:18:00.000 39.552 -82.018 39267.991351
7 Mar 2014 18:19:00.000 39.546 -82.018 39268.188501
7 Mar 2014 18:20:00.000 39.540 -82.017 39268.383344
7 Mar 2014 18:21:00.000 39.535 -82.017 39268.575876
7 Mar 2014 18:22:00.000 39.529 -82.017 39268.766095
7 Mar 2014 18:23:00.000 39.523 -82.017 39268.953995
7 Mar 2014 18:24:00.000 39.517 -82.017 39269.139575
7 Mar 2014 18:25:00.000 39.511 -82.017 39269.322830
7 Mar 2014 18:26:00.000 39.505 -82.017 39269.503757
7 Mar 2014 18:27:00.000 39.500 -82.017 39269.682354
7 Mar 2014 18:28:00.000 39.494 -82.017 39269.858616
7 Mar 2014 18:29:00.000 39.488 -82.017 39270.032541
7 Mar 2014 18:30:00.000 39.482 -82.017 39270.204126
7 Mar 2014 18:31:00.000 39.476 -82.016 39270.373367
7 Mar 2014 18:32:00.000 39.470 -82.016 39270.540261
7 Mar 2014 18:33:00.000 39.464 -82.016 39270.704806
7 Mar 2014 18:34:00.000 39.458 -82.016 39270.866999
7 Mar 2014 18:35:00.000 39.451 -82.016 39271.026836
7 Mar 2014 18:36:00.000 39.445 -82.016 39271.184315
7 Mar 2014 18:37:00.000 39.439 -82.016 39271.339433
7 Mar 2014 18:38:00.000 39.433 -82.016 39271.492187
7 Mar 2014 18:39:00.000 39.427 -82.016 39271.642575
7 Mar 2014 18:40:00.000 39.421 -82.016 39271.790595
7 Mar 2014 18:41:00.000 39.415 -82.016 39271.936242
7 Mar 2014 18:42:00.000 39.408 -82.016 39272.079516
7 Mar 2014 18:43:00.000 39.402 -82.016 39272.220413
7 Mar 2014 18:44:00.000 39.396 -82.015 39272.358931
7 Mar 2014 18:45:00.000 39.389 -82.015 39272.495068
7 Mar 2014 18:46:00.000 39.383 -82.015 39272.628821
7 Mar 2014 18:47:00.000 39.377 -82.015 39272.760188
7 Mar 2014 18:48:00.000 39.370 -82.015 39272.889167
7 Mar 2014 18:49:00.000 39.364 -82.015 39273.015756
7 Mar 2014 18:50:00.000 39.358 -82.015 39273.139952
7 Mar 2014 18:51:00.000 39.351 -82.015 39273.261754
7 Mar 2014 18:52:00.000 39.345 -82.015 39273.381159
7 Mar 2014 18:53:00.000 39.338 -82.015 39273.498165
7 Mar 2014 18:54:00.000 39.332 -82.015 39273.612771
7 Mar 2014 18:55:00.000 39.325 -82.015 39273.724975
7 Mar 2014 18:56:00.000 39.319 -82.015 39273.834774
7 Mar 2014 18:57:00.000 39.312 -82.015 39273.942168
7 Mar 2014 18:58:00.000 39.306 -82.015 39274.047153
7 Mar 2014 18:59:00.000 39.299 -82.015 39274.149730
7 Mar 2014 19:00:00.000 39.292 -82.015 39274.249895
7 Mar 2014 19:01:00.000 39.286 -82.014 39274.347648
7 Mar 2014 19:02:00.000 39.279 -82.014 39274.442986
7 Mar 2014 19:03:00.000 39.272 -82.014 39274.535909
7 Mar 2014 19:04:00.000 39.266 -82.014 39274.626415
7 Mar 2014 19:05:00.000 39.259 -82.014 39274.714503
7 Mar 2014 19:06:00.000 39.252 -82.014 39274.800171
7 Mar 2014 19:07:00.000 39.246 -82.014 39274.883418
7 Mar 2014 19:08:00.000 39.239 -82.014 39274.964242
7 Mar 2014 19:09:00.000 39.232 -82.014 39275.042643
7 Mar 2014 19:10:00.000 39.225 -82.014 39275.118620
7 Mar 2014 19:11:00.000 39.218 -82.014 39275.192171
7 Mar 2014 19:12:00.000 39.212 -82.014 39275.263295
7 Mar 2014 19:13:00.000 39.205 -82.014 39275.331992
7 Mar 2014 19:14:00.000 39.198 -82.014 39275.398260
7 Mar 2014 19:15:00.000 39.191 -82.014 39275.462098
7 Mar 2014 19:16:00.000 39.184 -82.014 39275.523507
7 Mar 2014 19:17:00.000 39.177 -82.014 39275.582484
7 Mar 2014 19:18:00.000 39.170 -82.014 39275.639030
7 Mar 2014 19:19:00.000 39.163 -82.014 39275.693143
7 Mar 2014 19:20:00.000 39.156 -82.014 39275.744822
7 Mar 2014 19:21:00.000 39.149 -82.014 39275.794069
7 Mar 2014 19:22:00.000 39.142 -82.014 39275.840881
7 Mar 2014 19:23:00.000 39.135 -82.014 39275.885258
7 Mar 2014 19:24:00.000 39.128 -82.014 39275.927200
7 Mar 2014 19:25:00.000 39.121 -82.014 39275.966707
7 Mar 2014 19:26:00.000 39.114 -82.014 39276.003778
7 Mar 2014 19:27:00.000 39.107 -82.014 39276.038412
7 Mar 2014 19:28:00.000 39.100 -82.014 39276.070611
7 Mar 2014 19:29:00.000 39.093 -82.014 39276.100373
7 Mar 2014 19:30:00.000 39.086 -82.014 39276.127698
7 Mar 2014 19:31:00.000 39.079 -82.014 39276.152587
7 Mar 2014 19:32:00.000 39.071 -82.014 39276.175038
7 Mar 2014 19:33:00.000 39.064 -82.014 39276.195053
7 Mar 2014 19:34:00.000 39.057 -82.014 39276.212631
7 Mar 2014 19:35:00.000 39.050 -82.014 39276.227773
7 Mar 2014 19:36:00.000 39.043 -82.014 39276.240478
7 Mar 2014 19:37:00.000 39.035 -82.013 39276.250747
7 Mar 2014 19:38:00.000 39.028 -82.013 39276.258580
7 Mar 2014 19:39:00.000 39.021 -82.013 39276.263977
7 Mar 2014 19:40:00.000 39.014 -82.013 39276.266940
7 Mar 2014 19:41:00.000 39.006 -82.013 39276.267467
7 Mar 2014 19:42:00.000 38.999 -82.013 39276.265560
7 Mar 2014 19:43:00.000 38.992 -82.013 39276.261219
7 Mar 2014 19:44:00.000 38.984 -82.013 39276.254444
7 Mar 2014 19:45:00.000 38.977 -82.013 39276.245237
7 Mar 2014 19:46:00.000 38.970 -82.013 39276.233598
7 Mar 2014 19:47:00.000 38.962 -82.013 39276.219527
7 Mar 2014 19:48:00.000 38.955 -82.013 39276.203026
7 Mar 2014 19:49:00.000 38.947 -82.014 39276.184095
7 Mar 2014 19:50:00.000 38.940 -82.014 39276.162735
7 Mar 2014 19:51:00.000 38.933 -82.014 39276.138947
7 Mar 2014 19:52:00.000 38.925 -82.014 39276.112732
7 Mar 2014 19:53:00.000 38.918 -82.014 39276.084091
7 Mar 2014 19:54:00.000 38.910 -82.014 39276.053025
7 Mar 2014 19:55:00.000 38.903 -82.014 39276.019534
7 Mar 2014 19:56:00.000 38.895 -82.014 39275.983621
7 Mar 2014 19:57:00.000 38.888 -82.014 39275.945286
7 Mar 2014 19:58:00.000 38.880 -82.014 39275.904531
7 Mar 2014 19:59:00.000 38.873 -82.014 39275.861357
7 Mar 2014 20:00:00.000 38.865 -82.014 39275.815765
7 Mar 2014 20:01:00.000 38.858 -82.014 39275.767756
7 Mar 2014 20:02:00.000 38.850 -82.014 39275.717333
7 Mar 2014 20:03:00.000 38.842 -82.014 39275.664496
7 Mar 2014 20:04:00.000 38.835 -82.014 39275.609247
7 Mar 2014 20:05:00.000 38.827 -82.014 39275.551588
7 Mar 2014 20:06:00.000 38.820 -82.014 39275.491519
7 Mar 2014 20:07:00.000 38.812 -82.014 39275.429044
7 Mar 2014 20:08:00.000 38.804 -82.014 39275.364164
7 Mar 2014 20:09:00.000 38.797 -82.014 39275.296880
7 Mar 2014 20:10:00.000 38.789 -82.014 39275.227194
7 Mar 2014 20:11:00.000 38.781 -82.014 39275.155108
7 Mar 2014 20:12:00.000 38.774 -82.014 39275.080624
7 Mar 2014 20:13:00.000 38.766 -82.014 39275.003744
7 Mar 2014 20:14:00.000 38.758 -82.014 39274.924470
7 Mar 2014 20:15:00.000 38.751 -82.014 39274.842804
7 Mar 2014 20:16:00.000 38.743 -82.014 39274.758748
7 Mar 2014 20:17:00.000 38.735 -82.014 39274.672304
7 Mar 2014 20:18:00.000 38.728 -82.014 39274.583474
7 Mar 2014 20:19:00.000 38.720 -82.014 39274.492262
7 Mar 2014 20:20:00.000 38.712 -82.014 39274.398668
7 Mar 2014 20:21:00.000 38.704 -82.014 39274.302695
7 Mar 2014 20:22:00.000 38.697 -82.014 39274.204346
7 Mar 2014 20:23:00.000 38.689 -82.014 39274.103624
7 Mar 2014 20:24:00.000 38.681 -82.014 39274.000529
7 Mar 2014 20:25:00.000 38.673 -82.015 39273.895066
7 Mar 2014 20:26:00.000 38.666 -82.015 39273.787236
7 Mar 2014 20:27:00.000 38.658 -82.015 39273.677042
7 Mar 2014 20:28:00.000 38.650 -82.015 39273.564488
7 Mar 2014 20:29:00.000 38.642 -82.015 39273.449575
7 Mar 2014 20:30:00.000 38.634 -82.015 39273.332306
7 Mar 2014 20:31:00.000 38.627 -82.015 39273.212684
7 Mar 2014 20:32:00.000 38.619 -82.015 39273.090713
7 Mar 2014 20:33:00.000 38.611 -82.015 39272.966393
7 Mar 2014 20:34:00.000 38.603 -82.015 39272.839730
7 Mar 2014 20:35:00.000 38.595 -82.015 39272.710726
7 Mar 2014 20:36:00.000 38.587 -82.015 39272.579383
7 Mar 2014 20:37:00.000 38.579 -82.015 39272.445705
7 Mar 2014 20:38:00.000 38.572 -82.015 39272.309695
7 Mar 2014 20:39:00.000 38.564 -82.015 39272.171356
7 Mar 2014 20:40:00.000 38.556 -82.015 39272.030691
7 Mar 2014 20:41:00.000 38.548 -82.015 39271.887704
7 Mar 2014 20:42:00.000 38.540 -82.016 39271.742398
7 Mar 2014 20:43:00.000 38.532 -82.016 39271.594775
7 Mar 2014 20:44:00.000 38.524 -82.016 39271.444840
7 Mar 2014 20:45:00.000 38.516 -82.016 39271.292597
7 Mar 2014 20:46:00.000 38.508 -82.016 39271.138047
7 Mar 2014 20:47:00.000 38.501 -82.016 39270.981195
7 Mar 2014 20:48:00.000 38.493 -82.016 39270.822045
7 Mar 2014 20:49:00.000 38.485 -82.016 39270.660599
7 Mar 2014 20:50:00.000 38.477 -82.016 39270.496863
7 Mar 2014 20:51:00.000 38.469 -82.016 39270.330839
7 Mar 2014 20:52:00.000 38.461 -82.016 39270.162531
7 Mar 2014 20:53:00.000 38.453 -82.016 39269.991942
7 Mar 2014 20:54:00.000 38.445 -82.016 39269.819078
7 Mar 2014 20:55:00.000 38.437 -82.017 39269.643941
7 Mar 2014 20:56:00.000 38.429 -82.017 39269.466535
7 Mar 2014 20:57:00.000 38.421 -82.017 39269.286865
7 Mar 2014 20:58:00.000 38.413 -82.017 39269.104934
7 Mar 2014 20:59:00.000 38.405 -82.017 39268.920746
7 Mar 2014 21:00:00.000 38.397 -82.017 39268.734306
7 Mar 2014 21:01:00.000 38.389 -82.017 39268.545617
7 Mar 2014 21:02:00.000 38.381 -82.017 39268.354684
7 Mar 2014 21:03:00.000 38.373 -82.017 39268.161511
7 Mar 2014 21:04:00.000 38.365 -82.017 39267.966102
7 Mar 2014 21:05:00.000 38.357 -82.017 39267.768462
7 Mar 2014 21:06:00.000 38.349 -82.018 39267.568594
7 Mar 2014 21:07:00.000 38.342 -82.018 39267.366504
7 Mar 2014 21:08:00.000 38.334 -82.018 39267.162195
7 Mar 2014 21:09:00.000 38.326 -82.018 39266.955671
7 Mar 2014 21:10:00.000 38.318 -82.018 39266.746939
7 Mar 2014 21:11:00.000 38.310 -82.018 39266.536001
7 Mar 2014 21:12:00.000 38.302 -82.018 39266.322863
7 Mar 2014 21:13:00.000 38.294 -82.018 39266.107529
7 Mar 2014 21:14:00.000 38.286 -82.018 39265.890004
7 Mar 2014 21:15:00.000 38.278 -82.018 39265.670293
7 Mar 2014 21:16:00.000 38.270 -82.019 39265.448399
7 Mar 2014 21:17:00.000 38.262 -82.019 39265.224329
7 Mar 2014 21:18:00.000 38.254 -82.019 39264.998086
7 Mar 2014 21:19:00.000 38.246 -82.019 39264.769677
7 Mar 2014 21:20:00.000 38.238 -82.019 39264.539104
7 Mar 2014 21:21:00.000 38.230 -82.019 39264.306375
7 Mar 2014 21:22:00.000 38.222 -82.019 39264.071493
7 Mar 2014 21:23:00.000 38.214 -82.019 39263.834463
7 Mar 2014 21:24:00.000 38.206 -82.019 39263.595291
7 Mar 2014 21:25:00.000 38.198 -82.019 39263.353981
7 Mar 2014 21:26:00.000 38.190 -82.020 39263.110540
7 Mar 2014 21:27:00.000 38.182 -82.020 39262.864971
7 Mar 2014 21:28:00.000 38.174 -82.020 39262.617281
7 Mar 2014 21:29:00.000 38.166 -82.020 39262.367473
7 Mar 2014 21:30:00.000 38.158 -82.020 39262.115555
7 Mar 2014 21:31:00.000 38.150 -82.020 39261.861531
7 Mar 2014 21:32:00.000 38.142 -82.020 39261.605406
7 Mar 2014 21:33:00.000 38.134 -82.020 39261.347185
7 Mar 2014 21:34:00.000 38.126 -82.021 39261.086876
7 Mar 2014 21:35:00.000 38.118 -82.021 39260.824481
7 Mar 2014 21:36:00.000 38.110 -82.021 39260.560008
7 Mar 2014 21:37:00.000 38.102 -82.021 39260.293462
7 Mar 2014 21:38:00.000 38.094 -82.021 39260.024848
7 Mar 2014 21:39:00.000 38.086 -82.021 39259.754173
7 Mar 2014 21:40:00.000 38.078 -82.021 39259.481440
7 Mar 2014 21:41:00.000 38.070 -82.021 39259.206658
7 Mar 2014 21:42:00.000 38.062 -82.022 39258.929830
7 Mar 2014 21:43:00.000 38.054 -82.022 39258.650964
7 Mar 2014 21:44:00.000 38.046 -82.022 39258.370064
7 Mar 2014 21:45:00.000 38.039 -82.022 39258.087136
7 Mar 2014 21:46:00.000 38.031 -82.022 39257.802187
7 Mar 2014 21:47:00.000 38.023 -82.022 39257.515222
7 Mar 2014 21:48:00.000 38.015 -82.022 39257.226248
7 Mar 2014 21:49:00.000 38.007 -82.023 39256.935270
7 Mar 2014 21:50:00.000 37.999 -82.023 39256.642294
7 Mar 2014 21:51:00.000 37.991 -82.023 39256.347327
7 Mar 2014 21:52:00.000 37.983 -82.023 39256.050374
7 Mar 2014 21:53:00.000 37.975 -82.023 39255.751442
7 Mar 2014 21:54:00.000 37.967 -82.023 39255.450537
7 Mar 2014 21:55:00.000 37.959 -82.023 39255.147665
7 Mar 2014 21:56:00.000 37.952 -82.024 39254.842832
7 Mar 2014 21:57:00.000 37.944 -82.024 39254.536044
7 Mar 2014 21:58:00.000 37.936 -82.024 39254.227309
7 Mar 2014 21:59:00.000 37.928 -82.024 39253.916631
7 Mar 2014 22:00:00.000 37.920 -82.024 39253.604019
7 Mar 2014 22:01:00.000 37.912 -82.024 39253.289477
7 Mar 2014 22:02:00.000 37.904 -82.024 39252.973013
7 Mar 2014 22:03:00.000 37.897 -82.025 39252.654632
7 Mar 2014 22:04:00.000 37.889 -82.025 39252.334342
7 Mar 2014 22:05:00.000 37.881 -82.025 39252.012149
7 Mar 2014 22:06:00.000 37.873 -82.025 39251.688059
7 Mar 2014 22:07:00.000 37.865 -82.025 39251.362080
7 Mar 2014 22:08:00.000 37.857 -82.025 39251.034218
7 Mar 2014 22:09:00.000 37.850 -82.026 39250.704479
7 Mar 2014 22:10:00.000 37.842 -82.026 39250.372870
7 Mar 2014 22:11:00.000 37.834 -82.026 39250.039398
7 Mar 2014 22:12:00.000 37.826 -82.026 39249.704070
7 Mar 2014 22:13:00.000 37.819 -82.026 39249.366893
7 Mar 2014 22:14:00.000 37.811 -82.026 39249.027872
7 Mar 2014 22:15:00.000 37.803 -82.026 39248.687016
7 Mar 2014 22:16:00.000 37.795 -82.027 39248.344331
7 Mar 2014 22:17:00.000 37.788 -82.027 39247.999825
7 Mar 2014 22:18:00.000 37.780 -82.027 39247.653503
7 Mar 2014 22:19:00.000 37.772 -82.027 39247.305374
7 Mar 2014 22:20:00.000 37.764 -82.027 39246.955443
7 Mar 2014 22:21:00.000 37.757 -82.027 39246.603719
7 Mar 2014 22:22:00.000 37.749 -82.028 39246.250208
7 Mar 2014 22:23:00.000 37.741 -82.028 39245.894917
7 Mar 2014 22:24:00.000 37.734 -82.028 39245.537854
7 Mar 2014 22:25:00.000 37.726 -82.028 39245.179025
7 Mar 2014 22:26:00.000 37.718 -82.028 39244.818438
7 Mar 2014 22:27:00.000 37.711 -82.029 39244.456101
7 Mar 2014 22:28:00.000 37.703 -82.029 39244.092020
7 Mar 2014 22:29:00.000 37.695 -82.029 39243.726203
7 Mar 2014 22:30:00.000 37.688 -82.029 39243.358657
7 Mar 2014 22:31:00.000 37.680 -82.029 39242.989388
7 Mar 2014 22:32:00.000 37.673 -82.029 39242.618406
7 Mar 2014 22:33:00.000 37.665 -82.030 39242.245718
7 Mar 2014 22:34:00.000 37.658 -82.030 39241.871329
7 Mar 2014 22:35:00.000 37.650 -82.030 39241.495249
7 Mar 2014 22:36:00.000 37.642 -82.030 39241.117485
7 Mar 2014 22:37:00.000 37.635 -82.030 39240.738043
7 Mar 2014 22:38:00.000 37.627 -82.031 39240.356933
7 Mar 2014 22:39:00.000 37.620 -82.031 39239.974160
7 Mar 2014 22:40:00.000 37.612 -82.031 39239.589734
7 Mar 2014 22:41:00.000 37.605 -82.031 39239.203661
7 Mar 2014 22:42:00.000 37.597 -82.031 39238.815950
7 Mar 2014 22:43:00.000 37.590 -82.031 39238.426607
7 Mar 2014 22:44:00.000 37.582 -82.032 39238.035641
7 Mar 2014 22:45:00.000 37.575 -82.032 39237.643060
7 Mar 2014 22:46:00.000 37.568 -82.032 39237.248870
7 Mar 2014 22:47:00.000 37.560 -82.032 39236.853081
7 Mar 2014 22:48:00.000 37.553 -82.032 39236.455699
7 Mar 2014 22:49:00.000 37.545 -82.033 39236.056733
7 Mar 2014 22:50:00.000 37.538 -82.033 39235.656191
7 Mar 2014 22:51:00.000 37.531 -82.033 39235.254080
7 Mar 2014 22:52:00.000 37.523 -82.033 39234.850408
7 Mar 2014 22:53:00.000 37.516 -82.033 39234.445184
7 Mar 2014 22:54:00.000 37.509 -82.034 39234.038415
7 Mar 2014 22:55:00.000 37.501 -82.034 39233.630110
7 Mar 2014 22:56:00.000 37.494 -82.034 39233.220276
7 Mar 2014 22:57:00.000 37.487 -82.034 39232.808921
7 Mar 2014 22:58:00.000 37.480 -82.034 39232.396054
7 Mar 2014 22:59:00.000 37.472 -82.035 39231.981682
7 Mar 2014 23:00:00.000 37.465 -82.035 39231.565814
7 Mar 2014 23:01:00.000 37.458 -82.035 39231.148459
7 Mar 2014 23:02:00.000 37.451 -82.035 39230.729623
7 Mar 2014 23:03:00.000 37.443 -82.035 39230.309315
7 Mar 2014 23:04:00.000 37.436 -82.036 39229.887544
7 Mar 2014 23:05:00.000 37.429 -82.036 39229.464318
7 Mar 2014 23:06:00.000 37.422 -82.036 39229.039645
7 Mar 2014 23:07:00.000 37.415 -82.036 39228.613533
7 Mar 2014 23:08:00.000 37.408 -82.036 39228.185991
7 Mar 2014 23:09:00.000 37.401 -82.037 39227.757027
7 Mar 2014 23:10:00.000 37.394 -82.037 39227.326649
7 Mar 2014 23:11:00.000 37.386 -82.037 39226.894867
7 Mar 2014 23:12:00.000 37.379 -82.037 39226.461687
7 Mar 2014 23:13:00.000 37.372 -82.037 39226.027119
7 Mar 2014 23:14:00.000 37.364 -82.038 39225.933879
7 Mar 2014 23:15:00.000 37.357 -82.038 39225.495512
7 Mar 2014 23:16:00.000 37.350 -82.038 39225.055779
7 Mar 2014 23:17:00.000 37.343 -82.038 39224.614690
7 Mar 2014 23:18:00.000 37.336 -82.038 39224.172252
7 Mar 2014 23:19:00.000 37.329 -82.039 39223.728474
7 Mar 2014 23:20:00.000 37.322 -82.039 39223.283364
7 Mar 2014 23:21:00.000 37.316 -82.039 39222.836932
7 Mar 2014 23:22:00.000 37.309 -82.039 39222.389186
7 Mar 2014 23:23:00.000 37.302 -82.039 39221.940134
7 Mar 2014 23:24:00.000 37.295 -82.040 39221.489786
7 Mar 2014 23:25:00.000 37.288 -82.040 39221.038150
7 Mar 2014 23:26:00.000 37.281 -82.040 39220.585234
7 Mar 2014 23:27:00.000 37.274 -82.040 39220.131048
7 Mar 2014 23:28:00.000 37.268 -82.041 39219.675600
7 Mar 2014 23:29:00.000 37.261 -82.041 39219.218899
7 Mar 2014 23:30:00.000 37.254 -82.041 39218.760954
7 Mar 2014 23:31:00.000 37.247 -82.041 39218.301774
7 Mar 2014 23:32:00.000 37.241 -82.041 39217.841367
7 Mar 2014 23:33:00.000 37.234 -82.042 39217.379742
7 Mar 2014 23:34:00.000 37.227 -82.042 39216.916909
7 Mar 2014 23:35:00.000 37.221 -82.042 39216.452875
7 Mar 2014 23:36:00.000 37.214 -82.042 39215.987651
7 Mar 2014 23:37:00.000 37.208 -82.043 39215.521245
7 Mar 2014 23:38:00.000 37.201 -82.043 39215.053665
7 Mar 2014 23:39:00.000 37.194 -82.043 39214.584921
7 Mar 2014 23:40:00.000 37.188 -82.043 39214.115022
7 Mar 2014 23:41:00.000 37.181 -82.043 39213.643977
7 Mar 2014 23:42:00.000 37.175 -82.044 39213.171795
7 Mar 2014 23:43:00.000 37.168 -82.044 39212.698485
7 Mar 2014 23:44:00.000 37.162 -82.044 39212.224055
7 Mar 2014 23:45:00.000 37.155 -82.044 39211.748516
7 Mar 2014 23:46:00.000 37.149 -82.045 39211.271875
7 Mar 2014 23:47:00.000 37.143 -82.045 39210.794143
7 Mar 2014 23:48:00.000 37.136 -82.045 39210.315328
7 Mar 2014 23:49:00.000 37.130 -82.045 39209.835440
7 Mar 2014 23:50:00.000 37.123 -82.046 39209.354487
7 Mar 2014 23:51:00.000 37.117 -82.046 39208.872478
7 Mar 2014 23:52:00.000 37.111 -82.046 39208.389424
7 Mar 2014 23:53:00.000 37.104 -82.046 39207.905333
7 Mar 2014 23:54:00.000 37.098 -82.047 39207.420214
7 Mar 2014 23:55:00.000 37.092 -82.047 39206.934077
7 Mar 2014 23:56:00.000 37.086 -82.047 39206.446930
7 Mar 2014 23:57:00.000 37.080 -82.047 39205.958784
7 Mar 2014 23:58:00.000 37.073 -82.047 39205.469646
7 Mar 2014 23:59:00.000 37.067 -82.048 39204.979528
8 Mar 2014 00:00:00.000 37.061 -82.048 39204.488437
8 Mar 2014 00:01:00.000 37.055 -82.048 39203.996383
8 Mar 2014 00:02:00.000 37.049 -82.048 39203.503376
8 Mar 2014 00:03:00.000 37.043 -82.049 39203.009425
8 Mar 2014 00:04:00.000 37.037 -82.049 39202.514538
8 Mar 2014 00:05:00.000 37.031 -82.049 39202.018727
8 Mar 2014 00:06:00.000 37.025 -82.049 39201.521999
8 Mar 2014 00:07:00.000 37.019 -82.050 39201.024364
8 Mar 2014 00:08:00.000 37.013 -82.050 39200.525833
8 Mar 2014 00:09:00.000 37.007 -82.050 39200.026413
8 Mar 2014 00:10:00.000 37.001 -82.050 39199.526115
8 Mar 2014 00:11:00.000 36.995 -82.051 39199.024948
8 Mar 2014 00:12:00.000 36.989 -82.051 39198.522921
Global Statistics
—————–
Min Elevation 8 Mar 2014 00:12:00.000 36.989 -82.051 39198.522921
Max Elevation 7 Mar 2014 19:42:19.716 38.997 -82.013 39276.264402
Mean Elevation -82.024
Min Range 8 Mar 2014 00:12:00.000 36.989 -82.051 39198.522921
Max Range 7 Mar 2014 19:40:42.995 39.008 -82.013 39276.267564
Mean Range 39254.635952
duncansteel said,
April 3, 2014 at 9:54 am
And here are the velocities (cross-beam and LOS/range-rate).
01 Apr 2014 18:57:57
Satellite-Inmarsat-3F1-To-Place-Perth_LES
Time (UTCG) FromAngularRate (deg/sec) RangeRate (km/sec)
———————– ————————- ——————
7 Mar 2014 16:41:00.000 0.004152 0.006618
7 Mar 2014 16:42:00.000 0.004152 0.006589
7 Mar 2014 16:43:00.000 0.004152 0.006559
7 Mar 2014 16:44:00.000 0.004152 0.006530
7 Mar 2014 16:45:00.000 0.004152 0.006501
7 Mar 2014 16:46:00.000 0.004151 0.006471
7 Mar 2014 16:47:00.000 0.004151 0.006442
7 Mar 2014 16:48:00.000 0.004151 0.006412
7 Mar 2014 16:49:00.000 0.004151 0.006382
7 Mar 2014 16:50:00.000 0.004151 0.006352
7 Mar 2014 16:51:00.000 0.004151 0.006322
7 Mar 2014 16:52:00.000 0.004151 0.006292
7 Mar 2014 16:53:00.000 0.004151 0.006261
7 Mar 2014 16:54:00.000 0.004151 0.006231
7 Mar 2014 16:55:00.000 0.004151 0.006200
7 Mar 2014 16:56:00.000 0.004151 0.006169
7 Mar 2014 16:57:00.000 0.004151 0.006138
7 Mar 2014 16:58:00.000 0.004151 0.006107
7 Mar 2014 16:59:00.000 0.004151 0.006076
7 Mar 2014 17:00:00.000 0.004151 0.006045
7 Mar 2014 17:01:00.000 0.004151 0.006014
7 Mar 2014 17:02:00.000 0.004151 0.005982
7 Mar 2014 17:03:00.000 0.004151 0.005951
7 Mar 2014 17:04:00.000 0.004151 0.005919
7 Mar 2014 17:05:00.000 0.004151 0.005887
7 Mar 2014 17:06:00.000 0.004151 0.005855
7 Mar 2014 17:07:00.000 0.004151 0.005823
7 Mar 2014 17:08:00.000 0.004150 0.005791
7 Mar 2014 17:09:00.000 0.004150 0.005759
7 Mar 2014 17:10:00.000 0.004150 0.005726
7 Mar 2014 17:11:00.000 0.004150 0.005694
7 Mar 2014 17:12:00.000 0.004150 0.005661
7 Mar 2014 17:13:00.000 0.004150 0.005628
7 Mar 2014 17:14:00.000 0.004150 0.005595
7 Mar 2014 17:15:00.000 0.004150 0.005562
7 Mar 2014 17:16:00.000 0.004150 0.005529
7 Mar 2014 17:17:00.000 0.004150 0.005496
7 Mar 2014 17:18:00.000 0.004150 0.005463
7 Mar 2014 17:19:00.000 0.004150 0.005429
7 Mar 2014 17:20:00.000 0.004150 0.005396
7 Mar 2014 17:21:00.000 0.004150 0.005362
7 Mar 2014 17:22:00.000 0.004150 0.005329
7 Mar 2014 17:23:00.000 0.004150 0.005295
7 Mar 2014 17:24:00.000 0.004150 0.005261
7 Mar 2014 17:25:00.000 0.004150 0.005227
7 Mar 2014 17:26:00.000 0.004150 0.005193
7 Mar 2014 17:27:00.000 0.004150 0.005159
7 Mar 2014 17:28:00.000 0.004150 0.005124
7 Mar 2014 17:29:00.000 0.004150 0.005090
7 Mar 2014 17:30:00.000 0.004150 0.005055
7 Mar 2014 17:31:00.000 0.004150 0.005021
7 Mar 2014 17:32:00.000 0.004150 0.004986
7 Mar 2014 17:33:00.000 0.004150 0.004951
7 Mar 2014 17:34:00.000 0.004149 0.004916
7 Mar 2014 17:35:00.000 0.004149 0.004881
7 Mar 2014 17:36:00.000 0.004149 0.004846
7 Mar 2014 17:37:00.000 0.004149 0.004811
7 Mar 2014 17:38:00.000 0.004149 0.004776
7 Mar 2014 17:39:00.000 0.004149 0.004740
7 Mar 2014 17:40:00.000 0.004149 0.004705
7 Mar 2014 17:41:00.000 0.004149 0.004669
7 Mar 2014 17:42:00.000 0.004149 0.004634
7 Mar 2014 17:43:00.000 0.004149 0.004598
7 Mar 2014 17:44:00.000 0.004149 0.004562
7 Mar 2014 17:45:00.000 0.004149 0.004526
7 Mar 2014 17:46:00.000 0.004149 0.004490
7 Mar 2014 17:47:00.000 0.004149 0.004454
7 Mar 2014 17:48:00.000 0.004149 0.004418
7 Mar 2014 17:49:00.000 0.004149 0.004382
7 Mar 2014 17:50:00.000 0.004149 0.004345
7 Mar 2014 17:51:00.000 0.004149 0.004309
7 Mar 2014 17:52:00.000 0.004149 0.004272
7 Mar 2014 17:53:00.000 0.004149 0.004236
7 Mar 2014 17:54:00.000 0.004149 0.004199
7 Mar 2014 17:55:00.000 0.004149 0.004162
7 Mar 2014 17:56:00.000 0.004149 0.004125
7 Mar 2014 17:57:00.000 0.004149 0.004089
7 Mar 2014 17:58:00.000 0.004149 0.004052
7 Mar 2014 17:59:00.000 0.004149 0.004015
7 Mar 2014 18:00:00.000 0.004149 0.003977
7 Mar 2014 18:01:00.000 0.004149 0.003940
7 Mar 2014 18:02:00.000 0.004149 0.003903
7 Mar 2014 18:03:00.000 0.004149 0.003866
7 Mar 2014 18:04:00.000 0.004149 0.003828
7 Mar 2014 18:05:00.000 0.004148 0.003791
7 Mar 2014 18:06:00.000 0.004148 0.003753
7 Mar 2014 18:07:00.000 0.004148 0.003715
7 Mar 2014 18:08:00.000 0.004148 0.003678
7 Mar 2014 18:09:00.000 0.004148 0.003640
7 Mar 2014 18:10:00.000 0.004148 0.003602
7 Mar 2014 18:11:00.000 0.004148 0.003564
7 Mar 2014 18:12:00.000 0.004148 0.003526
7 Mar 2014 18:13:00.000 0.004148 0.003488
7 Mar 2014 18:14:00.000 0.004148 0.003450
7 Mar 2014 18:15:00.000 0.004148 0.003412
7 Mar 2014 18:16:00.000 0.004148 0.003374
7 Mar 2014 18:17:00.000 0.004148 0.003335
7 Mar 2014 18:18:00.000 0.004148 0.003297
7 Mar 2014 18:19:00.000 0.004148 0.003258
7 Mar 2014 18:20:00.000 0.004148 0.003220
7 Mar 2014 18:21:00.000 0.004148 0.003181
7 Mar 2014 18:22:00.000 0.004148 0.003143
7 Mar 2014 18:23:00.000 0.004148 0.003104
7 Mar 2014 18:24:00.000 0.004148 0.003065
7 Mar 2014 18:25:00.000 0.004148 0.003027
7 Mar 2014 18:26:00.000 0.004148 0.002988
7 Mar 2014 18:27:00.000 0.004148 0.002949
7 Mar 2014 18:28:00.000 0.004148 0.002910
7 Mar 2014 18:29:00.000 0.004148 0.002871
7 Mar 2014 18:30:00.000 0.004148 0.002832
7 Mar 2014 18:31:00.000 0.004148 0.002793
7 Mar 2014 18:32:00.000 0.004148 0.002754
7 Mar 2014 18:33:00.000 0.004148 0.002715
7 Mar 2014 18:34:00.000 0.004148 0.002675
7 Mar 2014 18:35:00.000 0.004148 0.002636
7 Mar 2014 18:36:00.000 0.004148 0.002597
7 Mar 2014 18:37:00.000 0.004148 0.002557
7 Mar 2014 18:38:00.000 0.004148 0.002518
7 Mar 2014 18:39:00.000 0.004148 0.002479
7 Mar 2014 18:40:00.000 0.004148 0.002439
7 Mar 2014 18:41:00.000 0.004148 0.002399
7 Mar 2014 18:42:00.000 0.004148 0.002360
7 Mar 2014 18:43:00.000 0.004148 0.002320
7 Mar 2014 18:44:00.000 0.004148 0.002281
7 Mar 2014 18:45:00.000 0.004148 0.002241
7 Mar 2014 18:46:00.000 0.004148 0.002201
7 Mar 2014 18:47:00.000 0.004148 0.002161
7 Mar 2014 18:48:00.000 0.004148 0.002122
7 Mar 2014 18:49:00.000 0.004148 0.002082
7 Mar 2014 18:50:00.000 0.004148 0.002042
7 Mar 2014 18:51:00.000 0.004148 0.002002
7 Mar 2014 18:52:00.000 0.004148 0.001962
7 Mar 2014 18:53:00.000 0.004148 0.001922
7 Mar 2014 18:54:00.000 0.004148 0.001882
7 Mar 2014 18:55:00.000 0.004148 0.001842
7 Mar 2014 18:56:00.000 0.004148 0.001802
7 Mar 2014 18:57:00.000 0.004148 0.001762
7 Mar 2014 18:58:00.000 0.004147 0.001721
7 Mar 2014 18:59:00.000 0.004147 0.001681
7 Mar 2014 19:00:00.000 0.004147 0.001641
7 Mar 2014 19:01:00.000 0.004147 0.001601
7 Mar 2014 19:02:00.000 0.004147 0.001561
7 Mar 2014 19:03:00.000 0.004147 0.001520
7 Mar 2014 19:04:00.000 0.004147 0.001480
7 Mar 2014 19:05:00.000 0.004147 0.001440
7 Mar 2014 19:06:00.000 0.004147 0.001399
7 Mar 2014 19:07:00.000 0.004147 0.001359
7 Mar 2014 19:08:00.000 0.004147 0.001319
7 Mar 2014 19:09:00.000 0.004147 0.001278
7 Mar 2014 19:10:00.000 0.004147 0.001238
7 Mar 2014 19:11:00.000 0.004147 0.001197
7 Mar 2014 19:12:00.000 0.004147 0.001157
7 Mar 2014 19:13:00.000 0.004147 0.001116
7 Mar 2014 19:14:00.000 0.004147 0.001076
7 Mar 2014 19:15:00.000 0.004147 0.001035
7 Mar 2014 19:16:00.000 0.004147 0.000995
7 Mar 2014 19:17:00.000 0.004147 0.000954
7 Mar 2014 19:18:00.000 0.004147 0.000914
7 Mar 2014 19:19:00.000 0.004147 0.000873
7 Mar 2014 19:20:00.000 0.004147 0.000833
7 Mar 2014 19:21:00.000 0.004147 0.000792
7 Mar 2014 19:22:00.000 0.004147 0.000752
7 Mar 2014 19:23:00.000 0.004147 0.000711
7 Mar 2014 19:24:00.000 0.004147 0.000671
7 Mar 2014 19:25:00.000 0.004147 0.000630
7 Mar 2014 19:26:00.000 0.004147 0.000589
7 Mar 2014 19:27:00.000 0.004147 0.000549
7 Mar 2014 19:28:00.000 0.004147 0.000508
7 Mar 2014 19:29:00.000 0.004147 0.000467
7 Mar 2014 19:30:00.000 0.004147 0.000427
7 Mar 2014 19:31:00.000 0.004147 0.000386
7 Mar 2014 19:32:00.000 0.004147 0.000346
7 Mar 2014 19:33:00.000 0.004147 0.000305
7 Mar 2014 19:34:00.000 0.004147 0.000264
7 Mar 2014 19:35:00.000 0.004147 0.000224
7 Mar 2014 19:36:00.000 0.004147 0.000183
7 Mar 2014 19:37:00.000 0.004147 0.000143
7 Mar 2014 19:38:00.000 0.004147 0.000102
7 Mar 2014 19:39:00.000 0.004147 0.000061
7 Mar 2014 19:40:00.000 0.004147 0.000021
7 Mar 2014 19:41:00.000 0.004147 -0.000020
7 Mar 2014 19:42:00.000 0.004147 -0.000060
7 Mar 2014 19:43:00.000 0.004147 -0.000101
7 Mar 2014 19:44:00.000 0.004147 -0.000141
7 Mar 2014 19:45:00.000 0.004147 -0.000182
7 Mar 2014 19:46:00.000 0.004147 -0.000222
7 Mar 2014 19:47:00.000 0.004147 -0.000263
7 Mar 2014 19:48:00.000 0.004147 -0.000304
7 Mar 2014 19:49:00.000 0.004147 -0.000344
7 Mar 2014 19:50:00.000 0.004147 -0.000384
7 Mar 2014 19:51:00.000 0.004147 -0.000425
7 Mar 2014 19:52:00.000 0.004147 -0.000465
7 Mar 2014 19:53:00.000 0.004147 -0.000506
7 Mar 2014 19:54:00.000 0.004147 -0.000546
7 Mar 2014 19:55:00.000 0.004147 -0.000587
7 Mar 2014 19:56:00.000 0.004147 -0.000627
7 Mar 2014 19:57:00.000 0.004147 -0.000667
7 Mar 2014 19:58:00.000 0.004147 -0.000708
7 Mar 2014 19:59:00.000 0.004147 -0.000748
7 Mar 2014 20:00:00.000 0.004147 -0.000788
7 Mar 2014 20:01:00.000 0.004147 -0.000828
7 Mar 2014 20:02:00.000 0.004147 -0.000869
7 Mar 2014 20:03:00.000 0.004147 -0.000909
7 Mar 2014 20:04:00.000 0.004147 -0.000949
7 Mar 2014 20:05:00.000 0.004147 -0.000989
7 Mar 2014 20:06:00.000 0.004147 -0.001029
7 Mar 2014 20:07:00.000 0.004147 -0.001070
7 Mar 2014 20:08:00.000 0.004147 -0.001110
7 Mar 2014 20:09:00.000 0.004147 -0.001150
7 Mar 2014 20:10:00.000 0.004148 -0.001190
7 Mar 2014 20:11:00.000 0.004148 -0.001230
7 Mar 2014 20:12:00.000 0.004148 -0.001270
7 Mar 2014 20:13:00.000 0.004148 -0.001309
7 Mar 2014 20:14:00.000 0.004148 -0.001349
7 Mar 2014 20:15:00.000 0.004148 -0.001389
7 Mar 2014 20:16:00.000 0.004148 -0.001429
7 Mar 2014 20:17:00.000 0.004148 -0.001469
7 Mar 2014 20:18:00.000 0.004148 -0.001509
7 Mar 2014 20:19:00.000 0.004148 -0.001548
7 Mar 2014 20:20:00.000 0.004148 -0.001588
7 Mar 2014 20:21:00.000 0.004148 -0.001628
7 Mar 2014 20:22:00.000 0.004148 -0.001667
7 Mar 2014 20:23:00.000 0.004148 -0.001707
7 Mar 2014 20:24:00.000 0.004148 -0.001746
7 Mar 2014 20:25:00.000 0.004148 -0.001786
7 Mar 2014 20:26:00.000 0.004148 -0.001825
7 Mar 2014 20:27:00.000 0.004148 -0.001864
7 Mar 2014 20:28:00.000 0.004148 -0.001904
7 Mar 2014 20:29:00.000 0.004148 -0.001943
7 Mar 2014 20:30:00.000 0.004148 -0.001982
7 Mar 2014 20:31:00.000 0.004148 -0.002021
7 Mar 2014 20:32:00.000 0.004148 -0.002061
7 Mar 2014 20:33:00.000 0.004148 -0.002100
7 Mar 2014 20:34:00.000 0.004148 -0.002139
7 Mar 2014 20:35:00.000 0.004148 -0.002178
7 Mar 2014 20:36:00.000 0.004148 -0.002217
7 Mar 2014 20:37:00.000 0.004148 -0.002256
7 Mar 2014 20:38:00.000 0.004148 -0.002294
7 Mar 2014 20:39:00.000 0.004148 -0.002333
7 Mar 2014 20:40:00.000 0.004148 -0.002372
7 Mar 2014 20:41:00.000 0.004148 -0.002411
7 Mar 2014 20:42:00.000 0.004148 -0.002449
7 Mar 2014 20:43:00.000 0.004148 -0.002488
7 Mar 2014 20:44:00.000 0.004148 -0.002526
7 Mar 2014 20:45:00.000 0.004148 -0.002565
7 Mar 2014 20:46:00.000 0.004148 -0.002603
7 Mar 2014 20:47:00.000 0.004148 -0.002642
7 Mar 2014 20:48:00.000 0.004148 -0.002680
7 Mar 2014 20:49:00.000 0.004148 -0.002718
7 Mar 2014 20:50:00.000 0.004148 -0.002756
7 Mar 2014 20:51:00.000 0.004148 -0.002794
7 Mar 2014 20:52:00.000 0.004148 -0.002832
7 Mar 2014 20:53:00.000 0.004148 -0.002870
7 Mar 2014 20:54:00.000 0.004148 -0.002908
7 Mar 2014 20:55:00.000 0.004148 -0.002946
7 Mar 2014 20:56:00.000 0.004148 -0.002984
7 Mar 2014 20:57:00.000 0.004148 -0.003021
7 Mar 2014 20:58:00.000 0.004148 -0.003059
7 Mar 2014 20:59:00.000 0.004148 -0.003097
7 Mar 2014 21:00:00.000 0.004148 -0.003134
7 Mar 2014 21:01:00.000 0.004148 -0.003172
7 Mar 2014 21:02:00.000 0.004148 -0.003209
7 Mar 2014 21:03:00.000 0.004149 -0.003246
7 Mar 2014 21:04:00.000 0.004149 -0.003284
7 Mar 2014 21:05:00.000 0.004149 -0.003321
7 Mar 2014 21:06:00.000 0.004149 -0.003358
7 Mar 2014 21:07:00.000 0.004149 -0.003395
7 Mar 2014 21:08:00.000 0.004149 -0.003432
7 Mar 2014 21:09:00.000 0.004149 -0.003469
7 Mar 2014 21:10:00.000 0.004149 -0.003505
7 Mar 2014 21:11:00.000 0.004149 -0.003542
7 Mar 2014 21:12:00.000 0.004149 -0.003579
7 Mar 2014 21:13:00.000 0.004149 -0.003615
7 Mar 2014 21:14:00.000 0.004149 -0.003652
7 Mar 2014 21:15:00.000 0.004149 -0.003688
7 Mar 2014 21:16:00.000 0.004149 -0.003724
7 Mar 2014 21:17:00.000 0.004149 -0.003761
7 Mar 2014 21:18:00.000 0.004149 -0.003797
7 Mar 2014 21:19:00.000 0.004149 -0.003833
7 Mar 2014 21:20:00.000 0.004149 -0.003869
7 Mar 2014 21:21:00.000 0.004149 -0.003905
7 Mar 2014 21:22:00.000 0.004149 -0.003941
7 Mar 2014 21:23:00.000 0.004149 -0.003976
7 Mar 2014 21:24:00.000 0.004149 -0.004012
7 Mar 2014 21:25:00.000 0.004149 -0.004048
7 Mar 2014 21:26:00.000 0.004149 -0.004083
7 Mar 2014 21:27:00.000 0.004149 -0.004119
7 Mar 2014 21:28:00.000 0.004149 -0.004154
7 Mar 2014 21:29:00.000 0.004149 -0.004189
7 Mar 2014 21:30:00.000 0.004149 -0.004224
7 Mar 2014 21:31:00.000 0.004149 -0.004259
7 Mar 2014 21:32:00.000 0.004149 -0.004294
7 Mar 2014 21:33:00.000 0.004149 -0.004329
7 Mar 2014 21:34:00.000 0.004149 -0.004364
7 Mar 2014 21:35:00.000 0.004149 -0.004399
7 Mar 2014 21:36:00.000 0.004150 -0.004433
7 Mar 2014 21:37:00.000 0.004150 -0.004468
7 Mar 2014 21:38:00.000 0.004150 -0.004502
7 Mar 2014 21:39:00.000 0.004150 -0.004536
7 Mar 2014 21:40:00.000 0.004150 -0.004571
7 Mar 2014 21:41:00.000 0.004150 -0.004605
7 Mar 2014 21:42:00.000 0.004150 -0.004639
7 Mar 2014 21:43:00.000 0.004150 -0.004673
7 Mar 2014 21:44:00.000 0.004150 -0.004707
7 Mar 2014 21:45:00.000 0.004150 -0.004740
7 Mar 2014 21:46:00.000 0.004150 -0.004774
7 Mar 2014 21:47:00.000 0.004150 -0.004807
7 Mar 2014 21:48:00.000 0.004150 -0.004841
7 Mar 2014 21:49:00.000 0.004150 -0.004874
7 Mar 2014 21:50:00.000 0.004150 -0.004907
7 Mar 2014 21:51:00.000 0.004150 -0.004941
7 Mar 2014 21:52:00.000 0.004150 -0.004974
7 Mar 2014 21:53:00.000 0.004150 -0.005007
7 Mar 2014 21:54:00.000 0.004150 -0.005039
7 Mar 2014 21:55:00.000 0.004150 -0.005072
7 Mar 2014 21:56:00.000 0.004150 -0.005105
7 Mar 2014 21:57:00.000 0.004150 -0.005137
7 Mar 2014 21:58:00.000 0.004150 -0.005170
7 Mar 2014 21:59:00.000 0.004150 -0.005202
7 Mar 2014 22:00:00.000 0.004150 -0.005234
7 Mar 2014 22:01:00.000 0.004150 -0.005266
7 Mar 2014 22:02:00.000 0.004151 -0.005298
7 Mar 2014 22:03:00.000 0.004151 -0.005330
7 Mar 2014 22:04:00.000 0.004151 -0.005362
7 Mar 2014 22:05:00.000 0.004151 -0.005394
7 Mar 2014 22:06:00.000 0.004151 -0.005425
7 Mar 2014 22:07:00.000 0.004151 -0.005457
7 Mar 2014 22:08:00.000 0.004151 -0.005488
7 Mar 2014 22:09:00.000 0.004151 -0.005519
7 Mar 2014 22:10:00.000 0.004151 -0.005550
7 Mar 2014 22:11:00.000 0.004151 -0.005581
7 Mar 2014 22:12:00.000 0.004151 -0.005612
7 Mar 2014 22:13:00.000 0.004151 -0.005643
7 Mar 2014 22:14:00.000 0.004151 -0.005673
7 Mar 2014 22:15:00.000 0.004151 -0.005704
7 Mar 2014 22:16:00.000 0.004151 -0.005734
7 Mar 2014 22:17:00.000 0.004151 -0.005765
7 Mar 2014 22:18:00.000 0.004151 -0.005795
7 Mar 2014 22:19:00.000 0.004151 -0.005825
7 Mar 2014 22:20:00.000 0.004151 -0.005855
7 Mar 2014 22:21:00.000 0.004151 -0.005885
7 Mar 2014 22:22:00.000 0.004151 -0.005914
7 Mar 2014 22:23:00.000 0.004151 -0.005944
7 Mar 2014 22:24:00.000 0.004151 -0.005974
7 Mar 2014 22:25:00.000 0.004152 -0.006003
7 Mar 2014 22:26:00.000 0.004152 -0.006032
7 Mar 2014 22:27:00.000 0.004152 -0.006061
7 Mar 2014 22:28:00.000 0.004152 -0.006090
7 Mar 2014 22:29:00.000 0.004152 -0.006119
7 Mar 2014 22:30:00.000 0.004152 -0.006148
7 Mar 2014 22:31:00.000 0.004152 -0.006177
7 Mar 2014 22:32:00.000 0.004152 -0.006205
7 Mar 2014 22:33:00.000 0.004152 -0.006233
7 Mar 2014 22:34:00.000 0.004152 -0.006262
7 Mar 2014 22:35:00.000 0.004152 -0.006290
7 Mar 2014 22:36:00.000 0.004152 -0.006318
7 Mar 2014 22:37:00.000 0.004152 -0.006346
7 Mar 2014 22:38:00.000 0.004152 -0.006373
7 Mar 2014 22:39:00.000 0.004152 -0.006401
7 Mar 2014 22:40:00.000 0.004152 -0.006429
7 Mar 2014 22:41:00.000 0.004152 -0.006456
7 Mar 2014 22:42:00.000 0.004152 -0.006483
7 Mar 2014 22:43:00.000 0.004152 -0.006510
7 Mar 2014 22:44:00.000 0.004152 -0.006537
7 Mar 2014 22:45:00.000 0.004152 -0.006564
7 Mar 2014 22:46:00.000 0.004153 -0.006591
7 Mar 2014 22:47:00.000 0.004153 -0.006617
7 Mar 2014 22:48:00.000 0.004153 -0.006644
7 Mar 2014 22:49:00.000 0.004153 -0.006670
7 Mar 2014 22:50:00.000 0.004153 -0.006696
7 Mar 2014 22:51:00.000 0.004153 -0.006723
7 Mar 2014 22:52:00.000 0.004153 -0.006748
7 Mar 2014 22:53:00.000 0.004153 -0.006774
7 Mar 2014 22:54:00.000 0.004153 -0.006800
7 Mar 2014 22:55:00.000 0.004153 -0.006825
7 Mar 2014 22:56:00.000 0.004153 -0.006851
7 Mar 2014 22:57:00.000 0.004153 -0.006876
7 Mar 2014 22:58:00.000 0.004153 -0.006901
7 Mar 2014 22:59:00.000 0.004153 -0.006926
7 Mar 2014 23:00:00.000 0.004153 -0.006951
7 Mar 2014 23:01:00.000 0.004153 -0.006976
7 Mar 2014 23:02:00.000 0.004153 -0.007000
7 Mar 2014 23:03:00.000 0.004153 -0.007025
7 Mar 2014 23:04:00.000 0.004153 -0.007049
7 Mar 2014 23:05:00.000 0.004154 -0.007073
7 Mar 2014 23:06:00.000 0.004154 -0.007097
7 Mar 2014 23:07:00.000 0.004154 -0.007121
7 Mar 2014 23:08:00.000 0.004154 -0.007145
7 Mar 2014 23:09:00.000 0.004154 -0.007169
7 Mar 2014 23:10:00.000 0.004154 -0.007192
7 Mar 2014 23:11:00.000 0.004154 -0.007216
7 Mar 2014 23:12:00.000 0.004154 -0.007239
7 Mar 2014 23:13:00.000 0.004154 -0.007262
7 Mar 2014 23:14:00.000 0.004154 -0.007302
7 Mar 2014 23:15:00.000 0.004154 -0.007325
7 Mar 2014 23:16:00.000 0.004154 -0.007348
7 Mar 2014 23:17:00.000 0.004154 -0.007370
7 Mar 2014 23:18:00.000 0.004154 -0.007393
7 Mar 2014 23:19:00.000 0.004154 -0.007415
7 Mar 2014 23:20:00.000 0.004154 -0.007437
7 Mar 2014 23:21:00.000 0.004154 -0.007459
7 Mar 2014 23:22:00.000 0.004154 -0.007481
7 Mar 2014 23:23:00.000 0.004155 -0.007502
7 Mar 2014 23:24:00.000 0.004155 -0.007524
7 Mar 2014 23:25:00.000 0.004155 -0.007545
7 Mar 2014 23:26:00.000 0.004155 -0.007567
7 Mar 2014 23:27:00.000 0.004155 -0.007588
7 Mar 2014 23:28:00.000 0.004155 -0.007609
7 Mar 2014 23:29:00.000 0.004155 -0.007629
7 Mar 2014 23:30:00.000 0.004155 -0.007650
7 Mar 2014 23:31:00.000 0.004155 -0.007671
7 Mar 2014 23:32:00.000 0.004155 -0.007691
7 Mar 2014 23:33:00.000 0.004155 -0.007711
7 Mar 2014 23:34:00.000 0.004155 -0.007731
7 Mar 2014 23:35:00.000 0.004155 -0.007751
7 Mar 2014 23:36:00.000 0.004155 -0.007771
7 Mar 2014 23:37:00.000 0.004155 -0.007791
7 Mar 2014 23:38:00.000 0.004155 -0.007810
7 Mar 2014 23:39:00.000 0.004155 -0.007829
7 Mar 2014 23:40:00.000 0.004156 -0.007849
7 Mar 2014 23:41:00.000 0.004156 -0.007868
7 Mar 2014 23:42:00.000 0.004156 -0.007886
7 Mar 2014 23:43:00.000 0.004156 -0.007905
7 Mar 2014 23:44:00.000 0.004156 -0.007924
7 Mar 2014 23:45:00.000 0.004156 -0.007942
7 Mar 2014 23:46:00.000 0.004156 -0.007960
7 Mar 2014 23:47:00.000 0.004156 -0.007979
7 Mar 2014 23:48:00.000 0.004156 -0.007997
7 Mar 2014 23:49:00.000 0.004156 -0.008014
7 Mar 2014 23:50:00.000 0.004156 -0.008032
7 Mar 2014 23:51:00.000 0.004156 -0.008049
7 Mar 2014 23:52:00.000 0.004156 -0.008067
7 Mar 2014 23:53:00.000 0.004156 -0.008084
7 Mar 2014 23:54:00.000 0.004156 -0.008101
7 Mar 2014 23:55:00.000 0.004156 -0.008118
7 Mar 2014 23:56:00.000 0.004156 -0.008135
7 Mar 2014 23:57:00.000 0.004157 -0.008151
7 Mar 2014 23:58:00.000 0.004157 -0.008168
7 Mar 2014 23:59:00.000 0.004157 -0.008184
8 Mar 2014 00:00:00.000 0.004157 -0.008200
8 Mar 2014 00:01:00.000 0.004157 -0.008216
8 Mar 2014 00:02:00.000 0.004157 -0.008232
8 Mar 2014 00:03:00.000 0.004157 -0.008248
8 Mar 2014 00:04:00.000 0.004157 -0.008263
8 Mar 2014 00:05:00.000 0.004157 -0.008278
8 Mar 2014 00:06:00.000 0.004157 -0.008294
8 Mar 2014 00:07:00.000 0.004157 -0.008309
8 Mar 2014 00:08:00.000 0.004157 -0.008323
8 Mar 2014 00:09:00.000 0.004157 -0.008338
8 Mar 2014 00:10:00.000 0.004157 -0.008353
8 Mar 2014 00:11:00.000 0.004157 -0.008367
8 Mar 2014 00:12:00.000 0.004157 -0.008381
duncansteel said,
April 3, 2014 at 10:11 am
Ole said:
“From my calculations I doubt the LOS speed sat- aircraft at the ramp in KUL had been 21m/s. Imagine the dimension :
-earth radius ~ 6000 km
-orbit radius ~ 42000 km
From the sat velocity in z-direction (north-south) you will never see more than ~6000/42000=1/7 as LOS velocity on the ground.”
At present (semi-conscious) I have no idea where I got the 21 m/s from.
At the time in question the LOS speeds satellite-to-KL airport (which I call “Point_16:30″) are as below. At these times the drift speed of the satellite in its orbit is about 60 m/s, mostly northerly.
04 Apr 2014 07:00:54
Satellite-Inmarsat-3F1-To-Place-Point_16_30
Time (UTCG) FromAngularRate (deg/sec) RangeRate (km/sec)
———————– ————————- ——————
7 Mar 2014 16:30:00.000 0.004175 0.001035
7 Mar 2014 16:31:00.000 0.004175 0.001032
7 Mar 2014 16:32:00.000 0.004175 0.001030
7 Mar 2014 16:33:00.000 0.004175 0.001027
7 Mar 2014 16:34:00.000 0.004175 0.001024
7 Mar 2014 16:35:00.000 0.004175 0.001021
7 Mar 2014 16:36:00.000 0.004175 0.001018
7 Mar 2014 16:37:00.000 0.004175 0.001016
7 Mar 2014 16:38:00.000 0.004175 0.001013
7 Mar 2014 16:39:00.000 0.004175 0.001010
7 Mar 2014 16:40:00.000 0.004175 0.001007
7 Mar 2014 16:41:00.000 0.004175 0.001004
7 Mar 2014 16:42:00.000 0.004175 0.001001
7 Mar 2014 16:43:00.000 0.004175 0.000998
7 Mar 2014 16:44:00.000 0.004175 0.000995
7 Mar 2014 16:45:00.000 0.004175 0.000992
7 Mar 2014 16:46:00.000 0.004175 0.000988
7 Mar 2014 16:47:00.000 0.004175 0.000985
7 Mar 2014 16:48:00.000 0.004175 0.000982
7 Mar 2014 16:49:00.000 0.004175 0.000979
7 Mar 2014 16:50:00.000 0.004175 0.000976
7 Mar 2014 16:51:00.000 0.004175 0.000972
7 Mar 2014 16:52:00.000 0.004175 0.000969
7 Mar 2014 16:53:00.000 0.004175 0.000966
7 Mar 2014 16:54:00.000 0.004175 0.000962
7 Mar 2014 16:55:00.000 0.004175 0.000959
7 Mar 2014 16:56:00.000 0.004175 0.000956
7 Mar 2014 16:57:00.000 0.004175 0.000952
7 Mar 2014 16:58:00.000 0.004175 0.000949
7 Mar 2014 16:59:00.000 0.004175 0.000945
7 Mar 2014 17:00:00.000 0.004175 0.000942
04 Apr 2014 07:00:00
Satellite-Inmarsat-3F1-To-Place-Point_16_30: Inview Azimuth, Elevation, & Range
Inmarsat-3F1-To-Point_16_30 – AER reported in the object’s default AER frame
—————————————————————————-
Time (UTCG) Azimuth (deg) Elevation (deg) Range (km)
———————– ————- ————— ————
7 Mar 2014 16:30:00.000 358.163 -84.068 37296.620430
7 Mar 2014 16:31:00.000 358.165 -84.068 37296.682809
7 Mar 2014 16:32:00.000 358.167 -84.069 37296.745026
7 Mar 2014 16:33:00.000 358.169 -84.069 37296.807079
7 Mar 2014 16:34:00.000 358.170 -84.069 37296.868965
7 Mar 2014 16:35:00.000 358.172 -84.069 37296.930684
7 Mar 2014 16:36:00.000 358.174 -84.069 37296.992234
7 Mar 2014 16:37:00.000 358.175 -84.069 37297.053612
7 Mar 2014 16:38:00.000 358.177 -84.069 37297.114817
7 Mar 2014 16:39:00.000 358.178 -84.069 37297.175847
7 Mar 2014 16:40:00.000 358.180 -84.069 37297.236701
7 Mar 2014 16:41:00.000 358.181 -84.069 37297.297376
7 Mar 2014 16:42:00.000 358.182 -84.069 37297.357872
7 Mar 2014 16:43:00.000 358.184 -84.069 37297.418186
7 Mar 2014 16:44:00.000 358.185 -84.069 37297.478316
7 Mar 2014 16:45:00.000 358.186 -84.069 37297.538261
7 Mar 2014 16:46:00.000 358.187 -84.069 37297.598019
7 Mar 2014 16:47:00.000 358.188 -84.069 37297.657589
7 Mar 2014 16:48:00.000 358.189 -84.069 37297.716968
7 Mar 2014 16:49:00.000 358.190 -84.069 37297.776155
7 Mar 2014 16:50:00.000 358.191 -84.069 37297.835148
7 Mar 2014 16:51:00.000 358.192 -84.069 37297.893947
7 Mar 2014 16:52:00.000 358.193 -84.069 37297.952548
7 Mar 2014 16:53:00.000 358.194 -84.069 37298.010951
7 Mar 2014 16:54:00.000 358.194 -84.069 37298.069153
7 Mar 2014 16:55:00.000 358.195 -84.069 37298.127153
Skwosh said,
April 3, 2014 at 10:23 am
@duncanstele
Whoa! Thank you. I was thinking that it would be good to know these for just the times on the BFO plot – but having the full range is really excellent. Thank you very much. Do you never sleep!
Skwosh said,
April 3, 2014 at 10:25 am
@Ole – Excellent – you’re still here!
Very interesting – thanks. Lots to think about – and still cogitating what you’re saying.
However, I would very much appreciate a quick sanity check:
You say: “My understanding of Mike Exners charts is that the BFO in the inmarsat graph actually represent the Total Doppler. From there Mike subtracts D3 (C-Band Doppler) and D2 (S/C induced L-Band Doppler) and gets to D1.”
Now, in Mike’s description of his process (April 2, 2014 at 7:31 am – his points 8 and 9), the first thing he does (as you say above) is to correct the BFO for the satellite-ground Doppler (D3) in the diagram. This gives him a quantity that he calls “Total L band Doppler”:
BFO – D3 = “Total L band Doppler”
I was *very* assiduous to get Mike to clarify what he thinks this quantity represents – and he answered me:
On April 2, 2014 at 9:37 am he said (my emphasis): “Skwosh : YES. Total L band Doppler means the Doppler along the LOS path caused by the satellite antenna and the AER antenna *relative* motion.”
Now Duncan, in his velocity graphs, is plotting the *relative* velocity of the satellite and aircraft along their LOS also (isn’t he?) – so surely according to Mike’s interpretation this quantity (Mike’s “Total L band Doppler”) is what Mike should be giving to Duncan so that Duncan can do a direct comparison with his relative velocity plots? Surely Duncan does *not* need this quantity to be further corrected for the satellite’s motion in any way?
This is starting to drive me nuts. This seems so clear to me that I must surely have completely got the wrong end of the stick somewhere?
richardc10 said,
April 3, 2014 at 11:07 am
Assisted by some of the ideas on this blog I have had a go at modelling the Inmarsat Doppler data. I made the following assumptions:
1. The Doppler data is from a single pass through the system, from AES to GES. This is supported by the Inmarsat diagram. This assumption implies that the GES has told the AES what frequency slot to transmit on, and the GES is detecting the difference in frequency between the received and assigned signals.
2. I have assumed, as suggested by @skwosh and @ole, the AES compensates for the Doppler caused by its velocity, but works on the basis of a satellite at the mean position of INMARSAT 3F1, not its actual position second by second. This effect is computed here by calculating the difference in AES (aircraft) velocity (rangerate) to the actual satellite position compared to the mean position. This is D1 in the Inmarsat nomenclature.
3. Example North and South tracks used are from a separate modelling of the possible great circle paths of the aircraft, from a point just North of Indonesia to the last ping arc, using the speed of 450kts quoted in the published Inmarsat data to select the tracks. Positions and other data along the track were calculated for the ping times.
4. The rangerate between the satellite and the position of the aircraft was computed using a simple application called Orbitron which I have used in other applications. This is D2.
5. The ground system will have been originally set up to accommodate a stationary satellite, so I assume that a minimum change will have been made to get the system to work with a moving satellite. I have taken that this minimum was to dynamically adjust the IF used to extract the L band signal from the downlink C band signal to match the expected Doppler on the downlink to the GES. This leaves a residual Doppler due to the downlink, but only on the value of the L-band frequency rather than the higher C-band. Other assumptions are possible, clearly, but no correction leaves this component too large. This is D3, again computed with Orbitron for each ping time.
6. I have assumed an L-band frequency of 1.7GHz for all the links, in the absence of anything better.
7. The system bias was taken from the 16.30UT data, presumably with the aircraft stationary as it was before the declared takeoff time. This is the only ‘fit’ to the data.
The final modelling and the Inmarsat data is shown below, with the original Inmarsat graph. I have used the same formatting as Inmarsat (and so will incur the wrath of the anti-dot-joiners on this blog
).
http://i1311.photobucket.com/albums/s675/RichardC10/BFO_graph_zpsd52a0c77.jpg
Some comments:
1. The correspondence is reasonable, certainly all the trends are there. The data after 18.30 would be fit better with a different system bias (but that is set by the point at 16.30), or with a different downlink frequency.
2. The 16.30 modelled data point is with the aircraft stationary. The 16.41 model is for speed of 300kt and a course of 330, that is wheels-up after take-off on runway 33 at KL.
3. I have not tried (yet) to model the data points between 16.41 and 18.30. My modelled turn to the Southerly route is after 18.30. The 18.30 model is with the NW heading on the Northerly route, the match to the data indicates that was already approximately the heading at that time. The difference between the northerly and southerly routes modelled Doppler after 18.30 (just due to the different headings) is over 70Hz.
4. The model is thus sensitive to large changes of heading, at least for the first few points after 18.30 while the magnitude of D1 is large. The good fit that Inmarsat get constrains any more changes of heading after the 18.30 turn South. I haven’t tried the constant magnetic heading routes that have been discussed to see if they affect the model significantly.
I also show below the contributions to the Doppler for each of the Northerly and Southerly routes as D1, D2 and D3 (as defined above) in this case as m/s, with negative values meaning closing range, positive opening range. D3 is the same of course, as there is one downlink.
http://i1311.photobucket.com/albums/s675/RichardC10/components_zpsead22843.jpg
Skwosh said,
April 3, 2014 at 11:11 am
@Ole … yup … yup … WHERE does that *asymmetry* come from? It’s *big*. How can it be *that* big?
Ole said,
April 3, 2014 at 11:40 am
Skwosh said,
April 3, 2014 at 10:25 am
“This is starting to drive me nuts. This seems so clear to me that I must surely have completely got the wrong end of the stick somewhere?”
The problem is, inmarsat is very unclear of what their BFO actually is. Mike has found a way to convert them into reasonable aircraft range rates, but an official explanation of what these values represent is not available.
My take is the sign of the offset gets lost somewhere in the measuring process. Take into account that this offset has to be measured for thousands of channels all the time. The most efficient method to measure it probably is used. The reason to record this is probably to have a troubleshooting tool if the customer complains.
It’s also noteworthy that the inmarsat chart doesn’t talk about doppler shift but about frequency offset.
@Duncan, thanks for the range rates. STK seems to use the same vector algebra I was thought 25 years ago.
Skwosh said,
April 3, 2014 at 12:33 pm
@Ole: I am still thinking about your tomato (!) but, actually, aren’t the numbers basically about right if we get far enough away?
Say there *is* active correction by the aircraft based on it assuming the satellite is static over the equator. Then, as the aircraft gets further away from the satellite this active correction will get better and better at cancelling all the aircraft’s motion because the error in its assumption about the satellite position will become less and less important.
So, as we get further away, the *only* residual will start to look more and more like the actual satellite velocity along the line of sight to an effectively static aircraft.
So, say we have reached Perth by around the time of the final ping (on a southern track) – then according to Duncan (as we have his figures for Perth), the satellite is moving at ~8.3 m/s along the line of sight, and this gives a satellite Doppler of about 45Hz at 1.63GHz (the L-band).
If, however, we were at the anti-Perth (Perth mirrored on the equator) at the time of the last ping (on a northern track) then the Doppler is going to be equal but *opposite* (the satellite moves north-south – so if it was moving towards us along the line of sight at Pirth then presumably it would be moving away from us along the line of sight at anti-Pirth (neglecting that it is not *exactly* at the equator at the time)… or am I being really dumb about that?).
So, the *difference* between the un-compensated Doppler shifts between Pirth (south) and anti-Pirth (north) for the L-band at the time of the last ping is around 45Hz * 2 = 90Hz.
This is actually *too* big by about a factor of two to match up with the BFO plot (difference between green and red points at last ping), but we’re probably not as far east as Pirth or anti-Pirth, the tracks may not be symmetric about the equator etc. and this is just a back-of-envelope thing to try to reason about the orders of magnitude involved.
Also, if they are *not* taking D3 off the BFO plot then that would add an extra steady time varying offset (the blue line on Mike’s charts) to *everything* which could add further subtlety/confusion (but it would not affect the *difference* between the red and green values).
Just reeled this off real quick without too much thought – may be rubbish. If obviously so do say! Will try to give more careful consideration later.
sk999 said,
April 3, 2014 at 5:11 pm
richardc10
Very nice – I think you have made a big step in cracking the code. I had been thinking that AES was measuring the Doppler and compensating, but indeed, it just guesses based on a nominal location for the satellite.
I have lost track of the reference for how close the compensation needs to be, but it must dictate how much wobble Inmarsat can allow in the orbit of 3-F1.
MtKlimber said,
April 3, 2014 at 8:59 pm
richardc10:
Nice work and welcome to the discussion. Do you have a way to graphically show your assumed example N and S ground tracks on a map as compared to Inmarsat’s assumed tracks?
What plans do you have for further use of your model? May I suggest it would be helpful to understand how the BFO vs. time plots vary as a function of assumed ground track. For example, one could generate a family of N and S ground tracks with various assumed ground speeds, each of which satisfies the ping arc range data as “reverse engineered” by GlobusMax:
http://www.reddit.com/r/MH370/comments/21xw2a/mh370_reverse_engineered_ping_data/
http://i.imgur.com/R5r3OhD.png
Thoughts?
hal said,
April 3, 2014 at 11:50 pm
@richardc10 – I’ve been knocking around in here for a while and I think you will be the person to answer one question that’s been bugging me. Why does the northern predicted route inflect downward (in your model and the inmarsat one)? We have data showing the satellite was moving southward late in the timer period, and it seems a north-moving plane would generate greater doppler shifts with a southward-moving satellite than a south-moving plane would. Also a couple of other folks have come up with monotonic increasing doppler offsets for the northern route. Yours is the first to replicate the inmarsat plot (in this regard).
Can you explain — slowly and simply, as though talking to a child
— what accounts for the bend in the red line?
I’m leaving on vacation so may not be able to reply to your note but will definitely check in and read. Thanks!
Ole said,
April 4, 2014 at 12:08 am
Hi,
can somebody crosscheck the following thought, it is almost too simple to be true. It gives an idea of how the measured LOS speed between sat and aircraft relates to the position of the aircraft:
——————————————
Definitions:
a) Frame of reference is the earth at rest.
b) V_SPoA be the LOS velocity (satellite)-(position of aircraft), this does not include the LOS velocity of the aircraft itself. V_SPoA is a scalar.
c) vect_Vsat be the velocity vector of the satellite.
d) vect_LOS be the normalized line of sight vector from satellite to aircraft.
e) phi be the angle between vect_Vsat and vect_LOS
Assumption: V_SPoA can be extracted from the BFO.
Conclusion:
1.) If the line of sight vector vect_LOS is perpendicular to the sat’s speed vector, there will be no V_SPoA, if both vectors are parallel V_SPoA becomes greatest.
=>V_SPoA = |vect_Vsat| * cos(phi)
=> phi = acos(V_SPoA / |vect_Vsat|)
2.) That means at a given instant all points with equal V_SPoA are located on the surface of a cone.
- The apex of the cone is the satellite
- The axis of the cone is the velocity vector of the satellite,
- The aperture of the cone is 2*phi
3.) The ping arcs are derived from spheres of equal distance to the satellite. For each instant this sphere intersects with the surface of the earth and intersects with the cone of equal V_SPoA.
4.) The intersections of these three surfaces define the positions of the aircraft at the times of each ping. The “only ” problem is measurement accuracy.
———————————-
@richardc10
welcome here, spilled over from pprune?
I’m still chewing your post. Do I understand correctly that your model explains
1.) the difference around 19:40 between north and south prediction with the LOS miscalculation of the compensation algorithm (due to inaccurate hypothesis of sat position)?
2.) the difference at the end of the flight with different (mainly in sign) relative velocities between sat and aircraft ?
Skwosh said,
April 4, 2014 at 12:31 am
@richardc10
That looks absolutely fantastic! Thank you so much.
When I was commenting earlier I think I must have missed your post (or maybe it was queued as you’ve never posted before) – and I’ve been away now over night for some time.
I still don’t really have any time, but I’ve looked at your plots and they look very good. I’ll try to find some time later – but it looks *very* encouraging. I am so glad someone has been able to try this out.
@Ole
I was thinking EXACTLY that last night while trying to get to sleep – trying to visualise the intersection of that cone of constant angle with the earth’s surface – how it makes a (kind of southward sloping) curve of points of ‘constant satellite Doppler’ – and you can intersect that curve with the distance arc and get an *exact* position. I was thinking it can’t be right – not because of the logic – but because surely they would have done it – so I was then assuming the ideas about the BFO being almost entirely down to the satellite as you get further away must be wrong – but now, in light of this amazing work by @richardc’s it looks like those ideas may be correct… in which case the intersection idea should be correct too – and we can find the damn thing. Agreed – too good to be true though. Small steps. Caution. Sorry – I have no time at the moment! It’s so frustrating for me. Will try to get back as soon as possible.
Skwosh said,
April 4, 2014 at 3:21 am
@richardc10 [cc @Ole !]
I have had a bit more time to think. Just to confirm, this is what I think you are doing using the Inmarsat diagram notation. *None* of this is intended as criticism – it is just me trying to be absolutely sure that I am understanding what you are doing:
D1 = aircraft *correction* (aircraft shifts its frequency from the assigned base frequency based on what it thinks the Doppler shift would be were it transmitting to a *fixed* satellite position).
D2 = Doppler shift that happens (due to Nature!) to this transmission from aircraft to satellite (this is not exactly the opposite of D1 because the satellite is actually moving).
D3 = Doppler shift that happens (once again due to Nature) when the transmission is relayed from the satellite to the ground.
The BFO is interpreted as the sum of these three:
BFO = D1 + D2 + D3
I’m still trying to get my head around your ideas about the ‘adaptation’ of the ground station (makes a lot of sense) – but the upshot of this is that you are calculating D3 (and thus all of the Ds) based on the *L-band* frequency rather than the C-band frequency.
So, for a given track, you are effectively calculating the following:
D1 = – L-Band-Doppler( Moving aircraft to a *fixed* motionless satellite )
D2 = + L-Band-Doppler( Moving aircraft to actual moving satellite )
D3 = + L-Band-Doppler( Moving satellite to fixed ground station )
And plotting D1 + D2 + D3 + constant systematic bias
I am still digesting all of this. However, on the assumption that my above interpretation of what you are doing is correct I have some quick observations:
[1] Fuc**ng A!
[2] So… some of us are thinking that as the aircraft gets further from the satellite the contribution to the BFO of the aircraft’s *velocity* (with respect to the fixed-earth coordinates) gets smaller and smaller – and the BFO becomes dominated by the satellite’s velocity and thus will increasingly depend *only* on the aircraft’s *position* – so then, for a given BFO and instant in time – we could maybe try to deduce all the points on the earth’s surface where the aircraft could be (and intersect that with the corresponding ping ring and thus perhaps narrow down the aircraft’s position). First step is maybe to see how practical this could be by trying to get a feel for the numbers – how much/little of a difference does the aircraft’s actual velocity makes to the BFO once the aircraft is a long way out? We could maybe get a feel for this by seeing what the BFO looks like towards the end of the tracks if the aircraft tracks had the same positions as before but the the aircraft is assumed to be somehow ‘instantaneously static’ – rather than in motion – not sure how easy that would be to do in your setup (does that make sense – I know what I mean, but I may not have expressed it very well?). If this approach is sound then it would actually be quite ironic – that a technique inspired by trying to deduce stuff about the aircraft’s velocity actually tells us less and less about the aircraft’s velocity towards the end of the flight, but that this actually *could* turn out to be a *good* thing because it might allow us to constrain the aircraft’s position!
[3] For some time I’ve been wondering about the discrepancies at the *start* of the BFO plot between Inmarsat’s predicted tracks and the actual measured values. Surely – I keep saying to myself – the fit here should be *good* because the early history of the flight is know? Need to think about this further – but this discrepancy – and the apparent fairy constant discrepancy between the actual and predicted (southern) values towards the *end* of Inmarsat’s graph are both interesting because surely if they *could* have come up with a predicted track that fitted better at both ends then they would have? I’m still thinking about this could mean – just thought I’d throw it in as something that could may somehow contain information – and now we maybe have a good model of what Inmarsat were doing we could start to try to reason about these discrepancies.
@hal – I would love to try to do an ‘explainer’ – I need to find the time – and I need to be absolutely sure that I myself am clear about @richardc10′s plot first though (I am almost certain that I am – I just want to check and wouldn’t want to misrepresent).
Ole said,
April 4, 2014 at 5:29 am
Richard,
now I think I worked through your post. Your model appears to be a hybrid/synthesis between Mike’s model and the “imperfect compensation model”. Great work from all contributors!
I understand that you take D1 as the residual compensation error due to miscalculation of LOS aircraft-sat, because the sat is not at the position the aircraft expects it to be. D1 depends on the aircraft’s position(t) and it’s velocity(t). (@hal: it is no way proportional to it’s velocity).
That would be the blue component in
http://i1311.photobucket.com/albums/s675/RichardC10/components_zpsead22843.jpg
D2 is the contribution due to the sat’s own motion. The size of that contribution depends on phi(t) and sat’s velocity(t) . It is the orange component in your graph.
You explain D3 in your point 5. I too would have expected the C-Band Doppler to be corrected in the down converter (LNB) that sits in the focus of the receiving dish in Perth. The downlink sat->Perth has to carry 7 basebands (1 global beam, 6 spot beams) maybe not all of them are carried in the C-Band? Inmarsat will know what magic happens there, but that’s still a little weak point.
@Skwosh
” how much/little of a difference does the aircraft’s actual velocity makes to the BFO once the aircraft is a long way out?”
Isn’t that what Richard has done in his second graph, the one I re-linked above? The orange line D2 would be what’s interesting. Because Richard assumes the Imarsat 450 knot track, he gets further south into the realms of the 10m/s cone whereas Perth would be in the 8 m/s cone.
I just fear that the extraction of this D2 from the BFO is error prone.
The spikes in the first part of the flight could be due to another imperfection of the compensation: Imagine the compensation frequency for doppler compensation is updated only every ~5 seconds in the transmitter. If the velocity vector of the aircraft happens to change within this 5 seconds the correction at the end of this 5 second interval would be imperfect.
richardc10 said,
April 4, 2014 at 5:50 am
@skwosh
Will respond in detail to your and other messages later today. Here are some quick points:
>D1 = aircraft *correction* (aircraft shifts its frequency from the assigned base frequency based on
>what it thinks the Doppler shift would be were it transmitting to a *fixed* satellite position).
D1 is the _difference_ in corrections between the calculated Doppler shifts to a) a fixed satellite and b) that to the satellite at a moving position. As the satellite is moving then correction b) would remove _all_ the Doppler due to the moving aircraft. However, the AES is applying correction a) so the difference between a) and b) appears as a shift in the ping signal frequency.
>D2 = Doppler shift that happens (due to Nature!) to this transmission from aircraft to satellite (this
>is not exactly the opposite of D1 because the satellite is actually moving).
As you say D1 is related to the motion of the satellite so its magnitude and sign are unrelated to D1.
The velocities of D1 and D2 are with respect to the rotating frame where the point on the Earth under the aircraft and the *fixed* satellite position are both stationary. There must be some subtle physical effects of the rotation of the Earth but these will be small, I think.
>D3 = Doppler shift that happens (once again due to Nature) when the transmission is relayed from
>the satellite to the ground.
Yes.
>The BFO is interpreted as the sum of these three:
>
>BFO = D1 + D2 + D3
Plus a constant bias, it seems.
>
>I’m still trying to get my head around your ideas about the ‘adaptation’ of the ground station
>(makes a lot of sense) – but the upshot of this is that you are calculating D3 (and thus all of the Ds)
>based on the *L-band* frequency rather than the C-band frequency.
>So, for a given track, you are effectively calculating the following:
[corrected as below]
D1 = – L-Band-Doppler( Moving aircraft to a *fixed* motionless satellite ) minus
L-Band-Doppler (Moving aircraft to a motionless satellite at the *actual* position of
Inmarsat 3F1)
D2 = + L-Band-Doppler(Fixed point on the Earth instantaneously under the aircraft to
actual moving satellite )
D3 = + L-Band-Doppler( Moving satellite to fixed ground station )
>And plotting D1 + D2 + D3 + constant systematic bias
regards
richardc10 said,
April 4, 2014 at 5:53 am
the last bit was a formatted badly – repeating.
D1 = L-Band-Doppler( Moving aircraft to a *fixed* motionless satellite )
minus
L-Band-Doppler (Moving aircraft to a motionless satellite at the
*actual* position of Inmarsat 3F1)
(I have ignored the signs in this explanation)
D2 = + L-Band-Doppler(Fixed point on the Earth instantaneously under
the aircraft to actual moving satellite )
D3 = + L-Band-Doppler( Moving satellite to fixed ground station )
Ole said,
April 4, 2014 at 7:33 am
Some speculation on how the doppler correction on the downlink sat-Perth could work: For Richards predicted north track I notice the curve to be much smoother than in the inmarsat version (red curve in original inmarsat BFO chart).
So maybe the local oscillator of the down converter cannot be tuned continuously to adapt to the doppler shift, but is switchable so that it adapts in steps to the changing doppler shift on the downlink. At least my satellite dish at home uses such a switchable local oscillator, albeit not for doppler correction:
http://en.wikipedia.org/wiki/Low-noise_block_downconverter#Universal_LNB_.28.22Astra.22_LNB.29
devonseaglass said,
April 4, 2014 at 7:44 am
There is a patent application which (maybe) describes how the system operates.
“To solve this problem, Inmarsat requires that each AES 12 transmit all of its signals to satellite 16 within a defined frequency tolerance (e.g., 100 or 185 Hz). To meet the requirement, AES 12 listens to signals received on P Channel 34, which are continuously available, and measures the frequency error between received P Channel signals and the known P Channel transmission frequency. It is assumed that this error is caused by Doppler shift. AES 12 uses the measured error to determine an expected Doppler shift for each transmission based upon the ratio of the P Channel receive frequency to the R, T and C Channel transmit frequencies, and applies the expected Doppler shift to correct the transmissions on the R, T and C Channels to compensate for the Doppler shifts. Thus, the frequency error budgets will not be exceeded.”
The link is here; https://www.google.com/patents/US6008758
duncansteel said,
April 4, 2014 at 9:28 am
I have just put up a new post on my website:
Ping Rings from the Inmarsat-3F1 Data
duncansteel.com
duncansteel said,
April 4, 2014 at 9:34 am
Skwosh asked:
“what Mike should be giving to Duncan so that Duncan can do a direct comparison with his relative velocity plots? Surely Duncan does *not* need this quantity to be further corrected for the satellite’s motion in any way?”
Yes. And I have those values (i.e. LOS speeds satellite-aircraft derived from Mike’s BFO decomposition to get the Doppler component for just that satellite-aircraft leg).
The values were posted here: http://www.duncansteel.com/archives/507
(inter alia). Here they are again:
Time
(minutes) LOS Speed (km/sec)
0990 –0.000341
1003 0.007443
1015 0.014936
1027 0.011022
1105 0.043419
1107 0.025610
1109 0.020462
1180 0.020136
1240 0.031279
1300 0.041077
1360 0.051776
1451 0.064485
Times are minutes UTC so 990 means 16:30 UTC on 2014/03/07.
Cheers,
Duncan
Skwosh said,
April 4, 2014 at 9:43 am
@richardc10
Ah! I see what you’re doing now – so, not exactly what I thought, but probably very similar.
Thanks very much for re-writing it in my terminology – that was extremely helpful.
I’m still very time limited at the moment – sorry. Still pondering if what you’re doing is essentially equivalent to what I thought you were doing anyway – is maybe a bit different – asymptotic cases is what I’m preoccupied with.
If it’s really easy for you to run my slightly different one through would appreciate it if you could give it a try – but if it’s at *all* difficult or time consuming please don’t yet as it may be a complete waste of time.
@Ole – didn’t see that @richard had broken down his components – thanks for drawing that to my attention – as I now understand he’s not doing things in quite the way I thought he was doing so what I was saying doesn’t make sense in terms of his plots because what I was thinking D1 and D2 were aren’t actually what he has been plotting as D1 and D2.
Will ponder your thoughts regarding satellite to ground stage of process – very interesting.
Ole said,
April 4, 2014 at 10:36 am
My take on the frequency deltas involved:
In the “earth at rest” frame of reference we have:
[1] doppler shift from aircraft velocity (by nature)
[2] preemptive frequency compensation the aircraft applies
[3] compensation error due to miscalculation LOS aircraft-sat
[4] L-Band doppler shift from sat velocity (by nature)
[5] C-Band doppler shift on the downlink sat-Perth (by nature)
[6] correction at the ground station in Perth
- all six together give the BFO
- [5] and [6] are well known by inmarsat and add an offset(t) that is independent of aircraft velocity and position
- if [2] were perfect the sum of [1] and [2] would disappear
- because [2] is imperfect we get [3] in lieu of [1] and [2]
In Richard’s interpretation of inmarsat’s nomenclature (at least how I understand him):
D1=[3] (blue)
D2=[4] (orange)
D3=[5]+[6] (grey)
http://s1311.photobucket.com/user/RichardC10/media/components_zpsead22843.jpg.html
I love that chart!
My interpretation of the inmarsat nomenclature is:
D1=[1]
D2=[2]+[3]+[4]
D3=[5]+[6]
But that’s just a question of choosing groups for [1] – [6] .
richardc10 said,
April 4, 2014 at 12:13 pm
@Ole
>welcome here, spilled over from pprune?
Thanks – the wash of posts at pprune is overwhelming
>I’m still chewing your post. Do I understand correctly that your
> model explains
>1.) the difference around 19:40 between north and south prediction
> with the LOS miscalculation of the compensation algorithm (due to >inaccurate hypothesis of sat position)?
Yes. The as I said the difference in headings alone makes the compensation algorithm give D1 values different by 70Hz (at that location and time).
>2.) the difference at the end of the flight with different (mainly in sign)
> relative velocities between sat and aircraft ?
Yes, D2 dominates at the end of the flight.
> D2 is the contribution due to the sat’s own motion. The size of that
> contribution depends on phi(t) and sat’s velocity(t) .
> It is the orange component in your graph.
It also depends on the location of the AES. It is the relative rangerate between the instantaneous location of the aircraft and the satellite.
>You explain D3 in your point 5. I too would have expected the
>C-Band Doppler to be corrected in the down converter (LNB) that
>sits in the focus of the receiving dish in Perth.
>Inmarsat will know what magic happens there, but that’s still a little >weak point.
Agreed. I don’t understand why Inmarsat would not compensate fully for the C band downlink Doppler. Perhaps we need to consider that this was a ‘fix’ to allow the satellite to be used in the modified orbit. The original C-band setup would not have any need for Doppler compensation (as it was taking to a GEO satellite) so the simplest possible back-end solution was used to reduce the downlink Doppler (D3) to a value comparable to the other irreducible components of the BFO (D1 and D2).
> I just fear that the extraction of this D2 from the BFO is error prone.
Absolutely. The model I have generated is not is even slightly exact – it just gives a flavour of what Inmarsat have done with a full understanding of the system. They will be squeezing the last sub-Hz out of the analysis to improve the course solution. The Inmarsat analysis will be completely solid.
>My take on the frequency deltas involved:
>In the “earth at rest??? frame of reference we have:
>[1] doppler shift from aircraft velocity (by nature)
>[2] preemptive frequency compensation the aircraft applies
>[3] compensation error due to miscalculation LOS aircraft-sat
>[4] L-Band doppler shift from sat velocity (by nature)
>[5] C-Band doppler shift on the downlink sat-Perth (by nature)
>[6] correction at the ground station in Perth
>- all six together give the BFO
>- if [2] were perfect the sum of [1] and [2] would disappear
>- because [2] is imperfect we get [3] in lieu of [1] and [2]
Yes.
>In Richard’s interpretation of inmarsat’s nomenclature (at least how I understand him):
>D1=[3] (blue)
Yes, the uncompensated balance of [1], [2] and [3]
richardc10 said,
April 4, 2014 at 12:18 pm
@skwosh
>Ah! I see what you’re doing now – so, not exactly what I thought, but >probably very similar.
>
I rather pedantically have referred everything back to the rest frame. The components could be collected differently, but with the same result.
Skwosh said,
April 4, 2014 at 12:51 pm
@Ole (cc @richardc10)
Excellent – I think that is very succinctly expressed.
I think the problem *I* am having (probably just me!) is with the idea of talking about Doppler shifts without specifying clearly both the transmitter and the receiver. To me the idea that something like an aircraft can ‘have’ an intrinsic ‘Doppler’ independent of the position and velocity of any receiver doesn’t make sense. So – for example – if there is an ambulance going north and I am standing south of the ambulance I am going to hear it’s sound down-shifted; if I am standing north of the ambulance I am going to hear it’s sound up-shifted. The ambulance doesn’t ‘have’ an intrinsic ‘Doppler’ that is independent of the position of the (in this case static) observer. I know this is probably kind of pedantic – and perhaps this is why I keep getting confused – but I just can’t cope with the idea of talking about a Doppler shift unless both the transmitter and receiver are clearly specified. This is what I’m having trouble with (my problem I think!)
The only way my poor little brain can make sense of all this is in terms of a model (which could be wrong for sure) of the actual sequence of events that were *physically* happening – so I’m trying to look at it in a way that splits things up accordingly. So my overall mental framework at the moment is along the following lines (everything in “earth at rest??? frame as you say). I see the following stages (these do not necessarily always directly relate to a particular number – I’m trying to describe the stages of a model ‘process’).
[A0] Aircraft is assigned a bass frequency on which to transmit.
[A1] Aircraft *may* use some method or other to decide on a frequency shift to apply to the bass frequency in an attempt to compensate for the forthcoming Doppler effects.
[A2] Aircraft transmits a signal at (base frequency) + (what ever pre-emptive correction it has decided to use in [A1]).
[B] Signal gets Doppler shifted by Nature between moving aircraft and moving satellite. I think we all agree that this shift depends on the frequency of the signal and the *relative* velocity along the line of sight between the satellite and the aircraft – or, put another way, on the instantaneous rate of change of the straight line distance between the aircraft and the satellite. If this distance is getting smaller the frequency is Doppler shifted up, if the distance is getting larger the frequency is Doppler shifted down. I think we all agree here on how to calculate this Doppler shift given the positions and velocities of both the satellite and the aircraft.
[C] Satellite shifts the frequency of the signal up by a known fixed amount and transmits signal to ground.
[D] Signal gets Doppler shifted by Nature between moving satellite and stationary ground. Just as in [B] above (repeating what I said in [B] for clarity): I think we all agree that this shift depends on the frequency of the signal and on the velocity of the satellite along the line of sight between the satellite and the ground station – or, put another way, on the instantaneous rate of change of the straight line distance between the satellite and the ground station. If this distance is getting smaller the frequency is Doppler shifted up, if the distance is getting larger the frequency is Doppler shifted down. I think we all agree on how to calculate this frequency shift given the position and velocity of the satellite and the position of the ground station (which has velocity of zero!).
[E] The ground station receives the signal and may manipulate/shift and/or add/remove some offset to the signal.
[F] The frequency of the resulting signal is recorded, and we are currently thinking of this as what is being plotted on the Inmarsat BFO graph (less fixed constant).
So – in terms of the above:
[B] and [D] I think everyone here agrees on.
[A1] is an area of speculation.
[C] is something I think we all agree, but in some simplified models [C] can perhaps be safely glossed over.
[E] is also an area of active speculation.
[F] is just a definition of what the BFO is within the framework of this model (so speculation about how the frequency data may have been processed before it was presented to us in the BFO plot is, in my scheme here, meant to all be included in [E]).
Unfortunately I can’t currently get my head around how to neatly fit what @richardc10 has done in my model (and both you (@Ole) and he have very clearly described to me what it is that you are doing – thank you). I agree that this is basically *my* problem – and I may just be being very slow – I am now going to devote my time to trying to do this!
Much appreciate your exposition and ongoing dialogue!
richardc10 said,
April 4, 2014 at 12:51 pm
@hal
> Why does the northern predicted route inflect downward
> (in your model and the inmarsat one)?
> Can you explain — slowly and simply, as though talking to a child
> — what accounts for the bend in the red line?
The quantity plotted in the graphs (Inmarsat’s and mine) is termed Burst Frequency Offset (BFO) and is not all due to actual Doppler shifts, that is the velocities of the aircraft and satellite. Some of it is due to an error the satellite terminal on the aircraft makes, as described below.
The satellite terminal on the aircraft attempts to compensate for its own motion when it sets the frequency of its own transmission to the Inmarsat satellite. This is done so the satellite receives the transmission at the correct channel frequency assigned to that aircraft when it first made contact to Inmarsat (when it switched on before take-off).
However, (according to the proposal of @skwosh and @ole) the satellite terminal system on the aircraft was designed assuming the satellite was at a station fixed above the equator. Inmarsat has decided to allow their Inmarsat 3F1 satellite to adopt an orbit that drifts North and South of the equator. This movement means that the satellite terminal calculates the frequency compensation incorrectly, and this ‘correction error’ depends on where the aircraft is located and what bearing it is on. The correction error appears as an additional part of the BFO. It is large in magnitude for the first part of the track, and smaller when the aircraft is far South (or North) (because at later times the satellite is getting closer to where it ‘should be’).
For a track that goes North from the starting point, the correction error pushes the red line (North track) up for the first few points, and it pushes the blue line (South track) down. If this correction error did not exist then the red line would keep going down (and the blue line up) due to the southward motion of the satellite. As the magnitude of the correction error decreases later in the flight, the trend due to the satellite motion dominates and the blue line keeps going up, and the red line starts down.
I hope that is clear.:-?
Skwosh said,
April 4, 2014 at 1:42 pm
@Duncan
Re: my “sanity check” (!)
I think I was having trouble understanding why Mike was applying his subsequent calculation stages to try to correct for satellite motion at all (as I couldn’t understand why that would be required for fitting to your velocity plots) – and I think I was unclear in my own mind if he was sending you velocities that *had* had any of his subsequent corrections (his stages 10, 11 and 12 in his calculation details) applied to them or not – though now I guess Mike’s subsequent stages are all about aiming to try to get a ‘ground speed’ (along line to sub-sat point?) for the aircraft alone.
Anyhow – I was after a sanity check that I was right in thinking what number in his calculation corresponded ‘conceptually’ (according to his interpretation) to your aircraft/satellite relative velocities – and to be sure that was the number he was supplying. I think also part of why I was a bit worried about this was because of the actual values – at first I was thinking the line of sight velocity between (presumed static on runway) aircraft and satellite at the start of everything was quite high. I think I do remember seeing a figure that seemed *very* low to me in the original post you refer to (I think probably corresponding to that first -0.3 m/s in the numbers you have reproduced from it) and I think that was probably what set me off worrying. Sorry if I’ve caused any confusion – I was trying to make sure I was clear about what was happening before making any concrete suggestions to you – as indeed I still am! Thanks very much for clarifying this – and again thanks so much for the data dump yesterday – it’s made all the difference to me to get a feel for the numbers.
richardc10 said,
April 4, 2014 at 2:19 pm
@Skwosh
I don’t think there is a fundamental difference in the views here. We are trying to work out the changes of range between the 1) aircraft and satellite, and 2) satellite and ground station.
As both aircraft and satellite are in motion with respect to the rest frame, item 1) can be broken down in a number of ways. However, in the end it is their relative speed that is important.
In a non-relativistic world (i.e. speeds much less than speed of light), the Doppler components can be added simply as if they were unrelated, that is ‘Doppler’ of the aircraft with respect to the ground, plus ‘Doppler’ of the satellite with respect to the ground under the aircraft plus ‘Doppler’ of the spacecraft with respect to the ground station, and get the right answer. In this respect we are using ‘Doppler’ as a short-hand for velocity which has a direction independent of the observer.
The main point is not to double count velocity (and hence Doppler) contributions.
airlandseaman said,
April 4, 2014 at 2:54 pm
A few comments from the jungle:
Speculation about the frequency stability of the S/C LO is unnecessary. I’m pretty sure it is a TCXO or OCTCXO (certainly not a simple crystal oscillator) with excellent LTS and STS, but it does not matter. The frequency is effectively calibrated from the LES using pilot carriers and a Rubidium standard, or a GPS locked standard, so don’t waste your time trying to reverse engineer the s/c. Just take Inmarsat at their word, and assume they are not idiots. When they say the BFO is the Expected-Observed, just go with that. Moreover, I am quite sure the AES correction is known in real time at the ground, and taken into account when the “expected value” is calculated. Otherwise, they would not have been able to perform any analysis.
The C bad correction is all that Duncan needs. My spreadsheet has the provisions to separate the L band Doppler into S/C and A/C components, but the TOTAL L band Doppler is all Duncan needs. The S/C induced L band Doppler ESTIMATE is known to depend on very rough (poor) estimate of the aircraft position. In fact, I fully understand why the S/C component is underestimated. It is due to the fact that I used the airport RRs for the 4-12 transmissions. It is just a placeholder until we have real numbers, or estimates from Duncan’s Model. The first three are based on hard (ADS-B) data, and last 9 are based on a simple assumption to test the model, not solve for the exact s/c component. As I have explained to Duncan, as soon as he has good estimates for the L band RR to the 9 unknown LOPs (not the aircraft), then we will have fairly accurate separate components of the L band Doppler. All that said, I repeat, the TOTAL L band Doppler is a solid value, unaffected by S/C LO uncertainty, and Duncan can use this to constrain the solution. It does not need to be separated to find MH370.
Skwosh said,
April 4, 2014 at 3:21 pm
@richard10c Cheers – I’m just being slow, and am catching up now I think. I see how your calc method gives exactly same result now. It’s been a bit of a long day!
Ole said,
April 4, 2014 at 11:22 pm
airlandseaman,
I think there is no doubt that the oscillators and frequency converters in the sat are *very* precise. The idea of the C-Band correction at the ground station in Perth I think is the following:
To BFO is measured for all of the channels from all of the AES. That imho means it must be measured *after* the TDMA and FDMA channels have been separated by the receiving equipment in Perth. That channel separation probably happens by some stages of mixers, bandpass filters, and demodulators. It seems reasonable no to feed all the “dirt” of the variable C-Band Doppler into that chain but to eliminate as much C-Band Doppler as possible en bloc from the whole C-Band as close to the antenna as possible.
If the AES correction is known at the ground, then it would make sense to log that separately and not to mix it back into the BFO. (The BFO is a value measured directly at the physical layer, the correction value is only known after the header has been decoded).
This correction value effectively is the rangerate the AES thought it had. As @hamster3null noted elsewhere this rangerate is not an information really independent/different of the ping arcs because the distance between the ping arcs already represents the *hourly average* rangerate whereas the compensation value represents the *instantaneous* rangerate.
xiak said,
April 5, 2014 at 5:17 am
@Skwosh, @ Ole
**About Doppler frequency shift compensation on AES:
1. In general, YES, AES compensates the Doppler shift caused by the relative velocity between GES, satellite and aircraft, on its uplink direction, when sending data or voice signals to satellite (and, to GES through satellite);
2. But…… AES does NOT compensate the Doppler shift during the initial ‘handshake’ stage (or, ‘log-on’ stage, ‘acquisition’ stage, or ‘ping’ stage, depending on who calls it);
3. Instead, AES sends its PING burst on the random access channel at its nominal carrier frequency. .
4. GES measures the Doppler shift of the received PING burst coming from AES’s random access channel, calculates the compensation value the AES should apply, and sends it back to AES digitally. AES then can adjust its uplink frequency accordingly and reply back to GES with a further PING burst;
5. Now, GES receives the new PING burst with reduced Doppler shift. In ideal case the Doppler shift is reduced to such a small amount that it can be neglected. -That said, the received PING burst frequency now falls into system Spec definition. Otherwise the above described process is iterated until the measured frequency error at GES is small enough.
6. Then, traffic channels can be allocated and assigned by GES to AES, and AES can apply Doppler frequency shift compensation on its traffic channels, and the ‘handshake’ stage is done!
One may ask: if AES doesn’t compensate the frequency shift on its random access channel for the PING burst, won’t it ‘overflow’ to cause interference on the adjacent channels? The answer is, YES, it may overflow to adjacent channels. But the random access channel is planned by GES in such a way that, its left and right side adjacent channels are reserved as ‘guard’ channels not used for any communication. This is an overhead any satellite based communication system need to take.
**Now comes to the famous 3-page ‘Annex’ PDF image from Inmarsat:
Inmarsat says ‘Not corrected by system = measured frequency offset’. Indeed Inmarsat is precious, and doesn’t intent to create confusion, though it does. The fact is, the PING bursts are not ‘corrected’ so the whole, instead of the residual, Doppler shift caused by satellite and aircraft movement can be measured by GES.
**About D1
D1 refers to the Doppler shift caused by aircraft movement other than the ‘aircraft location, heading and speeding’. Such ‘other’ movement, for example, could be the aircraft fluctuation due to air turbulence, which introduces extra relative velocity between aircraft and satellite.
In most cases, such Doppler shift D1 is ‘instantaneous’, and is hard to predict. If we assume that the aircraft is not under any severe turbulence at the moment it’s sending out its PING burst, we can say D1 is small enough and can be ignored from analysis. In this sense, D1 is shown on the page only for completeness purpose.
** About BFO
Yes BFO includes both D1 and D2. More strictly speaking, you’d say that BFO includes also D1. That said, BFO = D1+D2+D3. But as said above, D1 is neither significant nor easily predictable, it is not an issue if one assume that BFO = D2 +D3.
2una said,
April 5, 2014 at 5:20 am
CCTV is reporting pinger signal at 25.59S / 101.29E
devonseaglass said,
April 5, 2014 at 6:49 am
@xiak
Thanks! Great contribution.
Ole said,
April 5, 2014 at 7:17 am
@xiak,
thanks for that info. It makes sense to use the measured value for doppler compensation. Your description of how doppler on the first ping is handled is close to Mike’s model. I will ponder what implication that has on the asymmetry of the predicted south/north tracks.
@richardc10′s model is a fairly good match of what inmarsat has produced and as you describe the process, there would be no need for the AES to have a GPS receiver for doppler compensation. OTOH I have the gut feeling that the effects that Richard’s model explains (i.e error due to sat being not above equator, error due to sat velocity) could occur similarly asymmetric in a process as you describe it.
Could the iteration process you describe under 5. be what happend around 18:25 ?
Is there a public source that has more on this D1,D2,D3 stuff? (Or is it insider info
?)
—————–
2una said,
April 5, 2014 at 5:20 am
CCTV is reporting pinger signal at 25.59S / 101.29E
The line of sight speed of INMARSAT 3-F1 to that position at 0:11 UTC was -0.0072 km/s.
xiak said,
April 5, 2014 at 7:53 am
a topo correction to my previous post, about BFO:
“Yes BFO includes both D1 and D2.”
should be:
Yes BFO includes both D3 and D2.
@Ole
“Is there a public source that has more on this D1,D2,D3 stuff” –
All the public source I have is the pdf from Inmarsat. and airlandseaman’s and my own reverse calulcation of the BFO at first time point (known position, known vecolity) matches very well Inmarsat’s figure (~87Hz), if we assume D1 is small to zero.
xiak said,
April 5, 2014 at 8:04 am
**An added discussion to my 1st post:
Why AES doesn’t compensate the Doppler shift on the random access channel for its initial PING burst?
We see that technically it’s also possible that AES can measure the Doppler shift on the global downlink broadcast channel and use it for AFC (Automatic Frequency Compensation) on its uplink random channel: The downlink broadcast channel is pre-known to the AES, so AES knows its nominal frequency very well, and once AES’ receiver is synchronized, i.e. locked, to that broadcast channel by successfully decoding the ‘pilot’ preamble transmitted on it, AES knows the actual frequency of it and can derive a delta frequency, which is seen as the Doppler shift on the downlink from satellite to AES. This delta could then be used to compensate AES’s uplink channel. During the communication between AES and satellite, AES can continuously measure the delta frequency of the downlink channel – either the global download broadcast channel or an traffic channel dedicatedly allocated to that AES by GES, thus apply compensation on its unlink in a ‘run-time’ manner.
It’s straightforward and easy, isn’t it?
Yes. And we have seen many patents from various companies claiming IP on such mechanism – though with subtle differences from one another other.
But, on the other side, it is NOT always an optimal approach to apply such ‘run-time’ frequency compensation by AES, given a specific satellite communication system in use. Sometimes, it is even impractical, especially using merely such ‘run-time’ compensation.
Let’s take the communication between GES and AES using Inmarsat-3 F1 satellite as an example. As shown below, the forward link (from GES to AES) starts with a 6GHz band between GES and satellite, followed by a 1.5GHz band between satellite and AES; the return link (from AES to GES) starts with a 1.6GHz band between AES and satellite, followed by a 3.6GHz band between satellite and GES.
The ‘delta_F1’ is the Doppler shift measured by AES on the downlink channel; and ‘delta_F2’ is the compensation value AES is going to apply to its uplink channel.
GES ——(6GHz C-band)——>satellite —–(1.5GHz L-band) ——>AES (delta_F1)
GES <—-(3.6GHz C-band)——satellite satellite —–(1.5GHz L-band) ——>AES (delta_F1)
GES <—-(3.6GHz C-band)————–satellite tens of years) interoperability of GES, satellite and AES, plus the required communication protocol/device backward compatibility, forward upgrade-ability, capacity evolvement and so on and so on.
To summarize, there is the practical reason and benefit for GES-assisted compensation, i.e. for GES to measure the Doppler shift on the return link i.e. the link from AES to GES, and to provide the to-be-adjusted frequency shift to AES in digital way. Here the only parameter to be communicated on the broadcast channel is the frequency shift itself. The frequency shift may cover both the GES-satellite segment and satellite-AES segment, or may cover only satellite-AES segment. It is totally a business of GES itself, and it makes AES totally dependent of the handling/upgrade of GES or even satellite itself.
Further, I’m not here arguing that the ‘run-time’ measurement and compensation is inferior to the GES-assisted compensation, nor am I saying that they are exclusive to each other. Indeed they can work together and the ‘run-time’ compensation can supplement the other one. Even an AES is capable of measuring the downlink frequency shift and applying it for initial PING burst uplink compensation, it should also be able to support the GES-assisted compensation mechanism. Once receiving it from the broadcast channel, AES should apply it on its uplink channel. With such way, once can easy say that the total time on handshake, log-on or data/voice call setup sequence can be significantly reduced and thus the spectrum utilization is improved. Not only more money for the network operator but also a better ‘user experience’ for the satellite terminal users.
Honestly, I believe some newer satellite or handheld satellite terminals mush have had such ‘run-time’ compensation ability inbuilt.
As regarding to the AES terminal on Boeing-777 aircraft, I have enough reason to speculate (I’m not an insider of Inmarsat or the AES) that the AES on Boeing 777, fortunately or unfortunately, does NOT support the ‘run-time’ compensation – at least doesn’t support ‘run-time’ compensation for its initial PING bursts, so Inmarsat is able to log its measured BFO covering all D1+D2+D3. Another fact to support my point: Inmarsat once compares/calibrates its analysis against six other B-777 aircrafts to come to a final conclusion. Why against other ‘B-777’ aircrafts? Isn’t it a reasonable guess that because the AESs on all (or at least these six and the MH370) B-777 don’t compensate PING burst?
xiak said,
April 5, 2014 at 8:12 am
(Can @Timfarrar help to delete my last post right prior to this one? It’s terriblly unreadable, for reason I don’t know )
**An added discussion to my 1st post:
Why AES doesn’t compensate the Doppler shift on the random access channel for its initial PING burst?
We see that technically it’s also possible that AES can measure the Doppler shift on the global downlink broadcast channel and use it for AFC (Automatic Frequency Compensation) on its uplink random channel: The downlink broadcast channel is pre-known to the AES, so AES knows its nominal frequency very well, and once AES’ receiver is synchronized, i.e. locked, to that broadcast channel by successfully decoding the ‘pilot’ preamble transmitted on it, AES knows the actual frequency of it and can derive a delta frequency, which is seen as the Doppler shift on the downlink from satellite to AES. This delta could then be used to compensate AES’s uplink channel. During the communication between AES and satellite, AES can continuously measure the delta frequency of the downlink channel – either the global download broadcast channel or an traffic channel dedicatedly allocated to that AES by GES, thus apply compensation on its unlink in a ‘run-time’ manner.
It’s straightforward and easy, isn’t it?
Yes. And we have seen many patents from various companies claiming IP on such mechanism – though with subtle differences from one another other.
But, on the other side, it is NOT always an optimal approach to apply such ‘run-time’ frequency compensation by AES, given a specific satellite communication system in use. Sometimes, it is even impractical, especially using merely such ‘run-time’ compensation.
Let’s take the communication between GES and AES using Inmarsat-3 F1 satellite as an example. As shown below, the forward link (from GES to AES) starts with a 6GHz band between GES and satellite, followed by a 1.5GHz band between satellite and AES; the return link (from AES to GES) starts with a 1.6GHz band between AES and satellite, followed by a 3.6GHz band between satellite and GES.
The ‘delta_F1’ is the Doppler shift measured by AES on the downlink channel; and ‘delta_F2’ is the compensation value AES is going to apply to its uplink channel.
GES —(6GHz C-band)–>s/c –(1.5GHz L-band) ->AES (delta_F1)
GES<–(3.6GHz C-band)–s/cs/c –(1.5GHz L-band) ->AES (delta_F1)
GES <-(3.6GHz C-band)—-s/c tens of years) interoperability of GES, satellite and AES, plus the required communication protocol/device backward compatibility, forward upgrade-ability, capacity evolution and so on and so on.
To summarize, there is the practical reason and benefit for GES-assisted compensation, i.e. for GES to measure the Doppler shift on the return link i.e. the link from AES to GES, and to provide the to-be-adjusted frequency shift to AES in digital way. Here the only parameter to be communicated on the broadcast channel is the frequency shift itself. The frequency shift may cover both the GES-satellite segment and satellite-AES segment, or may cover only satellite-AES segment. It is totally a business of GES itself, and it makes AES totally dependent of the handling/upgrade of GES or even satellite itself.
Further, I’m not here arguing that the ‘run-time’ measurement and compensation is inferior to the GES-assisted compensation, nor am I saying that they are exclusive to each other. Indeed they can work together and the ‘run-time’ compensation can supplement the other one. Even an AES is capable of measuring the downlink frequency shift and applying it for initial PING burst uplink compensation, it should also be able to support the GES-assisted compensation mechanism. Once receiving it from the broadcast channel, AES should apply it on its uplink channel. With such way, once can easy say that the total time on handshake, log-on or data/voice call setup sequence can be significantly reduced and thus the spectrum utilization is improved. Not only more money for the network operator but also a better ‘user experience’ for the satellite terminal users.
Honestly, I believe some newer satellite or handheld satellite terminals mush have had such ‘run-time’ compensation ability inbuilt.
As regarding to the AES terminal on Boeing-777 aircraft, I have enough reason to speculate (I’m not an insider of Inmarsat or the AES) that the AES on Boeing 777, fortunately or unfortunately, does NOT support the ‘run-time’ compensation – at least doesn’t support ‘run-time’ compensation for its initial PING bursts, so Inmarsat is able to log its measured BFO of D1+D2+D3. Another fact to support my speculation: Inmarsat once compares/calibrates its analysis against six other B-777 aircrafts to come to a final conclusion. Why against other ‘B-777’ aircrafts? Isn’t it a reasonable guess that because the AESs on all (or at least these six and the MH370) B-777 don’t compensate PING burst?
xiak said,
April 5, 2014 at 8:19 am
oh! @Timfarrar, please delete my two last posts (as well as this one). They are broken and unreadable – I guess it is too long? thanks.
duncansteel said,
April 5, 2014 at 8:37 am
New post up on my website:
http://www.duncansteel.com/archives/551
Title: Information Pertaining to the Search for MH370
Cheers,
Duncan
Skwosh said,
April 5, 2014 at 8:41 am
@xiak (in reply to your very first post):
Thank you very much for describing this process – it certainly makes a lot of sense – and has the ‘simplicity’ appeal of not requiring the aircraft to do anything other than to reply on whatever frequency the ground station has instructed it to transmit on. Very simple and robust – the aircraft doesn’t have to ‘think’ about compensation at all (at the cost of a ‘sloppy’ setup stage). If you had not mentioned the detail about ‘clearing’ frequency space around the channel used for the initial un-compensated setup I think I would probably have been asking you about that!
From my routing around on the internet I have convinced myself that there are systems out there in various applications that *do* use GPS to do active pre-emptive Doppler compensation – but, for sure, that doesn’t mean that such a system was being used here – and I have no domain knowledge myself.
Like @Ole I think I still need a bit of time to convince myself that the north-track/south-track asymmetry would still look like it does if the BFO, as you and Mike are suggesting, is simply just the total Doppler aircraft->satellite + satellite->ground.
Ole said,
April 5, 2014 at 9:39 am
@Timfarrar,
please _don’t_ delete @xiak posts, that is very interesting stuff and highly appreciated. Thanks @xiak !
I thought a little more on that problem. From a strictly geometric perspective the asymmetry between north/south track at the end of the flight is attributed to the sat’s velocity. The sat had a high velocity southward at that time. The sat’s velocity is a vector that breaks the rotational symmetry around the sub satellite point.
The asymmetry around 19:40 can not be attributed to the sat’s velocity. At that time the sat was close to it’s northernmost point and hat a negligible velocity. So somehow the aircraft’s *position* (as opposed to only it’s distance which is rotational symmetric too) must contribute to that geometrical problem. If the AES had no clue of it’s position, how could it behave differently for north/south track? I tend to discard my gut feeling that this effect could be produced by the process you described in your first post.
I read the rumor somewhere, that the in-flight entertainment of Malaysia’s 777-200 had been updated recently. On it’s website Malaysia states it offers sat phone service to it’s business class passengers.
http://www.malaysiaairlines.com/hq/en/mh-experience/our-fleet/boeing-777-200.html
So maybe they upgraded their AES recently together with the in-flight entertainment ?
AndRand said,
April 5, 2014 at 10:15 am
Skwosh said,
April 5, 2014 at 8:41 am
@xiak (in reply to your very first post):
Thank you very much for describing this process – it certainly makes a lot of sense – and has the ‘simplicity’ appeal of not requiring the aircraft to do anything other than to reply on whatever frequency the ground station has instructed it to transmit on. Very simple and robust – the aircraft doesn’t have to ‘think’ about compensation at all
With satellite sending uplink frequency to A/C it is also not that complicated – just reverse the shift.
Ole said,
April 5, 2014 at 9:39 am
I thought a little more on that problem. From a strictly geometric perspective the asymmetry between north/south track at the end of the flight is attributed to the sat’s velocity.
Mind you, airplane velocity is at any time 4-5 times bigger.
GuardedDon said,
April 5, 2014 at 11:39 am
@ole
Very early on in this dialogue I posted that 9M-MRO, the aircraft flying MH370, didn’t have a high gain antenna therefore limiting the use of the satcom facility to the basic SITA flight deck Aero services and voice. That’s borne out by a photograph on one of the plane spotter websites only a few days before it was lost where it still has only the ‘sharkfin’ style antenna
It’s quite feasible that MA is upgrading the B777 fleet, 9M-MRQ does display the plate or saddle type high gain antenna that is required for hgiher bandwidth services like Swift Broadband.
Ole said,
April 5, 2014 at 1:31 pm
AndRand said,
April 5, 2014 at 10:15 am
——————-
Ole said,
April 5, 2014 at 9:39 am
I thought a little more on that problem. From a strictly geometric perspective the asymmetry between north/south track at the end of the flight is attributed to the sat’s velocity.
Mind you, airplane velocity is at any time 4-5 times bigger.
——————-
Mike’s model inspired me to reactivate my vector math that was corroding for 20 years. The sat’s velocity vector breaks the rotational symmetry of the problem. I did the calculation myself and can verify the sat velocity has the right size to account for the asymmetry between predicted north/south path for the end of the flight in the inmarsat chart. Inmarsat has a difference of ~80 Hz for end of flight. That is equivalent to a difference in rangerate of ~15 m/s. Because the flight paths north/south have opposite direction that gives a rangerate contribution of the sat’s velocity of ~7.5 m/s (Thanks @skwosh for this eyeopener). You can double check that against the values Duncan provided above.
—————————-
GuardedDon,
thanks for that information.
I’m in an inner conflict here. From my geeky geometry perspective: This three dimensional problem mainly has a rotational symmetry. If a scalar derived from this problem – i.e. the BFO – becomes asymmetric there *must* be a vector with influence on the problem that breaks the symmetry. For the end of the flight it’s the sat’s velocity vector. But at 19:40 there is no such sat velocity vector.
The only symmetry-breaking vector I can come up with for 19:40 is the vector between assumed position of the sat (over the equator) and actual position of the sat (on it’s northernmost point). Because the aircraft’s velocity vector is either same direction or opposite direction to this vector it’s symmetry-breaking” contribution is either negative or positive. That is what the two blue lines in Richard’s charts tell us:
http://s1311.photobucket.com/user/RichardC10/media/components_zpsead22843.jpg.html
(it’s still on my list to verify Richard’s calculations, but they seem very plausible.
And a back of the envelope calc:
– sat was ~1200 km off it’s mean position
– distance aircraft-sat was ~36000
=> ~36000/1200~=3% of the aircraft’s velocity contribute to the asymmetry
- Aircraft speed was ~200 m/s
=> contribution was 3% * 200 m/s = 6 m/s.
- Check that against the blue line in Richard’s chart)
In other words: If anybody has another explanation why there is a difference between predicted north/south path for 19:40 I will be happy to change my mind.
(getting late here)
Alex Siew said,
April 5, 2014 at 2:57 pm
From the LOS figures from Duncan’ latest post on his web ( in knots as derived from Mike Exner) together with the formula given by Duncan in his march 26 2.50am comment in this blog regarding the calculation of the satellite’s component of the Doppler effect, I think it is clear the BFO chart shows that the plane was not moving at all 6 completed pings. In other words the LOS was contributed solely by the satellite moving away from a plane which had crashed early on into the South China Sea.
The first LOS reading at 18.29 UTC should actually be a negative reading (satellite moving to crashed plane) whereas the other 5 r positive readings (satellite moving away from plane after reaching northern apex at 19.36 UTC.)
@GuardedDon, would appreciate your comments.
sk999 said,
April 5, 2014 at 4:10 pm
Ole,
Part of the reason for the asymmetry between North and South at 19:30 is that the North track has to head further West than perfect symmetry would demand because it needs to end up on the 40 degee arc at 00:11, when the satellite has moved considerably further South.
However, the biggest difference is that, if richardc10′s conjecture is correct, what is being plotted is not the absolute Doppler shift but rather the Doppler shift relative to what one would measure if the satellite were positioned on the Equator. Since the starting point is near waypoint MEKAR, 6.5 degrees North of the equator, the North and South tracks see a much different Doppler for this hypothetical satellite. It is not the way I would have presented the results, but it is the way Inmarsat did it.
Now, I’ve reproduced richardc10′s diagrams at least roughly, so I think his conjecture is correct. But it begs the question – how did Inmarsat adjust the measured Doppler shifts so it could plot them on the diagram? I have no idea, unless the SATCOM was computing them and including them in the ping packets.
richardc10 said,
April 5, 2014 at 10:00 pm
sk999,
>However, the biggest difference is that, if richardc10?s conjecture is
>correct, what is being plotted is not the absolute Doppler shift but >rather the Doppler shift relative to what one would measure if the
>satellite were positioned on the Equator…..
>But it begs the question – how did Inmarsat adjust the measured
>Doppler shifts so it could plot them on the diagram?
There is still some discussion about component D3 and whether that is compensated by the system or not, but I think that we are seeing the raw data in the Inmarsat plot, that is D1+D2+D3 plus a system bias.
D1 is not quite as you stated, it is
the Doppler shift relative to what one would measure if the satellite
were positioned on the Equator MINUS the Doppler shift one would
measure if the satellite was at the actual position
This is the error induced by the aircraft system by the calculation method used onboard. D1 is not directly a Doppler (i.e an effect of velocity), it is an error induced by an incorrect calculation of the Doppler.
D2 is the Doppler component due to the velocity (along the line of sight) of the satellite itself.
Ole said,
April 5, 2014 at 11:14 pm
My sloppy back of an envelope calculation to check if the 19:40 value of richardc10′s model holds water triggered another thought:
In an earlier post (April 4, 2014 at 12:08 am) I tried to describe that the asymmetry due to sat velocity holds information which can be used to describe cones of equal rangerates due to sat velocity. These cones along the sat’s velocity vector are sets of positions on which the aircraft must have been and thus constrain the possible positions of the aircraft for the times of each pings.
The “19:40 asymmetry” of course also holds information. It constraints the set of possible velocities of the aircraft parallel to the vector between assumed position of the sat (over the equator) and actual position of the sat (on it’s northernmost point).The deeper the dip in BFO at 19:40 the higher the aircraft’s velocity parallel to that vector.This is interesting because this velocity component is mainly tangential and not radial as everything else. The effect is position/heading dependent but can be used to further curtail the range of possible speeds the aircraft had at that time.
This effect in other words is the fact that the blue line in Richard’s diagram is caused by “something”. In measuring the values of the blue line you also measure that “something”.
@richard10c: wouldn’t it be fun to check how that blue line changes if we assume an aircraft speed of let’s say 350 knots?
@sk999,
I too had pondered the asymmetry you describe in your first paragraph. Of course you are right. This asymmetry is not part of a single ping but arises because the timeline of the pings has to comply with the constraint, that there must be a possible trajectory through the constraints of all pings. Because the 19:40 ping was very early in the unknown part of the trajectory, small variations at that moment allow big variations in the outcome. So this asymmetry probably is very small.
richardc10 said,
April 6, 2014 at 3:22 am
@Ole
>wouldn’t it be fun to check how that blue line changes if we
>assume an aircraft speed of let’s say 350 knots?
350kt eh? The Haixun 01Option perhaps?
Having said before that the BFO model is only semi-quantitative, by looking at the model differences between different tracks I am breaking my rule immediately, so everything below has a _massive_ health warning attached.
I selected from my route model the great circle routes to three points on the final ping arc which require constant speeds of 470, 400 and 350kt. 470kt (or rather 469kt) was shown on the AMSA map for 28/3/14 as one of the speeds to the original search areas to the SW of Perth, 400kt as the speed to the new search area West of Perth and 350kt is the (modelled) speed to the Haixun 01 reported acoustic-ping location.
I ran the model for these three speeds, that is calculated the modelled BFOs for the ping times. The model results are shown at:
http://s1311.photobucket.com/user/RichardC10/media/6-apr-_zpsb4aa539c.jpg.html
I have supressed the North route model and only show the plot from 18.30 onwards, i.e. the supposed time of the final turn South. This plot is rather unclear due to the large change in BFO over the time from 18.30 to 00:11 so I have detrended the data here:
http://s1311.photobucket.com/user/RichardC10/media/6-apr-detrended_zps2ff6cd50.jpg.html
I have removed a linear trend with time from the data and models to reduce the range of BFO. This is just a presentational gadget, it does not change the differences between the points at each ping time.
The 470kt route is the best fit to the data, but this can only be regarded as coincidental. The 350kt Haixun 01 option is the poorest fit. Some points from the analysis:
1. Detrended this way, there is some more evidence of 5Hz steps in the data that you referred to before. The AES transmitter must have some quantisation in its adjustment (for channel selection and Doppler compensation), perhaps it is 5Hz?
2. The differences in the model predictions of BFO at each point are between 5-8Hz, so the data will have to be corrected for causes unrelated to D1, D2 and D3 to much better than those figures to allow any model to distinguish between the tracks (assuming the aircraft kept a steady course in the first place). A transmitter frequency quantisation of 5Hz will be significant in this. Sounds tough. My simplistic model is not even close to allowing that.
What has surprised me is how courses as different as those corresponding to 470kt and 400kt (never mind 350kt) can be consistent with the (unseen) ping-time delay (pin-arc) data; why didn’t the ping-arc data pin things down quickly? As a separate exercise I am looking at the options for the courses and whether the ping-arc and ping-BFO models can distinguish between them, given different ideas for the errors in each dataset.
Skwosh said,
April 6, 2014 at 3:28 am
@richardc10 @Ole
Yes – D3 – need to try to understand/justify why doing sat->ground (D3) correction at the *L*-band rather than C-band frequency seems to give a good fit. Been re-reading comments and now understand what you (both) are saying: that the signal is expected to be more or less immediately down-converted again to L-band when it hits the ground – and that if you twiddle the ‘fixed’ frequency of the oscillator used to do this down conversion then you could also do the Doppler correction at the same time – but hard to understand how the *C*-band D3 that Nature *must* be adding on transit from sat->ground wouldn’t either *all* be there in the measurement/BFO or *not* be there at all in the BFO because it was corrected out by the hardware before measurement.
@Ole has I think suggested that it’s possible the sat->ground link wasn’t up converted by the sat at all for this particular signal – I have no idea if that is plausible as no domain knowledge myself – but if this *is* plausible then that’s a perfectly good explanation/justification for there being an *L*-band sat->ground Doppler shift in the BFO rather than a C-band shift.
I have attempted a grand synthesis (!) of ideas so far:
[1] There is an initial ‘sloppy’ setup phase in the communications.
[2] None the less, the aircraft does have the kind of imperfect pre-emptive correction system we are speculating about – and this *is* used for the *initial* response (because although it is not perfect it is better than nothing and reduces the sloppiness (bandwidth allocation required) during the initial setup).
[3] The aircraft includes information digitally about the (imperfect) correction it applied in its initial response transmission.
[4] This initial setup phase is *special* because it is *not* expected to be ‘perfectly’ Doppler corrected – and both the actual frequency received on the ground and the information about the imperfect shift (digitally) included in the message by the aircraft are required so that the ground station can work out what the actual Doppler shifts are and can then proceed with a ‘perfect’ correction scheme for the subsequent communications (along the lines proposed by @xiak).
[5] Because this initial setup phase is a bit ‘special’ maybe this could somehow be linked to a justification for the use of the L-band from sat to ground? Yes – I know – I’m clutching at straws here!
[6] If this sort of scheme were in place there could maybe be no need for *any* correction of the frequencies received on the ground because in case of the setup phase we actually want to use the information in the frequency shift, and once the ‘perfect’ correction is going on for subsequent communications there is – kind of by definition – no need for any correction!
[7] Were all this true then the BFO could indeed be a real observation of a real L-band signal received on the ground resulting from the initial setup ping from the aircraft, and we would indeed expect the BFO to include all the components suggested in the @richardc10 model: imperfect aircraft correction, natural Doppler from aircraft->sat and natural Doppler from sat->ground.
Not really seriously suggesting this *is* how it works – but it may set-off some ideas in others – and or may tempt/provoke someone who really does know how it works to feed us a bit more info!
richardc10 said,
April 6, 2014 at 3:57 am
@Ole
Sorry, uploaded wrong plots. Correct ones:
http://s1311.photobucket.com/user/RichardC10/media/6-apr-_zpsb79c96c4.jpg.html
detrended
http://s1311.photobucket.com/user/RichardC10/media/6-apr-detrended_zps5a44989e.jpg.html
Apologies
Skwosh said,
April 6, 2014 at 5:15 am
@Ole “The deeper the dip in BFO at 19:40 the higher the aircraft’s velocity parallel to that vector” … yes – I get you. Am pondering.
sk999 said,
April 6, 2014 at 5:46 am
Here is a link to a patent from 1998 that describes how the AFC (Automatic Frequency Compensation) on Inmarsat communication links is supposed to work.
http://www.google.com.br/patents/US6008758
The AES is supposed to monitor the incoming P channel signal to determine the Doppler shift and apply it to the transmitted signal, but that wastes one receiver chain that could be used for another purpose (e.g., for conducting a phone call). The patent then explains how some vendors work around this limitation:
“One method that has been used in an attempt to address this problem is to pre-compensate the transmit frequencies based on a calculated Doppler shift rather than a measured Doppler shift. The method calculates the Doppler shift using the satellite location, the aircraft location, and data which defines flight characteristics (e.g., velocity, ground speed, heading pitch, roll, etc.). Much of the data needed to calculate the Doppler shift comes from the aircraft’s Inertial Reference System (IRS).”
This description is exactly what we have been assuming was happening on board MH370.
Ole said,
April 6, 2014 at 6:03 am
Richard,
no apologies needed. This is amazing work. I think your modeling shows how the signatures of the two asymmetries could show up in the BFO plot. At the end of the flight the rangerate contributed by the sat velocity “dominates”. At 19:40 the aircraft’s velocity parallel to the “sat out of mean position”-vector dominates. It would be interesting to see the error bars on the original inmarsat plot.But nevertheless, if well understood how the two asymmetries contribute to the BFO it should be possible to further suppress the noise/measurement error by applying cross correlation techniques over the whole time series.
I think the actual size and offset of the BFO really doesn’t matter that much, the important thing is to filter out the signatures of those two asymmetries, because _they_ hold the additional information. And the fact that inmarsat _can_ measure those asymmetries was the reason for them to go public with their data.
richardc10 said,
April 6, 2014 at 6:27 am
@skwosh
@Ole “The deeper the dip in BFO at 19:40 the higher the aircraft’s velocity parallel to that vector??? … yes – I get you. Am pondering.
The dip at 19.40 is caused by the change in component D1 as shown in the lower pane of
http://s1311.photobucket.com/user/RichardC10/media/components_zpsead22843.jpg.html
Components D2 and D3 change little between 18.30 and 19.40. The change in D1 is a change in sign of the error of the AES compensation (from your own idea), which is function of of speed and heading, and heading change. So if the headings and heading changes are the same, yes D1 is a simple function of speed.
@sk999
Nice find. So the IRS data is used, rather than some internal system (which would have been too complex a solution). I wondered for a moment about what if the IRS was sending bad data to the AES. However, a check in the model shows that if the IRS were sending the AES a course that was even 10degrees off, the compensation is massively wrong (100Hz).
MtKlimber said,
April 6, 2014 at 6:31 am
http://www.cnn.com/2014/04/06/world/asia/malaysia-airlines-plane/index.html?hpt=hp_t1
Quote:
“More detail has been added to the flight path calculated by investigators, a senior Malaysian government source told CNN on Sunday.
After reviewing radar track data from neighboring countries, officials have concluded that the passenger jet curved north of Indonesia before turning south toward the southern Indian Ocean. Its path took it around Indonesian airspace.
Malaysian government officials have said previously that the plane appeared to have been deliberately diverted from its original course, which would have taken it north to Beijing.
“What’s also interesting about this route … is it appears it goes to the designated waypoints that we (pilots) use (and air traffic control uses to give directions),” said CNN aviation analyst Miles O’Brien. “This particular route that is laid out happens to coincide with some of these named intersections. So what it shows is an experienced pilot somewhere in the mix on this.”
O’Brien said that an experienced pilot who had flown in the region would know where radar coverage begins and ends and where radio communication handoffs occur.”
Skwosh said,
April 6, 2014 at 8:05 am
@Richard Thanks very much for clarifying. I (think/hope!) I am up to speed on the ‘meaning’ of your D1 now (and now appreciate the elegance of your choice of how to calculate/separate the different components and of your graphical presentation of them!). I am into ‘pondering’ mode more with regard to how at that particular ‘moment’ (when the sat was roughly static) it might be possible to visualise/geometrise how aircraft pos/vel might be constrained – but agree that in principle there is nothing ‘special’ about that or any other time with regard to how well everything fits current conjecture.
Skwosh said,
April 6, 2014 at 9:29 am
@sk999
My quick ‘skimming’ summary of that patent so far is as follows:
It is a patent for doing Doppler correction by (1) aircraft measures the Doppler induced frequency shift on an incoming transmission of known (original) frequency coming from the sat (2) aircraft deduces what the Doppler induced shift must currently be from this (3) aircraft applies opposite shift (accounting for the different frequencies involved) to its transmission (4) there is lots of messing about to take account of the fact these measurements will have a ‘shelf life’.
So – I don’t think it is *directly*describing some of the ideas we are thinking about here around an (initial?) imperfect pre-emptive Doppler compensation?
However, the patent also contains a *remark* (which you quoted – *excellent* find) – along the lines of: “*If* there was a way to do compensation without having to make this initial measurement then that would be groovy…??? I don’t think the patent actually talks about any method for doing this (pre-emptive compensation) other than to say that up to that point in time (1998?) methods for doing this kind of pre-emptive correction based on information from the inertial navigation systems were a bit duff and unreliable, and not easily standardised – and so that probably wasn’t a good idea at the time.
Not necessarily saying anyone else is reading this differently – just trying to summarise how I’m currently reading the patent. I will try to take more time to have another read through!
sk999 said,
April 6, 2014 at 11:03 am
MtKlimber,
I thought it obvious 2 weeks ago that the route was deliberately avoiding Indonesia (and Thailand) and am a bit surprised no one else mentioned it until now. The “Beijing Event” radar figure (for which there are two photos on the internet, including one in the main article above) is the main evidence. The “Southern route” I came up with at the time went from IGARI (last communication from the flight) Southwest to Penang, Northwest to VAMPI to MEKAR to NILAM, then Southwest to NIXAL and a final turn from there to whichever final route one chooses. The radar plot covers Penang to VAMPI and ends just short of MEKAR. The “18:30″ turn South, which occurs around NILAM, is actually a turn to the Southwest, passing between Sumatra (Indonesia) and the Nicobar/Andaman islands (India). The final turn at NIXAL happens around 19:15. The new CNN map follows that route almost exactly. They just should have asked me first.
Skwosh – I did not mean to imply that the AES used the new method described in the patent (we have no idea if any reduced the method to a working product). Rather, patent applications generally describe the state-of-the-art at the time, and in this particular case the information was particularly informative. That is all I wanted you to take away.
GuardedDon said,
April 6, 2014 at 11:05 am
@MtKlimber at 6:31am
It was the abyssmal reporting of the technical implications & issues related to this story that brought me Tim Farrar’s blog nearly 4 weeks ago, that CNN story is shows that there is yet no motivation in the press to test out the stories they are relaying.
If MH370 did indeed divert back across the Malaysian peninsula, turn NW over the Straits of Malacca and turn again over/around the north of Sumatra it overflew the RMAF’s radar installation atop Western Hill on Penang Island & passed close by the Indonesian military radar installation near Sabang on Palau We, an island off the north Banda Aceh coast.
These installations are described on various local language websites & blogs.
Of course, its not possible to know whether either or both of these sites were operational in the early hours of Saturday 8th March but I’d like see someone at a MoTM press conference pose a credible question.
Skwosh said,
April 6, 2014 at 11:31 am
@sk999 Cool – that was my assumption of your intentions – just wanted to clarify my interpretation – and it is very helpful and interesting that you have found this patent and it adds a *lot* of very useful perspective and context. Cheers.
@GuardedDon: You say “[...] no motivation in the press to test out the stories they are relaying” – Yes – agreed absolutely – this is what got me into all of this too. I’m not saying there’s a conspiracy – it was just finding myself increasingly frustrated saying “but… but… if that’s true then surely that other thing they just said can’t also be true… so *why* aren’t they asking about this?”
GuardedDon said,
April 6, 2014 at 12:20 pm
No, definitely no conspiracy theories! I’d just like to see some robust interrogation of the ‘story’ instead of the ‘news’ being a simple conduit for press releases.
The old Reithian principles of inform, educate and entertain (in UK public broadcasting) are fading fast if not gone entirely. Style & presentation winning over content. Maybe ‘internet speed’ is just too fast.
Enough at the water cooler, back to the job at hand…..
richardc10 said,
April 6, 2014 at 3:07 pm
Late night speculation – others were pondering the 19.41 ping earlier today and any special meaning it might have. Also, the suggestion from sk999 that the final turn was at waypoint NIXUL at 4N, 92E at 19.15UT (sk999 said NIXAL, but that is North so I think NIXUL was meant). At 19.41 the satellite is by coincidence near its maximum north latitude so component D3 is near zero. As we are not sure how D3 is calculated as a function of satellite rangerate that is useful as the issue is not relevant at 19.41. To make the predicted D1+D2 match the data, the course from NIXUL has to be around 151true. More Southly courses don’t match. That takes it very close to the easternmost search area being investigated today (Sunday). If that course is extended (by 3.5hours past the last ping arc) you get to, um, Perth.
http://s1311.photobucket.com/user/RichardC10/media/CoursefromNIXUL_zpsa6009798.jpg.html
meadows.st said,
April 6, 2014 at 3:16 pm
re: @airlandseaman, @xiak, @skwosh, @Ole & @richardc10 (and others’) discussion on D1 + D2 + D3 interpretations for BFO.
I have been following all these conversations and captured what I hope is the essence in my summary worksheet. If I understand the approaches, the assertions by @airlandseaman and @xiak cannot both be true for the ping burst. I am taking the same approach as @richardc10 (and @skwosh and @Ole I think) in breaking down the potential components further. I would really like to know if @Xiak and @Airlandseaman are both assuming what the D1 component is or if one of them knows for sure that the a/c does or does NOT perform a correction before sending a response to the s/c.
My biggest question in the BFO data is why were Inmarsat unable to generate “predicted” BFO values that matched the measured BFO values in the first three data points where the position, heading, speed, and frequencies of the s/c and a/c were entirely known. Even if there is/was a bias in the system, shouldn’t Inmarsat be able to calculate what that bias is/was? In short, I can understand why a model does not fit the unknown measured data points but if the same model doesn’t even fit the known data points then what conclusion is one able to draw at all in terms of correlation to the unknown position/speed/heading data points?
As I am developing my model that is trying to in essence iterate through the ping arcs, assumed headings, assumed speeds, and BFO data to calculate potential best fit paths (in essence, an independent analysis but attempting to calculate similar quantities as DuncanSteel (although not at his level in terms of plotting in STK)) the interpretation of the public data from BFO is crucial to my analysis. I believe that the ping arc data already incorporates a “large” error but I think the BDO-interpretation will generate a magnified error (since I am using the heading/speed assumptions to calculate the next starting point for an iterative best fit on the subsequent ping arc.
… Still working.
Ole said,
April 7, 2014 at 1:49 am
If the inmarsat modelling of north and south path is not bogus, at 19:40 the aircraft’s position and speed vector *has to* contribute – via preemptive compensation (how else?) – to the BFO. If you strip the problem down to pure geometry that becomes “mathematically” as evident as 1+1=2.
Digesting that, the question arises, if the terminal knew it’s position, then it must be the simplest thing in the world to also transmit this position? I’m convinced the positions were *not* transmitted but here we have another source for conspiracy theories, as if there weren’t yet enough such sources. The question of the “missing” hourly pings at 18:07, 19:29, 23:30 also remains unanswered.
It seems Inmarsat is in a very delicate position here. If they become notorious for not treating their customer’s data with the utmost confidentiality they are out of business. On the other hand from the point of view of accident investigation they can’t help to conceal negligence either. Their delicate position might explain why they are very tight-lipped.
To D3:
In the GES probably a technical compromise has to be found
a) to only feed frequency offsets into the receiving and demultiplexing equipment that can be handled anyway (i.e. in the range of the residual L-Band doppler).
b) to not impair the SNR of the C-Band signal more than necessary by a too pedantic doppler correction.
Looking at the inmarsat modeled data I would suspect something like a saw-tooth function as residual D3.
@xiak mentioned that there is also a dynamic component to D1 which is caused by dynamic changes in aircraft speed vector due to turbulence or turns. richard10c mentioned that a 10 degree error in heading causes a ~100Hz BFO. A typical turn rate would be 1.5 degree per second. http://en.wikipedia.org/wiki/ROT_(aviation)
If one knows how frequently the AES updates it’s doppler compensation, one could predict the typical ranges for these dynamic BFO contributions.
Skwosh said,
April 7, 2014 at 4:30 am
@Ole You say: “[...] then it must be the simplest thing in the world to also transmit this position [...]???
I’m thinking there may be a difference between what was knowable at the time of the transmissions and what is knowable now. We think most of these transmissions were essentially minimal handshake transactions for keeping the ‘session’ going. Is it conceivable that what has actually been *logged* in the case of these (minimal handshake) transmissions could just be lower-level ‘physical’ stuff like exactly when a transmission is sent/received and at what frequency? Presumably information to be logged comes from each separate system/device along the chain that process the signals – so only the systems that actually had anything passed on to them to process would do any logging?
So, maybe (for minimal handshake):
[1] Ground transmits to aircraft.
[2] Aircraft transmits minimal response (using imperfect correction?): ‘yes, I would still like to keep the session going but otherwise I have nothing to say at this time’.
[3] The end.
[4] So, no sustained data transmissions required, no fancy perfect Doppler compensation process is started, so no detailed record of the correction data sent by the aircraft (that would be required to do these next steps) was made because the parts of the system that would handle this (and would perhaps have logged this data) weren’t invoked?
On the topic of conspiracy though… maybe it’s just me… but the images in the Inmarsat ‘News’ item all seem to have been removed: http://www.inmarsat.com/news/malaysian-government-publishes-mh370-details-uk-aaib/ Probably cock-up rather than conspiracy!
—
@meadows.st Agree about the lack of Inmarsat’s own fit at the start of the BFO plot. Can’t help thinking this has some info in it (though I guess we have no idea what they think the errors are).
Also, looking at your excellent summary on the spreadsheet (Id=8) of the ping data gets me thinking: Are we absolutely sure Inmarsat actually do have reliable earlier ping times/distances?
The actual statement (in the BFO release) says: “The ground station log recorded six complete handshakes after ACARS, the aircraft’s operational communications system, stopped sending messages.??? and “Inmarsat was then able to calculate the range of the aircraft from the satellite, and the time it took the signal to be sent and received, to generate two arcs of possible positions – a northern and a southern corridor.???
Do we know for sure that someone who would know (Inmarsat spokesperson etc.) has claimed that Inmarsat actually do know the distances for the other handshakes with the same kind of accuracy as they claim for the last completed handshake?
If Inmarsat do *not* actually have this data it would certainly help explain why they haven’t released it! It would also perhaps explain why some of the open questions with regard to the early stages of the flight that we’ve assumed they (Inmarsat) would surely be able to constrain a lot better if they had the distances still seem to be open questions. This idea is also not necessarily incompatible with reported Inmarsat statements about the *trends* in the ping distances over time – they may for some reason have data that allows them unambiguously to compare/order the distances of (some of) the pings without necessarily knowing very accurately what those distances were (I agree this is clutching at straws). However, I don’t think the idea that Inmarsat are uncertain about the earlier pings is incompatible with @GlobusMax’s (excellent) work – what @GlobusMax has demonstrated (I think) is that the two Inmarsat southern routes are consistent with a *common* set of ping distances (which he has deduced) – this does not exclude the possibility that Inmarsat themselves may have been guessing/approximating what those ping distances were (for all but the last ping) and/or Inmarsat were using some other constraint that would have the same effect (might also explain why they didn’t put any other arcs on their illustration of the routes – not because they were being coy – but because they didn’t want to give the impression that they knew more than they actually did?).
Skwosh said,
April 7, 2014 at 8:16 am
The Inmarsat .jpg illustrations seem to have re-appeared now (I was getting not-found-on-server errors earlier) – that’s a relief – and they don’t seem to be any different – I was starting to get a bit paranoid!
Ole said,
April 7, 2014 at 8:45 am
Today’s search map for the first time has the seventh ping ring.
http://www.jacc.gov.au/media/releases/2014/april/mr_012-1.jpg
Counting pixels the two ping rings seem at least 50 nm apart. To get from the sixth ping ring to the seventh in eight minutes the aircraft would have needed a _radial_ speed of 375 knots. Probably the depicted rings are only symbolic.
airlandseaman said,
April 7, 2014 at 9:53 am
It may help to understand the interpretation of BFO to understand that the system does not need to correct the Doppler for communications to take place. The AES makes a first order correction for the sole purpose of minimizing the a priori allocation of spectrum for “guard bands” around the nominal spectrum occupied by the signal received at the LES. The specification for AES is +/- 30 Hz as I recall. IOW, the AER offsets the inbound TX frequency by an amount estimated, within 30 Hz, to put the received signal at the LES in the middle of the channel filter. This also speeds the carrier and clock recovery loop delays, reducing the time slot that must be allocated for a packet. The AER offset is determined by monitoring an outbound pilot carrier, from which an accurate outbound Doppler is determined by comparison to a stable local reference. The offset value is communicated as part of the “handshake”. Thus, the BFO values are already adjusted for the offset such that the BFO=Expected – Observed. D3 is the C band correction. I’m confident in the analysis because, contrary to some comments I have read here, the speed calculated for the known position and speed at the airport ramp was ~1 kt. You could not hope for better validation of the math. In fact, the residual difference of 1 kt is easily explained by the fact that my BFO values are taken from a print out of the graph on page 2 of Annex II, which could easily be off by that amount.
AndRand said,
April 7, 2014 at 9:54 am
Ole said,
April 7, 2014 at 8:45 am
Today’s search map for the first time has the seventh ping ring.
Isn’t it 6th ping recalculated?
Ole said,
April 7, 2014 at 10:11 am
AndRand,
“Isn’t it 6th ping recalculated?”
good question, hadn’t considered that interpretation. OTOH the Hai Xun 01 was listening on that ring already two days ago.
And from today’s press conference transcript:
“…there were a series of arcs which signified where each exchange or handshake occurred between the satellite and the aircraft. The sixth exchange is represented by this line here. A short time after the sixth exchange, there was another exchange with a slightly different signal. This was a matter of, I think, about eight minutes after the sixth ping, and the expert team consider this as very significant.”
http://www.jacc.gov.au/media/interviews/2014/april/tr007.aspx
AndRand said,
April 7, 2014 at 10:30 am
Two pings with such small distance difference showed couple of weeks ago could shorten the search for couple of weeks… It looks like rings are in distance of ~10km. Flying jet needs 40 seconds to cover that distance.
Fitzcarraldo said,
April 7, 2014 at 10:35 am
Firstly, my thanks to Annette (April 3 at 3:01 am) for pointing out my March 26 transcription error in the longitude at the 00:11 UTC handshake. As I cannot edit my original post, for the record the coordinates (in degrees) of Inmarsat 3-F1 at the contact times provided by Duncan Steel on March 26 are as follows:
UTC Latitude Longitude
16:30 1.129 64.551
16:43 1.194 64.549
16:55 1.252 64.547
17:07 1.306 64.545
18:25 1.563 64.531
18:27 1.567 64.531
18:29 1.571 64.531
19:40 1.640 64.520
20:40 1.576 64.510
21:40 1.404 64.500
22:40 1.136 64.490
00:11 0.589 64.471
Secondly, the ping circles I back-calculated from the two flight paths on the poor-quality Inmarsat slide (‘Example Southern Tracks’) released on March 25 (see my post on March 27 at 6:01 pm) had somewhat different radii to those published by Duncan Steel on his Web site on April 4, so I have modified my Google Earth model to use the latter (although I am not certain they are correct either). My latest screenshot (link given below) also shows the location of the Chinese ship Haixun 01 on April 5 (black-box pings detected?) and the approximate search area of Australian ship Ocean Shield on April 7 (1140 km from Learmonth and 1760 km from Perth, according to AMSA) where black-box pings were also detected using more-accurate equipment.
http://i2.photobucket.com/albums/y9/imageuser/MH370-Estimated_routes_for_3333_to_450_knots.jpg
The coloured example flight paths on the screenshot are my rough calculations for the following ground speeds (knots):
450 yellow
400 red
380 orange
360 purple
350 blue
333.3 green
The reason I plotted a path for 333.3 knots is that I calculate it was the average ground speed between 2:02 MYT and 2:22 MYT, assuming the slide (Malaysian military primary radar plot) shown to the families in Beijing on March 21 is valid.
N.B. In deriving the above-mentioned flight paths I did not assume MH370 avoided overflying northern Sumatra. I know CNN reported on April 6 that an unnamed Malaysian official said the aircraft did not overfly Indonesia (CNN stated that ‘investigators reached this conclusion after reviewing radar track data from neighbouring countries’). What CNN alleges may have been the case, but, as far as I know, it has not yet been corroborated. The Indonesians stated on March 19 that they did not detect MH370, so it is not clear what new radar information, if any, is available to the Malaysian government.
http://i2.photobucket.com/albums/y9/imageuser/MH370-Estimated_routes_for_3333_to_450_knots.jpg
Anyway, if MH370 did avoid overflying Sumatra the flight paths in my graphic would all be shifted northward and have a somewhat greater curvature.
AndRand said,
April 7, 2014 at 11:06 am
Anyway, if airplane took turns, steady heading (magnetic? gps?) and speed is a strong assumption.
However, it would be great if we could instead say Doppler shifts are credible to match LOS speed.
ps. regarding my previous statement on 8min pings – looking closely it looks more like ~50km than 10. With 350kts it is ~5mins in shortest line so 8mins gets plausible thus not implying the last ping after water landing.
richardc10 said,
April 7, 2014 at 12:44 pm
@ole, @airlandseaman @skwosh etc
OK, I’m in brainstorming mode here, so don’t shoot me down immediately. Bear in mind that we have as yet _no_ idea what happened on-board MH370. If we did, we wouldn’t be here. Anyway, this blog is all speculation anyway, since we have minimal data.
1. Airlandseaman’s point that the system offset at 16.30 is consistent with the C-band frequency of 3.6GHz down (and the known satellite rangerates) is valid. Therefore, we have to assume that the Inmarsat plot includes the C-band Doppler due to the downlink to the Perth groundstation. The Inmarsat explanatory diagram supports that position. The frequency offsets at the GES due to the small LOS speed of the Inmarsat 3F1 satellite (<10m/s) are tiny in satellite comms terms. A low Earth orbit satellite can give a LOS speed to a groundstation of more than 5000m/s so the Inmarsat system may be quite capable of dealing with the full C-band Doppler without any compensation.
2. As described by airlandseaman there is a power-on handshake that sets a baseline. The AES will assume (my assertion) that the aircraft is stationary when this handshake happens.
3. The analysis presented in the Inmarsat plots and graphs was their early ideas intended to convince the authorities (and, most terribly, the families) that the aircraft went South, nothing more. If the reader is not convinced of that conclusion by the original Inmarsat analysis, stop reading now! However, Inmarsat have shared nothing more since that, so I am free to speculate.
4. From the Inmarsat graph there is something happening at 18.27 for a few minutes. The regularish (every hour or so) ping pattern we see later is not happening. The Inmarsat graph labels this as a ‘Possible turn’. However, what if this pattern indicated a restart of the system, or at least an interruption of the INS feed of position and speed data to the AES? If the correction (based on the aircraft’s speed and heading) made by the AES to the uplink frequency is removed the BFO will jump in the direction shown at 18.27, by my calculations. The system then settles down again by 18.30, but what if the bias has been changed? I don’t have the technical details of what would happen in that situation. I am working some numbers, but they are not convincing yet.
5. If the dataset is divided into two, before and after 18.30, then they can be each be fitted (roughly) using a model with the C-band downlink frequency, but with a different start offset.
As I said earlier, this is brain-storming stuff (and probably wrong). However, the search area changed a week or so ago. The original ping-arc data should have been convincing and defined the search area precisely, if it was well-founded, yet suddenly the search area moved massively to the NE. The interpretation of the data changed for some reason, IMHO.
AndRand said,
April 7, 2014 at 12:55 pm
richardc10 said,
April 7, 2014 at 12:44 pm
The original ping-arc data should have been convincing and defined the search area precisely, if it was well-founded, yet suddenly the search area moved massively to the NE. The interpretation of the data changed for some reason, IMHO.
Probably due to track assumed going north around Sumatra.
Fitzcarraldo said,
April 7, 2014 at 12:57 pm
The second link in my previous post should have been to an article regarding the statement by the Indonesians on March 19 that they did not detect MH370:
http://www.antaranews.com/en/news/93270/indonesian-military-radar-did-not-detect-missing-airplane
I don’t know why the screenshot I linked to in my previous post appears significantly smaller in my Web browser than the previous screenshots I posted, as the originals are roughly the same size. Anyway…
Regarding the handshake circles in that screenshot, as I mentioned in my previous post the radii are those posted by Duncan Smith on his Web site on April 4. Notice that the 08:11 MYT arc is a little further to the east than the corresponding 08:11 MYT arc in the Inmarsat graphic ‘Example Southern Tracks’. So, to show the difference between the two, I have added the latter arc (white) to my Google Earth model — see the following screenshot (I hope the image is larger and easier to view this time):
http://i2.photobucket.com/albums/y9/imageuser/MH370-Estimated_routes_for_333dot3_to_450_knots_plus_Inmarsat_08h11MYT_circle.jpg
(By the way, did anyone notice that the 450 knot flight path in the Inmarsat graphic appears to go over, or darn close to, waypoint RUNUT?) Mind you, I still wonder if that Inmarsat graphic is partly schematic rather than a precise plot of the 450 and 400 knot flight paths derived by Inmarsat.)
XocoLatte said,
April 7, 2014 at 1:31 pm
I read this last transcript of that news conference and got really annoyed. This investigation started to look like some stupid soap opera with twists and turns rather than a criminal investigation for 200+ human lives.
The winner sentence was something like this: “the 7th incomplete ping shows that something happened” — my God, really? They think that ping was associated with the aircraft running out of fuel and that is why they search the postulated location of that ping.
I am nothing more than a stupid layman either in satellites, airplanes or radio communation, but I learned a while ago that airplanes in an event of their fuel running out are capable of so-called thing as gliding, and depending on the altitude and flying speed where this event happened they can glide quite far away. So even if the last incomplete ping at UTC 0:19 would have indicated the fuel running out, the plane itself could have still glide far from that location.
Quite fishy, isn’t it?
Skwosh said,
April 7, 2014 at 3:10 pm
@richardc10 I am all in favour of brainstorming and being wrong!
And in that spirit (and what follows is a kind of metta-point rather than addressing your speculation directly)… I may once again have got the wrong end of the stick – but one thing I’ve been wanting to clear up for some time is: Can we confirm that the yellow southern Inmarsat track *does* or does *not* generate a reasonable fit to the green points on the BFO chart when the straightforward @airlandseaman method is used to generate the BFO?
BFO =
L_BandDoppler(moving aircraft to moving satellite) +
C_BandDoppler(moving satellite to ground)
I guess you could fairly easily test this and present the result graphically?
That yellow Inmarsat track, and those green points are the *only* example we have of (1) a track (though for sure we’ve had to approximate it from the picture) and (2) the corresponding BFO values that the Inmarsat model generates from that track.
If any hypothesis we have for interpreting the BFO is able to generate the green points from the yellow track (with a reasonable fit) then we can start to build some confidence that we *may* be getting somewhere in understanding how Inmarsat were themselves modelling and interpreting the BFO. Then, if a hypothesis gives a good fit to the southern track we might try to build confidence further by seeing if it is possible to fit the red (northern track) points on the BFO plot by using a plausible northern track. Though even if we can do both of these things it doesn’t mean we are right – and there could of course be other very good reasons why the hypothesis could be wrong.
However, if the hypothesis does not fit the green points well (which, if that were the case, would be clearly visible on a BFO plot) then it would help to make sense of why some of us might be focusing on trying to understand/come-up-with-ideas-for why that might be (as I think you are doing with your suggestion about an event/discontinuity that may be happening in the middle that is then introducing some sort of systematic error subsequently)…
airlandseaman said,
April 7, 2014 at 7:05 pm
Skwosh and @richardc10
Unfortunately, the Inmarsat “predicted” north and south tracks are utterly meaningless. They are pure fiction. No one knows for sure what path MH370 went down, so those predictions are not based on any facts. I recommend ignoring them. They don’t prove anything.
In the 3 plots below, the C band Doppler is correct and the L band Total Doppler is correct. However, as explained in the charts, we only have hard data (from ADS-B) for the first four aircraft positions, so the satellite induced L band Doppler and the aircraft induced L band Doppler values are only accurate for the first four points in the L band Doppler and Aircraft radial velocity charts. The math is correct for all 12 points, but the aircraft position is not known for the last 8 positions, so the airport lat/lon and range rates were assumed for all 8, just to check the software. In reality, the satellite portion of the L band Doppler is larger than depicted because of the assumed position for epochs 5-12. The airport is nearly due east of the satellite, so not much satellite induced Doppler from there. The aircraft was no doubt either farther to the north or south where the satellite to aircraft range rate would be higher than at the airport. The bottom line is that the plot of aircraft radial velocity is a little high for the last 6 samples (~5-15 kts if it went down to the southern Indian Ocean), but the first three are accurate and can be verified by comparison to the ADS-B data available online. I am working with Duncan to test several assumed speeds and positions to get better estimates of the two L band Doppler components.
http://www.duncansteel.com/wp-content/uploads/2014/04/All_Doppler_2014-04-02.jpg
http://www.duncansteel.com/wp-content/uploads/2014/04/L-band_Doppler_2014-04-02.jpg
http://www.duncansteel.com/wp-content/uploads/2014/04/MH370_Radial_Velocity_2014-04-02.jpg
Ole said,
April 7, 2014 at 11:50 pm
Assuming Inmarsat engineers know what they are modeling, their modeling tells us there *are* asymmetries between north and south track.
The only thing that is asymmetric in this problem is at 19:40 the sat’s position and at 0:11 it’s speed.
At 19:40 the sat’s speed is zero, so the asymmetry in modeled BFO *must* be caused by the aircraft’s speed (and *not* it’s radial speed because that is symmetric).
At 0:11 the asymmetry in modeled BFO can be caused by the sat’s speed vector, so the this asymmetry can be related to the the aircraft’s position relative to the sat’s speed vector.
Now also consider that these asymmetries are not only qualitative but also *quantitative*, so the size of the effects that cause them can be measured.
It’s pure geometry.
Alex Siew said,
April 8, 2014 at 3:29 am
@GuardedDon,
i had a look at Alteon’s description of the SATCOM system on 777 as well as the “System Description, Installation, and Maintenance Manual” published by Honeywell, one of the main manufacturers of such system. The Satellite Data Units or SDUs by Honeywell have an inbuilt battery.
The SDU on a 777 is located at rack E11, next to the APU battery at rack E10.
Skwosh said,
April 8, 2014 at 3:51 am
@airlandseaman
I agree that the Inmarsat predicted tracks are ‘fiction’, but I do not think that Inmarsat or anyone else here would dispute that. However, I think the (yellow) Inmarsat southern track is still very relevant to what we are trying to achieve here:
[1] Inmarsat have a method for generating BFO values from speculative aircraft tracks, but we do not know for sure what that method is.
[2] Inmarsat used their method to generate the green BFO points from a speculative southern track and the red BFO points from a speculative northern track. The green (southern) points give a good fit to the blue (‘measured’) points, whereas the red (northern) points give a bad fit to the blue points. The conclusion is that the aircraft *may* have taken the (particular) speculative southern track but that it could *not* have taken the (particular) speculative northern track.
[3] *We* would all like to use the BFO data to be able to draw similar conclusions about the various speculative aircraft tracks that we are all proposing.
[4] Though we do not know Inmarsat’s method for generating BFO values from aircraft tracks we *do* know that the green points on the BFO plot are the BFO values that Inmarsat’s method generates from their yellow (450 knot) southern track.
[5] Therefore, if a method *we* propose for generating BFO values from a given aircraft track can *not* generate the green points on the BFO plot from the yellow Inmarsat southern track then surely our method can *not* be the same method that Inmarsat were using themselves?
Alex Siew said,
April 8, 2014 at 4:05 am
Pan Am Flight 214 crashed after getting struck by lightning.
23 minutes before Air France Flight 447 crashed, the pilots had observed a glow in their cockpit which the captain described as ‘St Elmo’s fire’, an electrical phenomenon which can be caused by lightning whereby a charged object would appear to be on fire or burning.
The Kiwi working on an oil rig off the coast of Vietnam said he saw a burning object in the sky which appeared to be in one piece and that the ‘flames’ lasted 10 to 15 seconds. It might have been a real fire or it could have been another case of ‘St Elmo’s fire’.
duncansteel said,
April 8, 2014 at 5:21 am
New post on my website:
Constraining Possible Routes for MH370
http://www.duncansteel.com/archives/621
seanhelmi said,
April 8, 2014 at 9:57 am
This is off-topic for a satellite blog but I believe (layman’s opinion) there is no actual evidence the plane “skirted” Indonesian radar. The only actual report is that Indonesian radar operators “did not detect” the plane. From this it is inferred the plane skirted the radar coverage area. But an equally if not more likely conclusion is the radar was not working, not monitored or inadequate to the task. Could simply be the case of an operator reporting he did not see the plane rather than admitting he had left his post for a cup of tea or fallen asleep. Or Indonesia reporting “no contact” rather than admitting its radar is not on or not monitored at that hour. We are talking, at most, about an unidentified blip on the screen.
In fact, no country has released any records or factual basis for the initial “left turn”, the return across Malaysia, or (now) the “skirting” of Banda Aceh. These “events”, like the supposed drop in altitude to 12,000, have been reported and repeated in the press, but the underlying basis is never revealed. Does the radar reveal altitude information anyway?
Contrast Inmarsat, which has not released the underlying numbers but has at least disclosed the methodology and the nature of the data examined. With Inmarsat we can at least determine if the methodology is sound. But no basis is given for the other flightpath claims. Lack of disclosure fuels suspicion and disbelief.
Neither Malaysia nor Indonesia have released any actual radar records, and this is assuming there are “records” to release. Is the scope actually recorded resulting in a screen capture? Or is the “record” a written notation by the operator? Anyone more knowledgeable about what type of radar was involved, its capabilities and how and if this type of radar is recorded please comment.
Alex Siew said,
April 8, 2014 at 11:22 pm
@GuardedDon,
A little bit more info from the manuals referred to in my previous comment on the battery issue.
All the satcom components (SDU, HSU/RFUIA,HPA,LNA/DIP etc) derive “primary power” from 115v AC and 28v DC. AC is sent via the ‘left main AC bus”. DC presumably is sent via the two 28v batteries on board, the main battery up in front and the APU battery at rack E10, next to where the satcom components are located at rack E11 (rear upper fuselage).
As mentioned in my previous comment, the SDU also has an internal battery.
From the Honeywell’s manual:
” Each AES maintains a system table stored in nonvolatile memory in the SDU. The system table contains the data EIRP table, the satellite and GES identifying information……The system table does not lose its contents because of loss of primary power”.
” The ORT [Owner Requirements Table] is stored in nonvolatile memory in the SDU. The ORT contains information relating to different areas of functionality like log on and telephony. The ORT does not lose its contents because of the loss of SDU primary power….”
Fitzcarraldo said,
April 8, 2014 at 11:31 pm
CNN report on Wednesday, April 9:
“The Australian ship Ocean Shield had first picked up the underwater pulses Saturday [April 5]. But then, for the next three days, nothing. On Tuesday [April 8], the ship once again reacquired the signals. That’s four signals in the same broad area: two on Saturday; two on Tuesday. All of the signals are within 17 miles of one another.”
Looks promising. I’ve updated my Google Earth model to show the last reported position of Ocean Shield a few hours ago; a screen snapshot is at the following link (the example flight paths are the same ones shown on the snapshot in my previous post):
http://i2.photobucket.com/albums/y9/imageuser/MH370-Example_tracks_and_Ocean_Shield_on_9_April.jpg
Fitzcarraldo said,
April 9, 2014 at 12:21 am
Just to add to my previous post, the April 9 a.m. JACC media release has two slides showing the aforementioned four locations where pings of the suspected FDR and/or CVR were detected by Ocean Shield. They are near to an arc labelled ‘Satellite Handshake Calculation # 7′ which I believe could be Inmarsat’s calculation of the arc for the 08:19 MYT partial handshake with Inmarsat 3-F1:
http://www.jacc.gov.au/media/releases/2014/april/mr014.aspx
http://www.jacc.gov.au/media/releases/2014/april/mr_014-1.jpg
http://www.jacc.gov.au/media/releases/2014/april/mr_014-2.jpg
GuardedDon said,
April 9, 2014 at 1:37 am
@Alex Siew
Thanks for that expanded post on Satcom installation and battery. You stated:
‘All the satcom components (SDU, HSU/RFUIA,HPA,LNA/DIP etc) derive “primary power??? from 115v AC and 28v DC. AC is sent via the ‘left main AC bus???. DC presumably is sent via the two 28v batteries on board’
Incorrect presumption: the B777 electrical system includes transformer rectifier units onboard to deliver the 28V DC as part of its managed power distribution. The supply to the satcom will be managed through the ELMS.
One 28V battery supplies emergency power to critical flight systems and the APU battery in E10 serves the APU’s starter; while that battery is adjacent to the satcom install it doesn’t supply it. The APU is absolutely critical to maintaining electrical power should there be a single engine failure, the aircraft ETOPS certification depends on that – the APU starter battery will not be shared with other systems that may compromise that.
The electrical system on the B777 is managed through the ELMS – Electrics Load Management System – the design intent includes load shedding if one supply element fails, satcom is *not* a flight critical system. Power generation is triple redundant: IDG on each engine plus backup gen on each engine plus the APU generator & finally the RAT. Batteries are heavy, they’re not a primary power source so they’re avoided. Take the 787 Dreamliner as an example – Boeing elected to use lithium technology batteries to replace the NiCD technology of the 777 generation.
See http://bit.ly/1g6EzGq for a schematic of the B777 electrical distribution.
The SDU capability to store data in NV memory does not presume battery power: the NV memory is most likely flash memory just like PC motherboards have used for BIOS settings since the 1980′s.
GuardedDon said,
April 9, 2014 at 2:54 am
Re: seanhelmi, mt.klimber
In earlier comment posts I’ve asked where the emphatic details of Malaysian, Thai or Indonesian radar sightings were published. No-one has replied positively & I my searches have not turned up anything specific.
In an attempt to understand the region’s military radar capabilities I located the references listed below. None describe an integrated operational air defence capability (ie remote stations feeding data to a sector centre further integrated with civil radar/traffic information) although that is described as the goal in Indonesia and Malaysia. Without automation and integration the information extracted from their sighting data remains questionable.
Indonesia: http://bit.ly/1rdDbXh Jan 2014, four remote radar sites in N Sumatra including Sabang an island 9M-MRO is alleged to have passed on a NW path along Str of Malacca.
Indonesia: http://bit.ly/1rdDqS2 Feb 2014, describes Indonesia’s strategic plan to replace previous generation radars. Only 3 replacements in service?
Malaysia, similarly, had plans to develop an ‘integrated air defence’ capability (see http://bit.ly/1pswkHu and http://bit.ly/1psvGdf ) however a severe budget cut was imposed on RMAF in 2012 and the TRS acquisition was cut back to one system. (Translations required, use Google Chrome & it should offer that automatically.)
Those references provide a starting point to explore the region’s various air defence capabilities, those journalists attending the daily MoTM press briefings should still be asking probing questions. Without firm information on the starting point from which to extrapolate tracks to the southern Indian Ocean (or the north), the great mathematics work undertaken by contributors here explores only a process.
Ole said,
April 9, 2014 at 3:53 am
GuardedDon,
what about Cocos (Keeling). The Aussies relocated at least one of their P-3 Orion from there, so the place seems to have at least some importance. If MH370 flew to the area where the ULB pings are detected now, it must have passed close by. Obviously no radar there either?
Alex Siew said,
April 9, 2014 at 4:32 am
@GuardedDon,
What u said on the electrical systems makes sense. However, the SDU does have an internal battery. From what I can gather from the net, this battery needs to be replaced every few years ( a sticker would be put on the SDU to show when the battery was last replaced).
The first generation SDUs are governed by ARINC 741, I don’t have access to these specifications. I suspect these specifications will show the required battery arrangement for such SDUs.
Lastly, I note that the pings emitted were said to be “faint”.
GuardedDon said,
April 9, 2014 at 4:59 am
Re: Ole at April 9, 2014 at 3:53 am
There has been no substantial information released from any party in the region about radar sightings of MH370 since 17:30UTC 7th March.
Cocos Islands are Australian territory but I haven’t looked at what radar capabilities might be located there. It would be useful to position an Orion there if its mission was to search for suspect ‘illegal maritime arrivals’ departing Indonesian waters for Australia (a whole different story….)
The Australian JORN system is reported to have an arc of coverage extending 1000-3000km from the site at Laverton, WA (-28° 19′ 36.29″, +122° 0′ 18.84″) and that should cover their interests in the area south of Indonesia including the Cocos Islands..
Alex Siew said,
April 9, 2014 at 6:28 am
@Duncan,
Regarding what u said on your website in reply to my latest comment there.
1. U said in your comment here March 26 2.50 that the satellite component of the LOS values would be vz cos 45 or roughly 0.7vz.
2. Mike Exner’s LOS values for the 6 successful pings (which u do not dispute) are as follows: 39.77, 39.14, 60.80, 79.85, 100.64 and 125.35 knots.
3. I had previously commented (on your website and here) that the LOS reading for the first ping should actually be a negative reading (the BFO chart did not differentiate between negative and positive readings- the reading for 00.30 when the plane was stationary at KL airport and the satellite moving northwards ie towards the plane, had a positive reading of 87 hz).
4. Applying your formula to MIke’s numbers but with the first LOS value as a negative reading, shows that Mike’s numbers are consistent with the satellite’s speed and movement providing for the entire LOS value ie the plane was stationary during all 6 pings.
AndRand said,
April 9, 2014 at 11:05 am
seanhelmi said,
April 8, 2014 at 9:57 am
Neither Malaysia nor Indonesia have released any actual radar records, and this is assuming there are “records??? to release. Is the scope actually recorded resulting in a screen capture? Or is the “record??? a written notation by the operator?
Here is the track from radar, even linked in this blog up there…:
http://tmfassociates.com/blog/wp-content/uploads/2014/03/Beijing-event.jpg
However, when you look at this map:
http://i.dailymail.co.uk/i/pix/2014/03/19/article-2584399-1C642F3E00000578-611_634x422.jpg
in fact everything between lost transponder contact around IGARI and presented radar tracks around Penang are not really known (at least wasn’t presented as radar track) but guestimated. Therefore, when you are quick to jump to conclusions from BFOs you are also quick to completely discard them (at least Duncan is, who censores me on his blog from now on when I pointed that out).
But there are less possibilities than with the whole track because we know that the turn occured somewhere between IKUKO and Vietnamese primary radars. So when treated as assumption it could be taken for calibration of BFOs thru first part.
Applying LOS to heading/speed is another point some assumptions get in the way: I think both steady speed and steady heading assumptions are far fetched observing plane taking turns due to autopilot. But in fact the track is not easy to calculate when it creates in fact a decision tree – with one pair heading/speed matching with LOS (from BFOs) and satellite distance ring comes another set possibilities – this recurrency is best delt just manually (with constraints on speed and heading change).
When I tried to match only BFOs (I got them matching roughly the first part of track with Hamster3null calculations using 900MHz AES communication frequency) from point (-1, 93.5) – the average point on range rings at 19:40UTC from last radar contact at 18.22 – the best match I obtained were with BFOs less than in 6Hz difference and distances differences from distance rings rising from ~5km to ~300km:
400kts 400kts 375kts 375kts 350kts 350kts 325kts 325kts 300kts 300kts
Hz km Hz km Hz km Hz km Hz km
2.07 -7.32 0.67 -7.32 -3.06 -7.32 4.41 -7.32 3.16 -7.32
6.71 177.87 -1.60 183.00 2.21 191.14 3.04 183.13 0.35 187.16
5.88 118.86 -1.13 109.02 1.92 121.88 3.26 114.60 -1.30 111.91
4.18 183.65 2.23 156.07 0.29 167.13 2.37 156.06 2.41 136.76
2.36 373.33 2.92 330.74 2.81 323.43 -0.45 303.23 3.53 263.13
http://i.imgur.com/mBSPNwC.jpg
and they are due to BFOs quite different than those created just on distance rings by Duncan:
http://www.duncansteel.com/wp-content/uploads/2014/04/C_3D_c.png
With so big lack of actual data it is really needed to exactly know what IS KNOWN or MEASURED and what is, indispensably, just conceiving ASSUMPTION with estimated probality.
AndRand said,
April 9, 2014 at 12:30 pm
Here is how the calibrating looks like, Inmarsat BFOs with BFOs as calculated for 900MHz for two assumed tracks:
http://i.imgur.com/YjsNsk0.png
GuardedDon said,
April 9, 2014 at 12:53 pm
More ‘radar’ thoughts, only because to work out how to get somewhere it’s useful to know where to start.
Beijing event radar plot image note the time, last point off to top right is 18:22UTC
http://tmfassociates.com/blog/wp-content/uploads/2014/03/Beijing-event.jpg
Flightradar24 – one may yet playback a recording, using a view point close to above, via this URL
http://www.flightradar24.com/2014-03-07/18:00/24x/6.28,98.43/9
or review at this image from that sequence
http://i.imgur.com/2UbzVbc.jpg
So is the RMAF radar track MH370 or UAE343?
sk999 said,
April 9, 2014 at 2:20 pm
GuardedDon,
Nice graphics. UAE343 looks like it is heading from waypoint GUNIP to VAMPI (staying South of Pulau Perak), then a left turn over to MEKAR. The radar plot (of which there is a better photo out on the web somewhere, but can’t find a link at the moment) shows MH370 starting from a more Northly point, heading directly from Penang, over Pulau Perak, then to Vampi and on in the direction of MEKAR. I have read that one should not trust the timing on the flightradar24 plots; however, MH370 must have been hot on its tail.
AJ said,
April 9, 2014 at 4:03 pm
Using the Ruler feature in Google Earth if I select the South Magnetic Pole as my first point then select a second point around the northern tip of Sumatra, the resulting line goes right thru where the Ocean Shield is conducting its search. Hardly conclusive proof, but I’d make a small wager that MH370 was headed to the magnetic pole during it’s final leg.
Ocean Shield Position: -21.08 / 103.92 (per Marine Traffic)
South Magnetic Pole: -63.5 / 138 (per Google Earth)
AJ said,
April 9, 2014 at 4:18 pm
Then again, looking at the magnetic field declination lines, it appears a magnetic south heading would go further east than where the Ocean Shield is. So maybe I won’t make that wager and leave the cash in my pocket instead
XocoLatte said,
April 9, 2014 at 11:09 pm
GuardedDon,
I remember Keith Ledgerwood said the next day this Beijing event has been shown with the photo of the radar coverage that it apparently showed UAE343 path and not MH370. He also exclaimed at his apparent stonewalled state how and why the Malays play dumb with everybody…
AndRand said,
April 10, 2014 at 4:11 am
AJ said,
April 9, 2014 at 4:18 pm
Then again, looking at the magnetic field declination lines, it appears a magnetic south heading would go further east than where the Ocean Shield is.
I think when you want to use magnetic heading you will have to use airspeeds, therefore also weather implications. Good luck!
And for loaclization and search purposes that is completely useless also for fuel usage calculations.
Skwosh said,
April 10, 2014 at 4:47 am
@richardc10 @Ole (if either of you are still there!)
I think the ideas we’ve been thinking about relating to an imperfect Doppler correction based on a fixed satellite position assumption may still have some merit, particularly because I think we reckon they may help to explain the following:
[*] North/south asymmetry
[*] The overall shape of the plots
[*] The magnitude of the differences between the north and south tracks towards the end of the plots
[*] The text “not corrected by system = measured frequency offset” in the Inmarsat diagram
However, as we acknowledge, the problem with @richardc10′s current implementation of the imperfect Doppler correction scheme is that in order to get a good fit to the Inmarsat BFO graph it needs to assume there is an *L*-band sat->ground component included in the graph rather than a *C*-band sat->ground component.
I have concocted the following hair-brained theory to try to account for this:
Notation (to try to avoid D1 D2 D3 confusion horror):
V_AS = aircraft->sat LOS speed divided by speed of light
V_SG = sat->ground LOS speed divided by speed of light
L_Band = L-band frequency
C_Band = C-band frequency
[1] Let’s say all they actually know is the frequency that was recorded on the ground, and that there is no active Doppler correction on the ground:
Actual_Measured_Offset = (L_Band*V_AS – Aircraft_Correction) + C_Band*V_SG
(As we have argued before, if they knew the exact value of the aircraft correction (from a header) then they could just deduce V_AS directly – so if that was the case, why didn’t they just do that?)
[2] Let’s say that what they *intended* to present on the graph was the frequency at the satellite (so they intended to remove all dependency on V_SG).
[3] What if they *incorrectly* removed V_SG from the measurements by using the *L*-band frequency rather than the C-band frequency and that this is what they have presented us with as the measured BFO?
If they did this then they would be presenting us with the following:
BFO_Measured = Actual_Measured_Offset – L_Band*V_SG
= (L_Band*V_AS – Aircraft_Correction) + (C_Band – L_Band)*V_SG
This would explain why, even though we would have expected them to have removed V_SG from the plot, there is still a dependence on it.
Why might they have done this? Perhaps they were presented with measured frequencies that were in the L-band (so after down-conversion on the ground) and this got them into thinking the correction should be at the L-band frequency – it may have been that different people were being fed different pieces of knowledge and assuming other people had already made some sort of correction that they actually hadn’t (though I*do* realise this is a really long shot!)
[4] However, this does *not* (yet) explain why they didn’t notice this error when they went on to test their predictions.
If they made the oversight in [3] then they *think* their BFO_Measued is just:
(L_Band*V_AS – Aircraft_Correction)
So when they come to calculate what they think these values should be for some aircraft tracks they will be disappointed to find that they do *not* get a match with their BFO_Measured values.
However, they notice the match is out by something that looks very much like the V_SG Doppler – and they are in a hurry – they want the numbers to match up – so they wave their hands (perhaps already uncertain about if/how a correction for the sat->ground link may have already been applied to the values they’ve been given) and so they just hack the predicted values by a factor dependent on V_SG, and this gives a good fit. Their obvious first choice of hack would be to use L_Band*V_SG.
So, let’s say their predicted values are as follows:
BFO_Predicted = (L_Band*V_AS – Predicted_Aircraft_Correction) + L_Band*V_SG
This would give a reasonable match between BFO_Predicted and BFO_Measued because L_Band is roughly of the same order as C_Band – L_Band: If C_Band = 3615 MHz and L_Band = 1634 MHz then C_Band – L_Band = 1981MHz (around 20% larger than L_Band).
I know all this is a *very* long shot, and really stretches credulity, but it does help to explain the following:
[*] Why there is a V_SG component in the BFO graphs at all
[*] Why the text and diagrams published by Inmarsat are so confusing
[*] Why @richardc10′s model appears to give such a good qualitative and quantitative (in terms of rough orders of the values involved) match to the Inmarsat BFO graph if the V_SG component is assumed to be at (around) the L-band frequency.
Does this also explain the *discrepancies* in Inmarsat’s graph between their measured and predicted plots?
I don’t think it explains the discrepancy at the start (take-off) at all, but I think it *could* explain the discrepancy at the end (and I have been thinking for some time that surely if they *could* have got a better fit at the *end* of the flight they surely would have as it is the *end* of the flight that is so important with regard to the search):
If the above wild speculation is right then Inmarsat are plotting the following:
BFO_Measured = (L_Band*V_AS – Aircraft_Correction) + (C_Band – L_Band)*V_SG
BFO_Predicted = (L_Band*V_AS – Predicted_Aircraft_Correction) + L_Band*V_SG
So, even if their calculation of the predicted corrections and tracks were spot on there would still be a discrepancy (though not a very large one):
BFO_Measured – BFO_Predicted = (C_Band – 2*L_Band)*V_SG
This works out to about (347 MHz)*V_SG
At the start of the plot V_SG*c is about 8 m/s and at the end V_SG*c is about -8 m/s, so if they aligned the measured and predicted at the start of the flight then this gives a steadily increasing discrepancy which would get to about (16m/s / c)*(347 MHz) ~ 18 Hz at the end – which looks to be about the discrepancy between the blue and green points at the end of the Inmarsat BFO graph. However, as I say, this does *not* explain the magnitude of the mismatch between the measured and predicted at take-off.
Ole said,
April 10, 2014 at 6:54 am
@Skwosh,
I come to think the key to understand the BFO diagram is to look at it’s purpose. If it’s purpose were to inform the public about either
- the missing ping rings
- or the instantaneous range rates at the time of the pings
why then don’t publish those values ?
The purpose of the BFO diagram is solely to emphasize the differences between north and south track. It doesn’t claim to convey *any* of the above information.
In contrary the slides state:
“The burst frequency offset is the difference (due to the Doppler contributions) between the expected received frequency and that actually measured.”
So the values in the diagram don’t directly represent measured values. They represent values that remain after the *expectations* have been subtracted from measured values. The question then is: What is already included in these expectations? It could be D3, D3/2, the V_AS digitally received, or any other f(t).
We would have to look into the heads of the inmarsat engineers to answer this. My most recent guess is, these “expectations” are chosen such that they serve the purpose of the BFO diagram to emphasize the difference between north/south. IMHO it even would be methodically correct to choose to subtract different “expectations” for each single ping as long as they are the same for measured, modeled north, and modeled south. It is just the differences at the times of each single ping between models and measured that matters for this diagram. The “correctness” of the differences can be shown by Richard’s model.
If people want to interpret information into the BFO that is not meant to be
conveyed, you can’t blame inmarsat or AAIB. It is not their job to pass confidential information to the public. It is the job of MAS and the Malayan authorities to provide the public with all necessary information.
Skwosh said,
April 10, 2014 at 9:10 am
@Ole Thanks for replying. Fair points – all of them. What nags and nags at me is that the BFO diagram/graphs/text sort of *do* appear to be trying to claim *something* – and they at least seem to imply that they constitute an explanation of what they did – and for sure most people seem to have accepted the diagrams and the text must surely be an explanation of what they did (even though no one actually appears to be able to explain it in a way that fits together with the graphs and the tracks). I guess I’m trying not to accept defeat – trying to fit something vaguely coherent to something that probably isn’t (story of my life!) – and I guess “looking into the heads of the Inmarsat engineers” is basically what I’m trying to do here – so I’m loosening my assumptions a bit to allow for the possibility of some sort of oversight – which is probably not at all wise of me. It would be better for me to just accept that we don’t have enough information to get any further. I find it difficult to give up on stuff – character flaw!
richardc10 said,
April 10, 2014 at 9:27 am
In data interpretation of this type there needs to be plausible evidence for any assumption made – if every parameter can be changed then any dataset can be fitted. I’ve run out of ideas for closing the gap between the model and the data later in the flight, if the correct return downlink frequency is used, so I can’t make any more progress.
Some final conclusions from the trends of the model.
a. As someone commented a while ago, the ~90Hz offset at 16.30 is not directly due to the C-band Doppler, it has the wrong sign. Perhaps it is due to the start-up sync performed by the AES, and keeps appearing as a constant correction later, on which other corrections are added. The true Doppler element of the BFO might be quite small (i.e. D2) with most of the rest made up of corrections (some of which at least use not very exact, but adequate, algorithms).
b. The BFO is sensitive to climb rate, it seems this is not compensated in the AES in the same way bearing and airspeed is. The differences in the Inmarsat data and model at pings 2 and 3 can be accounted for by the climb rate stated in the published ADS data. Ping 4 is after top-of-climb, hence the downturn in the trend of the data.
c. The deviations at 18.25 to 18.29 could be similarly due to climbing, or turning as suggested on the Inmarsat graph, or indeed both together.
d. after the 19.41 ping, the BFO is very sensitive to heading changes and climbing/descending. As Inmarsat said, there is no sign of climbing or descending in the data.
e. The BFO after 19.41 is _not_ sensitive to varying airspeed. Changes of +/-50kt around the required average of ~290kt (to get to the ping arc) after 19.41 are consistent with the deviations in the data – that doesn’t mean the airspeed was actually changing of course.
I found the detailed discussion of the Inmarsat-C communications payload at the link below interesting (it is a pdf document). This was submitted to the FCC for the 3F3 mission.
http://licensing.fcc.gov/myibfs/download.do?attachment_key=-136047
Skwosh said,
April 10, 2014 at 9:55 am
@Ole Supplemental (!): I think what set me off again on this was watching this short interview with the Inmarsat guy: https://www.youtube.com/watch?v=RJ71jEAPDZg – it’s what he says at the end “because there was no GPS data, because it wasn’t mandated, and no other data coming off the plane, we can only provide you the direction of travel…”
Skwosh said,
April 10, 2014 at 10:02 am
@richardc10 Yes- I found that document last night too! That’s what made me absolutely sure that there *must* be a C-band Doppler in there physically – and hence my wild speculations above on how that could end up looking like an approximate L-band Doppler in the data if they incorrectly compensated for it and then hacked a model to work with the incorrectly compensated values.
Alex Siew said,
April 10, 2014 at 10:10 am
239 lives presumably lost, families in anguish, Inmarsat trading at 674 on March 14, 2014 yesterday closed at 760, market cap up more than 300m, this Chris guy pitching this mandate thing at every opportunity…
Skwosh said,
April 10, 2014 at 11:00 am
@richardc10 Having had a bit of time to digest your post: Excellent observations – particularly the stuff about the climb/take-off. Agree completely about the dangers of ‘fitting’ data – not sure if that was partially directed at me – but in my defence my wild speculation doesn’t introduce any further parameters apart from the C-band frequency – though for sure it does suggests further complications on account of (an admittedly highly implausible) oversight… maybe there was an idiot like me involved – incorrectly subtracting the sat->ground Doppler using the L-band frequency is just the sort of mistake I’d make as I’d probably just assume (without asking an engineer) that the base frequency was the same all the way thorough the system!
AndRand said,
April 10, 2014 at 11:17 am
richardc10 said,
April 10, 2014 at 9:27 am
b. The BFO is sensitive to climb rate, it seems this is not compensated in the AES in the same way bearing and airspeed is. The differences in the Inmarsat data and model at pings 2 and 3 can be accounted for by the climb rate stated in the published ADS data. Ping 4 is after top-of-climb, hence the downturn in the trend of the data.
c. The deviations at 18.25 to 18.29 could be similarly due to climbing, or turning as suggested on the Inmarsat graph, or indeed both together.
d. after the 19.41 ping, the BFO is very sensitive to heading changes and climbing/descending. As Inmarsat said, there is no sign of climbing or descending in the data.
e. The BFO after 19.41 is _not_ sensitive to varying airspeed. Changes of +/-50kt around the required average of ~290kt (to get to the ping arc) after 19.41 are consistent with the deviations in the data – that doesn’t mean the airspeed was actually changing of course.
You know that this in fact falsifies BFO data?
Passenger plane very rare go more than 10m/s (20kts) vertical with 300-525kts horizontal and LOS changes due to heading.
The smallest range of speed is vertical
Fitzcarraldo said,
April 10, 2014 at 12:48 pm
As the location for Ocean Shield on 9 April on my Google Earth model in my previous posts was based only on the approximate distances from Perth and Learmonth given by AMSA, I have now removed that placemark and added two placemarks which are virtually on top of the locations where two suspected back-box pings were detected on 8 April. I have obtained precise coordinates for the ship’s location at specific times, I know the pings were detected at 16:27 and 10:17 local time on 8 April and the ship is travelling at only circa 2 knots. My latest screenshot is at the link below (the 3-F1 satellite handshake arcs and example flight paths are the same as in my post on April 8 at 11:31 pm):
http://i2.photobucket.com/albums/y9/imageuser/MH370-Example_tracks_and_Ocean_Shield_on_8_April_virtually_at_ping_locations.jpg
For those who didn’t see them, here are some of the statements published in the Press regarding military radar observations:
http://edition.cnn.com/2014/03/18/world/asia/malaysia-airlines-plane/
CNN 19 March
“Thailand: Plane sent intermittent signal
The Thai military’s revelation that it also spotted the plane turning west toward the Strait of Malacca is one encouraging sign that investigators could be on the right track after days of searching for the missing plane have failed to turn up any answers about its location.
The Thai military was receiving normal flight path and communication data from the Boeing 777-200 on its planned March 8 route from Kuala Lumpur to Beijing until 1:22 a.m., when it disappeared from its radar.
Six minutes later, the Thai military detected an unknown signal, a Royal Thai Air Force spokesman told CNN. This unknown aircraft, possibly Flight 370, was heading the opposite direction.
Malaysia says the evidence suggests that the plane was deliberately flown off-course, turning west and traveling back over the Malay Peninsula and out into the Indian Ocean.
The Thai data are the second radar evidence that the plane did indeed turn around toward the Strait of Malacca.
It follows information from the Malaysian air force that its military radar tracked the plane as it passed over the small island of Pulau Perak in the Strait of Malacca.
“The unknown aircraft’s signal was sending out intermittently, on and off and on and off,” the spokesman said. The Thai military lost the unknown aircraft’s signal because of the limits of its military radar, he said.”
http://edition.cnn.com/2014/04/10/world/asia/malaysia-airlines-plane/index.html
CNN 10 April
“A senior Malaysian government official and another source involved in the investigation divulged Thursday a number of details about the flight:
•
•
•
• Malaysia Airlines Flight 370 disappeared from military radar for about 120 nautical miles after it crossed back over the Malaysian Peninsula, sources say. Based on available data, this means the plane must have dipped in altitude to between 4,000 and 5,000 feet, a senior Malaysian government official and a source involved in the investigation tell CNN.
The dip could have been programmed into the computers controlling the plane as an emergency maneuver, said aviation expert David Soucie.”
My comments:
1. The above-mentioned ‘dip in altitude’ is presumably indicated by the circle on the slide of the Malaysian Military primary radar plot shown to the families in Beijing on 21 March.
2. The Thai Military and Malaysian Military comments regarding their respective radar observations appear consistent and, from the first report, it does not appear the Thais could track the aircraft any further than the Malaysians did (see the above-mentioned slide).
3. As mentioned in the blog post and several of the comments, the Indonesian Military said their radar did not detect an unknown aircraft.
So, in summary, if you take the three countries at face value, it seems there was not much good primary radar data to go on. One or more of the three countries might be hiding radar data, but equally it could be that they are not.
Fitzcarraldo said,
April 10, 2014 at 12:53 pm
Gahh… For “16:27 and 10:17 local time” read “16:27 and 22:17 local time”. Those times were given by the UK Daily Telegraph newspaper.
richardc10 said,
April 10, 2014 at 2:10 pm
@Skwosh
>Agree completely about the dangers of ‘fitting’ data – not sure if that
>was partially directed at me
I was thinking mostly of ideas I had myself for getting a better fit (kludging the model), but which I could not justify or ever be able to prove were true.
@AndRand
>You know that this in fact falsifies BFO data?
>The smallest range of speed is vertical Passenger plane very rare go
>more than 10m/s (20kts) vertical with 300-525kts horizontal and LOS
>changes due to heading.
The proposal from @skwosh and ole was that the AES compensates for its own speed and course (but not exactly). This reduces the contribution of the speed and course to the BFO to the same order (10m/s) as the vertical speed. The BFO numbers in the graph are much too small to represent actual Doppler shifts due to velocity of the aircraft – the range of BFO values would be 1000Hz if that were so.
sk999 said,
April 10, 2014 at 5:26 pm
Here is a slide presentation that gives a great deal of background information on Inmarsat’s aeronautical services. (Wish I had found this earlier). Companies making SATCOM systems with the capabilities of the 9M-MRO system include Rockwell-Collins, Honeywell, Chelton, Thrane & Thrane, and (maybe) EMS Technologies.
http://www.satcomdirect.com/connect/presentations09/Inmarsat%20101.pdf
Here is link to the installation manual for the Thrane & Thrane TT-5000. This SATCOM system was manufactured around when 9M-MRO was delivered to Malaysia Airlines (2002) and … it supports using the Inertial Navigation System (IRS) to provide the Doppler compensation, just the capability we need to explain the BFO diagram. This particular system was made for business and regional jets, so it wouldn’t be on a B-777, but perhaps a comparable model was the one at issue.
http://esupport.thrane.com/index.php?_m=downloads&_a=downloadfile&downloaditemid=1410
Ole said,
April 10, 2014 at 10:34 pm
@sk999
great documents, the installation manual shows the state of the art 2002:
Quotes:
“As an option, a Navigational Reference System NRS may be included to enable the TT-5000 Aero-I System to be operated independently of the aircraft’s navigation, heading, and altitude reference systems”
“The SDU has two high speed ARINC 429 input interfaces for IRS 1 and IRS 2. Antenna positioning and Doppler correction data are computed from either the IRS data or NRS data. The priority of using either IRS or NRS data can be
determined by viewing the Reference System Table.”
@AndRand
The ADS-B data for the two pre-17:07 “pings” has climb rates of ~1400 ft/min ~=7 m/s. If the sat was at an elevation of ~45 degrees that would give an LOS contribution from climb rate of ~5 m/s, the equivalent of ~27 Hz doppler shift. That’s at least the right ballpark to explain the differences between modeled and measured.
McLaughlin of inmarsat once stated that the 1:07 ACARS message was of importance for calibration because it contained a GPS position. Trying to look into the heads of inmarsat engineers (@skwosh): Maybe this was also used to calibrate their expectations and their north/south model?
http://www.bloomberg.com/news/2014-03-21/missing-plane-flew-steady-speed-over-ocean-inmarsat-estimates.html
Alex Siew said,
April 10, 2014 at 11:46 pm
@Tim, are u still here….
The SDU on MH370 had an internal battery (meant primarily to power memory and the clock i think). Is it possible that the SDU had responded to the signals from the satellite and transmitted the faint pings, using power from this internal battery?
Skwosh said,
April 10, 2014 at 11:47 pm
@sk999 Excellent – your searching powers are marvellous! I did manage to find those Inmarsat slides a while back (but was thinking everyone had more or less given up by now) but I spent hours and hours trying to find details of how Doppler compensation might be implemented on various of the manufacturer’s systems and couldn’t find anything specific. As far as I can see Inmarsat basically specify the protocols/tolerances for talking to their systems and then others implement hardware accordingly – how they choose to do this is up to them so long as they meet the spec.
Ole said,
April 11, 2014 at 4:56 am
richardc10 said:
“The true Doppler element of the BFO might be quite small (i.e. D2) with most of the rest made up of corrections”
It took me until now to notice, that this is exactly the title of the first inmarsat slide:
“Doppler correction contributions”
Obviously nothing else implied.
Skwosh said,
April 11, 2014 at 10:35 am
@sk999 I’ve had some more time to look at the installation manual you found and I’m finding it very affirming! I note (as @Ole and I’m sure you also already have) that there are some configurations that do not require a data feed from the aircraft’s navigation system at all, and that these configurations just use GPS acquired either via a separate antenna or via a feed from the main antenna.
Given the previously noted extract (Page 602) “… Doppler correction data are computed from either the IRS data [from the aircraft] or NRS data [from GPS]…” the implication is that one or other of these sources of navigation information *alone* is sufficient to calculate Doppler corrections that will keep the system within the required tolerances.
I suppose the wording does not entirely exclude the possibility that additional data (e.g. incoming frequency data) may also be being used in the computations of the Doppler corrections, but if calculations based purely on the navigation information and the known (perhaps assumed fixed?) position of the satellite are indeed sufficiently good to keep within the required tolerances then it’s going to make implementation of this kind of hardware a lot simpler (no need to bother with measuring, storing and timing-out incoming frequency information).
I guess we all agree that in isolation none of this means that whatever was in MH370 was doing any of this – but, as you imply, it sure makes this kind of scenario a great deal more plausible!
sk999 said,
April 12, 2014 at 4:30 am
Regarding climb rates, richardc10 and Ole both suggest that the inital climb out of KL could explain the high data points at pings 2 and 3 in the BFO diagram. I have taken the data from the flight log here:
http://flightaware.com/live/flight/MAS370/history/20140307/1635Z/WMKK/ZBAA/tracklog
and computed the BFO with and without the climb component of the aircraft velocity. The maximum climb rate is 2940 feet per minute, and over most of the climb-out stays over 2000 fpm. I find the BFO becomes more positive by 21 to 57 hz during the climb-out, consistent with and having the same sign as the offsets seen on the diagram.
The drop in BFO at 18:30 is more of a challenge to reproduce, since it can depend on the size of the turn and final heading, any change in altitude, and the behavior of the AES as it adjusts to the new flight conditions. Still pondering it.
richardc10 said,
April 12, 2014 at 5:07 am
In order to discuss the 18.30 pings later in this post, I added a time varying component to the model proposed in earlier posts, to better fit the data. This component is a linear function of time with value 0 at 16.30UT and -60Hz at 00:11UT. This could be considered a ‘drift’ in the system offset set into the system when it powered up at 16.30. I have no engineering reason for including the value of 60Hz, or indeed the drift at all, so this is a kludge to the model. Others with knowledge of the AES terminal (I have none) may be able to state that drifts in AES transmission frequency cannot happen. However, the effect of this component on the discussion below is not large.
The plot of the 450kt final track (the same as the one and only Inmarsat graph) is figure 1 below. The model includes no climbs, no lag (see below). The data for the speeds and courses up to 18.30 is included in figure 1. The match in BFO value at 00:11 is due to the value of the bias drift term I have added to the model, but it is perhaps interesting that the gradient over the last 5 pings is about right. There is a reasonable match to the Inmarsat graph (figure 2).
To be clear, the only modelled elements are:
1. the initial offset and the ‘bias drift’ with time.
2. the selection of the 450kt course after the final turn.
The model is not very sensitive to the location of the final turn – the course (and less so) speed are the key ingredients at this stage.
Given this model I then changed the final track to the course required to take the aircraft to the current FDR/CVR search area. I also added the recorded climb rates over the first few pings as discussed in an earlier post.
The main issue for this post are the 3 pings at 18.25, 18.27 and 18:29. As stated by others earlier, these seem to correspond to aircraft generated messages rather than keep-alive pings from the Inmarsat GES. The first two pings show significantly different BFOs, particularly the 18.25 ping (an offset of 130Hz from the model in figure 1).
From the model, the BFO (for a particular geographical location and time) is a function of:
1. Heading lag (see below)
2. Climb rate
3. Heading (ground track)
4. Airspeed (ground speed)
These are roughly in _decreasing_ order of effect on the BFO.
Heading Lag – As discussed by others, the AES gets navigation data from the IRS or NRS and it is hypothesised that this is used to adjust the transmission frequency so the satellite receives the transmission at the correct frequency (however, a simplified algorithm is used, not requiring the spacecraft orbit details). The aircraft heading (ground track) and hence relative velocity to the satellite is a key part of that calculation and the one that can change fastest, i.e. in a turn. A error of 10 degrees in the heading used in the calculation would give an additional contribution to the BFO of 120Hz (probably more in some situations, I didn’t look for a worse-case). The data link between the IRS and AES must run at some rate; one sample per 10secs sounds too slow, so I would guess once per second or faster (but this is still a guess). I assume once per second here, so the data used by the AES could be 1sec out-of-date. A rate one turn (to the left) could result (at the 18.30 ping) in a lag of up to 3 degrees in the course used in the AES speed compensation calculation. This gives a BFO lag of 35Hz, much less than the 130Hz seen at 18.25.
A much higher rate of turn to the left (12degrees/sec – impossible I suspect) is needed, or a turn and a climb. In figure 3 I have modelled at 18.25 a rate 2 turn (6 degrees/sec) at a speed of 287kt (the same as the required speed to the final ping arc – lower than used in figure 1 at 18.25) plus a climb rate of 3000ft/min. I have no idea if a B777 perform such a manoeuvre, but these are only the flight conditions at the instant of the ping. At 18.27 I have used a climb rate of 1000ft/min (but no turn). At 18.29 I have modelled a steady course of 315, any further to the South and the model does not fit the data, but of course the errors (in the model) are large.
Anyway, all this speculation implies some event at 18.25 which involved a high rate of turn (possibly for a short period) and climb and caused the ACARS system to attempt to send a sequence of messages (not finally transmitted we assume).
It is of course quite possible that other less violent conditions can cause the BFO at a single ping to jump by the 140Hz shown in the MH370 data which would negate this conclusion.
At some point between 18.29 and 19.41 the turn (or turns) to heading 160 occurred to take MH370 to the final ping arc. The data does not give any better indication of when. I haven’t gone into the question of whether the flight crossed Sumatra.
Apologies for the long post.
Figure 1: Model and data: no climbs, no heading lag, 60Hz change of bias with time. No modelling of turn at 18.30. 450kt final course to the ping arc.
http://s1311.photobucket.com/user/RichardC10/media/Model1results_zpscf94f3b7.jpg.html
Figure 2: Original Inmarsat BFO Graph
http://s1311.photobucket.com/user/RichardC10/media/inmarsatgraph_zps4fc4673b.png.html
Figure 3: Model and data: climbs and heading lags as indicated. 287kt final course to the ping arc.
http://s1311.photobucket.com/user/RichardC10/media/Model2results_zpsadfad2cd.jpg.html
Fitzcarraldo said,
April 12, 2014 at 5:10 am
Report in the New Straits Times today:
Call traced to co-pilot’s phone
http://www.nst.com.my/nation/general/call-traced-to-co-pilot-s-phone-1.562612?cache=wixtvnujghdrti
Apparently connection to his phone detached before take-off from KUL at Sepang (i.e. he switched his phone off), but it attached briefly to a telco tower near Penang later.
Skwosh said,
April 12, 2014 at 6:04 am
@richardc10 This is excellent work you’re doing here. I was hoping your previous ‘final conclusions’ didn’t mean they were going to be your final contribution! Looks like the numbers work out remarkably well with the take-off – and all essentially ‘for free’ without having to extend the model (at the start at least). I agree about latency during rapid changes and how that could be plausibly modelled (for this kind of implementation) and how it could then yield an account of the big changes during the three closely spaced pings – need more time to digest your post/numbers – but it looks very good. If *only* there was a reasonably/plausible explanation for the magnitude of the D3 component and for your offset… would be nice if any explanation for D3 also came with a ‘built in’ time varying offset – I guess my previous wild speculations about this would indeed give you a slowly changing offset, but it would be too small, and would have the *wrong* sign (would get more positive).
richardc10 said,
April 12, 2014 at 8:19 am
> If *only* there was a reasonably/plausible explanation for the >magnitude of the D3 component and for your offset…
The D3 component of the model uses the 3.6GHz return frequency as per the Inmarsat-C specification. I don’t understand the method of setting the ‘static’ offset, if it gives the numbers in the graph. The modelled BFO (without adding an offset to make it match to the 16.30 data point) has a range of -90 to +80. Perhaps they didn’t want a graph with negative numbers which would have been harder to present to the audience they were addressing, so an offset was added to make all the numbers positive.
A bit of googling suggests that (at least some) L band oscillators for satellite terminals have around 100Hz stability over their temperature range. So a shift of 60Hz over the flight with the MH370 terminal under unknown conditions does not sound implausible.
Skwosh said,
April 12, 2014 at 8:58 am
@richardc10 Ah yes – I see – I didn’t spot that you’d transitioned to using the C-Band frequency with the D3 component and had dealt with the resulting issues with your linear offset (being slow again… was trying to understand how your linear term was negative and so large… but now I understand).
So – overall – this is pretty good.
Just to be sure I’m clear:
BFO = CoreModel + Adjustments
CoreModel = (D1+D2)*FL + D3*FC (using your earlier notation)
Adjustments = F0 + ((t–t_start)/(t_end-t_start))*F1
FL = L-Band frequency
FC = C-Band frequency
F0 = Constant bias frequency (to get fit at start)
F2 = – 60Hz (to get fit at end)
The core model has a full theoretical justification and has no free parameters at all (other than the C-band and L-band frequencies, which are fairly well constrained).
The adjustments, on the other hand, are just a simple linear correction to get a good fit at the start and end of the graph.
So, given the quality of the fit and the simplicity of the model this isn’t half bad in terms of explanatory power for something with essentially only two free parameters!
Skwosh said,
April 12, 2014 at 9:00 am
@richard10c – sorry… there’s an F2 in there that should be an F1… but I guess you spotted that!
richardc10 said,
April 12, 2014 at 9:52 am
@Skwosh
You have used D1, D2, D3 in m/s which were the units of the components graph I posted before. In that notation positive is an increasing range.
In which case
CoreModel = -(D1+D2)*FL -D3*FC (using your earlier notation)
as BFO seems to be given in units where positive numbers means shift to lower frequencies, rather than higher.
Skwosh said,
April 12, 2014 at 10:23 am
@richardc10
Yes – you’re absolutely right – those should been negative – and so overall we get:
BFO = (F0 + ((t-t_s)/(t_e-t_s))*F1) – ((D1 +D2)*FL + D3*FC)
Where F1 = -60Hz
For a laugh I’ve just done a quick check, and I think the ‘partial D3 correction’ hypothesis (Inmarsat meant to correct for all of D3 in the analysis/graphs but inadvertently used the L-band rather than the C-band frequency to do so) also has a very similar outcome both qualitatively and more or less quantitatively as your linear time offset.
As above, using your D1 D2 D3 and assuming they have the same signs they have in your decomposition plots (so D3 ~= +7m/s at the start and D3 ~= –8m/s at the end).
Current model (exactly as above):
BFO = (F0 + ((t-t_s)/(t_e-t_s))*F1) – ((D1+D2)*FL + D3*FC)
F1 = –60Hz
Partial D3 correction model:
BFO = F0 – ((D1+D2)*FL + D3*(FC-FL))
The F0s would obviously be different in the two cases to get the fit at the start.
Because D3 looks pretty linear anyway (as plotted on your decomposition graphs) then the net effect of re-scaling the contribution of D3 is presumably more or less the same as a linear-time correction term.
Quantitatively (I think… I am prone to error – as you know – but I have checked this – not that that always helps!):
In current model:
D3 and correction term at start = –D3_start*FC
D3 and correction term at end = –D3_end*FC – 60Hz
Difference of terms (end – start) = (D3_start – D3_end)*FC – 60Hz = (15m/s /c)*(3.6GHz) – 60Hz = 120Hz
In partial D3 correction model:
D3 term at start = -D3_start*(FC-FL)
D3 term at end = -D3_end*(FC-FL)
Difference of terms (end – start) = (D3_start – D3_end)*(FC-FL) = (15 m/s /c) * (3.6GHz – 1.7GHz) = 95Hz
So, same sort of order, and obviously a degree of wiggle room depending on choices for FL and FC… one less parameter… maybe… I don’t think I’m being entirely serious…
sk999 said,
April 12, 2014 at 11:37 am
This story indicates that the SATCOM on MH370 was likely a Honeywell system.
http://www51.honeywell.com/honeywell/news-events/press-releases-details/3.13.09TechnologyEnablesCellPhoneUse.html
Honeywell makes several models of SATCOM systems – e.g., MCS-4000/7000, which vary mainly in the number of channels that they support. Newer generations of these systems use incremented numbers – e.g., MCS-4200/7200. The following is a link to the installation manual:
http://www.slashdocs.com/nkzyzq/sdim-msc7200-23-20-35-rev-1.html
The Satellite Data Unit – SDU – is the component of interest.
“The SDU system table memory contains the location of all satellites. When a GES is selected, the SDU uses this location information and aircraft positional information (through an ARINC 429 interface) from the IRS to compute the position of the satellite relative to the aircraft.”
One use of the IRS data is to point the high gain antenna at the satellite to get stronger reception.
“The SDU can adjust the transmission frequency in one–Hertz increments to compensate for the Doppler shift caused by the speed of the aircraft.”
However,we are not told if the IRS data are used to determine the compensation.
Skwosh said,
April 12, 2014 at 2:11 pm
@sk999 Still digesting. Another excellent find. One of the extracts you quoted: “[...] The SDU can adjust the transmission frequency in one Hertz increments to compensate for the Doppler shift caused by the speed of the aircraft.” then continues: “The receive mode is handled in a similar manner”… So what I’m thinking is that if it hasn’t received anything for some time then how can it Doppler compensate a received signal *unless* it uses the position/navigation information.
@richardc10 Regarding my previous ‘partial correction’ suggestion (if it is worth considering as far as providing a decent fit goes) – the more I think about this the more I think my earlier scenarios were un-necessarily contrived – this could just have been a *presentation* issue with the graph – nothing to do with the core team or their analysis. I’d say there is evidence of some confusion in the publicly released graph, text and diagram (that red-circle *still* bothers me – it looks so much like an *afterthought* – and/or an attempt at clarification on recognition of some uncertainty/confusion and/or that clarification was required – almost like someone was marking-up the diagram for corrections) – perhaps someone under intense time pressure and only partially briefed on the full details was *intending* to remove all dependency on D3 from the graph used for the public presentation but maybe they used the L-band bass frequency rather than the C-band frequency for the correction (perhaps hacking an existing Excel plot that included all of D3?) – that might be an understandable error if the measured data was associated with an L-band base frequency (perhaps post-down-conversion?) and maybe the explanation they had been given of how the system worked glossed over the up-conversion on the downlink (the diagram certainly glosses over this). Perhaps the core team were all understandably comatose through sleep deprivation at that point?
Alex Siew said,
April 12, 2014 at 6:01 pm
@GuardedDon, @hal
The hijacked Ethiopian Airlines Flight 961 crashed in the Indian Ocean.
Following is an extract from Flight International (Dec 4-10, 1996 edition) referred to in Wikipedia:
“Conditions for ditching were fair but the 767… hit with about 10* left bank, causing the aircraft to yew left and break up. All but the rear fuselage section inverted and sank quickly…”
Skwosh said,
April 13, 2014 at 3:38 am
@richardc10 I think I see an order of magnitude justification (perhaps the same as yours?) for your possible flight-time drift value; the Honeywell unit found by @sk999 has an oven controlled crystal oscillator (OCXO):
[*] 10^–12 /s [short term OCXO stability over seconds from Wikipedia]
s [~flight time]
[*] (60 * 60 *
[*] 2 GHz [frequency]
Product of all the above is order of 100Hz?
I’m thinking that if the oscillator can drift order 100Hz in around one day then the corrected Doppler errors are of the same kind of order as this ‘daily’ drift, so there must be some sort of calibration/compensation for the oscillator frequency drift happening on the same sort of timescale (at start up perhaps?). I guess they could calibrate at start up using a transmission of known frequency from the ground station (via the satellite) if they knew they were stationary on the ground – but then the satellite is still moving a bit (in this case) – but the ground station can at least pre-compensate its transmissions for the ground-to-sat Doppler – so that would probably be good enough to tether things for the duration of a flight – or I guess they could use GPS as a frequency reference. Still pondering… but – anyhow – I think this all makes the kind of magnitude of drift you have in mind quite plausible/manageable.
Also, we think (as stated by @Ole) that Inmarsat said they had GPS (and thus possibly other data such as heading) at 17:07 UTC and that they said this was important for calibration. They also know the position at the start (static). So they probably have enough to infer the aircraft’s active Doppler compensation at these times (and/or the compensation was reported digitally anyway) so they can work out exactly what all the natural and compensated offsets would have been on the aircraft’s transmissions at those times and can thus infer the aircraft’s bass frequency at those two times – and can gauge its drift (again supporting your idea).
However, if they were including a model of the (fairly substantial) base frequency drift then would they not have already removed it from the graph for public presentation? I guess not if the graph is indeed just meant to be the raw measured offsets on the ground. Still odd where they put the ‘zero’ though – I agree with you about the sign of the C-band correction being wrong to account for the initial ~90Hz (with respect to the subsequent development of the graph) – but it is a bit of a coincidence (perhaps a ‘presentation issue’ – someone says ‘where should we put the origin?’ – someone else says ‘what would the offset be at the start?’)… also still pondering.
Ole said,
April 13, 2014 at 4:00 am
Many thanks @richardc10 for the update on your modeling.
One normally knows the system and the way data is measured. Then one can try to interpret the data. We are doing the reverse: We know part of the data and inmarsat’s interpretation thereof and from there we try to work backwards to how the system works and how the data was measured.
Previously I suspected the D3 correction was done in stages, but probably jumps in frequency is exactly what is less tolerated by the clock recovery circles in the receiving equipment in Perth. So if D3 correction is done in the down-converter in Perth, maybe they use a VCXO with a tuning range smaller than D3 (because such a VCXO is less phase noisy) which would leave a residual D3. If the goal is to minimize the frequency change rate, they may choose to use the limited correction range to minimize the D3-induced frequency *change rate*. The result would be to distribute the residual change of D3 evenly over the time, i.e. D3 would be proportional to time.
I don’t like the idea of the MH370 terminal’s oscillator drifting around. That would imply the measured changes in BFO could be solely attributed to random drift of the terminals’s oscillator. That would invalidate all other conclusions.
I thought about the 18:25 event. If it is essential to avoid jumps in frequency, maybe the compensation in the terminal is only done in small steps. From the spec linked in this blog article:
———-
4.2.3.5.10 Transmitter Doppler rate.The maximum rate of change of the frequency of the transmitted signal when compensated for aircraft acceleration in the direction of the satellite shall not exceed 15 Hz per second. The Doppler adjustment resolution shall not exceed 10 Hz and the associated frequency changes shall be made without introducing phase discontinuity into the transmitted signal.
———-
I understand that to prohibit frequency jumps larger than 15 Hz during on compensation step. Maybe the terminal even chooses smaller frequency steps to avoid introducing phase discontinuity. So because only small frequency steps are possible, during longer turns of the aircraft the terminal may allow the uncompensated part of the doppler shift to run away a little bit and catch up again after the turn is completed.
Warning – the following is error prone: If phi is the angle between aircraft heading and the direction to the sub-satellite point, during a turn with constant turn rate the change in doppler is proportional to cos(phi). The derivative dcos(phi)/dphi becomes smallest when the aircraft is heading directly toward the satellite. So if we assume the 18:25 turn to the left began with the sub-satellite point at 9 o’clock, during the first phase dcos(phi)/dphi was big, the compensation allowed the doppler to run away and become bigger (aircraft turning towards the satellite). When the sub-satellite point was around 12 o’clock dcos(phi)/dphi was small and the compensation could catch up again. After that the sub-satellite point went towards 3 o’clock dcos(phi)/dphi became bigger and the compensation again allowed the doppler to run away, this time into the other direction because the aircraft was now turning away from the sub-satellite point. Qualitatively this scenario matches with the BFO diagram.
Sorry too for the long post.
GuardedDon said,
April 13, 2014 at 5:30 am
@ Alex Siew
One of there recent posts here links to a spec for a satcom installation typical of a B777, that doc states that the power requirement is 180W at 28V, that’s about 6.5A. As I’ve set out before, batteries are heavy and only used for critical flight control systems. Also, a recent commented found that MH were trailling an upgraded satcom capability on the B777 fleet. As I’ve posted previously, online images of MH’s B777 9M-MRQ do evidence a full high gain antenna but even images taken in early March of 9M-MRO still show the smaller antenna suggesting it didn’t receive the upgrade.
You mention the Ethiopian Airlines Flt 961 crash in the Comoros Islands & you’re correct in that the empennage didn’t sink: however, the crash occurred in the vicinity of a reef and if you pay attention to the contemporary photos there’s also an engine lying exposed above the water.
Both the Ethiopian Airlines Flt 961 and Air Transat Flt 236 incidents involved fuel exhaustion, both aircraft ended up running on emergency battery power for flight controls only: even the CVR didn’t have power in each circumstance. As I’ve said the satcom isn’t a critical system warranting emergency battery power supply. In case you might consider US Airways Flt 1539 where both engines shutdown as an example, do note that one of the first actions of the crew was to start the APU therefore maintaining hydraulic and electrical power.
On a totally different thread of the story: it’s been reported that the first officer’s mobile phone was registered on a cellular network (between 17:21 and 18:22). Has there been any report of the cell location where the registration was logged?
Ole said,
April 13, 2014 at 6:02 am
@GuardedDon
“Has there been any report of the cell location where the registration was logged?”
Penang. Full story here:
http://www.nst.com.my/nation/general/call-traced-to-co-pilot-s-phone-1.562612
Skwosh said,
April 13, 2014 at 1:17 pm
@Ole said “I don’t like the idea of the [...] oscillator drifting around…” I don’t like it either. If the OCXOs do drift this much (which is amazingly tiny, but so are the Dopplers) then either the system has to live with it (which it maybe could depending on the overall tolerances) or it has to be dynamically corrected with something more accurate and presumably external? I would like this not to be true – maybe the drifts are a lot smaller than I think and/or I’m missing something obvious? I’m just starting to look at stuff about GPS disciplined oscillators (GPSDOs – you probably know about these already) though no indication in my reading so far of the Honeywell document that their gadget can do this (GPSDO).
Regarding the ‘turn’: someone’s probably already suggested this, but the satcom units are listening for instructions all the time and if these incoming signals degrade (or are lost) then they try to re-connect. We are thinking the Doppler correction has lag that can’t keep-up if the aircraft is manoeuvring rapidly – presumably this lag in the Doppler correction applies equally to the *receive* side too, so could cause the incoming transmissions to be degraded/lost – so the closely spaced ‘turn’ transmissions could be re-connection attempts (which involve *un-solicited* transmissions from the aircraft). There has been speculation the unsolicited transmissions were due to other systems on the aircraft reporting something unusual – but the three ‘turn’ transmissions (and also the very last ‘unsuccessful handshake’ transmission) could all be down to motion induced Doppler shifts pushing the communications system out of tolerance and forcing re-connect(s) – so there may be *some* extra data in these transactions (to do with connection setup) – but probably only communications related data.
From page 2-2 of the Honeywell document founf by @sk999 http://www.slashdocs.com/nkzyzq/sdim-msc7200-23-20-35-rev-1.html :
Automatic handover is initiated upon detection of Pd–channel link *degradation* defined as:
[*] Error rate above 10^4 over an averaging period of 3 minutes
[*] More than 10 short–term interruptions (loss of P–channel clock synchronization for less than 10 seconds) in any 3 minute period.
Automatic handover is also initiated upon detection of *loss* of the Pd–channel defined as:
[*] Loss of clock synchronization for more than 10 seconds
[*] An unsuccessful log-on renewal procedure
richardc10 said,
April 13, 2014 at 2:26 pm
@skwosh
The Honeywell MCS-4200/MCS-7200 manual referred to earlier doesn’t mention a GPS interface (or GPS antenna). If so there would not be access to a GPS frequency standard.
Other VSAT systems refer to using a frequency standard transmitted by the satellite to synchronise the LES. Stability of low/infrequent maintenance VSATs may be more of a concern than aircraft systems which would have more frequent checks.
I haven’t seen a reference in the INMARSAT-C system to frequency synchronisation of the AES.
@ole
I defer to your expertise here on the transmitter stabilities expected. The Honeywell manual refers to a cooling water system, so if the equipment was still functional temperature changes may not be expected. The Inmarsat model matches the data (implying they understand the trends), so my idea of an unquantified ‘bias drift’ doesn’t work well.
I found a more complete set of the standards that the Inmarsat-C system meets, of which the one linked to this blog is part.
http://legacy.icao.int/anb/panels/acp/meetings/amcp3/
I haven’t managed to find a reference to a frequency synchronisation method therein.
Appendix chapter 9 refers to the LIDU parameters that are sent to the AES at logon. This includes information on the satellite latitude and longitude. I did look at what the BFO would be if stale satellite position data was used in the Doppler correction (rather than the nominal/average position) but there was a poorer match to the data.
Skwosh said,
April 13, 2014 at 3:11 pm
@richardc10 Having spent a bit of time (more interesting than going to sleep – but I am very nerdy) casually browsing oven controlled crystal oscillators (OCXOs) it looks the aircraft ones can do stability of 1×10^-9 over one day ( http://www.golledge.com/pdf/products/ocxos/hcd220.pdf ) – and the really scary looking ‘double oven’ ones (for ground stations) claim 1×10^-11 over one day ( http://www.oscilloquartz.com/files/1363164953-Br_%20OCXO%208607.pdf )
airlandseaman said,
April 13, 2014 at 3:43 pm
richardc10; @skwosh; @ole
1. The Honeywell system can take as input either IRS or GPS (GNSS) or other compatible AIRINC 429 sources of aircraft UTC, speed, direction, altitude, etc. data for the purpose of choosing satellite beams and P channels frequencies, antenna aiming, etc. See “MCS–4200/7200 Multi–Channel SATCOM System??? manual, page 1-11 and elsewhere in that manual.
2. Inmarsat C service is a low-speed packet data service (1200 bps?) designed for use by small, omnidirectional user terminals. I have read several places that MH370 had a “Classic Aero” system. like the Honeywell 7200 System. See for example the Wikipedia description below.
“Analysis of satellite communication [edit]
The datalink for Malaysia Airline’s avionics communications is supplied by SITA, which contracted with Inmarsat to provide a satellite communication link using Inmarsat’s Classic Aero service.[44][168]???
Source: http://en.wikipedia.org/wiki/Malaysia_Airlines_Flight_370#Analysis_of_satellite_communication
3. From the various Doppler compensation patents, AIRINC Spec’s and User Terminal installation manuals cited here and elsewhere, it seems clear that Inmarsat and AIRINC only publish a “performance spec” for user equipment, not a “design spec”. Thus, manufacturers are free to use any Doppler compensation method that meets the performance standard. Some models may use a “preemptive” method based on tracking a pilot carrier. Others may use the IRS or GPS based data plus configuration files to estimate the antenna pointing and Doppler compensation. Thus, it is likely that the BFO values contain some residual offset component due to imperfect TX compensation. Moreover, the residual is likely to be different from model to model, and time to time, based on the method used, and the aircraft and satellite state at the time.
4. I don’t believe there is any “bias drift”. Rather, I am coming to believe that this “residual” is why the so called “Predicted North??? and “Predicted South??? BFO values are different. The AER Doppler compensation probably over predicts or under predicts up to 30 Hz or so under normal conditions, depending on the position and direction of the sub-satellite motion relative to the AER. Just a hypothesis at this point, but the BFO-D3 = D1+D2 (“Total L band Doppler???) plots sure look like that is what we have. This would also explain the somewhat cryptic note above the D2 definition (“Not corrected by system = measured frequency offset???).
airlandseaman said,
April 13, 2014 at 5:47 pm
Skwosh:
Communications satellite ground stations almost always use a Rubidium standard, not TCXOs or OCTCXOs, for time and frequency references. Sometimes they use Caesium standards. Either way, the accuracy is essentially perfect for Inmarsat LES’s.
http://en.wikipedia.org/wiki/Cesium_clock
http://en.wikipedia.org/wiki/Rubidium_standard
The LES “knows” the satellite ephmeris precisely from the TT&C system, so the outbound P channel carriers used for “pilot carriers” can be automatically offset to eliminate C band uplink Doppler in the outbound downlink. The AES then measures the received L band offset relatave to a stable local reference and determines the corresponding TX offset needed [= -(1.53/1.63) * downlink Doppler]. As previously noted, the AER can determine the offset by several other methodes as well. It is the manufacturer’s choice how to meet the performance spec.
The bottom line is that the absolute accuracy of ALL the frequency references in the entire system is such that nobody needs to worry about them. The only thing we need to figure out is the small uncorrected “residual” TX offset error resulting not from reference accuracy, but due to the dynamics of the aircraft and satellite, resulting in some unavoidable difference between the offset used and a “perfect offset”. Inmarsat knows these values, but we don’t….yet. D2 includes this residual. we need to reverse engineer this residual component from the north and south predicted BFO values.
richardc10 said,
April 13, 2014 at 10:43 pm
@airlandseaman
The AIRINC 429 interface for navigation data was already understood. The issue was whether the MCS–4200/7200 unit received GPS frequency standard channels, which I don’t believe would be carried by the digital AIRINC 429 interface. However, the weight of comments is that stability of the L-band transmitter frequency is high and a significant drift is not expected.
The line of reasoning in previous posts gives a residual time varying component between the developed model and the data (and the original Inmarsat model in their graph) of 60Hz, varying linearly with time over the flight. A linear drift in L-band transmission frequency would explain this, or a difference in adjustment of the return C-band Doppler which varies rather linearly over the period. Apart from this, the structure of the Inmarsat N and S models is understood using the proposal from Ole and Skwosh for how the AES computes the Doppler compensation.
richardc10 said,
April 13, 2014 at 11:50 pm
For what it is worth, the state of play of the BFO model is at
http://s1311.photobucket.com/user/RichardC10/media/Modelcomponents_zpsa56c7c9f.jpg.html
Total modelled components = D1 + D2 + D3 + ‘Constant Bias’ + ‘Residual time varying term’.
All terms are in Hz.
The ‘Residual time varying term’ is the added linear component to get the fit (a.k.a. A Kludge), and for which an explanation is lacking.
I have excluded any speculative turn and climb components to D1 around 18.30. The documented early climb rates are included in D1.
Skwosh said,
April 14, 2014 at 1:51 am
@airlandseaman
“Frequency distribution systems for satellite ground stations” was one of the manufacturer’s suggested applications for the the double oven temperature controlled crystal oscillator http://www.oscilloquartz.com/files/1363164953-Br_%20OCXO%208607.pdf I guess that’s why I put “for ground stations”.
Are you back from holiday now?
richardc10 said,
April 14, 2014 at 2:17 am
@ole
>If the goal is to minimize the frequency change rate, they may choose > to use the limited correction range to minimize the D3-induced
>frequency >*change rate*. The result would be to distribute the
>residual change of >D3 evenly over the time, i.e. D3 would be >proportional to time.
Interesting. You are saying they might be less concerned about the value of D3, but want it to be linear after correction. The fact it appears at all in the Inmarsat explanation suggests it is not zero. The trend of ‘raw’ D3 changes for geometrical reasons at 00:11 but there is no trace of that in the data.
So, in a graph (just example numbers):
http://s1311.photobucket.com/user/RichardC10/media/sine-to-sawtooth_zps19ef92ce.jpg.html
Ole said,
April 14, 2014 at 2:27 am
Previously I advocated the idea that inmarsat engineers were free to choose whatever bias/offset they liked for the purpose of presenting the BFO diagram.
Nevertheless another idea on the C-Band correction in the ground station in Perth occurred to me (it maybe just invalid). As the name already suggest inmarsat is mainly a marine application, the aero stuff is just an add-on. Marine terminals would not need Doppler compensation.
On the risk of being chauvinistic: Probably more than 80 percent of the inmarsat comms originate in the northern hemisphere. This might be the rationale for compensating the C-Band doppler only to a degree where the residual C-Band doppler is the same size as the L-Band doppler, as was originally proposed by Richard. If there is an “L-Band doppler” left by the C-Band correction, this would be equivalent to an (albeit imperfect) L-Band auto-compensation of D2 for all marine terminals that are in the northern hemisphere (probably >80%).
Just speculation.
Ole said,
April 14, 2014 at 3:01 am
richardc10 said,
“So, in a graph (just example numbers):”
Yep, that’s exactly the image I tried to imagine. (actually I failed to imagine how the grey correction function would look like).
We don’t know how the GES in Perth works. This would be the logical way if a residual D3 has to be accepted and the rationale were to minimize the maximum change rate of the residual D3. OTOH the change rate of D3 is quite small : ~200Hz/12h but maybe by using the above correction they gain some permil in accumulated bit error rate. That idea still could be combined with rough auto-compensation of D3 for terminals in the northern hemisphere. Just speculation again.
Skwosh said,
April 14, 2014 at 3:11 am
@richardc10 I like your new summary plot very much – excellent visual representation of what is going on – and expressing the D1 D2 D3 as shifts rather than speeds make it very clear that the signs correspond to what would be expected physically.
I’m trying to see how re-scaling D3 (rather than having a residual) works out by eye as I’ve still not entirely given up on the presentation oversight idea… so same sort of outcome (re-scaled D3 rather than a residual) as @Ole’s (April 14, 2014 at 2:27 am) speculation – but attributed to a different cause, and with the a factor (slightly larger than L-band) of C-band minus L-band…
marvinvestal said,
April 14, 2014 at 6:56 am
I have 2 questions. How reliable is the time uncertainty of +/-300 microseconds and is it round trip or each way? Has anyone seen the actual measurement of the time delays, and if so where are they? Without this info I am skeptical of the conclusions drawn by Inmarsat. This is a great blog that has done much to allay my ignorance, but without definitive data I remain skeptical. I have expressed this skepticism in my blog marvinsthinking.blogspot.com and have done calculations using the established facts, but rejecting Inmarsat’s flight paths. This may only demonstrate my ignorance, but without the actual data we can only speculate.
Alex Siew said,
April 14, 2014 at 7:03 am
@GuardedDon,
Thank you for your reply. Regarding the antenna, Malaysia Airlines issued a statement to say that the plane was using Aero H. In the “Inmarsat 101″ slides, the SDUs by Honeywell offering Aero H were listed to be paired with a high gain antenna HGA 6000 manufactured by Omnipless (now Cobham?) and described as “Tail Mount”. There is a picture of the antenna on the Cobham’s website, it is like a large round knob and stated to be designed for “mounting under the tail radome of an aircraft”.
Both the Honeywell’s manual and the Thrane & Thrane’s manual refer to a “battery”. See for eg at pages 4-5/4-6 and F-19 for the former and page 901 for the latter. There is a service letter dated Nov 9, 2007 from Thrane & Thrane posted on the net with a reminder that the Aero I battery’s life is 5 years.
I haven’t been able to find any info on the voltage of the Honeywell’s SDU’s battery. Do u think this battery would have sufficient power to transmit the faint pings to the satellite?
Regarding the story about the co-pilot’s call, the Malaysian authorities have come out to deny the story. There were some posts on PPRUNE much earlier about the authorities having checked with telecom companies about passengers’ phones being picked up by cell towers and the results were negative.
@Airlandseaman,
I know u and Duncan believe that the LOS values after take off are all positive values. However there are some who think that the value for the ping at 2.29am on the BFO chart should be a negative reading. If that is so, the LOS numbers derived from the chart (-39 knots to 125 knots) would correspond to the velocity of the satellite (50 knots to 159 knots) and movement of the satellite northwards reaching its northern apex at 3.36am and descending southwards thereafter, cosine approx 38.
I am not suprised that Inmarsat has refused to reply to your emails. If u watch Chris McLaughlin’s interview on Fox, Inmarsat rushed their analysis, they found the pings on Sunday and by Tuesday had turned over their northern/southern arc thing to the investigation team. In their haste, they could have overlooked that longer RT timings could also mean the satellite moving away from a stationary plane. I said in my first comment here and i will say it again, i believe the arcs for the first 5 pings are the same as for the final arc after discounting the movement of the satellite. Inmarsat can prove me wrong. In the meantime, Inmarsat’s stock price has gone up 10% amounting to an increase of over 300m pounds in market cap and i leave people to draw their own conclusions.
airlandseaman said,
April 14, 2014 at 7:04 am
richardc10:
Skwosh:
Send an email to me here:
airlandseaman@earthlink.net
…and I’ll respond with an updated spreadsheet that shows the values of D3 (C band correction) and methods used. D3 is the only part of the BFO puzzle that is straight forward to calculate, and not subject to much uncertainty. In fact, the only significant uncertainty is that due to not knowing the exact downlink frequency that was in use, within the range of 3600-3629 MHz. This ±0.4% uncertainty has an insignificant effect of the results.
Of course, D1 is what we want. After D3 is removed [ (BFO-D3) = (D1+D2) ], the remaining sum, D1+D2, is more difficult to decompose for several reasons. First, D2 is a function of the instantaneous position of the aircraft (but not the velocity), which is unknown for the final 8 transmissions. Thus, an STK or similar model is needed, like those Duncan and others here have produced. The STK models will only provide a set of D2 values (derived from the range rates) for a given set of assumptions for the final 8 points (starting point, autopilot configuration, altitude, speed and direction, etc.). But even if we had the correct model, and we had the exact values for D2, D2 itself must be decomposed further because it will still contain the sum of (1) the aircraft instantaneous position to satellite Doppler, + (2) an error term that results from the imperfect AES TX frequency offset.
It should be emphasized that Inmarsat surely knows these error terms and offset values. Depending on the Doppler correction system in place at the Perth LES, either (1) the LES calculates the required AES and sends the value to be used to the AES, or (2) the AES calculates the offset value, based on one of the several methods described in the patents and UT manuals, and sends the TX offset value to the LES. In either case, the LES record will contain the offset values, and the D2 values will contain the residual error, but Inmarsat has not disclosed them. They are buried in D2 (See ANNEX I, page 1 definition of D2: “Not corrected by system = measured frequency offset???). Under normal flight conditions, the residual should be <±30 Hz.
My spreadsheet graphics suggest that an AER might exhibit a repeatable pattern for this residual TX offset error that is dependent on the direction of flight and the state of the spacecraft at the time (headed north or south). For example, one could reasonably assume that whatever algorithm is in used to calculate the AES TX offset, it will depend on some simplifying assumptions, like ignoring the second order effects of acceleration of the aircrfat or satellite or both. This in turn will result in a predictable, repeatable pattern of small positive or negative offset errors, the sign of which is dependent the aircraft traveling straight and level to the north vs. south. The sign for a given time will likely depend on the whether the spacecraft and aircraft are going the same N-S direction, or in opposite directions at the time of the sample. If this hypothesis is correct, it would explain how Inmarsat might in fact have determined that that MH370 went south.
Skwosh said,
April 14, 2014 at 7:59 am
@richardc10 I realise it is generally a sign of desperation to doubt the data… but just to repeat my proposal as it may well have got lost in my other incessant rambling/jabberings:
[1] Say there is no correction of D3 on the ground (as you said earlier “…the fact it [D3] appears at all in the Inmarsat explanation suggests it is not zero…”)
[2] Say the actual raw recorded measurements are at L-band frequencies (so perhaps after a down-conversion on the ground).
[3] Say at some stage in the analysis (perhaps even just at the very end when someone – possibly not in the core engineering team – was deciding how to *present* the graph for public consumption) there was an attempted to subtract *all* of the D3 Doppler from the numbers (to make them as they would be ‘measured’ at the satellite – so intended perhaps to be consistent with the red-circle and the text “not corrected by system = measured offset”)… but who ever did this accidentally used the L-band frequency rather than the C-band frequency to remove D3 (thus leaving a component scaled at the difference between the two frequencies – which is roughly 20% larger than the L-band frequency alone).
airlandseaman said,
April 14, 2014 at 10:07 am
Skwosh:
[1] Annex I page 1 clearly states that the BFO values include the D3 component (C band Doppler). It must be subtracted to get the total L band (D1+D2).
[2] The receiver at the LES does not donconvert to the L band, and even if it did, the hetrodyne process simply subtracts a constant freqency from the C bnad observation. It has no effect on the Doppler, regardless of the IF frequency.
[3] Sounds like baseless speculation. Why not accept what is defined in the Annex I, and subtract D3 from the sum to get D1+D2? D3 Values are here:
UTC D3= C band Doppler (Hz)
16:30 -83.55
16:43 -79.09
16:56 -74.38
17:07 -70.21
18:26 -36.50
18:28 -35.08
18:29 -34.61
19:41 0.24
20:41 29.07
21:41 55.52
22:41 77.84
0:11 100.88
Skwosh said,
April 14, 2014 at 11:24 am
@airlandseaman We are trying to understand why the current model requires a time-linear correction of order ~60Hz. All/any speculation as to where this might come from, baseless or otherwise, is more than welcome!
You may want to take a look at @richardc10′s ‘state of play’ graph here: http://s1311.photobucket.com/user/RichardC10/media/Modelcomponents_zpsa56c7c9f.jpg.html
In order to try to help with this, here is my attempt to present (at some considerable effort) a formal summary of the current ‘state of play’ (my apologies to @richardc10 if I have made any errors – to which I am prone – I hope he can point out any corrections that may be required):
The model converts speculative aircraft tracks into BFO values intended to correspond to the values plotted on the Inmarsat BFO graph. The model can be expressed as follows:
F_BFO = F_CoreModel + F_LinearAdjustment
Where:
F_BFO is the quantity plotted on the Inmarsat BFO graph.
F_CoreModel = – ( (V_AS – V_AS_FixedPosSat)*F_L_Band + V_SG*F_C_Band )
F_LinearAdjustment = F_Bias + F_Residual*(t-t_start)/(t_end-t_start)
V_AS is the range-rate (rate of change of distance) between the aircraft and Inmarsat-3-F1.
V_AS_FixedPosSat is the range-rate between the aircraft and a truly *geostationary* satellite fixed at the mean position of Inmarsat-3-F1.
V_SG is the range-rate between Inmarsat-3-F1 and the ground station.
All V_ (range rate) quantities above are assumed to be divided by the speed of light and are dimensionless.
F_L_Band is the constant frequency used by the uplink from the aircraft to the satellite.
F_C_Band is the constant frequency used by the downlink from the satellite to the ground station.
F_Bias is a constant frequency used to accommodate system bias chosen so that F_BFO at the start of time is equal to the first measured (blue) point on the Inmarsat graph.
F_Residual is a constant frequency used to scale a time-linear correction so as to give a good fit at the end of the graph (currently ~= 60Hz).
Richard’s (@richardc10′s) previously posted calculations and presentations are *not* expressed in terms of V_AS and V_AS_FixedPosSat (though his method is equivalent). He instead decomposes the contributions due to the aircraft-satellite motion and corrections differently – his choices are *very* useful in visualising and reasoning about the overall behaviour of the plots, but I have not used them here for reasons of exposition. I describe the correspondence between his notation and mine at the end of this post.
Brief description of the ideas behind model:
[1] The model proposes that the aircraft is actively trying to correct for Doppler shift on its transmissions to the satellite.
[2] The model proposes that the aircraft is calculating these Doppler corrections by using knowledge of its own position and velocity combined with the simplifying assumption that the satellite is truly geostationary:
Aircraft correction = V_AS_FixedPos*F_L_Band
[3] If the aircraft does this then the corrections it will be applying will not be perfect because its geostationary satellite assumption means that no account is being made of the satellite’s velocity or the satellite’s true position:
Actual Doppler from aircraft to satellite = – V_AS * F_L_Band
Thus:
Offset observed at the satellite = ( V_AS_FixedPosSat – V_AS ) * F_L_Band
[4] If the values plotted by Inmarsat on their BFO graph were simply equal to this offset, but as it would be measured after transmission to the *ground*, then the model would predict values for the BFO graph as follows:
F_CoreModel =
– ( (V_AS – V_AS_FixedPosSat)*F_L_Band + V_SG*F_C_Band )
However, a fixed offset *and* a fairly substantial time linear term are also required in order to get a good fit, and this is the F_LinearAdjustment term referred to earlier.
—–
The correspondence between the above and the notation used in Richard’s ‘state of play’ graph is as follows:
D1 = – ( V_AS_MovingToStatic – V_AS_FixedPosSat )*F_L_Band
D2 = – ( V_AS_StaticToMoving*F_L_Band )
D3 = – V_SG*F_C_Band
Where:
V_AS_MovingToStatic is the range rate between the aircraft and the satellite at its true position, but setting the satellite’s instantaneously velocity to zero.
V_AS_StaticToMoving is the range rate between the aircraft and the satellite at its true position, but setting the aircraft’s instantaneous velocity to zero.
Thus,
D1 + D2 + D3 = F_Core_Model
D1 + D2 = – (V_AS – V_AS_FixedPosSatellite)*F_L_Band
Hope this helps!
Skwosh said,
April 14, 2014 at 11:34 am
Correction to the above in section [2] of the model description:
“Aircraft correction = V_AS_FixedPos*F_L_Band”
This should read:
“Aircraft correction = V_AS_FixedPosSat*F_L_Band”
Skwosh said,
April 14, 2014 at 11:38 am
Correction to the above:
All values quoted for F_Residual above should be – 60Hz and not + 60Hz.
Skwosh said,
April 14, 2014 at 11:55 am
@airlandseaman Regarding your specific point: You say “Why not accept what is defined in the Annex I, and subtract D3 from the sum to get D1+D2?”
I think we’d all very much *like* to accept that. It’s just that, given our current model (which for sure could be wrong – but does otherwise is really quite simple and seem to fit a lot of other things rather well) we can’t fit that assumption (BFO = D1 + D2 + D3) without adding a large time-linear kludge-factor – so… we’re scratching around for possible explanations as to why that might be in order to *retain* the notion that D3 was in the *actual* data and that it *must* have been at the C-band frequency – so an ‘oversight’ in the numbers used for the presentation is perhaps one possible explanation for this.
airlandseaman said,
April 14, 2014 at 12:13 pm
Skwosh:
As I said above, correcting for the C band is the easiest and most exact part of all this. The frequency (~3614.5 MHz) and the exact locations and velocities of the satellite and Perth C band antenna make tis a simple trig solution based soley on well established, publically available data. It requires no interpretation of the BFO data at all to get the C band correction. So why not start with that? It works. Then you can noodle on the decomposition of the (D1+D2) term.
airlandseaman said,
April 14, 2014 at 12:23 pm
All:
My latest analysis is available here:
https://dl.dropboxusercontent.com/u/32349391/BFO_Analysis_2014-04-14.xlsx
Skwosh said,
April 14, 2014 at 12:33 pm
@airlandseaman This *has* been done – D3 at the C band *is* in there (it’s the D3 component on @richardc10′s graph) – we also have a nice simple model for ‘D1 + D2′ that explains the north/south asymmetry and even appears to fit the take-off values – but the problem is – if we put our simple ‘D1 + D2′ model together with D3 at the C-band frequency we still need a large time-linear correction to get a good fit – *one* way to explain this (my baseless speculation as you so charmingly describe it) is that it could be down to some sort of mistake in the data that was *presented* to us – I’m not saying we or anyone else *should* correct for D3 at the L-band frequency – I’m just suggesting that perhaps someone *accidentally* may have done this in the numbers that were plotted on the graph for the public presentation – I suggest this *only* because it could perhaps account for the discrepancy we find – but for sure they may be many other and more credible explanations – including that the model of the ‘D1 + D2′ part we have is wrong.
richardc10 said,
April 14, 2014 at 12:55 pm
@ole @skwosh etc
..the 60Hz correction
Another idea (also completely unverifiable). The BFO model is based on an AES correction for the aircraft Doppler contribution that isn’t completely realistic – it uses a nominal satellite position – so it isn’t perfect. The calculation of the Doppler correction uses a number of sin/cos/atan terms so needs appropriate floating point calculations. It might also be done iteratively, that is each calculation is based on the last, with delta changes. If there was some minor rounding error the correction could be biased and creep in one direction with time (but still be within the relatively wide error bars, at least compared to the raw Doppler – the requirement on the correction was not to be exact, just adequate). Inmarsat did testing of their conclusion, including with B777s presumably with the same AES equipment, so would have seen this effect, if it exists. More speculation, of course.
airlandseaman said,
April 14, 2014 at 1:04 pm
Skwosh:
OK. I see that you have essentially the same D3 correction I have found, but I don’t see any basis for the constant or time varying “corrections”. I think it is more likely that the model has errors in the math or assumptions that need to be fixed, not “adjustments” the BFO data to fit the model.
Can you make your Southern Trak 287kt model available for review?
sk999 said,
April 14, 2014 at 1:39 pm
Further information on how the Honeywell SATCOM works is provided by a poster, Backseater, over at airliners.net:
————————————
http://www.airliners.net/aviation-forums/general_aviation/read.main/6042926/1/#1
Just got my paper copy of AWST (Mar 31, 2014). Excerpt form “New math” By Amy Svitak:
“Built by Honeywell Aerospace, MH370′s L-band satcom terminal uses position, speed, direction, pitch, roll and yaw data from the aircraft to steer its antenna and maintain a lock in Inmarsat 3-F1. But while the terminal is continually pinging the spacecraft, this data is only used to orient the antenna and offset transmitted frequency due to Doppler shift. It is not transmitted off the aircraft.”
—————
So yes, the Doppler compensation is based on calculation, not the measured P-channel
frequency.
Random conjecture – MCS-3000/6000 are two other Honeywell satcom models. They are not mentioned as much as MCD-4000/7000. Why? In the latter two, the 4 and 7 refer to the number of channels. One would infer that the 3 and 6 in the other models also refer to the number of channels, but one less for each. Why did things change? Perhaps the 3 and 6 models used the old method of Doppler correction done by monitoring the incoming frequency and applying the measured offset (with opposite sign) to the transmitted frequency, while the 4 and 7 models use the computed-Doppler method. By not monitoring the incoming frequency, one channel is freed up for revenue-generating operations, just like the patent application described. It’s all about the money. If this conjecture is correct, it would mean that MH370 had either the 4000 or 7000 model.
Skwosh said,
April 14, 2014 at 1:43 pm
@airlandseaman I think I am starting to get to the stage where I need to go and have a bit of a lie down – however, before I do, I think it is important to emphasise that we have got to where we are here through an open and highly collaborative effort – many people have contributed much time and many ideas and insights to this ongoing endeavour – and in this particular instance I don’t have access to the particular data that you’re asking for, so you will need to ask someone else.
sk999 said,
April 14, 2014 at 2:22 pm
Random stuff …
The AES maintains something called a “system table” that includes information about the satellite orbit. The GES send the AES updates periodically so it can keep its table up to date. This information includes the satelllite longitude, latitude, and “Right Ascension Epoch”, which turns out to be the UT on New Year’s Day that the satellite crosses the Equator. All of these numbers are quantized – longitude is in units of 1.5 degrees, inclination in units of 0.625 degrees, and UT in units of 10 minutes of time. This info is probably not exchanged for a simple “ping”. I found a Rockwell-Collins installation manual which said that if their SATCOM receiver gets out of whack, it will reset the system table to default values (satellite exactly on the Equator at 64.5 degrees).
The maximum allowed frequency offset for the AES transmission (as measured at the satellite) is +/- 383 hz.
Land and sea mobile stations are not required to compensate for Doppler. Since they are generally moving much slower than aircraft, the Doppler effect is simply absorped into the overall tolerance budget. A boat going at 30 knots viewing the satellite at an elevation close to 0
degrees will have a Doppler shift of 82 hz. For the nominal MH370 flight path, the peak error induced by computing the Doppler correction assuming that the satellite is exactly over the Equator as opposed to on its true orbit is about 60 hz. The FCC document said that Inmarsat expected it would allow the satellite to reach 2.5 degrees of inclination; the error would then grow to about 90 hz. It is possible that Honeywell decided that it was safer or just easier to avoid the complexities of modeling the exact orbit when computing the Doppler correction.
References:
“Global Mobile Satellite Communications: For Maritime, Land and Aeronautical Applications”
Link to the “Classic Aero Specification” in story at the top of the page.
airlandseaman said,
April 14, 2014 at 2:52 pm
sk999:
Thanks for the last 2 posts. Some useful info there. All those points are consistent with the information I have found for the system. However, I don’t interpret the quotes to necessarily mean that the P channel is not used at all, but only that the AES does not transmit any information about the Doppler correction applied. I think it is likely that the position, speed, direction, pitch, roll and yaw data from the aircraft data buss are used to steer its antenna while using the P channel Doppler to offset the TX frequency. If MH370 had a directional antenna, it had to use the configuration file and the position, speed, direction, pitch, roll and yaw data to steer the antenna before it would be possible to get a carrier lock. But once that is accomplished, the TX correction is far easier to get from the P channel than it is to calculate it from the aircraft IRS data. In the end, it does not matter which of the many algorithms were used. What is important is that an imperfect corection is applied and the residual offset error is a “hidden component” in D2.
Skwosh said,
April 15, 2014 at 2:34 am
@sk999 Excellent digging! My thoughts on your thoughts:
I agree that your reasoning about the number of channels agrees with the discussion in the patent and thus with the model numbers, but on the other hand I think these systems do have to listen all the time for control information as part of the protocol… so I’m still pondering.
I keep thinking that it *is* a very good question as to why these systems would *not* just measure incoming frequencies for their Doppler corrections because, on the face of it, it makes a lot of sense to do it that way and seems like a simple and elegant solution… except… we are thinking that if it *does* work that way then it’s difficult to explain the BFO graph… but, anyhow, my thoughts so far on this (no doubt repeating myself from earlier in some cases!):
[*] If you are *looking* for a transmission on a pre-specified base frequency from a given satellite (at start up, hand-over or in a state of confusion etc.) then you don’t have an incoming frequency measurement yet – so if you use known pos/vel info then you already know roughly what the Doppler shift is going to be beforehand, so you can pre-emptively offset your receive frequency and your transmit frequency for any un-solicited transmissions you may want to make (which could be very important for not going outside channel limits in these sorts of situations).
[*] Your ability to accurately measure the frequency of incoming signals is only going to be as good as the accuracy of your local frequency reference – and as far as I can see, if you use an inaccurate frequency reference to calculate the Doppler correction then the error in that frequency reference is going to get *doubled* (rather than cancel out) in your ‘corrected’ transmission frequency. Having said this I guess we think the local oscillators are pretty stable and also kept pretty accurate so this is probably not an issue.
[*] I would argue that it is not going to be difficult to use position and velocity information if you *already* have it for other reasons and have good reason to believe it is reliable. The Doppler calculation is not exactly rocket science, particularly if you assume a fixed satellite (the satellite position info is already in the data table) – then you just feed the expected Doppler factor to both the transmit and the receive systems. Job done. No need to do any measurements, no need to feed the results of the measurements from receive system to transmit system, no need to keep track of when you last made a measurement.
I think that anyone still advocating the idea that these systems *only* use measurements of incoming transmissions for Doppler correction needs to explain why you are finding statements in manuals and elsewhere saying that position and trajectory information *is* used for Doppler compensation. It may well be that some sort of ‘mixed’ approach is used – but it seems increasingly inescapable that, at least at *some* stages in the process/protocols, these particular devices *do* use pos/vel info as part of their Doppler compensation.
airlandseaman said,
April 15, 2014 at 6:27 am
WRT the BFO analysis, our common objective here is to figure out D1=BFO-(D3 +D2).
The BFO data has been provided by Inmarsat. IMHO, the BFO data should be taken literally as it was presented with no assumptions about Inmarsat mistakes, assumptions about the scale being absolute values, etc.
It seems many here are in agreement that D3 can be derived from publically available data (Perth antenna location and I3-F1 satellite ephemeris).
That leaves D2. D2 is difficult to derive precisely due to uncertainty in the AER Doppler Corrected TX Frequency. However, that uncertainty is bounded to a maximum of +/- 383 Hz, regardless of the method chosen by the equipment manufacturer to meet the performance specification. If the manufacturer chooses to use outbound the P channel Doppler to estimate the TX Doppler correction, that correction will be more accurate than it would be using a look up table and the IRS or GPS data (via 429 bus) to calculate the TX Doppler correction. Moreover, it is easier from a circuit design POV to estimate the correction from the outbound carrier. Regardless of the method used, we are left with the reality that WE do not know the value of the TX correction applied, or residual error, even if Inmarsat does. So, what to do?
There is one more piece of potentially valuable information supplied by Inmarsat that, until now, we have not tried to exploit. That is the so called “Predicted Northern Track” and “Predicted Southern Track” time series on ANNEX I, Page 2. Over the last 3 days, I have been revisiting the assumption that these data are worthless cartoons. They may well be based on nothing more than assumed northern and southern routes, but the difference in these plots is surely the result of the satellite inclination, and how the satellite N-S velocity affects the TX offset calculated, regardless of the method used to calculate the offset.
To explore this idea, I expanded the BFO analysis to include the predicted N & S time series so all three time series could be compared after D3 is removed. The results are quite interesting. As with the Inmarsat raw BFO plot, the Southern route (D1+D2) is better correlated with the observed (D1+D2) data. But the difference between the Northern and Southern time series may be telling us something about the systematic bias errors produced by the TX Offset algorithm, whatever method is used.
If it is assumed that the TX Offset residual error is symmetric (equal magnitude but opposite sign) for aircraft headed generally north or south, then the residual error can be estimated to be 0.5*(Npredicted-Spredicted) at each epoch. Using only this assumption of symmetry, “Offset Error Corrected??? values of (D1+D2) can be plotted. Results are here:
https://dl.dropboxusercontent.com/u/32349391/BFO_Analysis_2014-04-14.pdf
AndRand said,
April 15, 2014 at 10:55 am
Here is some good food for thought for you:
http://mcleodsean.wordpress.com/2014/04/15/mh-370-back-tracking/
I thought it would be impossible to calculate best fit tree for both ping rings and BFOs but Sean McLeod proved me wrong
He did it backwards starting from leafs – points on last known ping ring.
BTW. Inmarsat BFOs doesn’t match at all as previously observed, he used best fit BFOs to known track – not scaled down by 4 to 900MHz but with polynomial 0.3673* LOS + 94.975
As you can see, even with that fit, tracks are bit unlikely.
BTW2. blackbox batteries and its beacon is said to send sound signals:
* 160dB up to 30 days
* 157dB next couple of weeks
* 150dB up to 90 days
It is very disappointing there are no new listenings.
Ole said,
April 15, 2014 at 11:38 am
Fun stuff to read on D3 correction:
https://www.miteq.com/docs/20TEC.PDF
Still digesting it, I assume the process described applies to the earth station in Perth. What I understand so far:
- the frequency conversion in the satellite is expected to drift !
- D3 correction is calculated according to long term measurements of a pilot signal sent through the transmission path from an L-Band pilot generator.
- D3 correction is done in the downconverter.
Ole said,
April 15, 2014 at 12:56 pm
According to the doc the drift in sat’s frequency translation is a long term process.
But it was close to equinox, meaning the sun is above the equator. The satellite would have gotten into the earth’s shadow around midnight. The batteries are over fifteen years old, so it might experience voltage drops – maybe affecting the stability of the frequency conversion?
If the sat was in the earth’s shadow for 2 hours (eclipse of the moon ~1hour) that would have been from ~19:00 to 21:00 UTC (65 degree ~ UTC +4).
Alex Siew said,
April 15, 2014 at 1:27 pm
@airlandseaman
It is stated on your latest chart: 08.11am AES to S/C LOS velocity = -111.18 knots.
Can i ask u whether your calculations also show the approximate LOS values for 3.40, 4.40, 5.40, 6.40am as follows: -22, -33, -62, -86 knots.
If so, it would mean the LOS values are contributed solely by the movement of the satellite, according to the formula given by Duncan in his March 26 2.50 comment in this blog ( satellite component of LOS value = velocity of satellite cos 45 or 0.7vz). The satellite velocity (vz) for these 5 pings are: 32, 47, 88, 123 and 159 knots.
Do your calculations also show the LOS value for 2.29am as -34 knots? I have previously argued that this reading should be reverse ( the satellite was moving closer to the plane prior to 3.36am with the satellite moving away thereafter).
If your calculations do show the foregoing values, it would mean the plane had already crashed by 3.40am, if not by 2.29am.
I look forward to your reply.
airlandseaman said,
April 15, 2014 at 2:46 pm
AndRand:
Can you explain the logic for 900 MHz? That frequency is not used anywhere in the Inmarsat system. I don’t understand why that number appears in anyone’s analysis.
Alex Siew:
My results do not match the values in your last post. You can download the complete BFO analysis with all the LOS velocities here:
https://dl.dropboxusercontent.com/u/32349391/BFO_Analysis_2014-04-15.xlsx
…or a pdf of the graphs only here:
https://dl.dropboxusercontent.com/u/32349391/BFO_Analysis_2014-04-15.pdf
Note that these are (D1+D2) LOS relative velocities between the aircraft and satellite. To remove the D2 component, the position of the aircraft is required for each data point. Once D2 is removed, the remaining value (D1) is the aircraft velocity along the AES-S/C LOS path, not the aircraft velocity in the local horizontal plain. To map the LOS aircraft velocity to the horizontal plain, the D1 Doppler value (converted to speed) must be divided by COS(el), where el is the AES antenna elevation. Of course, if the aircraft positions are “known” from a STK or similar path model, then the elevation angle is easily derived for all positions. The velocity so mapped to the local horizontal plain is the radial component of the aircraft speed. If the ground track speed is known from the model, the angel at which the aircraft crosses each arc can be computed and by iterating the assumed speed and positions and the BFO analysis, it should be possible to get a simultaneous solution for the path and Doppler derived radial velocity.
Alex Siew said,
April 15, 2014 at 6:31 pm
@airlandseaman,
Thank you for the reply. When i saw your first chart with the LOS value of -111.18 knots for the 8.11am ping which works out to be exactly 0.7 of the satellite velocity (159knots), i was expecting the other LOS figures to likewise be a function of 0.7 vz. (The previous set of LOS values (39.77 to 125.35 knots) was a function of 0.788 vz).
Having no mathematical training, i cant really follow completely the analysis in your reply but appreciate your detailed explanation. I was just wondering whether the BFO chart would be consistent with the plane having crashed early on, with the Doppler effect provided solely by the movement of the satellite to and from a stationary plane. To a layman, the plane could have flown north, could have flown south, or could have crashed early on. Dont understand the collective silence on the part of mainstream media regarding Inmarsat’s refusal to release the data on the earlier pings. Nothing proprietary there and the data can only help, not hinder the search.
airlandseaman said,
April 15, 2014 at 6:45 pm
Alex Siew:
I can assure you the plane did not crash before 00:11 UTC. The Doppler data alone proves that it was still moving at 00:11. Note that the satellite induced C band Doppler is subtracted from the D1+D2 values, and the satellite induced L band Doppler is small compared to the aircraft Doppler, so it was definately moving >300 kts.
richardc10 said,
April 15, 2014 at 10:01 pm
Here is a rather depressing view.
The data as presented in the graphs has a number of anomalies as have been discussed.
a. The BFO numbers should be scattered around 0, positive and negative. There is no reason for the large positive offset given the published synchronisation methods. I have always taken this out in the model discussed before.
b. the range of the data between 16.30 and 00:11UT (160Hz) is too small to accommodate all of the 3.6GHz downlink Doppler between those times (184Hz) plus the variation in D2 required by the Inmarsat model (51Hz, acting in the same direction). However, ‘D3’ in the graph cannot be zero, it is at least a substantial fraction of 160Hz.
c. It is mysterious that the C band downlink Doppler appears at all. As has been pointed out by others, Inmarsat have the Pilot Frequency system available on all their links, C and L band, specifically to take out link Doppler. It so happens that there is an (inexact) alternative on L band for the aircraft up-link, since L band channels are expensive for the aircraft terminal. C-band Doppler should not come into the equation.
d. Information has been released ONLY when it is specifically required. The 00:11 ping arc was revealed to convince people that the aircraft was not in the South China Sea – the other pings have been kept secret. The Inmarsat graph was published to show the pings followed a line representing the Southern rather than one for the Northern track – and only that.
e. Inmarsat have an eye to their commercial advantage as is clear from their public statements. Nothing wrong with that, they are not the bad guys here. This new analysis technique may have commercial applications and they will not want to reveal more than they have to. Inmarsat are not under investigation – it is not their aeroplane in the ocean.
Conclusion: the data published data have been skewed to conceal the underlying system performance. A substantial and changing component similar to the C-band Doppler has been added where only a residual (or nothing) exists in the real data. This does not change the stated conclusion over South/North track as the skew has been applied to the models and the data.
Others can keep going on analysing the published data, but I have lost trust.
airlandseaman said,
April 16, 2014 at 2:15 am
richardc10; April 15, 2014 at 10:01 pm:
I find nothing in the raw BFO data inconsistent with Inmarsat statements defining the BFO, or the public statements that the aircraft was moving in a radial direction away from the satellite at all transmission times.
It should be noted that the Butterworth radar shows a north west track between 18:02 and 18:22 UTC, but this data falls in-between the AES 17:07 and 18:26 transmissions, and the 3 transmissions between 18:26 and 18:29, following shortly after the loss of radar, indicate a turn, and possibly a decent. Thus, the radar track to the northwest between 18:02 and 18:22 is not inconsistent with the statements made by Inmarsat that the aircraft was moving away from the satellite at all transmission times.
a. There is no reason to think that the BFO numbers should be scattered around zero. The C band Doppler was -85 .6 Hz at the time of the first data point (16:30 UTC), which means the (D1+D2) term was -5.5 Hz on the ramp at the time of push back. The ramp is almost due east of the satellite at that time, so the satellite induced part of the L band Doppler was ~0. Attributing all of the -5.5 Hz to the aircraft motion, the radial speed on the ground was ~2.8 kts (walking speed), which is totally consistent with the pushback speed. An unofficial ATC transcript suggests MH370 requested approval for push back and start up at 16:27:27 UTC, and announced it was ready to taxi to the departure runway at 16:32:13. Thus, the 2.8 kts speed on the ramp is exactly what we would expect at 16:30.
b. After removing the C band Doppler, the remaining term (D1+D2) varies by more than 300Hz between 16:30 and 00:11.
c. It is not at all mysterious that the C band Doppler is included in the BFO values. ANNEX I defines the BFO to include it (D3). Moreover, the fact that this interpretation of ANNEX I leads to a speed on the ramp at 00:30 of 3 kts is about the most compelling reason I can think of that the interpretation is correct.
I invite you to look at the complete analysis here:
https://dl.dropboxusercontent.com/u/32349391/BFO_Analysis_2014-04-15.xlsx
…or in the pdf version here:
https://dl.dropboxusercontent.com/u/32349391/BFO_Analysis_2014-04-15.pdf
airlandseaman said,
April 16, 2014 at 2:51 am
Does anyone know the KLIA gate from which MH370 departed?
LGHamiltonUSA said,
April 16, 2014 at 3:26 am
@airlandseaman ~
Please refer to the official ATC transcript issued by MAS for the subject flight MH370. I believe it contains the KLIA departure gate information you are seeking:
http://www.malaysiaairlines.com/content/dam/mas/master/en/pdf/Audio%20Transcript_MH370%20Pilot-ATC_BIT.pdf
~LGH~
LGHamiltonUSA said,
April 16, 2014 at 4:17 am
@airlandseaman ~
The following Google link contains a .pdf file for a clear, detailed aerodrome map of the WMKK (KLIA) runway facilities:
http://www.google.com/url?q=http://va-transaero.ru/files/charts/WMKK.pdf&sa=U&ei=Y3JOU5GbN-3nsATd-oGQBg&ved=0CCAQFjAJ&usg=AFQjCNGX3tvLaItGcSNwVxWpdRJhIGEbIQ
I did not choose to deconstruct the pure URL so as not to possibly corrupt the file.
~LGH~
airlandseaman said,
April 16, 2014 at 4:47 am
I found the gate. It was C1. The details of the pushback timing and path are here:
https://dl.dropboxusercontent.com/u/32349391/MH370%20push%20back%20and%20taxi.pdf
LGHamiltonUSA said,
April 16, 2014 at 7:45 am
@airlandseaman ~
I found the official Malaysia AIP Department of Civil Aviation document:
http://www.google.com/url?q=http://aip.dca.gov.my/aip%2520pdf/AD/AD2/WMKK/WMKK-Charts%2520Related%2520To%2520KL%2520International%2520Sepang%2520Airport.pdf&sa=U&ei=V55OU7jXKsGLyAS624KYAQ&ved=0CBAQFjAC&usg=AFQjCNG8C2MakzPdvgSe9dxu4bY7an1G_w
¤ Official WMKK (KLIA) Aerodrome Charts
~LGH~
Skwosh said,
April 16, 2014 at 7:50 am
@Ole Very interesting find of yours – I must say those diagrams at the end have been doing my head in (I am wondering if Inmarsat have a department specialising in un-necessarily confusing diagrams… I am particularly fond of the text: “The down converter output to the pilot receiver is frequency corrected. The pilot receiver calculates the uncorrected frequency.”) I need to spend more time on them, but I certainly understand the basic principle here – and it seems there is now no doubt that they do *actively* correct for the ‘D3′ Dopplers in hardware and that it is therefore increasingly difficult to understand why these Dopplers would still be in the measurements. Interesting also that they seem to be expecting perfect correction on the satellite-to-aircraft-back-to-satellite route – maybe it came as a bit of a surprise to them that this correction wasn’t actually perfect – surely not?
Skwosh said,
April 16, 2014 at 7:53 am
@richardc10
Thanks for all of the time that you have put into this, and particularly all the effort you have spent in explaining your methods, providing us with plots and engaging openly in speculative discussion. You are a star! I can completely understand your position regarding further work. I should probably stop too.
Regarding your speculation about Inmarsat deliberately obfuscating/skewing the data: I have been thinking about the more societal dimensions of this problem for some time – and I have always wanted to give Inmarsat the benefit of the doubt. As you say, they are not the bad guys – but I also understand the pressures within some such organisations and the desire to pounce on any potentially useful IP – and there is perhaps a ‘pitch’ being made in the text of the Inmarsat release “[...] Inmarsat developed a second *innovative* technique that took into account the velocity of the aircraft relative to the satellite [...]” However, I think for them to deliberately obfuscate/corrupt what they were doing in the public release would have been an extraordinarily risky/ill-advised thing to do under these *particular* circumstance. Where it to come to light that they did indeed do this then I do not think it would be difficult to spin it into a story about a company putting its own financial interests above the cause of providing maximum certainty, clarity and re-assurance to those in desperate need of it at the time. For this reason, among others, I think it is unlikely that they would have done this… However if they *have* done something like this then I would definitely expect them to have thought about some sort of plausible deniability – so were it to become apparent that the release was erroneous then they would be able to attribute it to some sort of ‘understandable mistake’ or oversight – perhaps under time pressure – and so they could plausibly argue that there was no deliberate intention to mislead/deceive/misdirect.
Your speculation is very interesting though – and running with it wildly for just a moment – if one *did* suspect Inmarsat of deliberately generating misinformation to protect their commercial interests then what *else* might they do? Might they perhaps sponsor credible sounding sock-puppets on forums/blogs such as this to deliberately steer contributors away from any genuine insights? It occurs to me that if there were such sock-puppets (and for clarity I’d like to emphasise that *neither* of us are *actually* suggesting this) then one might expect such a sock puppet to (1) get very agitated when people suggest there may be something fishy/incorrect about the Inmarsat data (2) to be highly dismissive/disparaging of any suggestions that might correspond to the *actual* methods used by Inmarsat (3) to actively promote any interpretation of the data that is in-line with the deliberate obfuscations introduced such as, perhaps, a *very* carefully chosen first BFO value. I’m sure you would agree with me that the idea that this sort of thing could actually be happening is just too farfetched to be at all credible.
Cheers!
airlandseaman said,
April 16, 2014 at 8:10 am
Skwosh:
Miteq is only one of many companies that manufacture Inmarsat ground station equipment. The document referenced by Ole is 18 years old and almost certaainly not the equipment in use at Perth today.Regardless of the specific pilot equipment in use today, Inmarsat’s statement reads in part:
“During the flight the ground station logged the transmitted and received pulse frequencies at each handshake. Knowing the system characteristics and position of the satellite it was possible, considering aircraft performance, to determine where on each arc the calculated burst frequency offset fit best.”
Moreover, ANNEX I explicitly defines BFO to include D3 (C band Doppler). It does not matter what equipment was in use, or how the equipment works. Inmarsat has defined the BFO components, and BFO includes D3.
Skwosh said,
April 16, 2014 at 9:16 am
@airlandseaman
I think we all agree that it certainly *looks* like there is a D3 component in the BFO graph. I don’t think @Ole would disagree with that either.
Incidentally, you seem to be *removing* D3 by *adding* it rather than *subtracting* it. I do not understand this.
In your spreadsheet you appear to take the BFO value (column ‘C’ in your spreadsheet) and you *add* your calculated C-band Doppler (column ‘I’ in your spreadsheet) and you then *negate* the result.
This is apparent in the formula for D1+D2 (column ‘J’ in your spreadsheet):
-(C[n] + $I[n])
Am I interpreting this correctly?
marvinvestal said,
April 16, 2014 at 11:46 am
Have you considered the possibility that the BFO data you are trying to analyze is merely low frequency noise in the system and has nothing to do with Doppler shifts? The ACARS system was not designed to determine the distance of the plane from the satellite, nor the velocity relative to the satellite. This is apparently the first time these determinations were attempted and I have seen no data on testing and validating the system for this purpose. Inmarsat claimed to validate the Doppler data by observations on other aircraft where the flight path was known, but have you seen that data?
AndRand said,
April 16, 2014 at 11:53 am
airlandseaman said,
April 15, 2014 at 2:46 pm
AndRand:
Can you explain the logic for 900 MHz? That frequency is not used anywhere in the Inmarsat system. I don’t understand why that number appears in anyone’s analysis.
I would say, vulgar easy
If you have LOS calculated you just derive frequency from Doppler formula to get such results:
Time (UTC) FREQ (GHz)
16:30:00 24.32
16:55:00 0.93
17:07:00 0.63
17:30:00 0.90
18:25:00 0.95
18:29:00 0.50
Average for all values is 0.45GHz, for mid 4 values (16:55-18:25) is 0.85GHz.
AndRand said,
April 16, 2014 at 11:56 am
btw. this trivial example is on LOS calculated for planned track:
Time Latitude Longitude Speed Heading
16:30:00 3.1 , 101.7 0 0
16:55:00 3.9316 102.1618 454 25
17:07:00 5.1962 102.6849 454 18
17:30:00 7.7715 103.5172 454 18
18:25:00 13.9124 105.5528 454 18
richardc10 said,
April 16, 2014 at 12:20 pm
@skwosh
This is more a philosophical issue. Information was created to address a single issue, that is whether the aircraft went North or South. That is all that was claimed for the published graph.
Nothing in the Inmarsat statement is formally incorrect. The only line that is marginal is ‘The blue line is the burst frequency offset measured at the ground station for MH370’. It doesn’t say ‘Blue line is the actual burst frequency offset values measured at the output of the first stage C-band downconverter before any Doppler adjustment’ or similar. That is what we would _like_ it to say, but it doesn’t. If they have tweaked the data to protect confidentiality issue, it does not affect the conclusion the graph draws in any way. If we seek to extract more information than is claimed that is our problem. We are in the position of an amateur sailor using a world atlas to sail an ocean (we don’t have anything else). We can’t complain if it doesn’t work – we are using it for a purpose that wasn’t intended.
I could be quite wrong, but I think it makes sense.
airlandseaman said,
April 16, 2014 at 1:27 pm
Skwosh:
Regarding the sign inversions…my original spreadsheet used the arbitrary sign convention “positive Doppler numbers” = “movement away” from the subsatellite point (or satellite). But I quickly realized that it would be more consistent with common convention to use negative numbers for movement away from the satellite, and positive values for movement towards the satellite. That way, a lower measured frequency, compared to the “at rest condition???, corresponds to movement of the source away from the observer, like the passing train. Looking back at the spreadsheet, the quick fixes I made to change the sign convention for all Doppler values makes the math hard to follow. I’ll double check all the signs to make sure, but I believe the final results are correct, even though you make a good point about the sloppy way I changed the convention. We know the satellite was moving away from Perth at 16:11 UTC, so those values should be negative per this convention, and they are. And we know the aircraft was moving away from the satellite at all the transmission times, so those numbers should also be negative, and they are. I’ll still take a close look to make sure its right. Thanks for bringing this to my attention.
Skwosh said,
April 16, 2014 at 1:45 pm
@richardc10 I agree – though I guess it depends on what is meant by *address* in “address [the single issue of] whether the aircraft went North or South”.
If they’d just issued a bit of paper on which they’d scribbled (in green pen) the words “We are very clever, and we say it could not have gone North – don’t question us. Signed the very clever people at Inmarsat” then that probably wouldn’t have cut it. At the other end of the spectrum, I guess, would be for them to have issued something that was very clear, and that moderately technical outsiders (and surely there are *many* such people interested in this – some for very obvious reasons) would have been able quickly to get heir heads around and to also agree, when asked by their less technical friends, that, yes, indeed it is clear that the aircraft can’t have gone North.
I guess what you’re suggesting is that we may have something in-between: A shock-and-awe ‘sciency’ graph, some text and a diagram that implies an *explanation* of how they concluded what they did but – actually – doesn’t really quite explain it.
I certainly agree that this is entirely possible – and that was actually my first ‘reading’ of it all those weeks ago – and like you – a reading to which I am now again gravitating (not that I have *any* reason to doubt their actual conclusion – I’m sure they wouldn’t have issued the statement unless they’d been very sure themselves that it was sound – and indeed I am much more confident that their conclusion is surely correct now given where we’ve got to, the closeness of the fit, the asymmetry aspects, the asymptotic aspects, the actual magnitudes of the numbers, the take-off fit etc.)
airlandseaman said,
April 16, 2014 at 1:48 pm
marvinvestal:
Admittedly, Inmarsat has created a lot of confusion…one might say deliberate misinformation…surrounding this “never before used technology”. It is really very misleading to call this new technology. That makes people question the accuracy and quality. But in fact, computing ranges using a calibrated round trip time delay is as old as the first satellites. Inmarsat uses the exact same technique every day to track all their spacecraft on C band TT&C (Tracking Telemetry and Control) frequencies. Virtually all spacecraft, both orbiting and deep space, are tracked using this ranging technique. The only thing new is applying this old technique to the specific case of the Inmarsat AES. The same is true for Doppler. Doppler measurements have been exploited with many different satellite systems to derive speeds. Again, it is old technology applied to a new case.
Inmarsat is just trying to look like they have invented something new for the PR and potential commercial value. The engineers that realized that this old trick could be used in a new application certainly deserve full credit and more for their quick thinking, but the techniques have been well proven over decades. It is solid, proven technology.
Skwosh said,
April 16, 2014 at 1:51 pm
@airlandseaman The way I read it, your interpretation/conventions make sense if you assume the Inmarsat BFO graph is ‘upside down’ – in other words – if you assume all the BFO values are negative rather than positive. Then you can indeed subtract the D3 doppler (which itself is negative at the start) to get a roughly zero value at the start, and all successive values (for your interpretation of ‘D1 + D2′) will also be negative.
Ole said,
April 16, 2014 at 1:58 pm
@airlandseaman
The first slide has the title “Doppler correction contributions”. I would take all contributions which are not marked otherwise as exactly that: contributions by *corrections*.
The 18 year old document – btw same age as the satellite – shows that the system is designed for D3 correction to take place in the downconverter before the IF is fed into the demodulators. The BFO that is measured during or after demodulation, consequently the BFO can only include that part of D3 that remains after correction. Or are you aware of a system redesign ?
@skwosh @richardc10
No doubt inmarsat is deliberately limiting the information they provide as much as they can. I don’t think it’s for commercial reasons. This analysis only was feasible because the satellite constellation was favorable. If the sat had been at it’s nothernmost point at the end of the flight and at it’s mean position at 19:40, this kind of analysis would not have worked: no D2 contribution at the end of flight and no D1 contribution at 19:40. So there isn’t much commercial value in this method.
To me, inmarsat’s (or indirectly MAS’s) reluctance to release any data seems to indicate there is something in the data that could embarrass their customer MAS.
I’m beginning to like the idea of partial D3 correction (to the size of L-Band doppler, i.e. -D2 for terminals in the same cone as Perth). It may be possible for the GES to assign frequency channels to the marine terminals such that terminals with similar D2 contribution use the same frequency sub-bands. These sub-bands could then be corrected en bloc for D2+remaining D3. The D3 correction could be chosen such that D2 for the cone with the most traffic is automatically compensated by the remaining D3, so that most of the channels don’t need further D2 correction. Maybe by this ordering the channels for the marine terminals, whose doppler contribution is mainly D2, can be used more efficiently.
The only skew in the data would then be the constant bias of ~150 Hz, which may have been introduced for presentation purposes. Anyhow, to extract the aircraft’s line of sight speed from this graph is impossible by any means, because that doppler component is already compensated for by the terminal, so in @richardc10′s line of thought we don’t even have a world atlas to sail the ocean, we just haven’t realized that yet.
sk999 said,
April 16, 2014 at 4:14 pm
There are two disjoint interpretations of the BFO.
Duncan Steel and Mike Exler assume that the BFO is the sum of the Doppler between the satellite and the aircraft plus the Doppler from the C-band downlink to Perth – essentially as if the aircraft transmitter did no compensation.
richardc10 and myself (and likely others) assume a more complex combination – the BFO is the difference between true Doppler of the aircraft/satellite and the Doppler one would compute if the satellite were exactly stationary over the equator, which we conjecture is the algorithm used by the AES SATCOM to pre-tune the transmitted frequency.
These models for the BFO cannot both be right. richardc10 has alreay pointed out some issues with the second one. Here I will highlight two problems with the first one.
First, no one knows how Inmarsat would have obtained the information in the first place. The measured frequency at the ground station does not measure the total Doppler of the aircraft/satellite alone (with or without a D3 contriubtion); rather, it measures the error in the frequency compensation (AFC) applied by the AES (along with all other errors along the chain). The AFC will bounce around just as much as the aircraft/satellite Doppler itself. From all documentation, the frequency offset applied by the AES is not transmitted to the GES. The AWST article says it is not. Further, looking through the Classic Aero documentation, I cannot find any description of where or how such information would be transmitted.
The second problem is that the BFO diagram does not depict the early phase of the flight properly at all. After takeoff, the aircraft has a large velocity away from the satellite; there should be a big jump in the BFO plot. There is a jump, but it is much too small. Consider Airlandseaman’s spreadsheet table, AES to SC/LOS velocity for UTC 19:07 – the time of the last ACARS transmission. The LOS velocity is listed as -30 knots (increasing separation) but the actual LOS velocity is closer to -155 knots.
BFO is not “D1+D2+D3″ – rather, it is “difference … between expected received frequency and that actually measured”. What is expected? If I give this definition its straightforward meaning, it would be that the satellite-Perth doppler is in both expected and measured and so would cancel out in the BFO.
While the Annex defines “Total Doppler” as D1+D2+D3, I think that it should more properly refer to Total Contributions to Frequency Change. The figure makes the most sense if one interprets D1 as the frequency compensation applied by the AES that is meant to counter D2 (the satellite/aircraft Doppler). I believe Skwosh came to this conclusion already in an earlier post.
sk999 said,
April 16, 2014 at 4:55 pm
Satellites 101
By way of background material. I thought it would be useful to explain why 3-F1 has a non-zero orbital inclination.
A geostationary satellite – one located at a fixed longitude over the equator, will not stay there without constant course correction. The principal perturbation acting on a geostationary satellite is a torque exerted by the moon and sun (and eventually the Earth) that cause it to precess. The precession causes the orbital inclination to oscillate between 0 and 14.4 degrees relative to the celestial equator with a period of 53 years. By my calculation, the initial rate at which the inclination should increase is about 0.85 degrees per year.
Orbital elements for a satellite are expressed in a form called a “TLE” (two-line element set) used by NORAD and NASA. The most recent TLE for 3-F1 can be obtained from celestrak.com. Here is a list of a few recent TLE’s, along with one from over a year ago. [Hopefully the forum formatting will keep them readable.]
INMARSAT 3-F1
1 23839U 96020A 12341.07205535 .00000023 00000-0 10000-3 0 5984
2 23839 0.6620 73.3284 0006319 183.7234 268.6593 01.00271888 61084
INMARSAT 3-F1
1 23839U 96020A 14083.86389615 -.00000011 00000-0 10000-3 0 2916
2 23839 1.6716 73.0934 0005461 286.8563 197.8158 1.00274430 65830
INMARSAT 3-F1
1 23839U 96020A 14091.92112660 -.00000013 00000-0 10000-3 0 3021
2 23839 1.6895 73.0749 0004948 297.2159 215.9781 1.00271331 65918
INMARSAT 3-F1
1 23839U 96020A 14099.06050456 -.00000004 00000-0 10000-3 0 3141
2 23839 1.7040 73.0010 0005094 298.0602 272.4340 1.00273066 65980
The format is well documented (just do a Google search). For our purposes the most relevant numbers are the date on line 1 and the inclination on line 2. For the most recent TLE, the date is 14099.06… which means 2014, day 99.06 since the beginning of the year. The most recent inclination is 1.7040. You can figure out the earlier TLEs quite easily.
The inclination has been increasing linearly since December 2012, from 0.66 degrees to 1.70 degrees a few days ago. The observed rate of increase is 0.78 degrees per year, about 8% less than the predicted rate. Possibly there has been some attempt to control the orbit over that time, but obviously not much.
There is more involved – the “right ascension of the ascending node” is listed just after the inclination on line 2, and it comes into play in a way that modifies the above discussion somewhat, but the main concepts still hold.
Interpolating, I would predict an inclination of 1.634 degrees on March 8.
Alex Siew said,
April 16, 2014 at 6:34 pm
A layman’s perspective on the BFO chart, for what it’s worth.
1. The first 4 transmissions are ACARS transmissions (via VHF or satellite?), the next 2 are unknown, the remaining 6 are complete handshakes/pings. Cannot compare apples to oranges? Different formulas may apply to different transmissions? Just a thought.
2. At 00.30am, plane was stationary at KL, satellite was moving northwards (ie closer to plane), reading is +87. The ping timings were said to be getting longer and the deduction made (by Inmarsat) was that the plane was moving away from satellite, yet these readings are all also positive. So it is possible, even likely the BFO values are merely absolute values (no sign given)?
3. @airlandseaman, I dont think Inmarsat ever said the plane was further away from the satellite at all transmission times? Chris McLaughlin merely said the ping timings were getting longer?
4. Chris did not say each of the pings was getting progressively longer. In any event, the BFO value for the 3.40 ping is lower than the 2.29am ping.
5. The BFO values for 2.29am and 4.40am are approximately the same (140). Coincidentally or not, the satellite vz at these 2 times is also more or less the same ( 48 or 49 knots).
6. The BFO chart shows a dip at around the 3.40 ping. Coincidentally or not, the satellite reached its northern apex at around the same time at 3.36am.
7. If we take the first ping at 2.29am as a positive reading and the rest of the pings as negative readings, it would mirror the movement of the satellite during that period.
XocoLatte said,
April 16, 2014 at 11:28 pm
Alex,
I read your points very carefully, and I think I comprehended some perception between your lines as well. Can you tell out loud what you tried to mean?
Weeks ago I came to this blog and discussion in awe for the high quality professionalism that tried to keep focus on available data and analysis of those data.
More than hairsplitting and sometimes painstaking attention to detail led to a complete refusal of the veracity (or punctuality at best) of conclusions based on published official data, not only satellite pings but military radar ones, as well.
(see for example Duncan Steel’s blog for details)
Since I am a layman in all fields that count in this analysis, let it be satellite communication, aviation or radar data, I can only offer my layman opinion on the proceedings. I think no matter how elaborately painstaking a hairsplitting strategy on professional analysis would be, the results of such analysis would be equally false when available data for said analysis were intentionally and calculatedly missing essential parts, or, again by premeditated design, distorted or falsified in order to fit an equally predesigned conclusion as outcome.
Satellite ping and military radar data available for the public DO NOT serve a solid and uncontroversial base for any scientifically sound interpretation, or may provide such basis for mutually contradicting results of said analysis. Any scientist would know by inherent instinct that such kind of data could not be valid and need to be thrown out and search for new data for a new analysis must be done.
By thinking along the interpreted between-the-lines narrative of Alex points, I would wonder whether any completely different aircraft flight route was possible that was corroborated by the 06:15 (MVT) sighting of a large airplane over one of the Maldives archipelagos, especially with the possible practical use of Boeing Remote Controlled Autopilot patent ?
XocoLatte said,
April 17, 2014 at 12:15 am
Just to make really simple and by refuting the black-and-white possibility of whether the plane went to the South or North: is it completely impossible that the plane went almost straight to the West than turned to the South but those data points were never made public?
Ole said,
April 17, 2014 at 2:58 am
@XocoLatte
my preliminary conclusion on what data points are reliable:
From leaked radar data we know MH370 was painted over western Malacca Strait around 18:20 UTC. This radar data seems to be corroborated by the 18:25 to 18:27 ping rings.
If I follow the BFO model of “imperfect compensation” as evolved by @skwosh, @richardc10, @sk999 and others, then I have to accept these facts:
- at 19:40 MH370 was heading mainly south with a speed >~270 knots.
- it kept heading south with at least that speed until 0:11.
Inmarsat and AAIB weren’t helpful at all in describing how the BFO is to be interpreted. With the “imperfect compensation” model inmarsat’s conclusions seem to be stringent.
From the JACC we have the arc of the last complete and the last partial ping (0:11,0:19 UTC). The data that was used to establish that MH370 didn’t end up in the roaring forties but much further north was never published. Nevertheless I don’t see a possibility for MH370 to not have turned south between 18:20 and 19:40. The 19:40 ping ring should give a better estimate of how far to the west MH370 could have gone before turning south.
ICAO Annex 13 Chapter 7.4 states: “7.4 The Preliminary Report shall be sent by facsimile, e-mail, or airmail within *thirty days* of the date of the accident unless the Accident/Incident Data Report has been sent by that
time.”
That means a preliminary accident report should have been issued by now including all the data that is not yet in the public domain. The problem here is, that according to Annex 13 the state where the accident occurs will lead the investigation (and thus issue the preliminary report). Until the Aussies haven’t found a trace of the plane, it is unclear where the accident occurred and who is in charge of this investigation.
Skwosh said,
April 17, 2014 at 4:40 am
Just been reviewing the numbers and signs of things. I’m in need of a quick sanity check. At the start, if the aircraft is stationary at Kuala Lumpur, the satellite is moving ever so slightly *closer* to the aircraft? … so the aircraft-sat range rate at the start should be negative – or is my geography/geometry duff (wouldn’t be the first time!)
richardc10 said,
April 17, 2014 at 4:48 am
@skwosh
No, at 16.30 the AES to satellite rangerate is +1.2m/s, so moving away. Satellite is moving North until 19.36.
richardc10 said,
April 17, 2014 at 5:02 am
Positive range rate is a negative BFO contribution
Skwosh said,
April 17, 2014 at 5:15 am
I agree about the numbers we have – I was just thinking about the actual geometry (probably wrongly) isn’t Kuala Lumpur further north than the extent of the satellite’s north/south variation – so – if the satellite is moving north and the aircraft is ‘north’ of the satellite then wouldn’t the range be closing?
Alex Siew said,
April 17, 2014 at 5:20 am
@XocoLatte,
I had articulated the theory that the plane had crashed early on in the South China Sea in my previous comments including the very first comment posted in this blog. Since the blog now contains over 600 comments, instead of asking u to refer to my previous comments i will sum it up for u in this comment.
The plane disappeared from civilian radars at around 1.21am off IGARI over the South China Sea. No one has come forward to say they heard a Mayday call from MH370. What happened at 1.21am to cause it to fall off the radars and why did the pilots not make a distress call?
If u ask PILOTS this question, most of them will have a lightning strike as one of the possible causes. Unlike other possible causes like mechanical failures, decompression, etc, a lightning strike can explain 2 critical facts, the transponder not transmitting radar signals anymore after 1.21am and the lack of a distress call on the radio.
The transponder’s non transmission can be due to 2 possible causes, someone switched it off or it suffered a breakdown. It has been more than a month now since the plane disappeared and there is no evidence to suggest there was someone on board who was not a bona fide passenger or crew member.
We are told aircraft are designed to withstand lightning strikes. That is only true to a certain extent. Aircraft are designed to withstand lightning strikes up to 200,000 amperes. The typical lightning strike, called negative lightning, usually would not exceed 20,000 amperes. However, there is a another form of lightning called positive lightning which can be up to 300, 000 amperes in power. If a plane is hit by a lightning strike exceeding 200,000 amperes, its lightning defenses can be breached, resulting in massive electrical failure.
Such a powerful lightning strike would also have another effect, it would cause magnetization of radio equipment.
Was MH370, a fly by wire plane, hit by positive lightning causing electrical failure resulting in the transponder not working anymore and causing the radio equipment on board to be magnetized resulting in the pilots’ inability to radio a Mayday call?
There is evidence to support such a scenario.
Someone who appeared to be a pilot posted on PPRUNE on March 8, 2014 (post#120, page6) that he was flying westbound to southern vietnam passing MOXON at 1.20am and that it was a clear night but that “THERE WAS SOME LIMITED SCATTERED LIGHTNING VISIBLE WAY OFF TO THE SW”. Way off to the south west would be the area where MH370 was flying through. This person also mentioned that the emergency frequency was congested that night with both Vietnamese ATC and another MH plane trying to contact MH370 on the radio.
According to the March 9, 2014 edition of the Guardian, another pilot who flew within 100 nautical miles of MH370″s route 12 hours earlier had reported large thunderstorms in that region.
Weather maps show light scattered clouds where MH370 was flying through. At 1.21am MH370 was at a cruising altitude of 35,000 ft.
A lightning strike at such altitude,in clear or slightly cloudy skies, points to positive lightning. The following is from Wikipedia:
“Unlike the far more common negative lightning, positive lightning originates from the positively charged top of the clouds…rather than the lower portion of the storm…A positive lightning bolt can strike….often in areas experiencing clear or slightly cloudy skies; they are known as ‘bolts from the blue’ for this reason. Positive lightning typically makes up less than 5% of all lightning strikes…..Positive lightning…. can develop 6 to 10 times the amount of charge and voltage of a negative bolt and the discharge current may last 10 times longer. A bolt of positive lightning may carry an electric current of 300,000A and the potential at the top of the cloud may exceed 1,000,000,000 volts- about 10 times that of negative lightning. During a positive lightning strike, huge amounts of extremely low frequency and very low frequency radio waves are generated. As a result of their greater power, as well as lack of warning, positive strikes are considerably more dangerous. At the present time, aircraft are not designed to withstand such strikes, since their existence was unknown at the time standards were set and the dangers unappreciated until the destruction of a glider in 1999….Positive lightning tends to occur more frequently…..in the dissipation stage of a thunderstorm……”
In addition to the reports of lightning and earlier thunderstorms, there is further evidence of a lightning strike.
The pilot of the other MH plane flying 30 minutes ahead of MH370 bound for Narita and requested by Vietnamese ATC to contact MH370, reported that he finally got through to MH370 using emergency radio frequency at about 1.30am. He said he heard a lot of static, interference and “mumbling” from who he thought was the co-pilot. [New Straits Times, March 9, 2014]. 1.30am was 9 minutes after the plane went off radar screens.
The static, interference and the difficulty in establishing radio contact are all consistent with the radio equipment of MH370 having been magnetized by a lightning strike.
The mumbling from the co-pilot was either a distortion of his words due to the magnetized radio equipment or it could have been the co-pilot was actually mumbling due to having suffered an electric shock from the lightning strike. In the 1999 glider incident, the pilot briefly lost consciousness from the lightning strike.
Finally, a Kiwi working on an oil rig off the southern coast of Vietnam reported seeing an object burning in high altitude that night. He said the object appeared to be in one piece and the “flames” lasted 10 to 15 seconds.
What the Kiwi saw could well have been MH370 experiencing “St Elmo’s fire”, a lightning related electrical phenomenon whereby an electrical charged object or plane would appear to be in flames or glow. The black box of Air France Flight 447 recorded the pilots saying there was St Elmo’s fire in their cockpit, 23 minutes before the plane crashed into the Atlantic Ocean.
Going to grab a late dinner. Will come back to explain how an early crash can be reconciled with the pings from the Satcom terminal on board, i believe the terminal (located above the overhead luggage compartment at the rear of the plane) survived the crash and transmitted the pings using battery power, as wreckage floating in the sea until it finally submerged or the battery ran out at around 8.19am
Ole said,
April 17, 2014 at 6:26 am
@skwosh
It’s counter-intuitive, but the sat was actually moving away from KUL at 16:30. My vector math gives a range rate of 0.0010355 m/s which is the same as Duncan posted April 3, 2014 at 10:11 am.
Maybe it’s best visualized by imagining two spheres. One with 36000 km radius centered around KUL (distance KUL sat) and another one with 42000 km radius centered around the center of earth (sat’s motion tangential to this one). Because the 42000 km sphere has a smaller curvature than the 36000 km sphere tangential vectors on the larger sphere will point away from the smaller sphere (I may be mistaken).
richardc10 said,
April 17, 2014 at 6:42 am
@skwosh
> – if the satellite is moving north and the aircraft is ‘north’ of the >satellite then wouldn’t the range be closing?
It took me a while to work it out! The satellite is in a slightly eccentric orbit, with perigee point aligned close to the southernmost point it reaches. So when it is going north, it is going up in altitude and when it is going south it is going down (the difference is 44km). The rate of change is ~1m/s so is significant when the AES is close to the equator and the rangerates due to its north/south movement are small (~0.5m/s). If the orbit was circular what you said would be correct.
Skwosh said,
April 17, 2014 at 7:53 am
@richardc10 Excellent – That’s a great relief. So it’s the up/down – of course – I have been thinking – wrongly – that the up/down is always going to be more or less negligible for our purposes – which I guess is true broadly speaking (and in this case the shifts are very small anyway) – but I foolishly haven’t really ever appraised myself of the rough magnitude of the altitude changes. At least I wasn’t being *totally* stupid. Thank you for sorting me out!
Alex Siew said,
April 17, 2014 at 8:33 am
@XocoLatte,
Before moving on to the pings, i should mention one last thing related to the lightning theory.
This particular plane had suffered a broken off wingtip in August, 2012 when the wingtip collided with another plane on the ground while taxiing at Shanghai Airport. The plane was reportedly repaired and cleared to fly.
A plane’s defence to lightning is premised on the Faraday’s Cage theory whereby the electrical charge from a lightning strike is dissipated quickly through the outer skin of the plane to various exit points on the plane, before it has a chance to penetrate into the plane’s electrical circuits. The wingtips are reportedly common exit points.
A 777 uses composite materials rather than aluminium as its basic structure. As composite materials are less conductive, a mesh is inserted below the skin of the plane to help conduct the electricity charge from a lightning strike. Any gap in the skin or mesh can potentially compromise a plane’s ability to dissipate the charge quickly. Such a gap can also cause static build up and there is a theory that static buildup on a plane can potentially induce lightning.
We have to assume that the wingtip was properly repaired and the plane was “as good as new” unless there is evidence to the contrary. To do otherwise would be to indulge in speculation.
On the matter of the pings. 2 things come to mind immediately. The pings were said to be faint. Secondly, handshakes/pings are supposed to happen at regular hourly intervals but some of the pings from MH370 were not transmitted in regular hourly intervals. What could be the cause?
If the plane had been flying on until after 8am at cruising altitude and speed as Inmarsat want us to believe, the pings would have been at regular signal strength and at regular hourly intervals.
The satcom terminal having survived an early crash and transmitting on battery power as wreckage floating in the sea and being swept around by waves, can account for the faint signal power and the irregular times of transmission.
The satcom terminal on a 777 consists of various components the most important of which is the Satellite Data Unit (SDU). According to manuals available on the net, these components are located at rack E11, above the overhead luggage compartment, towards the rear of the plane. It is unclear where the satellite antenna was located on MH370, it was either on top of the part of the fuselage above rack E11 or at the tail of the plane.
According to the manuals available online, the SDU for a 777 has an internal battery. This battery’s main purposes would appear to be to power memory and the clock but it could also presumably act as a residual source of power in the event of loss of primary power.
In addition, a 777 has backup battery power for its electrical circuits. The main battery is in front while the APU battery is at rack E10, which would mean it is next to the satcom terminal. @GuardedDon is of the view that these 2 batteries would not be available to power the SDU in the event of an emergency as satcom is considered to be not essential equipment then.
Even if that is the case, that still leaves the internal battery of the SDU. I have posed the question on this blog whether this battery could conceivably have been the source that powered the faint pings. No one has replied yet.
Note that it was not the satellite terminal initiating these pings. The satellite was pinging the satcom terminal, all the terminal did was to transmit a signal back to say yes I am here. Just like a cell tower pinging a handphone.
According to reports, there were altogether 13 transmissions from MH370. The first 4 were ACARS transmissions by VHF or satellite the last of which was at 1.07am, there were 2 transmissions at 2.25 and 2.27 the nature of which is unknown, 6 complete handshakes/pings at 2.29, 3.40, 4.40, 5.40, 6.40 and 8.11am, and a final transmission at 8.19am said to have been initiated from the plane.
The transmissions at 2.25 and 2.27 were likely post crash unsuccessful attempts at establishing a handshake, before the successful handshake at 2.29am. The last transmission at 8.19am was likely induced by the battery running out or the terminal submerging into the sea.
In the Ethiopian Air Flight 961, a 767 crashed into the Indian Ocean albeit close to a beach. The plane broke up upon impact but the the tail and rear fuselage did not sink but remained above water in an upright position. If the same had happened to MH370, the satcom terminal could have survived and be in a position to respond to the satellite’s pings using its battery power.
What about the purported turn to the west? Surely that is inconsistent with a crash early on into the South China Sea?
There is no evidence to show the plane had turned west. All we have is an after the fact primary radar recording showing an unidentified blip at 2.15am at VAMPI or 2.22am at MEKAR, 200nm off the upper west coast of Malaysia. There was no live radar tracking or after the fact recorded radar, primary or secondary, showing any blip traveling from IGARI crossing over Malaysia to VAMPI/MEKAR. This unidentified blip at VAMPI/MEKAR was tracked flying following navigational waypoints to the Andaman Sea, a common route to the Middle East, and was most likely a commercial airliner, UAE343. That this blip had originated from IGARI and had crossed Malaysia is pure conjecture. @GuardedDon has come to the same conclusion.
What about the BFO chart? Surely it shows the plane still flying?
Not necessarily so. As i have postulated in previous comments, the BFO values for the 6 complete handshake are fully consistent with the movement of the satellite moving closer to the crashed plane before 3.36am and moving away thereafter after reaching its northern apex at 3.36am. As i have pointed out previously, the BFO chart shows a dip at around 3.36am, and the BFO values for 2.29 and 4.40am are around the same (140Hz) when the satellite velocity for these 2 points in time are also around the same 48 to 49 knots. Finally, if one takes the reading at 2.29am as positive (moving closer) and the other 5 as negative (moving away ), the chart for the 6 complete handshakes is a mirror of the movement of the satellite for that period. Could it all be coincidence?
Lastly, what about the arcs for the earlier 5 complete pings/handshakes?
If the plane had crashed early on , those arcs would more or less be the same as the arc from the final ping. This final arc crosses the South China Sea but this portion of the arc has been excluded from the ongoing search presumably on the argument that the plane could not have flown for 7 hours and yet landed there, so close to the point where the plane went missing, off IGARI.
But where are these 5 arcs? Inmarsat has refused to release them or the raw data on the RT timings despite the clamour from the scientific community. In a court of law, if a witness refuses to disclose evidence in his or her possession, the presumption of adverse inference will be invoked against the person that the evidence would not be in his or her favour.
We are only asking for the raw data on the RT timings. There is nothing proprietary in the data, they just have to say how many seconds each ping took and people like Duncan or @airlandseaman will be more than able to calculate the arcs from there. The data can only help and cannot hinder the search for the plane.
The fact of the matter is that it would be in the interest of Boeing, Rolls Royce, the Malaysian authorities and Malaysia Airlines, from the perspective pf legal liability, if the plane is never found. Likewise, Inmarsat will also have the grounds to push for compulsory usage of their more advanced and expensive satellite services. Thus the fact that they all concurred that by some unexplained human intervention the plane crossed back over malaysia, flew west somewhere to the Andaman Sea following navigational waypoints, then turned south in a straight or magnetic line and flew on at cruising speed and altitude for several hours the last few of which in broad daylight, to ultimately descend into the Indian Ocean in the middle of nowhere, undetected by radar or satellites or the hydroacoustic, seismic or infrasound stations of the global nuclear organization some of which are located at Perth, is not suprising come to think of it.
The search at the South China Sea before it was abandoned, was amateurish. If i remember correctly, i had addressed a comment to u much earlier, regarding the ‘follow up’ reported by Aviation Herald on the sighting by a Cathay Pacific crew of debris and a streak of what appeared to be jet fuel off the coast of Vietnam on March 10, 2014. The crew photographed the debris and took down the coordinates. The Vietnamese authorities asked a Thai commercial ship to go take a look! The report from this ship was negative. I would not be suprised if the ship did not even go to the site. A second commercial ship was then asked to check it out and this ship reported seeing some debris. Only then the authorities sent a coast guard vessel to look for the debris. This vessel couldnt find anything but reported large waves and strong winds the suggestion being that the debris could have drifted away.
By all means, search the Indian Ocean. But should the search at the South China Sea be abandoned so quickly? The arc from the final ping crosses the South China Sea after all.
A good starting point for a search at the South China Sea would be the intersection of the plane’s last known flightpath (IGARI 40 degree) and the final arc.
Skwosh said,
April 17, 2014 at 8:40 am
@Ole sorry – I missed your earlier post – you’ve got me straining my brain and drawing circles on bits of paper now!
AndRand said,
April 17, 2014 at 10:54 am
airlandseaman said,
April 16, 2014 at 1:48 pm
Inmarsat is just trying to look like they have invented something new for the PR and potential commercial value. The engineers that realized that this old trick could be used in a new application certainly deserve full credit and more for their quick thinking, but the techniques have been well proven over decades. It is solid, proven technology.
Exactly… not exactly – the bounce is one thing, system response is another. Inmarsat states it is deterministically stable and so is to be the uplink AES frequency. But I am doubtful on that.
Skwosh said,
April 17, 2014 at 10:59 am
@Ole – just starting to get my head around your maritime idea(s) – and generally a good idea to try to understand how things might work in an ‘evolutionary’ way – fixes/extensions/enhancements added on top of previous layers etc.
Alex Siew said,
April 18, 2014 at 12:58 am
@Richard c10, @Ole, @Skwosh,
Sorry, this layman cannot understand the part about the satellite moving away from KL at 00.30am.
KL is roughly 3.13N 101.68E. At 00.30am the satellite was at 1.129N 64.551E, x=18120, y=38078, z=830, vx=0.001912, vy=-0.001008, vz=0.063780 (around 124knots).
Thus vertical velocity was significant compared to vx and vy. At 00.30am the satellite was moving essentially northwards at 124 knots. I would have thought that it would mean the satellite was moving closer to KL at that point in time?
richardc10 said,
April 18, 2014 at 3:25 am
@ Alex Siew
>Sorry, this layman cannot understand the part about the satellite >moving away from KL at 00.30am.
If I understand your frame of reference, it is origin at the centre of the Earth, X axis towards (0N,0E), Y axis towards (0N, 90E), Z towards the North Pole. I can’t compute the velocities in that frame here, so I can’t tell if you have used the full orbital elements including eccentricity, but I assume you have. The problem with using that frame is that doesn’t easily give velocities with respect to Kuala Lumpur – all three of vx, vy and yz have components towards that location. You would need to rotate the frame in two angles so that the X axis is through KL. In that case vy and vz would have no component towards KL, and vx would give the rangerate. I have just done that (with your data) and got xkl=0.0021, ykl=-0.0016, zkl=0.0637, so a positive range rate of 2.1m/s, a bit higher than I had.
The shorter answer is that for the observer standing at KL, the satellite’s velocity North has a very small component towards the observer, but the satellite is increasing in altitude with respect to the Earth as it moves North which has a more significant (but still small) positive component away from the observer.
Ole said,
April 18, 2014 at 3:28 am
@Alex
my previous take with the sphere’s probably was bogus, the sat can not be moving away from KUL all the time.
Duncan Steel has a good picture of the motion of the sub-satellite point on his website:
http://www.duncansteel.com/wp-content/uploads/2014/03/E6-small.bmp
You can see, at 16:30 the sat’s motion had a slight westward component. Together with the vertical movement that might (has to) be sufficient to explain that the sat was moving away from KUL.
I have to admit, my 3d imagination is failing here, but the math is unambiguous.
richardc10 said,
April 18, 2014 at 3:29 am
sorry, symbols wrong, that should have been
vxkl=0.0021, vykl=-0.0016, vzkl=0.0637, all km/s.
vxkl, vykl, vzkl components of velocity in the frame where the xkl axis is from the centre of the Earth through location of Kuala Lumpur.
Skwosh said,
April 18, 2014 at 3:39 am
@Alex – I know what you mean! However, I think the key to this is to do with the satellite being a long way above the earth (the Wikipedia entry for Geostationary orbit has a picture that is to scale for this: http://en.wikipedia.org/wiki/Geostationary_orbit ).
As I understand it, at the time, the satellite was moving North at around 60m/s, but it was also moving ‘up’ at ~ 1m/s (along the direction outwards from the centre of the earth, so getting further away from the centre of the earth at 1m/s).
So, in this case, it is moving 60m north every second, and that does indeed shorten the distance between it and KL, but it is also moving ‘up’ 1m every second, and that lengthens the distance between it and KL. The question here is which makes the largest difference:
If the satellite was flying at a little above sea level with those velocities (thought experiment only!) then the 60m northward move would be by far the most significant contribution to the change in its distance to KL – so it would indeed be getting closer to KL. But if the satellite is flying very high (as it is) then the contribution of that 60m northward move to the change in the satellite’s total distance to KL (or indeed to any point on the earth) is going to be a lot less than if it were flying at sea level – whereas the contribution of its 1m increase in distance from the centre of the earth is going to be, more or less, the order of 1m… and so in this case the contribution of the ‘up’ motion wins over the diminished 60m north motion.
Skwosh said,
April 18, 2014 at 3:41 am
@sk999 Just to expand a bit on your earlier discussion of the models – as I commented previously, I think @airlandseaman’s model makes the implicit assumption that the BFO graph is ‘upside down’ – in other words – that the physical BFO values are negative rather than positive (this is entirely reasonable if, in his view, the BFO physically represents something that should always be a total negative Doppler shift). Looked at this way his interpretation *does* provide a completely natural explanation for the value of the first BFO value, and I think this has been a core part of his reasoning in advocating this approach/interpretation all along. He can add another term (as I think he is proposing to do) to introduce a north/south asymmetry and this extra term could, I guess, also change the implied LOS velocities during take-off and elsewhere. However, as you say, I think that if he believes that substantial aircraft-satellite Doppler correction *is* actually happening, then he must surely also accept that the BFO – in his interpretation – can’t be a true *measurement* and must instead have been ‘synthesised’ by Inmarsat for presentation/explanation purposes – and that in order for them to have done this they would have surely have had to have some information about what the actual corrections were – which, to be fair on him, he has always said he thinks they must have.
LGHamiltonUSA said,
April 18, 2014 at 3:52 am
Alex Siew’s “MH370 Lightning Strike Theory”
Part One: http://tmfassociates.com/blog/2014/03/24/understanding-the-satellite-ping-conclusion/#comment-25051
Part Two: http://tmfassociates.com/blog/2014/03/24/understanding-the-satellite-ping-conclusion/#comment-25171
Hi Alex,
I am intrigued by your theory. For continuity purposes I wanted to present your two previous comments as a preface to the three links I am providing to you below. They all relate to eyewitness accounts of residents from the eastern Malaysian coastline on the South China Sea, such reports seeming to support your theory. I hope these will help you:
“The Terengganu police today confirmed having received a report on a loud explosion heard by local villagers in Marang last Saturday morning, the day the Beijing-bound Malaysia Airlines (MAS) MH370 went missing.”
“One of them…said he and seven fellow villagers were seated on a bench about 400 metres from the Marang beach at 1.20 am when they heard the noise, which sounded like the fan of a jet engine. “The loud and frightening noise came from the north-east of Pulau Kapas and we ran in that direction to find out the cause.”
“He said according to the reports lodged on Sunday, the aircraft was sighted at Kuala Besar, Pantai Cahaya Bulan (both in Kota Baru), Geting (Tumpat) and Pantai Senok (Bachok).”
~LGH~
Alex Siew said,
April 18, 2014 at 6:28 am
@Richardc10, @Ole, @Swosh,
Thank you for the replies. If i understand what u guys are saying, the movement of the satellite upwards in terms of altitude (or in combination with any westwards movement) exceeded the movement of the satellite northwards, thus the satellite was moving away from the plane at 00.30am when it was stationary at KL.
However, the figures given by Duncan in his various posts on his website dont seem to support this theory. From 00.41am to 8.11am, the distance of the satellite to mean sea level only ranged from 35,801.4 to 35,793km, just 8 km in difference. By comparison, the figures for z for 00.30am, 00.43am and 1.07am as an example were 830, 878 and 960km respectively. vx and vy were at all times negligible relative to vz. In other words, the satellite’s altitude was more or less constant, the movement westwards was negligible, with the satellite moving primarily northwards (at speed of 124 knots at 00.30am).
richardc10 said,
April 18, 2014 at 6:41 am
@Alex Siew
>However, the figures given by Duncan in his various posts on his website
>dont seem to support this theory.
>
see Duncan Steel’s post above from April 3, 2014 at 10:11 am. The numbers there (from STK I presume) confirm a positive range rate to KL at 16.30UT. This is basic orbital mechanics and these numbers (however calculated) are rock-solid.
Alex Siew said,
April 18, 2014 at 6:52 am
@richardc10,
Sorry, i should have been more precise. All the numbers quoted other than the distances to MSL are from Duncan’s post on his website on March 26. These are raw data regarding the positions and velocities of the satellite at various times.
The figures for the distances to MSL are from Duncan’s post on his website on March 24. Again raw data.
I do not know how Duncan derived the numbers in his April 3rd post.
Alex Siew said,
April 18, 2014 at 7:20 am
@richardc10,
Ok, i have read Skwosh’s comment again, think i understand what u are saying.
Skwosh said,
April 18, 2014 at 7:38 am
@Alex you are correct when you say that the northerly speed of the satellite exceeds the upward speed by a large factor – and I do not think anyone is disputing this – however – the contribution the northerly speed makes to the total distance between the satellite and KL on the ground is, in this case, not very large because of the geometry involved (the distance that matters is not the distance from the position of the satellite as projected onto the surface of the earth – it is the actual distance from KL up into space to the position of the satellite).
richardc10 said,
April 18, 2014 at 7:55 am
@Alex Siew
First a mea culpa, I finished my previous calculation too soon. Correcting it…
‘If I understand your frame of reference, it is origin at the centre of the Earth, X axis towards (0N,0E), Y axis towards (0N, 90E), Z towards the North Pole. I can’t compute the velocities in that frame here, so I can’t tell if you have used the full orbital elements including eccentricity, but I assume you have. The problem with using that frame is that doesn’t easily give velocities with respect to Kuala Lumpur – all three of vx, vy and yz have components towards that location. You would need to rotate the frame in two angles so that the X axis is through KL. I have just done that (with your data) and got vxkl=0.0021, vykl=-0.0016, vzkl=0.0637, so the satellite altitude in the KL frame is increasing at 2m/s. The three components are then convoluted with the satellite position in that KL frame (x,y,z = 33616.39, -25453.52, -1007.01) to give the range rate, +0.00092km/s, quite close to the STK figure of 0.001035.’
In general the vx, vy, yz in the source you quote have to be convoluted with the positions of the satellite and the point to which the final rangerate is required, in whatever frame they are measured, to get the final answer.
Alex Siew said,
April 18, 2014 at 8:22 am
@richardc10, @Skwosh
Think i got it ( i think!), thanks.
@LGHamiltonUSA,
Thank you for your comment. I do not know really know what to make of those reports u referred to. Those villagers would probably be too far away to have seen or heard anything relating to MH370.
Skwosh said,
April 18, 2014 at 11:05 am
Sorry, another long post (we should stop soon or we’ll explode Tim’s blog?) This is an attempt to incorporate a number of the ideas/strands we’ve encountered so far – though I’m close to giving up now I think:
[1] ‘Perfect’ correction:
Say I plan to use ‘prefect’ Doppler correction by measuring the Doppler shift on a signal of known incoming frequency and then re-transmitting with the opposite shift. On the face of it this is a good idea:
So, say there is a transmission from the satellite to the aircraft that arrives at the aircraft at frequency F_Incoming, and I know it was transmitted by the satellite at F_Base. I can trivially deduce that the Doppler contribution was:
F_Doppler_Actual = F_Incoming – F_Base
Assuming for now that I am transmitting on the same frequency as I am receiving, I would then reverse this Doppler shift to compensate my transmissions back to the satellite:
F_Transmit = F_Base – F_Doppler_Actual
This is what we’ve been referring to as ‘perfect’ Doppler correction.
[2] Perfect correction with duff local oscillator:
Consider the above perfect correction scheme when there is an unknown error of F_Error added to the aircraft’s local frequency reference:
I will *incorrectly* measure the Doppler shift as follows:
F_Doppler_Measured = F_Incoming – (F_Base + F_Error)
= F_DopplerActual – F_Error
And, because my transmit frequency will also be out by F_Error I will transmit at the following frequency:
F_Transmit = (F_Base + F_Error) – F_Doppler_Measured
= F_Base – F_Doppler_Actual + 2*F_Error
This will still ‘compensate’ for any Doppler between the satellite and the aircraft, but it will introduce a fixed offset of 2*F_Error from the correct base frequency. However, I guess this is still a reasonable strategy if we can keep F_Error under control.
[3] Correcting the correction:
What if there was a way to determine F_Doppler_Actual that was *independent* of the local frequency reference? Let’s say we have some independent method of calculating what the Doppler shift between the aircraft and the satellite *should* be. I will call such a method F_Doppler_Calculated.
Given the definition of F_Doppler_Measured in the above section [2] we can then come up with an estimate of the error of our local frequency reference:
F_Error_Estimated = F_Doppler_Calculated – F_Doppler_Measured
We already know (from section [2] above) that the error in our local frequency reference is adding a term of 2*F_Error to the frequency that will be received at the satellite, so we can use the estimate of the error in our frequency reference to add a further correcting offset to our transmission frequency:
F_Transmit_Corrected = F_Transmit – 2*F_Error_Estimated
= (F_Base + F_Error) – F_Doppler_Measured – 2*F_Error_Estimated
= (F_Base + F_Error) + F_Doppler_Measured – 2*F_DopplerCalculated
= F_Base + F_Error + (F_Doppler_Actual – F_Error) – 2*F_DopplerCalculated
= F_Base + F_Doppler_Actual – 2*F_DopplerCalculated
Note that this quantity is now *independent* of F_Error (the actual unknown error in the local frequency reference).
When this corrected transmitted frequency is received at the satellite it will have incurred a Doppler shift of F_Doppler_Actual, so the frequency at the satellite will be:
F_Received_At_Satellite = F_Transmit_Corrected + F_Doppler_Actual
= F_Base + 2*(F_Doppler_Actual – F_DopplerCalculated)
So, *if* the calculated Doppler correction is completely accurate then this will give truly perfect Doppler correction *independent* of any drift in the local frequency reference:
F_DopplerCalculated = F_Doppler_Actual
=> F_Received_At_Satellite = F_Base
However, in general, the error in the correction will be:
2*(F_Doppler_Actual – F_DopplerCalculated)
I propose that this quantity could correspond to the text “not corrected by system” in the Inmarsat diagram.
Note that the above is a slightly different strategy to what we have been thinking of up to now. If we simply used F_DopplerCalculated alone to set the Doppler compensation on a transmission then the result would still be vulnerable to inaccuracy in the aircraft’s local frequency reference, whereas the ‘mixed’ method above does not have this problem. This method nails down the base frequency independent of any local oscillator drift, but it does this at the price of the maximum possible offset being *twice* the largest difference between the calculated and the actual Doppler shifts.
The above is actually a very long-winded way of getting to this (no kidding!) but I’ve done it this way in an attempt to make it an ‘incremental’ explanation, though this may not have been a good idea. Also, my usual Dyslexic health warning has to apply; I have checked this quite carefully – but once I post it and read it through for the tenth time I’ll probably find some errors like I always do!
—-
tl;dr Summary:
In this model – I propose that:
BFO = 2*(F_Doppler_Actual – F_DopplerCalculated) + FixedOffset
This model deals exclusively with the aircraft to satellite part of the system.
If F_Doppler_Calculated is determined by the method based on the assumption of a fixed satellite that we’ve been considering up to now then the above model looks like *twice* the value of ‘D1 + D2′ in Richard’s ‘state of play’ plot (but with a different fixed offset) – no other components involved.
Part of the reason I am proposing this is because I think that it may then be possible to get a rough fit to the Inmarsat graph *without* having any ‘D3′ component in there at all (and thus to say that D3 is, perhaps as expected, one of the things that *is* corrected by the system and is thus not measured, and thus not in the BFO at all).
However, by eye I can see that the fit probably isn’t going to be that fantastic given the particular track Richard has used in his ‘state of play’ summary, but I’m not sure how much wiggle room we have on the speculative tracks or the L-band frequency (and I’ve also not explored the consequences of the receive and transmit frequencies being different, but I imagine that’s going to be fairly insignificant given that the ratio of these frequencies is going to be pretty close to one).
I would like to think that this approach *does* have the following virtues however (though obviously if it doesn’t fit very well then its other virtues don’t really help that much!):
[*] No D3 component required at all.
[*] Incorporates the idea of using ‘perfect’ Doppler correction by measuring incoming frequencies.
[*] *Also* incorporates the idea of using independent aircraft position and velocity information for Doppler correction/calibration along with the approximation of a fixed satellite position calculation.
[*] Incorporates the idea of uncertainty in the accuracy and/or potential drift of the aircraft oscillator along with a strategy to deal with this.
[*] Incorporates ideas about an ‘evolutionary’ approach to how the technology may have developed over the years.
GuardedDon said,
April 18, 2014 at 3:03 pm
response to Alex Siew said, at April 17, 2014 at 5:20 am & 8:33 am
First, the lightning & aircraft protection idea:
You state that ’777 uses composite materials rather than aluminium as its basic structure’. That is incorrect, composite structures do not figure large in the B777 structure, it uses predominantly aluminium alloys and the wings, including the skins, are largely aluminium. From Boeing’s published information: ‘an improved aluminum alloy is used in the upper wing skin and stringers. Known as 7055, this alloy offers greater compression strength than previous alloys, enabling designers to save weight and also improve corrosion and fatigue resistance. Progress in the development and fabrication of weight-saving advanced composite materials is evident in the 777. Carbon fibers embedded in recently available toughened resins are found in the vertical and horizontal tails. The floor beams of the passenger cabin also are made of these advanced composite materials. Other composite applications include those on secondary structures such as aerodynamic fairings.’
So there was no conductive mesh to be compromised during repair from the previous taxiing incident.
As to a lightning event impacting the aircraft: that is a possibility but aircraft are designed to cope with lightning by providing a ‘safe’ external conduit to the energy, however, I don’t know the impact of exceeding the tested environment. I do know that crews will avoid thunderstorms ‘like a plague’ and the aircraft weather radar will indicate where storm cells lie ahead.
Second, the satcom installation: I’ve attempted to provide enough information for you to make a decision about the satcom capability. Another commenter posted information about a Rockwell-Collins satcom unit: IIRC, the power supply requirement was stated as 28V @ 6.4A (or 180W) – redundancy would require a substantial battery (consider a typical 12V automobile battery has 40Ah capacity, i.e. it could supply a 12V-6A load for approx 6 hrs). I’ll reiterate: satcom is not essential flight equipment, the aircraft has redundant power generation, battery capacity is only provisioned for essential flight systems and APU air start. A button cell battery, maintaining data tables in NVRAM or a system clock, has no other function.
Satcom survivability: a) it’s not designed for survivability – it comprises at least 3 discrete units; b) water and electrical systems don’t play well together; c) fuselage section 46 would have to remain intact & buoyant; c) Ethiopia 961 crashed near shore among reefs, the empennage (only, no part of the fuselage pressure hull) & an engine were sitting proud of the water on reefs – not floating.
Third, continued flight: Mike Exner derived aircraft radial speeds, from the sub-satellite point, which were non-zero at the time of each comms event.
While lightning is a possible initial event, the consequent circumstances you suggest aren’t likely. If a lightning strike catastrophically disrupted the FBW systems then what outcome could be expected from a descent to sea-level from FL350?
Alex Siew said,
April 18, 2014 at 10:10 pm
@GuardedDon,
I am not saying that lightning was definitively the cause of MH370′s disappearance, but was pointing out the evidence supporting such a theory. The main point i am trying to make is that they should not have stopped searching at the South China Sea given that the arc from the final ping crosses there and the plane disappeared there and given Inmarsat’s refusal to release the data on the earlier 5 pings and before any investigation as to whether the pings could have been transmitted by battery power. Why put all eggs in one basket, why not have a few ships search the South China Sea, which is relatively shallow, at the same time?
1. Battery
I do not have access to ARINC 741 the specifications for the SDUs. These specifications will presumably show the details and functions of the internal battery. Perhaps others on this blog with access to these specifications can advise. Whether the pings could have been transmitted by battery power is something the investigation team has to investigate and rule out, before summarily concluding that the plane was flying on until after 8am. If Honeywell and Boeing or the investigation team come out to say there is no possibility that the pings could have transmitted using battery power and showing why that is so, that’s the end of the matter.
2. Weather radar on board
From an article on the Boeing website: ” Lightning strikes to airplanes may occur without indication to the flight crew “. The literature on the net indicates that a commercial airplane, on average, is hit by lightning once a year.
3. Aluminium vs composites
U are correct that aluminium is the main material used for a 777. According to information provided by Boeing, a 777 is 12% composites 50% aluminium as compared with the 787 which is 50% composites 20% aluminium. My mistake.
The AAIB published an accident report on the 1999 glider incident. The investigators found, among other things, a rod made from aluminium alloy from the plane had been ‘crushed’ as a result of the intense magnetic field generated by the lightning strike. Lab tests in UK, USA and Germany failed to reproduce such damage despite subjecting a similar rod to currents of up to 312,000 amperes. Following are extracts from the report:
” …CFRP is an electrically conductive material but is more resistive than aluminium alloy. Modern jet transport aircraft types are designed with increasing utilisation of such composite materials for structural and control surface elements. One example of this trend is the Boeing 777 which uses CFRP for the horizontal and vertical stabiliser torque boxes and graphite epoxy for the elevators, rudder, ailerons and flaps…”
“…Recommendation No 99-49: It is recommended the CAA should request serious consideration, during its participation in the current review of aircraft lightning certification standards, of the fact that energy levels from positive polarity discharges have been shown to greatly exceed those specified in Advisory Circular AC 20-53A, with the associated implications for the certificated lightning protection assurance of existing and future aircraft designs, particularly those which utilise significant amounts of composite material in their primary and control structures…”
If indeed MH370′s lightning defences were breached by a positive lightning strike , we would not know whether electrical failure was instantaneous or gradual, complete or partial or whether the air turbine deployed unless the black boxes are recovered. We know the plane was still up in the air at 1.30am. Even if electrical failure was instantaneous and total and the turbine did not deploy, the pilots could have still glided the plane down for a sea landing. The South China Sea at night is not the Hudson River during the day so it would be very unlikely that the pilots could have landed the plane without significant damage to the plane. The faint and irregular pings would suggest however, in my view, that the upper rear fuselage remained above water and the SDU retained some functioning ability, for several hours after the crash, before sinking.
4. Mike’s figures
It is probably fair to say that nothing conclusive can be deduced from the BFO chart. Duncan himself says that either the chart is wrong, or MIke is wrong or ‘there is something else’ or words to that effect. I have pointed out in previous comments certain things about the chart that would be consistent with the plane having crashed early on. In addition to those earlier observations, i also note that the nett BFO readings for the 6 complete handshakes seem to correspond to the satellite velocities at those times. If we use round numbers, the BFO readings for the 6 pings nett of the offset (90hz) are roughly 50, 20, 50, 80, 110 and 160Hz. The vz for the satellite for those times are roughly 49, 20, 47, 88, 123 and 160 knots.
richardc10 said,
April 19, 2014 at 2:39 am
Ole had the idea some days ago of temperature change in the satellite and the WSJ refers to this at:
http://tinyurl.com/l27phrv
“Investigators relied on the principle that the satellite’s temperature distorts the way it receives radio waves. The investigators analyzed changes in the temperature of the Inmarsat satellite on each occasion that the plane made contact and then made calculations about the jet’s trajectory, according to Warren Truss, Australia’s deputy prime minister.???
The angle of the Sun on the satellite changes with position around the orbit and the antennae would be fully pointing to the Sun just before the eclipse which lasted from 19:21 to 20:26. Elements on the antennae will have the largest temperature excursion at eclipse, but units inside the spacecraft will also have some temperature drift at that time. I doubt there is much thermal control, the units will have been specified to meet performance over some reasonable range. So the data points at 19:41 and 20:41 are particularly at risk of being prejudiced by the eclipse effect, though there will be some continuing drift due to the change of sun-angle over the orbital period. I presume the major effect will be on the L-band receiver chain stability and whatever frequency reference it uses. Googling gives one space solution for an oscillator which claims “Frequency stability: better than 0.2ppm over the temperature range -40°C/+70°C???. At best this is still 3Hz/C at L-band, so a shift of 10C would give 30Hz, a large shift in the context of the measurements Inmarsat are trying to make. No doubt the external temperature of the oscillator is measured (possibly not directly on the oscillator component), but the measurement could be several degrees off, particularly if the temperature is changing fast. Can’t see how an oscillator shift (or any temperature change in the receiver chain) would change the ping-arc time delays but others might know better.
The same applies to the C-band downlink but shifts in the pilot frequency on that link and the expected Doppler from the satellite orbital elements should allow that to be disentangled.
The WSJ article suggests that the Doppler data featured in the modelling of the final detailed position of MH470. The ping-arc data would have given an accurate final position if a constant speed/great circle course was taken. Given the very large change of search area at the end of March, I suggest that assumption did not pertain and the finally adjusted Doppler data was key in the current solution.
richardc10 said,
April 19, 2014 at 3:00 am
@Skwosh
Some imaginative thinking, but if we need to fit the model to the very early data points when there is other data, multiplicative models are going to struggle. The difference between the ‘core model’ and the data is, as you have said before, linear with time and neither of D1, D2 has that form.
I would stop beating your brains over D3; it doesn’t exist.
Skwosh said,
April 19, 2014 at 4:44 am
@richardc10 To be fair on myself – my latest brain beating was all about getting rid of D3. There is *no* D3 in my latest rambling.
Just to clarify (using my previous notation):
Existing ‘state of play’ model:
F_BFO = F_CoreModel + F_LinearAdjustment
F_CoreModel = – ( (V_AS – V_AS_FixedPosSat)*F_L_Band + V_SG*F_C_Band )
F_LinearAdjustment = F_Bias + F_Residual*(t-t_start)/(t_end-t_start)
New model:
F_BFO = F_Bias – 2*(V_AS – V_AS_FixedPosSat)*F_L_Band
Skwosh said,
April 19, 2014 at 5:16 am
@richardc10: So – to further clarify – *no* dependence on the sat to ground link or the c-band frequency at all because, we think, that’s all corrected for and would *not* be measured.
As you say “[D3] doesn’t exist”.
The idea above is that the *only* thing in the BFO is the uncorrected part of the link between the aircraft and the satellite (the only part that’s not corrected by the system). My ‘new’ thinking was that there could actually be a factor of *two* on this (so it’s basically just the sum of your D1 and D2 components but multiplied by two).
I guess you could still add a linear time offset to improve the fit! I was trying to go for something that was simpler than what we have now, and is a better conceptual fit with the idea that the BFO is an actual measurement, and that we really can’t think of a good reason why there would be *any* D3 in it at all!
It’s like @Ole’s been saying – the title of the diagram is “Doppler *correction* contributions”. Pretty much everything is corrected apart from a little bit between the aircraft and the sat and so that is what would be measured and would thus be ‘un-expected’.
GuardedDon said,
April 19, 2014 at 9:38 am
@alex
I’m confident to state that the satcom system would not operate autonomously without power from the aircraft distributed DC supply: no engine IDGs, no APU, no DC power, no satcom operation. My final contribution on this point.
While a lightning strike may have been a contributing event, the scant evidence in the public domain justifies that the aircraft remained in flight until approximately 00:19UTC on Sat 8th Mar. Many contributors have ‘sliced and diced’ that evidence published by MoTM, as based on information provided by Inmarsat, to derive the progress of the aircraft.
Skwosh said,
April 19, 2014 at 10:40 am
@richardc10 Re: The WSJ article: Don’t we think errors in the satellite get corrected by the pilot-signal technique? The final diagram in the document found by @Ole (https://www.miteq.com/docs/20TEC.PDF ) “Figure 8: EAFC Downlink ‘Aeronautical Downlink Frequency Correction’” shows (among other things) a pilot-signal being transmitted from the ground at the *L*-band frequency up to the satellite – so if that was being done they’d know about (and automatically correct for) any temperature induced duffness because that pilot signal is surely taking the same route through the satellite and back down to ground as the aircraft’s transmissions are taking? Maybe the whole pilot-correction thing in that document isn’t actually how it works – or maybe it was really subtle – perhaps part of the route through the satellite for incoming L-band transmissions could be different for the pilot-signal and the aircraft signal? Directional vs. non-directional stuff perhaps?
Alex Siew said,
April 19, 2014 at 5:59 pm
@GuardedDon,
I think i found what i was looking for in Rockwell Collins’ Installation Manual for their Satcom 2100/6100 series.
At page 1-30, the ‘Equipment Qualifications Categories’ for various aspects of the system are stated. For ‘Power Input’, it is as follows:
” A (WF) A, ac power
A Certified for use on aircraft electrical systems where primary power is from constant frequency ac generators and the dc system is from a transformer-rectifier. A battery may be floating on the dc bus.
BZ dc power
B Certified for use on aircraft electrical systems where primary power is from engine driven alternators/rectifiers or dc generator where a significant capacity battery is floating on the dc bus at all times.
Z Certified for use on aircraft electrical systems not applicable to any other category. For example, a dc system from a variable range generator where a small capacity or no battery is floating on the dc bus. ”
At page 1-31 of the manual, the Rockwell Collins SDU’s power input was categorized as Category A (CF) H.
From the Honeywell’s manual for their Satcom System MCS 4200/7200, that SDU (and all other related components) are categorized as Category A (WF) XBZ.(See for eg page 1-29)
I believe the electrical system being used in a 777 is the second category ie Category A where primary power is from ac generators and dc is from transformer-rectifier. In that case, ” [A] battery may be floating on the dc bus”.
I do not know whether the floating battery referred to is the internal battery, or the plane’s backup batteries or a stand alone separate battery for the Satcom system.
richardc10 said,
April 19, 2014 at 9:33 pm
@skwosh
re: L-band pilot frequency.
You are right, that is referred to. I guess a question is whether it is used by the satellite L-band receiver (rather than transmitter) – which is what we are concerned with here. The transmitter has to be spot on to meet the L-band downlink requirements, the receiver only has to work, so to speak.
richardc10 said,
April 19, 2014 at 11:01 pm
New line of thought on the change of search areas.
Following earlier thoughts I mentioned on the pprune forum, the ping-arc data should be very good at selecting between courses that are members of a particular class, e.g. all great circle routes, all rhumb-line routes, all constant magnetic heading routes, for example. However, the ping arc data is not good at differentiating between a course of one class and an equivalent course of another class. For example, for a given set of ping data there is one great circle route and one constant magnetic heading route with very similar ping data (but different destinations, and speeds).
The original search area in the Southern Ocean was chosen on some grounds. The NTSB tracks on the original maps were labelled with speeds, which might suggest the interim ping-arc data was not used at that stage as the speed is an output from the model, not an input.
Anyway, here I assume that at the start of the search a great circle route was chosen to define a first-order search area. Only one such course would fit the ping-arc data, and it was the Southern Ocean search area West of 90E, 40S where the Australian search started. This could be termed the base-course.
I looked at the ping data for the base-course and an alternative that would take the aircraft to the current search area. This latter is a course with a constant change of heading of 5.5degrees/hour starting roughly on the same heading as the base-course. This has the same ping data as the base-course, with an rms difference of 5km (a great circle course to the current search area has a completely different ping-signature to the base-course). Online discussions have suggested that the ping-arc data is not going to be more accurate than 5km; therefore the courses cannot be distinguished by the data. This confirms that the ping-arc data is not good at selecting between courses with different characteristics.
The two tracks are shown in figure 1.
Figure 1: Base-course to the original search area, and the changing heading course to the current search area.
http://s1311.photobucket.com/user/RichardC10/media/Route-map_zps0481c5fd.jpg.html
The actual base-course may be different with a smaller heading change required to the current search area, but the principles are the same. Whether there is a B777 flight mode that would give a continuous heading change of this sort, I do not know.
However, the ping-BFO data for the two tracks will be different, but not by much. Figure 2 shows the modelled BFO for the two, with the published data as an example. The uncertainty of the origin of ‘D3’ means no comparison with the data is meaningful, but the graph shows the modelled BFOs are up to 15Hz different. The distance between the two final destinations is 2300km, so roughly 150km/Hz.
Figure 2: Modelled BFO predictions for the base-course and the changing heading course.
http://s1311.photobucket.com/user/RichardC10/media/BFO-predictions_zps1fbf409b.jpg.html
So if the ping-BFO was used to tighten up the position along the final ping-arc to better than 100km, to allow the acoustic ping search in a limited area, sub-Hz BFO resolution would be needed. If this is what happened, no wonder it took time to resolve/calibrate out all the errors that could contribute, including spacecraft thermal effects mentioned earlier, and that the best-fit position crept North over a period of many days. Of course there may be other data as well, as yet unreleased.
Skwosh said,
April 20, 2014 at 2:58 am
@richardc10 Excellent – very well made and illustrated points. In summary then, I think you’re saying: Those two tracks, which are both consistent with the *same* set of ping rings, are hugely different in outcome – and though their BFO plots (using existing ‘state of play’ model?) are different, they aren’t *that* much different. So, if all Inmarsat have are the ping rings and the BFO data, then for them to have narrowed things down to as small an area as they have must have involved some *very* tight certainties on the accuracy and interpretation of the BFO data – almost unbelievably tight in fact.
One thing from the WSJ article that caught my notice: “[...] investigators further refined those projections by evaluating data from *hundreds* of other flights with similar equipment that crisscrossed the same region [...] ‘The Inmarsat model was *designed* for fine tuning,’ said Inmarsat Senior Vice President Chris McLaughlin, who said it revised the search area continually as new information arrived [...]“
Alex Siew said,
April 20, 2014 at 7:12 am
@GuardedDon
Please ignore my comment about the floating battery. I think those are just the RTCA categories. The power input for the antenna used for Aero M from Thrane (TT-5006A) is said to be “28 V DC Floating Battery”.
richardc10 said,
April 20, 2014 at 8:01 am
Yes, that is right. I not suggesting that MH370 followed that particular path, just that even a good fit to the ping-arc data for a great circle route does not rule out a whole family of curved courses of the sort I showed. The ping-arc data is not helpful to pin down the final destination when nothing is known about the nature (type) of the course taken.
I suspect the sequence was the following:
a. The ping-arc data gave no good fit, for any GC course or indeed any reasonable course that could be justified. At that point the ping-Doppler data was still being worked on and had not reached a state adequate to set the search area. Therefore, an ‘NTSB’ average speed method was used, which indicated a destination in the Southern Ocean.
b. The calibration of the ping-Doppler data proceeded to remove the systematic errors, verified by the use of data from other air traffic. Extracting the value of D2 for the final (full) ping is the key measurement – inside that is the latitude of the aircraft via the known (and then calibrated) D2 function of spacecraft position and latitude. D1 is small for the final ping. The final ping-arc gives the longitude. When this was mature enough, the search area was moved to the NE. The drastic reduction in the modelled airspeed (from the ‘NTSB’ figures) might have been a surprise, perhaps it took a while to be accepted.
c. The model development and calibration continued and as the last few Hz were found the best-fit moved to the current position.
The Inmarsat model is not proven to be right until MH370 is found, of course.
GuardedDon said,
April 20, 2014 at 2:19 pm
@alex
No floating batteries on 777 DC busses: a) nothing to do with buoyancy; b) power distribution and ELMS on the 777 is designed to be highly redundant and non-interrupting – both characteristics eliminate need for batteries. The B777 systems have to be highly redundant and the ELMS non-interrupting, it was the first FBW and twin engine aircraft to fly long oceanic segments previously operated by three and four engine aircraft. My last contribution to the battery topic, however, your reference to the Thrane product did lead me to some useful information on doppler correction input to the SDU from their 3 different antenna types.
sk999 said,
April 20, 2014 at 3:32 pm
richardc10,
Very nice presentation. I can more or less reproduce both tracks as follows.
Start at NILAM at 18:30, Base route – great circle, initial heading 186.5, speed 450 knots. This puts us on the 40 degree ping arc at 20:11 at long 96.5, lat -35.5. Hopefully that jibes reasonably with your values. For the alternative track I used the constraint that the track follow the ping arcs of the base route exactly. I seem to need an average heading rate change of abou 9.8 degrees per hour (it’s not exactly constant) versus 5.5 that you assume. End point at 00:19 is long 104, lat -20.8
Trends in BFO plots match in general – slight differences in detail.
Reportedly a driver for the shorter track was fuel burn rate, so it would not have been refined analysis of the BFO data alone.
airlandseaman said,
April 20, 2014 at 3:36 pm
Debate revolving around the meaning of the ambiguous BFO values has been spirited and inspirational. I have been convinced from the beginning that the inbound C band Doppler is included in the BFO values because the BFO observation at 16:30, when MH370 was parked at Gate C1, provides such an excellent fit to the data. I remain confident in that interpretation. However, the meaning of the remaining (D1+D2) term has been difficult to validate. Several interpretations have been put forward. Originally, I believed that the AES TX offset value must be communicated to the LES as part of the header in the handshakes, and that offset value was taken into account by Inmarsat in the computation of the LES “Expected Frequency???. But some have reported here that this value is not communicated to the LES. If so, then D1+D2 is more likely to be residual error resulting from an imperfect (and unknown) TX frequency offset computed by the AES.
It occurred to me that we have in the ADS-B data the means to validate the D1+D2 values not only for the Gate C1 position, where the AES velocity was zero, but also for the next 3 ACARS reporting times. To investigate this idea, I asked Duncan to calculate the AES Position to S/C (1) AZ, (2) EL, (3) Range and (4) Range Rate for the times 16:30, 16:43, 16:56 and 17:07 UTC. From these data, it was possible to calculate the separate D1 and D2 values for the first 4 ACARS times using only the satellite ephemeris and ADS-B data. For the 16:30 observation, the value of D1+D2 calculated from ADS-B data agrees with the value calculated from BFO data to 0.18 Hz. That is a very compelling argument for the belief that the BFO values include the C band Doppler. However, the next 3 ADS-B derived values for D1 and D2, when the aircraft was moving, are not even close to the BFO derived D1+D2 values. This seems to validate the theory that the BFO values are the sum of the C band Doppler plus the residual error in AES TX Offset algorithm + AES reference oscillator error. Since this offset error is essentially zero when the aircraft is at rest, the AES reference oscillator error must be ~0 Hz, and the total error is dominated by the Offset Algorithm error. A summary of the data and results can be downloaded here:
https://dl.dropboxusercontent.com/u/32349391/BFO_Analysis_2014-04-20.pdf
Feedback appreciated.
richardc10 said,
April 20, 2014 at 11:46 pm
@airlandseaman
Thanks for posting those numbers. Some feedback:
1. I get similar numbers for the calculations done using your definitions. Somewhat different for D1 (the offset due to the aircraft velocity) but there is a deal of spherical trigonometry in that calculation (as you know) and I wouldn’t claim mine is dead right.
2. The natural measurement for BFO is a positive frequency change fron the expected is a positive BFO, so a negative range rate is a positive BFO. Regardless of the D3 origin, Inmarsat have the BFO increasing for the South track at the end of the flight, when the satellite is going South and this gives negative range rates for both the C-band and L-band links. I know this doesn’t match with your interpretation of the 16.30 ping where the C-band Doppler would give a negative BFO by this definition.
3. There isn’t room in the data for the raw aircraft velocity induced Doppler, so the correction performed onboard has to reduce this to a much smaller number. Using the idea proposed by sqwosh, ole, D1 becomes the difference between the velocity components to the _actual_ satellite position, which I assume you have used here, and to the _nominal_ position of 64.47E, 0N. On this basis I get D1 to be (using your speeds etc):
16:30 0m/s
16:43 -9.9m/s
16:56 -10.2m/s
17:07 -5.7m/s
These are not actual ‘speeds’ of course, they are errors with these values and signs. In this idea the onboard algorithm does not compensate for the rate of climb of the aircraft, so this appears directly in D1 (as above) after correction for the elevation of the satellite. The main difference between the 16:56 and 17:07 D1 numbers is due to the change in rate of climb.
You should be able to check this using your method of calculating D1.
richardc10 said,
April 21, 2014 at 2:25 am
@sk999
>Reportedly a driver for the shorter track was fuel burn rate, so it
>would not have been refined analysis of the BFO data alone.
Quite right, that was said. The track was pulled to the East as well as shorter, so presumably the new predicted range at that point was less than the distance to the last ping-arc on the original track, so a new track was also needed (and hence a lower speed). So it sounds like the ‘NTSB’ average speed strategy still had a lot of weight at that time – perhaps the ping data full acceptance came even later (if indeed it is fully accepted even now).
One can imagine some discussion along the following lines, with stereotypical dialogue (apologies in advance for the flippancy).
NTSB guy: Look [AAIB/Inmarsat person], you’ve got the airplane corkscrewing all over the goddam Indian Ocean at less than 300kts, why the hell should it do that? Have you even flown a triple-7? You’ve only got five measurements, I don’t buy any of this.
AAIB/Inmarsat person: Sorry, old boy, but that’s what the data tells us. And if you don’t mind me saying, you’ve had the Aussies flying all over the Southern Ocean for two weeks now with your 450kt track and, pardon the language, they’ve found sweet Fanny Adams.
You can write your own dialogue for when AAIB and NTSB were told the Malaysians had invited BEA to join the investigation.
airlandseaman said,
April 21, 2014 at 2:42 am
@richardc10
I used the following:
D1=[ADS-B Speed * COS(heading - AZ) * COS(el)]/wavelength
D2=Range-Rate/wavelength [NOTE: RR from fixed points]
I neglected to include ROC in the 16:43 and 16:56 D1 calculations. I’ll fix that. ROC = 0 at 16:30 and 17:07, so they should be correct. But inclusion of the ROC effect will not change the big picture much. The main point was to show that the C-Band Doppler is a component of the BFO, the signof D3 is negative at 16:30, and the term (D1+D2) is definately the TX Offset algorithm *errror*, not the true total (D1+D2) Doppler.
It is a shame the TX Offset is appraently not communicated to the LES. Without it, the true L band Doppler can not be derived. This must explain why Inmarsat did not claim more than the general direction (south) from the BFO data. That said, more be learned by estimating the TX Offset, based on assumptions about the algorithm used and aircraft path.
Skwosh said,
April 21, 2014 at 7:08 am
@richardc10 Top job on the stereotypical dialogue above – actually sounds strangely credible to me – but what do I know. I’m going to try to find time to code up the model for myself (long overdue really – and the best way to resolve for myself various speculations/possible-sign-confusions I have without wasting too much of anyone else’s time). My initial objective is to get to the point where I can reproduce the ‘state of play’ plot – and I think all the numbers I need are already published either by you in your diagrams and comments, or by Duncan and others. The possible exception to this could be the positions, headings and speeds for the final five points that you used for that particular southern track (though they may be published elsewhere (GobusMax track?) – anyhow, I’ll read back to check if you referenced where you got them from). If not, and only if a convenient moment arises for you to do this, I’d really appreciate it if you could put them in a comment or point me to where I can get them – but I guess even without those last points I can be fairly sure I’ve got it right if I can match the initial data.
richardc10 said,
April 21, 2014 at 8:20 am
@skwosh
>I’d really appreciate it if you could put them in a comment or point
>me to where I can get them
All calculations of position, angles etc were done with my own spreadsheet. I got the satellite rangerates from Orbitron. Simpler interface than STK but probably a bit less accurate (at the 0.1m/s level) and can’t do a time series. I used the rotor/radio option.
The data for the state-of-play (a GC to the current search area) are:
Start point: 18:27UT long -94.00 lat +6.00 initial heading 159.96 (True), speed 287.403kt
Then
Time Long Lat
19:41 -96.02133063 +0.447375905
20:41 -97.65623627 -4.055478959
21:41 -99.30949202 -8.555006084
22:41 -101.0023215 -13.0473482
00:11 -103.6057743 -19.61415614
If you want to code it yourself I recommend the following for the 3-D trig formulae. http://williams.best.vwh.net/avform.htm
richardc10 said,
April 21, 2014 at 8:24 am
@airlandseaman
In case you’re interested, the azimuths and elevations to the ‘nominal’ satellite position (64.47E, 0N) for the first four points are:
Azimuth Elevation
266.3922 46.7187
266.2581 46.7711
264.7583 46.0269
263.9819 45.6061
Skwosh said,
April 22, 2014 at 7:30 am
@richardc10 Cheers – thanks very much for the info – that reference is excellent. Model building in progress…
sharonc said,
April 22, 2014 at 10:21 am
Although this information is revealing it does not explain the fact that if a plane crashed in water at any angle other then a nose dive and maybe even then, the wings would be torn off thus making the engine ping theory not hold up. Pings would not be found from a plane with no power. The plane’s location of impact is known. See here: http://www.lagrandeobserver.com/News/Local-News/Mystery-of-missing-airliner-solved
airlandseaman said,
April 23, 2014 at 8:17 am
I am looking for the MH370 exact Lat, Lon, speed, ROC and heading as of the time of the 4th ACARS communication (17:07 UTC). The last ADS-B position on Flight Aware was at 17:02 UTC, but I read somewhere (McLaughlin interview?) that the 1st and 4th ACARS transmissions (16:30 and 17:07 UTC) included position reports. Please advise if you have any sources for these reports or postion data.
airlandseaman@earthlink.net
Thanks, Mike
Annette said,
April 23, 2014 at 10:50 am
@airlandseaman
The following link does have the speed if you click on the dark gray button at bottom right, a speed/altitude graph appears. If you hover over the red & blue lines, the values appear.
http://www.flightradar24.com/data/pinned/mh370-2d81a27/#2d81a27
There is interpolation there but it might still be helpful.
airlandseaman said,
April 23, 2014 at 12:23 pm
Thanks Annette. I got the 17:07 speed and heading from FlightRadar24. From the FlightRadar24 map, I was able to find the same location in Google Earth to get the Lat and Lon.
17:07, 469 kts, 35,000 feet, 5.419167N, 102864167E, ROC=0
This data is in close agreement with the position I calculated from the extrapolation of ADS-B data for the period from 16:52 to 17:02 up to 17:07.
marvinvestal said,
April 23, 2014 at 12:26 pm
airlandseaman
You misunderstood my comment. As you said the technology is not in question. Perhaps the last honest (although misleading) statement from Inmarsat was “never before used technology???. The truth is that the automatic transmission and detection of pings was not designed for this purpose and was not tested or validated. Their conclusions could have been true, but clearly were not. Thus the data generated provides no information about the flight path of MH 370. The most likely explanations for the problem with the time delay measurement are that the clocks on the satellite and airplane were not synchronized with sufficient precision and the problem with the frequency shift results that you and your colleagues have gone to great effort to analyzer are merely low frequency noise. I have fifty years of experience conducting these kinds of measurements in a controlled laboratory environment and even with the most carefully designed and constructed state-of-the-art equipment, low frequency noise is very often a problem that must be solved. Garbage in garbage out.
airlandseaman said,
April 23, 2014 at 1:27 pm
regarding:
marvinvestal said,
April 23, 2014 at 12:26 pm
Respectfully, I must disagree. The BFO values are real observations, not noise. But we don’t know exactly what all the D1+D2 components are…yet. We do know that the C band feeder link Doppler (D3) is part of the BFO values, and we have good reason to believe the remaining term (D1+D2) is the Total L band Doppler residual after an unknown AES TX Offset is applied to the AES TX frequency. We may not fully understand the BFO values yet, but they are not noise.
BTW…I also have ~50 years of experience, both as a pilot, and as an entrepreneur and RF & Systems engineer. I know quite a bit about the Inmarsat system, having founded a competing mobile satellite company in 1983. I was a US delegate to the 1987 Mobile WARC where we fought with Inmarsat over the allocation of L band spectrum for the new US Mobile satellite Service we pioneered. That system and service was eventually approved by the FCC and we eventually launched the largest commercial communications satellite in history in 1995. It used the same L band frequencies used by Inmarsat. Going through my basement museum this morning, I found photos of a prototype Inmarsat transmitter we built to demonstrate the services we wanted the FCC to authorize. I also found the actual hardware, both the low data rate transmitter and the receivers and demodulators! Too much nostalgia. Despite the competition with Inmarsat over spectrum, we had a good working relationship. They gave us access to their New England earth-station for the installation of our receiver and demodulator and allocated space segment capacity for our demos. We used this demo system to show Reagen’s OS&T, the FCC and Congressional folks what we could do with a thin route satellite communications system to serve rural and remote areas of the US. But I digress. Bottom line: Inmarsat is a good company, and I don’t think they would cook the books. The BFO values have meaning. We are still learning.
richardc10 said,
April 23, 2014 at 1:56 pm
@marvinvestal
You raise very good points and have the practical experience. It is not clear that the published Doppler data are the actual measurements so it is possible that noise has been smoothed out. The trends seem to match the model but the accuracy needed to determine the final destination corresponds to a 1Hz characterisation of a single BFO measurement (on a 1.6GHz signal, so one part in 2 billion), if I understand what is being attempted. The Inmsarsat statement is that a lot of post-facto calibration has been done using other aircraft but of course they have not had access to the actual satellite terminal in the aircraft.
GuardedDon said,
April 24, 2014 at 2:25 am
@airlandseaman at April 23, 2014 at 8:17 am
Mike, the first four events will have carried what’s termed OOOI exchanges using ACARS messages between the aircraft and the dispatch team at Malaysian Airlines Operational Control Centre (OCC).
MoTM alluded to this in a statement, http://bit.ly/QFc2y2:
‘The last ACARS transmission, sent at 1.07am, showed nothing unusual. The 1.07am transmission showed a normal routing all the way to Beijing.’
At that time the aircraft would have been intercepting the FMS pre-planned route at the IGARI waypoint: the FMS /will/ relay route updates & changes back to the OCC. MoTM stated the 1:07 msg was the last downlinked from the aircraft.
Apologies that I don’t explicitly answer the question, the specific content of MH370′s messages isn’t public knowledge.
OOOI: “Out, Off, On, In”, in the parlance of airline operational control.
marvinvestal said,
April 24, 2014 at 6:23 am
airlandseaman
You know a lot more about the details of the ACARS system then I, so I am happy to yield to your judgment. Are you aware of any previous case where transmissions between a single plane and a single satellite have been used to determine fight path? It clearly could be done if the system were designed, validated, and tested for that purpose, but it was not. My initial skepticism was triggered by the original statement from Inmarsat that the plane flew in either a southern or northern path maintaining exactly the same distance from the satellite. To the best of my knowledge the data behind that conclusion has not been released and it still stands as the major reason for the extensive search in the Indian Ocean. As a pilot how would you or an autopilot manage to do that if you did not know exactly the position of the satellite?
GuardedDon said,
April 24, 2014 at 9:17 am
@marvinvestal
I came to this with both curiosity and skepticism. Maybe going back two further posts on this blog and following it through will help you!
The satellite in question doesn’t contribute to the aircraft navigation by a pilot or the aircraft AFDS, it’s a comms satellite but given that modern airline operations rely heavily on satcomms it was realised that the telemetry data associated with the comms events to/from the aircraft could help guide the search when nothing else was available.
In addition to here, check out http://www.duncansteel.com.
Skwosh said,
April 24, 2014 at 2:54 pm
@richardc10 Thanks again for posting that data. I’ve got my model together now – and reproducing your numbers pretty much exactly (though I haven’t experimented with ‘lag’ yet). Part of what I wanted to be sure about was to see how the climb sensitivity behaves – and now I’ve done it for myself I can see how extraordinary it is that such a good fit for the (known) 16:43, 16:55 and 17:07 points just pops out when (as you discovered) the compensation mechanism is made unaware of climb. It is also very interesting to confirm your observations about what the model is and is not sensitive to in various cases.
Alex Siew said,
April 24, 2014 at 5:30 pm
@marvinvestal,
Inmarsat did not say the plane flew along the arc, Inmarsat said the plane was somewhere on the arc when the 8.11am ping was transmitted.
However given how close the arc is to the point where the plane had disappeared at 1.21am off IGARI over the South China Sea, the plane would have to be traveling ALONG the arc for the most part, to end up somewhere on the arc at 8.11am.
For Inmarsat’s theory to make sense, the starting point for the plane’s journey subsequent to its disappearance would have to be much further west. Thus the conclusion reached by the investigation team that the unidentified blip 200 nm off Penang at VAMPI at 2.15am or MEKAR at 2.22am which was later tracked following navigational waypoints to the Andaman Seas even further west, was MH370, despite no radar, primary or secondary, from military bases or the various airports/ATCs in that part of Malaysia having picked up any blip off IGARI crossing over northern Malaysia to VAMPI or MEKAR off the other coast.
airlandseaman said,
April 24, 2014 at 8:28 pm
marvinvestal said,
April 24, 2014 at 6:23 am
Regarding your questions:
1. “Are you aware of any previous case where transmissions between a single plane and a single satellite have been used to determine fight path?” No one is claiming that the path can be uniquely and independently determined from the range and range rate data from one satellite alone. So your premise is not valid. But any communications satellite (L band, C band, Ku Band…) can be used to measure time delays (range) and range rate (Doppler) if the earthstations involved are capable of the necessary measurements, which is the case with this system. Using a model of the aircraft and satellite motions, together with these measurements and some assumptions about the average speed and initial starting point, a most likely path can be computed. (In some cases, a single satellite can locate a transmitter to within a mile or better. See for example the TRANSIT Satellite series, NIMBUS6, TIROS N, etc. Also note, 121.5 MHz ELTs can be located using a single LEO satellite (NOAA LEOs do it) and Dopplerprocessing.)
2. “My initial skepticism was triggered by the original statement from Inmarsat that the plane flew in either a southern or northern path maintaining exactly the same distance from the satellite.” Again, the premise is incorrect. Inamarsat never said “…maintaining exactly the same distance from the satellite.” What they said was that the aircraft was headed away from the subsatellite point at each handshake time. The distance was different at each handshake, and the aircraft could have been flying in the opposite direction inbetween handshakes. The Doppler and range data do not tell us anything about the path inbetween handshakes. We can only make reasonable assumptions and constrain a model with those assumptions to get to a likely path.
richardc10 said,
April 24, 2014 at 10:36 pm
@skwosh
Only a couple of days ago Jeff Wise, a CNN contributor, was saying “Even more significantly, I haven’t found anybody who has independently analyzed the Inmarsat report and has been able to figure out what kind of northern route could yield the values shown on Page 2 of the annex. ”
http://jeffwise.net/2014/04/18/slate-why-inmarsats-mh370-report-is-a-smokescreen/#more-3264
Now there is at least two of us who can!
airlandseaman said,
April 25, 2014 at 3:12 am
richardc10 said,
April 24, 2014 at 10:36 pm
I agree with Jeff Wise. I understand that several people have done a good job attempting to reverse engineer “rings”, and I agree that northern paths can’t be completely ruled out. But no “path models” I am aware of are completely consistant with, or completely explain the BFO data on Page 2 of the ANNEX I. That was Jeff’s point.
That said, I believe I am inching closer to understanding the individual components of the 3 BFO time series, each defined to be:
(Expected-Measured) = (D1+D2+D3).
With Duncan’s expert help with STK, I now have radar and ADS-B based ground truth for the the individual D1, D2 and D3 components for the first 4 ACARS Handshakes. In other words, we now have four independent “calibration points”, not just the one when MH370 was stationary at Gate C1 on the ramp at 16:30:00. I am hoping that these additional 3 “in flight calibration points” will shed light on the “AES TX Offset questions”, the answers to which are crucial to understand, if we are to squeeze anything useful (net aircraft Doppler) from the BFO data.
The preliminary analysis clearly indicates that the BFO values could not have been produced by an AES that used a Doppler TX Offset method that “accurately compensated” for the total L band Doppler (D1+D2), such as the one patented by Rockwell which measures the 1.6 GHz downlink Doppler in real time to offset the 1.5 GHz uplink. The D1+D2 residuals are far to big for that assuption to hold. That implies that the AER used a different TX Offset method which was less accurate. However, the fact that it was not as accurate as the “closed loop” (Rockwell) methed may be a lucky break if it can be shown to produce repeatable, systematic errors that are dependent on the instantaineous S/C – A/C geometery and relative motion. Reading between the lines, I believe that may be eaaxctly what Inmarsat is exploiting in the “predicted tracks”, and why they needed to use other 777 flights to validate their assumptions. Stay tuned.
Alex Siew said,
April 25, 2014 at 3:36 pm
For those who think that a different formula may apply to the first part of the BFO chart (the ACARS transmissions) as compared to the latter part of the chart, the comments of Victorl on Duncan’s latest post (April 23) are worth noting.
Victorl has this theory that the offset correction would apply for the ACARS transmissions but not for the pings, that something had happened (prior to the pings) to break the data path between the Aircraft Information Management System (AIMS) in the main bay and the SATCOM at the rear, disabling ACARS and preventing the SATCOM from getting updates of speed and position from the AIMS.
Alex Siew said,
April 25, 2014 at 5:43 pm
@LGHamiltonUSA,
Regarding the reports about villagers at various locations on the north east coast of Malaysia having claimed to have heard or seen a plane, I had posted a further reply to your comment but it seems it didnt go through.
The various radar recordings posted online show that there were other planes flying on a north/south direction along the north east coast of Malaysia at the time MH370 disappeared from radar screens at around 1.21am. Most likely the villagers saw or heard one of these other planes.
Regarding the CNN interview with the Malaysian PM, from the transcripts and videos of the interview on the net, the PM said their military radar “tracked an aircraft which did a turn back”. He did not say their radar tracked an aircraft crossing over Malaysia, those words were said by the interviewer.
Right from the outset, the malaysian military had said that there was a ‘possibility’ MH370 did a turn back. I believe the military based their conclusion, mistaken in my view, upon the fact that at the time of disappearance MH370 was turning from 25 degree to 40 degree off IGARI. This turn however is reportedly in accordance with MH370′s normal flightpath as previous flights earlier in the week also show a turn to 40 degree at this point.
Bottomline is that if the malaysian military or any of the airports/ATCs which would also have primary radar, have a recording of MH370 or an unidentified blip crossing over from the east coast to the west coast, they would have produced it by now.
richardc10 said,
April 26, 2014 at 2:37 am
Given the model developed for the ping-BFO I modelled the track of the aircraft against the published data, using the excel solver function to fit a number of parameters. The aim was to see what Inmarsat might have concluded was the final destination based on the BFO data (at that time) alone. The role of the mystery interim ping-arc data remains unclear, but the BFO data is insensitive to the longitude of the route taken, so is not susceptible to the ‘bendy-course’ problem that can confuse the ping-arc technique. Even so, the 19:41 ping-arc should have given a useful longitude constraint. The final ping-arc still gives the key final longitude.
Given it was released for a particular purpose the BFO data has some problems, but it does represent a snap-shot (if at an odd angle!) of the data at that time. The parameters I modelled were:
a) the destination on the final ping-arc
b) the latitude of the start point
c) the linear (with time) BFO component (D3) added by Inmarsat for some reason to ‘mask’ the details of the data. This has been discussed earlier in this thread – not satisfactory, but this is an intelligence operation, not a science or engineering problem; we can’t carry out experiments or read a tech manual to answer all the questions.
The constraints were:
a) the longitude of the start point should be the same as the position of loss of radar contract NW of Penang, at 97E. The ping-BFO data does not constrain the longitude, these constraints have to be separately provided.
b) a constant speed course was maintained over the last five pings, from 19.41 onwards. As noted above the technique is not sensitive to the course heading, smooth changes of heading do not affect the result of the fit. The last five points were fitted (the data around 18.30 was not used, a heading of 295 at this time is assumed in the graph).
The model and the data is shown in the graph below (figure 1); the r.m.s. for the fit is 1.9Hz. On the plus side, the fitted path ends on the edge of the new search area declared on 28th March, which might suggest that the ping-BFO data (at least in part) was used in selecting that area (figure 2). However, there is a significant gap between the last reported radar position of the aircraft at 18:20 and the start of the modelled constant speed track at 18.30, so the result is not perfect. The modelled BFO at 19.41 is dominated by the D1 contribution which is the actual Doppler to the satellite minus the correction made by the AES. My model of how that correction is made may not be fully correct; tweaking the AES correction value by 10% (0.5m/s) moves the 18.30 position North close to the 18:20 position (figure 3). A lot of fitting in this exercise, but I think it gives an indication of what was going on.
Note that none of this modelling uses a diversion West round Indonesia. As stated earlier, the BFO data does not constrain longitude on its own, but using a more Westward turning point leaves a lot of distance to be covered to the fitted 19.41 ping position. Using a variable speed would assist (or a larger change to the D1 contribution), but in the end the issue does not materially change the method of selecting the 00:11UT position.
The different in predicted 00:11UT BFO between the 28th March search area and the final search box is 10Hz. This can only be in the difference in component D2 (satellite to aircraft position Doppler which is a function of latitude at any given time), the origin and value of which is not in any doubt. The other components at this time are small or well known (to Inmarsat). This must represent a real shift in the data during early April, if the BFO data was used in this way. I guess this was the result of the stated Inmarsat ‘fine-tuning’.
Figure 1: Fit to the data (last five points), fitting parameters destination on last ping ring, latitude of start point, linear ‘masking’ component (D3).
http://s1311.photobucket.com/user/RichardC10/media/graph-28-4-14_zps6fc618de.jpg.html
Figure 2: Map showing the track represented by the best fit showing the 28th March and Final search areas
http://s1311.photobucket.com/user/RichardC10/media/map-28-4-14_1_zps242a19c9.jpg.html
Figure 3: Map showing the track represented by the best fit showing the 28th March and Final search areas, after 10% adjustment to the D1 contribution.
http://s1311.photobucket.com/user/RichardC10/media/map-28-4-14_2_zps52aa8c16.jpg.html
airlandseaman said,
April 26, 2014 at 4:53 am
I think I have finally cracked the BFO code. By using STK Range Rates, radar and ADS-B data to compute the true Doppler values for the first 4 handshake times, it was possible to calibrate the system. These four times include the stationary case at Gate C1, and 3 other times when the aircraft was flighing toward the satellite, away from the satellie, climbing and straight and level. Thus, it shows how well the AES TX Offset system works in a variety of cases.
Conclusion: The BFO values are the sum of the C band Doppler and the L band TX Offset Residual Error. The AES attempts to offset the uplink carrier frequency so as to reach the satellite antenna in the center of the assigned channel. But thee AES algorithm/hardware does not produce a perfect offset, so there is a residual error in the BFO values. If the TX Offset was perfect, then the BFO would simply be the C band Doppler component (D3). The Offset is fairly good, reducing the Doppler from as much as 460 Hz in one calibration case to no more than 85 Hz worst case for all 4 cases. The results are posted here.
https://dl.dropboxusercontent.com/u/32349391/BFO_Analysis_2014-04-25.pdf
There will be one minor update to the analysis once I figure out how to include the Doppler due to the ROC for the second and third calibration points. The ROC was 0 for the first and fourth case, so they are correct. Victor is helping me with that detail. The correction will be small, so I decided to release this preliminary documewnt to get the word out. I will release the entire spreadshhet as soon as we get the final tweeks in.
Mike
airlandseaman@earthlink.net
LGHamiltonUSA said,
April 26, 2014 at 5:20 am
http://tmfassociates.com/blog/2014/03/24/understanding-the-satellite-ping-conclusion/#comment-26224
Hi Alex ~
With regard to your previous post referenced above, I agree with your assessment however whatever may be the case (whether true or false) the Malaysian authorities have a propensity to hide everything so we can rarely confirm anything.
I am aware of the 40* heading change; Flightradar24 confirms that here:
https://m.facebook.com/photo.php?fbid=679309148775178&set=a.116008071771958.7699.111607872211978&type=1&theater
[Be advised this has always been a good link but the server was down when I tested it. I also confirmed the server error directly through other links to their page.]
However, I might disagree with Flightradar24′s claim about MH370 flying the same route on March 4th. I have a record from Flightaware (not 100% accurate either) that this route was flown the day before (MYT) on March 7th:
07-Mar-2014 B772
Kuala Lumpur Int’l (WMKK / KUL)
Beijing Capital Int’l (ZBAA / PEK)
00:51 MYT 06:24 CST 5:32 hrs
Getting back to the turn: The 15* heading change turning from 25*NE to 40*NNE always caught my attention. Rather than the aircraft making a sharp left westward turn I always thought the aircraft perhaps banked ~20* (Wiki/NYT) and completed the loop heading starboard right to make the purported course correction. As you know, this is speculation. It’s not logical to me otherwise, but I lack proof. I suppose it all depends on whether the aircraft was under human or autopilot control.
~LGH~
LGHamiltonUSA said,
April 26, 2014 at 8:57 am
http://tmfassociates.com/blog/2014/03/24/understanding-the-satellite-ping-conclusion/#comment-26282
Correction: “…from 25*N to 40*NNE…”
~LGH~
LGHamiltonUSA said,
April 26, 2014 at 9:14 am
https://m.facebook.com/photo.php?fbid=679309148775178&set=a.116008071771958.7699.111607872211978&type=1&theater
It seems that Flightradar24 requires a user to now be logged into their Facebook account in order to view the above link. Here is what the page said:
“The last location tracked by Flightradar24 is
Time UTC: 17:21:03
Lat: 6.97
Lon: 103.63
Alt: 35000
Speed: 471 knots
Heading: 40
Between 17:19 and 17:20 the aircraft was changing heading from 25 to 40 degrees, which is probably completely according to flight plan as MH370 on both 4 March and 8 March did the same at the same position. Last 2 signals are both showing that the aircraft is heading in direction 40 degrees.”
As previously mentioned, Flightaware indicates that 9M-MRO flew the MH370 route on the 7th, not the 4th. This discrepancy could have been a typographical error. If anyone can confirm please advise. Thanks.
~LGH~
sk999 said,
April 26, 2014 at 9:24 am
The document found by Ole on automatic frequency compensation schemes used by Inmarsat raises a couple of questions.
https://www.miteq.com/docs/20TEC.PDF
1. A pilot signal is used by the ground station (Perth) to monitor frequency shifts induced by the satellite, but the pilot signal need not be sent from Perth. Figure 3 shows it being sent from a separate station. I’m guessing it is sent from the “telemetry, track, and command” station. Does anyone know where this is located for 3-F1? Various possibilities include Fucino, Italy and Beijing.
2. The L band pilot is sent out at a fixed frequency (no compensation for anything.) In the old-style AFC system, the ground station uses the measured pilot frequency to compensate the incoming C band signal from other mobile stations, ignoring the Doppler contribution entirely. This means that the L band doppler between the TT&C station has not been removed and will show up as an error in the BFO. The newer AFC system removes this Doppler contribution from the correction. The question is – which system does Perth use? Perth seems to have older hardware that supports only the basic Aero H service, so it is conceivable that the AFC system was never upgraded.
A North latitude location for the pilot frequency transmitter would give a Doppler that has the right sense (if not magnitude) as richardc10′s unknown drift.
LGHamiltonUSA said,
April 26, 2014 at 9:43 am
http://aviation-safety.net/database/record.php?id=20140308-0
This is the Aviation Safety Network’s accident report for 9M-MRO. It includes a chart of MH370′s flight at the IGARI waypoint plus other useful information.
~LGH~
LGHamiltonUSA said,
April 26, 2014 at 10:06 am
http://tmfassociates.com/blog/2014/03/24/understanding-the-satellite-ping-conclusion/#comment-26278
@airlandseaman (Mike)
I just saw your very important announcement. This is wonderful news! I look forward to reading your latest BFO Analysis and the final spreadsheet when it’s available. All you guys are AMAZING!
~LGH~
Skwosh said,
April 26, 2014 at 10:44 am
@sk999 Brilliant – that’s such an appealing idea! What I could not understand about that document was that if the transmitter of the pilot frequency was distant from the receiver then they’d *have* to do an actual Doppler *calculation* based on the various ground positions and the position and the velocity of the satellite anyway… which kind of defeats part of the object of using the pilot transmission in the first place (though I guess it would still be useful for compensating errors in the satellite’s frequency conversion). I think (as you suggest) they probably *do* do these calculations on the more advanced setup if only because there is this bit of text on the very last diagram: “[...] The pilot receiver *calculates* the uncorrected frequency.”
However, it never occurred to me, as you are now suggesting, that on the *older* system they may just *not* worry about that at all and simply subtract off the offset in the pilot frequency ‘as is’… in which case that might provide a pretty sound explanation for where the extra component in the BFO is coming from and why it *looks* like an added southern hemisphere roughly-*L*-band satellite velocity derived component – and this would also allow us to get back to the idea that the BFO can be interpreted as a true post-ground-correction measurement, and therefore truly the difference between what was expected and what was measured on the ground. As you say, such a term would be the ‘right way up’ if the transmitter was north of the satellite (because it is being *subtracted* from the signal) – and I think actually the magnitude could be fine – that is all down to the position of the transmitter – the further north the greater the magnitude. I guess we *really* need to know where the transmitter for that pilot signal is!
airlandseaman said,
April 26, 2014 at 2:58 pm
Updated BFO Analysis is available here:
https://dl.dropboxusercontent.com/u/32349391/BFO_Analysis_2014-04-26_REV-A.pdf
Changes in REV-A:
1. Added Victor’s Aircraft ROC Doppler
2. Fixed 2 cell reference errors (no material change to results)
3. Fixed some typos
4. Added more annotations
It should be noted that over the calibration period from 16:30 to 17:07 UTC, there are four cases where the BFO Analysis values can be compared to independent “ground truth” (STK analysis applied to Radar and ADS-B data). From what I have heard said publicly, Inmarsat only relied on the 16:30 UTC case to “calibrate” their model. But the other three cases provide much more insight into the performance of the AES TX Offset and residual Offset error.
At 16:30, MH370 was stationary, or moving <2kts. It was authorized to pushback and start at 16:28 and authorized to taxi at 16:32, so it might have been moving slightly at the time of the 16:30 handshake. Assuming MH370 was stationary at the time, the BFO model gives a +1.4 Hz TX Offset Correction and a -4.2 Hz correction error. If it was moving back from Gate C1 at 0.9 kts/140°, the TX Offset Correction = 0.0 Hz. I believe this calibration point provides compelling evidence that the model is accurately calculating the values of D1, D2 and D3, and the D3 (C band) correction is correct.
The second calibration point was at 16:42:43, shortly after takeoff. At that time, MH370 was climbing out on the runway heading (327°, 201 kts, 1725 ft, 450 ft/min). The first turn did not take place until ~30 seconds later, so the Doppler was not affected by a turn at this point. The Total L band Doppler at the time was +204.6 Hz and the AES TX Offset was -250.4 Hz for a residual TX Offset error of -45.8 Hz (it over compensated by 22.4%).
The third calibration point was at 16:54:55, after the first turn was complete, while still climbing (now headed 25°, 452 kts, 26,775 ft, 1380 ft/min). So the Doppler was not affected by turns at this point either. The Total L band Doppler at the time was -390.2 Hz and the AES TX Offset was +305.9 Hz for a residual TX Offset error of -84.3 Hz (it under compensated by 21.6%).
The last calibration point was at 17:07:15, after MH370 had reached cruising altitude, and before it started the second turn (to 40°). At this point, there was no climb or turn in progress. Thus, this is the best case for an assessment of the TX Offset accuracy in a steady-state condition (25°, 469 kts, 35,000 ft, 0 ft/min). The Total L band Doppler at the time was -463.0 Hz and the AES TX Offset was +400.7 Hz for a residual TX Offset error of -62.4 Hz (it under compensated by 13.5%).
This 4 point calibration provides evidence that the BFO values are real and useful. After removing the C band Doppler component, the remainder (D1+D2) can be interpreted as the AES TX Offset residual error. The fact that the error is near zero at Gate C1 means that there are no significant additional bias errors that need to be considered. The fact that the residual error remained in the range of 13.5% to 22.4%, for speeds between 201 and 469 kts, headings toward and away from the satellite, climbing and straight & level, mean that the mechanism and algorithm work reasonably well over a range of conditions. However, the fact that the error is not close to zero also infers that the method is not the “Rockwell system??? that uses an outbound downlink pilot carrier to measure the Doppler. It is more likely that the AES generates the offset from a lookup table and knowledge of the current position, speed, heading, and maybe altitude and ROC. But it is clearly not a high accuracy estimator.
The fact that the AES did not have a high accuracy offset estimation system may be an advantage. If the error is systematic for a given set of conditions (geometry and dynamics), then it may be possible to squeeze a bit more useful information from the BFO values. That is the next step in the investigation.
Meanwhile, Victor and I have been discussing the possibility that the TX Offset algorithm and/or related hardware was somehow disabled or broken sometime after 17:07. The steady increase in the TX Offset residual error, from -111 Hz at 19:40 to -353 Hz at 00:11, is out of spec and inconsistent with the typical correction accuracy (<85 Hz for all 4 calibration cases). If the AES used IRS data to calculate the offset, and the data link was lost (due to an intentional act or fire for example), then the AES might have defaulted to no TX correction, or possibly the last known good value. If the Offset was effectively reset to zero after 17:07, and remained zero for the rest of the flight, then the D1+D2 residual observed will equal the true aircraft to satellite total L band Doppler. This is a scenario worth a careful look in the various path models under discussion.
airlandseaman said,
April 26, 2014 at 3:10 pm
sk999 said,
April 26, 2014 at 9:24 am
Skwosh said,
April 26, 2014 at 10:44 am
I’m pretty sure the Miteq document is related to the pilot tracking system used to compensate for the Local Oscillaror offset in the satellte transponder. It does not have anything to do with inbound L or C band Doppler correction per se. It does provide the information needed by the LES to offset the outbound C band link so that outbound signal leave the L band downlink antenna with no net Uplink Doppler or Transponder LO error.
In summary, this pilot tracking system can be ignored as far as interpretation of the BFO values. It is just eliminates a couple of offsets that effect the entire transponder bandwidth, not individual FDMA channels.
sk999 said,
April 26, 2014 at 5:38 pm
Airlandseaman,
I do not follow your comment. The satellite has two transponder chains – the 6.4 to 1.5 GHz chain for the “uplink” (ground station to satellite to aircraft) and 1.6 to 3.6 GHz chain for the “downlink” (aircraft to satellite to ground.) Each chain has a local oscillator that needs to be calibrated. There are two pilot signals generated to do so – one at C band for the uplink chain, and one at L band for the downlink chain. Both pilot signal mechanisms are described in the document (Figs 5/6 for the uplink, and 7/8 for the downlink.)
There is a terminology problem. In “Inmarsat-speak”, the term “uplink” incorporates both ground to satellite and satellite to aircraft links, even though you and I would normally think of the latter as a downlink. I think your term “outbound” is equivalent to the Inmarsat-speak term “uplink” but you have blurred the terminology regarding up- / down- link.
My reading of the document is that the downlink is equally important as the uplink to Inmarsat. A ground station receives the 3.6 GHz signal and down-converts it to some intermediate frequency (IF) where it is fed to demodulators. Given the large number of channels involved, it would make sense that these demodulators all work at fixed (not tunable) frequencies. All the tuning is done to the ground station’s local oscillator. The tuning is controlled by tracking the L-band pilot. (At least, that’s how I would build the system.) In particular, the C-band Doppler in the satellite-Perth link is common to both the aircraft and to the pilot signals as received at Perth, and the system removes it before the frequency of the aircraft signal is measured.
In summary, I disagree – the (L-band) pilot tracking system cannot be ignored.
airlandseaman said,
April 26, 2014 at 6:21 pm
sk999 said,
April 26, 2014 at 5:38 pm
Regarding the definitions…”Outbound” and “Inbound” link pairs are standard terms used in the mobile satellite service world. The outbound pair uses the 6.4 GHz uplink and 1.5 GHz downlink to the AES. The inbound pair uses the 1.6 GHz uplink and 3.6 GHz downlink to the LES, as you described. Uplinks are always in the earth-to-space direction, and downlinks are always in the space-to-earth direction. I’ll reread a bit of the Miteq paper to see if I can untangle the semantics.
I would be very surprised if the current baseband gear in Perth uses discrete modulators and demodulators. It is far more likely that they are now using direct digital block downconversion from an IF in the VHF range. A single fast ADC samples the entire IF band and feeds the samples to a bank of FPGAs, DSPs or ASICs that do all the filtering and demodulation in the digital domain. They allocate the bandwidth dynamically to many different service types, so the IF is parsed into different FDMA channel bandwidths as needed to serve classic services like Inmarsat A, Inmarsat C while at the same time making it possible to switch a chunk of the band to Swift64 or some newer service as needed.
As for the pilots…I believe you are correct in that there may be two complimentary systems used in the older I3 satellites, one for L to C and one for C to L transponders. (There are also cross-straps for C to C and L to L, but we don’t need to worry about those paths for our work.) But the C and L band Doppler measurements of interest to us are made with the inbound transponder only. Regardless of how the space segment LOs are configured, I’m pretty sure the S/C LO offset and C band Doppler are corrected on the ground at each LES separately because the total offset (Doppler and LO) will be location dependent. Does that help?
seanmcleod said,
April 27, 2014 at 1:39 am
airlandseaman, I tried to visualize possible routes from the 19:40UTC ping arc with and without filtering based on the Doppler data, this was done with your previous LOS speed calculations.
http://mcleodsean.wordpress.com/2014/04/25/mh-370-forward-tracking/
I’ll update it using your latest estimates to see if there is a better match.
Alex Siew said,
April 27, 2014 at 4:35 am
I wish to draw everyone’s attention to the 2 reports by Dr Kuang posted by LGHamiltonUSA on Duncan’s latest post on his blog (April27). Basically Dr Kuang has concluded that the authorities were either negligent or outright lying in suggesting that the unidentified blip at VAMPI or MEKAR was MH370.
I believe Dr Kuang must have forwarded the reports to Duncan even before LGHamiltonUSA posted the reports and this may be the ‘false assumption’ mentioned by Duncan in his latest post.
Some of the points made by Dr Kuang to show that it was not possible for MH370 to have flown such a distance from IGARI to MEKAR in that period of time, had previously been made by the French pilot Alain.
Given this final nail in the coffin for the theory that the unidentified blip was MH370 and given @Victorl’s theory that something had happened to the plane after 1.07am but before the first ping to break the data path between the AIMS and the SATCOM with the suggestion it could be due to a disabling event like fire etc, may i humbly suggest that the latest flightpath modelling based on @airlandseaman and @Victorl’s latest analysis, should not exclude the possibility that the same disabling event might have caused the plane to crash early on and that the BFO values for the 6 pings could be the Doppler effect arising from the movement of the satellite to and from the plane that had crashed somewhere on the final arc at the South China Sea.
GuardedDon said,
April 27, 2014 at 6:26 am
Superimposing the alleged ‘radar trace’ onto a map was a good move, I posted a graphic some time back which showed that track could equally have been UAE343.
“Jim’s” graphical method for approximating a path (from another route deviation point) is a tool I’ll experiment with later. Like Dr Steel, I’m somewhat time starved at the moment.
I would like to suggest a note of caution in using the 3 comms events shown to have occurred just prior to 18:30UTC: I don’t doubt the events happened but they may not have happened when the chart indicates. That caution doesn’t prelude any doppler/BFO data that can be extracted, rather just their place in a timed sequence.
airlandseaman said,
April 27, 2014 at 6:34 am
Alex Siew said,
April 27, 2014 at 4:35 am
Alex: My first inclination was to dismiss your theory as completely inconsistent with the BFO data and analysis. But let’s assume the aircraft did crash (or land) early. If it did, how do we explain the BFO values we have?
First, the C band Doppler can be removed without any speculation about the validity of that part of the analysis because it is in no way dependent on the aircraft. That leaves the D1+D2 values, which are normally the “Residual Offset Error”. Normally, the residual error could be anywhere between 0 and the Total L band Doppler (or a little more), depending on the accuracy of the AES Doppler correction algorithm and hardware. If the AES correction is perfect, then D1+D2=0 (no residual error). If it makes no correction, then D1+D2 = actual Total L band Doppler. But it can’t be more than D2 if the aircraft is not moving, and D2 cannot be more than ~50 Hz no matter where the aircraft was (in the general area). Again, this is all assuming “normal operation???.
Between 19:41 and 00:11, D1+D2 increased steadily from -111 Hz to -353 Hz (the negative sign means movement away from the satellite). That corresponds to a radial velocity between 40-125 kts if there was no TX offset, and a higher radial velocity if there was any offset correction. The aircraft speed would be higher than the radial velocity component, depending on the heading relative to the satellite position. Thus, it would be impossible for the aircraft to have been stationary given these facts and measurements, unless the AES was making totally bogus corrections to the TX frequency, in a smooth systematic way, as observed. So, if you think the aircraft crashed early, I leave it to you to suggest a failure mode that could explain the BFO data we have. The latest BFO graphics are here:
https://dl.dropboxusercontent.com/u/32349391/Inmarsat_BFO_Analysis_2014-04-27.pdf
seanmcleod said,
April 27, 2014 at 7:46 am
Alex Siew
In terms of your hypothesis that the aircraft crashed much earlier on somewhere on the 00:11UTC ping ring and that the last 5 Doppler readings were just the effect of the satellite moving and the aircraft stationary how do you explain the ping ring ranges that have been calculated?
What’s noticeable is that if you do assume the calculated ping ring ranges are fairly accurate then you can see why there is a big gap in the 00:11UTC ping ring arcs that the authorities released early on, see the plots I generated below (the 1st ones without any Doppler filtering).
http://mcleodsean.wordpress.com/2014/04/25/mh-370-forward-tracking
LGHamiltonUSA said,
April 27, 2014 at 9:46 am
During my research I found some interesting information:
http://www.pprune.org/rumours-news/535538-malaysian-airlines-mh370-contact-lost-361.html
¤ PPRUNE p.361 “Malaysian Airlines MH370 Contact Lost”
http://www.pprune.org/rumours-news/535538-malaysian-airlines-mh370-contact-lost-361.html#post8393795
¤ Cue points & data for the 1st 40 minutes of MH370′s flight
http://www.pprune.org/rumours-news/535538-malaysian-airlines-mh370-contact-lost-361.html#post8393809
¤ Eugene’s 3/22 UAE343 comment
http://www.pprune.org/rumours-news/535538-malaysian-airlines-mh370-contact-lost-361.html#post8393916
¤ Skyvector chart at UAE343′s 18:22 position
~LGH~
sk999 said,
April 27, 2014 at 3:50 pm
By taking the difference between the Inmarsat predicted North and South track BFO values, many of the uncertainties in modeling the BFO cancel out (e.g., hypothetical satellite-to-Perth Doppler), and one is sensitive mainly to the errors in the AES AFC system, which presumably Inmarsat has included in its modeling. Here are my predictions for the last five data points on the BFO plot and a comparison with the Inmarsat values. As before I adopt the idea that the AES computes Doppler correction assuming that 3-F1 is stationary over the equator, ignoring the orbital inclination.
A few more details – I calculate the satellite position and velocities straight from the orbital elements (no need for STK, although I used it as a cross-check). I assume a spherical earth. I use vector arithmetic in place of spherical trig. We don’t know the exact timings or flight paths used by Inmarsat other than that they were computed for 450 knots. I assume a starting point computed by GlobusMax of 95.4E, 6.6N at 18:22 UT, which is not entirely consistent with the radar timing and the time of the “possible turn”. The South track has an initial heading (or I supposed more properly “course angle”) of 187 degrees. The North route has an initial heading of 332 degrees. These headings are chosen so that the aircraft arrives at the 40 degree elevation ping circle at 00:11. The South track is close to (but doesn’t quite match) the yellow track on the Inmarsat Google Earth plot.
Here are the results:
19:41 Predction: 74, Measured: 78, Error: -4
20:41 Predction: 56, Measured: 58, Error: -2
21:41 Predction: 23, Measured: 27, Error: -4
22:41 Predction: -18, Measured: -16, Error: -2
24:11 Predction: -79, Measured: -76, Error: -3
The errors are smaller than the size of the square and triangle symbols drawn on the Inmarsat plot. While I don’t think this calculation proves anything, it does show that there is at least one plausible way in which Inmarsat could have distinguished between North from South routes.
hamster3null said,
April 27, 2014 at 4:40 pm
@airlandseaman,
Very interesting analysis.
* Do you have a source that allows you to quote calibration ping times with 1 second precision? I thought all we had was the original chart picture and it was nowhere precise enough. In case of the second calibration ping (during takeoff), being off by 30 seconds can completely change the results.
* As I understand, your result is that the AES Doppler correction mechanism undercompensates twice and overcompensates once in the course of 30 minutes. This is _very_ bad for us. If the residual of the correction mechanism is so random, it means that we can’t say much at all about the course without additional hypotheses.
Alex Siew said,
April 27, 2014 at 4:43 pm
@airlandseaman,
Thank you for your enduring patience in responding to comments from laymen.
I have no answer to why the non mathematical evidence (or the lack thereof) would suggest the plane had crashed early on but the numbers from the BFO chart analysis would show otherwise. For what it’s worth, here are my thoughts.
The statement accompanying the BFO chart says these 3 things (a) the satellite would start pinging the Satcom if it does not hear from the plane after 1 hour (b) the last complete handshake was at 8.11am (c) there were altogether 6 complete handshakes.
Working backwards, the 6 complete handshakes would be 8.11, 6.40, 5.40, 4.40, 3.40 and 2.29am.
The last ACARS transmission was at 1.07am. If everything had been operating normally, the pings would have started at 2.07am and be at regular hourly intervals thereafter 3.07, 4.07. 507 etc.
The abnormal pattern of the complete handshakes, the unexplained transmissions at 2.25 and 2.27am and the below strength signal (said to be faint) all suggest that something had happened prior to the pings and the Satcom was by then not operating normally.
The 2.25 and 2.27 transmissions were likely incomplete handshakes before the successful handshake at 2.29am. I do not think these 2 transmissions were initiated from the plane as such transmissions would not fit into the ‘frequency expected- frequency received’ concept. Notably, the 8.19am transmission, said to have originated from the plane, is not shown on the BFO chart.
What could be the cause of the Satcom not operating normally?
If indeed the plane was hit by a positive lightning strike, there would have been 2 major effects, huge currents rippling through the plane and electromagnetization of the plane’s systems. At the back of my layman’s mind, the electromagnetization in particular could have affected the workings of the Satcom including the frequency compensation mechanism.
@seanmcleod
Inmarsat has not released the data on the RT timings or the locations of the arcs for the first 5 pings, i believe all the ping arcs out there are merely people’s idea of where these arcs should be located.
hamster3null said,
April 27, 2014 at 5:14 pm
@Alex Siew
I don’t recall any authoritative statements that pings _have_to_ be every 1 hour. Protocol specification is available online and all it says that the period between interrogations is “at the discretion of the satellite operator” (maybe not in these words). The satellite commences repeated pinging if it does not hear a response to the interrogation.
The aircraft is required to keep a continuous lock on the satellite and it may attempt to relogin if it observes a loss or degradation of the satellite signal. Something as simple as a sharp turn could temporarily interrupt the connection (same well-known Doppler effect, but in the other direction) and result in a relogin.
Alex Siew said,
April 27, 2014 at 7:37 pm
@hamster3null
The following are extracts from the statement issued by the investigation team on March 25,2014 (Malaysian time) accompanying the BFO chart, entitled “Information provided to MH370 Investigation By UK Air Accidents Investigation Branch (AAIB) 25/03/2014″:
“…If the ground station has not heard from an aircraft for an hour it will transmit a ‘log on/ log off’ message, sometimes referred to as a ‘ping’, using the aircraft’s unique identifier. If the aircraft receives its unique identifier it returns a short message indicating that it is still logged on. This process has been described as a ‘handshake’ and takes place automatically……..
“…From the ground station it was established that after ACARS stopped sending messages, 6 complete handshakes took place……”
“…The analysis showed……….. and depending on the ground speed of the aircraft it was then possible to estimate positions at 0011 UTC at which the last complete handshake took place…..”
So, according to the statement, the satellite would start pinging automatically after not having heard from the aircraft for an hour, there were 6 complete handshakes and the last one was at 0011 UTC or 8.11am malaysian time.
However, it is not clear if the satellite would in fact start pinging on the dot. The statement goes on to say “…No response was received from the aircraft at 0115 UTC when the [GES] sent the next log on/ log off message. This indicates that the aircraft was no longer logged on to the network….”.
If the last complete handshake was at 8.11am by right the next ping would be sent on 9.11am or 0111 UTC, not 0115 UTC. However, there was a complicating factor in that there was another unexplained transmission at 8.19am, said to have been initiated from the aircraft. If we add up 8.11 and 8.19 and divide by 2, we get 8.15 so maybe the satellite did the same math.
Inmarsat has not said anything about the 2.25 or 2.27am transmissions being ‘relogin’ resulting from ‘loss of connection’. However, a turn whether or not it resulted in a ‘loss of connection’, should not result in a handshake which as the statement above makes clear, is something initiated from the satellite end at fixed hourly intervals.
airlandseaman said,
April 27, 2014 at 8:41 pm
hamster3null said,
April 27, 2014 at 4:40 pm
The times in the BFO Analysis spreadsheet are not accurate to 1 second, but they are better than 1 minute for the first 4 points because they came from a combination of radar and ADS-B sources, not the BFO chart. Accuracy of the BFO times is probably more like 1minute, and the BFO values are ~1-2 Hz.
There were 5 radar records between 16:42 and 16:43 and 4 more between 16:43 and 16:44, so . I matched speed and headings from the radar and ADS-B to sync the two sources. I estimate the times accurate to ~10 seconds. The first turn started around the time of the second radar record time stamped 16:43.
http://planefinder.net/flight/MAS370/time/2014-03-07T16:50:00
airlandseaman said,
April 27, 2014 at 8:53 pm
sk999 said,
April 27, 2014 at 3:50 pm
Regarding the following:
Here are the results:
19:41 Predction: 74, Measured: 78, Error: -4
20:41 Predction: 56, Measured: 58, Error: -2
21:41 Predction: 23, Measured: 27, Error: -4
22:41 Predction: -18, Measured: -16, Error: -2
24:11 Predction: -79, Measured: -76, Error: -3
Please explain what is predicted and measured here. What are the varibles and units?
Alex Siew said,
April 27, 2014 at 10:10 pm
@hamster3null, the following extracts from the Honeywell/Thales’s manual for the MCS 4200/7200 satcom system may be useful in considering whether there would be a ‘relogin’ in the event of loss of connection.
” …A. (2) An AES logs onto a GES to enter the satellite communications system and logs off to terminate its operation i the system. Log off is initiated automatically or by a user command issued as part of normal operational procedures. (3) The AES also logs off before initiating handover. The AES does not log off if handover is initiated because of degradation or loss of the P-channel…….A handover procedure is followed automatically when an AES needs to change the log-on GES or to access a different satellite…….F. (1) Log off is initiated in the AES by a user command, either from the SCDU, from the analog connected telephone handset, or from the CMT. Log off is also initiated by the SDU as part of the handover sequence, except for handovers implemented because of P-channel degradation.”
From the above, it would appear the AES would not log off due to a temporary loss of connection so the issue of having to re-log-in may not arise.
@airlandseaman,
Another extract from the manual “…(10) Each AES maintains a system table stored in nonvolatile memory in the SDU. The system table contains the data EIRP table, the satellite and GES identifying information, such as satellite Psid-channel frequencies, satellite locations and associated GES IDs, GES capabilities, and GES Psms-channel frequencies. The system table does not lose its contents because of loss of primary power (11) The SDU also maintains a bootstrap system containing a default set of satellite and GES identifying information. This information includes satellite Psid-channel frequencies, satellite location and associated GES IDs, plus satellite inclination and right ascension, spot beam support and GES Psms-channel frequencies that are set to zero. (12) The bootstrap system table is loaded into the SDU as an inseparable part of the upload of executable software. The SDU defaults to the bootstrap system table in the absence of a stored system table or upon execution of a factory settings restart. The default data for a satellite is used until that satellite is first accessed. Then a complete update of the data for that satellite happens…….”
I do not know if the foregoing extract is useful but am posting it just in case it is.
hamster3null said,
April 27, 2014 at 10:50 pm
@Alex Siew
I see. Notice that the article mentions 6 handshakes “after ACARS stopped sending messages”, but there are actually 8 points in that period of time in the accompanying chart. Three packets close to each other at 18:27-18:29 could be consistent with a relogin (this would involve a few packets going back and forth – logon request, logon acknowledgement, possibly something else). Any of them could be used to compute Doppler shift. The article is not being all that pedantical, anyway (it describes interactions as “handshakes” or, at one point, as a “log on / log off message”, when the correct word should be “interrogation”) – it may be glossing over some minor details like an hour not always being an hour or one of the handshakes being a full-fledged relogin.
The absence of a handshake at 23:41 is another sign that the satellite is not doing the pinging precisely every hour. If it tried to reach MH370 at 23:41 and got no response, it would knock its entry out of the table and it would not try again at 00:11.
Re: the satcom system manual, I read this simply to mean that the AES does not send a log-off message before trying to relogin due to P channel loss.
4.9.3.3.4 PROCEDURES AFTER LOG-ON
4.9.3.3.4.1 The AES management shall attempt to log-off before terminating communication with the log-on GES.
Note.— Loss or degradation of the P channel precludes any log-off attempt (4.9.3.3.4.4 refers).
(…)
4.9.3.3.4.4 The AES management shall respond to the indications relayed to it via the AES physical layer interface as follows:
Pd channel loss/degradation indication: the AES management shall either attempt to (1) reacquire an adequate signal level on the same Pd channel and resume normal operation, or (2) renew its log-on to the same GES by re-initiating the log-on procedure to the same GES, or (3) re-initiate the satellite, beam and GES selection and the log-on process as specified in 4.9.3.3.2 and 4.9.3.3.3 respectively.
Alex Siew said,
April 27, 2014 at 11:53 pm
@hamster3null
I think it is difficult to read too much into the Doppler shift for the 2 unexplained transmissions at 2.25 and 2.27, simply because we dont know what they are and what their BFOs represent. We know what the 6 complete handshakes are and what their BFOS represent ( frequency expected versus frequency received of the ‘i am here signal’ from the plane). Those 2 unexplained transmissions could have been garbled or incomplete signals leading to higher than expected BFOs.
Regarding the lack of a handshake at 7.40, my guess is the satellite started pinging at such time and continued to do so until the satcom finally summoned enough power to respond at 8.11am. That would fit the theory that the SDU’s battery was by then on its last legs, with the battery running out soon thereafter triggering the 8.19am transmission. (Please see my previous comments in this blog or as reposted by LGHamiltonUSA in her twitter account on April 18 as the MH370 Lightning Theory).
airlandseaman said,
April 28, 2014 at 12:24 am
Alex Siew
The information in the Honeywell/Thales’s manual for the MCS 4200/7200 satcom system is interesting, but what evidence do we have that this is the equipment in use on MH370?
seanmcleod said,
April 28, 2014 at 1:33 am
@Alex Siew
In terms of the ping rings yes as I mentioned they’ve been ‘calculated’. By others based on tracks released by the authorities as opposed to the authorities releasing the actual ping data (range or elevation angle).
Now if the aircraft was stationary on the 00:11UTC ping arc as you suggest then the difference in ping ring range for the last 5 or 6 pings would match exactly the difference in motion of the satellite between pings. Don’t you think Inmarsat would’ve noticed this?
Alex Siew said,
April 28, 2014 at 1:55 am
@seanmcleod,
Good question but we dont know what Inmarsat might have overlooked in their rush to come out with their northern-southern arc analysis. As i have said since day one, Inmarsat can prove me wrong by releasing the data on the RT timings or the arcs for the first 5 pings.
Also the movement of the satellite was apparently not foremost in their minds when they came out with their original analysis, otherwise it wouldnt have taken them 2 full weeks to come out with the ‘groundbreaking yet tradition based’ Doppler analysis.
Why do u think they are refusing to release the data on the RT timings and the first 5 arcs, with no sign of the plane after 7 weeks?
Alex Siew said,
April 28, 2014 at 2:13 am
@airlandseaman,
Unfortunately i do not have any information on the exact model of the SDU on board MH370. There was a press release by Honeywell in March 2009 (about upgrading to Swift 64) containing a statement that Malaysia Airlines Boeing 777 aircraft “are already outfitted with Honeywell’s SATCOM communication systems…” and MAS issued a statement some days after the plane went missing that MH370 was using classic Aero H.
The older Honeywell’s SDUs would be the MCS 3000/4000/6000/7000 series. The manual for MCS 4200/7200 which i quoted from describes the MCS 4200/7200 series as “an augmented version” of the MCS 4000/7000 series. The SDU for MCS 4200/7200 has an internal battery as i have pointed out in previous comments.
Those older series apparently can be upgraded by adding a high speed data unit, the HD710 which functions as both a high power amplifier and a high speed data unit, meaning the existing SDU remains.
Alex Siew said,
April 28, 2014 at 2:45 am
@airlandseaman,
More extracts from the Honeywell manual.
” For the LRUs, the software upload is a single pass process……..When successfully validated, the LRU causes the data loader to initiate the transfer complete function and the LRU remains in data load state, while the Link A connection remains intact. When the Link A connection is removed, the HPA performs a POST and the SDU performs a factory settings restart. A factory settings restart results in category C nonvolatile data being set to default values followed by execution of POST/PAST”
” The [Owners Requirements Table] is stored in nonvolatile memory in the SDU. The ORT contains information relating to different areas of functionality like log-on and telephony. The ORT does not lose its contents because of the loss of SDU primary power or as a result of PAST. All ORT contents are set to default values by a factory settings restart…”
seanmcleod said,
April 28, 2014 at 2:47 am
@Alex Siew, they’ve been willing to move the search area a massive amount after further analysis, so you don’t think that even if it took them a couple of weeks to notice a coincidence like the ping ring ranges match a stationary point on the 00:11UTC arc based solely on the satellite’s movement they wouldn’t have checked it out?
Also for the stationary position on the 00:11UTC arc for 5-6 hours all of the following would have to be red herrings:
- Malaysian radar showing an aircraft heading west over the Malay peninsula.
- Thai radar also showing aircraft heading west over the Malay peninsula.
- Malaysian radar showing aircraft heading north-west after crossing the Malaysian peninsula.
- First officer’s cell phone attempting to connect to a cell tower.
Also for your hypothesis you’re suggesting the aircraft crashing in the sea but enough of the satcom equipment staying out of the water to transmit for another 5-6 hours but the ELTs not going off.
-
sk999 said,
April 28, 2014 at 3:49 am
airlandseaman,
Sorry – should have been more clear. The units are hz. The “measured” points are the “Predicted North Track” (red line and points) minus the “Predicted South Track” values (green line and points) taken off the BFO diagram. The “predicted” points are what my model predicts for that quantity.
Alex Siew said,
April 28, 2014 at 4:21 am
@seanmcleod
Sean, I have covered most of what u have raised in my previous comments, see for eg april 17 at 5.20 and 8.33am. As for the cell phone story, it has been officially refuted. I do not know where the ELTs on MH370 were located, it is moot now since their batteries would have expired.
Please do note that both Dr Kuang and it seems Duncan have given up on the theory that the blip at MEKAR was MH370. Dr Kuang’s analysis has been reposted by LGHamiltonUSA in Duncan’s latest post.
andyhull said,
April 28, 2014 at 5:31 am
Is anybody aware of any analysis of seismic events off the west coast of Australia in the approximate time window when we suspect the plane went down?
I know there was initial speculation about seismic events in the area of the last routine contact with ATC, but I have not heard anything regarding analysis for the time window we now suspect the aircraft may have hit the ocean in.
airlandseaman said,
April 28, 2014 at 6:02 am
Can anyone provide links or references to hard data on the specific Inmarsat equipment used on 9M-MRO? I have read several posts on the subject, but all were speculative in nature. It is important to establish as much knowledge as possible on the following questions:
1. Specific ype of service subscribed?
2. Type and number of antenna(s) installed? Did it have only one omni, an omni and a high gain, top mounted mechanically steered, dual side mounted conformal electrically steered, …?
3. Make and models?
seanmcleod said,
April 28, 2014 at 7:59 am
@Alex Siew
You’ve asked numerous times here and on Duncan’s blog for someone to analyze the BFO data and report back whether their interpretation of the BFO data allows for the possibility that the aircraft was stationary for the last 5-6 pings and I’ve seen at least 3 replies from 3 different people saying that it doesn’t.
Not sure what the battery life of the ELTs have to do with anything. Maybe I wasn’t clear enough on the ELTs and your hypothesis.
The ELT has an accelerometer inside it and when it detects an abnormal acceleration it then transmits a signal to be picked up by orbiting satellites to indicate a crash.
Now they’re not foolproof, e.g. they didn’t go off in AF447, the main issue being that with a crash into the ocean the antenna of the ELT can be submerged before the first signal to the satellites is transmitted, saw a reference to it potentially being on the order of 50s.
So my point was that for your hypothesis to hold the crash into the ocean would’ve had to have been such that the satcom antenna, electronics and power supply were left floating and dry enough for 5-6hrs but that the ELTs would’ve had to have been submerged within 50s.
Do you have a link to the first officer’s cell phone trying to contact a cell tower (not that he tried to make a call) being officially refuted?
seanmcleod said,
April 28, 2014 at 8:32 am
@Alex Shiew
In terms of Dr Kuang’s post on the radar trace have you taken a look at it?
My reading of it via Google Translate is roughly along the lines of:
That the final radar point 295R 200nm at 02:22 from Butterworth AB is really 250nm based on overlaying it on Google Maps, I haven’t double-checked this.
He assumes/checks that the 279R 89nm at 02:02 is accurate.
So he works out an increased distance between those 2 points to be 312km and then assumes a round 20 minutes (02:02 – 02:22) and therefore an average ground speed of 936km/h.
He then claims a ‘usually fastest speed’ for the 777-200 as 905km/h.
So based on this difference of 31km/h (roughly 3.4% difference) he casts into doubt the Malaysian’s radar data as presented.
How about some sanity checks on the resolution of some of the data presented? Let’s assume that the 312km calculated by Dr Kuang is correct, but what is the resolution of the timestamps provided in the radar image? Is it exactly a 20 minute difference? No seconds were displayed.
In the extreme case say it was really 02:02:00 and 02:22:59, so let’s round it to an extra 1 minute, then the average speed for 312km covered in 21mins is only 891km/h, below the maximum speed of 905km/h quoted by Dr Kuang.
At 20mins 30sec then you end up at 914km/hr.
Now let’s look at the ‘usually fastest speed’ quote of 905km/hr.
Take a look at: – http://en.wikipedia.org/wiki/Boeing_777
Typical cruise speed – Mach 0.84 – 905km/h
Max speed – Mach 0.89 – 950km/h
Now if there was a tailwind component the ground speeds would be even higher than those quoted on Wikipedia.
So based on that I really wouldn’t go round writing off the Malaysian radar data!
airlandseaman said,
April 28, 2014 at 9:04 am
Regarding:
sk999 said,
April 26, 2014 at 5:38 pm
sk999: I re-read the Miteq Tech Note 25T020 as promised, and confirmed my understanding of how the Miteq pilot receivers work. Of course, it is unknown if either of these Miteq pilot receivers are in use at Perth. That said, both of the pilot tracking receivers (AFC and EAFC versions) described do essentially the same thing, but in slightly different ways.
I can certainly understand your confusion with the ambiguous terminology. All of the references to “uplink” and “downlink” should be read as “C band uplink” and “C band downlink”, or equivalently, “outbound uplink” and “inbound downlink”.
Both the AFC and EAFC “Uplink Pilot Systems??? described in Fig. 5 and Fig. 6 correct for outbound uplink Doppler and outbound transponder LO offset. This ensures that all communications carriers transmitted from the Secondary LES are offset so as to be transmitted from the spacecraft L band antenna with zero carrier frequency error.
Both the AFC and EAFC “Downlink Pilot Systems??? described in Fig. 7 and Fig. 8 correct for inbound downlink Doppler (D3) and inbound transponder LO offset. The output of these receivers go to the individual channel demodulators.
From the BFO data analysis, it is pretty certain that the BFO values are sampled after correction for the inbound transponder LO Offset, but before the C band Doppler correction. Indeed, that is exactly how the ANNEX I defines the terms. There has been some confusion about what is included in D1 and D2, but it has always been clear that D3 was the C band Doppler. This suggests that the Perth LES is not using either of these specific Miteq pilot receivers, or if they are using one of them, they are being used only to drive the demodulators, and not involved in the BFO measurements.
As noted previously, given that Inmarsat is now offering many more service options, involving a wide range of FDMA channel bandwidths, using far more sophisticated multi-beam satellites, it is unlikely that they are still using any discrete single channel demodulators or inbound analog pilot tracking systems. For over a decade, that approach has been obsolete. Given the evolution of fast ADCs, FPGAs and DSP technology, it is more likely that the entire C band downlink band (assumed to be 3600-3629 GHz on the I3 satellite) is block down-converted to an IF in the VHF range and digitized with a single fast ADC. From there, all the FDMA channel filtering, TDMA channel parsing, pilot tracking, demodulation and decoding takes place in the digital domain. I think this assumption is more consistent with the BFO definition and observations since we know that the BFO values are sampled after the inbound LO correction, but before the C band Doppler correction.
Bottom line: I do not see anything in the Miteq Receiver brochure or Tech Note that changes anything in my analysis of the BFO data or conclusions.
GuardedDon said,
April 28, 2014 at 3:14 pm
@airlandseaman
I guess its mostly my posts you’ve read about the satcom install on 9M-MRO.
1) the AIMS-2 upgrade used a Honeywell SDU, I’m assuming the fleet had the AIMS-2 upgrade.
2) 9M-MRQ has a HGA on the upper fuselage aft of the two ADS antenna but 9M-MRO (and other MH B777s show what looks like a LGA – sharkfin).
3) MH definitely a SITA customer, Classic Aero services, Switft64 possibly (anything more would have required service from I4).
@seanmcleod et al
This possibly does refute the RMAF/TUDM MoTM released radar data. I took the pretty picture that was shown to the MH370 relatives in Beijing purporting that a fuzzy green element in the image was the radar return from MH370. I scaled and sheared that image to fit a snapshot of waypoints, paths & coastline at Skyector, then I took the FR24 log of UAE343 and composited that with the other two images. I maintained some transparency to confirm the alignment. That final composite was imported as an overlay to Google Earth. See http://i.imgur.com/NHbLF46
MH370 and UAE343 could not have been in the same place at the same time. The excursion around Sumatra has never been credible to me. A diversion to the south from just beyond IGARI is much more credible, with the intent to intercept an approach vector to Terrenganu that was never completed & hence a continued path south/west of south.
There have been so many inconsistencies in MoTM’s presentations since 8th March (aside from media ‘stories’ about cellphones, etc). I dread to think what they’ve presented to ICAO as a the first interim report & yet only last week the establishment of an International Investigation Team was announced. Did they not realise it was their responsibility to set up the Investigation Team on 8th March and they could ask anyone to help?
airlandseaman said,
April 28, 2014 at 3:57 pm
GuardedDon:
Please contact me via email. I would like to discuss the equipment offline.
Thanks,
airlandseaman@earthlink.net
Alex Siew said,
April 28, 2014 at 4:46 pm
@airlandseaman,
Malaysia Airlines issued a statement a few days after the plane went missing that MH370 was using Classic Aero H. (when the story broke about them saving $10 in not upgrading to Swift)
The SDU is almost certainly from Honeywell, see my previous comments. The Immarsat 101 slides on the net have a good summary of the SDUs made by Honeywell AND the associated antennas and how different antennas are mounted.
One of these antennas being used with Honeywell’s SDUs, by Omnipless HGA 6000 is tail mounted under the ‘radome’. Lastly i believe some planes have both a low gain and a high gain antenna, the low gain is usually like a shark fin. The high gain is usually like a paddle mounted on the upper rear fuselage but it could also be something else like the HGA 6000 mounted at the tail.
Alex Siew said,
April 28, 2014 at 6:48 pm
@airlandseaman,
You said ” D2 cannot be more than -50Hz no matter where the aircraft was (in the general area)…. assuming ‘normal operation’…”.
Can i ask a favour, can u let me have the values for D2 for the 6 pings assuming the aircraft was in the general area ( say off IGARI), when u have a spare moment. Thank you.
Skwosh said,
April 28, 2014 at 6:53 pm
@sk999 I’ve tried out some of the other ground station locations. As I guess you suspected they don’t generate a sufficiently large term at the L-band frequency (and there is an interesting asymmetry – the component due to the sat’s vertical motion – which is quite significant – is obviously the *same* for both the north and south stations – in the case of the south stations, during the end period of the flight, the Doppler shift due to the vertical motion (positive as the sat is descending) has the same sign as the shift induced by the tangential motion, but for the northern stations the tangential component is in the opposite direction so the overall magnitude of the shift is reduced). This is not to say that there may be no Doppler component at the L-band coming in from the pilot compensation system somewhere though – still a very interesting idea.
Also – now I’ve got everything coded up – and given the talk above about the north/south asymmetry I’ve started working on an ‘explainer’ document – trying to think of a way to more easily ‘visualise’ the ideas about the compensation mechanism. It may never get beyond ‘draft’ stage as my time is a bit all over the place – anyhow – if you’re interested there should be a provisional version here: https://onedrive.live.com/redir?resid=B265D7D2A4682D36!143&authkey=!AEq_LyLwFfro2hU&ithint=file%2c.pdf
airlandseaman said,
April 28, 2014 at 7:54 pm
Alex Siew:
No one knows the D2 Doppler for any of the times, except the first four, because thet are the only ones for which we know the location. D1, D2 and D3 for these times are as follows (from ground truth, not BFO data)
UTC (HH:MM:SS) Lat (North) Lon (East) D1=AES Induced L band LOS Doppler (including ROC) D2 = S/C Induced L band LOS Doppler (Hz) D3 S/C Induced C band Doppler (Hz)
16:30:00 2.7467 101.7133 0.0 -5.7 -83.6
16:42:43 2.813 101.680 210.1 -5.4 -79.1
16:54:55 3.932 102.162 -386.0 -4.2 -74.4
17:07:15 5.419 102.864 -460.3 -2.7 -70.2
As you can see, D2 is very small because the aircraft was nearly due east. But it never gets above 38 Hz even if the observer was at Perth.
Alex Siew said,
April 28, 2014 at 9:10 pm
@airlandseaman,
Thank you very much for your reply. Would u have the numbers for D2 for the 6 ping times assuming the plane was stationary at those times at waypoint IGARI? Only when u have a spare moment. Thank you. ( I am trying to figure out whether the SDU went into some sort of default TX Offset or last used TX Offset after 1.07am, if that makes any sense).
richardc10 said,
April 29, 2014 at 12:35 am
Inmarsat ping-arc data released today via the Malaysian authorities
https://twitter.com/IvanCNN/status/460977558168043520/photo/1
Gash first fit to the data is shown in figure 1 using a great circle at constant speed, fitting the course and start point. No surprise perhaps, the course heads straight for the original search area, so that _was_ defined by the ping data. It’s an excellent fit, with the last point only a bit wobbly, an error of 0.6degrees. The other fitted points are have errors around 0.1degree.
However, it is completely inconsistent with the ping-BFO data by the model discussed earlier. So we are in bendy-course territory which as mentioned cannot be distinguished by the ping-arc (elevation data).
Figure 1: Best fit to the Inmarsat ping-arc data.
http://s1311.photobucket.com/user/RichardC10/media/map_zps008b98dd.jpg.html
seanmcleod said,
April 29, 2014 at 1:54 am
@Alex Siew
Assuming this is legitimate the authorities have released/shared the ping elevation data. Can you see any way for this to match a stationary aircraft in the South China sea?
http://www.duncansteel.com/archives/743
The figures aren’t that far off for each ping ring radius that GlobusMax calculated from the previously released 400, 450kt possible tracks that the authorities released when they released the BFO data.
GuardedDon said,
April 29, 2014 at 2:19 am
Great to see MoTM investigating team release some coherent information. I can stop questioning the course around Sumatra for an OR solution directly N/S from Gulf of Thailand.
The information also fills out the chronology, there was previously unreported datalink activity between 22:40 and 00:11UTC – a satcom voice call attempt to the a/c: if MoTM would publish elevation/RTT/BFO telemetry for that it’d be useful to plot.
richardc10 said,
April 29, 2014 at 2:26 am
Not sure this comment makes statistical sense yet, but the error on the last ping puts the aircraft position behind (North of) the constant speed model, so it was slower in the last segment (22:41 to 00:11). I am going to hazard a guess that the fuel had already been exhausted at 00:11 and the speed was reducing, with the crash a few minutes later at 00:19.
Alex Siew said,
April 29, 2014 at 2:43 am
@seanmcleod,
Sean, i very much doubt the investigation team would release such critical information like the elevation angles for the first 5 pings, in such manner. Perhaps a bit of caution is in order until the authorities make an official statement? And even if they make it official, dont u think we should see the raw data first? These are the same people who prepared that military radar composite after all.
richardc10 said,
April 29, 2014 at 3:08 am
It was released at a briefing this morning, the slide presumably snapped by the CNN reporter. It’s legit.
http://edition.cnn.com/2014/04/29/world/asia/missing-plane-recordings/index.html?hpt=hp_t1
airlandseaman said,
April 29, 2014 at 3:55 am
Has anyone “successfully” digitized the CNN photo?
This photo is still far from raw data. It is nothing more than evidence that they have raw data, which we already new. Moreover, angles are the result of processing raw data and therefore contain hidden, embedded assumptions. Angles are not DATA! We need the raw time delays or computed ranges (which only assume the speed of light to some error). Angles contain all kinds of geometric assumptions that just fuz up the data.
Alex Siew said,
April 29, 2014 at 4:25 am
@airlandseaman,
I have done some layman calculations about D2 for the 6 ping times and came out with -9, -7, -9, -11, -13 and -16Hz (all approximations). Can i ask u if these numbers are correct and if not, can u let me have the correct numbers, so sorry to impose on u.
My formula is simple. When the plane was stationary at KL, D2= -5.75 Hz when the BFO was around 89 Hz, so BFO is roughly a 15.4 multiple of D2. If the plane had crashed off IGARI ie the plane had become stationary again, the same formula should also apply (ignoring the change of location). So if round numbers are used for the BFOs ie 140,110,140,170, 200 and 250 and the same formula is applied, D2 would be roughly the numbers stated above.
I apologize in advance if the foregoing is just rubbish. I should have studied mathematics like Sean.
seanmcleod said,
April 29, 2014 at 4:29 am
Duncan has digitized the CNN photo.
http://www.duncansteel.com/archives/743
As mentioned above the figures aren’t that different compared to the figures that GlobusMax calculated.
seanmcleod said,
April 29, 2014 at 4:46 am
@Alex Siew
If you have so little trust in the data released then why even assume that in your hypothesis with the aircraft crashing in the South China sea that it needs to match the 00:11UTC ping arc?
There was no “raw” data released for the 00:11UTC ping arc, simply a map with arcs drawn over a 40 degree elevation angle and a statement that it was 40 degrees.
In the same vein all the “raw data” for the BFO data hasn’t been released either but you’re trying to match it to your hypothesis.
In my blog post, I provided a link to the source code for my program that I used to generate possible flight tracks and to compute the LOS speed between the satellite and the aircraft.
Why don’t you take it and generate a bunch of points on the 00:11UTC ping arc in the South China sea and then for each point which is stationary in your model then calculate the LOS speed between it and the satellite for each of the last 5-6 pings and then see how those LOS speeds map to the BFO data?
http://mcleodsean.wordpress.com/2014/04/25/mh-370-forward-tracking/
airlandseaman said,
April 29, 2014 at 5:01 am
Alex Siew said,
April 29, 2014 at 4:25 am
regarding: “BFO was around 89 Hz, so BFO is roughly a 15.4 multiple of D2. ”
Sorry, but there is no such simple relationship between BFO values and the D2 values.
seanmcleod said,
April 29, 2014 at 5:19 am
Up until today both the ping ring radii and the BFO data were derived with some uncertainties in both.
Now with the elevation data released by Inmarsat today in theory the level of uncertainty for the ping ring radii should be less.
So far no one has been able to come up with a ‘good’ match using the combination of ping radii and BFO data.
I’ve been trying to visualize the level of mismatch:
http://mcleodsean.wordpress.com/2014/04/25/mh-370-forward-tracking/
So for example in the above blog post from a couple of days ago using the GlobusMax ping radii and the early BFO LOS speeds from Mike Exner and Duncan you’ll see that with an allowance of a 4% error on the ping radii the only way to get a match combining ping radii and BFO data was to relax the error margin to 50% for the BFO data with an assumed ground speed of 350kts. Which obviously isn’t a very good match, and it got worse for higher speeds.
Now using the Inmarsat ping radii from Duncan’s blog post today and using the following BFO LOS speed data which I got out of the comments from Duncan’s blog post – http://www.duncansteel.com/archives/730#comment-2915 In which Mike mentions that Rob Matson’s BFO data matches his and Victor’s to within 10%.
The plot for 350kt now matches a combination of the ping radii and the BFO LOS speeds with the error margin on the BOF data reduced to 15% from the previous 50%.
Plot Assumptions:
Constant ground speed – 350kt
Constant ground track (iterate over 0-359 in 1 degree increments for each starting point on 19:40UTC ping arc)
Ping radii from Inmarsat and Duncan’s digitization today
Updated BFO LOS speeds as above
4% error margin for ping radii
16% error margin for BFO LOS speed
http://mcleodsean.files.wordpress.com/2014/04/mh370-forwardtrack2-350kt-doppler-filter-16.png
GuardedDon said,
April 29, 2014 at 5:59 am
Sean
See this img ( http://imgur.com/0PfZiD3 ) for visualisation of where that is & AMSA’s searched area.
Orange lines – Duncan’s update today (29th)
Pink line – fuel endurance
Image overlay – JACC on 26th
airlandseaman said,
April 29, 2014 at 6:11 am
seanmcleod said,
April 29, 2014 at 5:19 am
Sean: I hope you are aware that the most recent BFO analysis…once again available here:
https://dl.dropboxusercontent.com/u/32349391/Inmarsat_BFO_Analysis_2014-04-27.pdf
…indicates that the BFO values do NOT provide the true Doppler (or radial speed) values we hoped in the beginning.
After tracking down ground truth data from the ADS-B and Radar sources for the first four times (16:30 to 17:07 UTC), and comparing the Doppler values from this ground truth to the values derived from the BFO data, it is clear that the BFO-D3 = (D1+D2) values are the residual error left over after the AES offsets the TX frequncy by an amount estimated by the AES to exactly cancel the (D1+D2) Doppler. The estimates are fairly good, cancelling all but 13-22% during the 4 cases used in the calibration period. But that means the BFO values can not tell us what the Aircraft radial velocity was, unless the AES Offset was for some reason set to zero. It clearly was not zero durring the calibration data set, and we have no concrete data to tell us what the offsets were or the offset errors were for times 5-12. If Inmarsat ever releases the complete data they have available, perhaps we will learn that the Offset Values were in fact sent to the LES, in which case, it will be possible to reconstruct the aircraft Doppler. But we can not do that with the BFO values we have today.
seanmcleod said,
April 29, 2014 at 6:20 am
@airlandseaman
Thanks, I hadn’t noticed that, I had seen your earlier analysis where you did produce LOS speeds and in the comment I referenced I saw you commenting on Rob Matson’s figures which did include LOS speeds with your comment that your figures in terms of BFO Hz were within 10% of each other.
So I assumed that the LOS speeds listed by Rob Matson were a fairly good match for your latest calculations.
airlandseaman said,
April 29, 2014 at 6:54 am
Sean:
The D1+D2 values agree, but they are not Doppler, and they can’t be converted to speed.
Duncan’s 2014-04-29 digitized PING data converted to chart form is here:
https://dl.dropboxusercontent.com/u/32349391/Pings_2014-04-29.JPG
seanmcleod said,
April 29, 2014 at 7:03 am
@airlandseaman
How was Rob Matson calculating LOS speeds and D1+D2 figures that agree with your D1+D2 figures?
seanmcleod said,
April 29, 2014 at 9:25 am
@airlandseaman
Okay so if you want derive LOS speeds for the last 5 pings then you have to make an assumption on TX offset used at the time?
Or an upper and lower bound to give a range for each one to work with.
Skwosh said,
April 29, 2014 at 10:46 am
@richardc10 Yes – agreed – potentially bendy course territory. Am now pondering coding some sort of horrendous dynamic combined BFO and ping-ring course fitting thing.
seanmcleod said,
April 29, 2014 at 1:10 pm
@airlandseaman
Can you publish the aircraft position (Px,Py,Pz) and velocity (Vx,Vy,Vz) that you and Victor used for the 4 calibration points?
Given the satellite position and velocity data that Duncan has published I’d like to confirm the LOS speeds for the 4 calibration points compared to the figures you published for the total L band Doppler for these calibration points.
I seem to remember people wondering whether the AES TX offset was calculated based on the assumption/simplification that the satellite was truly geostationary.
With the aircraft position/velocity for each calibration point I’d like to work out what the LOS speed would be to an assumed geostationary point. Have you done this calculation already, and if so what were your results?
Thanks
richardc10 said,
April 29, 2014 at 1:20 pm
@Skwosh
I’ve being doing that tonight. Glad that it wasn’t the real thing – change a fitting constraint, the P-3Cs fly North, change an error estimate, the P-3Cs fly South. Will post tomorrow when I have another look at it.
andyhull said,
April 29, 2014 at 2:29 pm
To answer my own earlier question.. Yes, there is seismic data for the time frame and area..
http://www.ga.gov.au/earthquakes/seismicSearch.do?isRefine=true
I suggest it might be worth looking at the data from the Christmas Island stations.
andyhull said,
April 29, 2014 at 2:30 pm
This…. might be of interest…
http://seis-pub.ga.gov.au/dbheli/dbheli2png.cgi?sta=XMIS&chan=BHZ&time=2014-03-08+00%3a00%3a00&period=3600&lines=2&scale=auto&filter=BW+0.8+5+5.0+5&
airlandseaman said,
April 29, 2014 at 2:44 pm
Ground Truth for the first 4 times is here:
https://dl.dropboxusercontent.com/u/32349391/BFO_Ground_Truth.xlsx
andyhull said,
April 29, 2014 at 3:04 pm
Just to put my previous comments in context, here is
CHRISTMAS ISLAND, AUSTRALIA
Vertical
Waveform for period: 07/03/2014 22:10:00 – 08/03/2014 05:00:00
http://seis-pub.ga.gov.au/dbheli/dbheli2png.cgi?sta=XMIS&chan=BHZ&time=2014-03-07+22%3a10%3a00&period=3600&lines=7&scale=auto&filter=none&
I think this may be significant, but I am no seismic expert.
Alex Siew said,
April 29, 2014 at 3:27 pm
@airlandseaman,
Hope u and @GuardedDon can track down the model of the SDU and find out how it works in the situation where there is no info from AIMS. This is my guess as to how it might work.
BFO=D3+D2+D1
If data from AIMS is not forthcoming (and assuming the plane had crashed), the SDU wont know its location and heading but may be able to deduce speed = 0 (because there is no change of speed being fed to it or for some other reason)
If speed is 0, D1=0
To calculate D2 the SDU needs its position and heading but since it does not have the info, it assumes maximum doppler from the satellite (directly below satellite?), so the velocity of the satellite from its memory is taken to be the doppler (no need cosine angle etc).
To calculate D3, the SDU takes the value of D3 from its memory when speed = 0 which for this trip was approximately 90 at KL.
So for the first and last pings as examples and rounding numbers to the closest 10:
BFO (140) = D3 (90) + D2 (50) + D1 (0)
BFO (250) = D3 (90) + D2 (160) + D1 (0)
No need to reply if it does not make sense to u. This will be my last ‘mathematical comment’. Appreciate your patience all this while.
airlandseaman said,
April 29, 2014 at 3:49 pm
seanmcleod said,
April 29, 2014 at 1:10 pm
Regarding
“…I seem to remember people wondering whether the AES TX offset was calculated based on the assumption/simplification that the satellite was truly geostationary….”
It does not matter how it normally calculated the offset because after the malfuction, it apparently stopped calculating any new offset.
sk999 said,
April 29, 2014 at 6:13 pm
How much extra leverage do you get from the BFO measurements?
On the assumption that the AES TX offset was calculated on the basis of a geostationary orbit for 3-F1, I went ahead and calculated the difference in the BFO for two flight paths – one that was close to the original Inmarsat 450 knot great circle path ending up in the old search area SW of Perth, and the other being a “curvy” path that exactly matches the ping arcs of the first but ends up at the Ocean Shield position. This second path requires a constant velocity of 310 knots and a heading change of over 10 degrees per hour. I did not try to match the CNN-released ping arc angles exaclty, but they are pretty close.
The peak-peak dfference in BFO between 18:21 and 00:11 is 28 hz. This difference is the entire lever-arm that Inmarsat et al. have had available to distinguish between two vastly different flight paths and utlimately different search areas.
For those who have their own ideas about how the TX offset was determined. predictions would be welcome.
airlandseaman said,
April 29, 2014 at 6:54 pm
The AES was a Honeywell 4200/7200. This AES determins the Dopplerby calculating it using (1) a look up table containg the satellite ephemeris for all satellites in the Inmarsat system, and (2) the real-time position, velocity, etc. from the aircraft. The latter is supplied by the AIMS/IRS (Inertial Reference System) via 429 bus.
Alex Siew said,
April 29, 2014 at 10:08 pm
@airlandseaman, @GuardedDon,
All the extracts previously posted were from the MCS4200/7200 Honeywell manual. Further selective extracts from the ‘ FAILURE DESCRIPTION’ section are as follows:
1. SDU
Code 01182 BATTERY VOLTAGE LOW
2. HPA
Code 04140 [HGA HPA] INTERNAL POWER SUPPLY FAILURE
3. HSU
Code 08 K 85 [HSU1] BATTERY CHECK FAILURE
4. INPUT BUS
Code 9E 0 01 -04 [HSU1] 429 CONTROL BUS INACTIVE…..ICAO ADDRESS INACTIVE….. POSITION UNAVAILABLE……..VELOCITY UNAVAILABLE
It would appear the satcom components each has some sort of secondary/battery power source, thus the many references to ‘primary power’ in the manual including in the extracts previously posted. This could be due to requirements for UPS under RTCA or ARINC although i have not been able to confirm that as i dont have access to either.
Skwosh said,
April 30, 2014 at 12:19 am
@sk999 Agreed – the ‘better’ the compensation mechanism the more it destroys information about the aircraft’s velocity and location (if all we have is the frequency measurements) – so a ‘less good’ compensation mechanism would be more useful (and/or in the context of the ‘geostationary compensation’ model perhaps there could be some further aircraft-position/velocity dependence in the ‘mystery offset’). At least we all have real track data to test models against for the first *four* time points – and then I think all any of us can really do at the moment is to test further speculative track data against a given set of ping-ring data and any particular BFO/compensation model we may have in mind (though I think it is reasonable to require BFO models to be able to do some sort of north/south asymmetry that at least qualitatively matches the Inmarsat north/south ‘predicted’ points – and to bare in mind that Inmarsat claim to have tested the model they used to generate those points against some real aircraft data prior to the BFO graph release). Also, as far as bending/variable paths go, they may ‘fit’ a particular model, but there is then the need to explain *why* the aircraft may have been following such a path (which, I guess, could actually *support* a given model if there was a fairly straightforward explanation for such a variable path in terms of how the aircraft navigation systems works and/or possible failure modes and/or a plausible proposal for pilot action/motivation etc.).
seanmcleod said,
April 30, 2014 at 1:23 am
From – http://www.slashdocs.com/nkzyzq/sdim-msc7200-23-20-35-rev-1.html
When individually wired to the zero state, configuration pins TP11C and TP11D indicate, respectively, that the inputs designated for the primary and secondary IRSs(MP6A/MP6B and MP6C/MP6D, respectively) are connected to an ARINC 429 source of IRS label 310, 311, 312, 314, 324, 325, and 361 information (although label 361, Inertial Altitude, is not required for SATCOM).
From – http://www.gama.aero/files/GAMA_PUBLICATION_11-ARINC_429,GENERAL_AVIATION_SUBSET_VERSION_5.1.pdf
310 – Latitude
311 – Longitude
312 – Ground Speed
314 – True Heading
324 – Pitch Attitude
325 – Roll Attitude
361 – Inertial Altitude
Some of the IRS data e.g. pitch and roll are needed specifically for the high-gain antenna configuration where the antenna is steered towards the satellite.
Unless the SDU differentiates the inertial altitude it won’t have a rate of climb (ROC) to use for it’s Doppler correction (AES TX Offset), also since it only has true heading if there is any wind then the difference between heading and ground track won’t be accounted for.
Not sure whether they would account for the differences of up to 22.4% that you calculated for the 4 calibration points.
Skwosh said,
April 30, 2014 at 3:48 am
@sk999 @richardc10 @Ole etc… So, now a bit of a consensus on how the aircraft’s Doppler compensation probably works is… forming… we could maybe start to reason about failure modes – so what might happen if the compensation mechanism’s knowledge of the aircraft position/velocity becomes incorrect – either through drift and/or some sort of failure/event/duff-re-start etc. (as I think Richard was thinking a while back) – like maybe it and/or the navigation system just got stuck at some point. Maybe there could be a common cause/failure here that accounts for the (latter part of) the offset in the BFO and perhaps also the aircraft’s actual course – so I’m wondering about what the Doppler compensation system’s fall-back might be if its stops getting data – things like that. If the Doppler compensation went duff at some point then, somewhat ironically, much more information about the aircraft’s position and location would start to leak into the BFO measurements. Anyhow, I guess we can model these sorts of scenarios now.
richardc10 said,
April 30, 2014 at 4:16 am
I have posted below on the elevation data fitting only. I won’t clutter up this server with a copy.
http://www.pprune.org/rumours-news/535538-malaysian-airlines-mh370-contact-lost-522.html#post8457673
and yesterday (similar to the one here)
http://www.pprune.org/rumours-news/535538-malaysian-airlines-mh370-contact-lost-520.html#post8455863
seanmcleod said,
April 30, 2014 at 4:21 am
In terms of the AES TX Offset for the last 5 pings can’t we recover the value used by Inmarsat in the BFO graph for their predicted southern track?
On the assumption that the 450kt and 400kt tracks released as part of the BFO data release match both the ping ring radii and the BFO data then using GlobalMax’s digitization (maybe tweaked slightly to match the ping ring radii from the recent elevation data released by Inmarsat) of the possible tracks we will have the aircraft position, speed and can work out the ground track for each of the last 5 pings.
With that we can work out the LOS speed between the aircraft and satellite and then see what offset Inmarsat have used to match the BFO data. Whether it’s some constant, e.g. 0 or something like 50Hz that Victor has used in some of his tracks or whether it’s time varying.
We can then also do the same exercise for the 400kt track and compare.
GuardedDon said,
April 30, 2014 at 4:40 am
While I have, to date, only identified a low gain antenna on 9M-MRO I took another detailed look at recent images of the aircraft and found that the aircraft was fitted with a high gain antenna array – it’s a Ball Aerospace ‘patch’ design with a patch antenna fitted either side of the fuselage, just above the door that’s aft of the wing. So this confirms that MH could use Aero-H and potentially Swift64 but, IIRC, Tim Farrar suggested that MH didn’t subscribe to Swift64.
http://bit.ly/BallStrb
http://bit.ly/BallPort
I don’t believe that info materially affects any conclusions/assumptions drawn here so far, hope not anyway.
seanmcleod said,
April 30, 2014 at 5:50 am
I looked up GlobusMax’s digitized track and then calculated the bearing between his ping points, the ping radius to the satellite and what the LOS speed would be between the aircraft and satellite.
I’ve used his original digitized points, i.e. I haven’t tried to shift them to fit the ping radii from the recent Inmarsat elevation data.
GlobusMax 454kt Southern Check
(Lat,Lon) Bearing Ping Radius(nm) LOS Speed (kts)
(-3.28, 93.25) 191.8 1749 10.95
(-10.67, 91.68) 186.9 1781 -68.04
(-18.18, 90.72) 184.3 1944 -133.24
(-25.71, 90.1) 184.8 2192 -179.55
(-37.13, 88.91) 184.8 2640 -244.58
seanmcleod said,
April 30, 2014 at 6:00 am
Forgot to include GlobusMax’s 394kt southern track to compare the LOS speeds with the 454kt track.
GlobusMax 394kt Southern Check
(Lat,Lon) Bearing Ping Radius(nm) LOS Speed (kts)
(0.63, 93.47) 178.1 1739 -16.14
(-5.92, 93.69) 177.3 1806 -61.84
(-12.47, 94.01) 163.1 1946 -150.66
(-18.73, 96.02) 164.3 2210 -179.55
(-28.28, 99.06) 164.3 2638 -220.53
Skwosh said,
April 30, 2014 at 7:35 am
@richardc10 So… I’m thinking – curvy course? Why curvy? Duff navigation system perhaps and thus – possibly, also, duff Doppler compensation that might show up in the BFO (so – BFO (because it reads the inertial data) could be a possible ‘side-channel’/window into a failure in the navigation system which could *also* account for an eccentric course).
richardc10 said,
April 30, 2014 at 7:39 am
Ping-arc modelling
pprune doesn’t seem to like my post, so here it is.
Following the post yesterday on the new satellite elevation graph (above), I have modelled a course with constant rate of turn that ends at the final search box, and which fits the elevation graph. As stated yesterday, a great circle course at constant speed leads to the original search area.
In this work I fitted the start point (lat, long), original heading, change of heading per hour and the (constant) speed, and of course the satellite elevation data. I have fitted the 19:41 to 00:11UT elevation data. The plot is shown below.
http://s1311.photobucket.com/user/RichardC10/media/map_zps1f55c707.jpg.html
Some notes:
1. The best fit was a change of -10degrees/hour, from a start heading of 194.3, speed of 327kt.
2. The yellow point is the fitted course extended back to 18.27UT (the time of the pings previous to 19.41) so this point is not a fit to any data. The green box is the last reported radar position at 18:22UT. The model interpretation only requires that MH370 was established on the white arc of the track before the 19.41UT ping time. The exact route from the green box to the interception point on the white arc is not determined but I have plotted a small sector of the 18:27UT ping arc to show this is consistent.
3. The fit to the elevation data is excellent, r.m.s. error of 0.1degree, which is as good as the data can be read from the published fuzzy image (this may be a sign that the data has been over-fitted – the number of fitted parameters is large).
4. The plotted course is not consistent with an interpretation of the published BFO/Doppler data developed by myself and others (skwosh, ole, sk999). However, Inmarsat have said that their BFO model was ‘fine-tuned’ so it is quite possible (indeed almost certain) that the BFO data changed from the published set, or additional elements were added.
5. Constant magnetic heading courses to the final search box do not give enough heading change to fit the elevation data.
This graph does not prove that MH370 went to the area of the final search box. Presumably, the authorities used the results of modelling later generations of the BFO and elevation data, and perhaps other data sources. I think the graph does indicate that there is at least one such course (there will be others) that is consistent with the elevation data and hints at the route taken.
Skwosh said,
April 30, 2014 at 7:39 am
@richardc10 … which, extrapolating wildly, perhaps also raises the possiblity that the pilot *thought* he/she was going somewhere that, actually, they *weren’t*.
Skwosh said,
April 30, 2014 at 7:41 am
@richardc10 the pprune links you left above worked fine for me.
airlandseaman said,
April 30, 2014 at 7:45 am
4 more photos from the 2014-04-29 Beijing Meeting here:
https://dl.dropboxusercontent.com/u/32349391/Beijing_2014-04-29.zip
Skwosh said,
April 30, 2014 at 8:05 am
@airlandseaman – well – after *five* seconds looking at those photos:
(1) Blimey.
(2) This is going to launch a storm of speculation.
(3) There looks like there is a *lot* of incipient data in there about methodology.
airlandseaman said,
April 30, 2014 at 8:40 am
Regarding Don’s excellent find on the 9M-MRO antenna photos…This is a very important detail. We now know that the antenna system used on 9M-MRO was the Ball AirLink electronically steered Phased Array. This is a HGA (High Gain Antenna) System consisting of two phased patch arrays, one on each side of the fuselage above the doors, and two BSUs (Beam Steering Unit).
High gain means narrow beam, which means it required continuous, active steering, which requires an AIMS/IRS 429 connection. IOW, it needed AIMS/IRS data not only for Doppler Offset calculations, but also for antenna steering. If it lost the 429 link to the AIMS/IRS data, it would have lost more than the ability to calculate Doppler. It would have lost the ability to select the left or right side array, and the ability to steer the selected array. At least, that’s what it looks like on the surface. But there is a statement in the Honeywell 4200 manual on page 393 that suggests the system may have an ability to operate from an alternate source of nav data. It states:
“The MCS system requires ARINC 429 data for antenna pointing, antenna stabilization, and Doppler frequency correction. These requirements are defined in Table A–10. If the aircraft does not have an IRS that supplies this ARINC data, the SCU can be used to supply the data.???
The meaning of this statement is not entirely clear. The block diagram shows that the SDU gets its nav data from the 429 bus. It may simply mean that the system can be configured at installation time to use an alternative nav data source if there is no IRS (like GPS, etc.) Or, it may mean the system will automatically use some alternative nav data source if the IRS data becomes unavailable while operating. If so, what source?
In any event, the action item now is to track down how the 4200 system would work in the event that the AIMS/IRS data was lost. Did it have a crude backup capability that allowed it to search for the satellites by scanning the antennas, and tracking based solely on dithered signal strength? If so, that might explain how it was able to reconnect to the satellite after an AIMS/IRS link failure, but still have no Doppler correction (or a different, much simpler correction algorithm?).
seanmcleod said,
April 30, 2014 at 9:15 am
So in terms of working out the AES TX Offset assumed in the BFO graph for the southern route I don’t see a constant offset.
At roughly 2.82Hz/knot for the LOS Speeds calculated for the southern routes I get the following AES TX Offsets for the last 4 pings:
00:11 – 338Hz
22:40 – 224Hz
21:40 – 147Hz
20:40 – 21Hz
Versus Victor’s roughly constant 50Hz offset he uses in:
http://media.wix.com/ugd/c3aa61_a41a56f694bd439199658085a48fe095.pdf
richardc10 said,
April 30, 2014 at 10:30 am
The Beijing photos…
Great stuff
Lots of different kinds of courses in there:
- constant changes of heading courses
- changes of heading plus and minus at ping-arcs (the lines between pin-arcs are all plotted as straight lines)
The turning point North of Indonesia is on the ~18.27 arcs, so they are certain there is only one major turn at that time. There is another earlier turn implied at the pin mark, I think. The yellow line from there to the 18.27 point doesn’t look like the 295degree course from Penang.
So they are running families of courses through the model, as would be expected.
Sid said,
April 30, 2014 at 10:50 am
richardc10,
Where are the photos being published?
Thanks,
Sid
andyhull said,
April 30, 2014 at 11:14 am
I’m still bothered by the seismic event I pointed out previously, the more I look at it, the less like a “seismic” event it looks.
If it is seismic, then why does it look as though the P wave component arrives after the S wave, (the same event is clearly visible on both Christmas Island seismic stations, so it is clearly not someone dropping a spanner next to the seismograph).
If it is an impact, then could it be MH 370? It is clearly in the right time frame. Does anybody have any ideas about this?
richardc10 said,
April 30, 2014 at 12:44 pm
@skwosh
>failure modes
Here I work on the basis that up the BFO page in the Inmarsat presentation is ‘approaching’ Doppler, negative rangerate, that is the natural definition of positive frequency offset. The model I have been
working on works that way at least.
Some ideas, for what they are worth.
i) any leak of the uncorrected aircraft speed Doppler will give large negative BFOs for most of the time of the flight, certainly after the 18.30 turn. We don’t see that in the data. Complete failure of the correction mechanism seems ruled out.
ii) loss of navigation data updates. As airlandseaman has pointed out, loss of navigation data would probably imply loss of signal. Even if not, and the terminal was using old data, the Doppler due to the uncorrected aircraft velocity becomes larger (negative) in the flight so use of old data (old corrections) would give substantially more negative BFO contribution later in the flight, again not seen.
iii) stale data. More subtle failure than ii). Depending on how old the data was, the impact could be small or large. Should be easy to model.
iv) Reset of the system. This may be more subtle, I think. If the terminal had to restart in flight (which must be possible) it would receive L-band frequency standards via the p-channel(s) I think (I don’t claim to be an expert on this, far from it). However, any frequency it received would be changed by the aircraft velocity Doppler. It can correct for this using the Doppler velocity correction algorithm, but I don’t see how it could distinguish between an error from this algorithm and its own internal bias. On the ground this is not an issue of course but would an in-flight reset give an additional (incorrect) bias offset of the magnitude of Doppler velocity correction error at the time of reset? This may be gibberish.
v) Drift in AES oscillator frequencies. This has been mentioned before. However, the WSJ story talked about looking at oscillator drifts in the spacecraft system, so drifts at the Hz level in the AES must be as relevant. If the BFO data was used to give latitude of the search box they are after accuracies of 1Hz in the BFO. So big oscillator errors (i.e. a few Hz) on board would be very bad news.
airlandseaman said,
April 30, 2014 at 1:20 pm
Although I could not find any specific specifications for long term or short term frequency reference stability and accuracy, it is clear that the MCS-4200 uses an OCXO for the local frequency and time base reference, and it is continuously steered by a higher standard to zero long term drift. I’m sure it uses a GPS locked clock to do this. I think it is very safe to assume an absolute accuracy (after warm up) of <1 Hz. I know some readers may find this level of accuracy surprising, but it is easy to accomplish with fairly old technology, so not surprising to me. An OCXO will maintain better than 10^-9 for a day or more with no external help, so not an issue if the AES lost the 429 bus at some point. Some quotes from the 4200 manual:
1. The correct operation of much of the internal circuitry of the SDU depends on clocks derived from the high-stability frequency reference generated by the oven-controlled crystal oscillator (OCXO). Therefore, it is inappropriate to perform BITE tests until this clock frequency has achieved gross stability. If the SDU is powered on after having stabilized at a cold external temperature (e.g., –55° C), it can take several tens of seconds for the frequency drift rate to be low enough before the phase locked oscillators (PLO) that derive the
dependent clocks can lock onto the OCXO frequency reference.
2. L–Band
Reference Offset Calibration Thresholds
This item defines (in Hz) the thresholds of the L–Band reference offset calibration for both the with IRS and without IRS cases. These thresholds are used to determine whether to adjust the L–Band reference offsets. These values are displayed on the CMT.
Hopefully, this will end speculation about the accuracy of the reference oscillator. Assume it is perfect.
Skwosh said,
April 30, 2014 at 3:53 pm
@richardc10 Yes – thanks very much for your thoughts/feedback on that – not gibberish at all! I am currently thinking along the lines of your item (iii) stale and/or perhaps even *subtly* wrong data – so, say some sort of acute event introduces something like a ‘heading error’ in the inertial system – so the aircraft thinks its heading is not what it actually is – then – (though I am still trying to get my head around this and am starting to write code for it…) perhaps depending on the details – it could actually either over or under compensate the Doppler (so, I guess it would over compensate if it thought its heading was less tangential than it actually was?) and also obviously such a fault would impact the navigation system and thus the track – perhaps accounting for curvy-ness – should curvy-ness and/or an explanation for curvy-ness be required – though it doesn’t look, at least from those pictures, like Inmarsat are into curved tracks at all (though they may be indirectly as the headings of their segments look a bit all over the place in some cases. Obviously in this sort of scenario the position would also get increasingly wrong too – which would clearly be an ever growing problem for the directional antenna.. Anyhow – I’m trying to build a little model that allows for the possibility of a difference (perhaps really quite a subtle one) between what the nav system is saying and what the aircraft is actually doing physically so I can explore what impact that might have on the tracks and the BFO – this may be a rubbish idea – but I’ll try to give it a go – not necessarily saying we have any reason to think this is what happened (though I guess if you’re a negative-Doppler type person then a fairly substantial failure in the compensation may be the sort of thing that could fit better).
airlandseaman said,
April 30, 2014 at 4:48 pm
Victor’s latest. Worth a careful read. First path I have seen to fit all the 2014-04-29 Inmarsat elevation angles and the latset BFO analysis, without any BFO Offset assumptions other than that the BFO Offset went to zero after 18:00.
http://media.wix.com/ugd/c3aa61_2a070f311e6342ca82e0a4141e795aa4.pdf
Sid said,
April 30, 2014 at 4:56 pm
Most of the effort has been focused on the Southern route as it has been believed to be the only one consistent with both the BFO and ring radius data. All of the solutions have been handicapped both by the lack of data regarding the time delay measurements, and uncertainties in interpreting the BFO data.
With the publication of the elevation angle data (presumably from the unpublished time delay data) another constraint appears to have been provided. However, the additional constraint, if it is merely derived data, it can be considered to be redundant and result in only a stabilization of the solution as the two computations undoubtedly have different assumptions and error sources.
The analysis that is presented for discussion explores a Northern route. There may be other solutions, and a more accurate solution along the lines described is possible; however, until this proposed solution has seen some scrutiny by the community, further refinement is just an exercise.
Aqqa has prepared a spread sheet computational model taking account of the complete geometry and the motions of the aircraft and satellite. The model uses the BFO-to-radial-range-rate conversion according to Mike Exner. As there are several iterations of that analysis that have been published, the “Doppler??? data that we have used is also included. There is no implication that Mike Exner endorses the data that was used, but we are grateful to him for the data. (I know that there are doubts as to what the Doppler data mean, but the data has been taken face value as the rate of change of range rate) Also, the specific iterations of the model are mine, but would have been impossible without the meticulous analytic model that aqqa constructed.
For purposes of analysis, the presumed initial location of the aircraft is the generally acknowledged point of last radar contact at 18:22. That is, the issues related to the early time correlations are not considered here.
The model continues the track approximately along the last known radar radial vector for a time before turning in a northerly direction. From there, the azimuth and speed of the aircraft were adjusted to yield a manually-iterated match to the Doppler and elevation angle measurements (the elevation angle in this presentation is measured from the zenith).
The interpretation of the last data point (00:11) requires some thought. In essence, there is no further extension of the track data to check the validity of the assumed last segment. Since the measured Doppler data combines the aircraft velocity and the angle between the aircraft path and the radial vector to the sub-satellite point. So, as the presumed aircraft speed is increased, the path both rotates in azimuth in a counterclockwise manner and lengthens. This may be further complicated by end-point maneuvers. Until the basic analysis is accepted, there is no point in exploring the modalities.
As currently computed, the end point at 00:11 is 40.50N, 73.86E.
I am fully prepared to be wrong, but this computation is at least not inconsistent with the data as currently known.
https://dl.dropboxusercontent.com/u/15200211/plot.PNG
https://dl.dropboxusercontent.com/u/15200211/model%20results.PNG
https://dl.dropboxusercontent.com/u/15200211/BFO.PNG
Alex Siew said,
April 30, 2014 at 8:49 pm
@XocoLatte, @LGHamiltonUSA
In the first part of the narrative, i had said: “No one has come forward to say they heard a Mayday call from MH370. What happened at 1.21am to cause it to fall off the radars and why did the pilots not make a distress call?”
I might have been mistaken about the lack of an SOS call. A recent post on PPRUNE [Post #10426, Page 522] referred to a report about a military base in Thailand having heard an SOS call from MH370. Looking back at various postings on the net made in the first few days after the plane went missing, there was a report in China Times On March 8, 2014 at 2025, the original in Chinese with the translation as follows:
” Furthermore, according to the US Embassy, at 2.43 in the morning, American military personnel stationed at U-Tapao Air Force Base received an emergency SOS transmission from MH370, captain of the aircraft shouted that cabin was disintegrating and the plane needed to make an emergency landing”. Another translation is as follows:
” In addition, the US embassy said 2.43am US forces stationed in Thailand military base Fort UTA had been listening to a Malaysia Airlines flight MH370 the SOS emergency call signals, aircraft pilots call the cabin faced collapse, they are going to crash….”
U-Tapao is located at southern Thailand next to the Gulf of Thailand and was (and apparently still is) a US military base . Thailand is 1 hour behind Malaysia in time so 2.43am would be 1.43am Malaysian time.
If this report is true, this would be further evidence of a positive lightning strike.
The cabin floor beams of a Boeing 777 are made of composite materials. This is from the Boeing website:
“The 777 makes extensive use of lightweight, cost effective structural materials that lessen the overall weight of the airplane…Progress in the development and fabrication of weight saving advanced composite materials is evident in the 777. Carbon fibers embedded in recently available toughened resins are found in the vertical and horizontal tails. The floor beams of the passenger cabin are also made of these advanced composite materials….”
The following are extracts from the AAIB Investigation Report on the 1999 glider incident whereby the glider disintegrated midair after being hit by a positive lightning strike:
” Lightning interactions with aircraft:…….In aircraft…..constructed from a non conducting material such as GRP, the lightning arc is likely to attach to the extremities of any linked conducting components within that structure….there is a possibility that a lightning arc may track within the structure before being conducted through such mechanisms. Such arcs ionise the air and almost instantaneously produce extremely high gas temperatures which may be in the region of 50,000 F. The resultant combined shock wave and explosive overpressure emitted from the lightning arc channel can be very damaging to the structure. Additionally, heating damage and failures are likely to occur at various locations wherever resistance and impedance is high relative to the current flowing. This occurs particularly at bearings and joints within a mechanism, with further arcs (and their consequent shocks and overpressure) forming in the opened gaps between the linkages. Large mechanical forces are also generated by intense magnetic fields associated with such high currents, which may both assist any linked components to separate, thereby inducing further arcs, and/or cause them to deform……….RECOMMENDATION NO 99-49: It is recommended that the CAA should request serious consideration, during its participation in the current international review of aircraft lightning certification standards, of the fact that energy levels from positive polarity discharges have been shown to greatly exceed those specified in Advisory Circular AC 20-53A, with the associated implications for the certificated lightning protection assurance of existing and future aircraft designs, particularly those which utilise significant amounts of composite material in their primary and control structures….”
As regards the issue whether the Satcom terminal on board had a battery backup arrangement, a further review of the Honeywell’s manual for the MCS 4200/7200 Satcom system shows that not only does the SDU have an internal battery but the other components ie the HSU, HPA and the HGA each has its own battery or internal power supply. The following extract is from a draft of a manual for the Iridium satellite system:
” …As all the avionics, the AES will be designed so that [mean time between failures] is as long as possible whereas [mean time to repair] is as short as possible. These two requirements will apply to essential airborne units such as the satellite data unit, communication management unit, beam steering unit and the antenna sub system. This may be achieved by main/hot standby configuration of the critical units stated above, as well as automated change over mechanism within each unit….”
Finally Victorl has theorized that some disabling event must have happened between the time of the last ACARS transmission (1.07am) and the first complete handshake (at around 2.30am) to break the data path between the Aircraft Information management System in the main bay and the Satcom system at the rear, with the result that from such time onwards the Satcom system was not getting updates of its position, speed and heading from the AIMS to allow for the normal calculation of the Doppler correction needed and thus accounting for the BFO values for the transmissions subsequent to the disabling event.
Victor’s theory of such a disabling event would be consistent with a positive lightning strike at around 1.21am.
Alex Siew said,
April 30, 2014 at 9:20 pm
@XocoLatte, LGHamiltonUSA,
I had omitted to reproduce the following passage from the AAIB Investigation Report on the 1999 glider incident, in my previous comment:
“…. Many more recent glider designs use CFRP for major structural elements. CFRP is an electrically conductive material, but is more resistive than aluminium alloy. Modern jet transport aircraft are also designed with increasing utilisation of such composite materials for structural and control surface elements. One example of this trend is the Boeing 777 which uses CFRP for the horizontal and vertical stabiliser torque boxes, and graphite epoxy for the elevators, rudder, ailerons and flaps…”
Alex Siew said,
April 30, 2014 at 11:13 pm
@Skwosh
Can u or someone on this blog help me with a calculation?
The arc from the final ping lies on the 40 degree circle. If Inmarsat had calculated the location of that arc on the assumption that the ping had come from the plane at altitude 35,000 ft, what would be the location of the arc if the ping had come from mean sea level?
Would it be around 42 degree?
Sorry to ask u, i just dont know how to do the math.
seanmcleod said,
May 1, 2014 at 12:15 am
Hi Victor
So the biggest assumption in this case is that the AES TX Offset was 0 after 18:00UTC. In your previous case you had assumed it got ‘stuck’ at a fixed offset of round 50Hz.
To estimate what AES TX Offset Inmarsat had assumed, and in particular to see if it was also a constant like the one you found to match the measured/predicted BFO from their BFO graph I took GlobusMax’s digitized points for the 2 tracks that were released at the same time as the BFO data.
My assumption being that those 2 tracks (450kt and 400kt) were shown because they crossed the ping arcs at the correct time and at the same time they fitted the BFO data for the last 5 pings.
I took the digitized points and then worked out a constant bearing between subsequent points and then used that to derive the LOS Speed for each ping point.
Given the nature of the digitization etc. his ping radii don’t exactly match the new ones we have from the Inmarsat elevation data from today.
GlobusMax 454kt Southern Check
(Lat,Lon) Bearing Ping Radius(nm) LOS Speed (kts)
(-3.28, 93.25) 191.8 1749 10.95
(-10.67, 91.68) 186.9 1781 -68.04
(-18.18, 90.72) 184.3 1944 -133.24
(-25.71, 90.1) 184.8 2192 -179.55
(-37.13, 88.91) 184.8 2640 -244.58
GlobusMax 394kt Southern Check
(Lat,Lon) Bearing Ping Radius(nm) LOS Speed (kts)
(0.63, 93.47) 178.1 1739 -16.14
(-5.92, 93.69) 177.3 1806 -61.84
(-12.47, 94.01) 163.1 1946 -150.66
(-18.73, 96.02) 164.3 2210 -179.55
(-28.28, 99.06) 164.3 2638 -220.53
At roughly 2.82Hz/knot for the LOS Speeds calculated for the southern routes I get the following AES TX Offsets for the last 4 pings:
00:11 – 338Hz
22:40 – 224Hz
21:40 – 147Hz
20:40 – 21Hz
So in terms of working out the AES TX Offset assumed in the BFO graph for the southern route I don’t see a constant offset for these tracks.
richardc10 said,
May 1, 2014 at 1:29 am
In the Beijing slides all the ping-arcs and the last radar position have been pulled west by 110km with respect to Sumatra. Could just be an error in rendering the .kml files for google earth, but I suspect it is to spare a disagreement with Indonesia who have said they did not detect an over-flight. No advantage in starting a row, not material to the conclusion.
GuardedDon said,
May 1, 2014 at 2:44 am
@richardc10 at May 1, 2014 at 1:29 am
Do you imply that the GE renderings (their KML imports) are off or that the elevation data presented on the graphs at 29 Apr Metro Lido Hotel presentation is off? The latter is more of a concern.
LGHamiltonUSA said,
May 1, 2014 at 3:36 am
@Alex Siew
http://tmfassociates.com/blog/2014/03/24/understanding-the-satellite-ping-conclusion/#comment-26823
¤ Excellent information, Sherlock Siew! I’m “shocked” (pun intended). Why hasn’t the world heard about this “emergency SOS transmission” before now? If it weren’t for your finding the China Times corroborative reporting I’d be in disbelief. I have a comment awaiting Duncan’s approval with further comments about this.
@richardc10, @GuardedDon
http://tmfassociates.com/blog/2014/03/24/understanding-the-satellite-ping-conclusion/#comment-26844
http://tmfassociates.com/blog/2014/03/24/understanding-the-satellite-ping-conclusion/#comment-26859
If Beijing is “doctoring” the slides to appease Indonesia then perhaps we should assume the “7 Data Point” elevation angles are bogus derivatives.
~LGH~
airlandseaman said,
May 1, 2014 at 4:05 am
Regarding battery back up…I’m sure the MCS 4200 does have a battery, but it is not likely to be a battery that can power the entire AES installation. The HPA requires many amps. It is probably a backup battery to maintain the clock and possibly the reference oscillatioroven…not sure…but It could not have been a battery capably of powering the transmitter.
GuardedDon said,
May 1, 2014 at 4:27 am
Perhaps Alain de Botton’s book, The News: A User’s Manual should be essential reading.
richardc10 said,
May 1, 2014 at 5:02 am
@GuardedDon
>Do you imply that the GE renderings (their KML imports) are off or that
>the elevation data presented on the graphs at 29 Apr Metro Lido Hotel
>presentation is off? The latter is more of a concern.
I should have been clearer.
a) the elevation data in the slides can be translated into ping-arc distances from the sub-satellite point and hence plotted. For example the 18:29 arc should be 3618km away.
b) the position of last radar contact was presented at some meeting and I have copied it to:
http://s1311.photobucket.com/user/RichardC10/media/lasr_radar_contact_zps092992e0.jpg.html
From that data the final radar contact position at 18:22UT can be calculated as 6.86N, 97.34E. This is just outside the published (Beijing) 18:29 pin-arc from a), so is consistent.
On the slide Beijing-4_2014-04-29.jpg:
a. the ping-arcs positions plotted on the slide can be measured and the distance to the sub-satellite point calculated. As plotted the 18:29 arc (elevation 52.1 from the graph) – the one on the turn – is a distance 3473km, so actually more than 110km short. As a check I used a satellite prediction programme (Orbitron) for the right time. Entering the coordinates of the turning point shown in the slide (7.1N, 95.4E) (small error from reading off the image of course, but way less than 100km), Orbitron predicts an elevation of 53.2deg which checks with my calculation for the elevation at a ping distance of 3473km.
b. The Last radar position as plotted on the slide (the pin) (6.7N, 96.3E) (again a small error) is 117km from (6.86N, 97.34E) from b) above. The writing on the pin is just about readable – the first word is certainly ‘Last’. The relationship to the two arcs either side (the one on the right is the 21:41 arc) is correct.
c. All the other early arcs are similarly displaced to the West.
So the elevation data graph is not in dispute (from this point), the earlier calibrated points check out, and position of the arcs with respect to the last radar position is correct, so the path length from there to the turning-point is not in dispute. So it seems to be presentational only.
LGHamiltonUSA said,
May 1, 2014 at 6:03 am
Here’s a link to the 5-page preliminary report. I’m still looking for a link to the appendices. CNN reported that the cargo manifest lists 5,000+ lbs of lithium-ion batteries stowed in the aft cargo hold. This equates to the 50 unsold seats at 100 lbs per person:
https://www.documentcloud.org/documents/1151155-mh370-preliminary-report.html
~LGH~
Alex Siew said,
May 1, 2014 at 6:23 am
@airlandseaman,
Various pages of the FAILURE SECTION of the Honeywell’s manual seem to indicate each of the components has some sort of battery or ‘internal power supply’. Please see my earlier comment April 29 10.08pm. For eg, for ‘[HGA HPA]‘ Code 04140 = ‘INTERNAL POWER SUPPLY FAILURE’. As I dont know anything about these things, i could be reading it wrong.
The extract from the Iriduim manual quoted earlier seems to indicate that satcom components have inbuilt redundancy.
Also when the story about the pings first broke, NYT ran a story quoting a Robert W Mann Jr, said to be an aviation consultant in Post washington, NY:
” The fact that satellite contacts continued does not necessarily mean the plane continued to fly, Mr Mann said. If the system had a backup battery, he said, it could have kept trying to transmit after the plane had landed somewhere, and in certain circumstances even after a crash” [NYT March 13, 2014]
Reuters on March 14, 2014 quoted Oliver McGee, former senior US Transportation Department official and professor of mechanical engineering at Howard University: ” [ McGee] cautioned that the aircraft could continue to generate the signals, even if it had crashed, depending on any damage to the aircraft and its engines”.
The pings were said to be ‘faint’, suggesting much below normal signal strength and a secondary power source. The terminal was transmitting the most basic of signals in response to the satellite’s requests for a handshake and i just wonder whether the repeated pinging from the satellite could have prompted the terminal to summon whatever residual power left to ping back, faintly.
richardc10 said,
May 1, 2014 at 6:25 am
From the appendices to the ICAO report at
http://edition.cnn.com/interactive/2014/04/world/malaysia-flight-documents/?hpt=hp_t1
Bendy courses!
http://s1311.photobucket.com/user/RichardC10/media/ICAO-map1_zpsc8865dba.jpg.html
LGHamiltonUSA said,
May 1, 2014 at 6:44 am
http://tmfassociates.com/blog/2014/03/24/understanding-the-satellite-ping-conclusion/#comment-26937
The appendices can, rather inconveniently, be found in today’s tweets here:
https://twitter.com/H2OComms
Also, expecting files would be uploaded at:
http://www.mot.gov.my/en/Pages/Default.aspx
~LGH~
richardc10 said,
May 1, 2014 at 6:51 am
Appendices also at, download button at right
https://www.documentcloud.org/documents/1151152-mh370-actions-taken-between-0138-and-0614l.html
https://www.documentcloud.org/documents/1151153-mh370-cargo-manifest-and-airway-bill.html
https://www.documentcloud.org/documents/1151154-mh370-maps.html
Alex Siew said,
May 1, 2014 at 7:25 am
@LGHamiltonUSA
Some quick thoughts on the preliminary report. MH370 was last tracked by Vietnamese radar, presumably primary, at BITOD (7.15N 104.7E). Vietnam TC called KLATC at 1.38am presumably after losing track of MH370. BITOD would be around the area where MH370 was seen to be ‘burning’ at high altitude by the Kiwi on an oil rig. The timing seems right.
1.19 MH370′s last communications with KLATC
1.21 MH370 disappeared from secondary radar[positive lightning strike?]
1.30 MH88 made radio contact with MH370, heard static, interference and mumbling from co pilot
1.38 MH370 was last seen on primary radar of VTC at BITOD
1.43 MH370 issued Mayday call picked up by US military base at Rayong, Thailand which presumably had super sensitive radio equipment, captain said cabin disintegrating, needed to land
1.– MH370 crashed at South China Sea, south of the southern tip of Vietnam around the intersection of its flightpath and final arc adjusted to mean sea level (42 degree?)
1.– Rear upper part of fuselage remained above water after crash n satcom located just below rear upper fuselage survived
2.25- Satcom responded to satellite’s pinging, using its battery power to ping back until battery ran out or fuselage sank after 8.19
LGHamiltonUSA said,
May 1, 2014 at 7:41 am
http://tmfassociates.com/blog/2014/03/24/understanding-the-satellite-ping-conclusion/#comment-26952
@Alex Siew ~ Interesting observations, thanks. I researched the for the actual China Times article. Traced it back only to learn that it was “scrubbed”:
http://www.thaivisa.com/forum/topic/709464-missing-malaysia-airlines-jet-carrying-239-triggers-southeast-asia-search/page-67
http://tmfassociates.com/blog/2014/03/24/understanding-the-satellite-ping-conclusion/#comment-26949
@richardc10 ~ Thanks for these links!
~LGH~
soph said,
May 1, 2014 at 8:45 am
I understood the pings rings were derived from the ping delays. I was reading an article on propagation delays and I learned that software bugs can change them. Could damaged software have produced inaccurate ping delays and hence the ping rings are ‘false’? Are the elevation angles also derived data? Sorry if this has already been discussed. I’m not an expert. I was just wondering.
I also found this paper. Not sure it’s helpful:
The Effect of Tropospheric Propagation Delay Errors
in Airborne GPS Precision Positioning1
V.B. Mendes, J.P. Collins, and R.B. Langley
Geodetic Research Laboratory, Department of Geodesy and Geomatics Engineering
University of New Brunswick, P.O. Box 4400, Fredericton, N.B. E3B 5A3 Canada
http://gauss.gge.unb.ca/papers.pdf/ion95.tropo.paper.pdf
LGHamiltonUSA said,
May 1, 2014 at 10:15 am
@Alex Siew ~ FWIW check out this image:
http://i.dailymail.co.uk/i/pix/2014/05/01/article-2617647-1D7EEBAA00000578-31_634x725.jpg
It’s from: http://www.dailymail.co.uk/news/article-2617647/British-marine-archaeologist-claims-flight-MH370-3-000-miles-search-zone-spotting-debris-painted-colours-Malaysia-Airlines.html
~LGH~
richardc10 said,
May 1, 2014 at 10:21 am
@GuardedDon
> Do you imply that the GE renderings (their KML imports) are off
> or that the elevation data presented on the graphs at 29 Apr
> Metro Lido Hotel presentation is off? The latter is more of a
> concern.
Having now seen the ICAO report which has the same data as the Beijing presentation, I think I have to conclude that the data in the ’7 data point’ graph is _not_ consistent with the ICAO report. It seems unlikely that my political point would extend to an official report. The ICAO report refers to ‘updated last air defence radar point’ at 18:22, well West (55nm) of that implied by the radar plot in the image I posted.
airlandseaman said,
May 1, 2014 at 12:38 pm
Alex Siew
Your lightning theory *might* have some support if you were not insisting that it is connected with an early crash. None of the hard data we have is consistant with an early crash. The BFO and the elevation angle data are both inconsistant with an early crash. Moreover, as I have explained here at least twice, the HPA in the AES would require a HUGE battery to continue operating after the loss of primary power. It did not have such a battery.
It may not be the most likely scenario, but at least a lightning strike that caused several equipment failures, but not a crash, is a scenario consistant with the BFO and el angle data. An early crash is not possible.
Have you researched the weather conditions around 17:30 UTC? Were there any thunderstorms reported in the area? I have not heard of any such conditions.
Alex Siew said,
May 1, 2014 at 3:07 pm
@airlandseaman
Sorry for the late reply, 12 hours difference in time zone between where i am and New York.
Yes, i have researched the weather conditions prevailing at the time MH370 went missing, all the details are contained in my previous comments April 17 at 5.20am and 8.33am . Briefly, there were thunderstorms earlier in the day,but the night was basically clear with light scattered clouds but a pilot flying in the vicinity at the time MH went missing said he saw lightning in the area where MH370 was passing through. Lightning in such weather conditions ie dissipating thunderstorms, clear or slightly cloudy skies points to positive lightning aka bolt from the blue. Please see the comments on April 17.
There is considerable evidence to show that MH370 was indeed struck by such a bolt. The static and interference heard by the other plane that got through by radio at 1.30am, the apparent dazed condition of the co pliot at that time, the cabin made of composite material disintegrating, the likely St Elmo’s fire on the plane seen by the Kiwi on the oil rig, the electrical failure which would explain the transponder going off as well as the severing of the link between the AIMS and the Satcom at the back.
But how do we reconcile that with the BFO chart? Victorl to me has provided the last piece to the puzzle. He said there was an disabling event and from such time onwards, the Satcom was not getting updates on its position heading etc to calculate the Doppler correction needed. That would explain the shape of the chart for the 6 pings which is a mirror of the movement and velocity of the satellite for that period. U would have noticed the chart shows a dip at around 3.36am, the exact time the satellite reaches its northern apex and then the values got progressively larger when the velocity of the satellite was increasing for the last 5 pings. U would also have observed that the BFO values for the pings at 2.29 and 4.40 are roughly the same, when the satellite velocity for those times are also roughly the same (approx 50 knots). In fact when we minus off the BFO values by roughly 90 Hz, the nett BFO values roughly tally with the velocity of the satellite in knots for the corresponding times.
I think what happened was that the SDU could not process the proper Doppler correction because it was not getting updates of the speed, position and heading of the aircraft from AIMS anymore, so it basically computed the Doppler based on the position and velocity of the satellite preserved in nonvolatile memory.
As regards the RT timings for the pings, i have been saying since day one that the RT timings would show that the plane had crashed early on and that the differences in the timings can be accounted by the movement of the satellite and that Inmarsat overlooked the movement of the satellite in rushing out with their original analysis and that is the reason they are holding on to the data and not releasing it for dear life, apparently not even to the Malaysians if what the Malaysians told the relatives at Beijing this week is true.
As soon as we get the RT timings, we would know whether the early crash theory is a load of rubbish and i will be getting comments from Sean (just kidding Sean)
Alex Siew said,
May 1, 2014 at 3:14 pm
The reference in the preliminary report that the Vietnamese last saw the plane at BITOD would appear to be inconsistent with the purported turn to the west off IGARI. Curiously this information as to where the plane was last tracked by the Vietnamese, presumably by primary radar in range, has been withheld all this time.
airlandseaman said,
May 1, 2014 at 3:48 pm
Alex Siew said,
May 1, 2014 at 3:07 pm
Like I said, Alex, lightning is not necessarily ruled out by the data. But an early crash is absolutely eliminated by the data. Time to move on. I urge you to continue investigating your lightning theory, but assuming the aircraft continued to fly. Given the weather at the time, it seems unlikely, but not inconsistant with the Inmarsat data.
GuardedDon said,
May 2, 2014 at 3:19 am
Alex, the way this works: a) find the remains of the aircraft; b) [hopefully] locate the DFDR and CVR, c) begin a process to extract facts from the evidence, d) use the facts to generate a narrative of the events leading to the final loss of the aircraft with the expectation of identifying a root cause, e) make recommendations to minimise the risk of future incidents.
You are approaching the problem in reverse from d).
It’s important to remind ourselves that, in the case of MH370, the process hasn’t reached a) yet. One might say there isn’t actually an air accident investigation without aircraft debris but gathering tangible, verifiable, evidence of circumstances prior to and during the flight is a important task.
MoTM/DCA has itself attempted to pre-empt e) with a recommendation for real-time tracking. I’ll offer another one: ICAO should define a method to categorise and rank incident severity together with a capability maturity model to rank a state’s investigative ability. Where the rankings don’t match a state must nominate which investigation body will take the lead in an investigation.
Head over to http://www.weathercharts.org , follow up the 12 references to ‘sferics’ & look for a reported event between 17:07 and, say, 17:30UTC 7th March.
Alex Siew said,
May 2, 2014 at 5:48 am
@GuardedDon,
I did take a look at this website weeks ago when u first suggested that i provide verification for the lightning,i did not find anything but will take another look again tomorrow morning.
Skwosh said,
May 2, 2014 at 9:41 am
@Alex In answer to your earlier question – I calculate that it makes about a 1.2km difference on the ground between the 40 degree elevation angle being assumed to be at ground level, or if it was from 35,000 ft – so not very much difference at all (this is basically down to the earth being so big compared to 35,000 ft, and the satellite also being so far away).
One thing I don’t quite understand is why they presented the numbers as elevation angles in the first place. I think we all assume that the raw data on which these values is based are timings – so for sure, for a presentation, it could make sense for them to process the data into something more ‘physically-picture-able’ than time delays – but why elevation angles?
Skwosh said,
May 2, 2014 at 10:02 am
OK, say all you have is ping rings. Anyone can just draw a set of random lines from one ping-ring to the next and say, quite correctly, that it is a track that fits the rings. How credible is any such random track? Well, any segment that would require a speed that is incredibly low or incredibly high can’t be included – but apart from that, what other criteria are there? We might exclude tracks for which there wouldn’t be enough fuel – or perhaps for which there may have been too much fuel – we might also exclude tracks that take the aircraft to places where it would most likely have been observed and reported by radars (though this consideration doesn’t seem to be inhibiting people that much) – but in the absence of further information – or any kind of model – presumably all you can apply, further than these sorts of considerations, would be basic ‘simplicity’ criteria – so, tracks with less speed changes and less heading changes are perhaps more credible, and also tracks with multiple segments that form part of a great-circle or rhum-line might also add further credibility (though this is already starting to get into the area of an informal model of what the aircraft’s auto-navigation system may have been doing some of the time). However, even applying these sorts of criteria I guess you’re still left with a very large number of credible tracks that all fit the ping rings.
However, the ping rings are *not* the only data Inmarsat have. They also have the BFO data (what ever it is), and they have some sort of model that allows them to predict what the BFO data would be for a given track, and so, presumably, they are using this to further whittle down the set of credible tracks. So, based on this perhaps over simple view, I would guess their high probability tracks are – in order of importance – (1) must fit the ping-rings (2) must fit the BFO as well as possible (what ever the BFO is) (3) must otherwise be as ‘simple’ as possible in all other respects. It may of course be that Inmarsat also have other data and models that we don’t know about that they are also fitting (e.g. some sort of model of the aircraft’s navigation system).
Anyhow, it looks like the end result of all of this is a *bendy* track that ends at the current search-area. Given the above interpretation this suggests to me that either their faith in the BFO has overridden any concerns about making the tracks more ‘complex’ (bendy) and/or they have other reasons to explain why a bendy track may not actually be so unlikely in the first place. However, if they do *not* have any such explanation then surely it raises the question as to *why* the track taken by the aircraft was so bendy (rather than the track being either, say, a great-circle or a rhum-line etc.)
Given that none of us have un-equivocally managed to even fit Inmarsat’s previous rather simple ‘predicted’ southern track (the 450 knot southern route) to Inmarsat’s BFO graph I am wondering how the community is going to react to the latest bendy Inmarsat track. If the community also fails to fit this latest ‘predicted’ Inmarsat track to the currently published Inmarsat BFO measured data then presumably the community will likely conclude, not unreasonably, that this latest Inmarsat prediction is just as fictitious as the last one, and/or that the BFO data is still just as suspect as it ever was and/or that Inmarsat are themselves could be interpreting the BFO data incorrectly?
Skwosh said,
May 2, 2014 at 10:26 am
@richardc10 I’ve got my model working. Unsurprisingly much can be achieved as far as fitting the BFO to a variety of ever-so-slightly-bendy courses by introducing small steady cumulative heading errors (order of one degree per hour) into the navigation system – the resulting small (but increasing) heading and position differences between the actual and ‘preceived’ track can generate a steady offset in the BFO (positive or negative to taste) which can, for example, allow one to interpret the BFO as including the full C-band component (effectively substituting for the time-linear fitting offset). It’s a bit tricky because the actual track has to fit the rings and the BFO calculation is based on the ‘perceived’ track – but I’m fairly confident it works now. Will try to find time to do a quick write-up and some pictures. *However* this is obviously all a bit arbitrary – and for large heading drifts – such as the 10 degrees per hour or so required to make a track as bendy as the recently published one obviously the BFO (positive interpretation) goes way-way-off into the land of fail. Am still pondering. It is also possible to do subtle things like making the nav system’s idea of the speed incorrect too which can also obviously shift the Doppler in either direction. Anyhow – still pondering.
Skwosh said,
May 2, 2014 at 10:29 am
@andyhull I had a quick look at those seismic graphs you posted and it looks to me like the timing is out by an hour – but I could be wrong. Much confusion here generally between local time and UTC though.
Skwosh said,
May 2, 2014 at 10:55 am
@Alex – re-reading your question – you wanted the answer in degrees – so it would still be very close to 40 (I calc. about 40.01 degrees).
LGHamiltonUSA said,
May 2, 2014 at 11:47 am
@Airlandseaman ~
Please check your DM. Important message regarding CNN. Thanks.
~ LGH ~
seanmcleod said,
May 2, 2014 at 12:09 pm
Has anyone worked out the coordinates for the 350kt, 344kt, 325kt etc. tracks presented in the interim report? Once we have those we can work out the LOS speeds and compare them to LOS speeds for the 450kt and 400kt tracks they presented with the BFO data to see how consistent they are across all these tracks.
If they are pretty consistent then we can work out what AES TX Offset they’ve been assuming for each ping.
andyhull said,
May 2, 2014 at 2:24 pm
@Skwosh – thanks for that.. I did a quick time check on it myself, and it is at the very edge of the time frames suggested by the “pings”.
If my back of the envelope calculations are correct, it suggests the event took place somewhere between 200 and 400 km from Christmas Island, depending on which of the various methods of calculation is used, and therefore probably took place somewhere between 10 and 30 minutes before it appeared on the trace. This might squeeze it in just before the “missed ping”, but would put it probably on the “edge of possible”.
It would also place the aircraft much nearer Christmas Island than I would expect, but again this could be the case if it were travelling slower than speculation thus far suggests.
I didn’t really expect to see anything in the Seismic data, (frankly I was surprised to find the data so easily available), but since this particular event stands out like a sore thumb on the graph (which is almost entirely flat, save for background noise in the hours either side, and the same event is also clearly visible on the chart of the nearby airport station), I feel I need to pay it some heed.
The exact distance from the source to the detector is difficult to estimate, since I don’t know if the signal was mainly propagated through sea water (unlikely due to attenuation) or through rock. Obviously a seismic event would travel purely through the earth’s crust, but an impact might be different. Obviously waves travelling through seawater do so significantly more slowly than waves travelling through rock.
I did figure out that I can stretch the time scale and period of the graphs by manipulating the cgi call, so for example…
http://seis-pub.ga.gov.au/dbheli/dbheli2png.cgi?sta=XMIS&chan=BHE&time=2014-03-08+01%3a16%3a00&period=100&lines=1&scale=2000&filter=none&
This gives a much clearer view of the event. I still haven’t entirely eliminated this from my list of possible leads, but neither have I been able to dismiss it completely..
This may be more noise, in an already noisy debate, but equally it may be of interest.
One thing I have established by looking at the current data, is that there does not appear to (currently) be any significant drift between UTC and up to the minute data, (so the data is not an ahead or behind UTC, as might be the case if the timezone were incorrect somewhere in the logging process). I also didn’t check for any one hour gaps as might be the case if the clocks changed at some point in the last month and a half, so there is an unconfirmed assumption here that all of the times on the graphs are correct (+/- one minute or so).
I also took a quick look at the graphs for stations near the coast of Western Australia. However I suspect that attenuation of the signal, and the larger noise floor, presumably due to greater human activity near these stations, would make it very difficult to spot anything without some pretty heavy number crunching.
An impact with the water would presumably produce a significantly different signal from a seismic movement, but exactly how different is open to speculation.
There is another seismic measuring station on the Cocos (Keeling) Islands, (http://en.wikipedia.org/wiki/Cocos_%28Keeling%29_Islands) but so far I haven’t found any public access to its data.
I’ll keep digging however, as anything which might give us possible impact events, and thus circles to aid triangulation of the aircraft’s resting place is worth looking at.
@Skwosh said,
May 2, 2014 at 10:29 am
@andyhull I had a quick look at those seismic graphs you posted and it looks to me like the timing is out by an hour – but I could be wrong. Much confusion here generally between local time and UTC though.
Alex Siew said,
May 2, 2014 at 6:07 pm
LGHamiltonUSA,
There is something strange going on here.
In any investigation of or search for a missing plane, the point where the plane was last observed would be of the utmost importance. That begs the question: WHY HAS THE INVESTIGATION TEAM SUPPRESSED ALL THIS WHILE, THE FACT THAT THE PLANE WAS LAST OBSERVED AT WAYPOINT BITOD.
The preliminary report dated April 9 was only released on May1, and that only after pressure from the public. It is clear from the report Ho Chi Minh ATC had tracked MH370 on their primary radar all the way to BITOD. See items no. 1, 3 and 10 of the schedule setting out the ‘recorded communications on direct lines’.
These communications would have been recorded at both ends ie by the HCMATC in addition to the Malaysians, and so the Malaysians would not have been able to suppress or manipulate these recordings even if they had wanted to.
From item No. 3, ‘radar contact was established over IGARI’ with HCMATC. It is not clear whether MH370 was seen on their secondary radar at any point but the references to ‘radar blip’ or ‘radar target’ indicate that HCMATC was definitely tracking MH370 on their primary radar all the way to BITOD.
HCMATC first called KLATC at 1.38.19am (item No.1) saying ‘radar target was last seen at BITOD’. Presumably HCMATC had made that call soon after the radar target disappeared from their primary radar, so we can conclude MH370 was last seen at BITOD at around 1.38am.
These recorded communications between the ATCs are contemporaneous evidence. HCMATC was the ATC responsible for tracking MH370 as the plane was being handed over to them with it entering their airspace. Their repeated statements that night that the plane was tracked up to BITOD have to be given great weight and in all likelihood they have primary radar recordings to back them up.
In contrast, what do we have to substantiate the allegation that the plane had turned back off IGARI?
The preliminary report merely says as follows:
” A playback of a recording from military primary radar revealed that an aircraft with a possibility of MH370 had made an air-turn back onto a Westerly heading crossing Peninsular Malaysia. The search area was then extended to the Straits of Malacca”.
This recording has not been produced. There is no information as to where and when this aircraft had made this alleged turn back or where this aircraft had originated from. There is no mention of any corroborative evidence from civilian primary radar from the various airports/ATCS in that region. And it is conceded that it is only a ‘possibility’ that this aircraft was MH370.
The preliminary report however alludes to another possibility, that KLATC might have even tracked mh370 on their primary radar for a while even after it disappeared from their secondary radar:
“At 01.21.13 MYT the radar label for MH370 disappeared from the radar screen at……. KLATCC’.
To me, it is significant the report says ‘the radar label for MH370′ instead of just ‘MH370′ disappeared from the radar at KL.
In short, HCMATC was tracking MH370 right up to BITOD at around 1.38am and KLATC might have also been tracking MH370 on their primary radar after 1.21am at least for awhile. Thus the alarm was only raised after 1.38am when the first call was made by HCMATC to KLATC.
Yet despite all of the foregoing, the investigation team has chosen to base their search and calculations/models on this purported turn west off IGARI. Even more strange is why they have seen fit to suppress the fact that the Vietnamese say the plane was last observed on their primary radar at BITOD. If the preliminary report had not been released, we would not have even known about the plane at BITOD.
As u have noted, the March 8 report from China Times about the US embassy in Beijing saying that the US military base at Utapao had picked up an SOS call from Mh370 at 1.43am, has been ‘scrubbed’. I am not into conspiracy theories but u would think this is something any investigation team would have to check out before dismissing it.
Alex Siew said,
May 2, 2014 at 6:12 pm
@Swosh,
Thank you very much for the calculations, much appreciated.
airlandseaman said,
May 2, 2014 at 7:31 pm
Alex’s May 2, 2014 6:07 pm post re. the BITOD waypoint raises some serious questions. BITOD is 37 NM further than IGARI. (GPS N7°15.72′ E104°6.76). Why, if ATC was reporting radar contact all the way to BITOD, did the search team ignore this fact, and decide MH370 turned around at IGARI? This demands an explanation.
Alex Siew said,
May 2, 2014 at 9:34 pm
@airlandseaman,
Sorry, but is the 37nm figure correct as to the distance between IGARI and BITOD? It looks more like 90+nm on Google.
Alex Siew said,
May 2, 2014 at 9:58 pm
@airlandseaman,
Sorry, my mistake, it is 37nm i think
Alex Siew said,
May 2, 2014 at 10:13 pm
Correction, if BITOD is 37nm from IGARI, it is likely the plane was seen at BITOD not at 1.38am but at some time prior to the 1.38am call from HCMATC to KLATC.
LGHamiltonUSA said,
May 2, 2014 at 11:38 pm
@Alex Siew @airlandseaman ~ Regarding the BITOD issue, one thing that’s been gnawing at me since yesterday’s appendix “Actions Taken Between 01:38~06:14″ is that the entire episode with MH088/Narita was excluded. That occurred at approximately 01:30 MYT. Perhaps it might be useful to check MH088′s flight path and bring that result into the equation. Alex, I was also thinking about the Thai radar factor when I began to read your May 2, 2014 at 6:07 pm post. I need to digest all the above and put fresh eyes on it tomorrow. Great observations. IMO there’s a lot of hanky panky going on. The lies are piling high to the sky. ~LGH~
Alex Siew said,
May 2, 2014 at 11:46 pm
@LGHamiltonUSA,
For completeness, I have proceeded to calculate how long MH370 could have drifted if indeed it suffered a catastrophic failure at 1.21am.
Assuming a glide ratio of 18:1, the plane could have traveled roughly another 100nm. At 250 knots which i understand is the ideal gliding speed for a 777, the plane could have stayed up for around 24 minutes.
That would be consistent with the SOS call regarding an emergency ditching, picked up at 1.43am.
Alex Siew said,
May 2, 2014 at 11:55 pm
@GuardedDon,
Would u know the capability of the primary radar employed at Ho Chi Minh ATC. I am wondering as to how low a plane would have to be at BITOD to escape the primary radar at HCMATC.
LGHamiltonUSA said,
May 3, 2014 at 12:23 am
@Alex Siew ~
08-Mar-2014 B772 MH088
Kuala Lumpur Int’l (WMKK / KUL)
Narita Int’l (RJAA / NRT)
00:05 MYT 06:57 JST 5:51
This is the flight that made static contact & heard mumbling.
~LGH~
richardc10 said,
May 3, 2014 at 2:47 am
Some thoughts on the ICAO report maps.
The ICAO report analysis shows that routes can be generated from the start point to the final ping arc at a variety of speeds that are not impossible. Once a start point and a speed are selected there is only one choice for the Southern route (at least a route that has a chance of being close to the BFO data). I get speed changes of between 6 and 16degrees/hour for the first four route segments (a fit the red zone) and 1degree/hour for the 22:41-00:11 segment; the path looks roughly consistent with the report maps (figure 1). I get a slightly lower speed (311 against 323kt in the ICAO report) – the report analysis would have used wind corrections, I did not. Anyway, the precise route does not matter, the key issue is the BFO at the final ping arc(s).
Figure 1: Fit to the ICAO report start point and red-zone using a constant speed route of 311kt. To be clear this in not intended to prove the aircraft went to the red zone
http://s1311.photobucket.com/user/RichardC10/media/constant-speed-ICAO_zps339b22ec.jpg.html
Red/yellow/green zones meaning: In the map the 00:11 markers for speeds 323, 332 and 344 are marked with 30000, 15000 and 3000ft respectively. The ping-arc data is very slightly sensitive to the absolute height and the BFO not at all sensitive, so if heights has been used in these plots it must have used a _change_ of height in the modelling. Also, if the fuel was exhausted at 00:18, flying at 344kt/3,000ft would not give a longer range than 323kt/30,000ft so these values are not height for the whole route. The on-board correction does not include rate of climb/descent as has been discussed before and confirmed on the pings where ADS data is available. So if the aircraft was descending at 00:11 the BFO value at the final ping arc would have been changed, giving a lower value.
The red-zone track states a final height of 30000ft, so no descent. The required descent rate for the 344kt track at 00:11 (green zone) to bring the BFO value back to that predicted for the 323kt track (red zone) is 230ft/min (4.2Hz in BFO). That would give a change of height of 21000ft in the 1.5hrs between 22:41 and 00:11, so compatible with the difference between the supposed height of 30000ft at 22:41 and the marked 3000ft at 00:11. Presumably work in the simulator has indicated some basis for this.
So in summary, the hypothesis:
a) The final BFO data (which we do not have – we have only the initial set released to the families) is a fit to the Red Zone.
b) The Red, Yellow and Green zones refer to possible rates of descent after 22:41. The red zone is the best match to the (assumed) 00:11 data with the aircraft level at 30000ft. If the aircraft was descending at 230ft/min the green zone would be the best match to the 00:11 data. It is taken here that some work on the aircraft analysis has given a basis for this.
c) This explains why there is no green or yellow zone North of the red zone. The aircraft is not expected to climb from 30000ft, so the BFO cannot be changed to deflect the final position North.
Again, here I am trying to understand the presented analysis, not offering some alternate model.
GuardedDon said,
May 3, 2014 at 2:54 am
@alex, @LGH, @airlandseaman
IGARI to BITOD is indeed 35nm, ~8min flying time.
Here’s an image for a bit of context, http://imgur.com/B3ow154
*) skyvector image overlaid, accurately, on GE
*) Pink line = 9M-MRO course according to ADS-B data (with my own 100nm extrap on 40deg). It could have flown direct IGARI-BIBAN along that 40deg track.
*) Yellow arc = assumed range of the ADS-B ground based terminal on Con Son Island
*) Orange arc = segment of the 00:11 ring (superfluous to this context)
To Alex, I haven’t located a Vietnamese primary surveillance radar site (military) but their southern SSR (civil) site is on the Ca Mau peninsula.
9M-MRO turned after IGARI, as detailed in info published to date.
The Con Con ADS-B thing is significant, in as much as it’s another data source MoTM/DCA should have access to.
Must go back and check if anything was said about ADS-B transmissions vs 9M-MRO’s transponder and ACARS transmissions ceasing.
There’s been so much talk about the need for mandated sat tracking, those talking seem to be unaware that ‘the world’ is adopting ADS-B. Australia already has mandated it for traffic above FL300. Aircraft continuously transmit position using ADS-B (1093MHz Ext Squitter transmissions), that’s primarily how the tracking websites get their data, but it’s primarily for ATS surveillance (Of course, ADS-B it has limited range but ADS-A/C exploits ACARS, less frequent updates, for sparse areas)
Coincidentally, Malaysia seems to be the last country in their region to get with ADS-B, their ground based terminal (BGT) won’t be online til later this year (totally immaterial to what happened to 9M-MRO, just broad context).
An emphatic ‘no 9M-MRO ADS-B/SSR position data was logged by [Vietnam|Singapore|etc] ATS’ (or the opposite with the data) would be more confidence inspiring than the vacuous statements Hishammuddin is making at his ‘PCs’.
BTW: the references for ADS-B exploitation are a number of recent ICAO publications discussing improved air traffic surveillance in the SE Asia region.
airlandseaman said,
May 3, 2014 at 4:26 am
The distance between IGARI and BITOD is confirmed to be 37 NM. See:
https://dl.dropboxusercontent.com/u/32349391/IGARI-BITOD.JPG
Summary of BITOD references here:
#1 01:38:19 Ho Chi Minh first enquired about MH370, informed KL-ATCC that verbal contact was not established with MH370 and radar target was last seen at BITOD.
#3 01:46:46 HCM queried about MH370 again, stating that radar contact was established over IGARI but there was no verbal contact. Ho Chi Minh advised that the observed radar blip disappeared at waypoint BITOD.
#10 02:18:53 KL-ATCC queried if flight planned routing of MH370 was supposed to enter Cambodian airspace. HCM confirmed that planned route was only through Vietnamese airspace. HCM had checked and Cambodia advised that it had no information or contact with MH370. HCM confirmed earlier information that radar contact was lost after BITOD and radio contact was never established.
These are direct quotes from the May 1 Official Reort. They are totally inconsistent with the IGARI turn point everyone has been assuming. Until now, I have been taking on faith the reports that MH370 turned at IGARI and followed the path relentlessly reported on news channels. IF MH370 was in fact tracked to BITOD before dropping off the radar, it raises serious questions about the entire story and assumed path after loss of vioce contact. Maybe there is a good explanation for the decision to ignore these reports, but the May1 report makes no effort to reconcle the IGARI turn assuption and these BITOD reports.
LGHamiltonUSA said,
May 3, 2014 at 4:54 am
airlandseaman said,
May 3, 2014 at 4:26 am
@airlandsesman ~
I’m almost afraid to ask: Does this change your BFO analyses & results?
~ LGH~
airlandseaman said,
May 3, 2014 at 5:08 am
here is a simple summary of the L band Dopplerand derived LOS Speeds assuming AES lost AIMS/IRS data after 17:07UTC:
https://dl.dropboxusercontent.com/u/32349391/Doppler_2014-05-03.JPG
GuardedDon said,
May 3, 2014 at 5:49 am
@airlandseaman
The ADS-B transmissions are a function of the Mode S radar transponder unit (Honeywell TRS 67A, tbc). Like the satcom SDU the transponder gets GNSS positional update via A-429 so the source, AIMS, and the transfer medium, A-429, are the same as that for SDU. Food for thought.
airlandseaman said,
May 3, 2014 at 5:57 am
Don: I agree, but it would be different 429 cables going to the transponder and the AES. This tends to implicate the common IRS source, not the cables.
GuardedDon said,
May 3, 2014 at 7:53 am
Mike: agreed, I’m just not clear yet on A-429 topology downstream of AIMS’ IOMs (pt-pt, star, bus drop) but suspect its pt-pt for reliability.
nihonmama said,
May 3, 2014 at 9:09 am
Hi Alex:
Thanks much for your input and contribution. Been tweeting about MH370 since it disappeared on March 8 and now endeavoring to connect relevant info coming out of the the science-driven MH370 blogs with other (relevant) info coming out via news, and conversations on Twitter that are not necessarily flowing into mainstream media reports. The key to solving to this mystery will entail connecting many pieces, and some of those may not appear significant at first glance.
Re your questions, you may/may not be aware:
1.For reasons that escape logic (particularly as we in the midst of an on-going investigation have no plane bodies, or black boxes) five weeks ago, Malaysia SEALED evidence included air traffic control radio transcript, radar data and airport security recordings. Some of the answers to the questions you pose may be included in that bundle. People should ask how it is that information of an evidentiary nature has been sealed when there’s been no formal LEGAL (or administrative) proceeding http://t.co/piUcKCdqdO
2. As was noted in a New Straits Times article dated March 9, a second MAS pilot on a NRT-bound flight made contact with MH370 http://t.co/SHeAdS6WbT But it appears that investigators are ignoring this pilot’s (who, by any definition, would be considered a WITNESS) report. By any investigative on the planet standard, this makes not an ounce of sense.
airlandseaman said,
May 3, 2014 at 9:21 am
Don: I could be either point to point, or a bus. From:
http://www.aimonline.com/products/hardware/arinc429/arinc429.aspx
“ARINC 429 defines both the hardware and data formats required for bus transmission. Hardware consists of a single transmitter – or source – connected to from 1-20 receivers – or sinks – on one twisted wire pair. Data can be transmitted in one direction only simplex communication – with bi-directional transmission requiring two channels or buses. The devices, line replaceable units or LRUs, are most commonly configured in a star or bus-drop topology. Each LRU may contain multiple transmitters and receivers communicating on different buses. This simple architecture, almost point-to-point wiring, provides a highly reliable transfer of data.”
A transmitter may ‘talk only’ to a number of receivers on the bus, up to 20 on one wire pair, with each receiver continually monitoring for its applicable data, but does not acknowledge receipt of the data.
A transmitter may require acknowledgement from a receiver when large amounts of data have been transferred. This handshaking is performed using a particular word style, as opposed to a hard wired handshake. When this two way communication format is required, two twisted pairs constituting two channels are necessary to carry information back and forth, one for each direction.
airlandseaman said,
May 3, 2014 at 9:37 am
Don:
It could be either a point to point connection, or a bus. But I think the SDU is collocated with the antenna, so probably a point to point. See 429 spec’s here:
https://dl.dropboxusercontent.com/u/32349391/OVIEW429.PDF
From pg 70 in 4200 manual:
“The SDU system table memory contains the location of all satellites. When a GES is selected, the SDU uses this location information and aircraft positional information (through an ARINC 429 interface) from the IRS to compute the position of the satellite relative to the aircraft. The SDU then transmits pointing and tracking coordinates (aircraft relative azimuth and elevation) to the beam steering unit (BSU), antenna control unit (ACU), or ARINC 781 antenna to permit optimum signal transmission and reception between the high gain antenna subsystem and the satellite.”
“In the SDU, the baseband data modulates RF carriers, which are sent to the HPA for amplification, and then to the antenna subsystem for transmission to the satellite. The SDU can adjust the transmission frequency in one–Hertz increments to compensate for the Doppler shift caused by the speed of the aircraft.”
nihonmama said,
May 3, 2014 at 9:53 am
@ Alex Siew:
I asked @RWMann about possibility (assuming the story was true) that Utapao may have *heard* MH370′s SOS call. His response:
“VHF/UHF radio horizon at 35,000 feet is 265 miles, so Utapao would have been beyond #MH370 horizon but signal may have hopped..” http://goo.gl/yOQY6N
LGHamiltonUSA said,
May 3, 2014 at 10:36 am
Alex Siew said,
May 2, 2014 at 11:46 pm
@Alex ~
http://www.chinatimes.com/realtimenews/20140308003502-260401
https://translate.googleusercontent.com/translate_c?depth=1&nv=1&rurl=translate.google.com&sl=auto&tl=en&u=http://www.chinatimes.com/realtimenews/20140308003502-260401&usg=ALkJrhjIYXkYTziM-Ci3xCIS0jzRzUtrDw
“In addition, the U.S. Embassy said the 2:43 U.S. military bases stationed in Thailand U-Tapao SOS signal was listening to some of Malaysia Airlines Flight MH370 emergency call, said the aircraft cabin facing disintegration driver call, they want a forced landing. U.S. troops are currently stationed in Thailand, Malaysia has been providing this signal.”
~LGH~
airlandseaman said,
May 3, 2014 at 11:11 am
LGH: Waypoint have nothing to do with BFO analysis.
LGHamiltonUSA said,
May 3, 2014 at 12:06 pm
airlandseaman said,
May 3, 2014 at 11:11 am
@airlandseaman ~ Good, I’m glad. Thanks. ~LGH~
LGHamiltonUSA said,
May 3, 2014 at 12:20 pm
LGHamiltonUSA said,
May 3, 2014 at 12:06 pm
@airlandseaman ~ Apologies! The satellite pings, not the waypoints, involve the BFO. I suppose I was thinking about your .xls files that contain so much interrelated data. I was concerned that a new flight path was a SNAFU.
~LGH~
seanmcleod said,
May 3, 2014 at 12:36 pm
@Alex Siew
” the investigation team has chosen to base their search and calculations/models on this purported turn west off IGARI.”
You make it sound like that is their sole basis, ignoring the satellite ping rings, satellite Doppler data and further primary radar data from Malaysia and Thailand.
How do you explain the ping ring and Doppler data without assuming a conspiracy?
Including primary radar data at 18:22UTC and a satellite ping ring at 18:25UTC. Is it a coincidence that they are within range of each other again assuming no conspiracy?
And do you think the US military would sit on their hands (assuming they were even within VHF listening range) if they really heard an SOS radio call? Again without assuming a conspiracy?
At 450kts groundspeed and 37nm from IGARI to BITOD that works out to 4mins 54s flying time. The transponder stopped working 9 seconds after passing IGARI.
The interim report doesn’t indicate an exact time for the turnback based on the primary military radar data.
Now for arguments sake say the turn was initiated 1-2mins after passing IGARI and at 450kts and say a bank angle of 15 degrees given the turn radius how close would the aircraft come to BITOD?
GuardedDon said,
May 3, 2014 at 1:23 pm
@airlandseaman
Agreed: I’m clear on the antenna & SDU equipmnt location, picked up that 429 doc earlier too. We’re on the same page with that info. The transponder’s in MEC/EE bay.
Alex Siew said,
May 3, 2014 at 2:39 pm
@seanmcleod,
Sean, on this point whether there is a conspiracy, here are my thoughts.
U have to admit there are some really strange things going on for which there can be no reasonable explanation. For example, the refusal of the investigation team to release the RT timings, required for the calculation of the 6 arcs which would show where the plane went from point A to point F.
We are dealing with the loss of a 777 with 239 people onboard. The investigation team says the plane ended at arc F, but refuses to say where arcs A to E are, even after 2 months of fruitless searching, with the bodies of these 239 people rotting in the sea . No one has a monopoly on wisdom. Perhaps u can come out with an explanation as to why they are refusing to disclose this data.
There is not a single scrap of evidence to support the purported turn west. @GuardedDon has shown that the blip at VAMPI or MEKAR said to be MH370, was actually UAE343. There are many airports and military bases both in Malaysia and Thailand in that region all with primary radar, yet no recording has been produced to show this turn west n crossing from one coast to the other. Perhaps u can come out with an explanation as to why no one has yet to produce a single recording of primary radar to back up this claim.
Perhaps u can also explain as to why the investigation has failed to disclose that the plane was actually tracked to BITOD and not IGARI, and why the drawings in the preliminary report still show the plane stopping in its track at IGARI and headed back west from there ie IGARI.
We dont know the plane was still flying at 450 knots from IGARI to BITOD, this is only your assumption. If the plane had lost power and was only gliding at that point, that journey could have taken quite a few more minutes.
Whatever the speed or the time it took for the plane to get from IGARI to BITOD, the point is why suppress this information that the plane was last seen at BITOD to begin with, if one does not have anything to hide or an ulterior motive.
The report about the SOS call may or may not be true but surely u would agree something as critical as a purported SOS call with the pilot saying they had to make an emergency landing, has to be investigated. But do u see the investigation team doing anything in this regard? Do u see any mainstream media following up on this report? This was China Times quoting the US embassy, not some conspiracy theory nutcase.
The Malaysians on the team may be dumb but u would agree the people from AAIB, NSTB, Inmarsat, Boeing and Rolls Royce are not dumb. Why do u think these people are keeping quiet and letting the Malaysians do the talking. Just a matter of protocol?
Have u given any thoughts to the implications for Boeing if indeed MH370 was brought down by positive lightning? In 1999, 15 long years ago, the aviation world was put on notice positive lightning strikes can exceed 200,000 Amperes, the threshold planes were designed to withstand. I will set out one more time for u the safety recommendation from AAIB following the 1999 glider incident:
” RECOMMENDATION NO 99-49: It is recommended that the CAA should request serious consideration, during its participation in the current international review of aircraft lightning certification standards, of the fact that energy levels from positive polarity discharges have been known to greatly exceed those specified in Advisory Circular AC 20-53A, with the associated implications for the certificated lightning protection assurance of existing and future aircraft designs, particularly those which utilise significant amounts of composite material in their primary and control structures”.
That was 15 years ago and to my knowledge, the protection threshold under AC-53A of 200,000 Amperes, still remains today.
If the plane is found and the plane’s plight is ascertained to have been caused by positive lightning, the spotlight will fall on airline companies and in particular Boeing AND aviation safety regulators for ignoring the known safety risk posed by positive lightning. Boeing will be faced with one big lawsuit but even more damaging will be the required recall of their entire fleet to address the lightning protection issue. As u would be aware, many Boeing planes use significant amounts of composite materials in particular the 787.
So the stakes are high for those in the aviation world. I am not saying they are actively conspiring but the fact is it would be in their interests if the plane is never found.
LGHamiltonUSA said,
May 3, 2014 at 3:27 pm
Alex Siew said,
May 3, 2014 at 2:39 pm
@Alex ~ Bravo! As Duncan would say, “Exemplary”. ~LGH~
Alex Siew said,
May 3, 2014 at 3:42 pm
@nihonmama,
Hi. Yes, i am aware of the report regarding a pilot from another plane, almost certainly MH88, making radio contact with MH370 at around 1.30am. This report is corroborated by another report posted on PPRUNE (#120, Page 6) by someone who appears to be a pilot, that HCMATC and another MH plane were trying to contact MH370 on the emergency frequency during that period of time.
Regarding the SOS call, we dont know where exactly the US military picked up the signal. The US presumably has many ‘listening posts’ in that region other than Utapao. They could have just cited their known base at Utapao just to avoid disclosing the whereabouts of these other listening posts and their capabilities.
It would not be suprising that the US military managed to pick up the signal when others apparently did not. The radio equipment on MH370 was obviously not in normal operating conditions judging from the static and interference from by the pilot of MH88, so the SOS call was presumably in ‘scrambled’ or ‘distorted’ form. The US military presumably would be equipped to pick up even faint and distorted signals and to decipher them.
I believe the RWMann u referred to is the same Robert W Mann Jr who was quoted in New York Times on March 13, 2014 as saying that the Satcom could still ping even if the plane had crashed if it had a battery back up arrangement. We have debating this issue here on this blog and i would really appreciate it if u can get Robert to explain further on the battery back up thing.
Alex Siew said,
May 3, 2014 at 3:52 pm
@GuardedDon
Thank you for the really helpful post on the radar thing. I was just thinking that the plane must have dropped in altitude after it passed BITOD for it not to be detected anymore by the primary radar at Ho Chi Minh City ATC. If that drop in altitude can be calculated, it may give some clues as to whether the plane was gliding downwards at a certain speed from IGARI to BITOD, assuming it was gliding to begin with.
LGHamiltonUSA said,
May 3, 2014 at 4:26 pm
Alex Siew said,
May 3, 2014 at 3:52 pm
https://m.facebook.com/photo.php?fbid=679309148775178&set=a.116008071771958.7699.111607872211978&type=1&theater
FlightRadar24:
“Today there are reports in media that MH370 may have turned around. FR24 have not tracked this. This could have happened if the aircraft suddenly lost altitude as FR24 coverage in that area is limited to about 30000 feet.”
~LGH~
GuardedDon said,
May 3, 2014 at 5:14 pm
Alex:
Pls try not to misconstrue my posts: beyond IGARI towards BINOD waypts 9M-MRO should have been within range of Vietnam’s air traffic service SSR radar (on Ca Mau peninsula) and its ADS-B GBT on Con Son. Both of those technologies receive clear positional data from the aircraft & the aircraft would have to lose 1000′s of feet to no longer return signal.
Please understand the difference primary vs secondary surveillance radar. Primary is typically the military type that isn’t interrogating for the civil aircraft Mode-S transponder information whereas SSR is interrogating for that.
You may also have misconstrued the satcom technology being discussed here. There’s no way that the aircraft satellite communications system will continue to operate without full aircraft power available, no way, OK? You may be confusing the subject of this blog’s discussion with the emergency locator transmitters provided on the aircraft – these are fitted on the door slides/rafts plus one in the airframe itself. They are battery powered but are notoriously ineffective in crash situations: they’ve got to be above water to propogate a signal.
Cut back on your ‘presumptions’ and follow up some facts.
nihonmama said,
May 3, 2014 at 5:44 pm
@Alex Siew:
Hi Alex. Thanks much for your response. The RWMann I referenced is indeed the same who was quoted in the NYT. He’s a good egg, extremely knowledgeable and happy to share it. Will tweet alink with your request to him and I’m sure he’ll be happy to engage.
If you are so inclined, please also feel to come on Twitter. There are some very robust (and relevant) information exchanges happening there as well. The key to solving this mystery is not only going to be found in the science-driven WHAT (read: where and by what path did 370 crash – or land?) but the HOW and the WHY. Crowdsourcing — which includes actively sharing/synthesizing information across platforms — is a must if we are to ever get to the bottom of this.
I would just add in support of your comments above, that I am always amazed when people express incredulity at the possibility of a conspiracy, as though it’s a paranormal event. A conspiracy is: 1. An agreement; 2. Between two or more people; 3. To commit a crime. We don’t know what’s at work in this case (yet), but conspiracies happen all around us, everyday, and for a lot less than what’s at stake in this case.
airlandseaman said,
May 3, 2014 at 8:25 pm
The final 2 FR24 radar records at 17:21 do show a change in heading from 25 to 40 degrees, which was the normal path for the IGAGI turnpoint. The ADS-B fedd was F-WMKC1.
airlandseaman said,
May 3, 2014 at 8:27 pm
Correction:
The final 2 FR24 radar records at 17:21 do show a change in heading from 25 to 40 degrees, which was the normal path for the IGARI turnpoint. The ADS-B feed was F-WMKC1.
Alex Siew said,
May 3, 2014 at 10:50 pm
BITOD VS IGARI
As mentioned in one of my previous comments, the preliminary report alluded to the possibility that KLATC had tracked MH370 on its primary radar for awhile even after it fell off their secondary radar at 1.21am, so i went back to look at the reports on radar tracking made in the first week after the plane disappeared.
The following is an extract from WSJ on both March 12 and 13, 2014:
“Azharuddin Abdul Rahman, the Director General of the Dept of Civil Aviation, told a news briefing that air traffic control lost contact with Flight Mh370 on its secondary radar at 1.21am Saturday before losing contact with the primary radar at 1.30am. At that point, the plane was cruising at 35,000 feet above South China Sea, he said…………… As is standard international practice, Malaysian controllers use two radar systems. a primary and a secondary to monitor their airspace….”
From the link provided by @Nihonmama, it seems the Malaysians have sealed this primary radar data. The preliminary report only says that ‘at 1.21.13 MYT the radar label for MH370 disappeared from the radar screen at ….KLATC”.
The tracking by Malaysian primary radar of the plane up to 1.30am would be consistent with the Vietnamese’ repeated statements in the communications between the 2 ATCs that the plane was tracked as a ‘radar blip or target’ up to BITOD.
This time of 1.30am is significant for many reasons.
First it corroborates the Vietnam’s version of the story that the plane had flown on to BITOD.
Secondly, it corroborates the report by the pilot of MH88 of having made successful radio contact with Mh370 at about 1.30am before the connection was lost and could not re-established.
Thirdly it would suggest that the plane had dropped in altitude sufficient to lose primary radar coverage at BITOD at 1.30am.
ASSUMING the plane had a catastrophic electrical failure at 1.21am, from 35,000 ft the plane could have glided another 103.7 nm at a glide ratio of 18:1 and optimum gliding speed of 250 knots before hitting sea level 24.88 minutes later at around 1.45am.
BITOD is 37 nm away from IGARI. If the plane had been gliding at 250 knots, the plane would have taken 8.88 minutes to reach BITOD or at 1.30am.
At that speed and glide ratio, the plane was dropping 1406.75 ft per minute. At BITOD it would have dropped to 22,508 ft.
Perhaps those on this blog with expertise on radar coverage and knowledge of the ATC’s primary radar capability in both Ho Chi MInh city and KL can comment whether this would be the height that would make a plane disappear from primary radar coverage.
The other possible explanation is the pilots intentionally brought the plane down quickly in altitude after BITOD because of decompression issues caused by the cabin disintegrating.
Alex Siew said,
May 3, 2014 at 11:00 pm
THE PURPORTED SOS CALL
As this information, if true, would be of critical importance, i have taken the step of asking someone whose first language is Chinese ( but with lesser fluency in English it seems) to translate the paragraph from China Times about the SOS call:
” In addition, the US Embassy in Beijing claimed that at 2.43am USAF Base at U Tapao in Thailand monitored a piece of distressed SOS emergency message from MH370. Aircraft pilot claimed the cabin was facing the risk of disintegration, they demanded a forced landing. The USAF Base in Thailand has presented this piece of information to Malaysia. “
nihonmama said,
May 4, 2014 at 12:16 am
@Alex Siew
Thanks. The clarification in that last line, if true, is a biggie.
nihonmama said,
May 4, 2014 at 12:21 am
@Alex Siew
And I’ve conveyed your request via tweet to RWMann. It’s very early am Sun here, so I expect he’ll respond on Twitter or here in a few hours. Enjoy the rest of your day.
nihonmama said,
May 4, 2014 at 12:43 am
@alex Siew
One more —
RWMann (re Utapao):
https://twitter.com/RWMann/status/444602000467324928
RWMann said,
May 4, 2014 at 4:05 am
Monitoring frequency per request
airlandseaman said,
May 4, 2014 at 12:53 pm
Here’s a nice link to 370 weather data.
http://www.weathergraphics.com/malaysia/
Alex Siew said,
May 4, 2014 at 2:12 pm
@GuardedDon,
I am aware of the differences between primary and secondary radar and ADS-B. But to my knowledge, Vietnam did not receive any secondary radar or ADS-B signals after 1.21am. Vietnam did track MH370 on their ATC primary radar up to BITOD and Malaysia tracked the plane on their ATC primary radar up to 1.30am.
If we assume the plane disappeared from both Vietnam and Malaysia ATC primary radars at the same time, it means the plane had taken 9 minutes to travel from IGARI to BITOD, a speed of 250 knots, which happens to be the ideal gliding speed for a 777.
I hear what u and @airlandseaman are saying about the power needed to transmit these pings, at the same time R W Mann and Oliver McGee have said the Satcom can still ping even after a crash and there are numerous references in the MCS 4200/7200 manual suggesting some sort of secondary power for the system, so it is not unreasonable for someone to keep an open mind on this issue until there is further clarification. Perhaps those in the States can have a word with R W Mann on this matter.
Alex Siew said,
May 4, 2014 at 2:27 pm
@nihonmama
There is no moderator on this blog so everyone is free to post. However the laypeople here have always kept in mind that this is primarily a technical blog. I answered a comment addressed to me from someone on whether i was assuming there is a conspiracy but u would have noticed that there are now more than 800 comments and most of them are focused on interpreting the satellite data and the assumptions underlying the data, and i suspect the people on this blog would prefer that remains the case. Looking forward to your contributions.
Alex Siew said,
May 4, 2014 at 2:39 pm
LGHamiltonUSA,
Not knowing Chinese, i have not been able to do much in terms of checking out the article in China Times. Have u been able to find anything to suggest it is a genuine report or otherwise?
One sees it mentioned in conspiracy sites but these people are going on about ‘false flags’ and CIA having hijacked the plane to the base etc. However, the article itself does not suggest anything of that sort, if anything it suggests the Americans have shared this alleged information with the Chinese and Malaysians promptly and were not concerned with its publication.
LGHamiltonUSA said,
May 4, 2014 at 2:50 pm
Alex Siew said,
May 4, 2014 at 2:39 pm
@Alex Siew ~
I am now rejecting this claim because I’ve subsequently learned that is popular on conspiracy websites and poker forums and it cannot be substantiated.
~LGH~
GuardedDon said,
May 4, 2014 at 3:10 pm
@airlandseaman
Great graphics there. Not heavy winds, easterly up around Sumatra then turning westerly out to west of Aus, right?
GuardedDon said,
May 4, 2014 at 4:05 pm
Hey Alex
Last time, absolutely, definitely.
MCS4/7200 System Description: battery references relate, for example, ‘to supply backup power for the BITE memory’. BITE is the Built In Test Eqpmt function within all avionics, the battery objective to ensure that any logged fault data isn’t lost before the component is analysed by maintenance. Today, a design might just use a small SSD.
Power requirement for SDU plus ancilliaries + Ball Airlink antenna ship set = apprx 600W (at 28V). To put that in perspective: trying to power that complex from these internal batteries would be analogous to trying to start an automobile from a coupe of AA cells. Oh, wait, you’d also need a big chunk of the avionics powered up to feed the antenna with position data to enable the HGA to beam steer its array. Shame that I eventually recognised that the aircraft had high gain antennas and do you know what? They’re not on top of the fuselage, they’re located on the sides just above the doors so they’re gonna be under water pretty darned quick.
And U-tapao: disregarding that it’s beyond VHF range to MH370s route and a glide might even have allowed it to get to dry land on Ca Mau peninsula, try these searches, type into google search box exactly and use the ‘search tools’ to limit result to last year:
detachment utapao site:af.mil
detachment utapao site:navy.mil
Sure, the military do deploy ‘assets’ from time to time to work with the RTN based there but they do that with all friendly nations.
For good measure try a search with:
wikileaks utapao
In 2005 the ‘spooks’ said it was in a poor state & needed a lot of upgrading, including provision of VHF comms. Consider the Thai’s won’t even let NASA use it as a temporary base for ER surveying…. come on…..
Apologies for the sarcastic tone, it’s a holiday weekend & I’ve enjoyed a glass or two of wine. Plus, I do know – I spent a lot of time around Seattle with Boeing when the 777 was in development & flying for certification, while I wasn’t directly involved I knew guys who worked on the program, I understand the design rationale & reacquainted detail in the last few weeks.
airlandseaman said,
May 4, 2014 at 4:33 pm
Alex Siew said,
May 4, 2014 at 2:12 pm
Regarding MCS 4200/7200 operation from battery power or UPS:
I encourage you to explore your positive lightning theory, but I do not think it is helpful to continue speculating about the ability of the Inmarsat AES to continue operation after a crash. There is no way the Inmarsat AES continued to transmit after it lost primary power, either 115VAC or 28VDC. It is impossible. Unless one of the engines (or the possibly the APU) was operational, it could not have been working after it “crashed”. Period. Moreover, the BFO and elevation angle data prove MH370 was moving at high speed until 00:11, even if we still don’t know exactly where it went yet.
Contrary to your repeated statements here, the MCS 4200/7200 manual makes no mention whatsoever of any capability to operate from a built in backup battery or “UPS”. The only references to batteries in the entire manual are related to the (1) batteries in the handsets, and (2) the small battery that powers the non-volatile memory used in the BITE (Built In Test Equipment). The battery test referred to in the manual is a test of the BITE battery. There is no battery capable of operating the 60W (RF linear output power) transmitter HPA. The system requires about 300-400W total system input power when transmitting (linear RF power amps being fairly inefficient).
Alex Siew said,
May 4, 2014 at 4:52 pm
@airlandseaman, @GuardedDon
I am a layman, i read what u say and i read what R W Mann and Oliver McGee said and there is no way for me to know who is right. I have set out in full the remarks reported in the press attributed to them in a previous comment. It is not that i do not want to believe u or doubt your expertise. Is there a way to find out why these gentlemen said the Satcom can still ping even after a crash? R W Mann expressly referred to the possibility of the system having a back up battery arrangement. What was he referring to if not a back up battery arrangement for the Satcom system. And do we know whether this particular plane had a stand alone separate backup battery for the system? R W Mann seemed to be suggesting that some planes may have.
Alex Siew said,
May 4, 2014 at 5:18 pm
On the subject of the weather at that time, below is the post in PPRUNE on March 8, 2014 [post #120, page 6]:
” We entered HCM FIR last night westbound at FL340, passing Moxon (the boundary with WSJC) at about 1720Z, transitted HCM and Phnom Penh and exited, passing overhead PNH at about 1810Z.
We experienced no problem with VHF Comms with HCM Centre, and VVTS CPDLC/ADS also worked fine. We encountered no adberse wx- in fact it was a beautiful clear monsoon night, though there was some limited scattered lightning visible way off to the SW.
121.5 was congested with both HCM Centre and another MH flight trying to contact MH370. HCM Centre were also making repeated attempts to contact the aircraft on the normal Centre frequency”
Alex Siew said,
May 4, 2014 at 5:36 pm
I see R W Mann on twitter, i am not on Twitter but even if i were, i am not the right person to ask him about this. If he now says he was mistaken or his remarks were misconstrued or misreported, that’s the end of this matter.
Alex Siew said,
May 4, 2014 at 6:17 pm
Sorry, correction, the person said ‘it was a beautiful clear NE monsoon night…..”
RWMann said,
May 4, 2014 at 7:28 pm
You assume that’s the way the R-R EHM system transmits; to my knowledge that has not been revealed, nor why the EHM continued to operate at all when all other comms were interrupted or powered down. The fact that the EHM system continued to operate suggests the possibility of a non-standard power and data arrangement which has not been explained at all and deserves to be.
airlandseaman said,
May 4, 2014 at 7:51 pm
RWMann said,
May 4, 2014 at 7:28 pm
Thanks for joining the conversation here Bob. So far, we have good reason to believe the installed Inmarsat AES was a Honnywell 4200/7200 with a Ball Airlink HGA system. The manual for the AES is here:
https://dl.dropboxusercontent.com/u/32349391/MSC7200-23-20-35-rev-1.pdf
The manual refers to a battery, but the battery is only for a BITE memory, not the operation of the entire AES. Perhaps you could confirm is point for Alex.
The Honeywell AES equipment (SDU+RF) that resonds to low level handshakes is in the rear of the aircraft close to the antenns, as required to minimize RF power loss in the coax cables. An AIRINC 429 cable connects the Satellite Data Unit (SDU) with the avionics in the front of the aircraft. It is our working hypothisis that an equipment failure occured up front, affecting the Mode S, ACARS, ADS-B and other equipment, but this had no direct effect on the AES system in the back, except for the loss of AIMS/IRS data to the AES. Make sense?
airlandseaman said,
May 4, 2014 at 9:03 pm
New details on the 17 handshakes. Yes, 17.
https://dl.dropboxusercontent.com/u/32349391/From%20Chinese%20Briefing%20received%205-4-2014.pdf
I noticed that the 16:30 handshake is said to have been triggered by a turn while taxiing. This explains the small L band Doppler observed at 16:30.
nihonmama said,
May 4, 2014 at 9:21 pm
@ Alex Siew
Appreciate your comments. Fully aware, as most are, of the technical/scientific nature of this blog. I for one don’t assume that you are assuming anything. And since mine was merey an observation (and a definition of the tern) as opposed to floating an actual conspiracy theory, I stand by comment.
Will chime in if and when I have information that can advance the conversation. Look forward to more of your contributions Alex. Thanks.
nihonmama said,
May 4, 2014 at 9:25 pm
@RWMann: Robert thanks for coming over here and being as helpful as you are on Twitter.
GuardedDon said,
May 5, 2014 at 3:41 am
@ RWMann
Perhaps you would address the specific point that’s attributed to you: that significant power is available in the airframe without engine or APU electric power generation to have maintained the function of the air-ground satcom system and any necessary ancilliary avionics (not the ELTs).
We haven’t discussed RR EHM here in a long time.
GuardedDon said,
May 5, 2014 at 3:50 am
@airlandseman
Don’t quite understand the provenance of that doc above (May 4, 2014 at 9:03 pm). I expect to complete a draft of an evidence evaluation matrix derived from Friday’s MoTM releases & post late today.
I have no doubt, expressed many times, that the 25 Mar BFO Analysis chart did not correlate all the comms events on the satcom datalink after the departed the gate.
Mikhail said,
May 5, 2014 at 6:00 am
Hi All,
Subject (slightly off-topic, apologies): suggesting a new search area centred at (20.00 S, 103.45 E).
Assumption: the current search area is defined by the Inmarsat’s final (partial) ping ring, intersected by an acoustic bearing from Cape Leeuwin.
Inference: extend this acoustic bearing to intersect with the new Inmarsat’s final ping ring, corrected due to the modified elevation angles. The new intersection is centred at approximately (20.00 S, 103.45 E).
Curiosity: the new intersection is also a point equidistant from three centres with radar capabilities: RAAF Learmonth, Christmas Island, and Cocos Islands, with the distance of 600 nmi = 690.47 miles from each centre.
Details: https://sites.google.com/site/mh370tibet/updates/05may2014
Thanks,
Mikhail P.
seanmcleod said,
May 5, 2014 at 6:24 am
@RWMann
In terms of the RR EHM (Rolls Royce Engine Health Monitoring) I think you’re confused by some of the very early press reports regarding RR EHM data transmissions.
It was made clear later on by the authorities that no ACARS data was transmitted after 1:07am MYT, and that the satellite communication that continued for the next 6 hours or so didn’t involve any data transmissions, only pings/handshakes.
There is no evidence that “…EHM system continued to operate…”.
nihonmama said,
May 5, 2014 at 9:12 am
@ Alex Siew
You’ve probably seen Victor’s most recent analysis (dated 4.29), but wanted to share this tweet/convo since you’re not on Twitter:
https://twitter.com/RadiantPhysics/status/461526940877606912
nihonmama said,
May 5, 2014 at 10:07 am
@ airlandseaman
Re your question -the 4200/7200 with a Ball Airlink HGA system.
Have you been able to get any insights on this from a 777 pilot or mechanic? Or inquired directly with Honeywell? Not all pilots have an in-depth knowledge of some of these systems, but some do. I know this because I hail from a big airline family, and one of these is a long-time captain with extensive experience in the 777. He has already confirmed some very interesting info re the SATCOM on this a/c. If you think it would be helpful, I could pose your query to him – namely, whether or not the MCS 4200 has a backup battery.
nihonmama said,
May 5, 2014 at 10:14 am
@ airlandseaman:
To clarify:
I would be confirming that the battery is only for a BITE memory, not the operation of the entire AES.
airlandseaman said,
May 5, 2014 at 12:18 pm
nihonmama said,
May 5, 2014 at 10:07 am
Thanks for asking. It has been confirmed that the Honeywell 4200 has no built in UPS or the like. It only has a small battery to power a non-volatile memory used for BITE. It has also been confirmed that the 4200 derived it’s Doppler Tx Offset from the AIMS/IRS data via AIRINC 429 connection. All the information we have points to a failure of the source or connection providing this data to the SDU in the AES. It has also been confirmed that the SDU is collocated with the antenna in back. All this together supports the theory that the BFO data may have no offset applied, and therefore can be used as true L band Doppler after 17:07, which is easily converted to LOS Speed between the satellite and the aircraft. This in turn is a strong constraint on the path solutions.
Alex Siew said,
May 5, 2014 at 4:10 pm
@airlandseaman,
I had always stated expressly that the battery in the SDU would power memory and the clock but posed the question whether in the event of loss of primary power, this battery could have been the residual power that powered those faint pings. U have answered no.
I had also posed other questions which have remained unanswered. For proper closure on this issue, can i ask u for your take on these questions:
1. The Honeywell’s manual is replete with references to the phrase ‘primary power’. For eg in the electrical installation section: ” The SDU primary power is supplied to either +28V dc…or… 115V ac..”. The same statement is repeated for the HSU and the HPA. What does the phrase ‘primary power’ mean and would it suggest there is secondary power somewhere?
2. The draft manual for Iridium systems previously cited says “As all the avionics, the AES will be designed so that [mean time between failures] is as long as possible whereas the [mean time to repair] is as short as possible. These two requirements will apply to essential airborne units such as the satellite data unit, communication management unit, beam steering unit and the antenna sub system. This may be achieved by main/hot standby configuration of the critical units stated above, as well as automated change over mechanism within each unit”. To your knowledge, would the satcom components on Boeing planes, as a general rule, have main/hot standby configuration and/or inbuilt automated change over mechanism?
3. In the Failure Description section of the Honeywell manual (Page F-13), there is a failure described as follows: ‘Code 01 1 40 [HGA HPA] INTERNAL POWER SUPPLY FAIL’. What does it mean?
4. The various pings are said to be ‘faint’, meaning much below normal signal strength. What in your view, is the reason for this abnormal signal strength.
5. Various other components stopped functioning eg transponder for the secondary radar signal, the ADS-B, the ARINC 429 bus etc (see Bill’s analysis in Duncan’s blog). These components could have been intentionally disabled or it could be a case of electrical failure. Assuming the latter, would the electrical power supply configuration of a Boeing 777 allow for power to be still supplied to the satcom avionics at the back if the system is failing to provide power to the avionics up in front, or would all the avionics be supplied by common cables?
As usual, the laypeople on this blog stand to be guided by u.
Alex Siew said,
May 5, 2014 at 4:49 pm
@RWMann’
Thank you for responding to the request to come over to give your views. Much appreciated. Please continue to ‘monitor the frequency’.
@Nihonmama
Thank you for pointing out Victor’s analysis. I am not on Twitter but i do click on various people’s twitter to keep track of their thinking, including yours.
airlandseaman said,
May 5, 2014 at 5:52 pm
lex Siew said,
May 5, 2014 at 4:10 pm
The phrase ‘primary power’ means the input power, 28VDC or 115VAC. Internal power supplies convert the 28VDC or 115VAC primary power to various DC bias voltages needed to power different circuits. It does not suggest (to me) there is secondary input power source in the context of a UPS. The HPA power failure alarm is referring to a failure of the DC-DC converter and/or regulators used to supply high DC power to the 60W HPA. This is a high current circuit that generates some heat. This is one of the converter/regulator circuits I refer to above, and monitored because it is somewhat more prone to failure, due to heating, than the lower power bias regulators used to power logic and low leb=vel analog circuits.
I don’t know the details of the redundancy used in the Inmarsat terminal.
I have never read anything about the Handshakes having unusually low received signal strength. That characterization may be in reference to the fact that the signal strength of normal satellite signals is “faint???. If lower than normal, it would not have anything to do with the primary power. It would probably mean the Ball HGA was not being steered to the satellite optimally due to the loss of the Nav data. The internal voltage regulators maintain a constant voltage on the HPA over a wide range of input voltages. The HPA will also have a special circuit to monitor the output power and adjust the gain to produce a constant power output per carrier. So the TX power remains constant over a range of input primary voltage.
The primary power to the system in back will be supplied by an independent circuit, not the same circuit powering anything in front.
airlandseaman said,
May 6, 2014 at 7:51 am
This is an older CNN video, but relevant to the power discussion.
http://t.co/XX5lSuDnVc
seanmcleod said,
May 6, 2014 at 10:55 am
airlandseaman said,
“All this together supports the theory that the BFO data may have no offset applied, and therefore can be used as true L band Doppler after 17:07, ”
I’m not so confident that the AES TX Offset was 0 after 17:07.
When the authorities released the BFO analysis they included 2 possible southern tracks, the yellow 450kt track and the red 400kt track –
https://www.facebook.com/permalink.php?story_fbid=740971779281171&id=178566888854999&stream_ref=10
So my assumption is that both those tracks matched the BFO data otherwise they wouldn’t be included in the same presentation.
GlobusMax digitized the tracks to work out coordinates for each of the satellite pings.
I took the digitized points and then worked out a constant bearing between subsequent points and then used that to derive the LOS Speed for each ping point.
Given the nature of the digitization etc. his ping radii don’t exactly match the new ones we have from the Inmarsat elevation data from today.
GlobusMax 454kt Southern Check
(Lat,Lon) Bearing Ping Radius(nm) LOS Speed (kts)
(-3.28, 93.25) 191.8 1749 10.95
(-10.67, 91.68) 186.9 1781 -68.04
(-18.18, 90.72) 184.3 1944 -133.24
(-25.71, 90.1) 184.8 2192 -179.55
(-37.13, 88.91) 184.8 2640 -244.58
GlobusMax 394kt Southern Check
(Lat,Lon) Bearing Ping Radius(nm) LOS Speed (kts)
(0.63, 93.47) 178.1 1739 -16.14
(-5.92, 93.69) 177.3 1806 -61.84
(-12.47, 94.01) 163.1 1946 -150.66
(-18.73, 96.02) 164.3 2210 -179.55
(-28.28, 99.06) 164.3 2638 -220.53
At roughly 2.82Hz/knot for the LOS Speeds calculated for the southern routes I get the following AES TX Offsets for the last 4 pings:
00:11 – 338Hz
22:40 – 224Hz
21:40 – 147Hz
20:40 – 21Hz
So in terms of working out the AES TX Offset assumed in the BFO graph for the southern route I don’t see a constant offset for these tracks.
airlandseaman said,
May 6, 2014 at 11:57 am
seanmcleod said,
May 6, 2014 at 10:55 am
re: “So my assumption is that both those tracks matched the BFO data otherwise they wouldn’t be included in the same presentation.”
Why do you assume this? I see no evidence whatsoever that Inmarsat ever tried to use any Doppler data in combination with the elevation angles (ranges) to calculate the paths. Everything I read in the March 25 document, and have picked up in McLaughlin interviews, suggest that Inmarsat wrote-off Doppler data as unrecoverable (due to the presumed AES TX offset), and instead, used the BFO analysis for the sole purpose of trying to distinguish some general north vs. south pattern. I see no attempt to include the BFO data in the analysis beyond that. If you think otherwise, please explain.
seanmcleod said,
May 6, 2014 at 1:16 pm
Hi airlandseaman
Couple of reasons why I assumed it to be, have asked a couple of times before on this blog and never received a response until now.
There were only 3 slides in the BFO presentation which was all about the BFO analysis so I’d be surprised if the routes presented in this package didn’t match their “predicted burst frequency offset for the southern route”.
How did they predict the BFO for a southern route that so closely matched the measured BFO as shown in their BFO graph if they didn’t have a model for the AES TX Offset?
Do you think that it’s simply a coincidence that the LOS speeds for the 450kt and 400kt tracks are a ‘pretty good match’ to each other, on the order of 10% or less based on digitization process of a low res image?
If the assumption that the AES TX Offset went to 0 after 17:07 then Inmarsat assuming they haven’t missed this possibility would have an exact model of the AES TX Offset and as you said the L-Band Doppler would be an exact match for the LOS Speed and with this they could generate possible tracks like the 450kt and 400kt track that matched the BFO.
As an alternative to the assumption that the AES TX Offset went to 0 after 17:07 is that Inmarsat have a model for the AES TX Offset for this period that isn’t as simple as a fixed offset and again used this model to generate possible tracks that matched the BFO and hence produced the green and red lines in the BFO graph and the 2 Google Earth tracks.
In the articles quoting McLaughlin I haven’t picked up any explicit mention that they couldn’t recover the Doppler data.
Cheers
airlandseaman said,
May 6, 2014 at 4:13 pm
seanmcleod said,
May 6, 2014 at 1:16 pm
Re-reading the March 25 memo again for the 20th time, I did find a statement that supports your belief that Inmarsat used the BFO data for more than the general direction. It states in part: “Knowing the system characteristics and position of the satellite it was possible, considering aircraft performance, to determine where on each arc the calculated burst frequency offset fit best.???
That said, can we agree that the Offset algorithm was working well before 17:07, and poorly by the end of the flight? At 17:07, straight and level at 35,000 feet, 25°, 468 kts, ROC=0, the offset algorithm produced an offset that was within 13.6% of “perfect” (that is, residual D1+D2=-62 Hz vs. ground truth zero offset Doppler =-463Hz). I think at least 4 people have verified this finding (and the other 3 “calibration points???).
Assuming similar offset algorithm accuracy, by 00:11, the D1+D2 observation (-353 Hz) would imply a zero offset Doppler of -353/0.135=2615 Hz and an LOS speed of 927 kts. LOS speed mapped to the horizontal plane at an elevation angle of 40 degrees gives 1210 kts radial speed component, and higher aircraft speed, depending on the tangential velocity. If the math is right, this is conclusive proof that the algorithm was off in the weeds by 00:11. Maybe the offset was not zero, but the algorithm was sure not working normally. If there was an offset, it was much smaller than the Doppler. D1+D2 should be much lower under most normal conditions.
I believe our focus should be on (1) finding someone at Honeywell that will tell us what the MCS4200 does when it loses the IRS data feed, and in parallel (2) deciphering what the 2 “predicted tracks??? mean. One or the other or both are needed to nail down the real meaning of the residual D1+D2 after the assumed loss of nav data.
LGHamiltonUSA said,
May 6, 2014 at 5:19 pm
Hi All ~ Somebody up thread was looking for this:
Investigators incorporated arcane new calculations reflecting CHANGES IN THE OPERATING TEMPERATURES of an Inmarsat PLC satellite as well as the communications equipment aboard the Boeing 777 when the two systems exchanged so-called digital “handshakes.”
~LGH~
airlandseaman said,
May 7, 2014 at 6:30 am
Regarding: Patent Number: 6,008,758
METHOD AND APPARATUS FOR DOPPLER
COMPENSATION IN A SATELLITE
COMMUNICATIONS SYSTEM
In search of additional information about the upper bound on “normal BFO values???, I found the Inmarsat “…frequency tolerance…??? defined in the above referenced patent. The patent states in part:
“To solve this problem, Inmarsat requires that each AES 12 transmit all of its signals to satellite 16 within a defined frequency tolerance (e.g., 100 or 185 HZ).???
The patent does not elaborate on the conditions for the application of the 100 Hz limit vs. 185 Hz limit. It may be the case that the 100 Hz limit is applied to narrow band channels, such as Inmarsat C, while the more relaxed limit of 185 Hz is applied to wider bandwidth channels, like Inmarsat A and packet data channels. An alternative reason for the two limits might be that older equipment is grandfathered with a 185 Hz limit, and newer equipment (with improved reference oscillator technology) is required to operate within the 100 Hz limit.
During the period prior to 17:07 UTC, the AES met the tolerance requirement with a comfortable margin assuming the 185 Hz limit, and also met the requirement assuming the 100 Hz limit. But the limit was exceeded during the last three transmissions assuming the 185 Hz limit, and for every transmission after 17:07 assuming the 100 Hz limit. For the transmission at 00:11, when D1+D2 = -353 Hz, the limit was exceeded by almost a factor of 2 for the 185 Hz limit. If the 100 Hz limit applied, then it exceeded the limit by a factor >3.5.
Of course, this does not prove that the offset was zero after 17:07, but it certainly proves (1) the offset algorithm failed to maintain the carrier frequency within either limit, and (2) the offset must have been at least either 253 or 168 Hz less than it should have been, depending on the applicable limit. Given the actual location, speed and direction of the aircraft for any of the possible areas, it is much more likely that the offset applied after 17:07 was <50 Hz to have produce the observed BFO values. Based on the evidence we have so far, I continue to believe an offset of 0 Hz after 17:07 is the most likely value.
Alex Siew said,
May 7, 2014 at 9:14 pm
@airlandseaman, @Richardc, @Ole, @Skwosh
Since people are focused on the ‘default mode’ of the SDU, i thought i would repost the following extracts from the Honeywell manual at pages 2-2 and 2-3:
” (10) Each AES maintains a system table stored in nonvolatile memory in the SDU.The system table contains the data EIRP table, the satellite and GES identifying information, such as satellite Psid-channel frequencies, satellite locations and associated GES IDs, GES capabilities, and GES Psms-channel frequencies. The system table does not lose its contents because of loss of primary power.
(11) The SDU also maintains a bootstrap system table containing a default set of satellite and GES identifying information. This information includes satellite Psid-channel frequencies, satellite location and associated GES IDs, plus satellite inclination and right ascension, spot beam support, and GES Psms-channel frequencies that are set to zero.
(12) The bootstrap system table is loaded into the SDU as an inseparable part of the upload of executable software. The SDU defaults to the bootstrap system table in the absence of a stored system table, or upon execution of a factory settings restart. The default data for a satellite is used until that satellite is first accessed. Then a complete update of the data for that satellite happens. Satellite region blocks that have not yet been updated over the air are marked with a null revision number.”
airlandseaman said,
May 7, 2014 at 9:24 pm
“…satellite location and associated GES IDs, plus satellite inclination and right ascension, …” hmmm…sounds like the AES SDU had the ability to estimate TX Offset using inclination data. But did it use all the Lookup Table data available?
GuardedDon said,
May 8, 2014 at 11:03 am
@alex siew, airlandseaman, et al.
We’re focussed on understanding the “default”, or fall back mode, of the SDU in a dynamic (ie in flight) scenario where the SDU may no longer be receiving the periodic positional updates from a/c avionics.
The systems tables you reference are the “static” system tables listing all available satellite and the associated parameters the SDU needs to select a satellite, its frequencies, a GES, etc in order to log-in to the service.
airlandseaman said,
May 8, 2014 at 11:32 am
Don:
Yes, understood. The Tables are of little use without the realtime nav data. But it is important to understand the behavior during the 4 calibration handshakes. Why was there any residual error? The residual error will depend in part of the fidelity and accuracy of the realtime range rate calculation done in the SDU. The key question is, did the TX Offset algorithm depend on a “simplified” S/C – A/C model, or “high fidelity” model? Knowing the answer to that qustion will provide a better understanding of the observed residual error during the first 4 handshakes, and maybe someting about what to expect under other conditions.
nihonmama said,
May 8, 2014 at 12:36 pm
@Alex Siew
Don’t know if this helpful for you or not, but read something last night that brought this back to mind – which has been stuck in my head since I first read it. If the pilot has the date correct, it would have occurred on 3.06.14 – two days before MH370.
https://twitter.com/nihonmama/status/442342238098423808
airlandseaman said,
May 9, 2014 at 10:10 am
Ari’s article has really stirred up interest in our work. I’m scheduled for a live interview with Erin Burnett on CNN tonight at ~5:30 MDT. Wish me luck. Job #1: Get the Inmarsat data! Recommendations welcome.
nihonmama said,
May 9, 2014 at 10:33 am
[Also posted on Duncan Steel - awaiting moderation]
Just had a VERY interesting chat with a well-placed old friend/colleague from my consulting days in Asia (she’s still in that part of the world). Re what information is in those pings and why Inmarsat would be withholding that data.
Some of you may suspect this, others may know it, but I share for the benefit of all:
Whether MAS subscribes to a location tracking service or not, the aircraft satcom terminal sends its position WITHIN THE REPLY PING HEADER. Airlines don’t get billed for this, because it doesn’t count as payload data.
In essence, the location data related to the assets of many clients is being tracked through the Inmarsat satcom without their consent.
LGHamiltonUSA said,
May 9, 2014 at 11:29 am
airlandseaman said,
May 9, 2014 at 10:10 am
“Ari’s article has really stirred up interest in our work. I’m scheduled for a live interview with Erin Burnett on CNN tonight at ~5:30 MDT. Wish me luck. Job #1: Get the Inmarsat data! Recommendations welcome.”
Mike ~ This is wonderful news! Erin’s a smart woman so it’ll be easy to be your regular smart self. Don’t get bogged down with too much techie talk because she likes to keep things moving along. Speak to the masses. It’s a rare chance to help the public understand why Inmarsat is not entitled to carte blanche anymore! I am so proud of all you guys! Enjoy the interview, it’s such an honor! Best, ~LGH~
Alex Siew said,
May 9, 2014 at 4:32 pm
@nihonmama
Not quite sure what to make of the ‘tracking’ story. MH370 was a Malaysian flight carrying lots of Chinese nationals but also people from other countries flying over Vietnamese airspace, so unlikely to trigger any interest from anyone.
Regarding your comments elsewhere about reports from locals seeing a low flying jet etc, in my view these people saw some other plane. Bachok and the other places mentioned in those reports lie on the flightpath of planes heading from Malaysia to Thailand and vice versa. U can see those other planes on the videos from FlightAware and FlightRadar24, flying over Bachok for eg during that time. As far as i can tell none of those people said they saw a plane crossing into the mainland on a west east direction.
It is stated (3 times) in the schedule to the Preliminary Report of the recorded calls between HCMCATC and KLATC that HCMCATC last saw MH370 on their primary radar at BITOD. The head of malaysia’s DCA said on March 8th that KLATC had tracked MH370 on their primary radar until 1.30am. He repeated this statement in the days that followed at the various press conferences. (see for WSJonline march 12&13). So Mh370 fell off secondary radar at 1.21am but remained on primary radar of both ATCs until 1.30am up to BITOD.
If MH370 was at BITOD at 1.30am, it could not have turned west or back at 1.21am off IGARI. Also MH370 could not have turned left off BITOD at 1.30am and still make it to MEKAR at 2.22am, as a 777 cannot cover such distance in such time even if it were flying at top speed, especially if it had to fly at below radar altitude and against a NE headwind.
As i have pointed out many times already, there were many military bases and civilian airports/ATCs in the border region between Thailand and Malaysia, ALL WITH PRIMARY RADAR and so far no one has produced any radar recording showing a blip turning back off IGARI or BITOD and crossing over to MEKAR. U will also note that malaysia has seen fit to not mention in the main text of the Preliminary Report that KLATC had tracked the plane until 1.30am on their primary radar, and to ‘seal’ the primary radar recording of KLATC for the period in question. Finally where is the radar recording of this aircraft said to be possibly MH370, making a turn back at some undefined location and time and from some undefined origin.
Despite all of the foregoing, most people on this blog and on Duncan’s blog, still base their modelling of potential flightpaths on this purported turn west and the blip at MEKAR at 2.22am being MH370.
If the plane did not turn west , it could have flown south or north along the arc. Flying south would mean crossing Singapore airspace and as u may be aware Singapore’s defense systems were built by the Israelis and Singapore’s paranoia about hostile neighbours is second only to the Israelis’.
The plane could also have flown north or alternatively it might have just crashed at the South China Sea but CNN at least would never consider that possibility for obvious reasons.
nihonmama said,
May 9, 2014 at 5:21 pm
@Alex Siew:
“MH370 was a Malaysian flight carrying lots of Chinese nationals but also people from other countries flying over Vietnamese airspace, so unlikely to trigger any interest from anyone.”
Well, that statement appears to assume that IF there’s a bad actor involved here, it’s the pax that would be of interest. But what about the plane itself? What about the (inanimate) cargo on the plane?
Your comments about BITOD – agree. Bookmark them.
Re who saw what when? I’m not sure what plane the locals on the east coast of Malaysia saw that night. But from an investigatory standpoint, it would be difficult to exclude 370 without more follow-on interviews with witnesses, which would then be squared (or not) with the data – HCMATC, KLATC, other radar (civilian and or military), FlightAware and FlightRadar24.
And lest we forget, the Malaysians have already sealed some of their radar data and other. How does that possibly happen in the middle of an investigation? More to the point— what don’t they want the public to know?
I’ll just leave you with this convo for now:
https://twitter.com/nihonmama/status/464868214355144704
Have a good weekend Alex. More soon.
SyGunson said,
May 10, 2014 at 2:03 am
Not only has Malaysia sealed their radar data, but the NSA invoked Executive Order #13526 to block a request under the Freedom of Information Act for information held by the NSA about MH370 telling the US Attorney Orly Taitz their justification was that releasing their information on MH370 would harm National Security.
What they are hiding was spelled out in a China Times article published on March 8th 2014:
????????? ???????SOS??
?????????????????????????????????????????5??????????????????????????????????????????????????????????CNN???????????????????????????????????????????????
????????????????????2?43?????????????????????????????????????????MH370???????????SOS?????????????????????????????????????????????????????????????????
It is worth cut and pasting this item into Google Translate to find out what they are concealing. It concerns the distress call from MH370 detected by a USN Intelligence unit at U-Tapao, Thailand.
http://www.chinatimes.com/realtimenews/20140308003502-260401
LGHamiltonUSA said,
May 10, 2014 at 3:47 am
Hello All ~
Here’s the video of last night’s interview of Mike Exner on CNN:
http://edition.cnn.com/video/data/2.0/video/bestoftv/2014/05/09/exp-erin-panel-malaysia-airlines-plane-new-theory.cnn.html
Note that CNN has erroneously captioned the phrase “wrong ocean”.
~LGH~
RWMann said,
May 10, 2014 at 4:16 am
Welcome to the media world of being misquoted/misattributed.
nihonmama said,
May 10, 2014 at 7:20 am
@Sy Gunson
THANK YOU.
nihonmama said,
May 10, 2014 at 8:00 am
@Sy Gunson
1.Executive order 13526, passed in 2009, is an IMPLEMENTING directive that lays out how classified information is to be handled.
http://foia.state.gov/_docs/MDR/135190.pdf
Please provide a credible source (read: not from the myriad of conspiracy websites that have posted this rumour) reporting the issuance of an executive order specifically related to MH370 and national security.
2.The English translation of the article you provide ADDS information that was not contained in the piece that appeared on 03.08 – which was only the last paragraph. So either the original piece was redacted or the version you’ve provided is an ‘update’. It is possible that IF there were an event in the Gulf of Thailand related to 370, Utapao might have heard it – (in a twitter convo I had with RWMann, he noted the possibility that signals can hop – read up in this thread) – but there has been no independent verification of this story. Potentially relevant, many people have noted it, but not verified.
LGHamiltonUSA said,
May 10, 2014 at 12:41 pm
Hello Everyone ~
Here’s the video of last night’s interview of Ari Schulman on CNN:
http://ac360.blogs.cnn.com/2014/05/09/are-investigators-looking-for-flight-370-in-the-wrong-ocean/
Note that CNN has again erroneously captioned the phrase “wrong ocean’. At Mike Exner’s urging, Ari will attempt to bring this misinterpretation to CNN’s attention tonight at 7pmET. Tune in!
~LGH~
Tracking Down #MH370 or Physics of an Air Space Game of Marco Polo | George Hatcher's Air Flight Disaster said,
May 10, 2014 at 9:56 pm
[...] being taken to be at the same latitude in this simplified geometry; and satellite consultantTim Farrar. Recommend on Facebook Share on Google Share on Linkedin Tweet about it Print for later Tell a [...]
Alex Siew said,
May 11, 2014 at 3:36 am
There are more than 900 comments already, the search for MH370 has entered into some sort of a lull and Tim the host of this blog has posted 2 new posts, so this will be my last comment here.
On the issue whether the Satcom terminal had some sort of secondary power to enable it to transmit the pings even if there was no longer any primary power for eg in the event of a crash, please note what Bill said in Duncan’s blog in reply to a comment from me:
” Many pieces of gear have provisions for either AC power or DC power, as well as provisions for redundant power. How they are utilized is up to the airplane manufacturer and the build options chosen by the customer.”
I think Bill has summed it up well. We would not know whether the Satcom components on board Mh370 had a secondary source of power unless Malaysia Airlines/Boeing/Honeywell disclose just what sort of package was installed on Mh370, in particular whether the package provided for a secondary power source or sources.
To @LGHamiltonUSA, thank you for keeping an open mind and posting the lightning theory on your Twitter and on Duncan’s blog. Much appreciated.
LGHamiltonUSA said,
May 11, 2014 at 4:36 am
@AlexSiew ~
Absolutely my pleasure. I’ve enjoyed posting with you. I will continue to maintain your “Lightning Theory” wherever appropriate. I know you’ve put your heart & soul into its formulation. I admire your intellect and tenacity. Let’s continue our association whenever we have the opportunity!
~LGH~
Sid said,
May 14, 2014 at 5:28 am
Good Morning wherever you are in the world…
Some time ago I posted a proposed route computed using the spread sheet model of aqqa and input data based on Mike Exner’s work and others. I have continued to work with aqqa on improving the details in the model and have now done two paths to the North. They appear to be the only basic solutions in that direction (although the end point details are not completely understood). So so to be economical of space here, the end point coordinates are : 42.01 N and 71.56E for a path to the Northwest 30.10N and 94.00E for a path to the North.
Graphs, tables etc may be found at https://dl.dropboxusercontent.com/u/15200211/Links%20to%20posted%20documents%20-%20.docx
LGHamiltonUSA said,
May 15, 2014 at 4:23 am
Hello All ~
I was reminded of this previous TMF blog comment about spoofed pings when I read the following tweet yesterday regarding the matter of missing flight MH370:
“We are very confident that this data is correct assuming that there is no other way this data has been spoofed…” by May 14, 2014 APEXTC event Panelist David Coiley – Vice President, Aviation, Inmarsat to Mary Kirby – Founder & CEO, Kirby Media Group
A further discussion of spoofed pings can be found here.
~LGH~
MH370 Flight reconstruction (Part 7) | The MH370 Skeptic said,
May 24, 2014 at 9:18 pm
[...] Understanding the “satellite ping??? conclusion… (–click here for link) [...]
LGHamiltonUSA said,
May 29, 2014 at 10:37 am
LGHamiltonUSA said,
May 15, 2014 at 4:23 am
http://www.runwaygirlnetwork.com/2014/05/27/inmarsat-confident-mh370-data-correct-assuming-it-hasnt-been-spoofed/
David Coiley, VP Aviation Inmarsat, on the chance of “spoofed data” stated:
“All I can say is we are confident of the data that we have submitted. At the coffee break earlier, I was talking to some of you, and if there is any concern it is the most elaborate situation that probably comes somewhere the far side of Pluto.”
~LGH~
Dazza said,
June 18, 2014 at 4:18 pm
Has anyone considered that the aircraft was programmed to fly by auto pilot to a GPS way point called RERAB deep in the Southern Indian Ocean via RUNUT way point.
USE . http://www.skyvector.com flight planning to map track
RERAB S43 00.00 E 75 00.00
RUNUT S13 49.730 E 91 22.230 my trackpasses within 14 nm of this point.
RERAB is located between two islands Martin De Vivies lle Amsterdam and French Southern Antarctic Lands.
The PR_00_10_48 ping line from Duncan Steel KLM file passes within 71 nm of RERAB.
I have calculated the ground speed from the completion of the 180 degree turn at IGARI way point to last primary radar contact position, distance 492 nm in 55 minutes 46 seconds equals 529.34 kts.
Use this ground speed and plotting against the PR rings supplied by Duncan Steel, my flight path ends 74 nm bearing from 049T from RERAB way point.
Your thoughts please Dazza
Links to Previous Posts on the Inmarsat-3F1/MH370 Ping Analysis Saga | Duncan Steel said,
August 27, 2014 at 11:08 am
[...] Understanding the “satellite ping??? conclusion… [...]
Developments in Investigations of the Route Taken by MH370 | Duncan Steel said,
September 11, 2014 at 2:14 am
[...] he may, after herculean efforts, have broken the Burst Frequency Offset code. See his post here. This is important, and all (of course) subject to revision and [...]
The Inmarsat-3F1 Doppler Data Do Not Exclude a Northerly Flight Path for MH370 | Duncan Steel said,
September 11, 2014 at 2:16 am
[...] graph in different places, for example amongst my posts on this website itself and also at the TMF Associates blog site on this [...]
WIESO IST FLUG MH-370 NOCH IMMER VERSCHOLLEN? … | farsight3 said,
March 8, 2016 at 6:08 am
[...] sollten uns aber auch noch mit jener Firma näher befassen, welche letztendlich die Spur gen Süden auslegte, der die Weltöffentlichkeit, samt unzähligen Suchschiffen folgsamst nachlief. Die Aufgabe des [...]