Re: USB-OVP
Hi, why there is a requirement for VCHGR_UNDSHT 4V? If the voltage of charger fall below 4V when the charger is connected for 2 ms is this a big issue? Regards, Silvestro Joerg Reisenweber wrote: FYI: From http://www.usb.org/developers/devclass_docs/batt_charging_1_0.zip - Battery Charging Specification Revision 1.0 Mar 8, 2007 p.19: If the current drawn from a USB charger changes suddenly within the range of 0mA to 500mA, then the transient voltage from a USB charger shall not go below VCHGR_UNDSHT. Under no circumstances shall the transient voltage of a USB charger exceed VCHGR_OVRSHT. p.23: Charger Overshoot Voltage VCHGR_OVRSHT 6.0 V max. - Though we couldn't even attach a USB-charger compliant to this spec, as it has to be equipped with micro-USB plug, we should expect to see voltages on USB-receptacle of up to 6.0V AT LEAST. I think it's a strong argument for additional OVP extending our actual abs.max.rating of 5.5V to limits safely beyond 6.0V, like we are actually about to do for GTA03. cheers jOERG ___ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware -- View this message in context: http://n2.nabble.com/USB-OVP-tp790003p1394138.html Sent from the Openmoko Hardware mailing list archive at Nabble.com. ___ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
Re: USB-OVP
Am Fr 29. August 2008 schrieb Andy Green: Somebody in the thread at some point said: | Joerg Reisenweber wrote: | Do we really need more reasons to care about that issue? | | How about Postel's law ? | | http://en.wikipedia.org/wiki/Robustness_Principle | | Sounds like a good enough rule to follow at any interface, not just | software interfaces. ''Be conservative in what you do, be liberal in what you accept from others'' is a nice general principle. But then where does one stop, accepting mains power directly, automotive 12V, 12V charger connection, broken chargers... I gave some sort of spec in start of this thread, to give you an idea where *not* to stop, and this is 5.5V abs.max.rating of PMU. But seems you are considering to better not start at all on improving this situation, as *you* seem to fear *you* don't see a point to stop at. Whereas we started to think about it and when we see we landed at 25V OVP with our solution at (virtually) no additional costs, *we* all knew we did it and it's much better now. it is a guiding principle to be taken into account at specification time. Every new thing we accept to support has costs. False. Obviously, evidentally *not*, as you notice yourself in last line of your post. What I like though is the Be conservative in what you do part of it. Because we have not seen failures in the field from GTA02 arrangements, False. You don't stop to allege this, but actually there *are* some devices with obviously broken PMU... -- I am having a hard time accepting we need to change anything from proven GTA02 situation. ... so there is no such thing as a proven (good) GTA02 situation. Only proven thing is even USB charger specs allow for voltage transients we can not handle. If someone can actually show that GTA02 style arrangement leads to product failure in normal circumstances then it makes it clear we need to do better. But it seems thousands of users are proving it's robust enough already. False. And false. See above. The possibility to connect random power supplies to powered hubs is proof enough, it's self-evident. Why add reverse voltage protection when nobody seems to have reversed the voltage on their USB connector to date? False. I read a report of a user thanking the hw-EE for designing such a robust device, as he actually applied voltage reverse and device survived. Dunno why it did, you are free to ask Wolfgang for 100 devices to do a mass test and prove we don't need additional protection against that. But wait, I think 100 broken devices are more expensive than decent reverse protection for 250.000 to 500.000 devices, and even the time I spent for these messages is worth protection for another several 1000 probably. So why not just let's do it? Still one part of what Joerg has been talking about he characterized as different component selection so it was more robust, that sounds fine if it is not adding expense / size. Though you were bitching at it from very beginning, and it never would have happened if we listened to you. And, strange enough, all of your posts sound like you never had a chance to look at the GTA03 schematics and changes in there by yourself. :-/ Was the original USB-design yours, so you feel you have to fight for it with claws and teeth, despite it has ABS.MAX(!!!).ratings obviously much too close to normal operating conditions? That's clearly a faulty design, no EE would feel like good enough with it, absolutely no matter whether it already shows breakage in the field, or just is so close to the edge that it's easy to see it very likely will eventually. BTW: please do the exercise and apply all your basic objections raised in this case to your suggested uC. ;-) cheers jOERG signature.asc Description: This is a digitally signed message part. ___ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
Re: USB-OVP
Andy Green wrote: What I like though is the Be conservative in what you do part of it. Because we have not seen failures in the field from GTA02 arrangements, I am having a hard time accepting we need to change anything from proven GTA02 situation. If someone can actually show that GTA02 style arrangement leads to product failure in normal circumstances then it makes it clear we need to do better. But it seems thousands of users are proving it's robust enough already. Why add reverse voltage protection when nobody seems to have reversed the voltage on their USB connector to date? I have two GTA01's that are dead due to 12V being applied to the power supply of an upstream USB hub instead of 5V ... Of course, this was in a test rig scenario, with 5V and 12V both available on a serial-remote-controlled relay box powering the devices, so perhaps that doesn't count as normal circumstances (but then perhaps it is normal for a phone like this ...). -- Rod ___ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
Re: USB-OVP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | Andy Green wrote: | What I like though is the Be conservative in what you do part of it. | Because we have not seen failures in the field from GTA02 arrangements, | I am having a hard time accepting we need to change anything from proven | GTA02 situation. If someone can actually show that GTA02 style | arrangement leads to product failure in normal circumstances then it | makes it clear we need to do better. But it seems thousands of users | are proving it's robust enough already. Why add reverse voltage | protection when nobody seems to have reversed the voltage on their USB | connector to date? | | I have two GTA01's that are dead due to 12V being applied to the power | supply of an upstream USB hub instead of 5V ... | | Of course, this was in a test rig scenario, with 5V and 12V both | available on a serial-remote-controlled relay box powering the devices, | so perhaps that doesn't count as normal circumstances (but then | perhaps it is normal for a phone like this ...). Fair enough, I could tell you it won't survive 12V on USB port. Nor will any other USB device I heard of, I think it is OK. - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAki3+YQACgkQOjLpvpq7dMo7LQCfZ37RGbg34wZjs8SaTvP3w8LY HGkAoIqHXyrL50myBMXTe2a8yVqaQ2CB =G7nV -END PGP SIGNATURE- ___ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
Re: USB-OVP
On 8/29/08, Andy Green [EMAIL PROTECTED] wrote: Fair enough, I could tell you it won't survive 12V on USB port. Nor will any other USB device I heard of, I think it is OK. There are these nice little (Zehner) diodes that are designed to fail into a shorted mode. TransZorb, TranSil Gives protection against overvoltage and inverted supply. uwe ___ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
Re: USB-OVP
Joerg Reisenweber wrote: BTW: please do the exercise and apply all your basic objections raised in this case to your suggested uC. ;-) No, please don't ! We need that MPU !!! ;-) - Werner ___ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
Re: USB-OVP
Rod Whitby wrote: I have two GTA01's that are dead due to 12V being applied to the power supply of an upstream USB hub instead of 5V ... That's an interesting scenario because it shows the effect of abuse of an inherently less reliable interface being propagated to a supposedly more reliable interface. E.g., this discussion is about whether it's okay to feed USB's VBUS to an input that has an absolute maximum rating of 5.5V without any further protection. The USB 2.0 spec says that the maximum VBUS is 5.25V, so the question was how likely is it that someone is violating the spec ? My gut feeling would be about the same as hopping on the swivel chair in my office to change a light bulb. Probably nothing bad will happen, but it's not safe. (So yeah, I do it anyway.) Then Joerg found that the USB charger spec allows transients of up to 6V. I didn't expect that. So then the question became how serious are NXP about this 5.5V limit ? So that's more like running a red light with your car. Chances are that you still get away with it, particularly if you're careful, i.e., you watch for conflicting traffic, cameras, or the police, but you're probably aware that you're doing something very wrong. Now the hub scenario extends this: anything connecting to USB is almost certainly another USB device, so we can be reasonably confident that this device will make a honest effort of playing by the rules. However, whether the power supply that you plug into that barrel connector of your hub outputs the 5V the hub expects, 12V, -12V, or something meandering around the general vicinity of 5V, the plug will fit just as well. So now the safety of the Neo depends on either nothing ever going wrong at that fragile interface, or the hub's own protection circuits preventing further disaster. Now, if we're too cheap to care about adequate protection for our USD 399 device, how likely is it that the makers of as-cheap-as-possible no-name generic USB hubs aren't ? (And your example shows that the honest effort we assumed above doesn't seem to go that far.) So this is more like building your chalet in a known avalanche zone and counting on everybody else being prudent enough to not set off an avalanche. I can see a trend in the risks we discover in this process, and it seems that the initial gut feeling that this isn't right was quite correct. - Werner ___ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
Re: USB-OVP
On 8/29/08, Joerg Reisenweber [EMAIL PROTECTED] wrote: Nope, Tranzorb won't help here because the energy this component had to absorb is too high, so it would burn out. Transzorbs are for ESD surge suppression only. Yes, but the trick is that they burn to a short circuit. You still need a fuse element in front that burns garanteed open ( fuse, resistor ) Design target is to aim for a reasonable repair and avoid a fullbrick. However meanwhile main rant here seems to be about additional cost for a ~$0.05 diode to clamp reverse voltage and trip the polyfuse we have in new GTA03 design. Obviously there is a notion customer wouldn't like to pay this price for increased ruggedness of USB-power input. Also there have been objections about the safety of such a design, not taking in account that it can not be less safe than what we had originally. same applies here if you use the unsymmetric variety. Overvoltage and reverse voltage draw current through the TransZorp long enough to have the fuse blow. Save! A freerunner is more of a cherished posession than forex a Motorola F3 ;-) uwe ___ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
Re: USB-OVP
Am Do 28. August 2008 schrieb Andy Green: Somebody in the thread at some point said: | Charger Overshoot Voltage VCHGR_OVRSHT 6.0 V max. | - | | Though we couldn't even attach a USB-charger compliant to this spec, as it has | to be equipped with micro-USB plug, we should expect to see voltages on | USB-receptacle of up to 6.0V AT LEAST. Why? Our charger doesn't follow that spec that mentions 6.0V. | I think it's a strong argument for additional OVP extending our actual | abs.max.rating of 5.5V to limits safely beyond 6.0V, like we are actually | about to do for GTA03. Regulator and cap in the charger should mitigate this. Why don't we measure our actual charger performance in this case, shouldn't be too hard. For one simple reason: USB-charging was meant to work with *any* USB-charger (otherwise we would have used ID-pin for VDD of charger ;-) and Neo wouldn't take any power from USB-VBUS, thus no issue with OVP), and for sure we don't want to restrict customers to usage of OM-wallwart-powersupply only. We wouldn't even get away with this, legally. As long as our device has a USB-receptacle, it has to cope with insertion of what a customer can reasonably assume should work when attached to it. Then we also got the *wide* field of externally powered hubs. Ever had a look at the way those are providing power to downstream-connectors? And at the power-supplies that are (or are not!) shipped with these hubs. Dear customer! There are a plethora of powered USB-hubs out there. We strongly recommend NOT to attach Neo to any of those, as we didn't care to protect the device against voltages that may be found on a lot of the cheaper ones you might incidentally use. Please connect Neo to the original charger or certified good hosts only! :-( Do we really need more reasons to care about that issue? cheers jOERG signature.asc Description: This is a digitally signed message part. ___ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
