USB Superspeed connector question

[moffy]

I am designing an FT600Q to USB Superspeed interface at present, and am getting a little confused about the USB connector and power negotiation/detection.
The FT600Q datasheet: https://ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT600Q-FT601Q%20IC%20Datasheet.pdf
gives BUS powered example circuits but says this is only valid for the superspeed type B or micro B connectors, but I have opted for the more common Type A superspeed connector which appears to have all the requisite signals of the example.
The connector is: https://www.belfuse.com/resources/drawings/stewartconnector/dr-stw-ss-52000-001.pdf
The circuit at present is attached, please excuse the lack of decoupling capacitors, they will be added. My question is, should this work? or am I missing something? If someone could also clarify how for a USB_A to USB_C host the detection and power negotiation works that would be appreciated. The FT600Q also has a resistor R8 in the attached schematic that has something to do with power negotiation but I'm not sure what. Thanks in advance.

[ataradov]

It will work on a logical level, but Type A connector can only be a power source. And standard Type-A to Type-A cables will not have VBUS connected at all. Although most random Chinese cables have it and it is dangerous and not compliant.

I personally would stay away from Type A for this application.

[moffy]

It will work on a logical level, but Type A connector can only be a power source. And standard Type-A to Type-A cables will not have VBUS connected at all. Although most random Chinese cables have it and it is dangerous and not compliant.

I personally would stay away from Type A for this application.

What would be your recommendation? Type B or C? I originally started with a Type C, but in one example circuit I found they used a mux to select between the two sets of superspeed inputs and outputs, whereas I was blithely happy just to parallel them. Is it possible just to parallel connect the dual sets of superspeed signals, and would there be any other issues with using Type C for this application?

[ataradov]

I would go with Type-C, but you have to tolerate the annoyance or routing  and having to add the mux. Otherwise Type-B is the only real option.

It is not possible to just parallel them. It will not work at SS speeds. The way to know this for sure is to observe that even the cheapest junk from Aliexpress does not do it.  And they would cut any corners they can.

[moffy]

I would go with Type-C, but you have to tolerate the annoyance or routing  and having to add the mux. Otherwise Type-B is the only real option.

It is not possible to just parallel them. It will not work at SS speeds. The way to know this for sure is to observe that even the cheapest junk from Aliexpress does not do it.  And they would cut any corners they can.

Type C it is then with a mux added, thanks.

[moffy]

Attached is the revised circuit using a USB-C connector and a mux, again filter caps are yet to be included, comments welcome. Should I include TVS diodes or are they a point of signal degradation for the superspeed?

[Hydron]

Does the mux have ESD protection built in? There are plenty of low capacitance ESD diode arrays available designed for these speeds if not.

[moffy]

Does the mux have ESD protection built in? There are plenty of low capacitance ESD diode arrays available designed for these speeds if not.

I don't believe it does, but I have read some comments previously that TVS diodes caused some issues on new USB designs, so I'm wondering how problematic they can be.

[ataradov]

Usually you don't see any protection devices on USB SS. I have not researched if there are TVS diodes that would work for this, but if there are, they must be in a pass-through type of package, so should be easy to route and not install later. But personally, I probably would not bother.

[tom66]

I would be minded to put the AC coupling caps for TX pairs on the output of the mux rather than the input.  The mux has no biasing, so it would potentially be switching signals below ground, but it is only rated 0-2V common mode.  Most receivers do bias the pairs on the RX end, but it's not a mandatory feature of USB 3.0 to do so.

[moffy]

I would be minded to put the AC coupling caps for TX pairs on the output of the mux rather than the input.  The mux has no biasing, so it would potentially be switching signals below ground, but it is only rated 0-2V common mode.  Most receivers do bias the pairs on the RX end, but it's not a mandatory feature of USB 3.0 to do so.

That seems to be correct, I will adjust the schematic to suit, thanks.

[Hydron]

Agree regarding using a pass through package for ESD protection if you want it - I've done it on designs in the past and it's easy. For hobby stuff maybe just don't bother though.

[moffy]

Just for reference purposes I used a USB 3.1 type B connector, it sure looks a lot simpler. I am tempted to make two versions, one with USB-C and one with USB-B and if I get stuck with the USB-C version I can fall back to the simpler USB-B version.

[ataradov]

Not having to deal with the orientation makes things easier, for sure. But Type-C cables are nice and readily available.

It would be great if vendors started to include the mux inside the devices. This is something that majority or applications will need and the ones that don't need it, can leave it in a fixed position.

[moffy]

Not having to deal with the orientation makes things easier, for sure. But Type-C cables are nice and readily available.

It would be great if vendors started to include the mux inside the devices. This is something that majority or applications will need and the ones that don't need it, can leave it in a fixed position.

The Type C cables are neater and much more readily available than the full size Type B cables. The Micro B cables seem more common than the Type B but I've never liked the fit of the cable in the connector and one can only get, at least from Digikey, surface mount Micro B connectors, I think one needs the through hole pins to provide the mechanical support necessary.

[langwadt]

Not having to deal with the orientation makes things easier, for sure. But Type-C cables are nice and readily available.

It would be great if vendors started to include the mux inside the devices. This is something that majority or applications will need and the ones that don't need it, can leave it in a fixed position.

why didn't they make it the host responsibility and device only wouldn't have to do it?

[ataradov]

It is not possible to do only on one side. The cable only has one set of wires. Which pins of the connector they are connected to is determined by the orientation of the cable.

They solved this for the USB 2.0 signals by connecting them on the board. But this is not going to work for GHz speeds.

[langwadt]

It is not possible to do only on one side. The cable only has one set of wires. Which pins of the connector they are connected to is determined by the orientation of the cable.

They solved this for the USB 2.0 signals by connecting them on the board. But this is not going to work for GHz speeds.

afaict newer cables have two sets of wires to support 3.2+, or what number they have gotten to, that can use all four pairs. That could work without a mux at both ends, but it would definately not wok if they are put in parallel

[magic]

I believe type C can work without muxing, but only in one plug orientation.

Shorting the two lanes at the plug turns the unused lane into a length of unterminated cable hanging at the end of the connection, which is unlikely to do any good for signal integrity. May not work at all, may not work at certain cable lengths, etc - I have never tried it. Or it may be connected to a second transceiver in a type C host. This is not a problem for the USB 2.0 pair, because it is shorted at both ends, but SuperSpeed pairs are not.

Shorting would only work with single-lane A-C cables, maybe.

Type B is what you are supposed to use on a device if you don't want type C.

You can technically use type A and availability of cables is not a problem, they are widely used for some non-compliant 2.5" disk enclosures and for non-standard board-to-board PCIe (not to be confused with PCIe over thunderbolt). But it's not compliant and not idiot proof - if such cable is plugged into two hosts, one will end up powering the other's 5V rail.

Standard compliant A-A cables without Vbus connection are intended for using the USB debug capability and relatively rare. Practically all A-A cables you will find at "consumer" suppliers have Vbus.

[ataradov]

I believe type C can work without muxing, but only in one plug orientation.

Well, yes. The only reason muxing is needed is for the plug orientation. None of keyed USB3 connectors need a mux, which is how this thread has started in a first place.

All current USB 3.x cables have one TX and one RX pair. And given how stiff the full cable is already, I don't see that changing.
Well, it looks like there are cables with 4 pairs, but frankly I have no clue how to identify them.  All the products I can find are for the motherboard extension to bring out the connectors to the outside panels. I don't see them as the consumer actual cables. I don't know if they would actually exist. You absolutely need this for the panel mounted connectors, so I guess the cable itself has to exists. But terminated with connectors version - no idea.

[magic]

C-C cables have two lanes (two pairs of differential pairs). They are used for the Gen 2 x2  20Gb/s speed.

[Hydron]

Most common use for all 4 super speed pairs is surely DP alt mode, which needs all of them for high resolution screens.

[moffy]

This is a far deeper topic than I realised when I first posted, I appreciate all the discussion and the edification as a result.

[thm_w]

Why are you using 22 ohm D+/D- resistors when FTDI do not?

https://ftdichip.com/wp-content/uploads/2024/10/DS_UMFT60x.pdf

[moffy]

Why are you using 22 ohm D+/D- resistors when FTDI do not?

https://ftdichip.com/wp-content/uploads/2024/10/DS_UMFT60x.pdf

It is quite common on the D+/- lines though FTDI doesn't use it for their application.