My new iPhone with USB C charging is such an improvement!
Thank goodness for the European Union. If it weren't for them, we'd all be stuck with these flimsy Apple charging cables forever.
Always found it a bit strange that USB-C is referred to as a "new connector" when it clearly seems to be an entirely new protocol. (Unlike the previous new connectors mini and micro which were just differently-shaped plugs for the same wires)
So is the protocol technically USB 4.0 and USB-C "just" a new connector role defined by that protocol, or did they ditch the versioning and "USB-C" is its own thing?
The guide mentions that USB 4.0 is the first version to require a USB-C connector, but then later refers to the "USB-C protocol". Is that the same as USB 4.0?
Pretty good summary. It can be confusing since type C is "just a connector" but it's pretty heavily coupled with the protocol now.
Guides like this explain why there are so many broken USB-C devices. The guide mentions that you do not need a PD chip for 5Vs, but then tells you that USB C is a cold connector meaning 0V is on VBUS when nothing is connected and jumps straight into the complexities of the PD protocol running over the CC pins instead of explaining how to get the 5V without the PD chip first.
Then in the section where it tells you how to do that, it fails to properly explain how to connect a load switch (10 cent component at 100 units) to get around the 10uF limit. The vast majority of applications will require less than 15 W and a good chunk of them can't get away with 10uF between VBUS and GND so a schematic how to do it in the lowest cost way would have helped here.
Edit: After reading until the very end I got the impression that this is just an ad for Texas Instruments PD controllers.
How can I read out the bit error rate?
there is a timestamp as parameter, I don't know, what it is good for, but the link works without it as well
A helpful guide, but usb c usability from a consumer standpoint is atrocious. From the specs it runs so many modes, PD (at various power levels), classic 5v , alternative modes. Sadly, there’s no way of knowing which mode a device or cable is supporting.
They could have done a better job color coding the connectors like resistors, so you could know the protocols supported by the cables and devices.
I have to label my own cables according to data support, PD, max power, etc. And many of my “usb c” devices only work with usb-A to usb-C cables.
The connector design targeted the industry and not consumers. Hopefully they will improve that.
USB-C reminds me of HTTP: one familiar interface hiding an enormous amount of complexity underneath.
That's great for experts, but difficult for everyone else because the same connector can expose wildly different capabilities depending on the implementation.
The EPR safety design is the part worth highlighting for anyone not deep in USB PD. The handshake is deliberately structured so a single message error can't accidentally push a port into a 100W plus contract, the sink has to actively drive entry into EPR mode and the source verifies cable capability before sourcing anything above 20V. That's a sensible failsafe given how much heat and current you're dealing with at 48V and 5A. The eUSB2 section is also underrated context for why this matters beyond cables. As process nodes shrink below 7nm, the old 3.3V USB 2.0 signaling literally becomes a reliability risk to the silicon itself, which is why chipmakers had to invent a whole lower voltage PHY just to keep USB 2.0 alive on modern nodes.
Good find!
Nice one. I need to read this later.
I use an Apple Silicon Mac and often use programmable keyboards like the Royal Kludge RK61 via USB C. when I press keys such as A, S, D, F, W, or nearby keys in quick succession, the keyboard stops responding completely until I unplug and reconnect it. I've even replaced the USB C cable with a new store bought cable, but the issue still persists.
Bit of self-promotion: I spent the last year or so designing an open-source USB-PD protocol analyzer[1], and the complexity of the protocol can be mind-boggling. Most of the time, the communication between source and sink is really straightforward, but it can get amazingly complicated when both devices are dual-role or come from the same vendor[2].
As messy as it is, however, it's also a very useful protocol that allows even small players to take advantage of the same economies of scale that large companies can take advantage of. Pity that the communication often requires dedicated chips, though thankfully those are relatively inexpensive. I was able to get an RP2350 (the same MCU that's in the Raspberry Pi Pico 2) to interface directly with USB-PD, but they could have made it easier and more accessible.
[1] https://github.com/T76-org/drpd or https://www.crowdsupply.com/t76-org/dr-pd [2] https://hackaday.io/page/399885-a-mac-and-an-ipad-walk-into-...