Design flaw? Polyfuses for USB current limiting

[mahjongg]

USB ports are "normally" powered up but limited to 100mA....

...The host then sets that port to 500mA and away we go.

Errr, no!
The typical USB power monitor (chip, as used in PC's and such) doesn't care about limiting any current at all, all it does is detecting a short circuit current, reporting the fault condition to the PC, and blocking further current from flowing until the PC signals the chip that it should end the current block (when the user has confirmed he has removed the conflicting device).

Nowhere in typical USB hardware is any attempt done to "measure" what the actual current consumption is of an USB device, so the device can report it is using a maximum of 100mA, but in fact "lie", and consume 200mA and the system will be oblivious to that fact.

Errr, no.
Read the USB specs and you will see that it calls for the current to be physically limited to 100mA
to minimize spikes and dips caused by decoupling capacitors which the USB spec also sets at a maximum
of 10uF unless in-rush current is otherwise limited on the peripheral.

Errr, no.
Read the USB specs and you will see that it calls for the current to be physically limited to 100mA
to minimize spikes and dips caused by decoupling capacitors which the USB spec also sets at a maximum
of 10uF unless in-rush current is otherwise limited on the peripheral.

A USB1.1 compliant device (peripheral) will limit its current draw to 100mA until it has negotiated with the host for more current. The host doesn't do the current limiting, it was up to the device.

This might still be in the USB2.0 spec. I haven't looked. However, in the real world, there are a gazillion devices that ignore this. There are a wee tiny minority of chargers that do this, but most of them just draw 500mA right off the bat. The fancier chargers use yet some other protocol or signalling mechanism to see if they can draw 1 amp or 2 amps.

Lots and lots of stuff just draws whatever it draws. Almost nothing does anything useful with coordinating power usage in 100mA units. I wonder if that stuff is still in the latest version of the USB spec, and if it is there, whether it is still recommended behavior.

The Pi has the sense lines hooked up, so it can detect when the output voltage is too low, but I don't know if the USB driver uses them. [I won't have a Pi of my own for a few more weeks.]

@hamjudo
I can well believe that many cheaper peripherals simply ignore the USB specs.
If like you say the Pi does have the sense line/s connected then I wonder if it/they are actually being
read and what use reading them would actually do if they are connected to USB power before the polyfuse in which case it would never see a fault condition as the polyfuses would simply limit the current.
If on the other hand the sense line/s are after the polyfuses, then since the Pi has no way to switch the USB
power (so I have read, could be wrong) again it would serve no purpose.

Getting back to something useful...

If your USB device doesn't work, use a powered hub.

Some folks have measured the cold resistance of the polyfuses on the host ports on their Pis. The highest reported in this thread so far was measured at 7.5 ohms. Assuming a barely in spec USB power supply providing 4.75volts to the Pi, this would drop another 0.75 volts to a 100mA load, which would leave only 4 volts. Some 100mA USB devices won't work at only 4 volts.

Most wifi dongles and webcams draw more power than 100mA, so they will always need a powered hub. So that part works as designed.

The Foundation should be proud of their hardware, as this seems to be the worst problem in the design of their very first version. Powered hubs are inexpensive, and require no soldering to hook up. So the fix is cheap, and easy. All hail the designers!!!

[....] All hail the designers!!!

Each to their own I guess.

@hamjudo
I can well believe that many cheaper peripherals simply ignore the USB specs.
If like you say the Pi does have the sense line/s connected then I wonder if it/they are actually being
read and what use reading them would actually do if they are connected to USB power before the polyfuse in which case it would never see a fault condition as the polyfuses would simply limit the current.
If on the other hand the sense line/s are after the polyfuses, then since the Pi has no way to switch the USB
power (so I have read, could be wrong) again it would serve no purpose.

If the polyfuse has tripped, it has already cut off the current. The advantage of detecting the over current situation, is that the Pi can tell the user that nothing has been permanently damaged, they just need to find a powered USB hub before they will be able to get their widget to work.

I believe that communicating fault conditions from device drivers to the user in a timely and friendly way, is a challenge that is yet to be solved. We should be able to write something that does this. It is pretty much a two part problem.

Part one: Detection
Plug in something that draws too much current. Make sure the Pi's own voltage doesn't drop as a result. Assuming the Pi otherwise continues to function, see if the problem is reported. Look in /var/log, also scan /sys/bus/usb.

Part two: Notification (aka. the hard part)
Alerting users is hard, or ugly. You can have something which is continuously scanning for a fault condition, and then throw up a popup, or send email, or dozen other things. All of the notification techniques will miss some class of users, because not everyone uses the Pi the same way.

Fancier techniques can be done, that don't involve continuous scanning. That requires some notification framework, and a mechanism to register such fault events.

Leading to...

Part Zero: Documentation
Figure out the easiest way for a user to troubleshoot USB power problems, even when they don't have a powered hub. [If they do have a powered hub, try it through the hub, if it works, that was the problem.] I'm guessing for users that are comfortable with command lines, it would be something like, unplug the device, and grep the logs for a particular string. Not sure what the best approach would be for less experienced users.

@hamjudo

Some very valid points, however the easiest is just to use higher current polyfuses.
After all the cost and availability of powered USB hubs to many of us are trivial, this may
not always be the case in all parts of the world especially the impoverished 3rd world.

[mahjongg]

@hamjudo
I can well believe that many cheaper peripherals simply ignore the USB specs.

The point is that practically all USB hosts (read PC's and such) do this!
They are all simply using a "hot swap controller", which only senses overcurrents. Never seen a design that actually measured the current it outputted to the USB port.

Using such a device is also simply overkill for the R-PI, using polyfuses is the correct solution, but they should have chosen ones that have cold resistances of a tiny fraction of an ohm.

Getting back to something useful...

If your USB device doesn't work, use a powered hub.

Not true;) I usually have my keyboard and mouse in the powered hub and wifi adapter plugged directly into the Pi. And it all works beautifully.
Thought I'd see what happened if I plugged the wifi into the hub with keyboard and mouse. Booting produced some wierd output on the screen and when it finally booted NO wifi connection.
Removed the keyboard and plugged that directly into Pi, rebooted and all was fine again.
What about that then?
Have to say the same happened when I took the hub with wifi, keyboard and mouse and plugged it into my windows laptop. Removed the keyboard unplugged and plugged the hub back in and the wifi started working again.
For reference:
ID15d9:0a4c Trust International B.V. USB+PS/2 Optical Mouse
ID 04f3:0103 Elan Microelectronics Corp. (keyboard)
ID 050d:0224 Belkin Components F5U224 USB 2.0 4-Port Hub
ID 0bda:8176 Realtek Semiconductor Corp. RTL8188CUS 802.11n WLAN
The hub is rather old but I might just see if I can find a firmware update for it and see if I can fix it
.

A quote from the USB-2 spec section 7.2 Power Distribution

"All devices default to low-power. The transition to high-power is under software control. It is the responsibility of software to ensure adequate power is available before allowing devices to consume high-power"

Also all root port hubs (such as the Pi) when powered from an external power supply must be capable of supplying at least 500mA (5 unit loads, 5x100mA, in USB speak). Battery-powered systems may supply either 1 or 5 unit loads.

@hamjudo
I can well believe that many cheaper peripherals simply ignore the USB specs.

The point is that practically all USB hosts (read PC's and such) do this!
They are all simply using a "hot swap controller", which only senses overcurrents. Never seen a design that actually measured the current it outputted to the USB port.

I suspect you misunderstood what I wrote.
I didn't say that the USB spec calls for measuring the actual current drawn, I said it should "hard" limit the current
to either 100mA or 500mA, big difference.

Using such a device is also simply overkill for the R-PI, using polyfuses is the correct solution, but they should have chosen ones that have cold resistances of a tiny fraction of an ohm.

I'm 100% in agreement there.

I suspect you misunderstood what I wrote.
I didn't say that the USB spec calls for measuring the actual current drawn, I said it should "hard" limit the current
to either 100mA or 500mA, big difference.

But that's not what the spec says, nor is it common practice. The spec requires current limiting for safety set not higher than 5A 'and must be sufficiently above the maximum allowable port current such that transient currents (e.g., during power up or dynamic attach or reconfiguration) do not trip the over-current protector'.

There isn't any active current monitoring in typical USB applications. Power management is done simply by tracking power requests made by peripherals. If a port that can supply 500mA already has 400mA of load on it and a device requests 200mA, it will deny it and the device should not power up, and the user should be notified. As far as I can tell, this is what the spec requires, and it's what every host port I've ever encountered does in practice.

Most hardware does comply with the power negotiation protocol, though it is pretty common for devices to simply request 500mA even if they don't require that much power.

If the hardware bug isn't going to be fixed, then the USB host port should probably be configured so that it has a power budget of only 100mA, which should cause high power devices to fail to come up and the kernel to log an error.

But that's not what the spec says, nor is it common practice. The spec requires current limiting for safety set not higher than 5A 'and must be sufficiently above the maximum allowable port current such that transient currents (e.g., during power up or dynamic attach or reconfiguration) do not trip the over-current protector'.

I don't agree.
Look again at MrEngmans last post where he quotes an excerpt from the USB2.0 spec.

There isn't any active current monitoring in typical USB applications. Power management is done simply by tracking power requests made by peripherals.

Not true.
As one example I refer you to page 12 (description of PRTCTL2 pin) and also pages 17 -19 of the
LAN5912 datasheet (the USB control chip used in the Pi).
Available here: http://www.smsc.com/media/Downloads_Public/Data_Sheets/9512.pdf

If a port that can supply 500mA already has 400mA of load on it and a device requests 200mA, it will deny it and the device should not power up, and the user should be notified. As far as I can tell, this is what the spec requires, and it's what every host port I've ever encountered does in practice.

Exactly, and how do you think the port knows that it's already supplying 400mA and that allowing
another 200mA will be greater then the allowable 500mA (and not 5A as you say) ?

Most hardware does comply with the power negotiation protocol, though it is pretty common for devices to simply request 500mA even if they don't require that much power.

"Most" being relative.

If the hardware bug isn't going to be fixed, then the USB host port should probably be configured so that it has a power budget of only 100mA, which should cause high power devices to fail to come up and the kernel to log an error.

Getting an experienced user to make use of kernel logs is all fine and well, but what about the less
experienced/beginners?

Surely this whole "problem" can be avoided by simply using the correct polyfuses.
It's not as if they cost any more then the ones already being used.
Furthermore, how does one communicate to the less knowledgeable that the USB ports on the Pi
are OK as long as what you connect to them does not exceed 100mA.
Most users don't know the difference between a milliamp and a mega-amp, and why should they?

Bottom line whether we agree on the finer points of the USB spec or not, is that the power on the Pi boards as they stand is a problem.
First thing I'm going to do when I get my Pi is change the polyfuses to more sensible ones
and put this problem behind me once and for all.

[mahjongg]

How it supposed to work is this, initially a USB host is only supposed to be able to deliver the minimal 100mA, so that when any USB peripheral is plugged in it is supposed to need only that 100mA, (until after enumeration).
That is to ensure that initially any USB devise will work on any USB host device.
But some peripherals simple need more than 100mA. What happens is that the USB host polls the ("working, because it gets the minimal power") USB device, and ask it what it's power requirements are. the host then calculates if the USB device fits within its available power budget, then either it allows the device, or pops up a warning that the device is drawing more power than the total budget allows, and asks the user to remove the device. If the device is behind a powered hub, the OS "knows" this, and doesn't add the devices current need to the total.
That is -all- no currents are actually measured!.
The "plug and pray power controller" is just for short circuit (overcurrent) situations, it in no way has any part in the above scenario, and using a "chip device" is just for adding an extra layer of convenience. And a polyfuse is simply the cheap replacement for it, without that embellishment.

Also what some people simply seem to ignore is that just drawing 100mA is not a solution for a polyfuse that has a resistance of 5 or 6 ohm, it will -still- cause too much voltage drop!

what the RPF needs to do IMHO is just ensuring that the next batches of R-PI's have sensible polyfuses. If the power supply used can deliver an extra 250mA to the USB ports that shouldn't be a (hardware) problem.

I don't agree.
Look again at MrEngmans last post where he quotes an excerpt from the USB2.0 spec.

It's not about agreeing or not. Go read and understand the spec yourself. Devices, as in devices on the bus, are in low-power mode by default (that is they must draw under 100mA). Their elevation to 'high power' status is under software (ie. the host's) control. Basically they must get permission from the host to draw more than 100mA. There is nothing in that quote (nor the spec) about limiting them to what they request. The current limiting mentioned in the spec is for safety only.

Not true.
As one example I refer you to page 12 (description of PRTCTL2 pin) and also pages 17 -19 of the
LAN5912 datasheet (the USB control chip used in the Pi).
Available here: http://www.smsc.com/media/Downloads_Public/Data_Sheets/9512.pdf

Right, so where is the section on current limiting? It provides power control in the form of an output for a switch.

Exactly, and how do you think the port knows that it's already supplying 400mA and that allowing
another 200mA will be greater then the allowable 500mA (and not 5A as you say) ?

Because if you were paying attention, you would know that devices must request the amount of power they require. By summing these amounts for current bus powered devices, and adding the requested power, the host can determine if there is room in the power budget for the new device.

Getting an experienced user to make use of kernel logs is all fine and well, but what about the less
experienced/beginners?

Obviously it should have a UI, but I have no idea if one is actually implemented. This situation happens very rarely in practice because self-powered hubs are rarely used and the spec requires that each host port supply 500mA.

I definitely agree that the polyfuses selected are the source of the problem and should be corrected, you'll get no argument from me there.

[mahjongg]

By the way, the LAN9512 chip used as the internal USB hub for the model-B does seem to have the ability to "see" that the polyfuses have triggered, and that there is -no- voltage on an USB port, what they don't seem to have is the ability to detect a lower than normal output voltage.

All this to'ing and fro'ing about what the spec says is very interesting but it's in danger of losing sight of the main issue.

If we use polyfuses of such a high resistance as has been measured in the outgoing USB power rail, then Pi systems are going to suffer a lot of instability when powered from marginal cellphone chargers, and that surely is not what anybody wants, spec or no spec.

After all, the USB spec probably didn't foresee the extreme degree of crappiness of typical cellphone chargers, let alone recommend that such marginal (or way out of spec) chargers be used to supply constant inbound USB power in a system that is also supplying outbound USB power. I expect that the spec writers would be (are?) horrified by typical charger quality.

What's needed now is not more debate, but first confirming with Pete and/or Gert what values of pre-trip polyfuse resistance they designed to, and then determining whether the devices that people have actually measured have been out of spec or the wrong type or what. Whatever the answer to that, we have a potential problem of two different kinds, because it's either going to require sourcing polyfuses manufactured to tighter tolerances or else altering the design to use lower resistance ones.

It's not a good situation either way, but instability of Pi systems is absolutely not an option, IMO.

Morgaine.

We may disagree on some points but one thing is unequivocal, all fingers point to the polyfuses.

@Morgaine
I too would be interested in comments from Pete and/or Gert.

By the way, the LAN9512 chip used as the internal USB hub for the model-B does seem to have the ability to "see" that the polyfuses have triggered, and that there is -no- voltage on an USB port, what they don't seem to have is the ability to detect a lower than normal output voltage.

I don't believe there are any analog to digital converters on the Raspberry Pi. All of the thresholds are binary. In this case, as far as the chip can tell, the voltage is either below some value, or above that value. This leads to some frustration, as different USB devices stop working at different voltages. For any threshold, it will be "wrong" for most hardware.

Anything fancier would require significantly different hardware. At which point, you might as well ask for wheels and a sandwich dispenser.

We may disagree on some points but one thing is unequivocal, all fingers point to the polyfuses.

Here is how it is supposed to work(assuming a stable 700mA supply, with a good power cord):

1. If a user plugs in a USB device that uses less than 100mA, that device should work. If that device doesn't work because the voltage drop is too high, then, and only then, can we can blame the polyfuse.
2. If a user directly plugs in a USB device that draws more than 140mA, the polyfuse should trip. The Raspberry Pi should continue to function. The device should not function. This is not the polyfuse's fault.
3. If a user plugs in two devices that combined draw so much power that the Raspberry Pi itself stops functioning due to low voltage, without tripping the polyfuses, that would also be a problem.

If we simply swap polyfuses for larger current devices, then we trade problem 1. for problem 3.

Swapping polyfuses fixes problem 1. only if you can find an affordable polyfuse, that is available in quantity, with a similar trip point, but with a sufficiently low on resistance. There are additional logistics issues, if the polyfuse requires different pad placement.

Part and/or board changes take time. Certainly the first few hundred thousand boards will be cursed by the relatively high voltage drop polyfuses. The easy way to work around the problem, on those systems, is a good powered USB hub, with a good 2 amp or greater power supply.

Note that many devices just work on the current hardware. This is because a lot of low power USB devices are actually running at 3.3volts (or less) internally. They use a low dropout voltage regulator to provide their internal supply. Many low dropout regulators only need 3 tenths of a volt, so such a device would work fine on a 3.6volt supply.

[mahjongg]

You are making this more complicated than it is, (to the point of obfuscation) its not a question of that the polyfuse might be just tolerable OK when, when drawing 100mA, it doesn't cause enough drop to be bothersome, but when it happens to draw 50% more it does cause just enough voltage drop to cause devices to fail, that is no way to engineer such a solution. The 5% tolerance of 5V devices isn't something you can just ignore, or "tweak". If you remove any part of that 5% you are edging toward the point of failure.

its very simple.
The fuse is only a protection mechanism, it should be -completely- invisible, unless a real short happens!
In other words, the fuse isn't the device that should determine if drawing 100mA or 500mA is allowable!

Obviously therefore the LAn9512 chip doesn't have to have an A/D converter, it should only detect no voltage at the USB port, because the fuse has burned out!

The fuses should have no discernable resistance, not nearly one in the range that will cause any relevant voltage drop!

Also, if these fuses are bad, no power supply will fix that, you can use a 5A laboratory power supply giving out exactly 5.00 Volt, and the problem remains. A bad power supply will only eat away the 5% tolerance you have to begin with.

END OF STORY!

Getting back to looking at the fuses I've been taking a look at some docs from Littlefuse regarding PTC's and USB. Interesting reading.
http://www.littelfuse.com/data/en/Appli ... /ec616.pdf
http://www.littelfuse.com/data/en/Appli ... /ec606.pdf
http://www.littelfuse.com/data/en/Techn ... ations.pdf

And a data sheet for the fuses similar to those currently on the Pi.
http://www.littelfuse.com/products/Rese ... 1812L.html

The specs for the current fuses will be very similar, but the exact spec obviously depends on who makes them, and I don't have that info. Can anyone tell me who the manufacturer is?

I was a little surprised at first to see one of the most refered to fuses was 1.1A - same as the Pi's main power fuse F3. But reading the docs and reviewing the calculations it was obvious the major concern was the resistance of the fuse and voltage drop involved. Just the point we're concerned about. Using these would reduce the max resistance to about 0.2 ohms and subsequent voltage drop to 0.1v or less. A much more sensible value.

I've also had a quick look at a couple of other manufactures app notes and they have pretty much the same opinion regarding fuse values to use.

Just need to decide what to change the main power fuse value to to avoid the main power fuse triping before the USB fuse, probably 2.0A or 2.6A.

And one other point - using a 1.1A fuse means only one fuse value needs changing, so a little easier for purchasing.

[mahjongg]

That is what I have been telling all along, for a polyfuse to be useable for this job, it must be rated at several amperes!

What is the maximal internal resistance of the fuses that does not not cause a significant voltage drop? Where not significant means using just 1% or maybe maximal 2% of the 5% tolerance (remember, two fuses in series will use 4% of that tolerance, leaving only 1% for the PSU itself, and all other interconnections, like the cable resistance, the connector resistance, PCB tracks, ferrite beads, etc etc).

Well 2% of 5V is 0.1 Volt. So the fuse should never cause more than a 0.1 Volt drop.

Lets say (very conservatively) that this should be so when drawing 200mA. ( remember this is is what a simple keyboard with to USB ports for connection of a mouse uses, which is what the FAQ says is the ideal use of a R-PI USB port).

What is then the maximum allowable resistance? its R=U/I = 0.1/0.2 = 0.5 Ohm!
The lowest rated fuse with a guaranteed cold resistance (Rmax) below 0,5 Ohm is one that has a tripping current of 1.5 Amperes!

Lets say (very conservatively) that this should be so when drawing 200mA. ( remember this is is what a simple keyboard with to USB ports for connection of a mouse uses, which is what the FAQ says is the ideal use of a R-PI USB port).

What is then the maximum allowable resistance? its R=U/I = 0.1/0.2 = 0.5 Ohm!
The lowest rated fuse with a guaranteed cold resistance (Rmax) below 0,5 Ohm is one that has a tripping current of 1.5 Amperes!

Sorry but you either limit the port current to 100mA or allow the full load of 500mA so a fuse with 0.2 ohms max is needed. Otherwise you are going to end up with the same situation we have now. Not so often but anything drawing over 200mA will end up with the voltage out of spec with the possible risk of failing to operate properly at some point.

Remember

The fuse is only a protection mechanism, it should be -completely- invisible, unless a real short happens! In other words, the fuse isn't the device that should determine if drawing 100mA or 500mA is allowable!

I think the discussion is slowly heading towards a rough consensus that the polyfuses should be completely invisible except in the single situation of a complete short. Then they should trip, but even then only if the charger is sufficiently meaty to supply a large short current. We're talking amps now.

That seems to be the only approach that will give us polyfuses of sufficiently low resistance to not damage the charger's voltage regulation and to not exacerbate the poor electrical performance of a crappy charger even further and make Pi systems unstable when it can be avoided.

They should have absolutely nothing to do with metering out current usage down in the normal USB working area. If the charger can deliver 500mA per USB socket, great, the polyfuse should not interfere, its job is dealing with shorts only.

Morgaine.