Hi everyone,
Is anyone on the list familiar with the work on CISPR 22 and a part of the standard committee? I am looking at CISPR 22 Edition 5 (2005), trying to understand the specific requirements on ISN and CDN for Signal Line Conducted emission, especially the so called Longitudinal Conversion Loss (LCL) and the appropriateness of the ISN and CDN for Ethernet (four unscreened differential pairs). I see some issues that can affect Ethernet devices, and since there are many of such devices on the market that are or will be tested according to this standard, I believe there might be considerable general interest to adopt a test method that is appropriate to Gbit Ethernet and similar devices. If anyone has any influence on the development of this standard, and is willing to discuss it further with me, I would appreciate it off line, and using my work email address, which is npis...@broadcom.com Here are just some of the issues I see: If I am reading the Edition 5 correctly, the LCL (specified in 9.6.2) must be within the limits on the page 51. I am troubled with the intent of the standard is to introduce (create) imbalance by the ISN or CDN in order to “simulate” real installations. I have extensive background in the associated topics, and I have not seen any objective and verifiable data that would support the limit in LCL. Is there anyone who might present such data and the method that lead to the data? BTW, I can’t find in the Standard the suggested method to measure LCL, nor can I get the LCL-data from a prominent ISN/CDN vendor who I contacted (!). In my opinion, it would be much better to define “minimum” LCL, and allow using ISN and CDN with (infinitely) better/higher LCL. That would make it easier to design ISN and CDN. Depending on the construction, it may be hard enough to design a well-balanced ISC/CDN, and it is even harder to purposely imbalance it with a predefined characteristics. If the intention of the Standard is to create something that would “look like real installation”, that could be taken into account by adjusting the limit-line - assuming that one knows how “real-installation” looks WRT conversion, which is very questionable. Using an ISN of Figure D.3 is likely going to affect the Ethernet signals, to the point that the interface would fail the IEEE conformance (one parameter that immediately comes to mind is Return Loss) or the manufacturers’ spec on cable-reach. That is especially because of L3-L6 and maybe due to L1-L2. Therefore I don’t think using this ISN is appropriate, at least not with the specification as-is, although that is what some (maybe many) test labs use. The ISN form Figure D.6 might be more appropriate for Ethernet, but again here is the issue (in my mind) of the LCL as I described above, plus additional need of a decoupling the AE-side. The issue of affecting the signals remains, although the interface would “work” if the only criterion for “working” is whether it passes data through some length of cable. I can, relatively easily, construct a 150-Ohm ISN that would be much more appropriate for Ethernet, and that is well-balanced (not intentionally imbalanced). It could be imbalanced if required, but I don't feel it ould be appropriate - as I have described ealrier. As I mentioned in the introduction, since Ethernet has such a broad application, I believe it might be even appropriate to offer it in the Standard an alternative ISN construction that is appropriate for Ethernet. Of course, the current and voltage clamp metod is well-suited, but the test is cumbersome and may result in over-testing (worst-case), so I would prefer a more forward (but also a more appropriate) method. Enough for now, if there is any interest this topic – especially by anyone who might have inputs to CISPR22 – this can be taken farther from here (preferably off-line) and to my work email. Regards, Neven Pischl Senior Principal Engineer Networking Infrastructure Applications Broadcom Corporation San Jose, CA npis...@broadcom.com - ---------------------------------------------------------------- This message is from the IEEE Product Safety Engineering Society emc-pstc discussion list. Website: http://www.ieee-pses.org/ To post a message to the list, send your e-mail to emc-p...@ieee.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 emcp...@ptcnh.net Mike Cantwell mcantw...@ieee.org For policy questions, send mail to: Jim Bacher: j.bac...@ieee.org David Heald: emc-p...@daveheald.com All emc-pstc postings are archived and searchable on the web at: http://www.ieeecommunities.org/emc-pstc
