You read the table correctly, and it seems to be confusing a lot of people.
To go through it logically (I think)

The longer the line, the more likely surge energy would be coupled into a
cable -- certainly the case for induced lightning transients.

Terminated lines shorter than a few meters are not likely to pick up much
energy from lightning but keep in mind the old lineman's rule of thumb that
says "1kV across 1 meter or unterminated wire, 1 mile from the flash"! 

Hence, protecting inputs connected to long lines against surges makes sense,
whether they go outside a building or not. If you wrap a mile of wire (data
cable) around a high rise building, I would argue you have just constructed
a lightning antenna. In residential structures, there is no building steel
to help with shielding or grounding, so you might as well be outside for
purposes of coupling a transient into your system.

It follows that the IEC or EU would require surge testing long I/O lines.

Problem is: IEC wants to insure no upset or loss of operation, which means
testing the product live, with data flowing. This requires some kind of
coupler/decoupler in series with the line to the equipment being tested.
Works okay for slower data rates (<~100kHz), but no one has yet designed a
coupler/decoupler that works at the higher data rates that exist today.
Using existing coupler/decoupler designs will insure loss of data; hence,
the "unless normal functioning cannot be maintained because of the impact of
the CDN on the EUT" clause applies. Not sure I understand the reasoning, but
if you get a real live surge from the real world, data will certainly be
interrupted as well.

Reality is: if you want to insure minimum loss of function on a long I/O
line, you really want to know if the inputs are protected adequately, and
you can do this without a coupler/decoupler. Bellcore, CCITT, FCC and others
all surge test inputs directly without any data (knowing full well that
during the surge event, data will be interrupted anyway) then connect the
line and see if the input circuitry is still functioning.....

In the course of revising IEC 61000-4-5 for surge, it's this last paragraph
that I'm pushing for. That gets rid of the coupler/decoupler design problem
and provides a way of establishing a basic level of immunity for any kind of
I/O or telecom line.

Hope this helps,


Michael Hopkins
KeyTek
(also, convenor SC77B WG11 responsible for the revision of 61000-4-5, so if
you have anything to contribute, let me know)

 




-----Original Message-----
From: Terry Meck [mailto:tjm...@accusort.com]
Sent: Friday, January 05, 2001 9:23 AM
To: emc-p...@ieee.org
Subject: EN 61000-6-2 Table 2.3 inticates signal ports => 30 M +/- 1kv?




If I read the EN 61000-6-2 correctly Table 2.3 indicates signal ports => 30
M must be tested +/- 1000 surge " unless normal functioning cannot be
maintained because of the impact of the CDN on the EUT"  

This surprises and confuses me since I thought this would be imposed only on
cables leaving a building.  

Any insight on this will be appreciated?



Best regards,
Terry J. Meck
Senior Compliance/Test Engineer
Phone:215-721-5280
Fax:215-721-5551 hard copy;
Fax PC: 215.799.1650 To my desk PC
tjm...@accusort.com
Accu-Sort Systems Inc.
511 School House Rd.
Telford, PA 18969-1196 USA



-------------------------------------------
This message is from the IEEE EMC Society Product Safety
Technical Committee emc-pstc discussion list.

To cancel your subscription, send mail to:
     majord...@ieee.org
with the single line:
     unsubscribe emc-pstc

For help, send mail to the list administrators:
     Jim Bacher:              jim_bac...@mail.monarch.com
     Michael Garretson:        pstc_ad...@garretson.org

For policy questions, send mail to:
     Richard Nute:           ri...@ieee.org


-------------------------------------------
This message is from the IEEE EMC Society Product Safety
Technical Committee emc-pstc discussion list.

To cancel your subscription, send mail to:
     majord...@ieee.org
with the single line:
     unsubscribe emc-pstc

For help, send mail to the list administrators:
     Jim Bacher:              jim_bac...@mail.monarch.com
     Michael Garretson:        pstc_ad...@garretson.org

For policy questions, send mail to:
     Richard Nute:           ri...@ieee.org

Reply via email to