Best Practices when using the Design

Mitigating the Effects of Distant Interferers

One of the key challenges in running over-the-air experiments is accounting for uncontrolled external interference. While there is no single method for keeping unintended interference from polluting research results, there are a number of techniques that help mitigate harmful effects.

Change your Center Frequency

The simplest solution to avoiding interference is to steer away from it to a different part of the spectrum. The MAX2829 transceiver can be tuned to a variety of different center frequencies in the 2.4GHz and 5GHz bands. Before constructing your over-the-air experiment, it is a good idea to scan for Wi-Fi networks around your setup. There are many freely available tools for determining which channels are being used and how powerful the networks using those channels.

Example Wi-Fi Channel Scan

The above figure shows an example of what you might see after this scan. Given the occupied channels and their relative powers, we can see that 2.4GHz Channel 1 might be a good selection for a channel to run an experiment in.

Make your receivers "intentionally deaf" to very weak signals

Before running an experiment, you should consider what would happen if your design is exposed to weak, but frequent, interference. The 802.11 Rx PHY can only process one packet in any given instant in time. If the PHY starts attempting to decode weak interference, it may be unable to decode your own stronger traffic if it occurs immediately during and after the interference event. Instead, it may make sense to use the "Minimum Packet Detection Power" feature of the design (characterized here). This parameter lets you prevent the PHY from beginning to start processing a packet unless it is sufficient strong to meet a power requirement that you specify. In effect, this is a way to at least partially isolate your test setup from other interferers.

To provide a concrete example of where this function can be useful, consider the DCF with Multiple Flows Application Note. This experiment was to show the interaction of DCF behaviors on a few nodes in a very small tabletop topology. In this experiment, the Tx power was intentionally lowered to a minimum value (-10dBm), resulting in received powers between ​-75 dBm and -70 dBm for the duration of the experiment. At the same time, in the active scan figure above, we can see that there are other Wi-Fi channels near the scanner that packets as low as -90 dBm. If we set the minimum detection power to, say, -80dBm, we can keep the PHY from being "distracted" by the low-level interference and yet still be able to detect our -75 dBm to -70 dBm traffic with high probability. If we hadn't lowered the Tx power so much, we could potentially raise this threshold much more.

Pitfalls: The usage of this feature is highly situational. In the multi-flow appnote, it would have fit pretty seamlessly. Care should be taken when trying to use this feature in other applications. Here are some examples where it may not be appropriate:

• The multi-flow application note had direct line-of-sight links and zero mobility. This had the effect of creating remarkably static channels for the duration of the experiment. You can see this in the plot of receive power, where each line varies minimally. In the presence of non-line-of-sight fading channels like Rayleigh, the receive power of your signal can fluctuate immensely. These fluctuations can potentially drop below the minimum packet detection and cause the design to ignore packets you care about. At a bare minimum, considerably more headroom on this parameter must be allocated when you know that channels will fluctuate significantly.
• The act of ignoring weak but otherwise-decodable packets has subtle implications on random access protocols that should be considered. For example, ignoring a valid reception because it is weak will prevent clear channel assessment (CCA) from registering and deferring to that packet. If your signal is dramatically more powerful, this may not be an issue since you can likely overpower it and still have the receiver be able to decode your packet. If, however, your packet is just a little bit above the minimum packet detection power threshold and another interfering packet is just below the minimum packet detection power threshold, you could actually wind up causing a collision that might have been avoided if you didn't make your receiver so deaf.

In general, it's best to experiment with this parameter. If at first your results are anomalous and you hypothesize that external interference might be to blame, then try raising the threshold.

---

Using the IBSS project as a Monitor and Packet injector