Michael/Gert
When I worked as a design engineer for an ITE integrator, many manufacturers
of subassemblies disagreed that their (sub)system had to be EMC compliant in
all situations. Most had an assumption of what they considered "reasonable"
shielding effectiveness and immunity control that the chassis and platform
should provide to assist the subsystem in meeting compliance requirements.
Thus, the subsystem manufacturer felt that as long as compliance was
demonstrated in a platform of their choosing, any residual EMC problems
related to their subsystem were related to our platform/chassis being "weak".
Playing nice with other subsystems on the platform was even less of a
consideration.
Just as one example: We had a video card sitting next to a high-end audio
card, each very compliant on its own, near-field coupling RAM clock directly
into the analog ground of the audio card failing our tests by 12dB off the
headphone jack. The emission could not be suppressed according to the video
card manufacturer, as it was straight off the RAM chips, with the signaling
barely meeting eye diagram requirements, precluding slowing edges or reducing
amplitude. The PCB was about to go into production, so layout changes were
allowed to improve decoupling or no shielding could be added without delaying
release to sales (for which there was no business case of course and the
cost-add would reduce already tight margins). At the sound card, the analog
ground was deemed necessary to ensure sufficient dynamic range and that was
non-negotiable. It was an off-the-shelf unit, so no changes could be made to
the filtering on the jack. End of discussion. We had to make a business
decision for EMI reasons, and the card with the lowest upsell margin was
restricted on that particular platform. The program manager was not thrilled.
As a design engineer I agree that EMI control at the source and EMS reduction
at the victim are strongly desirable and often achievable. However, for
certain types of high-speed signals or clocks sufficient source control is not
necessarily feasible as signal integrity requirements pose restrictions on
harmonic content control and source filtering. For these types, eye diagram
requirements (mainly amplitude and jitter) as well as skew requirements in
diff pairs are very tight. Also, integrated circuits with cutting edge
interfaces are often noisy and a source of near-field coupling problems (both
EMI and EMS). Waiting until a cleaner chip arrives is not an option in an
industry where being first to market with a product can make or break
profitability. Using more expensive materials for PCB design would improve
impedance control and improve eye integrity (so source suppression can be
used) but that is akin to simply adding layers-- it's a cost add without sales
benefits. These are just a few examples of issues.
It is impossible to anticipate all EMI sources (or EMS victims) in a complex
environment such as a PC. Noise from clocked interfaces at several GHz will
find a chassis opening. Intentional signals from high-speed I/O must be passed
through chassis boundaries into cables, often mostly unfiltered, thus ensuring
that emissions problems will exist in certain situations. The business
requires cost to go down, EMC control drives cost up. That's life, and the
fine balance between cost and EMC performance is what keeps a few handfuls of
EMC engineers and technicians employed at the big system integrators.
I suppose the point I'm trying to make is that it is possible to use military
practices and make systems/subsystems highly immune as well as low on
emissions, but that is cost prohibitive and not feasible in commercial
applications. The business case is simply not there as customers are unwilling
to pay the incremental cost of improving EMC on a unit. In this world, $0.10
per unit impacts hundreds of thousands to the bottom line.
Anyway, just my lengthy $0.03.
-Robert
E.Robert Bonsen
Sr. Consulting Engineer
Orion Scientific
ce-test, qualified testing bv - Gert Gremmen wrote:
>The best approach -IMHO- to control EMI is to minimize potential
emissions
at the source,
>reducing the need for filtering and shielding. This must happen during
the
design
>and must involve EMC experts. An approach which is not generalized yet
-
unfortunately
But that doesn’t take care of potential immunity problems.
They get unnoticed until tested for, or in the field when it’s too
late.
Keep the gates to your equipment closed.
And another rule of thumb, that any designer should
obey too :
Never connect a semiconductor in- output low impedance galvanically
to a
cable port,
always insert some impedance !
Regards,
Ing. Gert Gremmen
[email protected] <mailto:[email protected]>
www.cetest.nl
Kiotoweg 363
3047 BG Rotterdam
T 31(0)104152426
F 31(0)104154953
Van: [email protected] [mailto:[email protected]] Namens
[email protected]
Verzonden: Thursday, May 07, 2009 11:15 AM
Aan: [email protected]
Onderwerp: RE: Compliant plus compliant does not equal compliant!
This is the unfortunate case of ideal world vs.. real world.
A manufacturer of a subassembly will not design for the EMC behavior
of other components in the target system unless he is really aware
and involved in the system integration or forced to do so by other
means.
A manufacturer of a card for, let's say, a PC can use a (current) model
of his choice for EMC testing and it is unlikely that the worst case
will be used in this case for many reasons.
The principle of due diligence applies, but is often victim to other
principles...
One way out of this dilemma could be a standard which uses for
example your findings to define the requirements and an environment
for verification, but the only applicable field I see are relatively
simple systems. With more complex systems, you get a mix of shielded
and unshielded cables depending on the required interfaces, making a
standardized approach difficult.
The best approach -IMHO- to control EMI is to minimize potential
emissions at
the source,
reducing the need for filtering and shielding. This must happen during
the
design
and must involve EMC experts. An approach which is not generalized yet -
unfortunately.
Best regards,
Michael Nagel
Michael Nagel
Senior Staff EMC Test Engineer
Embedded Computing
Emerson Network Power
T +49-89-9608-0
F +49-89-9608-2376
[email protected]
www.emersonnetworkpower.com/embeddedcomputing
Emerson Network Power - Embedded Computing GmbH,
Lilienthalstr. 15, D-85579 Neubiberg/Landkreis München, Deutschland /
Germany.
Geschäftsführer Josef Wenzl, Amtsgericht München HRB 171431,
VAT/USt.-ID:
DE 127472241
From: ce-test, qualified testing bv - Gert Gremmen
[mailto:[email protected]]
Sent: Montag, 27. April 2009 19:57
To: Nagel, Michael [NETPWR/EMBED/DE]; [email protected]
Subject: RE: Compliant plus compliant does not equal compliant!
All of these cases happen when a device
or apparatus passes by sheer luck instead of design!
For example:
The port in question was not radiating at a resonant
frequency because the WAS no such frequency in
the EUT . Connecting a peripheral having such
a frequency on board would connect it’s lead
to this port and make it resonate. Or
the lead length would be doubled in length compared
to the test setup, allowing more efficient radiation.
Or the connected EUT was transparent for RF and now
Its other leads are radiating too, creating a antenna
system with longer leads and radiating more efficient
at lower F.
It all happens when EMI is NOT under control.
I/O ports should always be considered
as an open port needing to be RF “firewalled”
Allowed signals should pass, unwanted signals should
be blocked.
There are a lot of problems with software design
but here we can learn something of those guys.
No open ports!
Good EMC design does not let one port open, unfiltered
or unshielded and keeps it’s CM input impedance nor a short
to enclosure (but for shielded cables), nor an infinite impedance,
but ideally 150 ohm to enclosure.
This effectively reduces resonant behavior.
CM signals should meet a high ( >300 ohm) input impedance
between lead and circuit.
A peripheral should “end” a EUT’s cable, not extend it !
BTW that is why I do not like shielded cables
to prevent EMC problems. Their functionality
depends heavily on (very) low impedance paths
to ground, which is acceptable in laboratory
conditions, but difficult to maintain in industrial , automotive,
dirty
and corrosive environments.
Gert Gremmen
Van: [email protected] [mailto:[email protected]] Namens
[email protected]
Verzonden: woensdag 15 april 2009 17:41
Aan: [email protected]
Onderwerp: Compliant plus compliant does not equal compliant, was:
"Quiet"
Laptop
Hello!
As pointed out below (and during the thread), the whole issue shows,
that two
devices, being measured compliant, are not automatically compliant as a system
when measured together.
A 'quiet' USB device connected to a 'quiet' host can pass with a poorly
shielded cable.
The same device with the same cable will most likely fail when
connected to a
'loud' host.
<insert finger pointing between manufacturer of USB device and host
here>
Given the number of different product/designs in domain of personal
computers
that can be plugged together, I cannot imagine an easy way to cope with that.
Currently it is cost vs. pressure of the government agencies which
establishes some kind of balance.
System integrators try to cope with that by imposing lower emission
limits to
their suppliers.
This works, but not in every case.
I have seen a computer fail radiated emissions testing thanks to a
printer
connected to it. The physical arrangement of the I/O ports helped to build an
antenna.
The same printer must have passed in another configuration. The same
computer
passed radiated emissions testing with a different printer.
Any similar experiences?
Best regards,
Michael Nagel
Michael Nagel
Senior Staff EMC Test Engineer
Embedded Computing
Emerson Network Power
T +49-89-9608-0
F +49-89-9608-2376
[email protected]
www.emersonnetworkpower.com/embeddedcomputing
Emerson Network Power - Embedded Computing GmbH,
Lilienthalstr. 15, D-85579 Neubiberg/Landkreis München, Deutschland /
Germany.
Geschäftsführer Josef Wenzl, Amtsgericht München HRB 171431,
VAT/USt.-ID:
DE 127472241
From: [email protected] [mailto:[email protected]] On Behalf Of Bill
Owsley
Sent: Mittwoch, 15. April 2009 15:57
To: EMC-PSTC; [email protected]; Piotr Galka
Subject: Re: SV: "Quiet" Laptop
"...if all devices were tested separately the number of observed problems
during using them in sets will grow by zero, zero, nothing."
Alas,
The problems seem to grow by the cube of the permutations of geometric sum of
triple integral of number of connections. <;-)
The symptom that empty ports don't radiate much, nor do poorly terminated
cables that are not plugged into previously mentioned ports, seems to manifest
when those two parts are plugged together, thus the reason for "system"
testing.
- Bill
Indecision may or may not be the problem.
-
----------------------------------------------------------------
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.ieeecommunities.org/emc-pstc
Graphics (in well-used formats), large files, etc. can be posted to
that URL.
Website: http://www.ieee-pses.org/
Instructions: http://listserv.ieee.org/request/user-guide.html
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]>
-
----------------------------------------------------------------
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.ieeecommunities.org/emc-pstc
Graphics (in well-used formats), large files, etc. can be posted to
that URL.
Website: http://www.ieee-pses.org/
Instructions: http://listserv.ieee.org/request/user-guide.html
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]>
-
----------------------------------------------------------------
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.ieeecommunities.org/emc-pstc
Graphics (in well-used formats), large files, etc. can be posted to
that URL.
Website: http://www.ieee-pses.org/
Instructions: http://listserv.ieee.org/request/user-guide.html
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]>
-
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.ieeecommunities.org/emc-pstc
Graphics (in well-used formats), large files, etc. can be posted to that URL.
Website: http://www.ieee-pses.org/
Instructions: http://listserv.ieee.org/request/user-guide.html
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]>
