←back to thread

USB On-The-Go

(computer.rip)
208 points jnord | 1 comments | | HN request time: 0.364s | source
Show context
thomas-st ◴[] No.42622492[source]
I have a power bank that is PD capable, but I cannot charge it from my MacBook even if the MacBook is plugged in to power. I get around it by using a USB-C/A dongle and corresponding USB-C/A cable. Presumably this "downgrades" the connection and since the MacBook doesn't support traditional USB charging it has to charge the power bank. Does USB-C not have a way to indicate that a potential power source is a battery so that the MacBook can charge it if it's plugged in to power, and reverse roles otherwise? Is this a fault how the power bank or macOS implements power negotiation, or is this scenario simply unaddressed in USB-C?

Funny enough, if I plug the USB-C/A dongle on the end of the power bank and the cable into the MacBook, it also won't charge.

I also have a Philips One toothbrush with a USB-C charging input. Similarly, I can't charge it with a USB-C cable directly from my MacBook but have to use A in between (I unsuccessfully tried using either a thinner "lower speed" or a thicker "higher speed" USB-C cable). I'm assuming the toothbrush doesn't support PD, so then why can't it fall back to traditional charging with a C-to-C cable?

replies(6): >>42622617 #>>42622643 #>>42622913 #>>42622952 #>>42623837 #>>42627256 #
mschuster91 ◴[] No.42622952[source]
> I also have a Philips One toothbrush with a USB-C charging input. Similarly, I can't charge it with a USB-C cable directly from my MacBook but have to use A in between (I unsuccessfully tried using either a thinner "lower speed" or a thicker "higher speed" USB-C cable). I'm assuming the toothbrush doesn't support PD, so then why can't it fall back to traditional charging with a C-to-C cable?

Because USB-C says that a power source cannot provide 5V onto Vbus until negotiation has happened to prevent both endpoints of the link "competing" for power which can have disastrous results - for USB-C devices, that is either two resistors on cc1/2 that is pretty dumb 5V, or it is actual bi-directional communication. Early USB-C devices, most infamously the Raspberry Pi 4, various vapes and likely your toothbrush managed to mess that up [1], although I recently came across a flashlight at Lidl which also has broken resistors.

Using an USB-C male to USB-A female adapter fixes this because the adapter has the two cc1/2 5K resistors correctly in place. The adapter can safely do that because - other than early USB 1 era hubs - 99.999% of USB-A devices with a separate power source have backfeed prevention, and so the source side will just provide 5V at either 100 mA or 500 mA cutoff.

More sophisticated power source devices will also try negotiation over D+/D- after the sink device has started to negotiate higher voltages using various proprietary schemes, there's controller chips available that speak everything from plain 5V@100mA bootstrap over 5V@500mA USB2 and proprietary schemes up to 20V@3A (and probably, given the newest USB-C PD specs, even higher), without even needing an external microcontroller (but of course, muxing the bus for everything up to USB4/TB should there be one). Absolutely wild.

[1] https://hackaday.com/2019/07/16/exploring-the-raspberry-pi-4...

replies(1): >>42638835 #
Dylan16807 ◴[] No.42638835[source]
> Early USB-C devices, most infamously the Raspberry Pi 4

They don't get the excuse of "early". The first macbook with USB-C came out four years before it.

replies(1): >>42721106 #
1. derefr ◴[] No.42721106[source]
It's "early" until the sockets and controllers are standard Shenzhen factory pick-and-place jellybeans. For the first few years of USB-C, it was essentially just being supported by one or two suppliers that most factories didn't work with — because that's all that needed to exist in the market when it was only Apple and maybe Intel sticking those chips and sockets on things.

See also: Thunderbolt, which still has this problem even today. (With the move to merging it into "USB4" in large part an attempt to solve the chicken-and-egg board-design-vs-part-supply problem by at least allowing use of the now-jellybean USB-C sockets, thus reducing the problem to "just" one of Thunderbolt-enabled controller-chip sourcing. And having an SoC that speaks PCIe in the first place.)