The Case of the Burning Solenoid

DN Staff

February 2, 2010

4 Min Read
The Case of the Burning Solenoid

An engineer may find himself on the next plane to Karachi if he can’t solve a problem with a digital flight recorder

By Contributing Writer Guy Olbrechts

Twenty years ago I worked in customer engineering at an avionics company. One day, one of our international airline customers, Pakistan International, complained that a solenoid in our QAR, a digital flight recorder used to record maintenance data, kept burning up. This solenoid was used to press the tape against the recording head via a roller. This sudden occurrence of multiple failures was very strange because we had maybe a hundred customers operating several hundred recorders for years without any such problems.

The recorder had an input for bipolar data and another one for bi-phase data. Input selection was determined by the state on a separate select line. The solenoid required a high current to pull in the plunger and once pulled in, this current could be reduced to hold the plunger and had to in order to prevent overheating and burn out. The recorder was designed not to run unless data was present at either input.

A data activity detector at the signal inputs detected if the signal was jumping up and down. If so, the solenoid received a strong DC current at first. After a short time, circuitry changed the current from DC to pulsed to hold the plunger in place while appreciably reducing the average current.

I suspected that somehow the circuitry in this case operated too much in continuous mode rather than pulse mode. This could happen if the applied data was intermittent, but the data stream was the same as at our other customers. I verified the solenoid drive circuit but did not find anything wrong–anyway, it had been working fine before. I asked and received a diagram showing how the recorder was connected to the other equipment in the aircraft.

It showed that the recorder received data on both the bipolar and the bi-phase inputs from different sources. Source selection occurred via the select line. I did not think our other customers had data simultaneously in bi-phase and bipolar form. They applied either one or the other, and they hardwired the select line accordingly. This led me to take a closer look at the activity detector. Whichever input was selected, it received the data from both inputs in an OR fashion.

We did not have the data source equipment to duplicate the airplane setup, but I was able to compute the probability: I knew the characteristics of the input data streams and assumed that they were uncorrelated and that the continuously varying states from both inputs could cancel each other out long enough for the activity detector to time out.

With a single input active, the activity detector input state was guaranteed to change state at least 768 times per second, and the circuit was allowed to time out after a fraction of a second. But with two inputs active, my computations indicated that every few seconds a time out and re-initialization could occur because data states on both lines could negate each other’s effect. This would be enough to overheat the solenoid.

To verify my theory I flew to Teledyne in Los Angeles, which was more convenient than flying to Karachi, where they had a customer setup including the data sources and our recorder. Verification of the data inputs and the combined signal at the data activity detector confirmed my theory.

I initiated a simple modification to the activity detector, allowing only the selected data source to drive it, and I sent instructions to Pakistan International how to implement it. They promptly did so but a couple of days later they telexed that they still had a solenoid failure, destroying all my confidence. The next day however they telexed me that it had been a mistake and that the failing recorder had not yet been modified. There were no more complaints after that.

Contributing Writer Guy Olbrechts worked 13 years at Boeing as an electronics engineer, first designing ground-based computerized test systems and later on in inertial navigation R&D. He then worked 15 years at Sundstrand in flight recorder and ground prox warning customer engineering. For the last 15 years, he has worked as a consultant in flight recorder data analysis for Avionica. 

Sign up for the Design News Daily newsletter.

You May Also Like