Give away medical masks when you place an order. learn more

How to Interface Sensors to Automotive Networks

There is a wide range of sensors used through a vehicle, from temperature and touch sensors to accelerometers and gyroscopes. This article looks at the issue of interfacing sensors to the wired networks, such as LIN, CAN and Ethernet, in automotive designs with extended temperature ranges and higher voltage protection.

Modern automotive networks use a combination of protocols for different applications. The increasing use of sensors around the vehicle for a wide range of applications – from image sensors for cameras to temperature sensors for heating and passenger identification – mean that different sensors have to be interfaced to different networks.

The Local Interconnect Network (LIN) is used for low-cost applications primarily in body electronics where data rates are typically 10 to 20 kbit/s, while Controller Area Network (CAN) is used for mainstream powertrain and body communications up to 10 Mbit/s. The FlexRay bus is for high-speed synchronized data communications in advanced systems such as active suspension. The MOST bus is used by some vehicle designers for higher performance networks carrying audio and even video at 50 to 100 Mbit/s, although there is also the development of Ethernet networks at 100 Mbit/s in the car to carry such data.

A key parameter for sensors to measure is temperature, as this can be used in many different ways to provide important information. The way the data is used, even for the same type of sensor, will require different bus interfaces. For example, an infrared temperature sensor such as the Melexis MLX90620 can be used as a ‘Thermal Comfort’ sensor in an automotive air-conditioning control system, but it can also be used for passenger classification and even for blind-angle detection. All of these applications would interface to different wired networks in the vehicle with different design requirements.

When the humidity in the car cabin is high and the temperature of the front windscreen is low, water vapor will condense on the glass, leading to an obscured view for the driver. The HVAC system can avoid this condensation by blowing dry hot air over the windscreen. For this, the system has to be able to detect condensation or even better, predict it. This can be done using IR thermometers, humidity sensors and external thermometers.

Figure 1: Using an IR temperature sensor array inside a vehicle.

The sensor can also be used to determine whether there is a passenger in the seat, enabling or disabling airbags. IR sensors can even be used for blind spot detection. One system uses a passive infrared sensor to sense thermal energy radiating from the tires of a moving vehicle. This temperature difference is used to trigger a flashing red light to warn the driver of the hazard.

Figure 2: IR temperature sensors can even be used for avoiding driver problems with blind spots.

IR temperature sensing is used as a more accurate and cost-effective alternative for measuring body temperature. Instead of measuring a sample of the air, the IR modules measure the body temperature directly. Its digital sensor interface also avoids reliability and design complexity issues.

The small size, low-cost 16 x 4 pixel IR array is easy to integrate with an industry-standard four-lead TO-39 package. The factory-calibrated infrared temperature measurement parameters are stored in EEPROM and the device can deliver a Noise Equivalent Temperature Difference (NETD) of 0.25K rms at 4 Hz refresh rate. It operates from a 2.6 V supply with operating temperature range of -40 to 85°C.

It contains two chips in one package: the MLX90670 IR array with signal conditioning electronics and the 24AA02 (256 x 8 EEPROM) chip. The MLX90620 contains 64 IR pixels with dedicated low noise chopper stabilized amplifier and fast ADC integrated. A Proportional To Absolute Temperature sensor (PTAT) is integrated to measure the ambient temperature of the chip. The outputs of both IR and PTAT sensors are stored in internal RAM and are accessible through I²C.

The results of the infrared sensor measurements are stored in RAM with a 16-bit result of the IR measurement for each individual sensor (64 words) and the 16-bit result of PTAT sensor. Depending on the application, an external microcontroller can read the different RAM data and, based on the calibration data stored in the EEPROM memory, compensate for difference between sensors to build up a thermal image, or calculate the temperature at each spot of the imaged scene. These constants are accessible by the user microcontroller through the I²C bus and have to be used for external post processing of the thermal data. The result is an image with NETD better than 0.08K rms at 1 Hz refresh rate.

The refresh rate of the array is programmable by means of register settings or directly via I²C command. Changes of the refresh rate have a direct impact on the integration time and noise bandwidth, as a faster refresh rate means higher noise level, so the frame rate is programmable in the range 0.5 Hz to 12 Hz and can be changed to achieve the desired trade off between speed and accuracy. The MLX90620 requires a single 3 V supply (±0.6 V) although the device is calibrated and performs best at VDD=2.6 V.

Figure 3: The Melexis MLX90620 IR temperature sensor on its evaluation board.

It is very important for the application designer to understand that the accuracy of the temperature measurement is very sensitive to the thermal equilibrium conditions when there are no temperature differences across the sensor package. The accuracy of the thermometer can be influenced by temperature differences in the package induced by causes such as hot electronics behind the sensor, heaters/coolers behind or beside the sensor, or by a hot/cold object very close to the sensor that not only heats the sensing element in the thermometer but also the thermometer package.

This effect is especially relevant for thermometers with a small FOV as the energy received by the sensor from the object is reduced. IR sensors are inherently susceptible to errors caused by thermal gradients. There are physical reasons for these phenomena and, in spite of the careful design of the MLX90620, it is recommended not to subject the device to heat transfer and especially transient conditions.

Capacitive loading on I²C can degrade the communication. Some improvement is possible by using a current source rather than resistors in the pull-up circuitry, and further improvement is possible with specialized bus accelerators. With the MLX90620, additional improvement is possible by increasing the pull-up current (decreasing the pull-up resistor values). Input levels for I²C compatible mode have higher overall tolerance than the I²C specification, but the output low level is rather low even with the high-power I²C specification for pull-up currents. Another option might be to go for a slower communication (clock speed), as the MLX90620 implements Schmidt triggers on its inputs in I²C compatible mode. Therefore, it is not really sensitive to rise time of the bus (it is more likely for the rise time to be an issue than the fall time, since the I²C systems are open drain with pull-up). This slower clock frequency means that the LIN bus is an ideal way of connecting the temperature sensor to the electronic control unit.

LIN/SAE J2602 is a universal asynchronous receiver-transmitter(UART)-based, single-master, multiple-slave networking architecture originally developed for automotive sensor and actuator networking applications and provides a cost-effective networking option for connecting motors, switches, sensors and lamps in the vehicle. The LIN master node extends the communication benefits of in-vehicle networking all the way to the individual sensors and actuators by connecting LIN with higher-level networks, such as CAN.

The LIN bus was developed to create a standard for low-cost, low-end multiplexed communication in automotive networks. Though the CAN bus addresses the need for high-bandwidth, advanced error-handling networks, the hardware and software costs of CAN implementation have become prohibitive for lower performance devices such as sensors. LIN provides cost-efficient communication in applications where the bandwidth and versatility of CAN are not required. LIN can be easily implemented using the standard serial universal asynchronous receiver/transmitter (UART) embedded into most modern low-cost 8-bit microcontrollers such as the Microchip PIC18, although there are also dedicated LIN interface devices.

The LIN bus uses a master/slave approach that comprises a LIN master and one or more LIN slaves. The message header consists of a break used to identify the start of the frame and the sync field used by the slave node for clock synchronization. The identifier (ID) consists of a 6-bit message ID and a 2-bit parity field and ID denotes a specific message address but not the destination. On receipt and interpretation of the ID, one slave begins the message response, which consists of one to eight bytes of data and an 8-bit checksum.

The master controls the sequencing of message frames, which is fixed in a schedule. This can be changed as required. There are several versions of the LIN standard. Version 1.3 finalized the byte-layer communication. Versions 2.0 and 2.1 added more messaging specifications and services but are compatible at the byte level with LIN 1.3.

Freescale Semiconductor’s 8-pin MC33662 is a Physical Layer component dedicated to automotive LIN sub-bus applications for the LIN Protocol Specification 1.3, 2.0, 2.1, and SAEJ2602-2. The part number selection defines the operating baud rate (33662L or 33662S for 20 kB/s and 33662J for 10 kB/s networks). Both integrate a fast baud rate (10 kB/s) for test and programming modes and provide the electromagnetic compatibility (EMC) and radiated emission performance, electrostatic discharge (ESD) robustness, and safe behavior in case of TXD short to ground that is required in an automotive design.

Figure 4: Interfacing Freescale’s MC33662 interface to a LIN network.

The MC33662 operates from a supply voltage of 7.0 to 18 V DC, functional up to 27 V DC, and handles 40 V during load dump so that it can be powered directly from the vehicle’s power rail, but supports 5.0 V and 3.3 V compatible digital inputs without any required external components; the local and remote wake-up capability is reported by the RXD pin.

The LIN driver is a low side MOSFET with internal overcurrent thermal shutdown. An internal pull-up resistor with a serial diode structure is integrated so no external pull-up components are required for the application in a slave node. As soon as the device enters normal mode, the LIN transmitter will be able to send the first dominant bit and the receiver will be enabled.

Similarly the Melexis TH8080 is a physical layer device for a single-wire data link capable of operating in applications where high data rate is not required and a lower data rate can achieve cost reductions in both the physical media components and in the microprocessor that use the network.

Because of the very low current consumption of the TH8080 in recessive state, it is suitable for ECU applications with hard standby current requirements, whereby no sleep/wake-up control from the microprocessor is necessary.

Figure 5: Controlling the Melexis TH8080 LIN interface transceiver.

The transceiver consists of a bus-driver with slew rate control, current limitation and, in the receiver, a high voltage comparator followed by a debouncing unit. The recessive BUS level is generated from the integrated 30 kΩ pull up resistor in serial with a diode. This diode prevents the reverse current of VBUS during differential voltage between VS and BUS (VBUS>VS). No additional termination resistor is necessary to use the TH8080 in LIN slave nodes. If this IC is used for LIN master nodes, it is necessary for the BUS pin to be terminated via an external 1 kΩ resistor in series with a diode to VBAT.

For higher levels of integration, devices such as the SPC560P44 from STMicroelectronics combine FlexRay, CAN, and LIN controllers in a chip that can be used as the hub for multiple functions using a PowerPC core with a flexible crossbar switch and analog-to-digital converter block. This also acts as the ECU device to integrate the data from multiple sensors on LIN and CAN.

Figure 6: The SPC560P44 combines CAN, LIN and FlexRay interfaces in a single device.

The FlexCAN interface block is used as a communication controller implementing the CAN protocol according to Bosch Specification version 2.0B. The CAN protocol was designed for use primarily as a vehicle serial data bus, meeting the specific requirements of this field: real-time processing, reliable operation in the EMI environment of a vehicle, cost-effectiveness, and required bandwidth, supporting 32 message buffers. A second CAN controller runs at high bit rates to be used as a safety port. The safety port CAN module provides bit rates as fast as 7.5 Mbit/s at 60 MHz CPU clock using direct connection between CAN modules so that no physical transceiver required.

The LIN network is more suited to the needs of sensors. The LINflex interface in the SPC560P44 acts as a master or a slave and manages a high number of LIN protocol messages efficiently with minimum load on CPU, supporting the data rates of typically 10 or 20 Kbit/s. Sensors can be easily connected via the ADC or the UART if there is a digital output.


For many of the more simple sensors, the LIN interface is the most effective way to transmit data back to the electronic control unit. Adding more sensors around the car is opening up new applications and making more use of the LIN bus, whether with individual transceivers or with sensor hubs.