WARP Project Forums - Wireless Open-Access Research Platform

We did not using the AGC at the RX nodes and we connected the nodes by cable+ attenuator to eliminating the wireless channel effects.

We use the same transmit data for WARPLab TX nodes and the same MATLAB (.m) file to demodulate the signals. So from the mechanism of WARPLab, the demodulation results should be the same for WARP v2 and WARP v3 platforms. But some distortions come when we use WARP v3 platforms.   

After many checks, It seems that if we use the WARPLab FPAG for WARP v3 platform, the distortion around the DC subcarrier would appear. Would these distortion really come from the  WARPLab FPAG for WARP v3 platform, which we mentioned in the first post? Or there is another possible reason.

Can you expand on this- what were the degradations near DC? What is your subcarrier spacing (bandwidth / num subcarriers)? Is the DC subcarrier always zero? Can you isolate the issue to a Tx or Rx path, perhaps by using a WARP v2 - v3 link and running the experiment in both directions?

We have tested the experiment of a WARP v2 - v3 link the in both directions. For WARP v3 as transmitter and WARP v2 as receiver, the constellations of the received signals are good. No degradation occurs. However, if we use WARP v2 as transmitter and WARP v3 as receiver, the degradation occurs. So the degradation might come from the RX path of the WARP v3 platform when we are using WARPLab.

The OFDM system we use in our experiment has the bandwidth of 5 MHz, 256 subcarriers, and QAM modulation. The DC subcarrier is always set to zero and the AGC is not used.

The only thing I can think that is related to degradations around DC would be the Rx high pass filter in the MAX2829. The filter bandwidth is controlled by the RXHP signal on the MAX2829. When RXHP=1 the corner frequency is 600kHz; when RXHP=0 it is 30kHz.  ....

It seems be the reason for our problem. because the bandwidth of the subcarrier in our OFDM system is about 19.5 KHz, and the degradation always occurs  at the +/- 15 subcarriers around the DC subcarrier. Would the WARPLab 6 FPGA for WARP v3 set RXHP=1 (the corner frequency is 600kHz) in manual gain control mode? And the WARPLab 6 FPGA for WARP v2 set RXHP=0 (the corner frequency is 30kHz), so the degradation does not occur.


P.S. The same degradation occurs in WARPLab 7 whether we use WARP v2 or WARP v3 platforms.

Last edited by oyyuan (2014-May-23 04:30:49)

It's a simple C code change to control the state of RXHP. In wl_interface.c, find the "case IFC_RX_GAIN_CTRL_SRC" clause and add "radio_controller_setRxHP(RC_BASEADDR, (rfsel), RC_RXHP_OFF);" to the manual gain control mode:

We have tried this for a few days. But we really don't know how to use interface.c file. Shall we need to use mex to compile it? How do we use the "C_Code_Reference" for WARPLab?

Another question for us is if we want to set RXHP for WARPLab 6, how shall we do?

sorry for these basic questions for warplab.

Hi,

We have modified the C code in "wl_interface.c", according to the murphpo's suggestion for WARPLab 7 in WARP v2 Platform.

murphpo wrote:

In wl_interface.c, find the "case IFC_RX_GAIN_CTRL_SRC" clause and add "radio_controller_setRxHP(RC_BASEADDR, (rfsel), RC_RXHP_OFF);" to the manual gain control mode:

Code:

case IFC_RX_GAIN_CTRL_SRC:
	rfsel =  Xil_Ntohl(cmdArgs32[0]);
	agc_en = Xil_Ntohl(cmdArgs32[1]) & 0x1;

	if(agc_en==0){
		//Manual gain control
		radio_controller_setCtrlSource(RC_BASEADDR, (rfsel), RC_REG0_RXHP_CTRLSRC, RC_CTRLSRC_REG);
		radio_controller_setRxGainSource(RC_BASEADDR, (rfsel), RC_GAINSRC_SPI);

		//Force RXHP to zero
		radio_controller_setRxHP(RC_BASEADDR, (rfsel), RC_RXHP_OFF);
		
		...

The problem of this topic is still there.  The degradation also occurs  at the +/- 15 subcarriers around the DC. It seems that  RC_RXHP_OFF is set by default in WARPLab 7.
Is there another reason that would produces this problem and we can fix it?

We also tested our OFDM system for WARPLab 6 - v6p3 in WARP v2 and v3 platforms. The system works well for WARP v2 platform; There is no degradation around DC. But the system  works not good for WARP v3 platform.  (And the same degradation occurs in WARPLab 7 for WARP v2 and WARP v3 platforms).

I think maybe we could compare the settings of WARPLab 6 - v6p3 between WARP v2 platform version and WARP v3 platform version. Maybe the differences or changes between these two versions are the reasons of this degradation. We did do this for the two versions' C codes. But we are not familiar with the hardware register settings and the WARP API functions, so we could not find the differences between these two versions.

Those code blocks perform the same function. The WARP v3 version uses the newer radio_controller core with a different (much cleaner) driver API. In both cases the code:
-Configures the radio_controller to drive the MAX2829 RXHP pin using a software-controlled register bit ("software" control). This disables the hardware control of RXHP, used by the AGC core.
-Configures the MAX2829 to use internal SPI-controlled registers to set the Rx LNA and VGA gains ("software" control). This disables the hardware gain control pins (the MAX2829 "B" port) when in Rx mode.

Did you try the RC_PARAMID_RXHPF_HIGH_CUTOFF_EN changed I mentioned above?

It seems that it happens if we use the newer radio_controller APIs. Could these APIs have some little bugs in them? or they don't perform so exactly the same as their previous APIs.

A radio_controller bug is certainly possible. I'll need to dig into the C and Verilog to see if I missed any connections that control RXHP or the Rx HPF settings.

I apologize for the long delay on this. I didn't find anything at the time, but was recently reminded to revisit the issue and believe I found the underlying problem.

The latest radio_controller driver has a bug which addresses the wrong bit in one register. As a result the application is unable to control the Rx high pass filter cutoff frequency when RXHP = 0. Specifically, it is register 0x8, bit 2, controlled via the radio_controller_setRadioParam(..., RC_PARAMID_RXHPF_HIGH_CUTOFF_EN, x); call. The radio_controller driver was toggling bit 1 (0x2) instead of bit 2 (0x4). This affects radio_controller versions v2_* and v3_*.

The MAX2829 defaults to a setting of 1, giving an Rx HPF cutoff of 30kHz when RXHP=0. This is the better setting for 802.11-style waveforms which don't use the 312kHz around DC. The 802.11 ref design has always assumed the MAX2829 default. The WARPLab ref design does provide an API for changing this parameter from MATLAB. It was seemingly possible to change it by modifying the C code (per post 13 above), but this exercised the radio_controller bug and did not alter the cutoff frequency.

I just committed fixed drivers (svn changeset 4519). These will be used in the next releases of the WARPLab and 802.11 Reference Designs.

To control the Rx HPF cutoff in existing designs, you can use the code below in your C application. This will write the correct register bits in the MAX2829. You should only use mode 0 (cutoff 100 Hz) if your application uses the frequencies near DC. 802.11-style waveforms with no energy in ±156 kHz should keep the default setting of 1.

//Set Rx HPF cutoff to 100 Hz when RXHP=0
radio_controller_SPI_setRegBits(RC_BASEADDR, RX_ANY_RF, 0x8, 0x0004, 0x0);

//Set Rx HPF cutoff to 30 kHz when RXHP=0 - this is the MAX2829 default
radio_controller_SPI_setRegBits(RC_BASEADDR, RX_ANY_RF, 0x8, 0x0004, 0x0004);