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

Neil Schroeder gigneil at gmail.com
Wed Jun 3 10:08:34 UTC 2015


It's definitely no optional.  The TI part is designed for that. Not sure
about the others.

The HV bus is definitely optional - but most stationary devices - hosts,
docks,etc can supply that no issue

I would say that we will see big values on the HV bus from AC mains powered
devices.

On Tuesday, June 2, 2015, Bob Camp <kb8tq at n1k.org> wrote:

> 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 <javascript:;>>
> 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
> <javascript:;>> 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 <javascript:;>
> >>> 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 <javascript:;>
> >> 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 <javascript:;>
> > 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 <javascript:;>
> 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