In yesterday’s post I argued that the reboot of MH370’s satellite communications system at 18:25 is a key piece of evidence about what happened to the missing plane. In fact, I would go so far as to say that we should discount any scenario which cannot explain the reboot.
That being the case, I thought it would be a good idea to clarify what we do know about rebooting the satcom and discuss the implications. Right up front I’d like to emphasize that I am by no means an electronics expert and I welcome any corrections or clarifications.
First, some basic background for those who might be new to the discussion. Flight MH370 took off from Kuala Lumpur International airport at 16:42 UTC on 3/7/14 bound for Beijing. At 17:07:29, the plane sent an ACARS report via its satcom. At 17:20:36, five seconds after passing waypoint IGARI and a minute after the last radio transmission, the transponder shut off. For the next hour, MH370 was electronically dark. The next ACARS transmission, scheduled for 17:37, did not take place. At 18:03 Inmarsat attempted to forward an ACARS text message and received no response, suggesting that the satcom system was turned off or otherwise out of service. At 18:22, MH370 vanished from primary radar coverage over the Malacca Strait. Three minutes later—about the amount of time it takes the Satellite Data Unit (SDU) to reboot—the satcom system connected with Inmarsat satellite 3F-1 over the Indian Ocean and inititated a logon at 18:25:27.
The question is, by what mechanisms could MH370’s satcom have become inactive, then active again?
Logging on and off the satcom is not something airline pilots are trained to do. A pilot can deselect the satcom as a mode of transmission for ACARS messages so that they go out over the radio instead, but this is not what seems to have happened in the case of MH370. According to the ATSB report issued in June of 2014,
A log-on request in the middle of a flight is not common and can occur for only a few reasons. These include a power interruption to the aircraft satellite data unit (SDU), a software failure, loss of critical systems providing input to the SDU or a loss of the link due to aircraft attitude. An analysis was performed which determined that the characteristics and timing of the logon requests were best matched as resulting from power interruption to the SDU.
Satellite communications expert Mike Exner addressed the issue specifically in a guest post here and likewise concluded that in all likelihood the SDU was powered down, and then powered up again.
There is no on/off switch for the SDU in the cockpit. A person wanting to turn the SDU off has two options. The first is to descend into the electronics and equipment bay (E/E bay) through a hatch at the front of the first-class cabin and flip three circuit breakers located there. The second method, which can be accomplished directly from the cockpit, is to isolate the portion of the plane’s electrical system which feeds the SDU, the left AC bus. According to IG member Barry Martin, the left main AC bus can receive its electrical power from any one of four sources:
- left main engine IDG via a left generator circuit breaker
- right main AC bus via both left and right bus tie breakers
- auxiliary power unit generator via an auxiliary power breaker and the
left bus tie breaker - backup generator converter which connects to the left transfer bus via a
left converter circuit breaker, and the left transfer bus connects to the left
main AC via a left transfer bus breaker.
In order to prevent any of these from supplying electrical power, Martin writes, a multi-step process is required:
The left IDG can be disconnected in a couple of ways via the flight deck electrical power system control panel. The preferred method would be via the left generator control switch. The second method is by use of the guarded drive disconnect switch, which permanently disconnects the IDG and the connection can only be remade on the ground. The L GEN CONT switch will open
the left generator circuit breaker, but the left bus tie breaker would then automatically close to re-energise the left main bus so the left BTB must be switched to ISLN on the electrical control panel before attempting to disconnect the IDG.
The left main bus can still be powered from the left transfer bus which picks up power from a solid-state variable-speed constant-frequency backup generator converter. The easiest method of preventing this is by simply opening the left transfer bus breaker, which allows the left transfer bus to remain energised to ensure the left transformer rectifier unit stays powered. However, I don’t see an option on the flight deck control panel to manually open the left transfer bus breaker. A second option would be opening the left converter circuit breaker, connecting the left transfer bus to the backup generator. Again, there’s no L CCB switch on the panel. Therefore the third option is to switch both backup generators off, which is possible via the panel.
This explanation is somewhat above my paygrade but my takeaway is that isolating the left AC bus requires some technical savvy. Indeed, when Mike Exner went to visit a professional flight-sim facility last November, the instructors there had never heard of this method of de-powering the SDU. (These are pilots whose job it is to train other airline pilots in every aspect of aircraft operation, so if it were common knowledge one would expect them to know about it.)
This is why I feel the reboot of MH370’s satcom suggests that whoever took the plane was technically sophisticated.
Some people have resisted this interpretation and instead raised the possibility that the SDU was power-cycled because someone wanted to turn something else off and back on again. The crucial question then becomes: What else is powered by the left AC bus? It wasn’t easy to find out, but after some careful digging, IG members were able to determine that the other systems fed by the AC bus are:
- TCAS (Traffic Collision Avoidance System)
- Cockpit door lock
- The centre tank override and jettison pumps
- Some galley equipment
- IFE (in-flight entertainment system)
- One of the high-frequency radios
- The main passenger cabin lighting system (the night, cabin and cross-aisle lights remain powered)
Looking at this list, it’s hard to imagine that a hijacker or suicidal pilot would feel a pressing need to depower an entire portion of the electrical system in order to turn any of these things on and off. (Also, given how hard the IG had to work to compile this list, how would they know?) I can imagine wanting to prevent passengers from seeing the moving map feature in the IFE, but it’s possible to turn this off from the cockpit without isolating parts of the electrical system.
To my mind, the only plausible explanation for the satcom reboot is the simplest one: somebody aboard the plane wanted to reboot it. But why? Again I am only able to think of one plausible answer: that they took it offline in order to tamper with it in order to effect a spoof. The fact that the reboot was apparently initiated less than a minute after MH370 left primary radar coverage would tend to support this hypothesis.
In the course of yesterday’s discussion, it was suggested that the SDU may have shut off due to fire. I don’t find this very plausible, given the evidence that MH370 went electronically dark just five seconds after passing the last waypoint in Malaysian airspace. This seems to me a clear indication of deliberate purpose. And if someone isolated the left AC bus in an attempt to fight an electrical fire, why on earth would they turn it on again an hour later without attempting to make an emergency landing or even radio for help?
Another suggestion that came forward yesterday was that hijackers might have wanted to distract the passengers and cabin crew by turning off the IFE and galley equipment. But it seems to me that doing so would have had the opposite effect—it would have alerted them to the fact that something was wrong, if they weren’t aware already.
Can anyone come up with an alternative explanation for the mysterious satcom reboot?
UPDATE:
- After receiving input from Don Thompson, who is perhaps the most knowledgeable independent experts in the world on this topic, I’ve change the wording of the third paragraph to clarify that it was the failed transmission of an ACARS text message at 18:03 that provides the first clear-cut evidence that the SDU was inoperative.
- On the advice of Gysbreght and LG Hamilton, I’ve removed “ACARS (VHF 3)” from the list of systems on the left AC bus and added “cockpit door lock.”
I am pretty much in agreement here on all this Jeff regarding the last 2 articles, great articles by the way. I too am not a technical expert but have thought for a long time that whoever figures out the reboot solves the mystery. The 3 remaining scenarios, the “inside cockpit” and “outside cockpit” applications to them, and the isolating the left AC bus complexities to me all seem to fortify the statement made by Sekinab Shah, sister of Captain Zaharie, who from the get go stated he was “smart but he was not Einstein to figure all this out.” And incidentally, Sekinab Shah commented on Tim Pardi’s Facebook page on June 23. I agree with her, saving on your heating and energy bill and fixing an ice maker is not exactly being one step ahead of Inmarsat in satcom configurations.
Sidestepping a bit here, new photo on Tim Pardi’s page, her child I believe in a candlelight vigil, it states, “the daughter of one of MH370 victim’s friends.” Possible clarification of who Tim is, a friend of Captain Zaharie, in what capacity though we still don’t know.
Back to the SDU. Is it entirely possible that ACARS, the IFE, etc. could have gone off however they did (bus isolated or not) with the SDU remaining ON the whole time somehow? Didn’t it state that the GES or system would contact the plane in an hour’s time if they had not “heard” from the plane? Could it be the SDU was on but askew somehow electronically in a glitch and righted itself somehow before the system reboot?
With the timing of leaving the radar and then the reboot a minute after circa 18:25 it certainly does seem to support Jeff’s theory of the spoof. And then there is still that mysterious unexplained line in the Four Corners piece, “around the same time someone interfered with the IFE.” (meaning same time comms were going off circa 17:21). Or……whatever was wrong on the plane resolved at 18:25 and whoever “switched both back up generators back on” for the SDU to come back on but all was lost somehow after that?
Hi Mike,
The Left Main AC bus cannot be fed by the backup generators; the backup generators are only small and only feed the essential equipment off the transfer buses. SATCOM is not one of those pieces of equipment.
Also ACARS can be disabled (deselected) in the cockpit by the MFD ACARS Manager menu .
OZ
I meant Jeff……been a long day.
No, it shows that ACARS was silenced, i.e. unable to address a message. ACARS remained silent after the reboot, otherwise it would have sent the messages that were waiting in the pipeline.
Also, I doubt if “ACARS (VHF3)” is one of the systems powered by the left AC bus. My understanding is that ACARS is an integral part of AIMS and cannot be switched off, but it can be cut off from the communication systems, or the comms can be switched off.
For example, if VHF3 configuration is changed from “DATA” to “VOICE”, VHF3 cannot send or receive ACARS messages, which are “DATA”.
Jeff,
“The next ACARS transmission, scheduled for 17:37z, did not take place, suggesting that the satcom system was turned off or otherwise out of service.”
I must point out that statement reads like the false reasoning favoured by a troll previously banned from commenting here. There is nothing to ‘suggest’ the state of the SATCOM at 17:37z.
It’s my view that AES transmitted no further AOC messages after 17:07z because none were forwarded to it. Between 17:07z and approx 17:21z a very straightforward action was executed on the B777 MFD’s ‘ACARS Manager’ page to deselect SATCOM as an available data link for ACARS messaging. A single click on a check box. That action ensured that the avionics systems would not initiate any messages inbound to SITA’s ACARS processor. I will make the assertion that whoever took that action was unaware that the AES continues to exchange datalink management messages even when the avionics systems are not using the AES.
If that action had not been taken -MRO’s avionics would have continued to chatter to MAS OCC with notifications concerning the deviation from flight plan.
Regarding the AES itself, no elective Log Off occurred. Had that occurred the attempt to send the adhoc text msg at 18:03z would not have been forwarded to the GES by the ACARS processor, it would have ‘bounced’ immediately back to the OCC terminal.
The only timed log records that show the AES datalink was down/failed/inoperative for a period are the failed outbound (from the GES) adhoc ACARS msg at 18:03z and the 18:25z Log On.
There is actually no evidence that the AES was powered down. The recent analysis by IG contributors of the SATCOM events around the 18:25z Log On indicates manoeuvres rather than a power up as reason for the variance in the recorded BFO values in the period 18:25z-18:28z. Those manoeuvres might indicate positioning the aircraft for an offset track along N571.
That action I describe above, to deny ACARS use of the SATCOM link, together with disabling transponder transmissions were sufficient to render -MRO ‘dark’ to MAS & ATC. Nothing more complicated or involved was necessary.
Malaysia’s military air defence system recorded -MRO’s track yet the country’s authorities have chosen not to disclose that data & corroborate the track depicted in the Beijing Lido image.
The period 17:50 to 18:25 is a significant gap in the publicly available information concerning -MRO: it includes the aircraft turning in the vicinity of Penang Island to its track over the Straits of Malacca, the last RADAR detection at 18:22 and the AES Log On.
I want to see that RADAR data. That data, together with what is known about the AES, would help fill the 17:50-18:25 gap.
The ‘crowd’ was a contributing factor in obtaining the release of the SATCOM log from Malaysia. The crowd’s call for the RADAR data has been ignored & as I have previously described, little of TUDM Air Defences Surveillance capability is a secret. Malaysia can’t deny it doesn’t exist while stating the last time of surveillance was 18:22z.
:Don
Gysbrecht,
Concerning ACARS & VHF. The ACARS Traffic Log, published in the Factual Information report, shows that VHF data link was down. A related Media Advisory msg was sent at 15:54:53 (ACARS terminal timestamp).
As a consequence of VHF Datalink unchecked in that same ACARS Manager screen on the MFD.
:Don
@Guarded Don
In regard of the radar data i would suggest to ask for the whole picture, that is, all military and commercial flights recorded between 17:20 and 18:40 in the entire area of MH370 s assumed whereabouts asap.
Concerning the logon: I did not understand your point. Do you agree, that the SDU was off for a time due to power loss? Or do you suggest it was powered all the time , in which case you should explain the need for an unexpected logon, i suppose?
Jeff,
Apologies for the sequence of responses, your latest was a long post & it’s early here.
I made the suggestion that removing power from cabin amenities may have provided some initial cover for the diversion/turn back. For example, the “flight deck” makes an announcement that the aircraft is turning back due to the apparent technical thus buying time for the next phase while explaining the turn back & placating the passengers who would otherwise be alarmed by a sudden 180° turn (& it was a dramatic turn to hold the times recorded by Kota Bharu RADAR).
:Don
@ Gysbrecht,
Your understanding around ACARS is correct. The aircraft will still however receive but will not give information.
OZ
I would like to add that the FO was new to the type, and his knowlege of B777 systems was probably limited to what he needed to know to pass the type rating examination.
CosmicAcademy,
I don’t conclude that the AES was powered off prior to 18:25.
There’s a condition where the MCS6000 will defer Log On for 30 minutes if it loses the GES signal (continuously transmitted, the AES must execute a Log On if it loses sync for more than 10sec). Differing interpretations exist for the logic processing that condition.
:Don
@Guarded Don @all
thanks for your answer. I would at this point now , really wish to see some praxis experiment which models the same conditions and figures that happened with that AES that night. This logon should be reproduced in detail, to see who is right here. I feel a bit caught between three different statements from extraordinary experts like the FI report, Mike Exner and you.
According to the FCOM there are three ACARS modes which are mutually exclusive. If ACARS MODE VHF is selected on page 2 of the ACARS manager, the default VHF radio selections can be changed from DEFAULT RADIO MODE: DATA to DEFAULT RADIO MODE: VOICE.
Are you suggesting that these selections were made 45 minutes before takeoff and not changed thereafter?
@Don, Thanks very much for your input. I’ve changed the wording in the third paragraph to clarify how we know that the SDU became inoperative. I agree that the public would be much better served if the authorities would release the complete radar data.
There’s one thing perhaps you could clarify. You write: “That action I describe above, to deny ACARS use of the SATCOM link, together with disabling transponder transmissions were sufficient to render -MRO ‘dark’ to MAS & ATC. Nothing more complicated or involved was necessary.” I understand that it would be easy for a pilot to deselect the satcom for outgoing ACARS messages, but as you point out this would not explain the lack of response to the outbound ACARS transmission at 18:03, nor would it explain why the system rebooted at 18:25. Aircraft maneuvering between 18:25 and 18:28 may well explain the BFO values received at that time, but it does not provide a good explanation for the failure of the SDU, as Mike explained in his guest post.
@Cheryl, Thanks for the kind words. Re: your question, “Could it be the SDU was on but askew somehow electronically in a glitch and righted itself somehow before the system reboot?” I would love to hear any suggestions to how that might be possible but haven’t heard any so far that are very plausible (e.g. Mike Exner considered and rejected the idea that aircraft movement might have been responsible for an SDU-satellite disconnection).
Gysbreght,
I’m not suggesting there was any relevant configuration made on the VHF Manager page.
From the FCOM:
ACARS Manager Page 2/2
This page allows the operator to select/deselect VHF or SATCOM transmission of data. ACARS is set to auto mode (both boxes selected) at power-up or data communication system reset. Normally, this permits ACARS to automatically use VHF or SATCOM (if VHF is unavailable). If both boxes are deselected, ACARS loses the capability to send downlink messages, but can receive and display uplink messages.
So, at 15:54:53z the ‘VHF ENABLE’ check box was unchecked, resulting in the ACARS Data Comm Mgmt function sending the Media Advisory ACARS ‘Lost VHF’ msg via SATCOM to the SITA ACARS Processor. SATCOM remained the operational datalink.
At a time after 17:07 but before the diversion was initiated the ‘SATCOM ENABLE’ check box was unchecked.
The configuration of which VHF radio may be used for DATA at this time was moot as there was no intention to use it.
:Don
@OZ, So to clarify, I should take #4 off the list? Or #3 and #4?
Hi Jeff,
Dump 4 and 3!
OZ
Jeff,
In my opinion, we don’t know emphatically that the SDU and/or complete AES rebooted at 18:25. The ATSB published their statement in June 2014, knowledge has developed since then.
We don’t have sight of the SU’s prior to the AES sending its Log On Acknowledge to the GES at 16:00:12.406 allowing a comparison of the intervals between the exchanges processing the Log On. However, the 18:25 and 00:19 events are similar, at approx 7.5sec, from Rch Log On Request to Rch Log On Acknowledge (that sequence is the core of the AES’ Log On process).
In response to your previous post, “curious” replied with a comment concerning the aircraft and, hence, the implied antenna orientation. The ATSB suggested that aircraft attitude could be a reason for loss of link & a parameter exists in the SDU itself related to delaying Log On after loss of link: the MCS6000 delay is fixed at 30mins. We’ve debated whether this delay would be invoked if only one satellite was in view or not.
:Don
Thanks for that clarification. I wasn’t aware that there are different AIMS versions. Do you know which version was installed in 9M-MRO?
It is not obvious to me why you conclude “before the diversion was initiated”. Perhaps we need to look into the functions of the Automatic Messages Manager?
Do the functions available in the AUTOMATIC DEPENDENT SURVEILLANCE MANAGER explain the delay between the Mode S symbol of MH370 dropping off from radar display, and the loss of the secondary radar position symbol?
@GuardedDon said, “There’s a condition where the MCS6000 will defer Log On for 30 minutes if it loses the GES signal (continuously transmitted, the AES must execute a Log On if it loses sync for more than 10sec). Differing interpretations exist for the logic processing that condition.”
Has this 30-minute timeout been definitively established. As you know, the ORT Item cviii, Aero Satellite Recovery Time, is described in the MCS Manual as:
This item defines the number of minutes to wait before allowing a Aero service to be available for selection again on a particular satellite after being temporarily marked as unavailable (e.g. as a result of P–Channel degradation or failure to acquire a P–Channel or HGA transmit gain below threshold). The defined range for the timeout is 1 to 30 minutes.
So it would appear that timeout time may have been much shorter than 30 minutes. I would argue that a 30-minute timeout is unnecessarily long.
@jeffwise: Here are two other possibilities for unsuccessful delivery of the messages at 18:03 followed by a log-on at 18:25:
1) The SATCOM remained powered but in an (undocumented) standby mode. This is a documented mode for Rockwell SATCOMs, but no reference to this mode appears in the Honeywell manual. Nonetheless, there could be an undocumented maintenance screen that allows this mode to be selected.
2) The SATCOM remained powered and there was an onboard jammer that prevented the AES from syncing to the P-channel signal. At 18:25, the jammer signal was stopped.
Gysbrecht,
AIMS on -MRO was v1, v2 was implemented in 2003 (IIRC). It’s not a sw upgrade, it’s a platform refresh.
I conclude “before the diversion was initiated” simply because the diversion from the active route would have likely initiated progress reporting messages back to the OCC.
The subsequent FCOM pages referring to ADS Manager are concerned with ADS-C, not related to SSR or ADS-B transmissions. While the data source is common, the pathways to route the data off the aircraft are completely separate: SSR and ADS-B via the transponder while ADS-C from the FMS via an ATN datalink to ANSPs. No datalink was established to the ANSPs, only two virtual circuits established: one VC over satcom for the IFE pax amenity messaging service and one VC for the aero operational comms via SITA’s ACARS processor. ADS-C & CPDLC services are not mandatory in KL FIR, DCA’s ATC people were struggling through trials. Concerning the SSR symbols disappearing, I’d expect the symbol/coasting timing to be a function of the ATC system presentation rather than the received data.
:Don
A friendly reminder to all: As I have clarified several times here in the past: The SDU is only one part of the complete AES. The complete AES consists of the SDU, HPA, LGA and HGA + IRS feeds, various cables, power splitters, etc. Don is very careful to make this distinction, but many others clearly don’t appreciate the fact that the SDU could have been working for the whole flight, and the AES still did not transmit for any one of a hundred other reasons. This often leads to confusion in the conversations. If you are not familiar with the technical details, I suggest that you refer to the AES (the whole enchilada) and not the SDU (one tortilla) when discussing the logon events. That way, you cover all the possible “boxes” that could be working or not working, affecting communication.
Victor,
Yes, the Satellite Recovery Timer for the MCS6000 was confirmed as a fixed delay of 30 minutes. Unlike the MCS4200/7200 SDU, which has a variable delay defined by an ORT parameter, the MCS6000 period is fixed.
:Don
@jeffwise: Since we are talking about log-ons, I will say that there is something else very troubling in the updated logs released by Malaysia on Dec 23, 2014: The timing of the two log-on attempts around 16:00.
The log-on requests have timestamps of 15:59:55.413 and 15:59:56.413, representing a timeout of exactly 1 second. However, by AMSS spec, ARINC 741, the timeout between log-on requests should be no shorter than 12 seconds. This was first highlighted by @GuardedDon in the days following the release of the updated logs.
So either we are misinterpreting or misapplying the ARINC spec (although several of us have reviewed the language and have identical interpretations), or the Malaysians inadvertently transcribed the wrong timestamp on one of the two log-on request entries, or there was a deliberate attempt to deceive us with altered logs.
We recognize and it has been officially acknowledged that there were redactions in signaling data transmitted by the GES related to the log-on at 16:00. (Those records would not have BTO or BFO data.) However, if the two added records are not 100% correct, we would have to question the accuracy of ALL the records, unless a persuasive argument could be made that the inaccuracy was limited to the newly added records.
Perhaps there is another explanation for the timestamp anomaly that I am not aware of.
@all
I thought I read and re-read the above fairly carefully, but I did not see a mention of the fact that the 18:25 login did not include an aircraft ID. Did I miss that being discussed? If so I apologize. Is there any significance to the missing aircraft ID? Is that normal for an inflight login?
@VictorI, thanks for pointing out the possible inconsistencies in the updated logs. I would add that inconsistent, missing, and erroneous information has been a long-standing problem with information released by the Malaysians. Who knows what errors we’re being led into, intentionally or not.
@VictorI:
I agree that the two 1600 logon records separated by exactly 1 second are very odd. I asked Don about this again yesterday. He confirmed (again) that it should not ever happen. So it raises doubt about the accuracy of those records. I am also very interested in the 17 Hz jump in BFO values around the same time, while the aircraft was stationary. So far, it is unexplained. Understanding this 17Hz jump could be crucial to our understanding of the other two logon events.
@GuardedDon:
Thanks again, I appreciate your expertise on these systems. I’m just a layman, but I’m learning all the time.
9M-MRO was manufactured in May 2002. I was referring to the LaudaAir FCOM and have since consulted the “B777 family” version which describes the [Not AIMS 2003] and the [AIMS 2003 and SATCOM and HF Datalink] versions of the ACARS manager. When you write “AIMS on -MRO was v1”, does that mean the [Not AIMS 2003] version is applicable?
Then you write:
Is that just a guess? For example, the time between routine progress reports is selected by the operator. At the time MAS had set it at 30 minutes, but IIRC has since changed it to 15 minutes, and in the case of AF447 it was 10 minutes. If a diversion from the active route generates unscheduled reports, the ATSB and the Factual Information should not have said that the next report was expected at 18:37.
@Jeff
“At 18:22, MH370 vanished from primary radar coverage over the Malacca Strait. Three minutes later—about the amount of time it takes the Satellite Data Unit (SDU) to reboot—the satcom system connected with Inmarsat satellite 3F-1 over the Indian Ocean and inititated a logon at 18:25:27.”
….and
“The fact that the reboot was apparently initiated less than a minute after MH370 left primary radar coverage would tend to support this hypothesis.”
I think you are inferring a linkage here that is implausible. How could anyone on the aircraft possibly know, with any precision, when the aircraft left primary radar coverage.
In fact the actual radar coverage, as distinct from any information that has been released publicly, is one of the great unknowns.
The reboot, if it was indeed a reboot at 1825, or some other event which resulted in the seemingly inconsistent BFO values at around that time, must stand alone. The timing (in relation to the end of the published radar track) can be nothing more than coincidental.
Apologies: 1837 should read 1737
@GuardedDon
“AES must execute a Log On if it loses sync for more than 10sec”
may be possible to perform such sharp maneuvre that HGA/LGA could be shielded from satelitte line of sight even by plane wing (they are in top-center of plane in fact) for example for more than 10secs? The higher frequency the more it behaves “as light” and could be in radio “shadow” – which angle would be required in relation to position of plane vs satellite, even using wing as shield??
@Brian Anderson, I agree that the timing could be coincidental, but it also could be intentional. If we agree that the reboot was not accidental — as I think we should — then we have to credit the hijackers for a good deal of sophistication and resourcefulness. Some ways they might be able to detect the edge of radar coverage could include a) some kind of detector, like those used by fighter planes to detect lock-on by enemy anti-aircraft systems b) prior scouting of area radar capabilities, of the sort that Russia does quite a lot of with its NATO neighbors.
@Jeff
you don’t find plausible that FO (maybe with help of that electrical engineer, confirmed to be on board at the time) tried to regain cockpit access fiddling with breakers in E/E bay and just accidentally turned off and on the whole AES? I doubt that novice pilot would know all the breakers and their function.
now why that happened exactly at 18:25…could be just coincidence, or could be the time when FO realised they were not landing in Malaysia that day and started looking for solutions…
@Jeff
It might be something as simple as a “range gate”. Depending on the pulse repetition frequency a range gate (truncate returns beyond a certain range) is used to keep distant targets and close targets from interfering with each other. My guess is that the range gate on the search radar in question was set at 200nm or so. If the range gate used by the radar is known by the “hijackers” it would be relatively easy to know when radar coverage ended.
Now what about my question on the missing flight ID?
That horse was beaten to death ages ago. IIRC Don explained that the flight ID does not feature in the SATCOM communications protocol, but is used only in ACARS messages to SITA.
@DennisW, very interesting idea about the range gate. Hadn’t heard of that. Worth looking into.
Also, I don’t recall hearing about a missing ID. The signal must have carried some kind of identifier or Inmarsat wouldn’t have logged the data as coming from 9M-MRO.
@Gysbreght
Thank you. There are probably many things that have been beaten to death that I am unaware of. There is no need to include that qualifier unless you are simply intending to scold me.
@StevanG
I have certainly considered that exact scenario many times in the past year. The only issue I have with it is the plausibility that a novice pilot who is unfamiliar with electronics and avionics would aimlessly begin switching off circuit breakers. It seems highly unproductive and dangerous, unless he fully knew what he was doing. And I think it’s very likely that he had little to no knowledge of the inner working of the E/E bay.
@Brian Anderson
How could a hijacker know the time, when the radar ceases?
Maybe my idea is oversimplistic, but if i want to disappear from a known radar observation roughly 200 nm away, i could change altitude by lets say 20,000 ft and be sure that the line of sight observation stops. Maybe there was a tight schedule for the hijacker, which he had to meet urgently at a given time, like arriving in indian or myanmar airspace under pretense of a regularly submitted flight plan as a different aircraft (this was discussed here last year).
@DennisW:
It was not my intention to scold you.
I cannot find where the Flight ID would be part of the log-on signaling data and so it would seem that would be a field at the application (ACARS) layer. However, the FI does specifically say that “No Flight ID was sent to the GES during the Log-On”, which seems inconsistent unless the FI was referring to what would normally be part of the missing ACARS exchange.
Of course, the ICAO ID for 9M-MRO was included in the signaling data.
DennisW,
The FlightID is something that’s generated/inserted to comms at the ACARS msg level. It derives from the FMS, ie when a valid, predefined route for a service exists in the FMS. My view is that the MH370 route was cleared from -MRO’s FMS as part of the deviation & subsequent waypoints entered ‘on-the-fly’.
The SATCOM datalink exchanges rely on the GES ID and the aircraft ICAO ID as identifiers.
Falken,
9M-MRO was not fitted w top centreline HGA, it used dual side mount aperture HGA configuration. Well covered in past discussion.
Gysbreght,
I think we’re all expanding our knowledge on this.
Jeff,
Thanks for the kudos but your attribution is too generous.
@Victor
Yes, the FI is where I saw it (flight ID) mentioned. Does seem strange that they would mention something expected to be missing. Lead me to believe that it was latent somewhere else in the signaling chain unless cleared or over-written.
@DennisW: Yes, I agree that the words in the FI are misleading, but I believe that @GuardedDon’s explanation is correct. Having checked all the fields, I can confidently say that Flight ID is only available at the application layer, not at the signaling layer.
@Jay
” have certainly considered that exact scenario many times in the past year. The only issue I have with it is the plausibility that a novice pilot who is unfamiliar with electronics and avionics would aimlessly begin switching off circuit breakers. It seems highly unproductive and dangerous, unless he fully knew what he was doing. And I think it’s very likely that he had little to no knowledge of the inner working of the E/E bay.”
could be, but from Penang to the reboot point they had like half an hour of flight or so? if he was scared (and he was) he might have tried anything in desperation and succeeded to unintentionally reboot AES
@StevenG
Your scenario is one I hypothesized as well. It would seem someone was flipping breakers if the power cycling explanation is correct. Could have been the FO in concert with the flight engineer on board trying to get the door open. Keep in mind that the system was unresponsive some time earlier, 18:00 or so per Jeff’s narrative above. So I do not believe it was a simple toggle back and forth at 18:25.
@StevanG @Dennis,
Pleas explain to me how the FO would conclude that going into the EEbay and tampering would lead to an outcome better than compliance? What did ‘they’ hope to accomplish?
This makes absolutely no sense to me. This would seem to ensure the worst possible outcome.
Desperation IMO doesn’t cut it. The FO realizing Z wasn’t landing in Malaysia was the catalyst to such a drastic measure??