The present disclosure relates to apparatuses and methods for sensors utilizing the single edge nibble transmission (SENT) protocol, and more specifically, relates to a multi-transmission mode that allows multiple sensors to connect and communicate to one receiver.
Sensors can be used to provide feedback information in various types of systems. In some examples, the sensors can operate as standalone sensors that are connected to an electronic control unit (ECU) through a sensor interface. An example interface that can be used for the sensors to transmit data to the ECU can utilize the single edge nibble transmission (SENT) digital communication protocol SENT protocol (also known as SAE J2716). The SENT protocol is a unidirectional point-to-point connection that allows the sensors to transmit data to the ECU. Data transmission using the SENT protocol is a serial data transmission, and specific hardware units are needed in the ECU for interpreting and decoding the data being transmitted. The SENT protocol can be limited to one hardware unit per sensor. Thus, to connect an additional sensor to an ECU, an available SENT port on the ECU, and additional hardware unit for each additional sensor, are needed. These additional ports and hardware units can be costly and can occupy additional space in the ECU.
In some examples, an apparatus for operating a multi-transmission mode of a single edge nibble transmission (SENT) protocol is generally described. The apparatus can include a controller. The controller can be configured to encode an identifier of a device in a synchronization nibble of a SENT signal.
In some examples, an apparatus for operating a multi-transmission mode of a SENT protocol is generally described. The apparatus can include a controller. The controller can be configured to receive a SENT signal. The controller can be further configured to decode an identifier of a device from a synchronization nibble of the received SENT signal to identify the device.
In some examples, a system configured to implement a multi-transmission mode of a SENT protocol is generally described. The system can include a receiver and a transmitter connected to one another. The transmitter can be configured to encode an identifier of a device in a synchronization nibble of a SENT signal. The transmitter can be further configured to transmit the SENT signal with the encoded identifier to the receiver. The receiver can be configured to receive the SENT signal transmitted from the transmitter. The receiver can be further configured to decode the identifier of the device from the synchronization nibble of the SENT signal to identify the device.
Further features as well as the structure and operation of various embodiments are described in detail below with reference to the accompanying drawings. In the drawings, like reference numbers indicate identical or functionally similar elements.
Each sensor among the sensors 110, 120, and 130 can include a transmission (TX) module 140. The TX module 140 can be an apparatus that can operate as a single edge nibble transmission (SENT) transmission interface or module configured to output a SENT signal 108 (e.g., a signal having a format defined by the SENT protocol). Further, the sensors 110, 120, and 130 can include sensing elements 112, 122, 132, respectively. The sensing elements 112, 122, 132 can include, but are not limited to, pressure sensors, temperature sensors, air flow sensors, accelerometers, speed sensors, infrared sensors, and/or other types of sensors that can sense various parameters (e.g., physical parameters) of an environment surrounding or within a vehicle implementing the system 100. Each one of the sensing elements 112, 122, 132 can be connected to the TX module 140 in its corresponding sensor. The parameters being sensed by the sensing elements 112, 122, 132 can be provided to the TX module 140, and the TX module 140 (or a controller in the TX module 140) can convert the sensed parameters into a SENT signal.
The ECU 102 can include a receiver (RX) module 150 and a microcontroller unit (MCU) 160. The MCU 160 can include processing components, such as a processor 162, and storage elements 164 such as a memory device or a cache memory of the processor. The storage elements 164 can be configured to store instructions, such as executable code, that can be executable by the processor 162 to perform one or more of the embodiments being described in accordance with the present disclosure. The RX module 150 can be an apparatus that can operate as a SENT receiver interface or module configured to receive SENT signals from the TX modules 140 of the sensors 110, 120, 130, via the sensor bus 106. The RX module 150 (or a controller of the RX module 150) can be configured to interpret and decode data and messages encoded in the SENT signal 108, and may convert the decoded data into digital signals having a format that can be processed by the processor 162 of the MCU 160. The processor 162 of the MCU 160 can use the digital signals provided by the RX module 150 to generate control signals that can control and/or operate various parts (e.g., various parts of a vehicle) connected to the ECU 102.
The TX module 140 in the sensors 110, 120, 130, and the RX module 150 in the ECU 102, can facilitate data transmission in one direction—from the sensors 110, 120, 130 to the ECU 102, using the SENT protocol. The SENT protocol is unidirectional, and is an asynchronous voltage interface. Transmission of SENT signals can be performed using three wires: 1) a signal line (low state<0.5V, high state>4.1V), 2) a supply voltage line (5V), and 3) a ground line, where these three wires can be in the sensor bus 106. The TX module 140 and the RX module 150 can be configured to facilitate transmission of SENT signals, such as a SENT signal 108, from the sensors 110, 120, 130, to the ECU 102 using one port 109 on the ECU 102. The port 109 can be connected to the RX module 150. In order to use one port (e.g., port 109) to receive SENT signals from more than one sensors (e.g., sensors 110, 120, 130), an identifier (ID) 107 can be encoded or coded in the SENT signal 108, where the ID 107 identifies the sensor that transmitted the SENT signal 108. The TX module 140 of each sensor among the sensors 110, 120, 130 can be configured to encode a respective ID in a corresponding SENT message. For example, if the sensor 110 is the sensor transmitting the SENT signal 108, the TX module 140 of the sensor 110 can encode the ID 107 of the sensor 110 in the SENT signal 108.
The basic unit of time for the SENT protocol is referred to as a tick, where the duration of a tick can be variable between, for example, 3 microseconds (μs) to 90 μs. In an example, the duration of a tick can be defined by dividing a clock cycle (e.g., 4-megahertz (MHz) clock) by a tick parameter defined for the system 100. A minimum data unit is referred to as a nibble. A nibble is 4 bits of data encoded using pulse width modulation (PWM), and encoded in a combined pulse timing of an initial fixed-width low period followed by a variable-width high period. In an example message frame shown in
A message frame of a SENT signal begins with a synchronization nibble (SN) that includes a calibration pulse (CP), where the synchronization nibble can be used by a receiver (e.g., the RX module 150 shown in
In the example shown in
As mentioned above, in order to use one port (e.g., port 109 shown in
In one embodiment, the identifier (ID) 107 can be encoded in other nibbles of the SENT signal 108. For example, the ID 107 can be encoded in the CRC nibble instead of the synchronization nibble. In another example, the ID 107 can be encoded in one of the 12-bit words that may be unused (e.g., not encoded with any data). For example, if the second 12-bit word is not being used, then the ID 107 can be encoded in one or more of the nibbles S2D1, S2D2, and S2D3 of the second 12-bit word. By encoding the ID 107 in one or more of the nibbles (e.g., synchronization nibble, CRC nibble, and/or data nibbles), the SENT signal 108 can include an identification of the sensor that transmitted the SENT signal 108. In an example, encoding of the ID 107 in the CRC nibble or a data nibble can include defining a number of ticks in the nibble. For example, a CRC nibble having 12 ticks can representing a 4-bit word of 0000, or an ID #0, and a CRC nibble having 15 ticks can representing a 4-bit word of 0011, or an ID #3.
In another example, the ID 107 can be encoded in more than one nibble in order for the RX module 150 to check the received decoded ID for correctness. For example, the ID 107 can be encoded in both the synchronization nibble and the CRC nibble, such that the processor 162 of the MCU 160 can compare both encoded copies of the ID 107 to validate a correctness of the ID 107. If the two encoded copies of the ID 107 do not match, then the processor 162 can determine that there can be an anomaly, such as error in operations of the sensor having the ID 107, or potential security issue (e.g., man-in-the-middle attacks, etc.).
In an example, to decode the ID 107, the RX module 150 can identify the tick position 201 in the synchronization nibble to determine the tick position where the transition from logic low state to logic high state of the calibration pulse (CP) begins. The RX module 150 can provide the identified tick position 201 to the MCU 160, where the storage elements 164 can stored correspondences between sensor IDs and tick positions. For example, the tick position 201 can be assigned to the sensor 110, and another tick position can be assigned to the sensor 120. Therefore, the MCU 160 can use the tick position 201 decoded by the RX module 150 to identify the sensor that sent the SENT signal 108.
In another example, to decode the ID 107, the RX module 150 can determine a tick count of the calibration pulse (CP) in the SENT signal 108. For example, the RX module 150 can determine a first time stamp where the logic high state of the calibration pulse (CP) begins (or where the low-to-high transition occurs), and a second time stamp where the logic high state of the calibration pulse (CP) ends (or where the high-to-low transition occurs). The RX module 150 can determine a difference between the first and second time stamps, and divide the time difference by the tick unit of the SENT message (e.g., that can be obtained by dividing the total time duration of the synchronization nibble by 56) to obtain a tick count of the calibration pulse (CP). The tick count of the calibration pulse (CP) can represent the ID 107. The RX module 150 can provide the tick count of the high logic state to the MCU 160, where the storage elements 164 can store correspondences between sensor IDs and tick counts. For example, the tick count X′ can be assigned to the sensor 110, and another tick count can be assigned to the sensor 120. Therefore, the MCU 160 can use either the tick position in which the calibration pulse (CP) begins (e.g., tick position 201), or the tick count of the calibration pulse (CP) (e.g., X′), to identify the sensor that sent the SENT signal 108.
Note that the example SENT signal 108 shown in
Each pulse shown in
The example presented in
In the initialization process, the TX module 140 of each sensor among sensors 110, 120, 130 can listen to traffic 406 on the sensor bus 106. In an example, the traffic 406 can include structure frames of SENT signals being transmitted on the sensor bus 106. If the multiple SENT signals have synchronization nibbles with the same tick position to start a low-to-high transition, then the controller 402 can determine that there is one sensor connected to the sensor bus 106 and can decode one of the synchronization nibbles of the multiple sensor signals to extract the ID of the connected sensor. If the multiple SENT signals are two SENT signals having synchronization nibbles with low-to-high transition starting at two different tick positions, then the traffic 406 can indicate there are two sensors assigned to transmission positions and the controller 402 can decode the synchronization nibbles to extract the IDs of the two connected sensors. If there is no SENT signal on the sensor bus 106 (according to the traffic 406), then the TX module 140 may wait for an amount of time (e.g., a number of time cycles) before transmitting a SENT signal to the sensor bus 106. For example, if the TX module 140 for the sensor 120 (assigned to ID #1) listens to traffic 406 and see no SENT signal on the sensor bus, then the sensor 120 may wait for one time cycle before transmitting its own SENT signal with the tick position representing ID #1 in its synchronization nibble. If the TX module for a sensor is assigned to ID #6, and the traffic 406 indicates no SENT signal was transmitted on the sensor bus, then this sensor may wait for five time cycles before transmitting its own SENT signal with the tick position representing ID #6 in its synchronization nibble. In some examples, the TX module 140 on each sensor can encode a reset signal in the R tick position (shown in
The controller 402 can be further configured to activate or deactivate a multi-transmission mode by controller a configuration bit 404. The configuration bit 404 can be, for example, a hardware switching element, a parameter that can be defined using software, a value stored in a register, or a bit configured in non-volatile memory (NVM) of the sensor, depending on a design and implementation of the system 100 and the TX module 140. The configuration bit 404 can have two values, such as binary 0 and binary 1. In an example, the configuration bit 404 being binary 0 (or binary 1) can denote a deactivation of the multi-transmission mode, and the configuration bit 404 being binary 1 (or binary 0) can denote an activation of the multi-transmission mode. The activation of the multi-transmission mode can cause the TX module 140 to encode the ID 107 in the SENT signal 108 to facilitate transmission from multiple sensors to the ECU. The deactivation of the multi-transmission mode can allow the TX module 140 to function as a normal SENT interface without encoding the sensor ID in the SENT signal 108. Therefore, the TX module 140 can be compatible with existing systems that uses the SENT protocol without sensor ID encoding.
In response to a completion of the initialization process, operation of the system 100 in multi-transmission mode can commence by having the sensors transmit their own SENT signals under the assigned transmission positions. In an example, the TX module 140 can continue to listen to the traffic 406 in order to determine whether it is the appropriate time to transmit a signal. In an example, an order of transmission for the multiple sensors can be predefined. For example, the NVM of each one of the three sensors 110, 120, 130 shown in
To perform transmission under the multi-transmission mode, the controller 402 can use traffic 406 to determine whether a corresponding sensor shall transmit its SENT signal to the sensor bus 106, or to wait for its turn to transmit. For example, the TX module 140 can obtain traffic 406 including a frame structure and/or a synchronization nibble of a most recent SENT signal on the sensor bus. The TX module 140 can decode the synchronization nibble in the traffic 406 to identify or extract an encoded ID of a sensor that transmitted the most recent SENT signal. If the most recent SENT signal is transmitted by the sensor 130, then the TX module 140 of the sensor 110 can determine that sensor 110 can perform a SENT signal transmission to the sensor bus 106 based on the transmission order (e.g., #0, #1, #2, #0, #1, etc.) and transmission positions (e.g., sensor 110 being assigned to #0 and sensor 130 being assigned to #2) stored in the sensor 110. If the most recent SENT signal is transmitted by the sensor 130, then the TX module 140 of the sensor 120 can determine that sensor 120 is prohibited to perform a SENT signal transmission to the sensor bus 106 based on the transmission order (e.g., #0, #1, #2, #0, #1, etc.) and transmission positions (e.g., sensor 120 being assigned to #1 and sensor 130 being assigned to #2) stored in the sensor 110. Thus, the ECU 102 can receive SENT signals in an orderly manner and conflicting traffic on the sensor bus 106 can be avoided.
In another example, the sensors 110, 120, 130 can be configured to transmit SENT signals in an order of ID #1, #3, #4, respectively. Thus, the sensor 120 may wait for the ID #1 to appear in the traffic 406 to transmit its SENT signal, the sensor 130 may wait for the ID #3 to appear in the traffic 406 to transmit its SENT signal, and the sensor 110 may wait for the ID #4 to appear in the traffic 406 to transmit its SENT signal. If an error occurs, such as the traffic 406 showing a transmission order of #1, #2, then the sensor 130 may start a wait event to wait for an amount of time before sending its SENT signal because the traffic 406 does not show ID #3. For example, a time between each transmission of SENT signal from different sensors is T. In response to the traffic 406 showing the most recent transmission was from ID #2, the sensor 130 may wait for, for example, a time of T to ensure that there may be ample time for the sensor device with ID #3 to transmit a SENT signal before sensor 130 performs a transmission. The ECU 102 may also be aware of the wait time T. If the ECU 102 does not receive SENT signals from a sensor after the wait time T, or detects that the sensor waits for the wait time T on numerous occasions (e.g., for N iterations of the sequence #1, #3, #4), then the ECU 102 can put (e.g., send, broadcast) a reset request on the sensor bus 106. In other words, the ECU 102 can detect whether there is a potential error based on an order in which SENT signals are being received, and also based on the timings in which the SENT signals are being received. The traffic 406 can indicate the reset request, and the sensors 110, 120, 130 can listen to the traffic 406 and detect the reset request, and reset the initialization process with the ECU 102
By encoding a sensor ID in the synchronization nibble of a SENT message, multiple sensors can be connected to a single ECU without the need to add additional ports and hardware that can occupy device space and increase device size. Further, due to the synchronization nibble is typically being used for synchronization purposes only, and does not include any data or information, the tick positions between a start tick and an ending tick of a calibration pulse (CP) in the synchronization nibble can be used for decoding the sensor IDs. The utilization of the synchronization nibble allows ID coding without adding ticks or nibbles to the SENT protocol, and without affecting any data or information being carried by the SENT signal. Furthermore, the encoding being performed by the transmitter, and the decoding being performed by the receiver, can be realized with relatively simple modifications to hardware, software, or firmware, without impacting normal operations of the system 100. Also, by having each sensor encoding its ID in each SENT message being transmitted, no additional communication before or after sending the SENT message is needed between the transmitter and the receiver.
The process 500 can be implemented by a transmitting device in a system implement the SENT communication protocol. The system can include a receiving device connected to one or more transmitting devices (including the transmitting device performing the process 500) via a sensor bus. The transmitting device can be a part of a sensor that includes sensing elements, memory devices, and processing elements. The receiving device can be a part of an electronic control unit including memory devices and processing units such as microcontrollers.
The process 500 can begin at block 502. At block 502, the transmitting device can enable a multi-transmission mode. In an example, the transmitting device can enable the multi-transmission mode by setting a configuration bit stored in the transmitting device. The multi-transmission mode can allow more than one transmitting devices in the system to connect, and to transmit SENT signals, to the receiving device. The process 500 can proceed from block 502 to block 504. At block 504, under the multi-transmission mode, the transmitting device can listen to traffic on the sensor bus. The traffic obtainable by the transmitting device can include, for example, frame structure of SENT signals being transmitted to the receiving device via the sensor bus.
The process 500 can proceed from block 504 to block 506. At block 506, the transmitting device can use the traffic obtained from block 504 to determine whether a most recent SENT signal on the sensor bus is outputted by another sensor assigned as a previous sensor in a transmission order or sequence. For example, the system can include three sensors assigned to transmission positions #0, #1, #2. A transmission order for the three sensors to transmit SENT signals can be a predefined order #0, #1, #2, #0, #1, #2, etc. In an example, the transmitting device performing the process 500 can be assigned to transmission position #2. In response to the most recent SENT signal on the sensor bus being outputted by a sensor assigned to #0, the process 500 can return to block 504, where the transmitting device may continue to listen to traffic on the sensor bus. In response to the most recent SENT signal on the sensor bus being outputted by a sensor assigned to #1, the process 500 can proceed to block 508, where the transmitting device may transmit its SENT signal to the receiving device via the sensor bus.
The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the Figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.
The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
The corresponding structures, materials, acts, and equivalents of all means or step plus function elements, if any, in the claims below are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The description of the present invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the invention. The embodiment was chosen and described in order to best explain the principles of the invention and the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.
Number | Name | Date | Kind |
---|---|---|---|
20150236876 | Cadugan | Aug 2015 | A1 |
20150269019 | Scherr | Sep 2015 | A1 |
20180067153 | Kolof | Mar 2018 | A1 |
20190199451 | Krall | Jun 2019 | A1 |
20200244481 | Scherr | Jul 2020 | A1 |
Number | Date | Country | |
---|---|---|---|
20230129498 A1 | Apr 2023 | US |