[time-nuts] USB problems and solutions - Some what Off Topic --> USB-C

Tue Jun 2 22:07:52 UTC 2015

Hi

The point that was made by the OP was that the new USB-C spec starts out with a “3A default” rather than
500 ma. Since this stuff is just hitting the market, only time will tell how the vendors decide to handle that 
“requirement” with multi port gizmos. 

With (now apparently obsolete) USB-3.0, hubs in the 8 and up range are indeed out on the market.
I *assume* that the large port count stuff will also show up for USB-C. 

Bob

> On Jun 2, 2015, at 4:44 PM, Jim Lux <jimlux at earthlink.net> wrote:
> 
> On 6/2/15 4:07 AM, Bob Camp wrote:
>> Hi
>> 
>> The one thing I would be a bit careful about is the power levels.
>> 
>> Consider an 8 port hub:
>> 
>> 5V 3A from each would be 24A total. That’s pretty unusual. Most hubs
>> give you one or two high current outputs.
> 
> There are very few 8 port hubs and lots of 7 port hubs (at least for USB 1 and 2).  A 7 port hub is two 4 port hubs daisy chained.  For commercial products, most (if not all, I've not checked for sure) have only 2 of the high power jacks.
> 
> The power switching and control protocol is non-trivial, especially if you are connecting and disconnecting devices. On windows (and other OSes, too, I imagine) there's a whole thing where the OS tries to keep track of the state of the whole tree of USB devices, so that it doesn't try to send a "power up" message to a device that downstream of a "powered down" hub until it's sent the "hub power up" message.
> 
> There's also some weird (and entirely within spec, apparently) behavior of a hub where it, say, has 1.2 Amp total capability, so the first two 0.5 Amp devices that are plugged in get the full allocation, and the rest do not get the "high power" acknowledgement.  Plugging in a combination of high and low power devices (or, equivalently, enabling and disabling them) can lead to things sometimes working and sometimes not.  (the Knapsack problem, which this sort of is, is NP hard, after all)
> 
> I've also found devices/hubs that seem to use some sort of ad-hoc power allocation scheme (actually measuring the power drawn, as opposed to just saying "high power (500mA)" and "low power(100mA)" devices when querying the device and/or looking at the pullup/pulldown  on D+/D-
> 
> One reference says "All USB devices enumerate as low-power devices at first. After enumeration, the host examines the bMaxPower field of the configuration descriptor for the device. If bMaxPower indicates that the device is high-power, and the power is available, the host allows the device to transition to high-power"
> 
> the whole "if power is available" might be done in real time.
> 
> And this causes real issues if you have a USB powered device that has multiple power modes (I have a bunch of radar modules that started out being USB powered, and have a low power "idle" mode and a high power "transmitter and receiver on" mode)
> 
> 
> There's some complexity also with "bus powered" vs "self powered" hubs.  A bus powered only gets 500mA from upstream, so cannot really support any downstream devices at 500mA: therefore, 100mA for each of the 4 downstream devices, and 100mA for the hub itself (if needed).
> 
> 
> In any case, USB power management (and hub and device state management) is substantially more complex than one might think, and lame software drivers in the host can make it more complex; particularly if, as in most modern systems, there's lots of power management going on for hibernation and sleep modes.
> 
> 
> There's a whole bunch of command line commands for Windows to manage this explicitly (if you don't want to use "device manager").  If you're doing a lot of USB stuff on windows, you NEED the devcon command, which gives a lot more visibility into the enumeration and hierarchy.
> 
> USB power management http://support.microsoft.com/kb/817900
> 
> devcon command:  http://support.microsoft.com/kb/311272
> 
> googling "Windows USB power management" will turn up a lot of info, too.
> 
> 
> devcon can also be used to deal with USB COM ports that move around or disappear and reappear.
> 
> I have a system that has 5 Teensy 3.1 microcontrollers hooked to it via USB (emulating a very fast serial port).  The problem is that when the microcontroller changes USB device types depending on whether it's in "bootloader" mode or "running an Arduino program" mode.
> 
> I think devcon might also be a good way to suppress the notorious "GPS masquerading as a Microsoft Serial Mouse" problem which is quite annoying.
> 
> 
> 
> 
> 
> 
> 
> 
>> 
>> 20V 5A (100W ea) on 8 ports would be 800W. That’s not going to be cheap.
>> 
>> Yes, the 20V is an “optional” part of the whole thing. The 3A does not appear
>> to be quite so easy to ignore. We’ll see what actually happens …..
>> 
>> Bob
>> 
>>> On May 30, 2015, at 11:28 AM, Neil Schroeder <gigneil at gmail.com> wrote:
>>> 
>>> USB-C will offer a number of things that I believe will be of benefit to
>>> time nuts everywhere:
>>> 
>>> 1) High current 5V up to 3A on every port
>>> 2) High voltage/current up to 20V/5A optionally on every port - sufficient
>>> to power some rubidium oscillators natively, and a small boost to get the
>>> rest of them.
>>> 3) a native UART channel - no more freaky USB interrupts/polling to get
>>> your pulses
>>> 4) single omnipurpose connector ends with no insertion dependencies
>>> 5) Better, simpler device enumeration - while I haven't seen how it
>>> addresses this personally, the stuff i have read is very promising.
>>> 
>>> Due to the switched controller nature of the interface, you should have
>>> less nonstandard crap that may cause your computer to hang or other issues
>>> related to drivers. The controller arbitrates a lot more setup details, and
>>> the number of those on the market will be limited compared to usb
>>> peripheral ICs.
>>> 
>>> This may be off topic from your off topic, but it seemed a good opportunity
>>> to share this  info.
>>> 
>>> NS9
>>> _______________________________________________
>>> time-nuts mailing list -- time-nuts at febo.com
>>> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>> and follow the instructions there.
>> 
>> _______________________________________________
>> time-nuts mailing list -- time-nuts at febo.com
>> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
>> 
> 
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.