I suspect many of us came into EMC unconventionally. I certainly did. I
walked into a job in EMC at Wang Labs after retiring from an Army career
that had me in the Signal Corps and Transportation Corps in
communications and repairing Avionics (also supervising and
instructing). I had been playing with electronics since age 12, when I
used a TV focus coil to build in my bedroom what some might call a
rail-gun.
On retiring from the Army I was a single parent with a pension that only
paid the rent. I wanted work as an instructor, but without a degree, the
only people who made an an offer paid less than I'd gotten on Active
Duty. Luckily, my my brother passed a copy of my resume' to his
neighbor, who worked for a large computer firm now defunct, Wang Labs. I
was able to show them I knew how to use the equipment and already had a
high enogh security clearance for Tempest work, so I was in.
Having come up through the lab, I look for not merely theory, but a feel
for systems and problems. A couple of my later employers had me
interviewing job applicants and I got an (undeserved, IMO) reputation
for being a difficult interviewer, handing candidates a ferrite bead,
for example, and asking, "What is this? What does it do?" and "How?" or
something like aPRD-219
<http://www.webalice.it/bruno.santalucia/UNK.JPG> and asking, "What is
this and how is it used?" (I own a couple.)
Most of the scrUwups I've seen were the result of engineers or managers
(not just in EMC):
1) Ignoring (or ignorance of) basic principles of EMC design; for
example, as Mother used to say (not really) "Cortland! Put that electron
back before he yells for his Dad!"
2) Neglecting to get all parties to producing a product to ATTEND design
reviews and point out what they can and can't do given the design and
desired results.
3) Ignoring (again BASIC) principles of shielding and grounding even in
testing (all too common).
4) Not talking directly to engineers and techs on projects outside their
own areas of expertise. Everything matters. Even firmware.
5) Not looking at systems a whole; test setups, platform or user
configurations, regulations and standard -- everything that concerns
emissions and susceptibility in use. It took time and effort (and one
actual RFI complaint) to convince a manufacturer of telco equipment that
if it was on or near a residential property it had to meet FCC Class B.
It has been the rare employer whose management was on board with EMC
problem *prevention*; perhaps surprisingly, one of my better ones was
Tandy, whose first venture into the IBM compatible computer market in
the late 1980's was not only yanked off the market by the FCC, but
incurred a sizable fine for not having been submitted for testing (it
failed). That'll motivate you! It did get a me a job there.
IMO, an organization needs both educated engineers and those who can
hold people to basic principles; if you do all the simple things right,
you will usually have done the complex ones too. WRT the EMC Cop role, I
prefer the missionary position (heh). Really, convert them, don't yell
at them. An Outside Expert many of us, at least in the US, know, was
called in to look at a PWB design and his first words to the CAD layout
guy were "Your board is a piece of sh*t!" How not to influence people,
etc. They did listen to my simpler and less confrontational advice
thereafter.
I'd have LOVED to get a job applicant who could show what's wrong,
what's right, and explain why in plain English; colleagues not in EMC
will often want simple rules: X mils of clearance and Y mils of prepreg;
Z mils of copper between bypass caps and devices etc. Sometimes it's
worthwhile to make design rules simple just to get them followed... but
one must know what the rules do, and why, and be able to teach those who
must follow them .
I was offered a job at DSC Communications (later Alcatel USA) as a test
engineer, and when I arrived, they gave me the choice of that or design.
That was no choice at all; I chose design for, as I answered when asked
why, test engineers have to fix the same problems over and over, but
design engineers can stop them from happening, By dint of constant,
friendly and informal oversight (I asked for and got read-only access to
the schematics and layout of every project from my own terminal) and
collaboration with designers in every group, I did that. I even got the
mechanical engineers on board. (That took a lunch and learn with a
modified stock-pot "shielded enclosure" and a hand held radio receiver.
) I didn't realize then, but I would learn, that I needed to keep an eye
on what the firmware and software did, too.
What does the EMC engineer need to be? Theoretician, practical engineer,
teacher, tech, missionary and salesman; electronics, metals, coatings,
insulators and chemistry; tooling, manufacturing and maintenance, all of
that too, essentially a systems engineer with a finger in every
discipline. If you find recent graduates that skilled, grab them, and
pay them what it takes to keep them, because they'll save a lot more
than it costs to have them around.
Retired, I still get an occasional contract to explain High School
physics to people who should know it. And I'm still learning.
Cortland Richmond
-
----------------------------------------------------------------
This message is from the IEEE Product Safety Engineering Society emc-pstc discussion
list. To post a message to the list, send your e-mail to <[email protected]>
All emc-pstc postings are archived and searchable on the web at:
http://www.ieee-pses.org/emc-pstc.html
Attachments are not permitted but the IEEE PSES Online Communities site at
http://product-compliance.oc.ieee.org/ can be used for graphics (in well-used
formats), large files, etc.
Website: http://www.ieee-pses.org/
Instructions: http://www.ieee-pses.org/list.html (including how to unsubscribe)
List rules: http://www.ieee-pses.org/listrules.html
For help, send mail to the list administrators:
Scott Douglas <[email protected]>
Mike Cantwell <[email protected]>
For policy questions, send mail to:
Jim Bacher: <[email protected]>
David Heald: <[email protected]>
