Design flaw? Polyfuses for USB current limiting

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 ... And one other point - using a 1.1A fuse means only one fuse value needs changing, so a little easier for purchasing.

Though the schematic indicates F3 as 1.1A it seems 750mA has been fitted to actual boards. I am not sure which thread that was mentioned in. From an earlier post in this thread it seemed the measured resistance of what is fitted was reasonably low so not problematic in itself.

The problem with increasing F1 and F2 to a high value is that the main inlet fuse, F3, will trip well before the USB protection fuses, so may as well not bother fitting them in the first place.

There's only 300mA nominally spare for both USB ports combined so it's understandable why the ports are specified for 100mA only, why 140mA fuses were fitted. The problem is ( if being specified as 100mA only is acceptable ) simply that their resistance is too high for some USB devices.

IMO the logical solution is to stick with 140mA ( or similar ) but use low resistance fuses. Anything else has knock-on consequences, having to increase inlet fuse F3 rating or risk that tripping and complete R-Pi shutdown, and increasing F3 in turn risks blowing PSU's or having them cut out.

The other solution is to make F1 and F2 500mA and route those directly to the power inlet rather than through F3 but that then necessitates a 1.7A supply as well as PCB redesign.

Having had the voltage drop blamed on the cheap USB cable before the finger of blame started pointing towards other sources of high resistance, and since I needed to dismember a cheap USB cable for another project, I thought I'd measure the resistance of an 80p no-name Amazon USB 2.0 cable and see what pitiful conductors lurked within.

The power leads were 7 strand 0.1mm each, and the red and black measured identically on a 1.5 metre length at 0.5 Ohms, rather less than the 7.5 Ohms I measured my F1 polyfuse . .

Here's the cheapo cable

The problem with increasing F1 and F2 to a high value is that the main inlet fuse, F3, will trip well before the USB protection fuses, so may as well not bother fitting them in the first place. [....] IMO the logical solution is to stick with 140mA ( or similar ) but use low resistance fuses.

Unfortunately, there are no such "low resistance fuses" with 140 mA rating. You would have to use a more expensive, active current-sense current limiter chip, presumably not done on the R-Pi due to cost. Note, the microUSB connector itself should be limited to 1.8 A total through the power pins which is just about the same as two 500 mA USB ports plus the R-Pi itself at full tilt. So if you wanted to tap off the USB port power separately before the R-Pi fuse, you could in theory have two full 500 mA USB ports (assuming your power source can do it), but you'd have to cut off the current just above that point to protect the connector. Again, it would probably need an active current-limit chip.

Example of a good-quality microUSB connector: 0.03 ohms, 1.8 A through pins 1,5 if pins 2,3,4 unused: http://www.hirose.co.jp/cataloge_hp/e24200011.pdf

Though the schematic indicates F3 as 1.1A it seems 750mA has been fitted to actual boards....

....IMO the logical solution is to stick with 140mA ( or similar ) but use low resistance fuses. Anything else has knock-on consequences, having to increase inlet fuse F3 rating or risk that tripping and complete R-Pi shutdown, and increasing F3 in turn risks blowing PSU's or having them cut out.

The other solution is to make F1 and F2 500mA and route those directly to the power inlet rather than through F3 but that then necessitates a 1.7A supply as well as PCB redesign.

That's why F3 is marked 07 what a pain. Why on earth have they changed it.

There are no low resistance poly fuses with 140mA current limit as far as I know. Well I haven't ever found any looking at the various fuse manufacturers web sites.

A PSU with over-current trip is a good idea then I could throw away F3. :)

Anyway for the USB an alternative would be to use a semiconductor current limiter something like theTI TPS2042BDRBR. http://www.ti.com/product/tps2042b. I haven't looked to see if there are any suitable for 100mA current USB. This one device would replace the 2 fuses F1 and F2 and the two diodes D10 and D11 and would require a PCB modification. There would be a price difference as well. The TI part is about $0.70 each for 1000, this would replace 2000 fuses and diodes costing about $0.50 for a pair of fuses and a pair of diodes. Prices are basic distributor prices. What they would cost Farnell/RS I've no idea, probably a lot less, especially in the quantities they must be buying them at the moment.

Changing the PCB layout is no option at the moment and probably for a conciderable time to come so some sort of fix needs to be figured out using what we have.

Right, now where did I put my soldering iron? :D

I'm not too keen on F1 and F2 tapping off the board's +5V rail, which itself taps off the charger input via F3.

It would look more logical to me if F1 and F2 were to tap directly off the charger input and had the purpose of protecting the charger and the two USBs from external shorts, while F3 were to tap directly off the charger input (as now) but had the sole duty of protecting the charger and the on-board circuitry from internal on-board shorts and not concerned with the USBs. Ie. all 3 polyfuses would be better tapping off the charger input in parallel.

That would make all three polyfuses independent, and they could all be sized individually to reflect individual maximum consumptions and trip points.

As it stands currently, the interdependencies complicate matters a lot, and they pretty much force F3 to be too large to protect the board effectively while F1 and F2 are forced to be too small to give the USBs any useful amount of power even if the charger can supply it.

Not keen on the current approach.

Morgaine.

The current approach is a bloody mess, and results in a high percentage of

a - chargers not supplying enough juice
b - usb devices not working

All (reasonable) keyboards and mice should be expected to work, first time, off the internal USB ports. Failure to do this is a defect. A bug.

This is part of why the first 10k were intended to be developer boards - to knock out the remaining hardware and software bugs. IMO it's probably time to bring out a revised board, go back to switchmode for the regulators, and knock the stupid USB charger idea on the head. Before half a million buggy boards finish hitting the street.

Simon

Yep.

This is part of why the first 10k were intended to be developer boards - to knock out the remaining hardware and software bugs. IMO it's probably time to bring out a revised board, go back to switchmode for the regulators, and knock the stupid USB charger idea on the head. Before half a million buggy boards finish hitting the street.

Agreed. But if I had ownership of the issue, had to find a solution, I'd say there is no easy solution beyond documenting the (unintended pun) current characteristics of the board and potential issues with it.

It's plugging 100mA USB devices into a 100mA rated USB port and having those not work as they would be expected to which is the main problem. Issues with devices needing more than 100mA, above the port spec, can be documented and legitimately addressed with RTM.

If very low resistance 140mA fuses had been fitted the above would stand and IMO there'd be no issue. The intended idea was sound so it's not really a design flaw more an implementation error. It does however need to be addressed.

[mahjongg]

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.

I was just mentioning a real world example that explains why saying the R-PI "only supports 100mA devices" is nonsense, as the RPF itself recommends using it this way. Obviously I agree that drawing 500mA should not be a problem either, as I mention elsewhere.

[mahjongg]

IMO the logical solution is to stick with 140mA ( or similar ) but use low resistance fuses.

The point is that 140mA low resistance fuses do not exist, that is the whole point!
The only way to get low resistance fuses is to have a higher tripping point, and that is the way it should be!

[mahjongg]

The best solution is to use polyfuses for the USB port rated 1.5A, and use a say 2A polyfuse on the power input.

If a normal adapter cannot supply a 2A short circuit current then in fact that's a "luxury problem", as it means that the R-PI probably won't be damaged (the tracks won't be damaged, not the connectors, which normally can take 5A or so). Also, a reasonably good power supply should be short circuit protected.

A longer term solution is to trace power for the USB polyfuses directly from the input connector bypassing the input fuse, which means that: a) no double drop from two fuses in series, and b) all fuses are independent, and can be rated as low as possible.

As has been stated before, electronic solutions are too expensive for a extreme low cost device such as the R-pi.

How about we just update the documentation to what reality currently is, forget what user expectations may be, how anyone thinks USB power management should or does work. The 100mA and 140mA values may need tweaking ...

"Each of the two USB ports are rated for 100mA. Most 100mA rated USB devices should work directly from a port but some may not; these will need to be used with a powered hub.

USB devices which draw over 100mA should be used with a powered hub.

USB devices which draw 140mA or more must always be used with a powered hub.

Some devices drawing over 100mA but less than 140mA may work directly from a port but some may not or may operate intermittently or unreliably and these will need to be used with a powered hub."

[mahjongg]

Hippy: too late, the RPF already has stated that using a keyboard with built in hub, which is used to connect a mouse to such a keyboard is a proposed solution. Such a solution would certainly draw more than 100mA.
But more importantly, even at 100mA the 5% tolerance is severely deteriorated, to the point of sometimes failing, even with just 100mA devices.

Hippy: too late, the RPF already has stated ...

There's no reason the RPF cannot review what they have stated and change and update it as appropriate.

There's no shame in changing position in the light of further information, and IMO it's ridiculous to say something must stand because someone said it will when it doesn't! Embarrassing maybe having to but that doesn't prevent a change of position.

They said it would run Ubuntu, would ship with Fedora. That turned out to wrong too but everyone just shrugged and moved on.

The RPF my have handed out some rope by which we could hang them but I don't think that's what's needed. We need something more constructive and useful.

But more importantly, even at 100mA the 5% tolerance is severely deteriorated, to the point of sometimes failing, even with just 100mA devices.

Agreed. Hence why it needs to be documented. None of this "wouldn't it be better if..." is going to help people who currently have a problem and nothing is going to change until a future time.

@hippy: "shame" doesn't come into it, nor blame nor any other such red herring. They're all completely off topic. This is simply a technical issue, and it must be corrected before it affects hundreds of thousands of users, Currently there are only 10k or so boards in the wild, so the problem is manageable. Now is the time for changes, not later.

And I have no doubt that they're looking at it as we speak. Good engineers recognize a problem when it's pointed out.

This is part of why the first 10k were intended to be developer boards - to knock out the remaining hardware and software bugs. IMO it's probably time to bring out a revised board, go back to switchmode for the regulators, and knock the stupid USB charger idea on the head. Before half a million buggy boards finish hitting the street.

Agreed. But if I had ownership of the issue, had to find a solution, I'd say there is no easy solution beyond documenting the (unintended pun) current characteristics of the board and potential issues with it.

It doesn't matter if the solution is easy or not. The problem exists, and it's going to be a killer for getting devices into schools, even if the wailing of hundreds of thousands of new, and now disappointed, owners doesn't do that first.

The idea behind the USB PSU was that pretty much everyone has one, those that don't can easily and cheaply get one, and that they can be relied on to provide enough juice for the Pi. The problem with that is that a large proportion of USB chargers (even OEM ones shipped with curent-model, although "basic", smartphones, if my quick check at the phone shop is anything to go by) do not put out enough juice for the Pi; of those that do, it appears to be a lottery as to whether they push out enough, and well enough regulated, juice for Pi + a couple of low-power USB devices. FWIW, in my quick straw poll at the phone shop, before the bloke got bored of showing me chargers, out of 12 OEM and 3 aftermarket chargers, I only found 3 OEM chargers that were labelled as putting out more than 500mA and only one aftermarket one.

What this means for schools is that they will have to shell out for name brand (or at least have to pay name brand prices) for PSUs. This was probably the case anyway, except that, instead of getting cheap, "throwaway" units, they are going to have to spend potentially more than the Pi itself on a PSU (which, of course, will charge little Johnny's smartphone faster than the one he has at home, and may well "grow legs")

USB devices are also a problem. I don't personally have a single USB keyboard that I have any confidence will work with a Pi (when I eventually get one). Every USB keyboard I have has a built-in hub. Hell, every mouse I have asks for 100mA (with the possible exception of the old logitech ball mouse that got retired because its rollers were jammed). It doesn't matter for me, because I don't anticipate using any USB devices on the Pi for a very long time.

What this means for schools is that they may well have to shell out either for new keyboards (and maybe mice), or for powered USB hubs (which don't appear to be the universal panacea to USB issues we were led to believe either). But they won't know for sure until after they have purchased X Pis and found that their existing kit doesn't work with it. Noice. This also means that the idea of sending little Johnny and Janet home with a Pi in their respective pockets is pretty much out of the question, unless you also hand them a "guaranteed in spec" charger, keyboard and mouse (or hub), because you can't guarantee that, even if they have something that nominally "should work" at home, it's actually in spec.

USB devices as simple as keyboards and mice should "just work" when plugged directly into the Pi. As it stands, it appears that the Pi is very broken for a significant number of people. And the longer we wait, the more significant that number of people is going to be.

"Raspberry Pi : An ARM GNU/Linux box for $25. If you're lucky, it might even work!" isn't much of a slogan

Simon

This is simply a technical issue, and it must be corrected before it affects hundreds of thousands of users ...

That is the question; does it have to be corrected, and when, or does the existing issue simply need to be clarified and documented ?

I can see that the issue will be a hot one and I would categorise it as just another balls-up in a long string of them but I don't see it as such a show-stopper as others do or perhaps want to make it be.

It would have been nice to be able to draw 500mA out of each USB port but the design decisions have precluded that. That lower, nominally 100mA rating, is acceptable in the circumstances, just needs to be made clear.

Yes, the fuse resistance is an issue and a problem for some 100mA rated devices which won't work but again I'd say that is acceptable if documented and made clear. Unfortunate but that's life.

It is a technical issue, just like some SD Cards not working, some PSU's not working, all the other issues which have been noted. In a perfect world it would be desirable to stop production, redesign and resolve everything, proceed then with a Mk II version but reality is never so simple, compromises have to be made. What is the greater good; stopping production until a full resolution is found or continuing with what there is, even if not perfect nor ideal ?

I don't think the USB power issue is any more of a problem than the SD Card and PSU issues; you have to have the right type or it won't work, acceptable as long as clearly documented and defined. If I had to make the decision I'd take that; document, apologise, continue production as is and look to find a full resolution for the future, accepting there may not be a suitable resolution to be had which meets all criteria.

The issue may be moot anyway because it's no longer necessarily a foundation issue but an RS and Farnell one. They are the ones building 75K batches now or shortly with more to follow. They'll likely decide what's acceptable to build so the discussion should really involve or be with them. Idealism don't always fit with commercial realities.

The problem exists, and it's going to be a killer for getting devices into schools, even if the wailing of hundreds of thousands of new, and now disappointed, owners doesn't do that first.

The $64,000 question - Is the R-Pi, as is, fundamentally flawed, so much that it's whole purpose and future is undermined ?

Flawed, yes, fatally, I don't think so. For schools, I would lean more towards yes and accept the nuisance factor becomes more problematic.

Perhaps one has to now view the R-Pi in two streams; developers plus application platform users and schools; it's (IMO) acceptable for the first but not for the later. It can (IMO) continue as is for developers but does need resolving before a school launch. Of course there's no obvious differentiation of which R-Pi is for which stream so that does compound the problems; it could be said that if the school stream is fatally flawed then both are.

I expect there are going to be some intense discussions around the RPF HQ table.

[mahjongg]

IMHO its not "fatally flawed", it is manageable as is, but it must be recognized as a problem, and immediate action must be taken so that future production switches to more appropriate polyfuses as soon as possible.
Here in the forums all the problems that are symptomatic of this problems must be taken up, and be told what to do to mitigate the problem.

I have one probably important observation to make, and that is that if the user has used a device, (lets say a keyboard with lighted keys, or a built in hub) that has drawn considerable more current than a minimum model and it misbehaves due to this problem, then its possibly not a good idea to take a lower powered alternative and to try it again immediately!
The polyfuse, when it has been exposed to currents near its tripping point will slowly increase its resistance, when you remove the current it will not immediately decrease its resistance to a normal value, but instead this can take hours, even days.

So the advice when using, for example, a malfunctioning keyboard, is to remove it then wait at least a couple of hours, and only then connect a more reasonably powered keyboard.
Otherwise the impression that the user might get, when even this lower powered keyboard also misbehaves, is that changing the keyboard has not helped. Although it probably would have worked fine if only he had waited for the polyfuse to "reset".


I agree that the RPF could mitigate the problem by more strictly requiring/strongly-recommending the use of only low power USB devices, and it might be a good idea to remove the FAQ recommending the use of a keyboard with a built in USB hub.

Just like always, the best policy will be openness.

Tips when having USB problems should be:

*Only use low power devices
*when seeing a problem, consider that the device is too high powered, and change it for another, after waiting several hours with the R-PI turned off.
*If you want to use higher powered devices, use a powered hub, one that doesn't have the "feed current back" problem (or the user could cut the +5V line of the cable between the PI and the HUB, only that isn't a job for beginners).
*If seeing continuous USB problems consider using a better PSU (if the PSU outputs 4.8 Volt to begin with you have no margin left).
*When in doubt whether the problem is caused by the polyfuse, wait several hours before trying again.

Such tips should be given every time a problem could be caused by this issue.

But most important perhaps, take immediate action so that the problem is resolved for future devices, at the very least before the "educational release".

[mahjongg]

Having had the voltage drop blamed on the cheap USB cable before the finger of blame started pointing towards other sources of high resistance, and since I needed to dismember a cheap USB cable for another project, I thought I'd measure the resistance of an 80p no-name Amazon USB 2.0 cable and see what pitiful conductors lurked within.

The power leads were 7 strand 0.1mm each, and the red and black measured identically on a 1.5 metre length at 0.5 Ohms, rather less than the 7.5 Ohms I measured my F1 polyfuse . .

Think of the problem in terms of a "power chain", every link in the chain weakens the chain until it breaks.
If the PSU outputs less than 5.00V to begin with its a problem, if the cable used causes a voltage drop the problem gets worse, if the input fuse has heated up for whatever reason and has an increased resistance, then the problem gets even worse, and lastly when the USB polyfuse also has an abnormal resistance because the USB device draws a certain amount of current, all the problems (voltage drops) adding up will cause the USB device to fail.

The white paper I referenced earlier gives a calculating example, and explains all the possible factors in a typical "USB power chain".

Hi I'm watching this topic with interest. I was looking at the polyfuses last week and thought there was some interesting stuff going on... What value is F3 by the way, has anyone confirmed it is 750mA instead of the 1.1A in the schematic, I also wondered why it was marked 07.

You guys are totally right, good instructions will vastly help with this issue (it may not solve it but it'll make a huge difference). To this end, please continue to refine the advice regarding this, as this is something which I feel may be worth explaining in the MagPi.

Interesting point about some hubs feeding power back into the Rpi through the USB ports, I had noticed that it wasn't fully powering off with the hub connected.

*If you want to use higher powered devices, use a powered hub, one that doesn't have the "feed current back" problem (or the user could cut the +5V line of the cable between the PI and the HUB, only that isn't a job for beginners).

Even for the cheep hubs, the "feed current back" problem, can be ignored if the Pi is being powered off of the same powered hub. This saves the effort of making a custom cable. It also makes it so the whole system, Pi + peripherals, can be turned on and off at one point. That one point being the power supply for the hub.

Has anyone found an inexpensive source for reasonable quality short USB cables? Somewhere between 10 and 30cm (4 to 12 inches) would be ideal.

In addition to the important discussion about what can be done to improve this situation at production time, it would be useful if those of you who already have their Pi and have examined the polyfuses closely can tell the rest of us whether there are problems on the horizon for those who have no difficulty working with SMD components and would like to replace the polyfuses on their own board.

Is there good access to them, and no other barriers to reworking?

Morgaine.

Just looked up the specs on my imx53 and it says the USB ports get their 5V from the plugpack via a FET and a 1.1A polyfuse. The PMIC can detect an overvoltage and do something if you use the wrong plug pack but there is no current limiting to the USB apart from the polyfuse. I can't find anything on beagleboards or pandaboards. It would be interesting to see how other small systems handle the same issue.

BTW the imx shipped with a plugpack and sd card which might not be a bad way to buy a Pi for most people.

In addition to the important discussion about what can be done to improve this situation at production time, it would be useful if those of you who already have their Pi and have examined the polyfuses closely can tell the rest of us whether there are problems on the horizon for those who have no difficulty working with SMD components and would like to replace the polyfuses on their own board.

Is there good access to them, and no other barriers to reworking?

Morgaine.

They probably won't be too bad if you needed to replace them (they aren't too small and clear of other components). Only the USB ones are a touch close to the USB connector (F2 in particular), but if you get a good angle it should be ok (aside from the usual dangers of damaging the board etc etc).
I'm not planning on changing anything on the board.

At the moment, I've created a hub with an additional USB power line to power it (from a solid PSU), and an extra power only micro-usb lead to power the Rpi (I may add a switch to this). I've then cut the +5V line on the Hub's normal USB connection cable. Seems to work at the moment.