USB-C Power Delivery has definitely made the big mess of wires a bit smaller but not all cables are created equal — some of them can handle upwards of 100 W while the cheapest can handle only 10. To accommodate this, USB-C cables need to actively tell both ends what their capabilities are, which turns an otherwise passive device into a hidden chip in a passive looking cable.
[Greg Davill] has decided to unravel the mystery of why your laptop isn’t charging by creating a USB-PD sniffer. Based on Google’s Twinkie sniffer, the FreshTwinkie makes the design more accessible by reducing the number of layers in the PCB and replacing the BGA variant of the STM32 for a more DIY-friendly QFN version. Interestingly, this isn’t the first time we’ve seen somebody try and simplify the Twinkie; back in 2021, the Twonkie from from [dojoe] hit a number of similar notes.
USB-C Power Delivery is just one of many protocols spoken over the CC pins, and the FreshTwinkie might be able to detect when some of those are enabled and why or why not. With future development, it could potentially provide useful information as to why a Thunderbolt 4 or tunneled PCIe device isn’t working correctly.
I would love to see v0.2 drop the microUSB connector for anything else. As my microUSB cables wear out, I hope never to replace them.
Micro-USB is pathetic trash. Is that the only USB port on this thing? I can’t find any picture other than this one.
Since it’s a PD Sniffer, it definitely connects to USB-C primarily. In the picture, those are USB-C ports on the right and left. The micro USB connector is on the bottom in that view, and might be used as a ground (?)
Micro USB makes a heck of alot of sense for something like this – its a simple spec that means the tester will reliably just work. USB-C with its either way up and PD type stuff instantly adds more complexity and a lack of reliability – Which is part of why these sniffers exist!
USB-C has become ubiquitous and has some nice features, but plain and simple USB 2.0 micro/Mini/A/B are still a really good choice when simple and reliable is what you want and you have no need of the highest of high speeds, PCIe alt modes etc.
Oh you should be aware by now that replacing a MicroUSB socket with a USB-C socket only requires two additional 5.1k resistors ;-P That’s it – no extra complexity required!
But then opens you up to all the odd USB-C cables that may or may not work right, and the polarity stuff that means that either way up cable may actually only work one way up, along with the fact there are now chips in the cables that may or may not manage to glitch the chip you are actively using to try and analyse a different cable – I’m not saying its an insurmountable problem by any means, but why add more points of failure and uncertainty to a tester for no reason at all!
You want the test equipment to be as immune to failure as possible, and you don’t really want the tester to be entirely reliant of the same objects its supposed to test to function properly.
No, it doesn’t open you up to those. That’s a 5V USB2 device, it’s seriously hard to screw up in a way that MicroUSB can’t be screwed up. The “chips in cables” have no effect on this scenario either – I routinely use emarked cables with USB2 stuff, it’s not a problem. You’re also confusing the two ports – the USB-C port for receiving analysis data and the two passthrough ports are not interconnected, so a chip on one won’t glitch the other.
I wasn’t thinking direct cross-talk. But what happens when the USB-C cable providing power has a faulty chip, even for a 5V only device? The answer being who bloody knows as there are too many implementations and varied optionals in the spec that change.
I’ve had a cable that triggers a whole new power negotiation cycle and so browns out every other device connected to that hub every damn time its used (but not constantly or predictably), but as a dumb bridge between two USB2.0 only devices it just works as far as I can tell 100%. I surmised because the e-marker is bust and keeps triggering a new cycle of the I’m newly plugged in negotiation – so the only reason its so noticeable is that hub cuts power to everything, including the USB 2 only USB-A ports as it does a renegotiation, thus corrupting more than a few USB stick as I was using them.
USB-C just adds extra crap that might be a point of failure, and a hard to find hidden one at that for absolutely no purpose in a device a like this – which is kinda why these testers exist! If it was as simple as USB2 you wouldn’t bother building testers to find out if its this cable that is screwing with you or something else.
Micro USB sucks enough that I would rather a slightly noncompliant usb-c like many cheap devices use – one where it ONLY works if you use a generic, no frills usb 2.0 a to c adapter, but then it works in either direction. Ever had trouble with that type?
> But what happens when the USB-C cable providing power has a faulty chip, even for a 5V only device? The answer being who bloody knows
nonsense, what happens is that either there’s 5V power provided, or no power is provided. It’s that simple.
> I’ve had a cable that triggers a whole new power negotiation cycle and so browns out every other device connected to that hub every damn time its used (but not constantly or predictably), but as a dumb bridge between two USB2.0 only devices it just works as far as I can tell 100%. […] I surmised because the e-marker is bust and keeps triggering a new cycle of the I’m newly plugged in negotiation
That’s not how USB-C works. The emarker itself can’t trigger anything, it’s designed in the spec as a passive device and, if needed, it’s queried by the power/data source. It doesn’t send out data. It could be that, simply put, one of the wires in your cable is finicky. So, please consider binning that cable if it doesn’t work for you – it will spare you a good amount of grief!
> a point of failure, and a hard to find hidden one at that for absolutely no purpose in a device a like this – which is kinda why these testers exist!
No, that’s not what this tester is for – it’s for capturing PD comms and measuring device power consumption. The article says as much. That said, the whole conversation was about using USB-C instead of MicroUSB on here, and you took it to rant about USB-C as a whole, as I usually see you do, so it makes sense that you’d misinterpret the article too.
Open source design, so… just go change the connector to whatever you want (and contribute it back)
Went to the github site. This project appears to be about the same age as twonkie and, in fact, is mentioned in the twonkie readme on github.
have you ever read The Twonkie?
SciFi from the ’40’s..
> not all cables are created equal — some of them can handle upwards of 100 W while the cheapest can handle only 10.
That’s not the case. Cables can handle either 3A or 5A, and be rated for either 20V or 48V max voltage. In practice, this results in only three power ratings for cables – 60W, 100W, and the new 240W.
> USB-C cables need to actively tell both ends what their capabilities are
No, the cable can be queried on what it supports, it doesn’t actively tell anything until one of the sides asks!
> USB-C Power Delivery is just one of many protocols spoken over the CC pins
Not as far as I’m aware – to the best of my knowledge, when it comes to CC pins, PD is *the* protocol. You can switch other wires (RX/TX/SBU) into an alternate mode where DisplayPort/Thunderbolt/USB4 is spoken over these. PD messages can be used as a sideband for enabling these protocols or managing really small details (i.e. DisplayPort IRQ), but crucial protocol information doesn’t go over CC pins, using PD or otherwise. For DisplayPort and TB, it goes over SBU pins, DisplayPort putting AUX onto them and TB using SBU pins for a UART link.
> With future development, it could potentially provide useful information as to why a Thunderbolt 4 or tunneled PCIe device isn’t working correctly.
Technically correct! However, to the best of my knowledge, Twinkie-provided information only touches concerns CC and power analysis, and so it will be limited to however far you can get with power and altmode negotiation analysis. If you want to analyze Thunderbolt[-connected] device incompatibilities, I’d bet that the UART channel on SBU pins has way more useful info.
Nice, any recommendations for cables that are consistent and are clearly labelled? It seems like every time I get a new cable it is a different variant of usb c and doesn’t do what I thought it was going to properly