Hi Janine, is it the flight data recorder or the beacon/telemetry radios that was turned off or maybe even the ID transponder? To my mind the ID transponder shouldn't be able to be switched off because that's what decides if you get blown out of the sky or not I would have thought. I think this incident as regrettable as it is may bring about some real changes in the way commercial airlines are instrumented. I'd like to see the GPS data sent to satellite on all comercial planes over 1-2 ton and without an on/off switch, ie. it should be on as soon as the plane leaves the ground. If that data were transmitted (ID, Lat, Long) every minute, it wouldn't break the bank and we wouldn't be wondering where that plane is.
Turning off a transponder because somebody's screen is too cluttered with data would be just plain stupid. You just filter what is displayed at the moment.
I'm thinking we might prefer that a drone captured by the Soviets would somehow loose its memory so we could say "what drone? We've been looking for that wayward boy! Wow, what gas mileage!" rather than "see, here it burst out its photos back to DC..."
In a civi aircraft it might be good to have cockpit recordings (voice, position, data, system...) that can't be turned off, even by personnel - or loss of primary electricity.
These articles are pretty thin on info. Even the ever-thorough CNN was showing ACARS transmitting every 30 minutes. Seems there was an old Black Box "teardown" at ESC (remember ESC?) five years ago (admittedly, it was a pretty old box).
I think what we need right now is that black box from "2001: A Space Odyssey" to beacon out where it is.
The transponder signal takes up space on the ATC radar display. (A controller's screen has to show many miles in less that a metre.) If too many signals come from the same point (as far as the screen resolution is concerned), they overlay and blur each other.
The transponder is switched from "standby" (warming up) at the runway threshold, just before takeoff, and back to standby, or off, after landing.
Its possible that the tower can request to turn off the Transp. and nobody else, if too many signals coming in. Both the pilot and tower can turn it on only. Also about the recoding box should go off and wake up on demand when request comes, so battery life is preserved.
@perl_geek: "It is necessary for the crew to be able to switch transponders to a non-responsive mode, because otherwise the signals can overwhelm the system, (e.g. around airports)."
I was searching for an answer to the question why there is a provision kept for the crew to switch the transponder off. Thanks for the answer to that. A continuing question that occurs to my mind now: is the intention not to overcrowd controller's radar screen or not to "overload" the system with too many signals from all different flights?
The military designation of the transponder is IFF "Identification Friend or Foe". Depending on the level of sophistication, a transponder replies to a pulse from ATC's Secondary Surveillance Radar with a 4-digit code, (Mode A, the basic level), possibly altitude, (Mode C), and additional information, (Mode S). On request from ATC ("Squawk Ident"), the pilot can make the response pulse distinctive, for identification. Special codes are available to identify hijacking, communications failure, and Mayday situations, in case radio communication is impossible or difficult.
It is necessary for the crew to be able to switch transponders to a non-responsive mode, because otherwise the signals can overwhelm the system, (e.g. around airports).
The FDR (Flight Data Recorder) records the data from the aircraft's systems and controls, while the CVR (Cockpit Voice Recorder) records the sounds in the cockpit for the last hour (I think). This provides a record of the crew interactions, (and sometimes vital clues as to explosions, decompressions, engine failures, and other events). The crew have no control over these records.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.