Conformity Magazine - September 2007 - (Page 37)

A sk any embedded software engineer about EMC and they’ll probably say that it’s the hardware engineer’s responsibility (those that know what EMC means in the first place). However, try running any piece of microprocessor based hardware without code and you’ll see a significant difference in the EMC characteristics (not to mention a complete lack of functional performance) than the same product with code. Therefore it is obvious that the software does have an impact on the EMC performance of a product, but the biggest problem is that most of the software impact is difficult to quantify, and even more difficult for software people to accept and take any responsibility for. There are, of course, limits. All the great software in the world can’t compensate for a poor PCB design or a bad electrical circuit. But, assuming the hardware itself has been designed intelligently, there is a lot of benefit in considering the EMC impact of embedded software. (Note to readers: firmware will be used in this article for embedded software, and by this I mean software that contains the embedded function of a product and not platform code that is easy to change (i.e. not an embedded PC)). Proof Positive The traces in Figure 1 are taken from the same piece of Telematics hardware running two different application programs. The first was a speaking navigation system, and the second a silent stolen vehicle tracking product. It might be obvious that a speaking version would have higher emissions than a non-speaking version, but over the frequency range 30-200MHz? (Note: both had the same test harness and connected hardware, including speaker, for the test.) Clearly a completely different piece of software running on the same hardware platform can have significant differences in the EMC profile, although both passed the same immunity requirements (60V/m). What about the same software running on the same platform? Just to illustrate how sensitive a product’s EMC can be to software, the trace in Figure 2 is the difference between the same software, running on the same hardware, but with September 2007 Conformity 37 Figure 1: Same hardware, different firmware has a significant impact on measured radiated emissions (note: audio output is generating emissions in the 100MHz range). http://www.spira-emi.com http://www.spira-emi.com

Table of Contents Feed for the Digital Edition of Conformity Magazine - September 2007

Contents Editor’s Note FCC Extends Disability Access Requirements to VOIP Commission Fines Importer $3 Million Over Non-Compliant TVs FCC Gets Tough on Retailers Over Analog TV Tuner Labeling Analog Cellular Service Sunset Date Reaffirmed Commission Adopts Recommendations of Katrina Panel Free-Space Antenna Factors Through the Use of Time-Domain Signal Processing Editorial Correction ESD Open Forum An Update on Revisions to IEC 61000-4-2, the Basic Standard on ESD Practical Advice for Meeting the DFS Testing Requirements of the FCC The EMC Impact of Embedded Software ESD Design Buyer's Guide Tate Renominated to the FCC EPA Releases Report on U.S. Electronic Waste Additional Standards For The EU’s Toy Directive Medical Device Manufacturer Enters Consent Order Updated Guidance Document on Laser Products Issued FDA Offers Advice on Defective Heating Pads CPSC Issues China Product Safety Program Report Other CPSC Actions In The News IEC Standards Update Product Reviews Product News UL Standards Update From Our “You Can’t Make This Stuff Up” Department Looking Back: Items from Past Issues of Conformity Advertisers

Conformity Magazine - September 2007

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.