Patent Description:
The present disclosure generally relates to electronic devices with wired communications capabilities, and more specifically to methods and devices for routing Controller Area Network (CAN) traffic over a Universal Serial bus (USB) connection.

A telematics system may gather asset data using a telematics device. The asset may be a vehicle ("vehicular asset") or some stationary equipment. In the case of a vehicular asset, the telematics device may gather the asset data through an onboard diagnostic port (OBD) using the Controller Area Network (CAN) protocol. Additionally, the telematics device may gather sensor data and location data pertaining to the asset. The gathered asset data, sensor data and location data may be received and recorded by a technical infrastructure of the telematics system, such as a telematics server, and used in fleet management tools, telematics services, or data analysis.

An electronic device, such as a telematics device, may connect with peripheral devices which provide additional capabilities. Such peripheral devices may communicate with the electronic device using one or more protocols such as the CAN protocol and the Universal Serial Bus (USB). Patent publications
<CIT>, <CIT>, and <CIT> discuss information that is useful for understanding the background of the invention.

The present invention is defined by the method and the host electronic device according to the appended independent claims. Preferred embodiments are set out in the appended dependent claims. In one aspect of the present disclosure, there is provided a method by a host electronic device that supports both a Universal Serial Bus (USB) protocol and a Controller Area Network (CAN) protocol. The method comprises determining whether a peripheral electronic device connected to the host electronic device is using CAN or using USB. In response to determining that the peripheral electronic device is using CAN, the method includes causing a switch to pass at least one alternate mode signal to a CAN transceiver. In response to determining that the peripheral electronic device is using USB, the method includes commencing communication using the USB protocol over a plurality of USB signal lines. Advantageously, the host electronic device can use either CAN or USB.

Determining whether the peripheral electronic device is using CAN or using USB comprises isolating the peripheral electronic device from a bus voltage line, connecting a USB signal line of the plurality of USB signal lines to the bus voltage line via a pull-up resistor, and determining a digital value of a voltage of the USB signal line. Isolating the peripheral electronic device ensures that the peripheral electronic device is not damaged when the USB signal line is connected to the bus voltage line. The digital value of the voltage of the USB signal line gives an indication as to whether the peripheral electronic device uses USB or CAN. Advantageously, when there are only two possibilities; USB or CAN, this method can determine that the peripheral electronic device is not USB, i.e., CAN. The determination is made without the need for a CAN peripheral electronic device implementing any special USB port functions, such as alternate mode messaging and negotiation.

Isolating the peripheral electronic device from the bus voltage line may comprise opening a bus power switch between the bus voltage line and the peripheral electronic device.

Connecting the USB signal line to the bus voltage line may comprise enabling a USB signal switch between the USB signal line and the pull-up resistor.

The USB signal line comprises a D+ signal line or a D- signal line.

Determining the digital value of the voltage of the USB signal line may comprise converting the voltage of the USB signal line to a digital value using an analog-to-digital converter (ADC).

Determining that the peripheral electronic device is using CAN comprises determining that the digital value is equal to a bus voltage (Vbus) of the bus voltage line.

Determining that the peripheral electronic device is using USB comprises determining that the digital value is lower than a bus voltage (Vbus) of the bus voltage line.

In another aspect of the present disclosure, there is provided a host electronic device. The host electronic device comprises a controller, a Universal Serial Bus Type-C (USB-C) connector, a controller area network (CAN) transceiver, a switch coupled to the controller the switch connecting the CAN transceiver with the USB-C connector, a USB-C port connected with a plurality of USB signal lines of the USB-C connector, an impedance detection circuit coupled to the controller and connected with the plurality of USB signal lines, and a memory coupled to the controller. The memory stores machine-executable programming instructions which, when executed by the controller, configure the host electronic device to determine whether a peripheral electronic device connected to the host electronic device is using CAN or USB. In response to determining that the peripheral electronic device is using CAN, the machine-executable programming instructions configure the host electronic device to cause a switch to pass at least one alternate mode signal to a CAN transceiver. In response to determining that the peripheral electronic device is using USB, the machine-executable programming instructions configure the host electronic device to commence communication using a USB protocol over a plurality of USB signal lines. Advantageously, the host electronic device can use either CAN or USB.

The machine-executable programming instructions which configure the host electronic device to determine whether the peripheral electronic device is using CAN or using USB comprise machine-executable programming instructions which configure the host electronic device to isolate the peripheral electronic device from a bus voltage line, connect a USB signal line of the plurality of USB signal lines to the bus voltage line via a pull-up resistor, and determine a digital value of a voltage of the USB signal line. Isolating the peripheral electronic device ensures that the peripheral electronic device is not damaged when the USB signal line is connected to the bus voltage line. The digital value of the voltage of the USB signal line gives an indication as to whether the peripheral electronic device uses USB or CAN. Advantageously, when there are only two possibilities; USB or CAN, this method can determine that the peripheral electronic device is not USB, i.e., CAN. The determination is made without the need for a CAN peripheral electronic device implementing any special USB port functions, such as alternate mode messaging and negotiation.

The machine-executable programming instructions which configure the host electronic device to isolate the peripheral electronic device from a bus voltage line may comprise machine-executable programming instructions which configure the host electronic device to open a switch between the bus voltage line and the peripheral electronic device.

The machine-executable programming instructions which configure the host electronic device to connect a USB signal line of the plurality of USB signal lines to the bus voltage line via a pull-up resistor may comprise machine-executable programming instructions which configure the host electronic device to enable a USB signal switch between the USB signal line and the pull-up resistor.

The machine-executable programming instructions which configure the host electronic device to determine the digital value of the voltage of the USB signal line may comprise machine-executable programming instructions which configure the host electronic device to convert the voltage of the USB signal line to a digital value using an analog-to-digital converter (ADC).

The machine-executable programming instructions which configure the host electronic device to determine that the peripheral electronic device is using CAN may comprise machine-executable programming instructions which configure the host electronic device to determine that the digital value is equal to a bus voltage (Vbus) of the bus voltage line.

The machine-executable programming instructions which configure the host electronic device to determine that the peripheral electronic device is using USB may comprise machine-executable programming instructions which configure the host electronic device to determine that the digital value is lower than a bus voltage (Vbus) of the bus voltage line.

Exemplary non-limiting embodiments of the present invention are described with reference to the accompanying drawings in which:.

The present disclosure relates generally to methods and devices for routing Controller Area Network (CAN) data over a Universal Serial Bus (USB) connection. The methods and devices also allow for routing USB data over the same USB connection. The USB connection used in the methods and devices is a USB Type C ("USB-C") connection.

A first method is provided for routing CAN data over a USB Type-C port (USB-C port) by utilizing the USB-C alternate mode provided by the USB-C standard. In the first method, a host electronic device expects a peripheral device connected therewith to send at least one configuration message thereto indicating that the peripheral electronic device uses the CAN protocol. In response to receiving the configuration message, the host electronic device enables USB-C alternate mode, and commences communication with the peripheral electronic device using the CAN protocol over USB-C alternate mode signal lines of the USB interface.

In one implementation of the first method, the peripheral electronic device contains a USB configuration channel controller (sometimes also referred to as the "configuration channel logic block") which communicates with a USB configuration channel controller (CCC) of the host electronic device. In this disclosure, a USB configuration channel controller is referred to as a "configuration channel controller. " The configuration channel controller of the peripheral electronic device sends the at least one configuration message indicating, to the host electronic device, that the peripheral electronic device uses the CAN protocol.

In another implementation of the first method, the peripheral electronic device is a CAN peripheral electronic device, which does not contain a configuration channel controller and only provides CAN signals via an external connector thereof. In such an implementation, an interface converter is needed to connect the peripheral interface device to the USB port of the host interface device, and to provide the at least one configuration message indicating that the peripheral electronic device uses the CAN protocol. The interface converter is described below.

The first method described briefly above provides connecting a CAN peripheral electronic device to a host electronic device that supports both the USB protocol and the CAN protocol. The first method utilizes the alternate mode available in the USB Type-C specification. Advantageously, a host electronic device supporting the first method is still in compliance with the USB standard.

In another aspect of the present disclosure, there is provided an interface converter and a method by the interface converter for connecting a CAN peripheral electronic device to a host electronic device over a USB-C connection. The interface converter has a CAN interface that receives CAN signals via a first connector. The interface converter also has a USB interface providing USB signals via a USB-C connector. The interface converter has a configuration controller for communicating with the configuration channel controller of a USB host electronic device and for sending at least one configuration message thereto indicating that the interface converter is a CAN device using USB-C alternate mode. The configuration channel controllers of the interface converter and the host electronic device thus negotiate an alternate mode in which the interface converter routes CAN signals over USB signal lines that are designated for use in USB-C alternate mode, and the host electronic device receives and interprets the CAN signals on those USB signal lines.

The interface converter has the advantage that a peripheral electronic device using the CAN protocol does not need to implement any additional USB circuitry for enabling USB-C alternate mode to communicate with the host electronic device. Any CAN peripheral electronic device may connect to a USB-C host electronic device via the interface converter. Accordingly, the cost of purchasing the interface converter is only incurred when connecting a CAN peripheral electronic device. A USB peripheral electronic device may directly connect to the host electronic device and work in USB mode.

In some implementations, the USB signal lines used for routing CAN signals in USB-C alternate mode are the sideband-use (SBU) signal lines. Specifically the signals CAN+ or CAN High (aka CANH) and CAN- or CAN Low (aka CANL) are routed over the USB signal lines SBU1 and SBU2, as will be described below.

In another aspect of the present disclosure, a second method by a host electronic device is provided for detecting whether a peripheral electronic device connected to a USB-C connector of the USB host electronic device uses the CAN protocol or the USB protocol. The method includes the host electronic device measuring the impedance of a number of signals on the USB-C signal lines of the USB-C connector thereof to identify the type of peripheral electronic device connected to the USB-C connector.

In some implementations of the second method, the USB signal lines are first checked to determine whether the peripheral electronic device connected to the USB-C connector uses the USB protocol or another non-USB protocol, such as the CAN protocol. For example, a host electronic device may measure the impedance of USB signal lines D+/D- on the USB-C connector. If the impedance indicates that the USB signal lines are in use, then the host electronic device determines that the peripheral electronic device uses the USB protocol. In some embodiments, if the impedance on the USB signal lines D+ and D- indicate that the peripheral electronic device does not use the USB protocol, the host electronic device may conclude that the peripheral electronic device uses the CAN protocol. This may be the case if older USB protocols using the D+/D- signal lines are the only ones supported and the only other possible protocol is the CAN protocol.

In some implementations of the second method, the host electronic device alternatively or additionally checks signal lines which are not used by the USB protocol and may be used by the CAN protocol. For example, if the CAN signals are routed through the sideband-use signal lines on the USB-C connector, then the host electronic device measures the impedance on the sideband-use signal lines. If the impedance measured on the sideband-use indicates that the sideband-use signals are used then the host electronic device determines that the peripheral electronic device uses the CAN protocol.

If the host electronic device determines that the peripheral electronic device uses the USB protocol, then the controller enables USB host mode and the host electronic device negotiates a USB connection with the peripheral electronic device as known in the art.

If the host electronic device determines that the peripheral electronic device uses the CAN protocol, then the controller disables USB interface circuitry and routes the sideband-use signals to a CAN interface module. The CAN interface module conditions the CAN signal levels so they can be processed by a controller of the host electronic device. The CAN interface module provides digital signals to the controller for processing.

This disclosure describes the above methods and devices in the context of a telematics device and an input/output expander that connects thereto. However, it should be apparent to those of skill in the art that the methods and devices described herein are not limited by this context. The methods and devices described herein can be used by any USB host electronic device so that it may accept connections from a peripheral electronic device that uses the CAN protocol. A telematics system employing a telematics device is described below as an example of an application of a telematics device.

A large telematics system may collect data from a high number of assets, either directly or through telematic devices. A telematics device may refer to a self-contained device installed at an asset, or a telematics device that is integrated into the asset itself. In either case, it may be said that telematics data is being captured or gathered by the telematics device. <FIG> shows a high-level block diagram of a telematics system <NUM>. The telematics system <NUM> includes a telematics server <NUM>, (N) telematics devices shown as telematics device 200_1, telematics device 200_2. through telematics device 200_N ("telematics device <NUM>"), a network <NUM>, administration terminal <NUM>, and operator terminals 150_1, 150_2. through 150_N ("the operator terminals <NUM>"). <FIG> also shows a plurality of (N) assets named as asset 100_1, asset 100_2. asset 100_N ("asset <NUM>") coupled to the telematics device 200_1, telematics device 200_2. telematics device 200_N, respectively. Additionally, <FIG> shows a plurality of satellites 170_1, 170_2 and 170_3 ("the satellites <NUM>") in communication with the telematics devices <NUM> for facilitating navigation.

The assets <NUM> shown are in the form of vehicles. For example, the asset 100_1 is shown as a truck, which may be part of a fleet that delivers goods or provides services. The asset 100_2 is shown as a passenger car that typically runs on an internal combustion engine (ICE). The asset 100_3 is shown as an electric vehicle (EV). Other types of vehicles, which are not shown, are also contemplated in the various embodiments of the present disclosure, including but not limited to, farming vehicles, construction vehicles, military vehicles, and the like.

The telematics devices <NUM> are electronic devices which are coupled to assets <NUM> and configured to capture asset data from the assets <NUM>. For example, in <FIG> the telematics device 200_1 is coupled to the asset 100_1. Similarly, the telematics device 200_2 is coupled to the asset 100_2 and the telematics device 200_3 is coupled to the asset 100_3. The components of a telematics device <NUM> are explained in further detail with reference to <FIG>.

The network <NUM> may be a single network or a combination of networks such as a data cellular network, the Internet, and other network technologies. The network <NUM> may provide connectivity between the telematics devices <NUM> and the telematics server <NUM>, between the administration terminal <NUM> and the telematics server <NUM>, and between the operator terminals <NUM> and the telematics server <NUM>.

The telematics server <NUM> is an electronic device executing machine-executable programming instructions which enable the telematics server <NUM> to store and analyze telematics data. The telematics server <NUM> may be a single computer system or a cluster of computers. The telematics server <NUM> may be running an operating system such as Linux, Windows, Unix, or any other equivalent operating system. Alternatively, the telematics server <NUM> may be a software component hosted on a cloud service, such as Amazon Web Service (AWS). The telematics server <NUM> is connected to the network <NUM> and may receive telematics data from the telematics devices <NUM>. The telematics server <NUM> may have a plurality of software modules for performing data analysis and analytics on the telematics data to obtain useful asset information about the assets <NUM>. The telematics server <NUM> may be coupled to a telematics database <NUM> for storing telematics data and/or the results of the analytics which are related to the assets <NUM>. The asset information stored may include operator information about the operators <NUM> corresponding to the assets. The telematics server <NUM> may communicate the asset data and/or the operator information pertaining to an asset <NUM> to one or more of: the administration terminal <NUM>, and the operator terminal <NUM>.

The satellites <NUM> may be part of a global navigation satellite system (GNSS) and may provide location information to the telematics devices <NUM>. The location information may be processed by a location module on the telematics device <NUM> to provide location data indicating the location of the telematics device <NUM> (and hence the location of the asset <NUM> coupled thereto). A telematics device <NUM> that can periodically report an asset's location is often termed an "asset tracking device".

The administration terminal <NUM> is an electronic device, which may be used to connect to the telematics server <NUM> to retrieve data and analytics related to one or more assets <NUM> or to issue commands to one or more telematics device <NUM> via the telematics server <NUM>. The administration terminal <NUM> is shown as a laptop computer, but may also be a desktop computer, a tablet (not shown), or a smartphone. The administration terminal <NUM> may run a web browser or a custom application which allows retrieving data and analytics, pertaining to one or more assets <NUM>, from the telematics server <NUM> via a web interface of the telematics server <NUM>. The administration terminal <NUM> may also be used to issue commands to one or more telematics device <NUM> via the telematics server <NUM>. A fleet manager <NUM> may communicate with the telematics server <NUM> using the administration terminal <NUM>. In addition to retrieving data and analytics, the administration terminal <NUM> allows the fleet manager <NUM> to set alerts and geofences for keeping track of the assets <NUM>, receiving notifications of deliveries, and so on.

The operator terminals <NUM> are electronic devices, such as smartphones or tablets. The operator terminals <NUM> are used by operators <NUM> (for example, vehicle drivers) of the assets <NUM> to both track and configure the usage of the assets <NUM>. For example, as shown in <FIG>, the operator 10_1 has the operator terminal 150_1, the operator 10_2 has the operator terminal 150_2, and the operator 10_N has the operator terminal 150_N. Assuming the operators <NUM> all belong to a fleet of vehicles, each of the operators <NUM> may operate any of the assets <NUM>. For example, <FIG> shows that the operator 10_1 is associated with the asset 100_1, the operator 10_2 is associated with the asset 100_2, and the operator 10_N is associated with the asset 100_N. However, any operator <NUM> may operate any asset <NUM> within a particular group of assets, such as a fleet. The operator terminals <NUM> are in communication with the telematics server <NUM> over the network <NUM>. The operator terminals <NUM> may run at least one asset configuration application. The asset configuration application may be used by operator <NUM> to inform the telematics server <NUM> that asset <NUM> is currently being operated by operator <NUM>. For example, the operator 10_2 may use an asset configuration application on the operator terminal 150_2 to indicate that the operator 10_2 is currently using the asset 100_2. The telematics server <NUM> updates the telematics database <NUM> to indicate that the asset 100_2 is currently associated with the operator 10_2. Additionally, the asset configuration application may be used to report information related to the operation duration of the vehicle, the number of stops made by the operator during their working shift, and so on. Furthermore, the asset configuration application may allow the operator to configure the telematics device <NUM> coupled to the asset <NUM> that the operator <NUM> is operating.

In operation, a telematics device <NUM> is coupled to an asset <NUM> to capture asset data. The asset data may be combined with location data obtained by the telematics device <NUM> from a location module in communication with the satellites <NUM> and/or sensor data gathered from sensors in the telematics device <NUM> or another device coupled to the telematics device <NUM>. The combined asset data, location data, and sensor data may be termed "telematics data. " The telematics device <NUM> sends the telematics data to the telematics server <NUM> over the network <NUM>. The telematics server <NUM> may process, aggregate, and analyze the telematics data to generate asset information pertaining to the assets <NUM> or to a fleet of assets. The telematics server <NUM> may store the telematics data and/or the generated asset information in the telematics database <NUM>. The administration terminal <NUM> may connect to the telematics server <NUM>, over the network <NUM>, to access the generated asset information. Alternatively, the telematics server <NUM> may push the generated asset information to the administration terminal <NUM>. Additionally, the operators <NUM>, using their operator terminals <NUM>, may indicate to the telematics server <NUM> which assets <NUM> they are associated with. The telematics server <NUM> updates the telematics database <NUM> accordingly to associate the operator <NUM> with the asset <NUM>. Furthermore, the telematics server <NUM> may provide additional analytics related to the operators <NUM> including work time, location, and operating parameters. For example, for vehicle assets, the telematics data may include turning, speeding, and braking information. The telematics server <NUM> can correlate the telematics data to the vehicle's driver by querying the telematics database <NUM>. A fleet manager <NUM> may use the administration terminal <NUM> to set alerts for certain activities pertaining to the assets <NUM>. When criteria for an alert is met, the telematics server <NUM> sends a message to the administration terminal <NUM> to notify a fleet manager <NUM>, and may optionally send alerts to the operator terminal <NUM> to notify an operator <NUM> of the alert. For example, a vehicle driver operating the vehicle outside of a service area or hours of service may receive an alert on their operator terminal <NUM>. A fleet manager <NUM> may also use the administration terminal <NUM> to configure a telematics device <NUM> by issuing commands thereto via the telematics server <NUM>. Alerts may also be sent to the telematics device <NUM> to generate an alert to the driver such as a beep, a displayed message, or an audio message.

Further details relating to the telematics device <NUM> and how it interfaces with an asset <NUM> are shown with reference to <FIG> depicts an asset <NUM> and a telematics device <NUM> coupled thereto. Selected relevant components of each of the asset <NUM> and the telematics device <NUM> are shown.

The asset <NUM> may have a plurality of electronic control units (ECUs). An ECU is an electronic module which interfaces with one or more sensors for gathering information from the asset <NUM>. For example, an engine coolant temperature (ECT) ECU may contain a temperature sensor and a controller for converting the measured temperature into digital data representative of the oil temperature. Similarly, a battery voltage ECU may contain a voltage sensor for measuring the voltage at the positive battery terminal and a controller for converting the measured voltage into digital data representative of the battery voltage. A vehicle may, for example, have around seventy ECUs. For simplicity, only a few of the ECUs <NUM> are depicted in <FIG>. For example, in the depicted embodiment the asset <NUM> has three ECUs shown as the ECU 110A, the ECU 110B, and the ECU 110C ("the ECUs <NUM>"). The ECU 110A, the ECU 110B, and the ECU 110C are shown to be interconnected via an asset communications bus. One example of an asset communications bus is a Controller Area Network (CAN) bus. For example, in <FIG> the ECUs <NUM> are interconnected using the CAN bus <NUM>. The ECUs <NUM> send and receive information to one another in CAN data frames by placing the information on the CAN bus <NUM>. When an ECU <NUM> places information on the CAN bus <NUM>, other ECUs <NUM> receive the information and may or may not consume or use that information. Different protocols may be used to exchange information between the ECUs over a CAN bus. For example, ECUs <NUM> in trucks and heavy vehicles use the Society of Automotive Engineering (SAE) J1939 protocol to exchange information over a CAN bus <NUM>. Most passenger vehicles use the SAE J1979 protocol, which is commonly known as On-Board Diagnostic (OBD) protocol to exchange information between ECUs <NUM> on their CAN bus <NUM>. In industrial automation, ECUs use a CANOpen protocol to exchange information over a CAN bus <NUM>. An asset <NUM> may allow access to information exchanged over the CAN bus <NUM> via an interface port <NUM>. For example, if the asset <NUM> is a passenger car, then the interface port <NUM> is most likely an OBO-II port. Data accessible through the interface port <NUM> is termed the asset data <NUM>. In some embodiments, the interface port <NUM> includes a power interface for providing electric power to a telematics device <NUM> connected thereto.

The telematics device <NUM> includes a controller <NUM> coupled to a memory <NUM>, an interface layer <NUM> and a network interface <NUM>. The telematics device <NUM> also includes one or more sensors <NUM> and a location module <NUM> coupled to the interface layer <NUM>. The telematics device <NUM> may also contain some optional components, shown in dashed lines in <FIG>. For example, the telematics device <NUM> may contain one or more of: an I/O expander port <NUM>, a near-field communications (NFC) module such as NFC module <NUM>, and a short-range wireless communications module <NUM>. In some embodiments (not shown), the telematics device <NUM> may have a dedicated power source or a battery. In other embodiments, the telematics device <NUM> may receive power directly from the asset <NUM>, via the interface port <NUM>. The telematics device <NUM> shown is an example. Some of the components shown in solid lines may also be optional and may be implemented in separate modules. For example, some telematics devices (not shown) may not have a location module <NUM> and may rely on an external location module for obtaining the location data <NUM>. Some telematics devices may not have any sensors <NUM> and may rely on external sensors for obtaining sensor data <NUM>.

The controller <NUM> may include one or any combination of a processor, microprocessor, microcontroller (MCU), central processing unit (CPU), processing core, state machine, logic gate array, application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), or similar, capable of executing, the actions performed by the controller <NUM> as described herein. The controller <NUM> may have an internal memory for storing machine-executable programming instructions to conduct the methods described herein.

The memory <NUM> may include read-only-memory (ROM), random access memory (RAM), flash memory, magnetic storage, optical storage, and similar, or any combination thereof, for storing machine-executable programming instructions and data to support the functionality described herein. The memory <NUM> is coupled to the controller <NUM> thus enabling the controller <NUM> to execute the machine-executable programming instructions stored in the memory <NUM> and to access the data stored therein. The memory <NUM> may be storing machine-executable programming instructions, which when executed by the controller <NUM>, configures the telematics device <NUM> for receiving asset data <NUM> from the asset <NUM> via the asset interface <NUM>, and for receiving sensor data <NUM> from the sensors <NUM> and/or location data <NUM> from the location module <NUM> via the sensor interface <NUM>. The memory <NUM> may also contain machine-executable programming instructions for combining asset data <NUM>, sensor data <NUM> and location data <NUM> into telematics data <NUM>. Additionally, the memory <NUM> may further contain instructions which, when executed by the controller <NUM>, configures the telematics device <NUM> to transmit the telematics data <NUM> via the network interface <NUM> to a telematics server <NUM> over a network <NUM>. In some embodiments, the memory <NUM> only stores data, and the machine-executable programming instructions for conducting the aforementioned tasks are stored in an internal memory of the controller <NUM>.

The location module <NUM> may be a global positioning system (GPS) transceiver or another type of location determination peripheral that may use, for example, wireless network information for location determination. The location module <NUM> is coupled to the controller <NUM> and provides location data <NUM> thereto. The location data <NUM> may be in the form of a latitude and longitude, for example.

The sensors <NUM> may be one or more of: a temperature sensor, a pressure sensor, an optical sensor, a motion sensor such as an accelerometer, a gyroscope, or any other suitable sensor indicating a condition pertaining to the asset <NUM> to which the telematics device <NUM> is coupled. The sensors provide sensor data <NUM> to the controller <NUM> via the sensor interface <NUM>.

The interface layer <NUM> may include a sensor interface <NUM> and an asset interface <NUM>. The sensor interface <NUM> is configured for receiving the sensor data <NUM> from the sensors <NUM>. For example, the sensor interface <NUM> interfaces with the sensors <NUM> and receives the sensor data <NUM> therefrom. The asset interface <NUM> receives asset data <NUM> from the asset <NUM>. In the depicted embodiment, the asset interface <NUM> is coupled to the interface port <NUM> of the asset <NUM>. The asset data <NUM>, received at the telematics device <NUM>, from the asset <NUM> may be in the form of data messages, such as CAN data frames. The asset data <NUM> may describe one or more of any of: a property, a state, and an operating condition of the asset <NUM>. For example, where the asset <NUM> is a vehicle, the data may describe the speed at which the vehicle is traveling, a state of the vehicle (off, idle, or running), or an engine operating condition (e.g., engine oil temperature, engine revolutions-per-minutes (RPM), or a battery voltage). In addition to receiving the asset data <NUM>, in some embodiments the asset interface <NUM> may also receive power from the asset <NUM> via the interface port <NUM>. The interface layer <NUM> is coupled to the controller <NUM> and provides both the asset data <NUM> and the sensor data <NUM> to the controller <NUM>.

The network interface <NUM> may include a cellular modem, such as an LTE-M modem, CAT-M modem, other cellular modem, Wi-Fi modem, or any other communication device configured for communication via the network <NUM> with which to communicate with the telematics server <NUM>. The network interface <NUM> may be used to transmit telematics data <NUM> obtained from asset <NUM> to the telematics server <NUM> for a telematics service or other purposes. The network interface <NUM> may also be used to receive instructions from the telematics server <NUM> for configuring the telematics device <NUM> in a certain mode and/or requesting a particular type of the asset data <NUM> from the asset <NUM>.

The NFC module <NUM> may be an NFC reader which can read information stored on an NFC tag. The NFC module <NUM> may be used to confirm the identity of the operator <NUM> by having the operator <NUM> tap an NFC tag onto the telematics device <NUM> such that the NFC tag is read by the NFC module <NUM>. The information read from the NFC tag may be included in the telematics data <NUM> sent by the telematics device <NUM> to the telematics server <NUM>.

The short-range wireless communications module <NUM> is a component intended for providing short-range wireless communication capability to the telematics device <NUM>. The short-range wireless communications module <NUM> may be a Bluetooth™. wireless fidelity (Wi-Fi), Zigbee™, or any other short-range wireless communications module. The short-range wireless communications module <NUM> allows other devices to communicate with the telematics device <NUM> over a short-range wireless network.

The I/O expander port <NUM> allows the telematics device <NUM> to connect additional peripherals thereto for expanding the input/output capability thereof. This will be described further below with reference to <FIG>.

The serial communications module <NUM> is an example of a wired communications module. The serial communications module <NUM> is an electronic peripheral for providing serial wired communications to the telematics device <NUM>. For example, the serial communications module <NUM> may include a universal asynchronous receiver transmitter (UART) providing serial communications per the RS-<NUM> protocol. Alternatively, the serial communications module <NUM> may be a serial peripheral interface (SPI) bus, or an inter-integrated circuit (I2C) bus. As another example, the serial communications module <NUM> may be a universal serial bus (USB) transceiver.

In operation, an ECU <NUM>, such as the ECU 110A, the ECU 110B, or the ECU 110C communicates asset data over the CAN bus <NUM>. The asset data exchanged between the ECUs <NUM>, over the CAN bus <NUM> are accessible via the interface port <NUM> and may be retrieved as the asset data <NUM> by the telematics device <NUM>. The controller <NUM> of the telematics device <NUM> receives the asset data <NUM> via the asset interface <NUM>. The controller <NUM> may also receive sensor data <NUM> from the sensors <NUM> over the sensor interface <NUM>. Furthermore, the controller <NUM> may receive location data <NUM> from the location module <NUM>. The controller <NUM> combines the asset data <NUM> with the sensor data <NUM> and the location data <NUM> to obtain the telematics data <NUM>. The controller <NUM> transmits the telematics data <NUM> to the telematics server <NUM> over the network <NUM> via the network interface <NUM>. Optionally, an operator <NUM> may tap an NFC tag to the NFC module <NUM> to identify themself as the operator <NUM> of the asset <NUM>. Additionally, an external peripheral, such as a GPS receiver, may connect with the telematics device <NUM> via the short-range wireless communications module <NUM> or the serial communications module <NUM> for providing location information thereto. In some embodiments, the telematics device <NUM> may receive, via the network interface <NUM>, commands from the telematics server <NUM>. The received commands instruct the telematics device <NUM> to be configured in a particular way. For example, the received commands may configure the way in which the telematics device gathers asset data <NUM> from the asset <NUM> as will be described in further detail below.

The telematics data <NUM> which is composed of asset data <NUM> gathered from the asset <NUM> combined with the sensor data <NUM> and the location data <NUM> may be used to derive useful data and analytics, by the telematics server <NUM>. However, there are times when additional data, which is not provided by the asset <NUM>, the sensors <NUM> or the location module <NUM> may be needed. The telematics device <NUM> may have a limited number of sensors <NUM> such as accelerometers or gyroscopes providing limited information about the motion of the asset <NUM> on which the telematics device <NUM> is deployed. The location module <NUM> may provide location and direction information. However, in some cases, more information may be needed to derive useful data and analytics pertaining to the asset <NUM>. One example of information that is not typically provided by the telematics device <NUM> is video-capture data. Another example of information that is not typically provided by the telematics device <NUM> is any proprietary signaling provided by devices which does not follow any of the standard protocols (OBD-II, J1939 or CANOpen). Some equipment may not have a CAN bus and may provide proprietary digital and/or analog signals. Examples of such devices include industrial equipment, winter maintenance equipment such as salt spreaders, farming equipment, and the like. Additionally, the telematics device <NUM> may not have an NFC module <NUM> or a short-range wireless communications module <NUM> thus limiting its connectivity capabilities.

To capture and provide information or services not provided by the asset <NUM> or the telematics device, to produce an output, or to perform an action not supported by the telematics device, the telematics device <NUM> may be modified to allow an input/output expander device ("I/O expander") to connect thereto, as shown in <FIG> shows a telematics device <NUM> coupled to an asset <NUM>. An I/O expander <NUM> is coupled to the telematics device <NUM>.

The asset <NUM> is similar to the asset <NUM> of <FIG> and therefore the internal components thereof are not shown in <FIG> for simplicity.

The telematics device <NUM> has a somewhat similar configuration as the telematics device <NUM> of <FIG>, but some of the optional components have been removed. Furthermore, the telematics device <NUM> adds an I/O expander port <NUM> for interfacing with the I/O expander <NUM>. The I/O expander port <NUM> is coupled to the controller <NUM> and may be configured for exchanging I/O expander data <NUM> with the I/O expander <NUM>.

In some embodiments, the I/O expander port <NUM> uses the CAN protocol to communicate with an I/O expander <NUM>. In other embodiments, the I/O expander port <NUM> uses the USB protocol.

An I/O expander is an electronic peripheral device, which provides additional capabilities to a telematics device when connected thereto. The additional capabilities may relate to capturing input data or generating output based on captured data. The I/O expander <NUM> of <FIG> is an example I/O expander which is designed to provide additional input and output options to a telematics device <NUM>, which has more limited features than the one shown in <FIG>. For example, the telematics device <NUM> shown in <FIG> does not have an NFC module, a short-range wireless communications module, or a serial communications module. Instead, the telematics device <NUM> has an I/O expander port <NUM> permitting the connection of an I/O expander that may provide such capabilities. The I/O expander <NUM> may be an input device configured to capture additional data such as video frames, audio frames, or proprietary signals and provide that data to the telematics device <NUM>. Alternatively, or additionally, the I/O expander <NUM> may be configured as an output device and may include a display for displaying information and/or an audio output device for broadcasting messages pertaining to the asset <NUM>.

An I/O expander <NUM>, which connects with the telematics device <NUM>, varies in complexity depending on the purpose thereof. <FIG> shows an I/O expander <NUM> containing several components which may or may not all be present in other I/O expanders. For example, the I/O expander <NUM> includes a controller <NUM>, an NFC module <NUM>, an output device <NUM>, a short-range communications module <NUM>, an image sensor <NUM>, a serial communications module <NUM>, an uplink port <NUM> and a downlink port <NUM>.

The controller <NUM> may be similar to the controller <NUM> in <FIG>. In some embodiments, the controller <NUM> is a microcontroller with versatile I/O capabilities. For example, the controller <NUM> may be a microcontroller which has a plurality of I/O ports such as general-purpose inputs and outputs (GPIOs), serial ports, analog inputs, and the like. In some embodiments, the controller <NUM> may have built-in persistent memory such as flash memory on which machine-executable programming instructions for conducting the functionality of the I/O expander <NUM> may be stored. In other embodiments, the controller <NUM> may be coupled to a persistent memory module (not shown) that contains the machine-executable programming instructions for conducting the functionality of the I/O expander <NUM>. The controller <NUM> may also have built-in volatile memory, such as random-access memory (RAM) for storing data. Alternatively, the I/O expander <NUM> may be connected to an external volatile memory for storing data.

The image sensor <NUM> may be a digital still camera or a digital video camera capable of capturing images. For example, the image sensor <NUM> may be a road-facing dashboard camera for monitoring the road ahead. In other examples, the image sensor <NUM> may be a driver-facing dashboard camera for identifying the operator <NUM> and/or their condition.

The uplink port <NUM> is comprised of an electronic peripheral interface coupled to the controller <NUM> and a connector coupled to the electronic peripheral interface. The uplink port <NUM> is used to provide data exchange and/or power capabilities to the I/O expander <NUM>. The uplink port <NUM> allows the I/O expander <NUM> to transmit and receive I/O expander data. The uplink port <NUM> is configured to use the same protocol and signaling as the I/O expander port <NUM> of the telematics device <NUM>. Accordingly, the I/O expander <NUM> may exchange the I/O expander data <NUM> with the telematics device <NUM>. In some embodiments, the uplink port <NUM> may also include power pins connected to corresponding power pins in the I/O expander port <NUM>, thus allowing the I/O expander <NUM> to be powered via the telematics device <NUM>. In other embodiments (not shown), the I/O expander <NUM> may have its own power source instead of or in addition to the power provided by the telematics device <NUM> via the uplink port <NUM>.

The downlink port <NUM> is comprised of an electronic peripheral interface and a connector, similar to the uplink port <NUM>. In the depicted embodiment, the downlink port <NUM> is coupled to the uplink port <NUM>. The downlink port <NUM> is configured to interface with the uplink port of another I/O expander (as will be described below). Allowing the downlink port <NUM> to connect to the uplink port of another I/O expander allows the conceptual daisy chaining of I/O expanders. In some implementations, the I/O expander port, the uplink port, and the downlink port use the CAN protocol. This will be discussed below with reference to <FIG> and <FIG>.

In the above-mentioned figures, a telematics device is shown as a separate entity connected with a corresponding asset. The telematics device, however, may have the components thereof integrated into the asset <NUM> either at the time of manufacture of the asset <NUM> or retrofitted at a later time. This may be the case when the asset <NUM> is a connected car having an asset network interface. For example, with reference to <FIG>, there is shown an asset <NUM> with the components of a telematics device integrated therein, in accordance with embodiments of the present disclosure. The asset <NUM> is similar to the asset <NUM> but, being a connected asset such as a connected car, it has an asset network interface <NUM>. In the depicted embodiment, the controller <NUM> is directly connected to the asset communications bus, which is a CAN bus <NUM> and may directly obtain the asset data <NUM> therefrom. The sensors <NUM> and the location module <NUM> are also integrated into the asset <NUM> and provide the sensor data <NUM> and the location data <NUM> to the controller <NUM> as described above. The asset network interface <NUM> belongs to the asset <NUM> and may be used by the asset <NUM> to communicate with an original equipment manufacturer (OEM) server, to a roadside assistance server, or for other purposes. The controller <NUM> may utilize the asset network interface <NUM> for the transmission of telematics data <NUM> provided by the controller <NUM>. In order to support further not provided by the integrated peripherals such as the sensors <NUM> and the location module <NUM>, the asset has an I/O expander port <NUM> coupled to the controller <NUM> so that an I/O expander <NUM> may be connected to the asset <NUM> therethrough. The asset <NUM> may have an interface port <NUM> for connecting other devices other than a telematics device <NUM>, such as a diagnostic tool including, but not limited to, an OBD-II reader device.

As discussed above, in some implementations the I/O expander port of a telematics device and the uplink port of an I/O expander may both use the CAN protocol. <FIG> depicts an implementation in which a telematics device <NUM> is connected to an I/O expander <NUM> via a CAN connection. Some components of the telematics device <NUM> and the I/O expander <NUM> are not shown for the sake of brevity. The I/O expander port of the telematics device <NUM> is a CAN port <NUM>, which comprises a CAN transceiver <NUM> and a CAN port connector <NUM>. Similarly, the uplink port of the I/O expander <NUM> is a CAN port <NUM> comprised of a CAN transceiver <NUM> and a CAN port connector <NUM>. The I/O expander <NUM> contains a sensor <NUM> which represents many types of sensors that provide data. The I/O expander <NUM> also contains an output device <NUM> for producing an output from output expander data received from a telematics device. The I/O expander <NUM> may be directly connected to the telematics device <NUM> as shown or a cable/harness (not shown) may be used.

In operation as an input expander, the sensors <NUM> provide data to the controller <NUM> of the I/O expander <NUM>. The controller <NUM> processes the sensor data and provides input/output expansion (IOX) data to the CAN transceiver <NUM><NUM> of the CAN port <NUM>. The CAN transceiver <NUM> can perform a number of tasks. The CAN transceiver <NUM> may drive the signal lines that transmit the IOX data to the telematics device <NUM>. Additionally, the CAN transceiver <NUM> may convert digital logic voltages to CAN bus voltages. CAN bus voltage levels are different from digital voltage levels used by the controller <NUM>. As shown in <FIG>, the CAN interface defines logic "<NUM>" as the dominant logic, and logic "<NUM>" as the recessive logic. In the dominant logic, the CANH signal is set to a voltage of <NUM>. 5V while the CANL signal is set to a voltage of <NUM>. In the recessive logic, the CANH and the CANL are both set to <NUM>. Digital logic voltages used by the controller <NUM> may be 0V for logic <NUM> and 5V for logic HIGH, or 0V for logic LOW and <NUM>. 3V for logic HIGH. The CAN transceiver <NUM> thus converts logic LOW and logic HIGH values which may be output on a general purpose I/O (GPIO) pin of the controller <NUM> to CAN voltage levels output on the signal lines labeled CANH and CANL. The CANH and CANL signals are sent over pins of the CAN port connector <NUM> to corresponding CANL and CANH pins of the CAN port connector <NUM> of the telematics device <NUM>.

At the telematics device <NUM>, the CANH and CANL signals are passed through the CAN port connector <NUM> to the CAN transceiver <NUM> where they are converted to digital voltage levels suitable for input to the controller <NUM>, for example at a GPIO pin thereof.

The I/O expander <NUM> of <FIG> may also be an output expander, in which case the telematics device <NUM> sends data thereto for producing an output. In this case, the controller <NUM> of the telematics device <NUM> outputs the data, for example over a GPIO pin thereof to the CAN transceiver <NUM>. The CAN transceiver <NUM> adjusts the voltage levels to the CANH and CANL levels and sends the data over the signal lines of the CAN port connector <NUM> to the pins of the CAN port connector <NUM> of the I/O expander <NUM>. The CAN transceiver <NUM> converts the CAN voltage levels back to digital voltage levels and provides the data in digital voltage levels to the controller <NUM> where it may be sent to the output device <NUM>.

In some embodiments, the I/O expander <NUM> and the telematics device <NUM> are connected using a Mini USB type B <NUM>-Pin connector. For example, the CAN port connector <NUM> of the telematics device <NUM> may be a Mini USB type B ("Mini USB") receptacle and CAN port connector <NUM> of the I/O expander <NUM> may be a Mini USB plug.

In the implementation of <FIG>, the telematics device <NUM> provides power and ground signals to the I/O expander <NUM>. The power (PWR) signal pin on the CAN port connector <NUM> of the telematics device <NUM> is connected to a corresponding power signal pin on the CAN port connector <NUM> of the I/O expander <NUM> for providing power thereto. The ground (GND) pin on the CAN port connector <NUM> of the telematics device <NUM> is connected to a corresponding ground pin on the CAN port connector <NUM> of the I/O expander <NUM>.

The CAN bus architecture permits connecting I/O expanders to one another. For example, with reference to <FIG>, there is shown a telematics device <NUM> connected to a first I/O expander 520A, which in turn is connected to a second I/O expander 520B. The first I/O expander 520A is shown to comprise a controller 330A, a CAN transceiver 352A, sensor 304A and an output device 340A. The first I/O expander 520A also has an uplink CAN port connector 574A and a downlink CAN port connector 524A. The second I/O expander 520B is shown to comprise a controller 330B, a CAN transceiver 352B, sensor 304B, and an output device 340B. The second I/O expander 520B also has an uplink CAN port connector 574B and a downlink CAN port connector 524B.

Specifically, the CAN port connector <NUM> of the telematics device is connected to the uplink CAN port connector 574A of the first I/O expander 520A. The downlink CAN port connector 524A of the first I/O expander 520A is connected to the uplink CAN port connector 574B of the second I/O expander 520B. Input/output expansion data from the second I/O expander 520B is passed through to the telematics device <NUM> via the downlink CAN port connector 524A and the uplink CAN port connector 574A.

The signal lines extending between the CAN port connector <NUM>, the uplink CAN port connector 574A, the downlink CAN port connector 524A, the uplink CAN port connector 574B, and the downlink CAN port connector 524A comprise a CAN bus <NUM> which may sometimes be referred to as the I/O CAN bus of the external CAN bus. The CAN bus <NUM> is distinct from the CAN bus <NUM> that is local to the asset to which a telematics device is coupled. The CAN bus <NUM> is shared by the telematics device <NUM>, the first I/O expander 520A, and the second I/O expander 520B.

The aforementioned I/O expander system uses the CAN protocol for communication between the telematics device <NUM> and the I/O expander <NUM>. Other technologies are contemplated. For example, another option is to use the Universal Serial Bus (USB).

The Universal Serial Bus (USB) is a common interface that enables communication between electronic devices and a host controller. USB may be used to connect peripheral electronic devices to a host electronic device. A host electronic device typically has a USB receptacle to which a peripheral USB device plugs. A peripheral USB device may contain a plug that plugs directly into the USB receptacle of the host electronic device. Alternatively a USB peripheral may plug into a USB host device by means of a USB cable.

In this disclosure, connectors are shown to have pins. The pins connect to "signal lines," which carry signals destined for other connectors or devices. The terms "pins" and "signal lines" may therefore be used interchangeably. A "signal" refers to an electrical signal traveling in a signal line. In the context of electronic circuit boards, a "signal line" refers to a wire or a connection on a printed circuit board (PCB). In the context of a microchip, the term "pin" refers to an external connection connecting the microchip internal circuitry to the outside world.

In this disclosure, the term "port" refers to a subsystem including a physical connector and all components, circuitry, and transceivers that facilitate the establishment of a connection and transmission of data over the connector. A USB port thus includes a connector, such as a plug or a receptacle, and other components for establishing a USB connection and exchanging data over the USB connection. In this disclosure when discussing signals on a port connector, the terms "pin" and "signal" may be used interchangeably, with the understanding that the pin is a physical element and the signal is the electrical signal passing through the pin.

For a host electronic device, the connector of a USB port is typically in the form of a receptacle. For a peripheral electronic device, the connector of the USB port is typically a plug. In some cases, a peripheral electronic device may also have a connector in the form of a receptacle. In this case, a USB cable is needed to connect the peripheral electronic device to the host electronic device. In this disclosure, references to a plug being connected to a receptacle should be understood to mean that the plug has been inserted into the receptacle and that corresponding pins of each of the plug and the receptacle have made electrical connections with one another.

In this disclosure, a "host electronic device" refers to an electronic device performing the main functionality of a system and accepts connections from one or more "peripheral electronic devices". A peripheral electronic device is an electronic device that performs input/output capability and transfers information to and from a host electronic device. In the context of USB technology, the term "host electronic device" refers to a device having a downstream facing port (DFP). Also in the context of USB technology the term "peripheral electronic device" refers to a device having an upstream facing port (UFP). This is explained further below. For brevity, the host electronic device may be referred to as the "host device", and the peripheral electronic device may be referred to as the "peripheral device".

A host device typically has a receptacle configured to receive a plug. The plug may be attached to another device or to a USB cable. For example, a laptop computer can act as a USB host electronic device with a receptacle. The receptacle may receive a plug from one end of a USB cable, or may receive a plug attached directly to a USB peripheral device such as a flash drive. Receptacles and plugs may both be considered "connectors".

The USB standard has evolved over the years starting with USB <NUM>. x in <NUM>, followed by USB <NUM> in <NUM>, USB <NUM> in <NUM>, USB <NUM> Gen <NUM> in <NUM>, and USB Type-C in <NUM>. USB Type-C ("USB-C") is a <NUM>-bin USB connector system with a rotationally symmetrical connector. USB-C adds more signal lines over previous versions of USB. <FIG> shows a USB host device <NUM>, and a USB peripheral device <NUM> connected to the USB host device <NUM> via a USB-C connection. <FIG> shows that up to USB <NUM>, a USB connector had only four signals (labeled "USB <NUM> Signals") namely Vbus (power), GND (ground), D+, and D-. USB devices up to USB <NUM> use differential voltage between the differential pair signals D+ and D-. For example, a logic "<NUM>" is specified by D+ having a logic HIGH while D- has a logic LOW. Conversely, a logic "<NUM>" is specified by having D- having a logic HIGH while D+ has a logic LOW. In USB technology, a HIGH is <NUM>. 8V and a LOW is -<NUM>. The voltage of Vbus is 5V by default, however, the standard allows USB devices to negotiate Vbus voltage values other than the default.

The USB <NUM> standard has added more signals namely the superspeed channel comprised of the differential pair superspeed signals TX1+/TX1- and RX1+/RX1-. The superspeed channel is capable of data transfer rates of up to <NUM> Gbits/s (or <NUM> MB/s), which is ten times the speed of USB <NUM>, which was <NUM> Mbits/s (or 60MB/s). The USB <NUM> superspeed signals are labeled "Super Speed Signals" in <FIG>.

The USB-C has added more signals to USB <NUM> signals, labeled as "USB-C" signals in <FIG>. Among the newly added USB-C signals, is a second superspeed channel comprised of the differential pair superspeed signals TX2+/TX2- and RX2+/RX2-. USB-C also adds a configuration channel CC for cable attach detection, cable orientation detection, role detection, and current mode detection. Additionally, USB-C has added sideband use (SBU) signals for use in alternate mode, as will be described below.

A USB-C plug can be inserted into a USB-C receptacle in any one of two orientations and still works the same way. This is accomplished through redundancies of pins in the port receptacle and plug. <FIG> shows a USB-C receptacle pinout, while <FIG> shows a USB-C plug pinout. As can be seen the VBUS (cable bus power) pins are symmetrically duplicated. As whether the plug is in a first orientation with respect to the receptacle or in a second orientation with respect to the receptacle, the <NUM>th pin from the left and the <NUM>th pin from the right is always VBUS. Similarly, the GND (cable ground) pins are symmetrically duplicated such that the GND pin is always the first pin on the left and the first pin on the right no matter what the orientation of the connector is. The USB <NUM> D+/D- pins are in the center of the connector and are mirrored such that the functionality thereof is maintained irrespective of the connector plug orientation. The configuration channels CC1 and CC2 pins are used for cable attachment detection, orientation detection, role detection, and current mode. One of CC1 and CC2 carries the signal VCONN to supply power for cable or adapter. The signals SBU1 and SBU2 are sideband use signals, and are used for alternate mode. The Superspeed Channel <NUM> and Superspeed Channel <NUM> are swapped when the plug is rotated with respect to the receptacle (i.e., switching from a first orientation to a second orientation, or vice versa). It is therefore important to know the orientation of the plug with respect to the receptacle.

A USB-C port may be used in one of three modes. The first mode is "host mode" which is used by a USB host electronic device. A USB-C port that supports host mode is termed a downstream facing port (DFP). A USB host device provides power to a USB peripheral device. In other words, a USB-C port configured as a DFP is configured to provide power. The second mode for a USB-C interface is "device mode". Device mode is used by a USB peripheral device. A USB-C port that supports device mode is an upstream facing port (UFP). A USB-C port that supports device mode does not provide power to another USB device connected thereto. Dual-role mode USB-C ports can be a UFP or a DFP. A USB-C port that supports dual mode role is a dual-role port (DRP).

As discussed above, the relative orientation between two USB connectors (namely a receptacle and a plug) needs to be known in order for a USB host electronic device to know which superspeed channel to use for data transfer.

<FIG> depicts an exemplary system comprised of a USB-port of a host electronic device configured as a DFP <NUM> connected to a USB-C port of a peripheral device configured as a UFP <NUM>.

The DFP <NUM> includes a power source <NUM>, a CCC <NUM>, a switch <NUM>, and two pull-up resistors Rp. The power source provides power to Vbus, when the switch <NUM> is turned on. The CCC <NUM> performs a number of tasks. For example, the CCC <NUM> may turn the switch <NUM> on to enable power delivery, when needed. The CCC <NUM> also determines the voltage at the configuration channel pins CC1 and CC2 to determine the orientation of a plug plugged into the receptacle of the host device, and determines the amount of power delivery that the DFP <NUM> delivers by default. The switch <NUM> may be a Field Effect Transistor that can be enabled by the CCC to connect power from the power source <NUM> to the bus power line Vbus.

The UFP <NUM> has a load <NUM> between the Vbus signal and the ground representing the circuitry of the peripheral device. One CC pin of the plug of the UFP <NUM> is connected to the signal Vconn while the other CC pin thereof is connected to the ground (Gnd) via a pull-down resistor Rd.

In the depicted example, the plug of the UFP1050 is connected to the receptacle of the DFP <NUM> in a first orientation such that the Vconn signal of the plug is connected to CC1 of the receptacle, while the CC pin of the plug is connected to CC2 of the receptacle. These two connections are represented by straight solid lines between CC1 (on the DFP <NUM>) and Vconn (on the UFP <NUM>) and between CC2 (on the DFP <NUM>) and CC (on the UFP <NUM>). As a result of the shown connection, CC1 is driven high by Vconn. Conversely, CC2 is pulled to a lower voltage as current flows from the 5V supply through the lower Rp resistor and the Rd resistor to the Gnd. The lower voltage of CC2 is determined by the values of the resistors Rp and Rd. As shown in the table depicted in <FIG>, when Rp is <NUM> and Rd is <NUM> the voltage on CC2 is approximately <NUM>. The CCC <NUM> determines that the UFP <NUM> is connected to the DFP <NUM> in a first orientation since CC1 is at a high voltage while CC2 is at a low voltage.

If the plug of the UFP <NUM> is flipped such that Vconn is connected to CC2 and CC is connected to CC1 (as shown in dotted lines), then the inverse of what has been described above takes place. In other words, CC2 is driven high and CC1 is driven low. Accordingly, the CCC <NUM> determines that the UFP <NUM> is connected to the DFP <NUM> in a second orientation since CC2 is at a high voltage while CC1 is at low voltage.

The values of the resistors Rp and Rd determine the Vbus current limit to which Vbus can be driven. As shown in <FIG>, Vbus can be driven to deliver 500mA or 900mA when Rp is <NUM>, <NUM>. 5A @ 5V when Rp is <NUM>, and <NUM>. 0A @5V when Rp is <NUM>. For example, when the UFP <NUM> is in the first orientation with respect to the DFP <NUM>, the CCC <NUM> may measure the voltage at CC2 by using an analog-to-digital converter (ADC). Since the resistors Rp and Rd act as a voltage divider, the voltage at CC2 varies with different values of Rp. Accordingly, the CCC <NUM> is able to determine the default current that the DFP <NUM> needs to deliver to the UFP <NUM> via Vbus. As a result, the CCC <NUM> may configure the power source <NUM> to provide the required default current, and enable the switch <NUM> to deliver the power to the DFP.

As shown in <FIG>, USB-C can deliver up to 3A of current at 5V. However USB charging has evolved and a new specification known as USB Power Delivery (USB PD) enables the maximum functionality of USB by providing more flexible power delivery along with data over a single cable. A recent revision of the USB PD specification (USB PD <NUM>) can deliver up to 240W of power. Earlier versions (prior to <NUM>) can deliver up to 100W based on 20V over USB-C cables rated at 5A. Power delivery in excess of 3A of current at 5V is negotiated between a DFP and a UFP via messages exchanged over the configuration channel.

The configuration channel of a USB-C port has been discussed briefly above. The signals CC1 and CC2 can be used to determine whether a USB-C plug has been plugged into a USB-C receptacle, determine the orientation of the plug with respect to the receptacle, and determine the default power that a DFP needs to provide to a UFP via the Vbus power line. The configuration channel has additional capabilities. The CCC of a DFP can exchange configuration messages with the CCC of a UFP, for example. The configuration messages may include a negotiation between the DFP and the UFP on the amount of power that the DFP delivers to the UFP which is in excess of the default values discussed above (which are determined by the value of the pull-up resistor of the DFP). The configuration messages may also include the enablement of USB-C alternate mode. The USB-C alternate mode specification allows for protocols other than USB to be transferred over a USB connection. For example, a UFP may indicate to a DFP that the UFP uses an alternate protocol to USB and may specify various parameters related to that protocol. In response, the UFP's CCC configures the UFP to use alternate mode pins to communicate with the DFP. This is explained in further.

<FIG> depicts a system in which an I/O expander <NUM> connects to a telematics device <NUM> via a USB-C connection. The I/O expander <NUM> has a USB-C interface configured as a UFP <NUM>. The telematics device <NUM> has a USB-C interface configured as a DFP <NUM>. In the depicted embodiment, the UFP <NUM> is connected directly to the DFP <NUM>. In other embodiments (not shown) the UFP <NUM> may connect to the DFP <NUM> via a USB-C cable.

The telematics device <NUM> is shown in simplified form where only the controller <NUM>, memory <NUM>, the sensors <NUM>, the network interface <NUM>, and the USB interface configured as the DFP <NUM> are shown. However, other components such as a location module may also be present and are not shown so as not to clutter the figure. The controller <NUM> and the memory <NUM> are similar to the controller <NUM> and the memory <NUM> discussed above. The sensors <NUM> are similar to the sensors <NUM>. The network interface <NUM> is similar to the network interface <NUM>. The memory <NUM> stores machine-executable programming instructions which configure the host electronic device to carry out the methods of the present disclosure.

The telematics device <NUM> draws power from a power source <NUM>. For a vehicle telematics device, the power source <NUM> may be the vehicle battery. The DFP <NUM> is similar to the DFP <NUM>. The pull-up resistors (Rp) have been removed for brevity but are nevertheless present in the UFP <NUM>. Other circuitry such as the switch <NUM> that routes power to Vbus is also not shown for brevity but is nevertheless present in the DFP <NUM> for routing power to Vbus from the power source <NUM>.

The I/O expander <NUM> is shown in simplified form containing only a controller <NUM>, sensors <NUM>, and the UFP <NUM>. The controller <NUM> and sensor <NUM> have been discussed above. The UFP <NUM> is similar to the UFP <NUM> but adds a peripheral configuration channel controller <NUM> similar to the host CCC <NUM>. The UFP <NUM> also contains a pull-down resistor Rd and a load, but they are not shown for simplicity.

<FIG> emphasizes the message exchange capability of the control channels. For example, in the depicted embodiment, the UFP <NUM> has one configuration channel with transmit and receive capability. The DFP <NUM> has two configuration channels, but only CC2 is used. As can be seen CC2 is connected to the CC pin of the UFP <NUM>, whereas CC1 is just connected to the signal Vconn. If the orientation of the UFP plug is reversed, then Vconn connects to CC2 and the DFP <NUM> uses CC1 to connect to the CC of the UFP <NUM>.

When the UFP <NUM> is connected to the DFP <NUM>, the host CCC <NUM> detects the connection and determines the orientation of the UFP plug with respect to the DFP receptacle, as discussed above. The host CCC <NUM> also determines the default power that the DFP <NUM> is to deliver to the UFP <NUM> based on the values of the resistor Rp (discussed above, but not shown in <FIG> for simplicity).

If the UFP <NUM> requires more power than the default power, the peripheral configuration channel controller <NUM> of the UFP <NUM> sends a configuration channel message <NUM> to the host CCC <NUM> of the DFP <NUM> requesting more power. If the host CCC <NUM> determines that the power source <NUM> can deliver the requested power, then the host CCC <NUM> responds to the configuration channel message <NUM> confirming that the requested power will be delivered. The host CCC <NUM> then configures the power source <NUM> to deliver the requested power to Vbus.

Another possible use of the configuration channel is to exchange messages that enable alternate mode, which is discussed below.

USB-C defines an alternate mode in which protocols other than USB may be transferred over a USB connection. Protocols such as DisplayPort, HDMI, MHL, and Thunderbolt may be sent over a USB-C port. Enabling a particular mode may be accomplished through the use of configuration messages between configuration channel controllers. For example, the peripheral configuration channel controller <NUM> of the UFP <NUM> may send a configuration channel message <NUM> indicating to the DFP <NUM> that the UFP wishes to communicate with the DFP using a requested alternate protocol other than USB. The host CCC <NUM> determines whether the requested alternate protocol is supported. In some implementations, the configuration channel message specifies the USB-C alternate mode signals used by the peripheral electronic device connected to the host electronic device. The host CCC <NUM> extracts the USB-C alternate mode signals from the configuration channel message <NUM> to determine which USB-C alternate mode signals shall contain the data sent by the peripheral electronic device. In response to determining that the particular alternate protocol is supported, the host CCC <NUM> enables the alternate mode for using the alternate protocol and sends a response configuration channel message confirming the enablement of the alternate mode that uses the requested alternate protocol. Enabling the alternate mode may comprise routing the alternate protocol signals to an interface module (or transceiver) for adjusting voltage levels, for example.

The USB-C alternate mode may be used to enable a host electronic device to support communications with a peripheral device such as an I/O expander using the CAN protocol. Additionally, the host electronic device may also communicate with a peripheral device that uses USB.

<FIG> depicts a simplified block diagram of a host electronic device <NUM> that supports communication with peripheral devices using either USB or CAN, in accordance with embodiments of the present disclosure.

The host electronic device <NUM> comprises a controller <NUM>, memory <NUM>, a USB interface including a host CCC <NUM>, a CAN transceiver <NUM>, a DFP <NUM>, and a switch <NUM>. The host electronic device <NUM> has a host device connector in the form of USB-C connector <NUM>.

An example of the host electronic device <NUM> is a telematics device, such as the telematics device <NUM>.

The controller <NUM> and the memory <NUM> are similar to the controller <NUM> and the memory <NUM>, respectively.

The CAN transceiver <NUM> is similar to the CAN transceiver <NUM>.

The switch <NUM> allows passing some signals from the USB connector, namely sideband use USB signals, to the CAN transceiver <NUM> based on a selection signal, CAN_SEL. Specifically, the switch <NUM> passes the signals SBU1 and SBU2 to the CAN transceiver <NUM> when the selection signal indicates CAN mode.

The USB connector connects the configuration channel signals CC1/CC2 to the host CCC <NUM> of the DFP <NUM>. The USB connector also connects USB <NUM> and the super speed channel signals to the DFP <NUM>. The USB <NUM> signals are depicted in <FIG> and comprise the signals D+, D-, Vbus, and GND. <FIG> shows only D+/D- for brevity. USB signals that may be used for CAN alternate mode are connected to the CAN transceiver <NUM> via the switch <NUM>.

When a peripheral electronic device is connected with the host electronic device <NUM>, the typical processes discussed above with reference to <FIG> and <FIG> take place at first. For example, the DFP <NUM> of the host electronic device <NUM> determines that the peripheral device is connected, determines the orientation of the connector of the peripheral device with respect to the orientation of the connector of the host electronic device, and determines the default Vbus current that the host electronic device is to deliver to the peripheral electronic device.

Subsequent to the initial processes discussed above, the peripheral electronic device sends configuration channel messages <NUM> to the host CCC <NUM> of the host electronic device <NUM>. For example, the peripheral device may request more electric power delivery current from the DFP <NUM> of the host electronic device <NUM>.

During the initial processes discussed above, the signal CAN_SEL is de-asserted and as such the switch <NUM> is off. When the switch <NUM> is off, the switch pin <NUM> and the switch pin <NUM>, that carry the SBU1/CANH and SBU2/CANL signals to the CAN transceiver are floating (i.e., are in a high impedance state). Consequently, the sideband use signals are not connected to the CAN transceiver. An example of the switch <NUM> is a tristate buffer that passes signals therethrough when an enable signal is asserted. When the enable signal is de-asserted, the output pins of the tristate buffer are in high impedance mode.

In the depicted embodiment of <FIG>, the peripheral device connects to the USB-C connector <NUM> and is either a USB device or a CAN device. When the peripheral device is a CAN device, the peripheral device sends the signals CANH and CANL over the sideband-use signals SBU1 and SBU2. When the peripheral device uses the USB <NUM> protocol, then in the depicted embodiments, the peripheral device exchanges data with the DFP <NUM> of the host electronic device <NUM> over the signals D+ and D-. When the peripheral device uses USB <NUM> or higher, then the peripheral device exchanges data with the DFP <NUM> over superspeed channel signals.

When the peripheral device uses the CAN protocol, the peripheral configuration channel controller of the UFP of the peripheral device sends a configuration channel message <NUM> indicating to the host CCC <NUM> that the peripheral device wishes to communicate with the host device using the CAN protocol over USB-C alternate mode. The host CCC <NUM> configures the DFP <NUM> to use alternate mode. Additionally, the host CCC <NUM> asserts the alternate mode indicator signal ALT_MODE_IND. In response to the assertion of the ALT_MODE_IND, the controller <NUM> determines that the host device will use the CAN protocol to communicate with the peripheral device. The controller <NUM> asserts the CAN select signal (CAN_SEL) which is connected to the switch <NUM>. When the CAN_SEL is asserted, the switch <NUM> passes the signals SBU1 (carrying CANH) and SBU2 (carrying CANL) to the CAN transceiver <NUM>. The CAN transceiver <NUM> converts the signals to CAN data in digital voltage levels suitable for consumption by the controller <NUM>. The controller <NUM> may also send CAN data to the CAN transceiver <NUM>. The CAN transceiver <NUM> converts the CAN data to CAN signal levels (<FIG>) and sends the CAN signals on the SBU1/CANH and SBU2/CANI signal lines. The switch <NUM> passes the SBU1 and SBU2 signal lines to the USB connector.

When the peripheral device uses USB <NUM> to communicate with the host electronic device <NUM>, no configuration messages are sent to the host CCC <NUM> and communication proceeds between the peripheral device and the host device over the D+ and D- lines. In this case, the switch pin <NUM> and the switch pin <NUM> of the switch <NUM> default to the high impedance mode on the SBU1 and SBU2 pins connected to the CAN transceiver <NUM>.

When the peripheral device uses USB <NUM> or higher to communicate with the host electronic device <NUM>, the configuration channel messages <NUM> indicate that the peripheral device uses USB <NUM>. The host CCC <NUM> de-asserts the alternate mode indicator signal ALT_MODE_IND. The controller <NUM> determines, from the alternate mode indicator, that the host device will use USB to communicate with the peripheral device. In response, the controller <NUM> de-asserts the CAN selection signal CAN_SEL. In response to the CAN selection signal being de-asserted, the switch <NUM> configures the switch pin <NUM> (which carries the signal SBU1/CANH) and the switch pin <NUM> (which carries the signal SBU2/CANL) in high impedance mode.

Advantageously, the host electronic device <NUM> can accept connections from both a USB peripheral device and a CAN peripheral device that uses USB-C alternate mode.

The embodiment depicted in <FIG> comprises the host CCC <NUM> notifying the controller <NUM> of alternate mode using CAN using the alternate mode indicator signal ALT_MODE_IND and the controller <NUM> configuring the switch <NUM> to pass the sideband-use signal lines (which are carrying the CAN signals) by enabling the CAN select (CAN_SEL) signal. In an alternate embodiment, the alternate mode indicator signal ALT_MODE_IND may be directly connected to the switch <NUM>. For example, with reference to <FIG>, the alternate mode indicator signal ALT_MODE_IND is used as the CAN select CAN_SEL signal used to enable the switch <NUM> to pass the sideband-use signals (used to carry CAN signals) from the USB connector to the CAN transceiver <NUM>. When alternate mode is not enabled, the CAN selection signal is de-asserted and the switch <NUM> places the switch pin <NUM> and the switch pin <NUM> thereof that connect the sideband-use signals SBU1/CANH and SBU2/CANL to the CAN transceiver in high impedance (or tristate) mode.

While new CAN peripheral devices may be designed to use a connector that can only fit in a single orientation, a USB-C connector can have two orientations with respect to another USB-C connector. Turning back to <FIG>, it can be seen that the signals SBU1 and SBU2 are swapped when a USB plug's orientation with respect to a USB receptacle is changed from a first orientation to a second orientation. Accordingly, in a host device that uses a swappable receptacle such as a USB-C receptacle, a mechanism needs to be added to ensure that the CAN transceiver accounts for the reversal in polarity between a first orientation and a second orientation in which the CANH signals and CANL are swapped. A CAN transceiver with a polarity control module is known. Such CAN transceivers include an input signal that identifies the polarity of the CAN signal lines. One example of such CAN transceivers is the TCAN4420 from Texas Instruments™. In both <FIG> and <FIG>, the USB-C port (i.e. , the DFP <NUM>) provides an orientation indication (ORIEN) to the CAN interface module. The orientation indication is set by the host CCC <NUM> after determining the orientation as described above. The CAN transceiver <NUM> swaps the signals CANH and CANL based on the orientation indication. Accordingly, the CANH and CANL signals are always in the proper order and the CAN transceiver <NUM> is able to convert the CAN signals to digital signals readable by the controller <NUM>. For example, the CAN transceiver <NUM> may pass through the signals SBU1 and SBU2 if the ORIEN signal is "<NUM>", and swap the signals SBU1 and SBU2 if the ORIEN signal is "<NUM>".

<FIG> depicts a method <NUM> by a host electronic device, in accordance with embodiments of the present disclosure. The method begins at step <NUM>.

At step <NUM>, the host electronic device detects a connection by a peripheral electronic device. As discussed with reference to <FIG>, the DFP <NUM> detects the connection of a UFP <NUM> by measuring the voltage on the signals CC1 and CC2. A lower voltage on CC2 for the depicted embodiment of <FIG> indicates the presence of a UFP connected to the DFP <NUM>.

At step <NUM>, the host electronic device checks whether it has received an indication that the electronic peripheral device connected thereto uses USB. The indication may be in the form of a configuration channel message. If the indication is received, control goes to step <NUM>. Otherwise, control goes to step <NUM>.

At step <NUM>, the host electronic device commences communication with the peripheral electronic device using USB.

At step <NUM>, the host electronic device checks whether it has received an indication that the electronic peripheral device uses the CAN protocol. If yes, control goes to step <NUM>. Otherwise, control goes back to step <NUM>.

At step <NUM>, the host electronic device configures the USB-C port to work in USB-C alternate mode.

At step <NUM>, the host electronic device determines a plurality of USB-C alternate mode signals used by the peripheral electronic device. For example, the peripheral electronic device may use the SBU1 and SBU2 alternate mode signals for the CAN signals. In some implementations, the USB-C alternate mode signals used by the peripheral electronic device are specified in a configuration channel message sent by the peripheral electronic device to the host electronic device.

At step <NUM>, the host electronic device passes the USB-C alternate mode signals used by the peripheral electronic device to a CAN transceiver. For example, the host electronic device configures the switch <NUM> to pass the sideband use signals SBU1 and SBU2 to the CAN transceiver <NUM>.

At step <NUM>, the host electronic device commences communication with the peripheral electronic device using CAN.

A peripheral device <NUM> configured to use the CAN protocol to communicate with the host electronic device <NUM> of <FIG> or <FIG> is shown in <FIG>. The peripheral device <NUM> has a controller <NUM>, a USB-C port configured as a UFP <NUM>, sensors <NUM>, a CAN transceiver <NUM>, and a peripheral device connector in the form of USB-C connector <NUM>. The UFP <NUM> includes a peripheral configuration channel controller <NUM>. Other components of the UFP <NUM>, such as those shown for the UFP <NUM> as shown in <FIG> are also part of the peripheral device <NUM> but are not shown for brevity.

When the peripheral device <NUM> is connected with the host electronic device <NUM> of <FIG> or <FIG>, the initial procedures relating to USB enumeration are first carried out between the host device and the peripheral device <NUM>. Specifically, the host device detects the connection with the peripheral device <NUM>, detects the orientation of the peripheral device USB-C connector in relation to the host electronic device connector, and determines the power requirements. Subsequently, the peripheral configuration channel controller <NUM> sends a configuration message to the host CCC <NUM> of the host electronic device <NUM> indicating that the peripheral device <NUM> uses USB-C alternate mode to send CAN data. Subsequent to receiving a confirmation configuration message from the host CCC <NUM>, the peripheral configuration channel controller <NUM> notifies the controller <NUM> that both the peripheral device <NUM> and the host electronic device <NUM> are now in USB-C alternate mode. In response to receiving the confirmation configuration message, the controller <NUM> commences sending data provided by the sensors <NUM> to the CAN transceiver <NUM>. The CAN transceiver <NUM> sends the data as CAN data to the host electronic device <NUM> via the USB connector. The CAN transceiver <NUM> adjusts the signal levels of the data from the controller <NUM> and sends the resulting CANH and CANL signals over the sideband-use signals SBU1 and SBU2 of the USB-C connector of the peripheral device <NUM>.

While new CAN peripheral devices may be designed with a built-in USB-C port including a peripheral configuration channel controller <NUM> as shown in <FIG>, other CAN peripheral devices, such as the I/O expander <NUM> of <FIG> only have a CAN interface. A peripheral device, such as the I/O expander <NUM> does not have a USB-C port or a configuration channel controller for establishing a CAN connection with a host device using USB-C alternate mode. In another aspect of the present disclosure, there is provided an interface converter that enables connecting a CAN peripheral device to a host electronic device that supports CAN over USB-C alternate mode.

An interface converter <NUM>, in accordance with embodiments of the present disclosure is depicted in <FIG>. In its simplest form, the interface converter <NUM> has a CAN interface connector <NUM> to which a CAN peripheral device may connect. The interface converter <NUM> has a buffering/protection module <NUM> that controls routing the CAN signals CANH and CANL to a USB-C connector for connecting to a host device. The interface converter <NUM> also has a USB-C port configured as a UFP <NUM> and including a configuration channel controller <NUM>. The configuration channel controller <NUM> negotiates with a host device configuration channel controller and requests a USB-C alternate mode connection for use by a CAN device. While not shown, the interface converter may also have a resistance Rd similar to that shown in the UFP <NUM>.

In operation, a CAN peripheral device is plugged into the CAN interface connector <NUM>. The interface converter <NUM> is then connected to a host electronic device via the USB-C connector <NUM>. The host electronic device detects the connection of the interface converter <NUM> thereto. The host electronic device also detects the orientation of the USB-C connector <NUM> relative to the USB connector of the host device. The UFP <NUM> indicates the default power that the interface converter <NUM> expects the DFP of the host device to provide. The configuration channel controller of the host device communicates with the configuration channel controller <NUM> of the interface converter <NUM>, for example to negotiate power delivery options. The configuration channel controller <NUM> of the interface converter indicates to the configuration channel controller of the host device that the interface converter represents a CAN device that uses USB-C alternate mode. Both configuration channel controllers negotiate a USB-C alternate mode connection. The configuration channel controller indicates to the buffering/protection module <NUM> that the USB-C alternate mode connection has been established thus enabling the buffering/protection module <NUM> to route the CANH and CANL signals to the SBU1 and SBU2 signals of the USB-C alternate mode.

Advantageously, with the use of the interface converter, a CAN peripheral device may connect to a host electronic device that supports routing CAN in USB-C alternate mode over the sideband use signal lines. No changes to the CAN peripheral device are necessary when the interface converter <NUM> is used. Accordingly, the cost of a CAN peripheral device is kept low. If a peripheral device uses the USB protocol, the peripheral device may connect directly to the host device without the need for the interface converter. The interface converter also offers backward compatibility for CAN-only peripheral devices.

In yet another aspect of the present disclosure, there is provided an impedance-based method and device for automatic detection of a CAN-only peripheral device connected to a host electronic device.

In some cases, a CAN peripheral electronic device does not contain any USB circuitry to negotiate a USB-C alternate mode with a host electronic device such that CAN traffic can travel over USB-C alternate mode signals. One solution discussed above is the use of an interface converter. Another approach that does not require the use of an interface converter involves the host electronic device accepting either CAN or USB signals over a single USB-C connector, and determining which protocol is being used by a peripheral device connected to the host device by means of checking impedance/resistance levels. For example, when the plug of a peripheral electronic device is inserted into a receptacle of a host electronic device, the host electronic device first checks whether the peripheral electronic device uses the USB protocol. The peripheral device may use the USB pins D+/D- if it uses the USB protocol <NUM>. Alternatively, the peripheral device may use other pins, such as the sideband use pins SBU1 and SBU2 to route CAN traffic. In the case where the peripheral device uses the CAN protocol, the USB <NUM> pins D+/D- are not used and are considered open circuit from the host device perspective. Accordingly, in some embodiments, by checking the voltage at the D+/D- pins, a host device determines whether the peripheral device is using USB or another protocol. To illustrate, reference is made to <FIG> and <FIG>.

With reference to <FIG>, there is shown a simplified circuit diagram of a connection between a host device and a peripheral device wherein the peripheral device does not use the USB protocol, and may be using an alternate protocol such as CAN. In this case, when the peripheral device is plugged to the host device, the D+/D- pins on the host device are not connected (NC) to anything as these signal lines are not being used by the peripheral device. The host electronic device has an impedance detection circuit that is used to determine the voltage of the D+/D- pins. <FIG> shows only an impedance detection circuit at the host electronic device <NUM> side. The impedance detection circuit is comprised of a bus power switch <NUM>, a first USB signal switch <NUM>, a second USB signal switch <NUM>, an analog-to-digital controller (ADC) in the form of ADC <NUM>, a first pull-up resistor Rc1, and a second pull-up resistor Rc2. The impedance detection circuit is coupled with the controller <NUM>. A conceptual block diagram of the impedance detection circuit is shown in <FIG>. The host electronic device <NUM> contains a USB-C port configured as a DFP and a CAN transceiver, but they are not shown in <FIG> for the sake of brevity.

The ADC <NUM> is coupled to the controller <NUM> and has at least two ADC channels for coupling to the D+ and D- pins. The ADC <NUM> provides digital values of the voltage on the USB <NUM> signal lines D+ and D- to the controller <NUM>.

The bus power switch <NUM> enables or disables connecting the bus power line Vbus from the peripheral device. The bus power switch <NUM> is coupled to the controller <NUM> and is controlled by the controller <NUM>. The controller <NUM> may assert a signal line on a general purpose input/output (GPIO) pin thereof connected to the bus power switch <NUM> to connect Vbus from the host side to the peripheral electronic device <NUM>. The controller <NUM> may de-assert the same GPIO pins thus isolating the bus power signal Vbus from the peripheral electronic device <NUM>.

The host electronic device <NUM> also contains a first USB signal switch <NUM> for connecting the bus power line Vbus to the D+ pin, and a second USB signal switch <NUM> for connecting the bus voltage line Vbus to the D- pin. Both the first USB signal switch <NUM> and the second USB signal switch <NUM> are controlled by the controller <NUM> in the same manner as the bus power switch <NUM>. The controller <NUM> can assert a GPIO pin connected to the first USB signal switch <NUM> to enable the first USB signal switch <NUM>. Similarly, the controller can assert another GPIO pin connected to the second USB signal switch <NUM> to enable the second USB signal switch <NUM>.

The bus power switch <NUM>, the first USB signal switch <NUM>, and the second USB signal switch <NUM> can be electronic switches utilizing one or more transistors as known in the art. For example, the aforementioned switches may be implemented using Metal Oxide Semiconductor Field Effect Transistors (MOSTFETs), Bipolar Junction Transistors (BJTs), or another form of electronic switch or relay.

When the peripheral device is plugged into the host electronic device and the host electronic device <NUM> is powered up, the controller <NUM> first disables the bus power switch <NUM> to isolate the power supply voltage Vbus from the peripheral device until the type of peripheral device is known. Next the controller <NUM> enables the first USB signal switch <NUM> and enables the ADC <NUM> to read the analog voltage of the D+ signal line. In the embodiment of <FIG>, the peripheral electronic device <NUM> does not use the USB <NUM> protocol. Accordingly, the D+ signal is not connected (NC) to anything on the peripheral electronic device. Since the first USB signal switch <NUM> is enabled, the D+ signal line is connected to Vbus via the first pull-up resistor Rc1. Since the D+ signal line is NC, no current flows and there is no voltage drop over the first pull-up resistor Rc1. The voltage of the D+ line is thus equal to Vbus. The voltage of the D+ signal line is fed to the ADC <NUM> and converted to a digital value provided to the controller <NUM>. The controller <NUM> determines that the voltage of the D+ signal line indicates that the peripheral device does not use the D+ signal.

The controller <NUM> may repeat the same process for the D- line. For example, the controller <NUM> enables the second USB signal switch1625 (while the bus power switch <NUM> is still disabled to isolate Vbus from the peripheral device). Since D- is also not connected, no current flows through the second pull-up resistor Rc2. The ADC <NUM> reads the voltage at the D- signal line and determines that the voltage is high (Vbus). As a result, the host electronic device <NUM> determines that the peripheral electronic device <NUM> does not use the USB <NUM> protocol.

In some embodiments, when the host electronic device <NUM> determines that the peripheral device does not use the USB <NUM> protocol, the host electronic device <NUM> determines that the peripheral device is using CAN if that is the only other possibility.

<FIG> is a simplified circuit diagram of a connection between a host device and a peripheral device, similar to <FIG>, but in which the peripheral device uses the USB <NUM> protocol.

When the peripheral device is plugged into the host electronic device and the host electronic device <NUM> is powered up, the controller <NUM> first disables the bus power switch <NUM> to isolate Vbus from the peripheral device until the type of peripheral device is known. Next the controller <NUM> enables the first USB signal switch <NUM> and enables the ADC <NUM> to read the voltage of the D+ signal line. Since the D+ signal line is connected to the ground via the resistance Rd, current flows from Vbus through the first pull-up resistor Rc1, the first USB signal switch <NUM>, and the first peripheral resistor Rd. The resistors Rc1 and Rd1 act as a voltage divider. The voltage at the D+ line is Vbus*Rd1 / (Rc1 + Rd1). The voltage at the D+ signal line is converted by the ADC <NUM> to a digital value provided to the controller <NUM>. The controller evaluates the digital value corresponding to the D+ signal line voltage. When the controller determines that the voltage of the D+ signal line voltage indicates a USB peripheral device is connected to D+, the controller <NUM> may then proceed to test the D- signal line in the same manner. Specifically, the controller <NUM> enables the second USB signal switch <NUM>, and reads the voltage at D-. The voltage at the D- line is Vbus*Rd2/(Rc2 + Rd2). Hence the controller <NUM> determines that the line D- is used by the peripheral device. The host electronic device <NUM> concludes that the peripheral device is a USB <NUM> device and not a CAN device.

The aforementioned method relies on the fact that voltage at D+ when a USB peripheral device is connected is lower than the voltage at D+ when a non-USB peripheral device is connected to the host device. For example, if the resistor Rc1 and the resistor Rd1 were equal, the voltage value at D+ would be Vbus / <NUM>. The voltage value at D+/D- when the peripheral device is using USB is thus significantly lower than when the peripheral device was not using USB (and was using CAN, for example). As such, it is possible to determine that a peripheral device connected to the host device is using USB <NUM>. The same process may be repeated for the D- signal.

If the peripheral device is determined to be a USB <NUM> peripheral device, then the host electronic device <NUM> turns off the first USB signal switch <NUM> and enables the bus power switch <NUM>. At this point, other USB functions such as the orientation detection, current requirements, and power delivery as described above may be activated.

<FIG> depicts a host electronic device <NUM> including an impedance detection circuit <NUM>, in accordance with embodiments of the present disclosure. The host electronic device comprises a controller <NUM>, a memory <NUM>, a USB-C port configured as a DFP <NUM>, a CAN transceiver <NUM>, a switch <NUM>, and a detection subsystem in the form of an impedance detection circuit <NUM>.

The controller <NUM>, the memory <NUM>, the DFP <NUM>, the CAN transceiver <NUM>, and the switch <NUM> have been described earlier. The impedance detection circuit <NUM> is logically depicted in <FIG>, and comprises the resistor Rc, the bus power switch <NUM>, the first USB signal switch <NUM>, the second USB signal switch <NUM>, and the ADC <NUM>.

In operation, when the host electronic device <NUM> is powered up, the controller <NUM> enables the impedance detection circuit <NUM> to determine whether the peripheral electronic device connected to the host electronic device is using USB or CAN. Upon determining whether the peripheral electronic device connected to the host electronic device is using USB or CAN, the host electronic device <NUM> configures the switch <NUM> to pass the appropriate signals.

When the detection subsystem (i.e., the impedance detection circuit) of <FIG> and <FIG> determines that the peripheral device uses CAN, the controller <NUM> asserts the CAN select signal (CAN_SEL) causing the switch <NUM> to pass CAN signals passed in the signals SBU1 and SBU2 to the CAN transceiver <NUM> via the switch pin <NUM> and the switch pin <NUM>. Conversely, when the detection subsystem (i.e., the impedance detection circuit <NUM>) indicates that the peripheral device uses USB, the controller <NUM> de-asserts the CAN select signal (CAN_SEL). When CAN_SEL is de-asserted the switch pin <NUM> and the switch pin <NUM> of the switch <NUM> become in the high impedance state. If the peripheral device uses USB <NUM>, then data is exchanged over the USB <NUM> lines D+/D-.

Advantageously, a host electronic device utilizing the detection subsystem (i.e., the impedance detection circuit <NUM>) can accept connections from either a USB peripheral device or a CAN peripheral device. The CAN peripheral device can be a CAN-only peripheral device and does not need to include any USB interface circuitry.

Claim 1:
A method by a host electronic device (<NUM>, <NUM>, <NUM>, <NUM>) that supports both a Universal Serial Bus, USB protocol and a Controller Area Network, CAN protocol, the method comprising:
isolating a peripheral electronic device (<NUM>, <NUM>, <NUM>, <NUM>) from a bus voltage line (Vbus) of the host electronic device (<NUM>, <NUM>, <NUM>, <NUM>);
connecting a D+ signal line or a D- signal line of the host electronic device (<NUM>, <NUM>, <NUM>, <NUM>) to the bus voltage line (Vbus) via a pull-up resistor (Rc1, Rc2);
determining a digital value of a voltage of the D+ signal line or D- signal line;
determining that the peripheral electronic device (<NUM>, <NUM>, <NUM>, <NUM>) is using the CAN protocol when the digital value is equal to a bus voltage of the bus voltage line (Vbus);
determining that the peripheral electronic device (<NUM>, <NUM>, <NUM>, <NUM>) is using the USB protocol when the digital value is lower than a bus voltage of the bus voltage line (Vbus);
in response to determining that the peripheral electronic device (<NUM>, <NUM>, <NUM>, <NUM>) is using the CAN protocol:
causing a switch (<NUM>) to pass at least one alternate mode signal (SBU1, SBU2) to a CAN transceiver (<NUM>); and
in response to determining that the peripheral electronic device (<NUM>, <NUM>, <NUM>, <NUM>) is using the USB protocol:
commencing communication using the USB protocol over a plurality of USB signal lines.