In the previous installment of this series, I looked at the psychological context for a hypothetical suicide run into the southern ocean. Today, I’d like to consider an equivalent issue with regard to a hijacking scenario. Presuming one occurred, what could be the motive for such an act?
As has often been observed, nobody claimed credit for the disappearance of MH370, and nobody visibly benefited from it. No benefit would seem to imply no motive.
Motive, however, can be a tricky thing to impute to another person’s actions. How can we be confident that we understand enough about a person’s position in the world—or more importantly, how they perceive their position in the world—to judge whether a given act would or would not be rational from their perspective?
A question more likely to yield results, I would argue, is: are there any potential perpetrators who might feel motivated to take such an action, however opaque their motive might be to us?
Here the answer is a resounding “yes.”
As it happens, the UK-based group Bellingcat today released the latest in a series of reports about the shootdown of MH17. For anyone who is not familiar with its work, Bellingcat is a very highly regarded group of amateur analysts who have pioneered the crowd-sourced investigation of open-source data. Bellingcat founder Eliot Higgins first attracted attention after using social media to locate evidence that the Syrian regime had used chemical weapons; later the group used similar techniques to identify the specific Buk missile launcher used to shoot down MH17 and has grappled with many other pressing topics of the day. If you haven’t visited their website, I heartily recommend it, as their coverage is fascinating and offers an excellent model for transparency and balance. Not for nothing the Columbia Journalism Review described Bellingcat’s work as “rigorous, evidence-based examinations of extremely specific questions… extremely valuable in helping us understand complex subjects.”
What has emerged from these reports is a strikingly concrete and layered depiction of events surrounding the destruction of MH17. And it is radically different from the picture that most journalists and analysts hold.
According to Bellingcat’s research, the Buk missile launcher that destroyed MH17 was not some trophy of war that a bunch of untrained militiamen got their hands on and fired off willy-nilly. Rather, it belonged to a specific regular Russian army unit, the 2nd Battalion of the 53rd Anti-Aircraft Missile Brigade, which was sent from its base near Kursk to the Ukrainian border. From there, this specific launcher was brought across the border in the middle of the night and positioned under the scheduled flight path of MH17. After it blasted the plane out of the sky it was put back on its trailer and brought back to Russia. The whole operation was a one-day mission.
Bellingcat identifies the unit’s officers, and even hones in on the individuals who likely operated the Buk in question. They stop short of speculating at who pushed the “fire” button. The report does make very clear, however, that operating a Buk requires intensive training, so whoever committed the fatal act must have had considerable experience with the system. And as might be expected with a weapon of its range and lethality, a major part of operational training is a tightly controlled firing process. Of the four man crew, only the officer in charge is authorized to make the firing decision. He, in turn, must receive the necessary order from his commanding officer. Contrary to the popular narrative, anyone who would be able to fire off a Buk blindly would know better than to do so.
That’s why, as I write in New York magazine today, Bellingcat has concluded that “responsibility for the downing of MH17 from a weapon provided and possibly operated by the Russian military lies with the Ministry of Defense and the Supreme Commander of the Russian Armed Forces, President Vladimir Putin.”
Some will no doubt find this conclusion incomprehensible: Why in the world would Putin order, or allow, a brutal attack which triggered such harsh repercussions against his country? What possibly could be the motive?
The answer is, we don’t know Putin’s motive. Indeed the alarming upshot of MH17, and how badly the press and intelligentsia have bungled their attempts to understand it, is that we don’t understand Vladimir Putin at all. We can’t presume to guess what his cost/benefit analysis of this decision was. But based on a year’s worth of intensive reporting by Bellingcat, as well as on work released by the official Joint Investigative Team, Putin obviously felt he had reason enough.
By this point I think the relevance of this story to MH370 should be clear. Within four months, two Malaysian Airlines 777s were taken out of the sky under suspicious circumstances. Imagine if you were a farmer who’s been raising chickens for many years without incident. Then one day, for the first time ever, one of the chickens goes missing. Then the next day, you see the neighbor’s dog jumping over your fence with a second chicken in its mouth. Now would you have a theory about what happened to the first chicken?
We know from the analysis of MH370s satcom system carried out by Mike Exner, Victor Iannello, Gerry Soejatman and others, that if a spoof hijacking was perpetrated on MH370 then whoever carried it out possessed an extremely high level of technical sophistication. So high, in fact, that the attack must not only have been state sponsored, but sponsored by a state with cutting-edge technology in aircraft systems and satellite communications. That being the case, if we suppose that MH370 was hijacked by someone other than Russia, then that would mean that two Malaysian Airlines 777s—of which only 15 existed out of a worldwide commercial aircraft fleet of perhaps 18,000—happened to be targeted within the span of four months by two different major powers.
Talk about bad luck!
@Interested Observer, The radar traces were only noticed after the fact, so no, jets could not have been scrambled. It’s quite doubtful that Malaysia had any jets standing ready to be scrambled, anyway.
@Sunken Deal, I’ve certainly thought about the possibility of being assassinated, but mostly thinking of what a great piece of evidence it would be in favor of a spoof scenario. Really, though, I think that Eliot Higgins of Bellingcat is way more exposed than I or anyone else here is.
Last month, I posted here regarding the patch of bad luck that seemed to be affecting Fugro Discovery. Its last 5 sorties had proceeded thus:
Departed / Fate
2015.10.28 / Sick crew #1 (no searching)
2015.11.09 / Sick crew #2 (no searching)
2015.11.29 / A record 33 days of searching
2016.01.13 / Lost towfish (no searching)
2016.01.31 / Damaged cable (no searching)
Disco’s latest sortie (departed 2016.02.20) introduced fresh concerns. On its first full pass SW, Disco precisely repeated the track it covered Dec. 24. And now, on the way back up NE, it is repeating the track it covered Dec. 30 – and again on Dec. 31 (it backtracked and re-did the same track on consecutive days).
I have confirmed that each of these three days in December were at towfish speed (~3kts) throughout.
I invite experts and fellow mappers to weigh in, but this first set of tracks may be calling into question the productivity of the one sortie among the five which WASN’T abandoned.
If that sortie needs to be redone, it would mean that Fugro Discovery went over four MONTHS (Oct.22, 2015 until Feb. 27, 2016) without increasing the area searched.
Curious.
Some new things to me
http://news.xinhuanet.com/english/2016-02/29/c_135142018.htm?
“one of Anwar’s sons-in-law, married to her sister, is a Malaysia Airlines pilot”
I didn’t know this…Anwar’s daughter is obviously doing everything to remove any connection between Anwar and Zaharie as it probably harms him politically.
@StevanG
Yeah, I read that earlier today. I had the same impression as you – throwing Shah under the bus.
@Ken, about MH17,
I had also read about the corpse theory. At first glance, I could not discard it out of hand. The very earliest pictures that included bodies seemed to show more decomposition than I would expect, but obviously I am not an expert.
The problem with the theory is it requires the corpses to be loaded as cargo in Amsterdam. Nobody boards a plane in Amsterdam and sits down next to a dead body.
The difficulty in getting corpses on as cargo beg explanation. It is hardly a convenient way to dispose of murder victims. And supposing they were from mh370, why not just bury them in Kazakstan or China, if that’s where the plane went?
One thing that might explain the story – regularly scheduled flights DO occasionally carry dead bodies being sent back to their families. Flights also carry organs (including TWA 800, which was carrying a heart). So it is at least possible that the story is true, but perfectly normal.
@Interested Observer
Four Corners asked Hishammuddin whether the radar traces were recognized in real time. His answer was, yes, but the unidentified aircraft was determined by the duty officer not to constitute a threat, and as such, there was no reason to scramble jets.
https://www.youtube.com/watch?v=2XQPCwY5SHk starting at about 5:25.
I doubt he was telling the truth but I don’t recall any different official or otherwise definitive answer to your question. Perhaps Jeff or the radar gurus among us wouldn’t mind reminding me.
Linking Captain Zaharie with Anwar won’t help in the hunt for motive. Being from Malaysia, it is very likely that Anwar would have met Z without even remembering it. Even Malay commoners typically invite a few thousand people to the wedding of their children – I have colleagues who invited half the company that I work for to their wedding (about 1000+ person).
And yes, a lot of people knows Z. My friend who was a junior pilot at MAS also knows him in person, and so does the father of a good friend. Radicalised political terrorist? Hahaha
I find it that people trust things they see on the internet written by clueless person more than what the intelligence agencies will call “human intelligence assets”.
By the way, Ahmad Shah or Shah is Z’s father. Just like Z’s daughter is called Aisah Zaharie. Most Malaysian Malays doesnt have a family name.
Well said MHW. I find all this finger-pointing at Zaharie nauseating (all because assumptions didn’t work out, ergo the only option remaining is “Z is the bad guy”). Sloppy logic. And disrespectful to boot.
Hi Jeff,
I greatly appreciate the careful and considered thought you’re putting into a very daunting problem (what happened to mh370?).In my opinion (and I’m just someone on the Internet) an important part of this problem is the following – what relationship should be ASSUMED between what happened to the airplane and what is publicly reported? This is (almost by definition) a matter of personal belief. Of course – it’s possible that there is no discrepancy at all – that the information provided by the authorities is honest and to the best of their knowledge. In that case the airplane probably crashed in the SIO and its exact whereabouts are probably irrelevant even to the unfortunate grieving families.
Once one starts to question that assumption though I think Brock McEwen has identified the key issue – that the (reported) Inmarsat data comes into question. Why believe it?
But there is also an element of human psychology – we all THINK we can picture an angry, grieving Captain Zaharie cruising over the seething Antarctic ocean with a cabin full of dead passengers. I would suggest this is what psychologists call the “availability heuristic” – it’s still something we can buy into therefore we believe it to be true.
As Brock McEwen suggests – if one limits oneself to the ex-ante publicly available information then there is little to go on – a scheduled flight MH370 took off from KL and its passengers have not been seen again. If one assumes otherwise then the scenario you laid out in your book may well be correct. But equally (under that assumption) the Inmarsat data may be incorrect, for any variety of reasons.
I think your thesis that the Inmarsat data should not be taken at face value was a very clever one. But I think the generality of Brock McEwen’s objection should be taken seriously – we can’t even put much credence in the radar data as reported. Unless there is an open, transparent, full-view approach by the authorities – as to the radar data, Inmarsat data, sattelite comms we just won’t know.
@Paul
“sloppy logic”
Says the guy who choses to ignore the ISAT data, the radar “graphics”, and the flaperon finding. Funny shit.
@MHW
I offered my daughter and future son-in-law $25,000 if they would go to Vegas to get married, leave the country on their honeymoon, and save me the expense of a big wedding. They almost took me up on it. Should have posed the offer as a going in position, probably could have gotten out at $35,000 or so.
@Eoghan, A large number of people have seen the Inmarsat data, including the ATSB, Thales, Boeing, etc, so I find it implausible that it has been forged from the ground up at the source. For one thing, if it had been fabricated out of whole cloth, it would probably make sense, and as I’ve noted here before, it really doesn’t: the BFO data predicts an end-point further to the northeast than autopilot-and-BTO data alone do. What’s more, the Inmarsat data and the radar data are very much congruent with another, suggesting that both are valid.
Brock says that it is impossible to tackle the mystery without an “open, transparent” review of all data, but everyone who’s spend any time with this case understands that this has an almost zero chance of taking place, so really what he’s saying is that we can’t trust any of the underlying data so all theories should at present be considered equally valid. The reason for this, in my estimation, is that Brock believes deep in his heart that the United States is responsible for the disappearance of MH370, but understands that there is at present absolutely no evidence for this, and so has constructed in his mind a scenario in which a conspiracy has hidden the true facts of the case and in their place created false evidence. In other words, Brock’s call for an open and transparent review of the facts, which at first glance would seem utterly reasonable and fair, is actually not motivated by a plausible agenda.
I have a question on the technical aspect of the suicide scenario.
As far as I’m aware, the only way to disable ACARS from within the flight deck is to select the ACARS manager menu in the Flight Management System. The next step is to switch VHF/HF to unused frequencies or disable and to disable the SATCOM downlink.
Now, this seems to imply that, while the ACARS downlink is dead, the uplink (from ground to aircraft) isn’t, messages are still displayed, the system itself logged on. Well that’s according to this guide book: http://www.smartcockpit.com/download.php?path=docs/&file=B777-Communications.pdf (p. 47) – pardon my ignorance, I am an interested amateur.
The deduction is that, when the SDU rebooted at 18:25 one would expect ACARS to logon to the ground station once again, but it didn’t. Moreover, MAS operation centre sent an ACARS text message to MH370 at 18:03, which didn’t go through successfully and was subsequently resent automatically for 40 minutes. When the SDU rebooted, the ACARS message still didn’t show up in the Inmarsat data logs. Unfortunately, the ACARS logs after 18:15 are missing in the factual information (interim) report, but the Inmarsat logs clearly state ’17:07 – Last Acknowledged Ground to Air DATA-2 ACARS Message. Link lost at sometime between here and 18:03:41.’ To my mind, this precludes that ACARS was disabled in the flight deck if the above is correct.
As far as I am aware, there are two different methods to explain the lack of ACARS traffic following the reboot.
1) failure/sabotage of AIMS
2) pulling circuit breakers in the e/e bay
1) would imply failure of autopilot, which contradicts the presumed flight route. Sabotaging AIMS from the flight deck would additionally require more than one person pulling a number of circuit breakers.
Does this mean the ACARS traffic data are consistent with pulling circuit breakers in the e/e bay?
@DennisW. Lateral thinking, yes. Sloppy logic, no. My paper sets out explicitly: all assumptions, inferences and the data that doesn’t fit. Without good evidential grounds, I don’t “make up stories” in order to discount the data that doesn’t support my hypothesis.
You’ll be glad to learn that there is more coming soon – “Now with added BTO!!”
ps: I like your wedding story 🙂
Correction: p. 47 needs to be p. 74: ‘If all boxes are deselected, ACARS loses the capability to send downlink messages, but can receive and display uplink messages’, i.e. it needs to logon during any reboot with no subsequent power failure (as did the IFE)
@Nederland: As has been discussed here many times, the SATCOM is powered by the left AC bus, which can be isolated from the cockpit. There is no need to enter the E/E bay if the SATCOM was intentionally disabled.
@VictorI:
It ist is clear that isolating the left AC bus can depower the SDU. However, the SDU rebooted at 18:25, but no ACARS traffic was received thereafter (or after 17:07) until the final handshake. How would you explain this? If one assumes that power was supplied to the SDU again at this point, why no ACARS traffic? (the IFE, for example, was working and logged on successfully)
Nederland:
There are 2 uplinks (C & L) and two downlinks (L & C). Not 1 each. There are other ways to disable ACARS from the cockpit. It is certain that isolating the left AC Bus will remove power from the AES, including the SDU and other components of the AES. There was no ACARS at the final handshake. The IFE system did not log on at 00:19. It seems your understanding of the FI is scrambled a bit.
@airlandseaman
Sure, no ACARS traffic whatsoever (bidirectional) after 17:07 and no IFE logon at 00:19 (but at 18:28), I agree with that.
How can you disable ACARS in the cockpit if disabling the various downlinks in the Flight Management System ACARS Manager doesn’t do the job? Or does it? Why did ACARS not log on and why did the ACARS text message by MAS OPS not go through after 18:25 via VHF/HF?
I mean after 18:25 via SATCOM or anytime between 18:03 and 18:43 via VHF/HF
Nederland:
ACARS can be disabled manually by deselecting all available paths (sat, VHF, etc.) from the cockpit. It can also stop working due to equipment failure or a software problem. Neither of these stop the AES from responding to periodic “handshakes” initiated from Perth. The AES hardware is independent of all ACARS hardware and software (located in the E Bay), and located 100 feet from the E bay. An E-Bay accident that disrupted the ACARS, transponder, VHF etc. would not necessarily disrupt the AES from handshakes.
@airlandseaman, but if an accident in the E/E bay led to loss of navigational/position data to the SDU from the IRS, that could disrupt the AES, right?
@airlandseaman
Thanks, that is what I assumed in my first post, above.
The problem I see is that deselecting the available paths only prevents ACARS from sending (downlink) messages.
This is explained in this manual:
http://www.smartcockpit.com/download.php?path=docs/&file=B777-Communications.pdf
p. 74:
‘If all boxes are deselected, ACARS loses the capability to send downlink messages, but can receive and display uplink messages’
If ACARS is thus disabled and the SDU reboots, it would follow that ACARS logs on to the ground station along with the IFE. Moreover, the ACARS uplink (text message by MAS OPS) would be automatically acknowledged and thus ACARS traffic be logged in the Inmarsat data at the time of the reboot, but it wasn’t.
Can we, therefore, exclude, that ACARS was disabled manually by deselecting the available paths in the cockpit?
JW: Yes. Loss of nav data via 429 bus would do 2 things: Loss of ability to steer the HGAs, and loss of ability to compute required Doppler Offset. The AES could still communicate via the LGA, but it needs the nav data for Doppler correction for both antennas.
Nederland: No. It is unknown why ACARS stopped working. Could have been manually or due to equipment/software failure.
@airlandseman
Does it mean the manual I linked is inaccurate? Does it mean the 777 ACARS manager allows deselecting/logging off completely (bidirectional), not just preventing outgoing reports and messages but also automated acknowledgments of incoming (ground to air) messages?
Perhaps it is an older version than the one described in this manual?
http://www.smartcockpit.com/download.php?path=docs/&file=B777-Communications.pdf
Nederland: Your link does not work. Repost pls.
It should open as pdf, perhaps a problem with pop ups?
http://www.smartcockpit.com/download.php?path=docs/&file=B777-Communications.pdf
If not try google ‘B777 communications smartcockpit’ and open the pdf link, pls
It’s p. 74
@Nederland: It is true that deselecting all transport modes from the CDU will allow the receipt of ACARS but no transmission.
But how can the ACARS application log-on to the ACARS server if there is no allowed transport mode? And likely there is a separate log-on table maintained by the ACARS server that will determine if an ACARS message is sent to a particular aircraft.
Nederland:
I found the document. And it does state outbound text messages would still be received, even if inbound messages were disabled manually. But the 2 MAS attempts to call 370 were voice call attempts, not text messages. Voice calls are not dependent on ACARS.
@VictorI
My understanding is there is no way to log off ACARS completely from the server by deselecting all transport modes. ACARS will stay logged on and try and receive uplink messages from the server. I can’t see why this would change if there is a temporary failure of the SDU. ACARS should therefore log on once the SDU reboots.
There could be further records in the SITA logs if there are any, but it seems that the 18:25 Inmarsat logs are way to short to allow data transfer of any ACARS message. Compare this to the ACARS messages prior to 17:07. In fact, the Inmarsat logs exclude this possibilty (no ACARS traffic after 17:07, this would be either way)
I have to say that this wasn’t all originally my idea but rather it was the result of a discussion elsewhere, but something potentially interesting to consider.
@airlandseaman
Have a look at FI, p. 47, pls!
‘The first message sent to the aircraft cockpit printer from the MAS ODC was at 1803:23 UTC. The ACARS message requested the crew to contact the HCM ATCC immediately. The
incoming downlink message at 1803:24 UTC showed the message failed to reach the aircraft. Messages are auto transmitted every 2 minutes and the message was retransmitted until 1843:33 UTC but all messages failed to get a response. Automated downlink message by ACARS showed ‘failed’. Message sent to the aircraft cockpit printer and the Automated Downlink messages are shown in Figures 1.9J and 1.9K, respectively.’
You can also see a screenshot of the text message.
And see also Appendix 1.9A
Nederland:
Out of time now. Will review 18:03 attempt later. Power was apparently off at 18:03 and back on at 18:25. Not sure why the 1803 message did not go through after 1825 if repeated every 2 minutes. I’ll discuss with Don and get back later today.
Appendix 1.9A shows the last uplink attempt failed at 18:15:25. Curiously the Inmarsat logs released by Malaysia don’t show anything between 18:06 and 18:25.
@Gysbreght
My understanding is the ACARS logs in App. 1.9A are incomplete. I’be curious to know how they look like after 18:25.
The lack of Inmarsat data before 18:25 could be due to VHF being the priority receiver. However, it is also remarkable that all ACARS reports were sent via SATCOM prior to failure, even though VHF is cheaper within SITA coverage.
@Nederland: We’re going in circles. How can the aircraft log into ACARS if there is not a mode for transmission? And if the (ground-based) ACARS server believes that the aircraft is not logged onto the ACARS server, no message will be delivered to the aircraft.
As Mike says, @GuardedDon has studied this in detail. We should seek his expertise.
@VictorI
Agreed it’s good to get another opinion.
I was advised the expectation is there is data traffic (outgoing) and therefore a logon along with the reboot, if all boxes are deselected in the FMS, and that’s the only way to manually disble ACARS in the cockpit.
The text stating that “if all boxes are deselected, ACARS loses the capability to send downlink messages, but can receive and display uplink messages.” is in the description of the AIMS 2003 version.
9M-MRO was delivered prior to 2003, and probably had the [Not AIMS 2003] version of AIMS.
@Gysbreght
Yes, I noticed that as well, but then again, if you look at Not AIMS 2003, it doesn’t even indicate that either VHF or SATCOM can be deselected.
That would be consistent with the FI saying that ACARS uses either VHF or SATCOM, but does not mention HF.
@Nederland
My understanding is that in the [Not AIMS 2003] version you can select “VHF only” in the ACARS Manager, and then select the default VHF as “Voice” (not Data) in the VHF Manager.
@Gysbreght
Ok, that’s a good point!
The question is whether that does the job of shutting down any transmission or some datalink (outgoing and/or ingoing) remains via either the other radio or SATCOM.
@Nederland: Is there evidence that there was a transmission by the Perth GES related to ACARS data after 18:25? I see no indication in the signaling logs. On the other hand, I do see evidence of failed attempts between 18:03 and 18:05.
The FI says that after the failure to send the ACARS message at 18:03:24, the message was auto-transmitted ever two minutes until 18:42:33. But this does not mean there were packets transmitted via satellite. Likely, the ACARS server did not forward these messages to the satellite link.
Or are you saying that Inmarsat removed ACARS entries from the signaling logs? I don’t think this is likely.
My understanding is that the repeated ‘Request for Acknowledge (RQA) User Data’ logs at 18:03 and 18:05 indicate the GES failed to transmit the ACARS text message to the aircraft.
I would assume any further attempt to retransmit was via VHF.
I was advised that the user data logs after 18:25 are too small to contain ACARS data and are probably consistent with the IFE logon.
Inmarsat said their data are complete, which I believe is a credible statement.
Another interesting obsevation is there is no indication that the IFE initiated any data transmission to the ground after 18:25. By contrast, it did so repeatedly and within short intervals before 17:07.
@Nederland: Likely the ACARS server has a table of all the clients that are logged in, including airline operation centers and aircraft. When the ACARS message was sent by MAS at 18:03, likely the ACARS server believed the 9M-MRO ACARS client was still logged in via the Inmarsat satellite link. The ACARS server tried between 18:03 and 18:05 to deliver the message, but no acknowledgement was received from 9M-MRO. It then removed 9M-MRO from its list of logged in clients. The subsequent retry attempts by the MAS client between 18:03 and 18:42 were never forwarded by the ACARS server to Inmarsat because 9M-MRO was not logged on the ACARS server.
As for sending it via VHF or HF, if 9M-MRO was not logged in to ACARS, how would it even know how to route the data?
@VictorI
How would you explain the attempts to retransmit for 40 minutes?
@Eoghan: thank you for your eloquent argument.
@Jeff: with respect: you are dead wrong on two counts:
1) That a call for transparency and accountability is connected to any particular scenario. It is not. It is in fact the opposite: it is – or should be – one of the few things on which we CAN all agree – that the general public has a fundamental right to know what search leaders know about this plane’s fate.
2) That a call for transparency and accountability has “zero chance” of leading to a proper audit. That depends on how hard we work together to demand it.
In my experience, we humans have grown over-fond of coming to debates equipped with our own disparate sets of “evidence”. You say I have no evidence of western complicity in a cover-up: my January, 2015 report – further bolstered by the search width simulations and drift study research you embraced – to me suggests otherwise. And each of its predictions seem to be coming true (search leaders’ “drifted to Indonesia” and “hard fuel limit at 38.3°S” claims are now abandoned…).
Since the efforts of many diligent grassroots researchers – including you – have revealed compelling evidence of a cover-up of SOME sort, we are now arguing with each other over the next questions: “By who?” and “Of what?”.
I would rather not ARGUE those questions – certainly not with folks who cheerfully set to zero the value of any evidence which conflicts with their pet theory (at last count, that describes ALL of us…). I would rather the value of an open society be demonstrated – by rallying public pressure sufficient to turn over stones, and ANSWER those questions.
What possible reason could there be for opposing the idea of a public demand for transparency?
@Nederland
“Inmarsat said their data are complete”
Do you have a reference for that?
Did they ever officially confirm the correctness and completeness of the summary that was published by Malaysia?
@Nederland asked, “How would you explain the attempts to retransmit for 40 minutes?”
Those are attempts by the MAS client (MHKULJACM001) to contact (via the ACARS server) the 9M-MRO client. That does not mean that the ACARS server in turn forwarded those messages. After 9M-MRO was removed from the ACARS server’s table of logged in clients after the failure to get an acknowledge at 18:05, it would not forward the message to the satellite link or any other communication link. Instead, it sent an automated “Failed” message to the MAS client.
@VictorI, Are we really sure that’s how it worked?
As @Nederland has pointed out, the FI says on p 48: “‘The first message sent to the aircraft cockpit printer from the MAS ODC was at 1803:23 UTC. The ACARS message requested the crew to contact the HCM ATCC immediately. The incoming downlink message at 1803:24 UTC showed the message failed to reach the aircraft. Messages are auto transmitted every 2 minutes and the message was retransmitted until 1843:33 UTC but all messages failed to get a response. Automated downlink message by ACARS showed ‘failed’. Message sent to the aircraft cockpit printer and the Automated Downlink messages are shown in Figures 1.9J and 1.9K, respectively.’
“downlink message” means from the satellite, surely? The illustration shown the top of p 48 of the FI, “Figure 1.9K: Automated Downlink Message” is Greek to me but the implication of this paragraph would seem to be not that 9M-MRO was listed as not-logged-on by SITA, but that the plane was not responding.
Apologies if I’m just being dense.
@jeffwise: You asked, “‘downlink message’ means from the satellite, surely?”
As you know, the satellite doesn’t generate messages, so if downlink is taken literally in the way you propose, it would be the AES terminal which generated the message. And then there would be record of this transmission from the AES terminal in the Inmarsat logs.
I believe “downlink” is being broadly applied to incoming messages to the MAS client all delivered by the ACARS server, which serves as a two-way proxy.
@Nederlander says he takes Inmarsat at its word and the logs are complete. I tend to agree, but I have no way to prove it. But, if I undersand your question, you are proposing that Inmarsat has deleted records. Is that what you are really proposing?
F.I. 1.9.4:
When the last ACARS message was at 17:07 why did MAS OCC not send a message to the airplane at 17:37 ?