Hi Robert,
A system integrator on a PC platform, that must be a EMI designers nightmare !!! Some remarks: > with the signaling barely meeting eye diagram requirements This alone indicates EMI out of control ! >. 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 Good PCB EMI design improves clock and harmonic content of the signal. The reason a fast signal gets disturbed is bad EMI design. Such a design “lets escape” the high frequency components into space because of enclosed surfaces (coils). > It is impossible to anticipate all EMI sources (or EMS victims) in a complex environment Is it ?? Most often the problems are not to be solved because of certain restrictions, such as budget, design platform (PCbus) , or time, and the designer did not realize in time he started a mission impossible. > speed I/O must be passed through chassis boundaries into cables, often mostly unfiltered, thus ensuring that emissions problems will exist in certain situations Not per se, selecting the right cable and signal type, and controlling impedance can do a LOT. Why 100 base-T works on UTP ?? >is cost prohibitive and not feasible in commercial applications Why ? I see designs fully stuffed with decoupling caps , where 5 are sufficient. A few small R’s/C’s at in/outputs and for high speed /balanced signal a small CM coil combined with a good PCB design will do a lot. Many EMI problems I encounter are caused because of “old” design techniques that persist in being used on modern fast PCB’s: - multiple grounds: I still have to meet the design where this is really necessary - analogue ground (!!!): not required on everything < 18 bits, even if the chip mfg suggests so - flatcables without GND on impair wires: these are efficient antenna’s - unbalanced signal transmission on substantial parts of a wavelength (for the signal in question) , - multiple PCB in 1 system without proper ground connections: with proper I mean full ground on 4 corners of the PCB minimum - connect output cables on floating PCB’s (in the case of motherboard and bad grounded plug-in) : jackpot on EMI problems ! - plug in CPU PCB with only one ground pin: I wonder why they work in the first place - use a backplane (variation of the above): one should use at least one row of a 1,2,3 x 64 pin connector to ground - try to distribute ‘hard” clock signals over distance : soften them by impedance, or transfer them differentially - use 2 layer PCB for everything over 1 MHz: no comment - use the ground plane for signal traces ( engineer: just one !! ???) : one layer should be full undisturbed ground - scatter IO connectors on a PCB instead of grouping them on one side (lazy design): ground potential might not be equal everywhere - not enough distance between fast signals and a connector: parts of ground current may rise ground potential at this place: keep 10 mm And so on… Having Van: E. Robert Bonsen [mailto:[email protected]] Verzonden: vrijdag 8 mei 2009 0:37 Aan: ce-test, qualified testing bv - Gert Gremmen CC: [email protected]; [email protected] Onderwerp: Re: Compliant plus compliant does not equal compliant! 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] 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]>
