USB-C and adapters nightmare - good article to share

Started by pasha811, November 02, 2016, 01:02:09 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.


Jim Roseberry wrote>
Jose has this covered... but I figured I'd chime in... as Thunderbolt can get confusing (especially on PC).

Microsoft decided to support "PCIe via Thunderbolt" (necessary for PCIe level performance), but... only for Thunderbolt-3 controllers.
If you have Thunderbolt-2, you can use Firewire protocol via Thunderbolt (like the original Apollo), but you can't run any audio interface that's using "PCIe via Thunderbolt" (in other words, no super low latency). You could run the original Apollo... but not the newer Apollo-8/16.

Thunderbolt-3 connects via a USB-C port. (This is where it can get confusing.)
USB-C can carry Thunderbolt or USB-3.1
If a motherboard has a USB-C port, that doesn't mean it has Thunderbolt. Many motherboards have USB-C ports... but the port carries USB-3.1.
The motherboard specifically has to have a Thunderbolt-3 controller.
Most Thunderbolt-3 controllers (at this point) are add-in-cards.
They must go into a full length PCIe slot... and also have a cable that goes from the card to a Thunderbolt-3 header on the motherboard.
You can't add the Thunderbolt-3 add-in controllers to just any motherboard.
The motherboard has to have a Thunderbolt-3 header... and the BIOS must specifically support the Thunderbolt-3 controller.

Most audio interfaces are Thunderbolt-2 (commonly just referred to a "Thunderbolt").
The UA Arrow is relatively new... and it's Thunderbolt-3. UA offers a Thunderbolt-3 option card for the Apollo-8/16 (~$500).
For most Thunderbolt audio interfaces, you'll need a Thunderbolt-3 (USB-C) to Thunderbolt-2 adapter.
Apple makes one... as does Startech. (The Apple adapter is about $20 less)
Presonus recommend the Startech adapter.
I've tested the Apple adapter with many different configurations (both laptop and desktop)... and it's always worked.

Once the hardware is squared away, you can connect the Thunderbolt audio interface and turn it on.
Your machine should recognize that a Thunderbolt device has been connected.
The Thunderbolt app should be running (right hand side of the Task Bar - you may need to click on "Show hidden icons" to get to it).
Open the Thunderbolt app. Under Thunderbolt Controller 1, you should see your Audio interface listed.
Click on the listed audio interface. At the bottom of the window, you should now see Device Information (including Connection Status).
Click on the blue Connection Status and select "Always Connect".

Hope that clears up some confusion about Thunderbolt.  :)
Now as to why Helix Native is sounding particularly good to my ears...  :D


Mistakes happen to the best of us... With the all-new Raspberry Pi 4 Model B, the power connector has evolved into a USB-C (instead of a USB micro-B) because the new SoC is more energy-hungry. Unfortunately, there was a bug in the execution. People realized that the Pi 4 did not work with some chargers, especially the MacBook's. Tyler Ward, a Southampton engineer, studied the mini-computer schematics and found the flaw in the design. The problem is that the charging port of the Raspberry Pi 4 shares a single 5.1 kΩ resistor between two of its pins, contrary to the official USB-C specification that says that each pin should have its own resistor.

This non-compliant design breaks compatibility with high-end USB-C cables that are e-marked. These cables have an electronic chip that negotiates power management, data rates, and more. Since the Pi4 USB-C port is not properly wired, these smart cables will detect the computer as an audio adapter accessory and will not charge it. The solution to the problem is simply to use a charger with a non-e-marked cable, such as the official Pi 4 charger. The Raspberry Pi Foundation says that a new version of the card with a specifications-compliant charging port should be available in the "next few months" — probably after the first batch of cards has been sold.

⇨ The blog
Pi4 not working with some chargers (or why you need two cc resistors)
By Tyler | June 28, 2019 23 Comments
The new pi has been released and it has a USB Type-C connector for power however people are finding some chargers are not working with it (notably macbook chargers). Some have speculated that this is due to a manufacturer limitation on the power supplies however it is actually due to the incorrect detection circuitry on the Pi end of the USB connection.

For those looking for a solution for the problem and and aren't interested in the technical details a set of potential solutions are given at the end of this post

The root cause of the problem is the shared cc pull down resistor on the USB Type-C connector. looking at the reduced pi schematics we can see it as R79 which connects to both the CC lines in the connector.

Excerpt from the reduced Pi4 Model B schematics.

Pi CC resistor locations
With most chargers this wont be an issue as basic cables only use one CC line which is connected through the cable and as a result the pi will be detected correctly and receive power. The problem comes in with e-marked cables which use both CC connections. To understand this lets look at the Type C specification document.

Excerpt from the Type-C spec (Figure 4-5)

Per the spec the source device doesn't provide power on the connector until it detects a sink device being attached. which is done by the presence of the Rd resistor (5.1K ohms) to ground. Active cables also signal their presence using another value or resistor Ra (800 ohms – 1200 ohms). The Type-C specification has a table for looking up what is connected based on the state of the CC lines.

Excerpt from the Type-C spec (Figure 4-10)
In the correct operation the charger will sense the Rd resistor (Or Rd Ra cobination) and turn on the power. The problem comes when an active cable which presents an Ra at both ends is used. On the source side one CC pin will be connected to the Ra resistor in the cable and the other to the CC line to the Pi. The Pi has connected both lines together so presents the combination of the Ra at the pi end of the cable and the Rd pulldown. Calculating the presented resistance assuming a average value of Ra still gives a value well within the Ra range (also note Ra resistances are permitted to go below 800 when cable electronics are drawing power so a resistance lower than 800 will also likely be detected as Ra).

Pi's presented resistance
With effectively two Ra values presented to the Source end it will detect the Pi as an "Audio Adaptor Accessory". These are analogue audio interfaces to allow for headphones to be connected to phones for example (although some phones use headphones/adaptors with inbuilt sound-cards which appear as USB devices). The audio adaptor accessory also allows the phone to be charged through the adaptor. This means the the device should not provide power on the Vbus pins which means no power for the Pi.

In order to test this I attempted to power the pi with a macbook charger and its e-marked cable and it didn't receive power. Two other chargers (a pixel 3 charger and an office electrics desk charger) where tested with the macbooks active cable and none powered the pi. When tested with a couple of non e-marked cables the pi was powered by all the chargers. This lines up with what is expected.

With regards to manufacturer limitations it is possible for chargers and devices to limit which devices they will use however this is only applicable for power deliver modes (higher voltages and currents) as the basic detection doesn't give scope for such communication to occur.

While this write-up focuses on units with detachable e marked cables as this has a clear set of detection steps when the CC lines are shorted. the problem could also happen with integrated cables if they are interfacing with both CC lines and dislike them being connected.

Now onto some solutions. Assuming the issue you are having is caused by the problem discussed above, using a non e-marked cable (most USB-C phone charger cables are likely this type) rather than an e-marked cable (many laptop charger/thunderbolt cables and any 5A capable cable will be in this category) will allow for the pi to be powered. In addition using older chargers with A-C cables or micro B to C adaptors will also work if they provide enough power as these don't require CC detection to provide power. Ultimately though the best solution in the long run will be for there to be a board revision for the pi 4 which adds the 2nd CC resistor and fixes the problem.

In conclusion. If you want your USB Type-C devices to work correctly then you need to have two independent CC resistors. If you are interested in adding Type-C connector to your project and don't want to read the whole spec to do so I have previously written a guide on how to do so.

Since this was published Eben Upton from the Raspberry pi foundation has commented that he expects this will be fixed in a future board revision in comments reported on Techrepublic, no word yet on timings on the release of this revision though.




USB-C is one of those things that generally everyone seems to agree on that it is a 'good thing', but is it really? In this first part of a series on USB-C, [Andreas Spiess] takes us through the theory of USB-C and USB Power Delivery (PD), as well as data transfer with USB-C cables. Even ignoring the obvious conclusion that with USB-C USB should now actually be called the 'Universal Parallel Bus' on account of its two pairs of differential data lines, there's quite a bit of theory and associated implementation details involved.

The Raspberry Pi 4B's wrong USB-C CC-pin configuration is a good teaching example.
Starting with the USB 2.0 'legacy mode' and the very boring and predictable 5 V power delivery in this mode, [Andreas] shows why you may not get any power delivered to a device with USB-C connector. Most likely the Downstream Facing Peripheral (DFP, AKA not the host) lacks the required resistors on the CC (Configuration Channel) pins, which are both what the other USB-C end uses to determine the connector orientation, as well as what type of device is connected.

This is where early Raspberry Pi 4B users for example saw themselves caught by surprise when their boards didn't power up except with some USB cables.

The saga continues through [Andreas]'s collection of USB-C cables, as he shows that many of them lack the TX/RX pairs, and that's before trying to figure out which cables have the e-marker chip to allow for higher voltages and currents.

On the whole we're still excited about what USB-C brings to the table, but the sheer complexity and number of variables make that there are a myriad of ways in which something cannot work as expected. Ergo Caveat Emptor.