
USB-C Explorer – A development board to get started working with USB Type-C - walterbell
https://www.reclaimerlabs.com/blog/2018/8/7/the-usb-c-explorer
======
walterbell
Additional resources:

USB-C for Engineers, [https://www.reclaimerlabs.com/blog/2017/2/1/usb-c-for-
engine...](https://www.reclaimerlabs.com/blog/2017/2/1/usb-c-for-engineers-
part-3)

An example of USB power delivery,
[https://www.reclaimerlabs.com/blog/2017/5/16/example-usb-
pow...](https://www.reclaimerlabs.com/blog/2017/5/16/example-usb-power-
delivery)

Twitter thread which observes “ethernet-like” protocol over control channel of
USB power delivery,
[https://twitter.com/whitequark/status/1035764804886126592](https://twitter.com/whitequark/status/1035764804886126592)

------
TheAceOfHearts
You know what I'd love? A tool that lets me identify what USB-C features a
cable supports. As I understand it there are multiple cable variations, but
it's not possible to identify visually.

It would be even cooler to have a device that you could plug into a port to
identify what USB-C features the host supports, but I don't know if that's
possible.

In general I like USB-C, but having such a large mix of capabilities without
an easy way to identify what's supported is a big pain point.

~~~
jjoonathan
Between USB-C and mSATA/mPCIe/M.2 it seems like in just few short years the
state of hardware UX reverted from "match the shape to the hole" to "buy pre-
matched / pre-assembled and don't you dare lose or mix/match anything." What
happened? Psychoactive substances in the water? Hostile takeover of the
standards bodies by marketroids? Anyone here have an inside perspective?

~~~
ken
Simpler: Hanlon's Razor.

When engineers see 5 different physical ports, they want to consolidate,
because there's no good reason for them to be different, and there are real
benefits to be gained by having them all the same.

E.g., Stuart Cheshire (Chairman, ZEROCONF Working Group), 2002: "My hope is
that in the future — distant future perhaps — your computer will only need one
wired communication technology. It will provide power on the connector like
USB and FireWire, so it can power small peripheral devices. It will use IP
packets like Ethernet, so it provides your wide-area communications for things
like email and Web browsing, but it will also use Zeroconf IP so that
connecting local devices is as easy as USB or FireWire is today. People ask me
if I'm seriously suggesting that your keyboard and mouse should use the same
connector as your Internet connection, and I am."

It's a great vision, but unfortunately, on the path from here to there,
features get cut. If your product needs to support 5 different protocols, and
you have to cut 1 to ship on time, that's still pretty good as far as your own
product is concerned (80%!). If every manufacturer does this, though, you end
up with a mess of cables and connectors that aren't quite compatible with each
other -- and users are more miserable than before this whole exercise started.

I don't think anyone _wants_ their USB-C device or cable to be intentionally
incompatible with another USB-C device or cable. They just don't make 100%
compatibility a hard requirement.

~~~
userbinator
_When engineers see 5 different physical ports, they want to consolidate,
because there 's no good reason for them to be different, and there are real
benefits to be gained by having them all the same._

Only _certain_ engineers. Don't group the ones who love gratuitous complexity
and "value engineering" with those who think complex standards like USB-C are
a horrible idea and would rather have separate and simple interfaces.

There's a reason RS-232/485 (along with good old D connectors) are still
extremely prevalent in non-consumer equipment.

~~~
quietbritishjim
I think that's a very developer-heavy perspective. As a user who doesn't know
anything about hardware communication standards (lucky me, perhaps?) I think
the fewer connector types there are, the better.

With a single USB OTG cable I can connect almost any peripheral to my phone,
including my XBox 360 controller and my endoscopic camera. Why not a monitor
as well? Why do they have all these other weird non-USB connectors like HDMI
and DVI? I'm sure there's a good answer from a developer's perspective but
from a user perspective or makes perfect sense for there to be a single
connector to rule them all.

Edit: another example is that sometimes I connect more than one mouse or
keyboard to a single computer. Imagine if there were still dedicated ports for
each type of peripheral – would I need to buy a special motherboard with two
mice slots? Or a mouse port expansion card? What a nightmare.

~~~
jjoonathan
Completely interchangeable cords for everything is an excellent goal that
everyone agrees would be a beautiful thing. That idea/direction is not what
we're criticizing. It's the implementation that we're criticizing. In
particular, the implementation that still requires separate cords for separate
tasks (because each USB-C cable supports an unknown subset of the
capabilities) but removes the labels and visual / physical cues that you could
use to identify _which_ tasks it supports. Not only does this fail to achieve
the dream, it fails to even live up to the previous generation.

Eventually we'll reach the dream and it will be great, but there was no need
to jump in the pit of spikes on our way there. It wasn't blocking the road, it
wasn't camouflaged, it was out there in the open, and the USB-C guys decided
it would be fun to jump in. Why?

------
cjcampbell
Just purchased a TS-80 soldering iron and have been incredibly frustrated by
the power requirements. While USB-C, the device requires 2A with 9V. Out of
four Type C, PD chargers, I don’t have anything capable of this combo.
Shopping around for something other than a dedicated QC3.0 charger, it’s been
interesting to see how few of the manufacturers publish a convenient and
complete set of charging specs. Something like this will certainly come in
handy.

~~~
simcop2387
It's unfortunate but as you've noted, the TS-80 is QC3.0 only. This means
you're going to need a dedicated charger (Though I thought the TS-80 shipped
with one?). This means that it doesn't support negotiating with USB-PD devices
to get the power it needs even though they'd be otherwise compatible. If they
had been able to do QC 4 or USB-PD directly then it'd be a lot easier to find
compatible devices (QC 4 added compatibility with USB-PD up to 27W).

~~~
voltagex_
I wonder if it'd be possible to make a QC2/3 -> PD translator? (for up to
12V/1.5A)

~~~
simcop2387
Not a huge reason why you couldn't. There's some differences in current and
voltage resolution; PD does 20mV increments of the voltage and similar for
current, depending on the mode you ask for; and QC 3.0 does it in 50mV and
100mA steps IIRC. So you'd have to round up for the current and hope for the
best with the voltage which would likely fine, cable losses would be more than
the differences in steps. But that could result in less accurate regulation
and such on the other end if it jumps too much and causes it to then request a
lower voltage until it drops the next step.

------
sitkack
Warm yourself with the tire-fire that is USB-C PD [1]

[1]
[https://twitter.com/whitequark/status/1035729916149604353](https://twitter.com/whitequark/status/1035729916149604353)

~~~
gumby
Oh boo hoo they enumerated an enormous number of corner cases, handled
backwards compatibility, crappy cables, all sorts of things. It also reflects
decades of back compatibility and painfully learned mistakes (consider mini-A)
not to mention some weird pathologies (weird naming like hi-speed/ full-speed/
super-speed).

It sucks that the standard is so complex that a small number of design houses
and consulting shops will end up with a de facto cartel of understanding the
Sacred Knowledge, but nobody's stopping you coming up to speed by reading the
whole spec and doing a lot of implementing. But it's not like you can build a
solid TCP stack these days either simply by reading the original late 70s
RFCs.

And you don't have to use this spec -- you can still use RS-449 if you think
the USB spec has become overly complex. In fact I used that in a design only a
few years ago!

~~~
whitequark_
> But it's not like you can build a solid TCP stack these days either simply
> by reading the original late 70s RFCs.

I literally did this. It's called smoltcp
([https://github.com/m-labs/smoltcp](https://github.com/m-labs/smoltcp)) and
we use it in production as an lwIP replacement with great results.

~~~
etaioinshrdlu
I think it would be cool if a project had a self-imposed token count limit.
The project would never be allowed to grow more than X tokens long.

Then you can guarantee the project is small and haiku-like forever!

LWIP started off small, and it grew...

~~~
whitequark_
The "smol" in "smoltcp" is mostly talking about the internal architecture and
exposed API. For example, it will never support true zero-copy sockets,
because the API burden due to restricting itself to safe Rust is too high.

I don't think any TCP/IP implementation is going to be "haiku-like", the
protocol stack is way too messy.

------
djsumdog
I've really wanted to take a shot at a USB-C KVM. I realize this would require
USB-C DisplayPort DSPs and a lot of knowledge that's waaaaay over my head. I
know some of the ViewSonics have build in USB-C KVMs, but I don't think any
other monitor manufacturer has gone this route yet.

~~~
adammunich
actually you just need passive signal switches for this, rather simple.

~~~
rini17
Can you provide some evidence? If it is so, surely many already have done
this.

------
zbrozek
What's the canonical project for the source code? The links in the writeup go
to github projects with deprecation warnings and links to other projects. Are
there yet more projects?

What's the best one to use if you want to actually build a widget that talks
to the FUSB302 and does PD negotiation?

------
AceJohnny2
Oh hey, I remember chatting with the author about this project at EMSL a year
ago. Glad to see it complete!

------
jradd
I didn't realize you could pull 87W from the Macbook Pro adapter using USB-C!

------
dynjo
The fact somebody felt the need to build this (great work btw!) tells us
everything that is wrong with this “standard”.

