I am planning to run an ESD test on a product running traffic to some test equipment over gigabit ethernet and some other signaling interfaces (RS-232, USB, etc.) How do I decouple the ESD spikes from my test equipment so that I don't accidentally induce a failure in the test equipment instead of the device under test?
\$\begingroup\$
\$\endgroup\$
Add a comment
|
1 Answer
\$\begingroup\$
\$\endgroup\$
4
The conventional wisdom is to not connect the interfaces to expensive test equipment during the ESD tests!
Best strategy is to have your product equipped with loop back capability and establish product functionality based upon the success of that loopback working throughout the test. (My experience is that some classes of tests proscribed by agency requirements is that the equipment remain operational through the tests). Obviously the loop back has to happen at the end of the cables since typical application cables are must be installed on all ports during such tests.
If certain test fixtures are required make them with a robust design so that they have adequate protections. And bring a spare test set along to the testing lab so that if the fixture fails in the ESD test that you do not waste the test day and are able to continue to the other classes of tests on your product.
answered May 11, 2016 at 1:35
-
\$\begingroup\$ Yeah -- zapping box A can break the stuff in box B. Quite a nuisance. \$\endgroup\$ Commented May 11, 2016 at 2:01
-
\$\begingroup\$ Argh, yeah, that was what I figured. :-) I'm going to write the test plan showing the cable assemblies disconnected from the test equipment and see if the customer accepts it. \$\endgroup\$ Commented May 11, 2016 at 18:18
-
\$\begingroup\$ @JasonASoares - It is more then what the customer will accept. You have to deal with what the test engineers at the agency testing lab indicate what is required in order to pass the ESD tests. My past experience is that the equipment has to be shown to remain functional throughout the ESD events. There is obviously some leeway in defining "remaining functional" but substantial operational behavior needed to be demonstrated. One product I had to test was a video conferencing system I designed. The testing lab found it acceptable to define remaining functional as being a test (continued) \$\endgroup\$ Commented May 12, 2016 at 2:54
-
\$\begingroup\$ (continued from above) mode video call between two of out units wired up back to back via a local ISDN call loop back. If the "call" dropped it was considered a failure. If the user interface screen on the video monitor stopped working it was considered a failure. \$\endgroup\$ Commented May 12, 2016 at 2:56