Incompatible Self-Powered Hub

I'm not sure it's the RPi design that's wrong, more that USB hubs are not always very careful about where their power goes. For instance... I have a Logik LP4HUB10. But, it sends power through the hub-Pi cable (just like Morgaine's problem) and I had to follow instructions http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=8926 here that meant taking apart the hub, snipping a wire and putting it back together again.

I guess the only thing the Pi could do is to prevent incoming power into the two USB ports... But then again why should it - power going through the wrong wire in a hub is a power drain, surely?

I'm not sure it's the RPi design that's wrong, more that USB hubs are not always very careful about where their power goes. For instance... I have a Logik LP4HUB10. But, it sends power through the hub-Pi cable (just like Morgaine's problem) and I had to follow instructions http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=8926 here that meant taking apart the hub, snipping a wire and putting it back together again.

I guess the only thing the Pi could do is to prevent incoming power into the two USB ports... But then again why should it - power going through the wrong wire in a hub is a power drain, surely?

Michael Horne wrote:

 

I'm not sure it's the RPi design that's wrong, more that USB hubs are not always very careful about where their power goes. For instance... I have a Logik LP4HUB10. But, it sends power through the hub-Pi cable (just like Morgaine's problem) and I had to follow instructions http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=8926 here that meant taking apart the hub, snipping a wire and putting it back together again.

I guess the only thing the Pi could do is to prevent incoming power into the two USB ports... But then again why should it - power going through the wrong wire in a hub is a power drain, surely?

RasPi shouldn't have to do anything.  A well-designed powered hub should not be sending 5V current upstream.  My cheap Inland 4-port hub has a Schottky diode to make sure this doesn't happen.  A better solution is to use a hot swap controller to reduce voltage drop, but that adds cost.  Hubs should not directly connect 5V external power to the upstream line, but obviously some do.

Michael, the Pi's power design is wrong in various areas, but in this thread I'm referring only to the Pi's USB host end by the type A sockets, ie. not to the micro-USB end.  Other problem areas are for other threads.

The Pi's power design is very badly wrong at the USB host end because even if a downstream hub were supplying more than 500mA per port (which the USB spec does not require it to do), and even if a self-powered hub's type B port were supplying that current upstream through the type-B to type-A lead (which it is not required to do), and even if that upstream current were sufficient to power the Pi (which it is certainly not required to do), then even under the combination of all these auspicious circumstances the Pi will still not boot properly when powered through this B-A upstream path because the F1/F2 polyfuses have far too high a resistance to keep the upstream voltage above 4.75V as per the USB spec.

This end of the power design is wrong whichever way you look at it.  The voltage drop across an F1/F2 polyfuse (eg. 4 ohms on my Pi) at the Pi's nominal 700mA is around V=IR = (0.7 * 4) = 2.8V, so even a perfect infinite-current supply at the upper end of the USB voltage spec (5.25V) would provide the SoC with (5.25 - 2.8) = 2.45V through the polyfuse, which cannot possibly work.

There is simply no in-spec way for the Pi to be powered from a downstream self-powered hub via that A-B path, and therefore the Pi design should prevent A-B power from being applied upstream.  And because the Pi power design doesn't block it, the Pi can go into rapid reboot cycles and damage HDMI equipment with perfectly in-spec hubs, as in this case.

Of course there are ways to hack hubs and cables to prevent the worst of this, but that's beside the point.  And applying power from the hub to the micro-USB charger socket is completely outside the topic of this thread.  That doesn't work either with this low-current unit, but it's not my topic here, and I can't criticize this cheap little hub for that --- it's not intended to be a Pi power supply.  It is however intended to be a working self-powered hub for USB devices downstream of the Pi, and in that it fails completely for reasons already described.

Morgaine.

John, I think what's most shocking is that I got my hub from PC World, of all places. You would've thought a high street chain like that would only sell things of the highest quality... Mind you, this is the company that popularised the Packard Bell make of PCs, so...

Morgaine, I wasn't attempting to hijack the thread, just seeking to contribute to the discussion... I may have made the wrong assumption. I'm assuming that NO device (Pi, PC whatever) is supposed to be powered through a type A socket that is specifically there to provide data inputs?

That's correct, but because self-powered hubs can usually also work in bus-powered mode and hence draw power from their host, it seems to be common for them to link their powered +5V directly upstream as well.  Unfortunately this is bad for the Pi because it starts her boot cycle, despite successful booting being 100% impossible because of the designed F1/F2 polyfuse values.

Of course it's nothing new that two devices are not compatible, especially when one of them has a pretty oddball power design.  In this situation though, a device that isn't compatible with the Pi's idiosyncracies should not be marketed as an official Pi accessory.

Morgaine Dinova wrote:

 

There is simply no in-spec way for the Pi to be powered from a downstream self-powered hub via that A-B path, and therefore the Pi design should prevent A-B power from being applied upstream.  And because the Pi power design doesn't block it, the Pi can go into rapid reboot cycles and damage HDMI equipment with perfectly in-spec hubs, as in this case.

Morgaine.

I stated upstream that a hub should not be sending current upstream.  Just to make sure, I took a quick look at the USB 2.0 Standard and found this:

Section 7.2.1:

 

No device shall supply (source) current on VBUS at its upstream facing port at any time. From VBUS on its upstream facing port, a device may only draw (sink) current.

 

If a USB hub is sending current upstream, it's not in compliance with the USB 2.0 standard.  IMO, it's not RasPi's responsibility to work around non-compliant hubs, but it may be in RasPi's interest to do so anyway since there seem to be a lot of non-compliant hubs out there.

In general, I find the USB 2.0 Spec to be quite readable.  An exception to this is the software sections, which help me appreciate why it's so difficult to write host controller software well.  The spec is available for free at http://www.usb.org/developers/docs/.

Is it possible to put something (i.e. simply solder) on the Pi so that it stops the upstream voltage? (Not from a it's-the-Pi's-problem point of view, more of a hobbyists question).

As for the USB spec... I choose not to read that. Please don't make me ;-)

Michael Horne wrote:

 

Is it possible to put something (i.e. simply solder) on the Pi so that it stops the upstream voltage? (Not from a it's-the-Pi's-problem point of view, more of a hobbyists question).

As for the USB spec... I choose not to read that. Please don't make me ;-)

According to my read of the schematics, all you need to do is remove F1 or F2, depending on which RasPi USB port you want to connect to the hub.  The LAN9512 can still detect whether +5V is present or not using D11 or D10.  I don't see any other connections to +5V0_USBA/B.

Aw c'mon, the USB spec is mostly quite readable, and has lots of pretty pictures.  But whatever you do, start with Chapter 4.  Chapters 1 - 3 can cure insomnia instantly.

If the USB spec says "No device shall supply (source) current on VBUS at its upstream facing port at any time" then I agree with John that no hub that does this is certifiably USB compliant.

Farnell are then in an even worse situation than I feared.  Not only should this hub be removed from the Farnell Pi accessory page since it is not Pi-compatible, but all alleged "USB" hubs that do likewise should either be removed from stock or no longer be described as "USB" hubs.  It's very common, so this would have a massive impact.

Of course, we know that the latter is not going to happen.  Pragmatically, one has to accept the situation as it is and work with it.

Engineers are typically very pragmatic.  The standard engineering mantra of "Be generous in what you accept but strict in what you send" is a very good mantra to apply in this area, and it should have been applied when the Pi was designed.  It wasn't, and so the Pi design has given Farnell and RS a big headache, rendered many a hub product on the market unusable with Pi, and endangered HDMI gear through the pathological rapid boot cycling.  Not good.

Pi design issues aside, I don't think it's good for Farnell to be listing a Pi non-compatible device as a Pi accessory.  At its exceedingly low price though, it's sure to be worth a simple hack to bring it into compliance.  Of course, official Pi accessories shouldn't need hacking to work.

Morgaine.

The Pi's power design is very badly wrong at the USB host end

I was curious about how the USB host end worked for a more normal x86 PC, so picked a random Asus board that happened to be lying around. You know what, it seems to use something very similar to the Pi. The polyfuses appear to be  1.6A (0.14ohm so unlikely to be 160mA) and there's a ferrite bead between the fuse and the usb connector. Difficult to tell if there's a diode to allow detecting a fault condition or not.

Of course the big difference is that the other side of the polyfuse is directly onto the main 5v rail - in this case something that can do 5v @ 25A. So even if we assume a 4 port powered hub has a 5v 2A supply it's rather unlikely to have any chance of powering something that can potentially draw 10x that current. 

Still, these non-compliant powered hubs can't be doing themselves any favours trying to dump whatever power they have available back into a load like that. The Pi has the disadvantage(!) of being such a low power device that this reverse power can cause the symptoms you describe.

Aye, the high resistance of the F1/F2 polyfuses causes a variety of problems, and this is just one.

As we've been saying for many months now, F1/F2 should be specc'd to trip at a far higher current than at present because low trip points entail high values of resistance which are a design error when present in a USB power line.  Using them as a 100-140mA USB current limit is a misapplication of the devices and a total disregard for voltage regulation.

Once the Pi is available ex-stock, I bet it'll be common to short out F1 and F2 and power the Pi from such badly behaving hubs through their upstream host A-B lead, thus eliminating one mains adapter from the system.