WARP Project Forums - Wireless Open-Access Research Platform

You are not logged in.

#1 2016-Jun-08 06:58:36

Christian
Member
Registered: 2010-Feb-26
Posts: 124

Continous IQ Samples

Hi,

we are looking into the topic of channel estimation w.r.t. deciding if interference is present (be it BT, ZigBee, WHART, WLAN, etc..). For this, we have an algorithm that needs IQ samples for all the subcarriers, but not only after a WiFi packet was detected, but rather in a very periodic manner.
From my understanding of the 802.11 design, the IQ samples are measured using the LTS and stored automatically along in the RX buffer. However, to capture these for non-WLAN signals is impossible this way.

We thought about potentially adding a second bridge, AGC, and RX Phy. Then we disable correlation-based pktDet and enable the energy-based one with very low values, making it trigger constantly, and henceforth, also the later stages of the processing such that we can get at least the samples. I guess we have to route a signal from the PHY which indicates a badPLCP event then.

A better alternative would be to intercept the IQ samples after AGC but before channel EQ, which potentially distorts the samples. These have to be stored in another fixed register similar to the OFDM ref design.

Do you think there is an easier way?

Thanks
Christian

Last edited by Christian (2016-Jun-08 07:26:10)

Offline

 

#2 2016-Jun-08 09:11:32

murphpo
Administrator
From: Mango Communications
Registered: 2006-Jul-03
Posts: 5159

Re: Continous IQ Samples

I don't quite understand the requirements. Does your algorithm need a stream of raw time-domain samples? Or frequency-domain samples (i.e. after the Rx PHY FFT)? Or a stream of frequency-domain channel estimates?

We thought about potentially adding a second bridge, AGC, and RX Phy.

The w3_ad_bridge core interfaces directly to the AD9963 pins; you can't have two bridges connected to the same RF interface. You can definitely connect a second PHY-like core to the bridge's Rx IQ outputs and consume the same sample stream in both cores. The wlan_agc core interfaces directly to the MAX2829 gain control pins; to have two AGC instances you would need to build some sort of mux to select which AGC core has control of the Rx gains at any given time.

Offline

 

#3 2016-Jun-09 06:22:27

Christian
Member
Registered: 2010-Feb-26
Posts: 124

Re: Continous IQ Samples

Ok to clarify, for interference detection we would need time domain and the corresponding frequency domain IQ samples, i.e. before and after FFT.

The setup should look as follows:
One RF interfaces is used for normal operation (PHY, MAC), while in parallel the second interface should sweep over the channels (or stay in one for longer duration) and continuously sample "what's on the air" irrespective of a packet detection event. Potential scaling of an AGC is not that much of a problem, yet it would be preferable to have no channel equalization (could be corrected if the scaling values are also accessible).

Meanwhile I think, adding a core with two large register blocks and a dedicated FFT is better than trying to adapt already present cores, isn't it? Maybe we can reuse some functionality of the WARPlab cores?

Offline

 

#4 2016-Jun-09 09:57:06

chunter
Administrator
From: Mango Communications
Registered: 2006-Aug-24
Posts: 1212

Re: Continous IQ Samples

murphpo wrote:

I don't quite understand the requirements. Does your algorithm need a stream of raw time-domain samples? Or frequency-domain samples (i.e. after the Rx PHY FFT)? Or a stream of frequency-domain channel estimates?

I think this remains unanswered in your reply -- we are still confused on the architecture you are envisioning. Where is your algorithm implemented? Is it implemented directly in the FPGA fabric? If so, you can use a FFT block and consume the inputs (time) and outputs (frequency) directly in the implementation of your algorithm. Or is the algorithm running in a Microblaze? Or a host PC that is tethered to the board via Ethernet? Does you algorithm operate on a burst of recorded samples periodically, or does it operate on a continuous stream of time-domain and frequency-domain samples?

Christian wrote:

... the second interface should sweep over the channels (or stay in one for longer duration) and continuously sample "what's on the air" irrespective of a packet detection event. Potential scaling of an AGC is not that much of a problem, yet it would be preferable to have no channel equalization (could be corrected if the scaling values are also accessible).

I'm confused by the use of "equalization" here. That isn't in reference to the PHY notion of channel equalization, right? You can leave an AGC off on the second interface that is tied for your FFT, but that will have implications on the spectrum measurement via your FFT. If you want the FFT to be sensitive to low Rx powers, you'd need to leave the gains high. But that will come at the cost of saturating the ADCs in moderate to high power receptions. The FFT of a saturated [-1,+1] signal may not be very useful. You might consider using a custom AGC implementation that triggers based upon RSSI changes (i.e. starts on the sudden increase in Rx power).

Offline

 

#5 2016-Jun-09 12:14:43

Christian
Member
Registered: 2010-Feb-26
Posts: 124

Re: Continous IQ Samples

I am sorry for not being specific enough. The idea is to have some interference detection algorithm, first purely running in C on CPU high. This algorithm would have to grab at certain intervals time domain and corresponding frequency domain samples from a frequency range to which RFB is currently tuned to. Then it would either wait and grab another IQ sample set, or re-tune RFB to another channel and redo a measurement for further processing. The point here is that the algorithm should also detect some narrowband interference not caused by WiFi. Meanwhile, CPU low and RFA are operating normally, i.e. execute the DCF for example.

My reasoning and explanations were driven until now by trying to use the existing PHY implementation (or a copy of it operating on RFB) for this purpose. Hence, yes, I was referring to the PHY notion of channel equalization, but this may not make sense if the PHY core (and the included FFT) is not utilized. In the end, the system should be sensible to all reasonable RX power ranges. I will clarify with my colleague on whether the standard AGC core is sufficient for him. I guess, for a first shot, this will be ok. I am more concerned about a logic that is capturing the time domain and associated frequency domain samples to let CPU high access this. I guess, we will need a BRAM segments that is filled from hardware. Once SW wants a sample set, HW fetches from the continuously incoming IQ samples a series of time samples to store them in the BRAM segment, while the FFT also processes them. These are then also stored in the BRAM segment. Then, HW resets the indicator, meaning the segment contains time and freq samples that can then be read safely from SW.
Depending on the exact requirements of the detection algorithm, e.g. the need of a batch of time and corresponding freq domain samples, we may need multiple BRAM segments that are filled subsequently.

Do you think this is a feasible approach?

Offline

 

#6 2016-Jun-09 16:38:26

murphpo
Administrator
From: Mango Communications
Registered: 2006-Jul-03
Posts: 5159

Re: Continous IQ Samples

This seems generally feasible. A few things to consider:

-The radio_controller core is connected to the peripheral interconnect of CPU Low. As a result CPU High cannot re-tune an RF interface. It must send an IPC message to CPU Low which re-tunes to the requested channel. This latency may not be tolerable for your application. It is possible to move the radio_controller to the shared interconnect so that both CPUs can access the core. You would need to build some mutual exclusion scheme to prevent the CPUs from attempting simultaneous SPI writes via the radio_controller API.

-As Chris mentioned the FFT core will only produce a valid transform if its inputs are in range. Overflow during a transform will corrupt the outputs. You will need some sort of AGC to control Rx gains on the secondary interface. The wlan_agc core operates synchronous to packet detection in the Rx PHY. The Rx PHY asserts packet detection. This starts the AGC state machine. The AGC then locks gains until the Rx PHY de-asserts packet detection. For a long-running, asynchronous "PHY" like you describe, a continuously tracking AGC may be more appropriate. You would need to ignore samples around gain changes (i.e. hard to use the FFT of a time-domain sequence exposed to multiple gain settings). One approach would be to use software to pause the tracking AGC and trigger a sample capture/transform in your custom core, then release the AGC.

-Sysgen supports Shared Memory blocks which are BRAMs that are mapped into the address space of the AXI interconnect. This is a better approach (more likely to meet timing) than a large number of discrete "From" or "To" registers. Sysgen Shared Memory blocks are 32-bit memories and are connected to the Sysgen core's standard AXI4-Lite interface. If you need the higher throughput / lower latency you can build a BRAM interface in Sysgen that connects to an external 64-bit bram_block instance. This is how WAPRLab implements the on-chip sample buffers and how the 802.11 Tx/Rx PHY cores connect to BRAM packet buffers.

Offline

 

Board footer