[time-nuts] USB problems and solutions - Some what Off Topic --> USB-C
jimlux at earthlink.net
Tue Jun 2 20:44:23 UTC 2015
On 6/2/15 4:07 AM, Bob Camp wrote:
> 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 …..
>> 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.
>> 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