Headlines

Headlines

Why Do Mobile Communications and Computing Devices Collide?

Meeting the challenge of embedded wireless vs EMI designs in today’s mobile communication and high speed logic devices.

With the advent of mobile computing, wireless communication has become an integral part of the computer platform. Who would now consider buying a laptop without wireless? At the same time, the once simple communications devices such as cell phones now have functions that require subsystems ordinarily associated with computer devices. So what’s the big deal? The problem is that these devices were never intended to coexist. Communications devices were not designed with high-speed digital logic in mind. High-speed digital logic never included communications as a design vector. The end result is that these devices don’t work well together, so much shoehorning is currently undertaken to make them cohabit in the same device. This shoehorning generally incurs costs in terms of product delays and additional mitigation solutions. It is a sobering thought that 3 dB of noise can reduce the performance of your communications system by 50%. It is even more sobering that 20 or even 30 dB of noise is common on some devices. This work has two main intentions:

1. To provide an education about the principles of radio frequency interference (RFI).

2. To provide a reference source for identifying noise-related issues and mitigating them in your current or future system design explanation.

Interference as a topic is overly broad. In the EMI/EMC world, interference is a system-to-system or environmentto- system phenomenon. Similarly, in the wireless world, interference can be one wireless system to another or a consequence of environment. Electromagnetic interference, or EMI, is measured in field strength (dBμV/m, or decibel ratio referenced to 1 microvolt per meter). In wireless, receive signal strength is a measure of power and is calculated using dBm (or decibel ratio of watts to 1 milliwatt). It is interesting to note that these two seemingly distinct and separate disciplines are so similar yet so different. This work is an attempt to bring these worlds together. You may ask why this is necessary and why now. The answer is quite simple.

In the mid 1990s, computer systems (classified as unintentional radiators by the Federal Communications Commission [FCC]) operated in the hundreds of MHz, and wireless functionality as part of a computer wasn’t even a glimmer in someone’s eye. Laptops were a fairly new device— an evolutionary development of the “luggables” of the early 1990s. Wireless communication (as a mobile feature/device) was essentially limited to cell phones, which were similar in many ways to these luggables. However, this has changed in the last few years.With the launch the Intel® Centrino® brand, wireless functionality became a fundamental part of mobile computing—a must-have. Today, many devices have wireless functionality integrated with computer functions. They range from GPS receivers on our vehicles that we can program for directions to handheld devices that combine a phone, a music player, and an instant and e-mail messaging system. It is clear that this trend will continue and is likely to accelerate. Designing these devices has become increasingly more complex. Although many industry experts talk about the convergence of computers and communications, it is clear that these are still two distinct worlds, and that the devices requiring both functions continue to challenge designers around the world. Why is this so difficult? Today’s multi-usage mobile devices incorporate one or more radios operating from 800MHz to the single-digit GHz. They also incorporate digital circuitry with processing, memory, and storage operating from the high hundreds of MHz to several GHz. This overlap in frequency is the crux of the issue. Today’s radios were not designed with this in mind. RF engineers typically design and simulate the operation of their radios in white or Gaussian noise environments. Today’s digital systems were conceived without any comprehension of wireless communications, and they tend to generate noise that is inherently non-Gaussian. When these two components meet, we have an undefined environment that typically leads to less than stellar operation and below par performance. In some cases, wireless will simply cease to function. What we truly have is a collision between communications and computing. Special attention to this issue will ensure that devices requiring computer and wireless functionality make it to market in the desired timeframe at the required price points.

Wireless vs. EMI

One may ask why EMI regulations do not protect against this type of issue. To answer this question, we must first look at the intent as well as the context of the regulations. When such regulations first appeared, the FCC was concerned primarily with protecting terrestrial broadcasts such as TV and radio. Their major concern was that other devices in close proximity would interfere and disturb the reception of such services. The EMI limits introduced were therefore based on a system-to-system interference model. Hence, they were measured at a distance of 3m, which, among other reasons, was to equate to device (aggressor-to-victim) separation. The limits were indeed intended to provide some level of protection from devices separated by approximately 10 feet, which at a stretch were located in the same room, but likely in an adjacent room or, in fact, next door. So, although perhaps a good starting point, it is clear that these regulations are wholly insufficient in themselves and in some ways completely inapplicable to protection of wireless devices collocated in the same system. In fact, the FCC doesn’t care if you interfere with yourself! To illustrate this point, we’ll look at the existing EMI limits (FCC Part 15 ITE) at 2.5 GHz and compare this to 802.11 b/g wireless sensitivity requirements. For the purpose of this illustration, we will assume that the radio receiver is 3 cm away from the EMI source.

Figure 1.1: Noise measurements on a production notebook.

EMI Limits:

2.5 GHz @1MHz BW = 54 dBμV/m (@3 m)
Translating for distance = 94 dBμV/m (@3 cm) [20 log (300/3)]
Converting to dBm=−13 dBm [dBm = dBμV−107]

Wireless Sensitivity Requirements:
802.11 b/g (11 Mbps)=−86 dBm (@20 MHz)
Converting for BW=−73 dBm (@1 MHz) [10 log (20/1)]

As we can see, there is a 60 dB difference between the EMI limit and the required level to ensure wireless functionality as indicated in the 802.11 specification. In the EMI world, 60 dB is a big number. In the wireless world, it is huge, where 1 and 2 dB performance gains can be the subject and result of a life’s work. In real-world terms, this means that the wireless voltage requirements are 1,000 times more stringent than current EMI regulations. It is also clear that, as stated earlier, meeting EMI requirements is a good starting point at best. This may be a relatively simple model, but it nevertheless enforces the message that EMI/EMC compliance guarantees nothing with respect to wireless functionality when the radio is integrated into the same device as the digital electronics.

To further hit the point home, Figure 1.1 shows a plot of noise measured using 802.11 embedded antennas on a production notebook running between 2.3 and 2.6 GHz.

Two lines are plotted: the wireless sensitivity requirements (assuming a 5 dB noise figure for the radio and incorporating the gain for the antenna used) and the EMI limit for the device in question (FCC Class B). The system in question easily meets EMI requirements, but has considerable noise up to 20 dB above the level required by the integrated 802.11 radio. It is clear that this system may have difficulty operating to specified parameters, depending on what radio channel is used.

Printed with permission from Newnes, a division of Elsevier. Copyright 2008. “Platform Interference in Wireless Systems: Models, Measurement and Mitigration,” by Kevin Slattery and Harry Skinner, Intel®. For more information about this title and other similar books, please visit www.elsevierdirect.com