Kris,
What I’m saying is that while a USB port should be LPS, you cannot assume that all USB ports will be LPS. Consider putting a PTC on the 5 Vdc input of your slave device. Then apply Method 2 from 60950-1 cl. 4.7.1, application of all simulated fault tests in 5.3.6. The selected fault condition per 5.3.6 c) should not be one that simply shorts +5 V to return, and thus trips the PTC right away, but a fault condition that causes the fault current to be just below the I-trip rating of the PTC for extended periods. Measure the temperatures on the enclosure plastic to confirm that it is insufficient to cause ignition of the plastic enclosure. I would consider soldering a resistor in place for the fault that would simulate a fault current just under the trip current rating of the PTC, and measuring the temperatures on the resistor; in fact, you should be able to calculate what that temperature on the resistor body will be. You will have to consider the PTC device ratings; it will go into high impedance mode eventually at any current above I-hold – you’ll need to set the fault current to the highest setting that the PTC can handle for an extended period, say 7 hours. The PTC specs should have curves that will help you pick the appropriate current. This way, you have proved that under the worst-case fault conditions, your slave device cannot cause a fire, and thus does not require a fire enclosure. Even if the slave device is very complex, the worst-case scenario is a fault that would cause the maximum fault current to flow for a long period, heating up the enclosure. You can predict the result by calculation and then prove the result through testing. Actually, the compliance criteria for the fault test is that it does not ignite the cheesecloth or tissue; but it’s good practice to monitor the maximum temperature that could be transmitted to the enclosure during the test. If it’s too late in the game to put in a PTC or change the plastic, you could still use Method 2; the current limit would be set by the current rating of the trace on the PWB – it will burn open if the current is too high. Set up a fault condition that allows the max current to flow that the trace will handle, run the fault test for an extended period to evaluate the effect, then increase the load to burn open the trace, demonstrating that at the maximum fault current that the device can handle, it cannot cause ignition, and that above that fault current, the trace opens without causing a hazard. Be aware that there is a US national deviation in cl. 5.3.8.1 which states that if a secondary circuit PWB trace is designed to intentionally open in a repeatable manner, the test must be repeated three times to insure that the trace does in fact open repeatedly. This could jam you up if you did not intentionally design the trace to open repeatably – it may open each time in a different place, giving inconclusive results. But most likely, it will open in the same place every time. And, it’s generally easier, faster, and cheaper to do a board spin than to change the plastic (unless you already have a ga-zillion boards in stock). The main problem with relying on a trace to open is that it will matter where you place the fault – so unless your design is to intentionally use a section of PWB trace as a current limiter, I probably wouldn’t be very comfortable applying this method, unless you could show that the trace will open in the same place every time, no matter where the fault is placed in the circuit. That could get a little difficult. I’d run any scenario like this by the certifying agency first, to make sure they agree with the reasoning. Applying Method 2 requires a little thinking ‘outside the box’, so to speak, and is usually not applied to any circuit with more than a handful of components, since applying every conceivable fault to a complex circuit could get very time consuming. And agencies tend get in the habit of always applying Method 1. But if you can present a reasonable fault scenario to the agency that addresses the hazard of a maximum fault current flowing for an extended period, I think most would accept the rationale. For the record, this safety lab does not consider a USB port to be LPS without evaluating the schematic and performing the LPS test. Why would any agency make such an assumption, when it can be verified as LPS (or not) in a matter of minutes? And to echo Richard’s comments, the ultimate goal is not to obtain an agency mark or meet the standard, but rather, to place a safe product on the market. I guess there should be some disclaimer here about the value of free advice, etc, etc – don’t hold me liable if I’m wrong! Good luck- Doug Massey, NCE Manager, Product Safety Engineering Advanced Compliance Solutions, Inc. Ph. (770) 831-8048 FAX (770) 831-8598 ****************CONFIDENTIAL**************** This e-mail and any attachments may contain information which is confidential, proprietary, privileged or otherwise protected by law. The information is solely intended for the named addressee (or a person responsible for delivering it to the addressee). If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete it from your computer. _____ From: [email protected] [mailto:[email protected]] Sent: Friday, December 17, 2004 3:59 PM To: [email protected]; [email protected]; [email protected] Subject: Re: USB interface Limited Power source ? Kris, >From your reply below it sounds as though the answer to your question may not be found by considering only the requirements of standards, but also the requirements of legislation: for Europe the General Product Safety Directive and the Product Liability Directive. Let us say that you are responsible for designing a USB 'current sink' device and you have concluded that all USB current sources are LPS per IEC/EN 60950-1 and therefore you decide not to provide a fire enclosure. Now let us say that you sell your product in the EU (or the USA) where there are laws of 'strict liability' where it not necessary to prove that any injury resulted from product failing to comply with a particular standard, only that that an injury was caused and that, beyond reasonable doubt, the cause of the injury was your product. So, one day, one of your customers connects your product to a USB source and leaves it powered overnight and during that time there is a fault which causes a fire. Your defence is "not my fault, the source wasn't current limited as I expected". If you think that the probability of the above scenario is very small and so the cost of providing a fire enclosure is greater than any potential legal fees and loss of good name then you have one solution, if not you have another. Compliance with standards is just one tool, there are other considerations that should be taken into account. Regards, Richard Hughes In a message dated 12/17/2004 17:25:58 GMT Standard Time, [email protected] writes: Hi Dough, Thanks for you clear explanation. The problem I have is not really with the USB host device, but with the devices connected to it. If I can assume that the power on a USB interface can be considered as LPS, then the slave device - that can be connected to any PC host - doesn't need a fire enclosure. Some safety labs accept a USB to be LPS, some don't. You say - correct me if my interpretation is wrong - that the power on the USB bus is LPS unless some designer made a mistake in a host equipment by not adding protection elements. But than, this device does not comply with the USB spec and isn't a USB host device at all. Regards, Kris ---------------------------------------------------------------- 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 [email protected] Instructions: http://listserv.ieee.org/listserv/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] For policy questions, send mail to: Richard Nute: [email protected] Jim Bacher: [email protected] All emc-pstc postings are archived and searchable on the web at: http://www.ieeecommunities.org/emc-pstc
