Several customers have asked us whether or not a USB hub or a USB switch is right for their USB testing or control application. There are important and distinctive differences between these two classes of devices, both architecturally and functionally. In many cases, both devices can be used in the same system to complement one another to achieve the required system functionality.
In this blog post, we will cover the functional and architectural differences between USB hubs and USB switches, using the specific example of CarPlay-capable devices.
A USB hub is a 1:N device that takes one upstream-facing USB connection and then shares it concurrently with several (N) downstream devices. Figure 1 below shows a simple example of a hub.
Figure 1: Simple diagram of a 1:4 USB hub
It is best to use a hub when you need to access multiple attached devices concurrently (Figure 2). The multiple devices attached to the hub are all available at the same time, but will collectively share the bandwidth of the single upstream connection (Figure 3).
Figure 2: USB host can access devices A, B, C and D concurrently
Figure 3: Downstream devices sharing the collective upstream bandwidth
Hubs are more complex devices than switches from a data handling standpoint. Since a USB hub must recognize multiple devices concurrently, it must keep context for data transfers to and from each device. In order to achieve this, the hub terminates the connection from the USB host, deconstructs USB data packets and routes the data packets to and from the appropriate individual devices. Finally, it will then re-transmit the properly routed USB traffic to the downstream devices. Figure 4 shows an example of a host transferring data through a hub to several devices concurrently.
Figure 4: Example of data routing and bandwidth sharing by a hub
In a hub, the internal hardware (a USB hub IC) typically requires that only upstream-facing protocols be present on one side and downstream facing protocols on the other. This is also indicated by the fixed types of external USB connectors on the hub.
The fixed roles of the internal silicon also mean that only USB hosts can be connected to the upstream-facing port and only USB devices can be connected to the downstream-facing port(s). Connecting a USB host to a downstream-facing port will result in the hub not being able to communicate over that downstream-facing port. Similar results occur when attaching a USB device to an upstream facing port as shown in Figure 5:
Figure 5: Upstream and downstream ports of a USB hub
CarPlay Example using USB hub
This can create a challenge for applications where the device may change roles from a USB device to becoming a USB host. CarPlay-enabled phones are an example of devices which exhibit this behavior. In CarPlay, the phone changes roles from a USB device to a USB host so that it has control of the car’s infotainment system. The infotainment system likewise changes roles from a USB host to a USB device.
Consider Figure 6 below: a CarPlay-enabled automotive infotainment system connected to a traditional USB hub and then to a CarPlay-enabled phone. The CarPlay protocol will not be successful as the traditional USB hub cannot not recognize the phone as a USB host or the infotainment system as a USB device (Figure 7).
Figure 6: Phone connected to infotainment system via traditional USB hub
Figure 7: Traditional hubs cannot support role reversal of CarPlay protocol
A USB switch is a 1:N or N:1 device which makes a selective connection between its Common port and one selected channel. This creates a direct and dedicated connection from the Common port to the selected device. The multiple devices attached to the switch can only be accessed one at a time, but the actively selected device receives the full bandwidth of the host that it is attached to.
Figure 8: Example of a 4-channel USB switch
It is best to use a switch when you need to make a direct and dedicated connection to one device, like a cable that can be moved from one device to another.
Figure 9: The USB host can access only the selected device, Device A
The multiple devices attached to the switch can only be accessed one at a time, but the actively selected device receives the full bandwidth of the host that it is attached to.
Figure 10: The selected device receives full bandwidth of the connection
Figure 11: USB switch showing dedicated data flow, similar to a cable connection
The internal hardware of a selector switch is typically protocol agnostic and does not have any context for upstream-facing protocols or downstream facing protocols on either side, thereby making the switch bi-directional.
This bi-directional behavior also means that USB devices can be connected to either side arbitrarily, depending on whether you require a 1:N or an N:1 configuration.
Figure 12: Bidirectional connections in a USB switch
CarPlay Example using USB switch
Let’s re-consider the CarPlay hub example, but instead, using a USB switch (Figure 13). The CarPlay-capable automotive infotainment system connected to a bi-directional USB switch and then to a CarPlay-enabled phone. The CarPlay protocol will complete successfully as the bi-directional switch acts like a direct connection between the infotainment system and the phone. USB protocol can pass freely and devices are able to change roles if the protocol mandates it (Figure 14).
Figure 13: Phone connected to infotainment system via USB switch
Figure 14: Bi-directional switch can support USB host/device role reversal of CarPlay protocol