Post has attachment
How do USB Type-C chargers support older USB devices?

tl;dr: All new USB-C dedicated chargers must also support USB Battery Charging 1.2 Dedicated Charging Port (BC 1.2 DCP) by shorting together Dp and Dn.

Ever run into a situation where you plug your older MicroB or Lightning port phone into a Type-C charger and nothing happens, or slow charging happens?

I was looking through some of the ECNs (Engineering Change Notices, or how the folks behind USB make changes to the specs) in the latest USB document bundle, and I noticed a document named, "USB Type-C ECN BC1.2 Clarification."

In red, there's the new requirement:
"A USB-based charger with a USB Type-C receptacle (Source) which is not capable of data
communication shall advertise Type-C current of at least 1.5A and shall short D+ and D- together
with a resistance less than 200ohms. This will ensure backwards compatibility with legacy sinks which
may use BC1.2 for charger detection."

Why did they make this change? Because prior to this requirement, BC 1.2 was completely optional and some dedicated chargers with Type-C receptacles chose to not implement it, instead implementing Apple's 2.4A BrickID, or nothing at all (floating Dp Dn). In some cases, this meant that completely valid cable combinations (using a C-to-Areceptacle adapter + A-to-B or A-to-Lightning, or using a C-to-uB, or a C-to-Lightning) would result in no charging or slow charging.

Going forward, all new dedicated chargers (those that lack any data functionality) must short Dp and Dn in accordance to BC 1.2 DCP. This will ensure that legacy devices will detect Type-C chargers as DCPs. This will include legacy iPhones and iPads as well.

Note: This requirement also means that it's no longer allowed to use Apple's BrickID method on Type-C receptacles anymore to advertise 2.4A on the port. This was covered in an earlier Type-C ECN which forbid all proprietary charging methods on the new Type-C connector, including Apple's. Now, if it's a receptacle dedicated charger, it MUST support BC 1.2 DCP.

This ECN, by the way, has also been rolled into the latest Universal Serial Bus
Type-C Cable and Connector Specification Revision 1.3.

+Nathan K. and +Hanpen for FYI, since they both ran into chargers that don't do this yet (various Anker and other chargers).

Post has attachment
How do Type-C Power Sources and Power Sinks dynamically negotiate power? (What are Sink Power Sub-States?)

If you recall my blog post on USB Type-C’s Configuration Channel (ref 1), one of the features of CC is to allow the power source to advertise its power capabilities to the sink; the source uses three values of the Rp resistor (Default USB, 1.5A, 3.0A) to indicate how much current the Type-C power sink may draw at 5V, and the sink detects this as different voltage levels on its CC pin on its end of the cable.

An important detail that I hinted at is that the source is allowed to dynamically change the value of Rp used during the same session without disconnecting, and the power sink must respond in kind and adjust its current limit.

The part of the USB Type-C spec that governs the behavior is Section “Sink Power Sub-State Requirements” and the simple state diagram attached to this post. When a device is in Power3.0.SNK state, it may draw no more than 3.0A at 5V. When a device is in Power1.5.SNK state, it may draw no more than 1.5A at 5V.

There are several reasons that a power source may change the power advertisement during the duration of a Type-C session.
The source may do this for load balancing (ie, the power source has a shared pool of power that must be split unevenly between several ports), or for temperature mitigation, for example. Some condition may change, causing the port to need to reduce the power consumption on a port, or allow the power consumption to jump up to a higher level.

Some examples of real-world power sources that change their Rp:
1) Google’s 22.5W Dual Port charger (
This Google charger has a 22.5W budget and two Type-C ports. Each port, individually, is capable of 3A, but when two devices are plugged in, one port gets 3A and the other gets 1.5A
2) Samsung Chromebook Plus (Ref 2) - This Chromebook is designed for 15W total output balanced between two Type-C ports. When a single one of the laptop’s Type-C ports is being used as a source, that device is given a 3.0A advertisement. When both are used, 1.5A advertisements are given to both ports.
3) Apple’s MacBook Pro 13” and 15”. (Ref 3) - Apple’s MacBook Pro has either 2 or 4 Type-C ports, with support for 15W output on half of the ports and 7.5W output on the other half.

In the case of the Google 22.5W Dual Port charger, the power advertisement of each port is based on measured power consumption. If the sink attached to the charger’s bottom port draws more than 1.4A, the charger will allow it to have up to 3.0A via the 10kOhm Rp, while the top port will only get 1.5A via 22kOhm Rp. However, if the power consumption drops below 1.4A again, the top port will see 3.0A given to it. This allows for smarter balancing of two devices when one’s battery gets close to topped off and it naturally draws less current, for example.

One important detail about the transitions between Sink Power Sub-States is that there is actually a deadline in the spec on some of the transitions. Crucially, transitions from higher to lower sub states, for example from 3.0A -> 1.5A are limited to tSinkAdj, which is mandated to be 60ms in the spec. Within 60ms of the voltage dropping from vRd-3.0A range to vRd-1.5A range, the sink (phone, laptop, etc being charged) must lower its power consumption to within the new limit.

Hope this has been helpful in understanding how dynamic power balancing happens in USB Type-C!

Ref 1 :
Ref 2 :
Ref 3 :

3 Photos - View album

Post has attachment
+Russell Holly, actually what you are describing is a common problem but it is actually a flaw in the simple Type-C battery pack and not necessarily the phone.

The battery pack, if it was implemented with USB Power Delivery and is connected to a USB PD phone like the Pixel, could identify that the other party is a dual-role device with a small battery like a phone and not a fixed power source like a wall charger and hold-off on draining from the phone.

If i were to design the pack, i'd allow the battery pack to just draw enough power to boot itself up until it can recognize the other device is a dual-role device without its own external power source using PD, and then stop charging. That way neither phone or the battery pack charge.

We could make the phone behave in the way you want... such that it only ever acts as a power sink until you explicitly ask to turn on power source and host mode, but that would mean that if you wanted to plug in a USB thumbdrive, or a USB accessory like, oh I don't know... USB-C digital headphones, they WOULDN'T work unless you explicitly change some setting first. You'd not even get any notification when you plugged in your USB-C headset because the port is fixed in sink-only mode, and it needs to supply power to the headset before the OS can even identify it as a headset.

These corner cases are hard to solve, but simplistic solutions like "phone always charges itself, never supply power" have pitfalls too!

There are really clever things that we can do if both phone and battery pack support Power Delivery.

Post has attachment
+Gordon Ung of +PCWorld has posted an update to the article he ran a while back testing various laptops with other Type-C power adapters.

The results are promising! In most cases, Type-C laptops just work when presented with another Type-C laptop's charger.

This is certainly not the end of the story though. There are other compatibility corner cases that happen especially with chargers that do not follow the USB PD Power Rules, and with smaller devices.

Post has attachment
+TalkAndroid, your article on on USB Type-C has some incorrect information... Especially the discussion about how "you really don't have to buy new USB-C cables to take advantage of something like USB 3.1"

That's provably false. If your phone only comes with a USB 2.0 only C-to-C cable, like the Pixel phones, in order to take advantage of the USB 3.1 controller in the phone, you'll need to buy a more complex USB 3.1 C-to-C cable, which has 10+ more wires.

Also, we've stopped calling the 5Gbps variant "USB 3.0". Both 5Gbps and 10Gbps variants are considered "USB 3.1" but the former is "Gen 1" while the latter is "Gen 2"

Not many mobile applications (ie phones, tablets) have Gen2, but many desktops and laptop PCs have Gen 2 now.

Post has attachment
+Texas Instruments put together this blog post last year, and it's an excellent resource for questions that are bound to come up this year about Power Delivery 2.0 versus Power Delivery 3.0.

Critically, it addresses the common misconception that the new PD Power Rules only applies to PD 3.0. That's not true! The 5/9/15/20 rules started applying to all PD 2.0 adapters in January of 2016 as well! See my post about that here :

The rest of the post goes to explain what the real difference between PD 2 and PD 3 is. It's subtle, but basically PD 3 builds in additional infrastructure into the protocol. Since TI's blog post, there's actually been a few new features added to PD 3.0 due to the expanded messages support. Perhaps later, I'll explain what these are (hint, something called Programmable Power Supply)


Post has attachment
I made a small error in reading and transcribing the USB Type-C spec when I edited this page last time.

I had previously wrote that 5V should only be applied when voltage vRd on CC is 0.85 < vRd < 2.60V. It turns out that 2.60V is the threshold voltage, and that the correct value should be 2.45V for the maximum voltage of vRd.

Page has been edited to reflect this.

Thanks +Nathan K.  for bringing this to my attention.

Post has attachment
If you're a follower of this and my other collections, you'll recognize the Twinkie analyzer tool :

Up until recently, the tool has been slightly clunky to use. Getting to Twinkie's command line required a Linux distro running on a PC, and even then, the specific instructions included installing the "usbserial" driver and writing Twinkie's USB VID:PID into sysfs to tell the usbserial driver what Twinkie is.

Recent Linux kernels have changed that because Google's serial devices (of which Twinkie is one) have now been included in the usb_serial_simple driver, so it should just be plug-and-play for recent Linux distributions.

As of Chrome OS 55, the necessary kernel patches are now in live in stable channel on Chrome OS as well.

What does this mean? If you're a Chromebook user and a Type-C enthusiast or developer, it's now possible to use Twinkie's command line interface without being in Developer mode, and without using Crouton or anything else.

Instead, install BeagleTerm :

Then plug in Twinkie, and launch BeagleTerm. All works while the Chromebook is even in Normal mode (secure boot).

This will also work with +Plugable's USBC-TKEY version of Twinkie available here :

Hope this has been helpful!

2 Photos - View album

Post has attachment
My team, the Chromium OS team, has updated our USB Type-C Cable and Adapters 1-page sheet with the following additions.

* USB Battery Charging 1.2 - we highly recommend that Type-C chargers with USB-C receptacles also support Battery Charging 1.2 DCP or CDP in order to support legacy devices. (Thanks +Nathan K.)
* Common FAQ about proprietary charging methods - Proprietary voltage change methods are forbidden as per Section 4.8.2, and thus manufacturers building Type-C power adapters shall not use them.

#USB   #TypeC   #USBC  

Post has attachment
+GTrusted posted a very complete description of the events that occur when you use a charge-through USB Type-C PD hub with a device like a +HP Chromebook 13 G1.

It's actually quite complex, with three different devices in the mix (the charger, the +Plugable hub, and the Chromebook) all negotiating with each other.

Voltages change between the two sources, and a role swap occurs between the laptop and the hub. This is a great illustration of the real potential of a USB Type-C and PD future. :) Type-C isn't just another shape connector. It opens up entirely new use cases like this.

#USBC   #USB   #TypeC  
Wait while more posts are being loaded