The SENT (Single Edge Nibble Transmission) bus continues to gain acceptance across the automotive industry and is widely used to transmit high-resolution readings from powertrain sensors to an electronic control unit (ECU). SENT is formally specified by SAE International and is often referred to as SAE-J2716. As with most automotive serial protocols such as CAN and LIN, it is a low- cost, noise-immune system; however, SENT differs from the other standards as it is a fairly lightweight, high-speed, point-to-point, one-way protocol specifically designed for real-time feedback from critical operational measurement sensors.
At the physical layer, SENT is a three- wire system supplying data, power, and ground across each wire. Signaling is accomplished by driving the voltage of the data line, with a nominal low state of <0.5V and a high state of >4.1V. Electromagnetic emissions are reduced by filtering or “shaping” the waveform transitions.
A SENT data packet is made up of the following: sync/calibration, status, data, and an error check (cyclic redundancy check or CRC). The sync/calibration component is fundamental to the trans- mission due to the very wide timing tolerance (25 percent) allowed by the SENT protocol.
The absolute data transfer number is calculated by measuring the length of the sync/calibration pulse. This derived timing is referred to as the tick time (TT), and the length of the sync/calibration pulse defines the tick time as it is always represented as 56 ticks. If the length of the sync/calibration pulse is measured as 171 μs, for example, then dividing this number by 56 gives a TT of 3.05 μs. This measurement and all subsequent measurements are made on falling edge to falling edge — hence the name single edge.
The next part of the decode is based on the nibble transmission. A byte is eight bits — eight bits divided by two makes four bits, or a nibble. The next measurement is the time between the next two falling edges that corresponds to the time of four bits (or a nibble). If the receiver measures 72.7 μs falling edge to falling edge, dividing by 3.03 μs equals 24 ticks, which corresponds to a nibble value of 1100. The nibble value is calculated as follows: 0000 data value is represented by a logic-high duration of 12 ticks, 0001 is 13 ticks, and so on up to a 1111 binary data value represented by a logic-high duration of 27 ticks.
The SENT bus can transfer data at two different rates simultaneously. The primary data is normally transmitted in what is called the “fast channel” with the option to simultaneously send secondary data in the “slow channel.”
Ensuring the SENT interface is per- forming well requires validation of at least four things:
- Data transfer levels to ensure basic electrical performance
- Data transfer speed and operation at the edge of the timing specification
- Data integrity to ensure the ability to effectively decode traffic
- Emissions to ensure edge filtering is optimal for transfer vs. emission levels
Unlike basic protocol analyzers, the latest oscilloscopes equipped with protocol decoding can be used to see both the decoded SENT bus traffic, as well as ver- ify signal quality in amplitude and time. This ability to see bus signals and decoded traffic makes oscilloscopes useful for visualizing overall system operation and for troubleshooting problems at the system level.
Automobiles rely on extensive networks of sensors, actuators, and displays, and many problems involve bus timing relative to I/O events or values. The ability to look at many I/O signals and bus transactions for multiple protocols at the same instant is critical to tracking down the root cause of a problem and for system-level debugging.
The SENT bus is a single-ended, ground reference signal. Although most oscilloscopes can acquire and display the bus using standard single-ended probing, signal fidelity and noise immunity can often be improved by using differential probing.
As discussed, the pulse-width encoding that makes SENT so robust also makes it difficult to interpret on an oscilloscope. Decoding software running on the scope greatly simplifies interpretation. For an oscilloscope equipped with SENT decoding and triggering, the measurement process starts by entering the necessary parameters to enable the oscilloscope to decode the packet. These typically include:
- Input channel
- Voltage threshold
- Signal polarity
- Number of fast channels and channel format
- Number of slow channels and channel format
- Pause pulse
Once the oscilloscope with SENT decoding is configured, it will be able to display the bus. A time-correlated wave- form and bus decode display is the preferred format for many hardware engineers. As shown in Figure 1, the decoded bus waveform indicates various elements of SENT messages. In this case, both fast and slow channel packets are shown in a single waveform display, with the slow channel packets shown below the fast channel packets.
For firmware engineers, a more comprehensive results table format may be useful. As shown in Figure 2, such a time-stamped display of bus activity can be compared to software listings and allows easy calculation of execution speed.
When the SENT bus contains both fast and slow channel data, the results table view provides side-by-side readouts of the two data channels. Since the slow channel data is spread across 18 successive fast channel packets, there are 18 fast channel messages from the start to the completion of the slow channel data message. In this example, the table is also linked to the waveform display for additional analysis.
SENT Bus Trigger and Search
When debugging a system based on one or more serial buses, one of the key capabilities of the oscilloscope is isolating and capturing specific events with a bus trigger. When the bus trigger is correctly set up, the oscilloscope will capture all the input signals and one specified bus event will be positioned at the trigger point. The example in Figure 3 demonstrates triggering on status value of 0000 binary, fast channel 1 data value 0¥27F, and fast channel 2 data value 0¥C72.
Another useful technique is to use the oscilloscope’s search functionality to find all the bus events that meet search criteria and determine how many of them occurred. In the example in Figure 4, the automatic search is looking for specified fast channel data values. This data pattern occurred 12 times in the acquired waveforms and the positions of the specified serial data packets are shown with the pink bracket icons.
In addition to fast channel search, other searches commonly performed in SENT bus analysis include start of packet, slow channel searches to determine when a specified message ID or specified slow channel data value occurs, pulse pauses of a specified duration, and instances when an incorrect frame length or incorrect CRC value occurs.
Emissions vs. Data Quality
When designing a SENT system, it is important to understand the tradeoff between transmitting high-quality data and minimizing emissions. Essentially, the faster the data edge, the more emissions you’ll have. To address this, SENT has provisions for soothing or calming data edge transitions so emissions can be reduced. But how much is too much and when is it not enough? The best way to test this is with a near- field probe kit and a spectrum analyzer. Some oscilloscopes have built-in spectrum analyzers, making correlating emissions to time-based protocol events easy. Another approach is to use oscilloscopes with triggers that can activate separate near-field spectrum analyzers.
The Right Tools
While the SENT bus is growing in popularity for many automotive applications, SENT bus communications can be affected by noise, board layout, reset issues, and subtle differences in implementations. The use of the right tools can remove risk and ensure performance over multiple conditions. Modern oscilloscopes offer powerful capabilities for quickly and efficiently tracking down the source of problems and validating designs, and can be used to see both the decoded SENT bus traffic as well as signal quality for a complete system view.
This article was written by Mark Elo, a senior technical manager at Tektronix, Beaverton, OR. For more information, visit here .