Tests on Wireless Communication to Tire Sensors

Joram Fillol-Carlini, Continental Automotive France, Wireless Tests

"With this approach, we can save time in development and validation to the tune of up to four weeks, as well as save costs, when compared to the currently implemented solution."

- Joram Fillol-Carlini, Continental Automotive France, Wireless Tests

The Challenge:

We needed to validate and develop a customised communication protocol sensor at a lower cost compared to existing systems.

The Solution:

We developed a generic and configurable RF communication card for the ISM band (315 MHz/433.92 MHz/868 MHz/915 MHz) that can transmit and receive any modulated frames in FSK or ASK. The card is intended to be integrated into a prototype tester followed by a production tester. We achieved this with a software defined radio approach that combines a USRP-2900 card to send and receive RF signals and LabVIEW software to create an easy-to-use, modular, and configurable programme.

Author(s):

Sébastien Kessler - Continental Automotive France, Wireless Tests
Joram Fillol-Carlini - Continental Automotive France, Wireless Tests

Testing Communication to Tire Sensors

Continental Automotive, a premium supplier of automotive solutions, manufactures various connected sensors, keys, and other equipment that operates according to different RF protocols.

Amongst these communication-capable sensors are some dedicated to monitoring continuous tire pressure so that it is always possible to know what the tire pressure is and receive an alert in the event of abnormal pressure loss. As such, the Continental tire pressure monitoring system prevents a frequent cause of accidents and ensures optimal safety for the driver. It also helps to reduce CO2 emissions and fuel consumption (a tire that is under-inflated by 0.3 bar leads to an over-consumption of 1.5 percent on average).

For light vehicles and heavy goods vehicles, Continental offers a complete range of tire pressure sensor solutions that meet the various European and international regulations.

The company’s quality requirements call for products to undergo many tests, which are now carried out with dedicated cards using hardware and software designed specifically for this purpose.

As a result, in the event that there are changes in customer requirements or the technologies used, it is sometimes necessary to update the dedicated card’s software or begin a new hardware design. Among the most common developments are the size of the frame, the type of modulation, the throughput, data coding, or frequency used. Such an approach is costly in terms of resources for development as well as maintenance and prohibits a standardised approach. The company therefore needs to find a more practical and less expensive alternative.

One solution is to use software defined radio (SDR) technology to create RF application software that is quick to develop and easy to configure.

The Constraints of a Test Card

In a context where hundreds of thousands of products are produced every day and where the tolerated error rate is extremely low, an application that tests equipment such as tire pressure sensors or car keys must be hardy, reliable, and fast.

It is therefore necessary to develop a hardy and flexible solution that ultimately has the same reliability as the solution currently being used. This solution needs to be easy to use while remaining complete so as to be able to adapt to future changes in technologies and protocols.

It has to be able to use ASK and FSK modulations in transmission as well as reception, to adapt to various transmission rates and different frequencies, and also to code/decode Manchester code.

The advantage of SDR technology is that it usually requires only two components:

A card for transmitting/receiving signal
A computer with software that can process this signal

Combining USRP-2900 and LabVIEW Equipment

We have therefore used USRP-2900 from NI (Figure 1). It is an RF transceiver that covers the range from 70 MHz to 6 GHz with a maximum instantaneous bandwidth of 20 MHz with characteristics that are relatively well suited to our application’s requirements. With this USRP (Universal Software Radio Peripheral) device, we can not only capture RF product messages under test but also transmit them through two channels, Tx/Rx and Rx.

The USRP is driven by LabVIEW software on which the main operations for processing the signal for demodulating and decoding the frames coming from the sensors are carried out. We can also use LabVIEW to create an intuitive graphical user interface.

The SDR card programming under LabVIEW replicates exactly the same signal processing steps as those performed by a dedicated card based on a specific RF integrated circuit for transmission or reception.

For the receiving (Figure 2), we have created a block diagram that can detect a frame in terms of power, isolating it, demodulating it, and, finally, decoding it to display the content.

Conversely, for transmission (Figure 3), we have created a block diagram with the same steps but in reverse order so as to be able to transmit RF frames through USRP.

One of the main requirements for creating the block diagrams under LabVIEW was to ensure users had access and were able to make changes to a maximum number of parameters relating to RF protocol to transmit or receive.

This solution works because of the combination of USRP hardware and LabVIEW software, which have optimum compatibility and development that is facilitated. 

Sending and Receiving Frames With the Continental Solution

With the LabVIEW programme, frames contained in the ISM frequency band can be sent and received. We can set the frequency, the baud rate, the modulation (ASK or FSK), and the number of bytes to be received as well as code/decode Manchester code. (Figure 4)

The content of the frames to be sent is customisable. We can send a sequence containing a wake-up frame followed by a defined number of frames containing the useful information. (Figure 5)

Most of the variables are configurable, which requires a configuration and initialisation step when first used. After completed, the programme works automatically and doesn’t require any further changes.

In the event of changes in the transmission and receiving protocol, we simply have to restart the software and amend the parameters during the configuration and initialisation step. Then we can use the new protocol.

With this approach, we can save time in development and validation to the tune of up to four weeks, as well as save costs, when compared to the currently implemented solution.

Note, we have not developed the system to perform communication with an object in real time. Sending and receiving frames is done asynchronously. The products being tested today don’t require such a capacity.

It would be possible, however, to develop the programme to include this feature in the future. However, the limitations of our current usage of SDR and LabVIEW software also need to be considered; the signal processing is done on a Windows PC, which doesn’t allow any purely “real-time” processing and leads to a delay of several milliseconds.

Conclusion

The use of the USRP-2900 card and LabVIEW software has validated the SDR approach for transmitting and receiving RF frames for vehicle access or tire pressure monitoring systems. The next step is to assess the integration of this solution in a production environment.