2.4GHz Intra-System (or Self/Platform) Interference Demonstration

In this blog we are going to take a short look at noise and interference in the 2.4GHz band. Our example victim is a Zigbee controller and the sources are nearby USB3.0 devices and Wi-Fi sources.

 

Background

One of our customers makes these rather useful USB Zigbee Coordinator sticks, frequently used for controlling smart home or IoT devices like light bulbs.

These devices operate at 2.4GHz, a very crowded frequency band with Wi-Fi, Bluetooth and Zigbee all fighting for a narrow, congested slice of spectrum.

One of the common issues faced by users of this band is that of intra-system interference, sometimes referred to as “self” or “platform” interference. This is where components in the same system interfere with each other, primarily due to their proximity.

[Note: The counterpart to intra-system (within the system) in this context would be inter-system interference (between separate systems), which is what the conventional EMC test regime of radiated and conducted emissions and immunity seek to characterise.]

This common problem is something that our customer knows all too well from helping their clients integrate these Zigbee products into the end application.

So, during a recent visit to our lab for some testing on a related product, we spent some time investigating this noise on a typical setup.

 

Demonstration Setup

The setup in the below image is common to many users with a Raspberry Pi Model B and lots of stuff plugged in to the USB ports. In this case, a Zigbee adaptor (black case) and an USB3.0 SSD in close proximity.

These parts, including the spectrum analyser, is part of the customers in-house electronics development laboratory.

 

 

The effects of USB3.0 on the 2.4GHz spectrum are well known. A good example is this 2012 paper from Intel which

For this demo, we used a near field capacitive probe and a 2.4GHz antenna to measure noise in the 2.4GHz to 2.5GHz band local to the Raspberry Pi.

This demonstrated the degradation of the noise floor with various levels of system activity including

• Measurement of system noise floor
• Presence of a USB3.0 SSD running a large file transfer using the dd Linux command
• Activation of the Raspberry Pi internal Wi-Fi

The below image shows three traces under these different conditions.

 

 

Experiment Conclusions

The conclusions we can draw about the in-band noise are:

• Noise from the SSD raises the noise floor by approximately 10-20dB (a factor of x10 to x100)
• The Wi-Fi transmission from the Pi is 40dB above the local noise floor. This will mask any received Zigbee signals from a remote transmitter.

 

In-Band vs Out-of-Band Sensitivity

Well designed radio systems are generally very robust to out-of-band interference i.e. anything outside of the narrow radio band that it is tuned to. For instance, a Zigbee radio system set to channel 20 (2.450GHz) will reject anything below 2.445GHz and above 2.455GHz.

 

Intra System Interference Diagnosis

Advice on diagnosing these issues is mostly outside the scope of this short blog. Differences in systems, components and ambient noise levels makes it impractical to offer guidance for all situations. However, some generic problem solving pointers are presented below.

A systematic approach to isolating the problem is required.

One of the primary rules of problem solving is to change only one thing at once and observe the effects.

In EMC terms, it is possible to change several things at once without realising it. Cable position, the specific port that a device is plugged into, location of nearby equipment and cables, even how firmly a connector is tightened will all make small differences that stack up. (Don’t use anything other than a torque spanner on those SMA connectors though!)

Another key rule is if you think something has made a difference, reverse the change and see if the problem re-occurs. Unless you can achieve consistency then you might be changing something else unintentionally, or the problem is caused by something outside of what you are changing.

Correlating the problem against time can help. Does it happen when something else happens (other devices on, or off, or switching, certain configurations, times of day, etc.) This can give clues.

Lastly, we should be looking for a significant step change in improvement to identify the issue. Phrases like “I think it made a bit of a difference but I’m not sure” indicates that we are dancing around the issue and not getting to the heart of it.

Ultimately, for a detailed understanding, the spectrum analyser is a key tool in gaining a proper grasp of this issue.

 

Solutions

The solutions to the problem are simple yet sometimes difficult – a technical balance needs to be struck.

Use of Ethernet rather than Wi-Fi on the Raspberry Pi.

It is not practicable to synchronise transmission from the Raspberry Pi Wi-Fi with that of the Zigbee stick. The simplest way of ensuring the Wi-Fi does not interrupt the Zigbee transmissions is to disable the Wi-Fi and provide network connectivity via Ethernet instead.

Depending on the installation this might not always be practicable but it certainly is more reliable.

 

Separation of components

Moving the antenna away from the noise source is usually the best way to achieve increased performance.

In this instance, placing the module at the end of a USB cable and away from other electronic items is a good start.

Another option that is not as ideal: a good quality SMA extension cable could be used to extend the antenna away from the problem area. This introduces loss into the RF channel, reducing signal quality.  Measurements made in our lab on a cheap extension cable from RS show a power reduction of 6.5dB at 2.4GHz for a 5m cable. This equates to a ratio of around 0.25 meaning we are broadcasting and receiving a quarter of the power we were before.

Also, it is still possible for the noise to couple onto the nearby module even without the antenna attached meaning the problem does not get entirely resolved.

 

Better quality components

Sourcing a bunch of cheap-as-possible parts from Amazon or eBay is likely to bring problems.

Using devices from big name manufacturers and buying from reputable sources helps. But, even reputable components are designed to a price point and can still cause problems if the other points in this blog are not taken into account.

USB cables can be a big source of the problem. Unshielded back shells (the part between cable screen and connector body) compromise the shielding to the point where their performance at high frequencies is equivalent to an unshielded cable.

The only way to tell if a cable is good quality is to perform an autopsy on the ends and check on the cable shielding

Remember that Pawson’s Law of Cable Quality states that the EMC performance is inversely proportional to the physical appearance. Braided covers, shiny plating, metal connector bodies, transparent mouldings etc are all indications of money spent on the OUTSIDE of the cable. EMC quality comes from the INSIDE and is not visible.

 

 

Hope this was useful! See you soon.

James