Designing Conductor: Power — A Tale of Two Diodes

• Setting the Scene — Thanks USB
• Union Station — USB Hubs
• Conductor’s Path
  • The Human Effect
    • Scenario 1 — No Sweat
    • Scenario 2 — Flip Flop
    • Scenario 3 — En Garde
    • Following Directions — Diodes
  • Edge Cases
  • Unintentionally Two Hosts
  • Dual Role Devices
  • Turning Negatives Positive
    • Acceptable Risk and Imperfection
• Conclusion

In the first post of a new series focusing on the engineering of Conductor, I hope to explore the decision-making process behind how Conductor’s USB-C hub power delivery was implemented and the kinds of engineering considerations that go into such a choice. In this post, I am to example some key design concepts such as the fallibility of humans as well as how I view tradeoffs in design.

Setting the Scene — Thanks USB

Conductor provides a two-port USB-C hub allowing Conductor to act both as a device as well as hub. Different from some most other USB hubs on the market, Conductor exposes exclusively USB-C ports both for its upstream port (to the computer), and its downstream ports (any other connected devices).

USB-C presents an interesting challenge as it is a “universal” port—the first of its kind in the USB specification. Previously, USB ports were broken into “device” ports (think Micro-USB, Mini-USB, USB Type-B) and “host” ports (think USB Type-A). Therefore, one could easily look at either a connector or a device and know exactly what its role is. A “device” would typically use power, such as a mouse, keyboard, or external hard drive. Inversely, a “host” would typically supply power, such as a laptop, desktop, or power brick. The nature of the those ports and their standardization makes any cross-connection nearly impossible (barring unusual cabling such as Type-A to Type-A cables). A device (with a device connector) would draw power from a host (with a host connector) and there would not be any crossing of streams.

USB-C on the other hand is a universal connector. Both the device and the host share the identical oblong connector, with nothing to differentiate between whether it is a device or a host. As such, if one were looking at just the connector or port itself, one would have no idea whether it draws or supplies power. One would also have no idea whether it is a device or a host.

Union Station — USB Hubs

USB hubs exist in an interesting land between a host and a device. They effectively act as a central union station for a number of devices, and as such, they serve special functions. While we’re primarily looking at power today, I’ll discuss some other complexities in later posts in this series. On the power side, a USB hub is expected to act as a power distribution platform.

Every connected USB device (in normal function), expects to receive power from the USB hub in some form. For example, a keyboard and a mouse connected to the hub will expect to receive the typical +5 V power. The end device would have no idea whether its connected directly to the host or through a USB hub. Otherwise, the end device might not actually behave properly.

At the same time, the connected host end is expected to supply its power to the hub as well as the end devices. The host (from a power perspective)¹ should also not know if its connected to a hub or an end device, If such process is not transparent, the host itself may actually malfunction and be permanently damaged if low quality (some motherboards, cough).

Going back to the earlier section, I noted that a “device” is expected to draw power and a host is expected to supply power. This is ultimately the basic assumption we must go with when designing the power distribution platform then. If this process gets reversed—e.g., if power is being fed into the host—then the power distribution platform is broken. If the devices receive less power than they expect, the devices will malfunction as well.

Conductor’s Path

Conductor’s power design is simple: the host end supplies power to the two downstream device ports through a dedicated Schottky Barrier Diode each.

While simple, I’ll examine 4 considerations that were made for this architecture.

The Human Effect

While Conductor has its hubs clearly labeled as “Comp” and “Hub” (host and device), one must never underestimate the infinite wisdom or sheer carelessness of humans. While it may be the best of times or the blurst of times,² humans naturally make mistakes. Even the most careful person may accidentally connect a full desktop to a hub port. The universal nature of the USB-C connector (supra) makes this an extremely likely possibility as well, if one isn’t paying full attention.

What should happen in these situations then? First, let’s analyze the four possible “fault” scenarios:

1. A device on any end + a device on any end
2. A device on the host end + a host on the device end
3. A host on any end + a host on any end

We’ll assume, for now, a naked power distribution, connected only be “dumb” buses, with no directionality at all.

Scenario 1 — No Sweat

For this scenario, imagine you have two keyboards plugged into your hub and nothing else.

The nature of a device of that it “draws” power (supra). As such, if we have two devices connected only with nothing to supply power, both devices are powerless. Nothing would happen in this case. Therefore, this isn’t really a problem since nothing could potentially get damaged.

Scenario 2 — Flip Flop

In this case, we have a reversal of the expected power distribution. Typically, power flows from host end to device end. In this scenario though, because the host is supplying power at the device end, power has ended up flowing from device end to host end. Standing alone, this actually is not a problem, but rather just unexpected behavior. In fact, in a naked distribution platform, the power path of this scenario would actually work find, with a singular host supplying the power and the devices drawing it.

However, which physically fine, this goes against the expectation that the host end always supplies power and the device end always draws power. Therefore, while actually alright, we should still prevent this scenario to avoid breaking our expectations of how something is supposed to function.

Scenario 3 — En Garde

In this scenario, imagine you have two desktops both plugged into the hub and nothing else.

In the third fault scenario, we have two clashing sources of power. In a naked power distribution path, this creates two conflicting voltages between the hosts connected. As no host can ever delivers a perfect +5 V power at all times. Therefore, there will always be a voltage differential between the two hosts. Where there is a voltage differential, current flows from high to low. Therefore, the host at a lower voltage would actually receive current in.

Higher quality hosts would typically be aware of this possibility and implement some from of “reverse current protection” into their USB-C port. However, one should never assume protection, because if it isn’t there, you are left naked in the dirt. While a customer may understand they screwed up by plugging in two desktops together, they will certainly not be happy if their motherboard is fried from that. Therefore, thinking as an engineer, one should actually build in the protection to prevent this.

Following Directions — Diodes

Now that we’ve laid out the three potential fault scenarios, we understand that we need directionality control of the power to ensure that power only flows from host end to device end. Diodes are the perfect component to use in this scenario, effectively, the one-way valves of electronics. Thus, we know that we need at least one diode between the host and device end making sure that power flows only one way.

Why does Conductor then use two diodes after the split instead of one diode before the split? It would save on board space, BOM cost, assembly cost, and overall simply the design just a little. Because, diodes have a pesky thing called “forward voltage drop.”

Every single diode has a measurable amount of “forward voltage drop”, also known as Vd.³ The voltage out of a diode will always be less than the voltage put into the diode, by the forward voltage drop. Vd though is not a constant number but instead scales with current. A higher current will result in a higher forward voltage drop and a lower output voltage for a given input. Therefore, pulling only 10mA from a single diode would cause less Vd than pulling 100mA and would therefore give a higher output voltage. All diodes do have a minimum Vd though, so even pulling 1mA would result in a measurable drop.

Remember a few sections ago that I mentioned devices expect to see +5 V power available. While this is true, the number is more of a range, between 4.4V and 5.25V on a host/hub. Similarly, the USB specification requires devices to tolerate a maximum 350 mV voltage drop within a hub, but best practice is to limit this drop.⁴

Because Conductor has a 2 port hub, two devices which draw current can potentially be connected at one time. This current draw is added together in determining the forward voltage drop if using a single diode. If using two separate diodes though, each diode only sees a single device worth of current and would thus exhibit a lower Vd. Since the goal here is to minimize the total forward voltage drop overall, an independent diode for each device end would offer the best of both worlds here. While ultimately we are trading off reduced BOM cost and reduced assembly cost, we are improving the design slightly to better comport with expected behavior.

Edge Cases

An important concept in good quality assurance of an engineered design is thinking through edge cases that may arise. Below I discuss the important ones.

Unintentionally Two Hosts

Imagine a scenario where we unintentionally have two hosts connected together, both plugged into the device end of the hub. With the two-diode configuration, power from each host is stopped before it even has a chance to make it to the other host. Therefore, we eliminate any possibility of damage in this edge case.

Dual Role Devices

So far, I’ve discussed hosts and devices as if they are independent and every USB-compatible object fits neatly into one category or another. This used to be the case with different connectors being completely reserved for different functions. However, with the advent of USB-C’s universal port, this assumption has actually been broken down.

Nowadays, electronics have the potential to act as a “dual role device,” a confusing moniker effectively meaning the item can either be a device or a host depending on what’s needed. For example, looking at the Apple iPad Pro, it has a USB-C port. It can be used as host, such that you can connect a keyboard or a mouse to it and use the iPad like it were a computer. At the same time, it can act like a device, such that you can connect it to a computer and sync data or charge the iPad. Effectively then, we have no way of readily determining ahead of time whether the iPad will act as a device or as a host.

How do we deal with this then? From what we know now, if we connect a desktop to the host end and an iPad to device end, will we end up backfeeding power into the iPad and potentially damaging it? Luckily, the answer here is no, thanks for the help of the USB-C Configuration Channel.

USB-C Configuration Channel (CC) is passive configuration which uses pull-up or pull-down resistors to instruct connected devices over USB-C whether to act as a device or as a host, if they are dual-role. A dual role device should not supply any power until it has finished the configuration through the CC resistors (practically instantaneously). A device should have two CC pull-down resistors while a host should have two CC pull-up resistors. If a dual role device detects a pull-up resistors when connected, it will begin to function as a device and “draw” power rather than supply it. If it detects pull-down resistors when connected, it will begin to supply power and act as a host.

Here, note that we want the device ends to be recognized as a host. In effect, we want the hub to be transparent in power even on the CC channel. Effectively, we want the iPad to see itself as connected directly to something like a Macbook. Therefore, Conductor should expose two pull-up CC resistors on the device end. Then, when something like an iPad is connected to Conductor, it will see that Conductor is actually a host and therefore will switch itself into device mode.

Turning Negatives Positive

Astute readers may actually have already noticed, I haven’t addressed what would happen if you have, for example, two desktops connected, one in the host end and one in the device end. I already touched on that if both were in the device end, the dual-diode architecture would prevent anything negative. What about if one was on the host end though? If Desktop 1 (on the host end) is putting out a solid 5 V output, and Desktop 2 (on the device end) is putting out a slightly droopy 4.9 V output, power would end up flowing from Desktop 1 to Desktop 2 (as if Desktop 2 was a device), potentially damaging Desktop 2.

Remember that pesky little forward voltage drop from earlier though? It used to be a negative, but we may actually be able to leverage it was a positive in this scenario. Note that voltage past a diode will always be less than what is put in. Therefore, if we put in 5 V, we may actually only end up with 4.8 V out. How is this useful to us?

Say Desktop 1 is spitting out 5 V, and Desktop 2 is spitting out 4.9 V. Let’s assume our diode has a Vd of around 200 mV or 0.2 V. Therefore, in the architecture that Conductor uses, the voltage after the diode that Desktop 2 sees is only 4.8 V. Power flows from high to low, so Desktop 2 will try to push power in, since it is at a higher 4.9 V. The presence of a diode will block that though, and therefore no power will flow at all. The devices will effectively be power-silo’ed from each other, with the forward voltage drop of the diode actually acting as a silo wall.

Acceptable Risk and Imperfection

The above example I gave is actually stylized to not show the “worst-case” scenario. As mentioned, the USB 2.0 specification allows a power to supply anywhere from 5.25 V to 4.4 V. Let’s build up the worst-case scenario then. Desktop 1 has a “hot” port spitting out 5.25 V and Desktop 2 is exceptionally droopy, spitting out only 4.4 V. The diode maintains the same Vd of 200 mV. In this case, post-diode, Desktop 2 would see a voltage of 5.05 V, much higher than its voltage of 4.4 V, and thus power would flow into Desktop 2. This, again is a breakdown of our intended case. Even with Vd ramping up at higher current levels, to potentially 400 mV, it still will not bridge the gap.

In engineering, a critical battle waged for eons is that between cost and effectiveness. One may build the world’s first bridge that would never collapse, but at what cost? An F-35 is incredibly reliable but costs hundreds of millions for one. On the other hand, that toy from Dollar Tree may be cheap but it only lasts three days. At the end of the day, reliability and quality costs and what are we willing to pay?

We come to the idea now of an “acceptable risk” or the idea of what level of risk of problems are we willing to accept for a reduced cost. While it may be possible to prevent the kind of “worst-case” scenario I described using a complex system of voltage monitors and MOSFETs to direct power, doing so will exponentially increase the cost of the device and increase the cost of complexity. Before we do that, we really should look at the level of risk we take on, if we don’t do it.

Given the stylized scenario I proposed with the fictitious diode, we can already withstand a voltage differential of 200 mV from host to device end. The overwhelming majority of USB hosts do actually spit out a fairly reasonable 5 V power rail to comply with the USB specifications with the help of Linear Dropout Regulators (LDOs) at each USB’s output typically. The likelihood that one USB port will differ from another more than 200 mV is exceptionally rare given the age and maturity of USB architecture.⁵

Ultimately, this design was a tradeoff between risk and cost. The risk here that devices create a voltage differential of more than 200 mV is slight, and the cost to prevent this scenario is large. Therefore, if we put on both our engineer caps and our business caps here, it seems more reasonable to not worry this worst-case scenario. Just as one does not prepare for an army of three legged monkeys wearing velvet clown suits to storm the nearest Target in hopes of finding a purple banana, one does not prepare for the most remotest of possibilities in engineering.

Conclusion

In this post, I examined the nature of designing the power distribution plane of Conductor and the how even two simple diodes may have a slew of considerations if fully thought out. While some benefits may have been incidental or as lucky result of a choice, when designing products, it’s important to keep in mind how the end user may behave, any and all potential edge cases, as well as ultimately the level of risk that one is truly comfortable with delivering.

In the following posts, I hope to examine some other elements of Conductor’s design such as the USB data-line implementation and the idea of “usecase.”