A device can tell when one end of the cable is plugged in by testing the cable's control channel, even without the other end connected yet. It sees that a cable is connected, but there's nothing on the other end, and presumes it's first and should act as the provider. A second later, you connect the other end of the cable to a consumer, and the first device will try to negotiate its role with the second. It's up to the devices to respect each other's role requests.
Different device types (like a powered hub or desktop monitor) can request different roles, and they'll have to sort it out during negotiation if there's a conflict. Sometimes a user-facing popup will ask you if you want to provide or take power from the other device.
Not necessarily. It can just test the resistance of the port/cable to see if anything is there. The first device (power provider) to detect the cable can say "ok, I got plugged in first" and then tell the other device (the consumer) that when they try to negotiate power delivery. That doesn't require maintaining state in the cable itself, just that the devices be able to detect the cable when it's plugged in (even without the other end connected).
The cable has a few wires dedicated to directionality (CC1 & CC2) lines as well as sideband channels. My guess would be that the first device to be plugged in sees nothing on the other side, decides it's going to ask for power, and configures itself (and thus the cable) as such. The second device sees a USB-PD device requesting power and begins to provide it.
While I don't doubt the foresight of Apple HW engineers, the possibility strikes me that this is entirely accidental and derived from the design of the USBPD spec. If so, these "stars align (but only because the spec was functionally designed)" moments are some of my favorites.
There are cables with an IC connected to the CC pins. However this is AFAIK only used to determine if the cable can handle higher charging currents, still the MacBook could detect if the cable was plugged in before the device in the other side
https://www.inviolabs.com/blogs/news/what-is-e-marker-and-wh...
This is really weird, most laptops require 20V PD to charge since the internal cells are typically at ~17V. So if true one of the decices (probably the laptop) has a boost converter. Still probably really inefficient
You know in scifi movies and novels where the protagonists tap at their keyboard and "route power to needed systems"? It looks like we're going to actually need the capability to dynamically choose where power comes from and goes to sooner than later.
20 comments
[ 3.6 ms ] story [ 57.8 ms ] threadIn Android there is a "Charge connected device" setting that you can turn on or off. Mine is off by default.
http://blog.teledynelecroy.com/2016/02/usb-type-c-cable-dete...
Different device types (like a powered hub or desktop monitor) can request different roles, and they'll have to sort it out during negotiation if there's a conflict. Sometimes a user-facing popup will ask you if you want to provide or take power from the other device.
Cable detection: http://blog.teledynelecroy.com/2016/02/usb-type-c-cable-dete...
Overview of USB power delivery negotiation: https://www.embedded.com/usb-type-c-and-power-delivery-101-p...
And then after the initial connection, the devices can renegotiate their roles if you want to reverse the charge.
It's great when it actually works. In the real world there are so many incompatible implementations that USB-C is a real clusterfuck.
While I don't doubt the foresight of Apple HW engineers, the possibility strikes me that this is entirely accidental and derived from the design of the USBPD spec. If so, these "stars align (but only because the spec was functionally designed)" moments are some of my favorites.
https://fossbytes.com/charging-cables-used-to-hack-devices/
Well, assuming batteries with similar % charge <-> voltage correspondence.