New and improved wireless devices hit the street with dizzying regularity. As such, the potential for in-vehicle interference from multiple devices using multiple protocols becomes unavoidable. Stepping up to the plate, Intelligent tools and CQDDR encoding offer an elegant solution to these in-vehicle RF range and interference issues.

By Ken Noblitt

Handsfree mobile phone operation in vehicles offers a huge potential market for Bluetooth and kits are already finding their way into both after-market solutions and embedded designs. Alongside handsfree mobile phone operation, future Bluetooth applications in-vehicle will include Internet access, wireless additions to the infotainment system, vehicle personalization and even vehicle diagnostics.

To make all of this possible, there are problems that need to be overcome. Other RF devices such as car stereo, GPS navigation equipment, Satellite Digital Audio Radio Service (SDARS), GSM transceivers and other electrical devices that are already in-vehicle can cause interference or be susceptible to interference. Also, think of a car as a reflective "tin-can," where radio waves are reflected within the vehicle cabin. This typically results in a phase shift that, with superposition, can effectively cancel out or corrupt the wanted signal.

All this RF activity can be detrimental to the data throughput of a wireless system in a vehicle. As the applications for Bluetooth expand as discussed, Bluetooth modules are likely to become more widespread around the car, further compounding the potential risk of interference.

Unique to Vehicle Issues

Bluetooth already has an existing arsenal of defenses, designed into the standard, to combat interference. The unique and difficult conditions within a car have meant that designers have had to sharpen their swords in order to lessen the considerable potential effects of interference.

Figure 1. Effective bandwidth plotted against increasing BER.

One of Bluetooth's standard weapons is frequency hopping which requires both the receiver and transmitter to tune/hop to one of its 79 different channels 1,600 times per second in a predetermined pattern. This provides a good level of immunity to interference. However, if a data packet is lost or received incorrectly, no acknowledgement will be returned and a retransmission will be sent at the next available time slot.

By utilizing frequency hopping technology and with care taken to separate the Bluetooth antennas from other sensitive in-cabin receivers or transmitters, interference can be minimized. But even with these measures in place a high amount of RF activity in the vehicle cabin can be detrimental to data throughput and link reliability.

Understanding BT Packets

Most Bluetooth products support all data packet types. However, if the IC's firmware decides to employ a type that doesn't match the noise environment, one can end up with a very inefficient communications link. For example noise, caused by users pushing products beyond their limits for range and noise immunity, and other wireless equipment operating in the same band (e.g. Wi-Fi).

The Bluetooth standard offers a range of data packet types, known as DH and DM. H types have higher payloads; M types support medium payloads but include forward error correction for integrity in noisy operating conditions. All have CRCs for error detection, but this cannot correct errors. The payloads of DM packets are divided into blocks of 10 bits, with an additional five bits for FEC. These can be used to detect and correct all 1-bit errors, and to detect and reject all 2-bit errors in each 10-bit block.

Figure 2. CQDDR lets the Bluetooth device dynamically switch packet types according to link conditions.

Choosing Packet Types

Although DH packets, particularly DH5, look like they give the best performance, in the real world things aren't so simple. To ensure a good user experience, packet types must be chosen not just on the basis of how much data is waiting to be sent, but also on the ambient error conditions which can greatly vary in a vehicle cabin. There are several possible ways this can be achieved within the current specification.

Designers of each layer of the stack can choose either to add an extra layer of error detection, and optionally correction, to their layer, or they can pass on the data unmodified. The former allows them to make a stronger reliability guarantee than the layer below, whereas the latter keeps the layer overhead low. In particular, the overhead for error correction (as opposed to mere detection) is high. Typically, all the data sent by a layer must be buffered in that layer until it is acknowledged (implicitly or explicitly) by the other side. As flow progresses up the stack, the data transfer latencies get higher, and hence the amount of buffering increases. A simplistic baseband implementation may choose the packet type purely on the number of octets it has waiting to be sent. This means that when there are many waiting it will choose DH5 packets as these have the largest payload. In laboratory conditions, this may look like a good solution, but users will ultimately be frustrated. At a BER of 0.04%, for example, DH5 packets have only a 33% chance of being received without error. In other words, it will take an average of three attempts to send a packet — reducing potential maximum bandwidth from 723 kb/s to just 241 kb/s.

On the other hand, DM5 packets show virtually no degradation from their maximum bandwidth of 477 kbits/sec until 10 times that BER (See Figure 1).

A Useful Bluetooth-Standard Option

There is a mechanism built into the Bluetooth scheme (v1.1 of the Bluetooth specification) which, if correctly implemented, solves range and constant interference issues. It is called CQDDR. CQDDR is a Bluetooth option, which ensures designers that products, will achieve the optimum data throughput. CQDDR allows a receiving device to negotiate with the transmitter to change the transmitted packet type according to the conditions experienced at the receiver. It requires access to packet and BER statistics to make an intelligent trade-off between bandwidth and data integrity. With CQDDR, if one side finds that it's receiving packets with lots of errors it tells the other side to switch to DM packets. If the link clears up, then it can allow the other side to use DH packets again (See Figure 2).

Surprisingly few companies have implemented CQDDR in their firmware in spite of the great improvements it brings to data transfer and link reliability in environments such as a vehicle cabin.

Bluetooth — The Right Choice for the Vehicle

The incredible amount of functionality that Bluetooth could enable in vehicles requires thought and foresight to implement. By taking care to consider the entire vehicle system, automotive designers can avert many of the problems associated with implementing a Bluetooth system. Interference control is a vital element for any RF designer, and the vehicle environment only magnifies this factor.

With the number of safeguards already put into place in the Bluetooth standard, designers are almost there. CQDDR offers the opportunity for automakers and OEM suppliers to ensure interference is not an issue and to deliver on Bluetooth's promise of a multifaceted wireless connectivity.


CQDDR — Channel Quality Driven Data Rate
CRC — Cyclic Redundancy Check
DH — Data, High Rate
DM — Data, Medium Rate
FEC — Forward Error Correction
GPS — Global Positioning System
GSM — Global System for Mobile Communications (or Groupe Spécial Mobile)
SDARS — Satellite Digital Audio Radio Service

Ken Noblitt, Technical Development Director for CSR, Inc., holds an MSEE from Southern Methodist University, a BSEE from The University of Texas at Arlington, and has 22 years of experience in many different spread spectrum systems in the commercial, government and military sectors. He joined CSR in October 2000 from NEC Semiconductor, where he was Field Applications Manager for System-on-a-Chip (SoC) solutions including Wireless, USB, ATM, DSL, and custom high density ASIC solutions. Noblitt was previously an R&D Program Manager and CDMA architect at Nokia, and a Sr. Systems Engineering Manager at Boeing and E-Systems (Raytheon), and speaks frequently at industry events concerning business development and engineering design for cellular handsets.