A consultant’s sloppy lab work leaves engineers mopping up
after him to produce an absolutely repeatable signal source
We were working on the development of a new type of sensor to detect
shock waves traveling through steel. Our challenge was to make our
sensors repeatable, which meant that we had to provide an absolutely
repeatable signal source. The challenge was to do this fast, and with
as little expense as possible, since this was still early in the
product development cycle and a large budget had not yet been allotted.
The input that we needed for the sensor was a shock wave traveling
between the surfaces of the metal that the sensor was mounted on. So
all that we needed was a perfectly repeatable source of impact, of just
the right amplitude—something that wound up being difficult to produce.
We tried a number of things, including a very repeatable ball dropping
from a pneumatically operated gripper. That was quite consistent but
One day a consultant who was working with us on the project announced
that he had found the solution, and had even published and circulated a
report on his discovery. His approach was to use a piezoelectric disc
from an acoustic sounder device, bonded to the plate, and driven with a
single cycle from a function generator. When the generator was set to
the plates resonant frequency, just one cycle would produce a beautiful
copy of the signal, from the sensor. A breakthrough! Our consultant was
going to publish a paper about HIS discovery, since it was so
We purchased an identical function generator and attempted to duplicate
his wonderful results. At this point it became very interesting,
because the signals that I did detect from our sensor were much weaker
and a lot noisier than the signals shown on his memory scope screen
shots. This was even though we had the same Tek scope as he had.
I was simply not able to obtain similar results, for quite a few hours
I kept at it, with the same weak results. Then the ground wire attached
to my piezoelectric driver became disconnected. Suddenly I had the same
big, beautiful, low-noise signal. The problem that became clear to me
was that this signal was traveling much to fast. The scope showed
no delay between the driving signal that would mechanically excite the
plate, and the detected signal from the sensor about 6 inches away.
Even though the shock travels about 3000m/ second in that metal, I knew
that there should be a delay of several microseconds. Then I noticed
the disconnected ground. The sad reality hit: The beautiful signal that
I was seeing was capacity coupled from the driver. Grounding the metal
plate removed all of the simultaneous signal, and left my noisy delayed
signal visible, and ugly. I disconnected and re-connected the ground
several times, and verified that was what was happening.
I wrote a report describing what I had done and the results that I got,
and then discussed it with my boss. He seemed a bit relieved that the
discovery was not something that he had overlooked, and should have
discovered himself. At the same time, he was disappointed that it did
not work. So now I had to find a way to make it work. I thought that it
was a good concept.
The solution came rapidly, which was to bring the driver element much
closer, so as to avoid the losses in the plate. What I did was to bond
our driver to one side of an aluminum plate about 0.010 inches thick,
and then attach our sensor to the opposite side. Now I was able to
ground the plate, disconnect the driver element ground return
connection, and verify that none of the capacitive signal was getting
through. Now I had the means to observe only the mechanically
transferred signal, and the means to verify that none of the capacitive
coupling was producing a signal. Our expensive consultant did
acknowledge that this was reasonable.
We used the back-to-back configuration of driver and sensor quite a
bit, and during every testing sequence, part of the procedure would be
to disconnect the ground lead from the driver and observe that there
was no capacitive signal coupling into the sensor. We called this “the
cheap reality check.” While my manager realized the value of this
discovery, the division manager continued to believe that “all
engineers are interchangeable,” and he showed his respect accordingly.
William Ketel is a hands-on electrical engineer
who enjoys troubleshooting and diagnostics, and Ham radio (Extra
class). His industrial machine projects range from an evaporator valve
calibrator to a brake drum inspection machine to crash-sled controls,
and a package to calibrate developmental crash sensors.
I think the title of the article doesn't seem to match the body of the article.
Given that the consultant probably should have tested more to ensure the results he was getting are valid. However, to completely dismiss him is not fair either. After all he came up with the so called solution that the EE refined. We have to give him credit for coming up with the solution.
I wonder what have happened if the consultant didn't come up with the solution?????
Much depends on why the consultant is there and who decided that he or she was necessary. Management ineptitude seems to me to be tolerated to a degree that would have long seen any consultant or engineer dismissed for it. Bad feeling between engineers needing help and consultants doing their best to give it smells strongly of inept management. Good engineers welcome all the help they can get and give as much as they can. Only bad ones hug their knowledge to themselves and try to outdo their colleagues by withholding information. I know the breed and have no time for them in any role.
This is one tricky story to interpret.
Generally, a consultant comes into an organization to bring upon a new perspective that regular workers might oversee This the reason why consultants exist and this consultant has done so. He has given a fresh perspective to a solution. Pursuing the consultants’ hint, an internal engineer has solved the problem which is great. That is what is to be expected. If the consultant has merely come in as an external pair of eyes, he has done his job. It is rather too optimistic to expect an external consultant (who is not an engineering expert) to practically solve an engineering problem for you,
However, if this consultant has presented himself as an engineering expert, it is not very smart of him to deliver untested solutions, and quite childish of him to expect to publish on such. I strongly believe that if you present yourself as an expert, you have to be one. Ideally, such engineering expert should be heads and shoulders above the internal staff engineers if they are to be contracted to solve engineering problems. Therefore, in my opinion, the problem is with the people who make such decisions and neither with the staff-engineer or the consultant.
While there are many ways to interpret the story, I have to disagree with Silicon_Smith that consultants are always gold diggers on other peoples hardships. They come in useful at times, the company has to be wise enough to contract the correct person at correct times. In my view, the call is with the management.
"My experience has been that it pays to verify ones results prior to telling others about them. Also, if a solution seems "almost to good to be true", it may well be that it is not true. "
This reminds me of Fleischmann and Pons cold fusion claim 20 years ago.
Thanks Ketel - sorry on my harsh comment. I was reacting to the article header and tagline which penalized someone for coming up with a good idea.
I understand the article better after reading your comment. I agree the consultant should have done the research and work completely before claiming glory.
Actually it's about both. It's a good engineering investigation and could just as easily have been in that column.
But Mr Ketel remarks at the end of the piece that "the division manager continued to believe that “all engineers are interchangeable,”"
It's this guy who I take strong exception to, not the consultant. People like this do their companies far more harm than sloppy consultants ever can.
I chuckled when I read at the beggining of the story.
'The challenge was to do this fast, and with as little expense as possible' which immediadately triggered the old saying. Time, Quality, Price. Pick two!
David Patterson, known for his pioneering research that led to RAID, clusters and more, is part of a team at UC Berkeley that recently made its RISC-V processor architecture an open source hardware offering. We talk with Patterson and one of his colleagues behind the effort about the opportunities they see, what new kinds of designs they hope to enable and what it means for today’s commercial processor giants such as Intel, ARM and Imagination Technologies.