Malaysia Airlines 777 missing

Just thinking, they should have the spin up time in Kuala Lumper... plus the 40 minutes to point of lost contact and then 4-5 hours data - so the time stamp should not be important, it would all be relative...
True, I was just thinking that this kind of misinformation could have leaked out by somebody that only got part of the story right. Like, there was data at xx:xx, without knowing the entire time window was shifted due to time errors.
 
Flight MH370 replied "All right, roger that" to a radio message from Malaysian air control, authorities said.

The only time I hear this phraseology is in the movies
I used to work with a guy that said that literately after every single transmission, now he works for a regional commuter!
 
I learnt a lot of information today, I like the discussion
image.jpg

Strong with you language is not.
 
I'm wondering if it isn't the satellite that continues sending stand-by messages if a flight isn't closed out properly based on aircraft input.

The way I read it was the SATCOM radio was connected to the satellite and ready to send, but had nothing to send (i.e. the link from the the sensors to the SATCOM transceiver was somehow severed, or the sensors were turned off). Definitely peculiar if true.
 
The way I read it was the SATCOM radio was connected to the satellite and ready to send, but had nothing to send (i.e. the link from the the sensors to the SATCOM transceiver was somehow severed, or the sensors were turned off). Definitely peculiar if true.
I was thinking that there might be an "end of file" or "end of transmission" string, which would be consistent with how some simple data files are constructed. Once a data file is open, it could stay open until it gets an "end of transmission" string or times out.
 
I was thinking that there might be an "end of file" or "end of transmission" string, which would be consistent with how some simple data files are constructed. Once a data file is open, it could stay open until it gets an "end of transmission" string or times out.

That could be as there would be no reason for the system to keep querying a plane that has completed it's flight and is shut down at the gate. I know that on the previous plane I flew (ACARS instead of SATCOM) after blockin at the gate it would dump a whole bunch of data to the system including all kinds of telemetry and engine parameters and then go silent until you started up an engine again.
 
That could be as there would be no reason for the system to keep querying a plane that has completed it's flight and is shut down at the gate. I know that on the previous plane I flew (ACARS instead of SATCOM) after blockin at the gate it would dump a whole bunch of data to the system including all kinds of telemetry and engine parameters and then go silent until you started up an engine again.
Just thinking how I would program the logging of a data stream (a bit of C++ and Ada experience). You would have to account for transmission interruptions, so it makes sense to loop until you get a termination string. I'd be curious what these data files indicate when there is a break in transmission, maybe "stand-by"?
 
I was thinking that there might be an "end of file" or "end of transmission" string, which would be consistent with how some simple data files are constructed. Once a data file is open, it could stay open until it gets an "end of transmission" string or times out.

I wish I knew enough about SATCOM to know for sure. I've studied other RF telecommunications systems and usually the subscriber unit has to sent a request to connect with a unique ID number and serial number, which is authenticated by the base station and a digital handshake and channel grant process ensues. Upon receipt of the message, there's an unkey/EOF message that terminates the call. My impression from the article was that this happened once per hour for four hours following loss of contact with the airplane. Thus, each time it would have had to be initiated by the SATCOM on the aircraft. Satellite bandwidth is expensive enough that there would almost certainly have to be a time out feature preventing an open line for continuing for that four hour period.

I was curious where the SATCOM antennas were relative to the transceiver (given all the speculation about the fatigue crack AD) and I found this picture:
post-418035-1394542478.jpg


The LNA/DIP is a diplexer and RF amplifier box, so the signal must travel from the transceiver (presumably in the avionics/electronics bay) all the way aft along the ceiling of the aircraft via coax cables. In other words the electronics bay under the cockpit would still have to be physically connected via coax to the SATCOM antenna on the rear upper fuselage in order to send those signals, which would rule out an inflight breakup. Then again the Malaysians deny the SATCOM signals were received at all, so at this point who knows what to believe.
 
The way I read it was the SATCOM radio was connected to the satellite and ready to send, but had nothing to send (i.e. the link from the the sensors to the SATCOM transceiver was somehow severed, or the sensors were turned off). Definitely peculiar if true.

Successful ditching? How long did the sully float before going under?
 
That could be as there would be no reason for the system to keep querying a plane that has completed it's flight and is shut down at the gate. I know that on the previous plane I flew (ACARS instead of SATCOM) after blockin at the gate it would dump a whole bunch of data to the system including all kinds of telemetry and engine parameters and then go silent until you started up an engine again.

I found this link on the Engine Health Management (EHM) via the Aircraft Condition Monitoring System (ACMS) on the Rolls-Royce website:
http://www.rolls-royce.com/about/technology/systems_tech/monitoring_systems.jsp

It breaks down the types of messages the ACMS sends via ACARS, and when they're sent.

Most modern large civil aircraft use an Aircraft Condition Monitoring System (ACMS) to acquire the data for EHM. This captures three types of reports:

The first are snapshots, where the sensor data listed above is captured and collected into a small report. This is carried out during take-off, during climb and once the aircraft is in cruise.

The second type is triggered by unusual engine conditions. Examples might be if an engine exceeded its TGT (Turbine Gas Temperature) limits during a take-off. These reports contain a short time-history of key parameters to enable rapid and effective trouble-shooting of the problem.

The final type is a summary, which is produced at the end of the flight. This captures information such as maximum conditions experienced during the flight, and power reductions selected during take-off and climb.

The Trent 900 is the first engine to be fitted with a dedicated Engine Monitoring Unit as well as the ACMS. This engine-mounted system places a powerful signal processing and analysis capability onto the engine. A fan -mounted EMU is shown below:

This is used to look in more detail at the vibration spectrum, which helps to pick up problems with bearings or rotating components. It also provides a flexible computing platform so new EHM software can be rapidly deployed to detect specific problems.
If you go to the site, it has a photo of the dedicated Engine Monitoring Unit, which has additional sensor inputs to monitor engine vibration (which was something I noticed was absent from some of the shorter ACARS snapshots).
 
Someone on pprune speculated about the cockpit O2 bottles in the avionics bay causing a fire or rapid decompression or both. I have no idea what happened but that theory would explain a lot of things.
 
Back
Top