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

Jim Lux jimlux at earthlink.net
Tue Jun 2 20:44:23 UTC 2015

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.

More information about the Time-nuts_lists.febo.com mailing list