by Victor Iannello
Note: Ever since the idea of spoofing was first discussed, one of the main issues has been how falsified BFO values might have been calculated. Most of assumed that the values were arbitrarily selected to suggest a flight in a generally southward direction. Here, Victor Iannello presents an ingenious suggestion: that hijackers might have altered a single parameter in the Satellite Data Unit frequency precompensation algorithm. — JW
Notice: The views expressed here are solely mine and do not representthe views of the Independent Group (IG), Jeff Wise, or any other group or individual. — VI
Summary
In previous work, paths were reconstructed for MH370 using the available radar and satellite data. Paths to the north of Malaysia were studied bymatching the measured Burst Timing Offset (BTO) data, but relaxing the constraint of matching theBurst Frequency Offset (BFO), which is appropriate if the BFOdata waseithercorrupted or misinterpreted. It was found that there are paths to the north that end at airports that could be reached with the fuel that was loaded onto MH370.In this work, the conventional interpretation of the BFO is challenged. In particular, the possibility that the operation of the SATCOM was deliberately modified so that a northern path would have the BFO signature of a southern path is studied. Some of the findings are:
- The Honeywell Thales MCS-6000 SATCOM used by MH370 hasafrequencycorrection algorithm withthe capability to correct for the Doppler shift caused by inclination of thesatellite. This is known to the official investigation team butis not generally known by independent researchers.
- The value of inclination for the Inmarsat I3F1 satellite that was broadcast by the Ground Earth Station (GES) at Perth, Australia, to be used by SATCOMs logged into the satellite, was zero. The true inclination of the satellite was around 1.65⁰. The two parameters that describe the satellite inclination, the inclination angle and the time of the ascending node, are stored in the System Table of the SATCOM in non-volatile memory, and are used by the frequency compensation algorithm.
- If an individual obtained unauthorized access to the non-volatile memory of the SATCOM, the value of the inclination used by the frequency correction algorithm could be changed from 0 to 3.3⁰, or about twice the true inclination of the satellite. With this change, the BFO signature of a northern path that satisfied the BTO data would resemble the BFO signature of a southern path that satisfied the BTO data.
- The apparent turn to the south between 18:28 and 18:40 UTC that is suggested by the measured BFO data might have been caused by a change to the inclination parameters stored in the SATCOM’s System Table during that time interval.
- The calculated values of BFO for northern paths with the inclination parameter changed to 3.3⁰match the measured BFO values with an RMS error less than 3.8 Hz. This is true for Mach numbers between 0.65 and 0.85 at FL350, with little variationin errorseen in this speed range.
- At each log-on, the inclination parameters would be reset to zero. Therefore, the BFO data associated with the log-ons at 18:25 and 00:19 UTC should be evaluated with inclination parameters set to zero. The BFO data at times between these log-ons should be evaluated with the possibility that a change was made.
- The BFO value at 00:19 matches an aircraft along the northern part of the 7tharc on the ground and stationary once the BFO is adjusted for the log-on offset seen at 16:00 UTC. This suggests that if MH370flew north, it might havesuccessfully landed.
- Researchers have identified security vulnerabilities in other SATCOMs, including backdoors and access to memory, although the MCS-6000 has not been specifically studied. The possibility of “spoofing” the BFO to disguise location has been considered before.
Read the whole report here.
@Nihonmama, I have to agree with you. If we are really looking at a successful spoof the perps must’ve learned somehow about the insider fact that the satellite was considered to be geostationary while in reality it had developed a small orbit. And that Inmarsat needed a compensation algorithm because of that. How could the perps possibly have acquired that knowledge? And how could they be (or make) sure that Inmarsat would actually use these procedures for determining that the plane must’ve gone South? If one contemplates at least the possibility of a spoof these are very intriguing questions.
Littlefoot – I could be wrong but I thought all so called geostationary satellites bobbed around a bit, it’s a case of how much. The Russians/Iranians for instance would be well across that, and if it’s part of a network used by US/UK etc they would have it pegged anyway.
I think some concepts are getting muddled a bit. First, the orbit inclination of the Inmarsat satellites are well-known. The orbit characteristics are published by the Joint Space Operations Center (JSpOC).
If the BFO spoof occurred in the way I proposed, the following knowledge would need to be known by the perps:
1. The AES frequency algorithm details, including the capability to model and compensate for the satellite inclination. (I don’t think this was publicly known until I disclosed it, first on this blog and then in more detail in my last study.)
2. The value of inclination that was broadcast by the GES to be used by the AES in its frequency correction algorithm. In this case, the value was zero.
3. An understanding of how velocity information could be extracted from the BFO.
4. A belief that Inmarsat would use (3) to guide the search.
The technical knowledge was resident at Inmarsat and Honeywell Thales. With the worldwide business partners of these organizations, this knowledge could have been known around the world. Gerry Soejatman, for instance, talks about BFO spoofing that he learned about when he worked for an Inmarsat reseller in Indonesia.
@Victor, this info from Gerry is interesting. Does that imply some factions were aware of the possibility to make a North vs. South distinction with data from an Inmarsat satellite, because the fact was known that Inmarsat dealt with the problem of it’s orbiting satellite by using this compensation algorithm? How widespread could that knowledge have been? Would Inmarsat have to tell it’s customers about it?
When everybody was clamoring a year ago to get an explanation from Inmarsat how the North vs. South distinction was made, I was surprised how reluctant they were to disclose it. When they finally relented and published their so-called “raw data” the truly important info about the fact that the satellite was treated as geostationary although it had developed an orbit and therefore the need of an compensation algorithm was hidden in the small print so to speak.
@Matty, you’re right about most so-called geostationary satellites having developed a small orbit.But I understood there are different possibilities to deal with that problem. Using a compensation algorithm was just one method. So the perps had to learn how exactly Inmarsat dealt with the problem of their wobbly satellite.
How difficult is it to manually enter a satellite inclination?
I do not have the manual for the MCS-6000, but I did snare one for the MCS-7200. On this system, the “bootstrap system table” (which is what one gets fresh from the factory) is described as being an inseparable part of the upload of executable software. After, the system table is updated only as part of logging on to a satellite. I don’t see any provisions for manual entry of satellite parameters. While one could likely hack the system, it would require particularized knowledge of the innards of the software and storage systems.
On the Rockwell-Collins 2100/6100 SATCOM, however, it possible. On p. 2-22 (pdf page 102), there is a whole section “Set Satellite Regions” where all the parameters can be entered for any satellite. The only constraint is that all quantities are quantized – 3 bits for inclination (intervals of 5/8 deg) and 8 bits for right ascension (intervals of 10 minutes). This info gets written to a file, which is uploaded to the SATCOM. Not sure how easy that last step is.
@sk999: The RC manual guided some of my thinking. For instance, it is possible on the RC to reboot and enter a maintenance mode, which is interesting because if this was possible with the MCS-6000, what researchers think might have been a power cycle could have been a reboot. This is not a documented feature for the MCS-6000.
For RC, the satellite orbit parameters in the menu change the values in the ORT, not the System Table. That affects where the AES looks for the satellite, but the System Table values broadcast by the GES should be the ones used for operation once logged-on.
Of course, the frequency compensation is much different for RC. The specific algorithm does not use navigational input and satellite orbit estimation, but rather looks at the frequency shift the P-channel signal it receives to determine how to pre-compensate its transmission.
@littlefoot: I do not know how widely known the frequency correction algorithm on the MCS-6000 would be known to Inmarsat’s partners, especially as it relates to satellite inclination, and even more specifically, path reconstruction. That’s really getting down into the weeds.
I am trying to learn more from Gerry to try to understand his comments better.
VictorI,
Thanks for that clarification of ORT v. System Table.
Victor,
I applaud you and think too this is brilliant and amazing work you have done. Didn’t Sara Bajc say from the get go that she thought this plane was taken and her initial keen intuition make come to be proven yet, i.e. Victor or Jeff’s theories.
If the firmware upgrade (I think that was the software name)had been done to the GES in Perth, then would what the GES sputted out to the AES have been different, or not at a zero value? Would the compensation algorithm have been automatically incorporated in that upgrade that wasn’t done? Did Inmarsat set the value to zero manually? (Forgive me if dumb questions, I’m muddling along in class here still getting my avionics degree!)
Agree with most here no matter how we shake out all the facts all those scenarios described here are still on the official table.
@Cheryl: This all gets quite confusing at first glance. There is frequency compensation (Doppler correction) both at the AES and the GES. The compensation at the AES corrects for the Doppler shift on the L-band uplink from the aircraft to the satellite and the compensation at the GES corrects for the Doppler shift on the C-band downlink from the satellite to the GES.
The software glitch at the GES would not affect how the AES should operate to produce the proposed spoof of the path. The software glitch meant that after the fact, Inmarsat had to apply another correction in order to properly extract the data about the path from the BFO. The perps did not need to have any knowledge of any of this.
Victor,
Thank you for the explanation. Got it.
That glitch, if anything a bit embarrassing for Inmarsat I had thought when it was exposed way back on Duncan Steel’s blog. The bypassed upgrade created more work for them on this case of MH370. I wonder why after AF447 talk of future tracking this upgrade wasn’t done. I wonder if it’s been done within this past year after MH370.
@VictorI:
I’ve re-read the Inmarsat article in the Journal of Navigation and didn’t find a reference to a ‘software glitch’. Was it discovered only recently?
If it was, doesn’t that indicate that Inmarsat never tried to geo-locate an airplane in flight from BTO and BFO prior to MH370?
@Gysbreght, as far as I know Inmarsat has indeed never tried to locate a plane before mh370 by using BFOs and BTOs. That’s why their spokesmen were talking about “new math” having been developed – a statement, which caused a bit of ridicule amongst natural scientists.
Anyway, the big question is of course in a spoof scenario: how could the perps be sure Inmarsat would really do the necessary computations, which placed the plane’s crash site in the SIO?
The ‘glitch’ is the error in the firmware in the Perth EAFC receiver that introduced an unnecessary (and large) contribution into the BFO.
The JoN paper refers to it as “For operational reasons associated with the hardware used to implement this AFC loop in the Perth GES it only partially compensates for the downlink Doppler”; the ATSB report also discusses it. It was understood by Inmarsat from the start, otherwise no fits at all would have been obtained by their early analysis.
Also, it wasn’t a ‘glitch’ it was a ‘bug’.
@Richard Cole: Actually, the bug in the MITEQ pilot receiver at Perth was not known from the start. It took about a week to discover it, as per a source in contact with Inmarsat. It was for this reason that they had some initial trouble matching the BFO. Of course, by the time the results of the BFO/BTO analysis were made public, it was identified and a correction included in the analysis.
@Gysbreght: I am not sure what previous work Inmarsat had done studying the BFO and BTO data and their relationships with paths, and in particular with path reconstructions. We know that it was never done before for an accident investigation. If they had studied this before, I would guess that I3F1-Perth link was not studied or they would have discovered the software bug prior to the disappearance of MH370.
@VictorI
The Doppler/BFO contribution from the bug would have been present in all C-band traffic received at the GES for many years, but was not relevant to operations. I guess what you are saying is that Inmarsat had never felt the need to identify the source of the error and hence its precise magnitude. I stand corrected.
@Alex Siew: The two formula are the same. The grouping of terms is different, and the definition of the terms was a bit cryptic in the original presentation, but there was no change in formula, and we now know that neither was “bogus”.
Bobby has never attributed the BFO only to the movement of the satellite after 19:36.
Please stop inventing facts.
@Richard:
If you’ve read my “Concerns” report, you can guess at the degree of faith I had – even BEFORE the towfish arrived – in the authenticity of this search.
Either they already know where the wreckage is in the SIO – and are finding it according to a schedule (and reverse-engineering the search rationale accordingly) – or they know it ISN’T in the SIO – and are running out the clock (and prospecting for minerals in the mean-time).
By demonstrating yet another gap between what search leaders decide and what the data support, my stochastic simulation paper merely supplements the wealth of scientific research which had already made clear how ridiculous the third option (authorities are searching in good faith, and should be given all the time and resources they say they need to find MH370) has become.
It is not difficult to make this case to friends and family – my technical mumbo-jumbo usually just confirms what they had already sniffed out intuitively.
But online, many folks remain quite determined to have us continue to trust authority. My paper, Richard, is for THEM.
Brock – Despite the many assertions of confidence and authority by people more qualified than myself I always thought that the planets really needed to line up for that plane to be where they said it was and outed myself as a search pessimist right there. Now I think we know that alignment never existed anywhere-anytime. That’s the bit they gloss over, but but you’re right about the public, they didn’t lose sight of the pea and stepped off ages ago. These MH370 doco’s that use the same old quotes and interviews often show a British aviation figure sitting in a cockpit saying – the public just won’t accept that we have lost a 777. The task of conveying this to the public however is going to be a monumental press conference and it’s edging closer. Unless we get lucky it will happen next year some time. I’m sure it’s not just the relatives who are glad the search is continuing.
@Matty
I certainly agree that the extension to 120000sq.km. is the final one. The words in the press release of the tri-partite meeting don’t give any expectation of further work and the ATSB statements have recently added the rider “Beyond that, it is not possible to refine the search area ….”. So we can’t expect any more interviews from ATSB that could give any implication of an on-going search, rather more language like “…commitment to finish our task…”, “…teams working under gruelling conditions…”, “…we knew the task would be difficult…”, “…searched an area the size larger than Tasmania or Ireland yard by yard [metre by metre?]…”. As you say, that won’t make the final statement much easier.
If they don’t find it.
In order to help the investigation, I compiled some questions that should be part of any investigation into the disappearance of MH370:
1. Why was the GES at Perth broadcasting an orbit inclination of zero for I3-F1 IOR when the actual orbit inclination at the time of the disappearance of MH370 was around 1.65 deg? If the actual inclination had been broadcast, it would have been impossible to use the BFO to distinguish between a path to the north and a path to the south since 9M-MRO’s SATCOM would have properly corrected its transmitted frequency to compensate for the satellite orbit’s inclination.
2. Why did 9M-MRO’s SATCOM log-off I3-F3 POR and log-on to I3-F1 IOR around 16:00 UTC? Was it a forced (manual) hand-off? Although KLIA is closer to IOR than POR, the flight to Beijing would be in the direction of POR, and Beijing is closer to POR than IOR.
3. Was Satellite Controller Stuart Fairbairn, who died unexpectedly on March 17, 2014, responsible or have knowledge of satellite operations related to I3-F1, including but not limited information in the System Table that was broadcast by the GES at Perth? Was his death questioned as part of the investigation?
Victor,
For consideration, not in defence of any particular party
1) Change introduces risk. If it ain’t broke don’t fix it. Why would a service provider amend the inclination if the system continued to operate within specification (ie AES’ weren’t exceeding the channel bounds).
2) The aircraft was powered up at approx 12:50UTC, IIRC, the FI release describes this and the event is corroborated by the APU shutdown ACARS report around pushback time. The flight crew (Zaharie & Fariq) started preflight procedures, including IRS alignment at approx 16:00. The AES then ‘knew’ its location & transitioned to HGA & the appropriate service region, IOR, given its location. I will suggest that POR via LGA was initially selected after the 12:50 power-up as it was the previous region used for Log On & no IRS data was available to the AES.J
3) No comment.
:Don
@GuardedDon,
Thank you, Don. Your answers are reasonable, but do we know the answers with certainty? Some comments:
1. I am not talking about amending the inclination of the satellite, of course. I am talking about using the correct value of the inclination in the System Table. I have shown that for large inclinations, compensation for inclination is required to remain within the ICAO spec. The system is already designed to correct for inclination. Was this compensation required for an inclination of 1.65 deg? Probably not, but why not take advantage of the capability that already exists? I see very little risk and improved uplink Doppler correction gives extra margin for other effects (like the fixed frequency bias and the partially functioning EAFC).
Also, independent of Doppler correction, broadcasting the correct inclination parameters will allow better pointing of the HGA. At some positions, 1.65 deg of latitude change can represent a significant pointing error.
By the way, the orbit inclination of I3-F1 has increased to 2.53 deg as of today. My guess is they are broadcasting the correct inclination parameter as the Doppler correction error would fall out of spec.
2. The initialization of the IRS could have been what triggered the hand-off, although if the signal was good from POR, I am not sure it would have automatically handed-off. After all, it did not hand-off to IOR from POR on the previous flight. In any event, I think we need to know for sure whether the hand-off was automatic or manual.
3. I understand. That is a difficult topic to discuss.
I will say there is something else that disturbs me greatly that is not obvious to many people.
In the original signal logs released by Malaysia in May 2014, in the ATSB report released in June 2014, and in the Inmarsat JON paper in Sept 2014, it is claimed that the algorithm in the AES for Doppler frequency correction is based on a geostationary satellite. We now know this is a false statement. In fact, I was chided by others for pursuing this because the language was so clear.
The AES algorithm makes the frequency correction based on a near geostationary, inclined orbit approximation, where the value of inclination that is used is based on the value in the System Table as broadcast by the GES. The GES was broadcasting an incorrect inclination of zero, and so there was no correction for this inclination.
Why was the algorithm and the incorrect value of inclination not described in this manner? I only discovered this because I asked the right question to the right person. Otherwise, we still would know this.
If the inclination parameters were not altered, it would not make a difference. But knowing how the system really works opens new possibilities regarding tampering and deception that otherwise would not be considered.
If I was a suspicious person, I would conclude that there was a deliberate attempt to conceal the true operation of the system. Of course, I try not to jump to conclusions.
Victor
Victor,
Concerning 1) I should have been more succinct: I was questuining why update the system table with the inclination & right ascension parameters if the received bursts from the AES aren’t breaking the channel frequency bounds. Any change introduces a risk to service. From personal experience, unless there’s a negative cost impact, the directive will be leave well alone & mitigation of future cost doesn’t cut the argument. The desired outcome is not ‘better’ but rather ‘not bad’.
The HGA ‘boresight’ gain pattern is not so critical, the -3dB contour is at least +/-5° from centre.
2) Following the pre-16:00 description for aircraft/satcom/ACARS activity in the FI release the events are consistent with the preflight checklist: entering the route, initialising the IRS and inhibiting VHF as an available datalink in ACARS Manager. At the KUL gate position, POR elevation to -MRO was very low (figures not to hand just as I write). At 12:50, when powered by the APU, -MRO may have been parked at the cargo ramp or the maintenance ramp with IOR, possibly, obscured.
At the departure gate, POR would have seen -MRO at approx 5° elevation, good enough for an LGA Log On.
:Don
@GuardedDon: I did some quick calculations. For a 1.65 deg inclination, the error in Doppler correction can grow to about 60 Hz. That is a significant part of the 100 Hz budget for compensation error. Considering that vertical velocity is not compensated by the AES, that 100 Hz budget can get eaten very fast as the error due to vertical velocity is about a 18 Hz/ 1000 fpm. That is why the inclination was included in the satellite model for the AES: it is necessary to ensure adequate performance. It makes no sense not to allow the AES to use the full capability of its frequency correction algorithm. There is zero risk and a good potential to avoid a problem.
How do we know that the correct inclination parameter was not broadcast for prior or subsequent flights to MH370? That is another important question that should be asked, and we should not make an assumption.
I looked at the pointing error for an inclination of 1.65 deg. The maximum pointing error is about 1.2 x the inclination when the AES is right below the satellite. I agree that pointing error is not a factor.
Yes, at 12:50, 9M-MRO might have been parked at the gate with IOR possibly obscured. Or maybe IOR was in plain sight. I think it is wise not to make assumptions. That is my whole point in asking the questions. Too many investigators make assumptions before even asking the question because they think they already know the answer.
@GuardedDon: One last thing about the log-on. For all we know, the ORT was configured such that ONLY constrained (manual) log-ons are allowed. Do we have evidence for the contrary?
Jeff – thought you might enjoy this
http://www.michaelsmithnews.com/2015/05/russian-warplanes-probing-nato-all-the-most-interesting-encounters-since-2013-.html
Victor,
I offered some reasonable answers for consideration, not statements etched in stone.
My experience is that a Service Manager would not accept the statement “There is zero risk” when assessing a change. The maxim I have observed in many tech operations is for ‘good enough’. That the EAFC unit operated for years without maintenance to maintain firmware currency suggests a ‘good enough’ policy.
:Don
@Victor
As you know, engineers are often forced to introduce features into a design to meet specifications based on individual sub-budgets that have been simply divided from a larger budget. It is another matter whether an operator of a system needs to use all those features when they have the total budget to work with (in this case +/-383Hz) including all the margins. That might annoy the engineer who worked hard to develop those features, but that’s life.
@victorl
“If I was a suspicious person, I would conclude that there was a deliberate attempt to conceal the true operation of the system. Of course, I try not to jump to conclusions.”
in fact, you was curious and this weird info published forced you to find the real truth; yes, it takes time, its not obvious at the 1st sight simply…
@GuardedDon and @Richard Cole: You both have provided reasonable explanations that I cannot dismiss. Let’s try to find the truth so we don’t have to make reasonable estimates. To date, we have all (myself included) made a string of reasonable guesses that has not yet found the plane.
Thanks, Matty. I’ll have to check out that e-book. Would be interesting to know if Russia has been doing any such probing of Chinese airspace.
@Don and Victor,
I can’t believe that an operator would wait until a network would stop functioning to update the inclination parameter. I can see not making a change in the interest of perfection, but to deliberately ignore a potential degradation altogether? If the attitude was “wait until a few calls drop and then we’ll take the same risk we would be taking now anyway” then I’d question every other thing that’s come out of their mouth. If the attitude was “we didn’t know about the inclination parameter,” well, that’s also incompetence.
Giving them the benefit of the doubt, I’m more inclined to think there was a scheduled update that simply hadn’t taken place yet – perhaps months off. Wonder if it has happened yet? That would be telling.
@JS: This is one of those situations where the truth is known to Inmarsat so there theoretically is no need to speculate. We should ask Inmarsat the following questions:
1. Is it standard procedure to broadcast a value of zero in the System Table when the true inclination is non-zero? If so, why?
2. What was the value of inclination for I3-F1 IOR that was broadcast in the System Table prior to and subsequent to the disappearance of MH370?
3. What is the value of inclination broadcast for other satellites in the Inmarsat network?
These are not hard questions that will require weeks of research. The answers will help determine whether or not the inclination parameter was tampered with and will also help us to understand certain performance characteristics of the satellite network.
@Victor – I agree, the answers are known.
Which means, by implication, that Inmarsat also now knows whether the value may have been tampered with. Right?
@JS: If tampering occurred in London, Inmarsat would be aware. If tampering occurred on the plane, they might not be aware. Of course, we have no evidence that tampering occurred anywhere.
Almost had to happen – http://www.theaustralian.com.au/business/aviation/malaysia-airlines-in-administration-assures-no-disruption-to-flights/story-e6frg95x-1227368524486
A question for VictorI or GuardedDon:
Are all terminals using the I3-F1 IOR satellite capable of Doppler compensation for non-geostationary orbits?
@Gysbreght: I would guess that in order to meet the ICAO specifications on AES compensation error, all terminals logged into the Inmarsat network would have the capability of compensating for inclined satellite orbits.
If a terminal is using a compensation algorithm similar to what Rockwell SATCOMs use, i.e., applying a frequency correction based on the Doppler shift measured on the P-channel, then no knowledge of the satellite inclination parameters is required.
@ VictorI:
Thanks foe your reply.
If I may ask more questions: What is the legal/regulatory status of the ICAO specification? Whom does it address? Does it apply to climb and descent? Is it available on line?
@Gysbreght: The ICAO specification is for Aeronautical Mobile Satellite Service (AMSS) and is published on the ICAO site. To help you find the documents, use the following Google search: “ICAO AMSS item-3aXY.pdf” where XY is replaced with the numbers 01 to 10, representing 10 chapters of one version of the document.
I do not know the legal status of the ICAO specification and whether compliance is voluntary or mandatory. Others here might know this better. It looks as though many of the specs were written to level the playing field between Inmarsat and Iridium, but I am just guessing.
I see nothing about disregarding the technical specifications during climb and descent, but I would be surprised if requirements are relaxed.
@VictorI:
Thanks for your help with Google. The following fragment caught my attention:
Doesn’t that mean that the AES is required to maintain the currency of the system table by monitoring the system table broadcast sequences transmitted by the GES, i.o.w. not only during the log-on protocol?
@ VictorI:
P.S.
Does the AES Fixed Frequency Bias of 150 Hz comply with the AES-to-GES frequency error budget that allows +/- 100 Hz for AES AFC error and assumes Doppler to be compensated?
@Gysbreght: If I recall, after a log-on, a partial System Table will be read and internal values updated if the revision difference is no more than 1. If more than 1, the entire table is read and the internal values updated.
Values in the internal System Table are not automatically over-written unless the revision number of the System Table that is broadcast changes, if that is your question.
@Gysbreght: If you look at Table 2-3 in Chapter 2, there is an entry for “AES transmit/receive reference error” where a value of 320 Hz is given, composed of 165 Hz for receive reference error and 155 Hz for transmit reference error. I believe that the 150 Hz bias is part of this error budget and not the error budget for AES AFC error.
@ VictorI:
Yes, that partly answers my question, but also raises another:
My understanding is that the AES needs the system table data in order to send a log-on request to the satellite. If I understand you correctly, at log-on it will compare the broadcast revision number to that stored in memory, and if the difference is no more than 1, it will partially read the broadcast table and update the internal values. Are the satellite orbit data part of the “partial read”? If the revision number has not changed, nothing in the internal system table will be over-written?
With respect to table 2-3, I only referred to it because I couldn’t find the 100 Hz tolerance for Doppler compensation elswhere. Table 2-3 shows the AES-to-GES frequency error budget with a P channel reference, a method of Doppler compensation that is different from that used in 9M-MRO’s equipment. One way to interpret that table is that the frequency error buget allows for AES frequency errors of 320 + 100 Hz.
The status of the document is far from clear. The Google link refers to it as “AMSS Guidance Material”, and it seems to be a Draft-SARPS (Standards and Recommended Practices) under development. Presumably there exists a Preamble preceding the chapters 1 – 10 to clarify the status. Surely it is up to Inmarsat to specify requirements for frequency accuracy and Doppler compensation for equipment that Inmarsat accepts for use on its system?
@Gysbreght: Here is the language
*****
a) Prior to log-on. Once the AES management receives a broadcast sequence on a
satellite/beam-identifying Psmc channel frequency, it shall determine whether the
received sequence is a partial sequence or a complete sequence (see
subsection 10.4.5.2) and then do the following:
1) If it is a partial sequence, the AES management shall compare the revision
number specified in the received partial sequence with the revision number of the
corresponding current data segment in the system table. If the received revision
number is one higher than the current number, the AES shall update its system
table according to the received sequence. If the received revision number differs
from the current number by more than one, the AES management shall wait for
the following complete sequence and update its system table accordingly.
2) If the received sequence is a complete sequence, the AES shall update its system
table accordingly.
b) After log-on. When the AES management receives a partial sequence from the log-on
GES, it shall update its system table accordingly.
*****
I believe that the partial sequence would contain only the changed data from the last revision. That is why a partial update is only allowed if the revision number is one greater than the revision number of the stored data. If there is no change in revision number, an update is not necessary. If the revision number is two or more higher than the revision number of the stored data, then updates would be missing from the partial sequence, and the entire System Table would need to be updated to ensure the accuracy of the data.