WARP Project Forums - Wireless Open-Access Research Platform

murphpo · 2014-Jan-26 23:51:00

A user asks:

The PHY layer description in the wiki (http://warpproject.org/trac/wiki/802.11/PHY) says: "Smaller bandwidths are supported by reducing the duty cycle of the sample_valid signal at the input to the Rx pipeline/at the input to sample FIFO at the RF interface ports”. Is it possible to have more details about how to do this?

The Tx and Rx PHY models run at 160MHz and support sample frequencies up to 20MHz. The ratio of system clock to sample clock must be >=8.

I've tested sample periods >8 in simulation successfully, but have not tried this in hardware.

The wlan_phy_rx_pmd input sample rate is set by the rate of the iq_valid signal in the top-level Inputs block. In the current design this signal is generated using a constant "1" with sample period T=8, passed through an upsample-by-8 block to generate a pulse that asserts 1 of every 8 cycles. This pulse is used by downstream logic as the I/Q qualifier.

To reduce the PHY sample rate adjust the sample period of the constant "1" and the corresponding upsample rate. For example to simulate a 10MHz waveform set the constant's sample period and the upsample rate to 16.

The wlan_agc model uses a similar design. The AGC and PHY Rx I/Q streams must run at the same rate.

The wlan_phy_tx_pmd output sample rate is controlled by the external DAC_TX_CLK signal. This signal must have one rising edge per desired output sample. In simulation this signal is driven by a pulse generator that asserts with period T=8. To simulate a narrower waveform change the period of the pulse generator.

In the reference design hardware the DAC_TX_CLK port is driven by a 20MHz clock. The same clock drives the w3_ad_bridge tx_clk ports, which in turn drive the AD9963 TXCLK port. Using the same signal here ensures a valid relationship between the I/Q samples and clock driven into the AD9963.

The DAC_TX_CLK arrangement is new in the v0.7 design (previous versions of the Tx PHY generated the Tx I/Q valid signal internally). I'm planning to move the Rx I/Q valid signal to a port as well; I just didn't have time before we posted v0.7.

Until now I have modified the Period and the Pulse width of Pulse Generator2 in wlan_phy_tx_pmd/Start Ctrl to 32 and 16 respectively and the Sample period of Constant8 in wlan_phy_rx_pmd/Inputs to 32 (in this case I want a band of 5MHz). Is this correct? In order two have two WARPs that interact using a smaller bandwidth than 20MHz, is it enough to modify the TX/RX cores or is it necessary to change
something else? For example, using XPS I’ve seen that a 20MHz clock is connected to the dac_tx_clk port of the wlan_phy_tx core and to the sys_samp_clk_Tx, sys_samp_clk_Tx_90 and sys_samp_clk_Rx ports of the ad_bridge_onBoard core. Given the changes to the TX/RX cores I’ve described above, can I leave this clock untouched or must I reduce its frequency to 5MHz?

Actually using slower sample periods in hardware is more complicated. The sample periods assumed by the PHY must be honored by the connected logic and clocks.

In the ref design the AD9963 reference clock is 40MHz. This clock drives both the ADCs and DACs. The ADC 2x decimation filter is enabled, giving a sample rate of 20MSps at the TRXD port. The DAC 2x interpolation filter is enabled, giving a sample rate of 20MSps at the TXD port. The w3_ad_bridge rx_clk port must run at the same frequency as the TRXD port. The w3_ad_bridge tx_clk ports must run at the frequency expected by the TXD port. Thus, in the reference design all three w3_ad_bridge clocks are tied to a 20MHz clock.

Narrower bandwidths will require changing the sample rate at the PHY I/Q ports. The quickest approach would be to reduce the AD9963 reference clock (currently configured on line 285 of wlan_phy_util.c). For example, for a 10MHz bandwidth:
1) Update the AGC and Rx PHY models as described above
2) Change the AD9963 clock to 20MHz in wlan_radio_init():
clk_config_dividers(CLK_BASEADDR, 4, (CLK_SAMP_OUTSEL_AD_RFA | CLK_SAMP_OUTSEL_AD_RFB)); //80MHz/4 -> 20MHz
3) Leave the AD9963 2x interpolation and decimation filters enabled
4) In system.mhs change the frequency of the MMCM output for clk_20MHz and clk_20MHz_90degphase to 10MHz (also change the signal names from _20MHz to _10MHz, for sanity's sake)
BEGIN clock_generator
PARAMETER INSTANCE = clk_gen_proc_bus_clks
....
C_CLKOUT2_FREQ = 10000000
C_CLKOUT3_FREQ = 10000000

Step (1) won't be required in future releases (I'm planning to update the AGC and Rx models to use an external IQ_valid signal, like the Tx model does in v0.7).

While this approach will probably work, my guess is the PHY performance won't be great in the presence of off-channel interference. It would be much better to run the ADCs and DACs faster and implement additional decimation/interpolation filters. Using rate-change filters will reduce the impact of noise and interference outside your band of interest. The AD9963 implements interpolation by 2x/4x/8x. However it only provides 2x decimation. Additional decimation must be implemented in the FPGA. The Sysgen FIR Compiler block with a halfband impulse response would be a good starting point.

Finally, supposing I will be able to generate a new bitstream, does the lower-level MAC implementation support the smaller bandwidth natively or is it necessary to modify it? For example, the radio controller initialisation code.

If the PHY is transmitting and receiving valid packets the MAC will work. However the narrower bandwidth modes in 802.11 assume different values for the various IFS times and the ACK timeout. I believe these are well parameterized in our code, so updating them should be possible with only C code changes.

One last question, have you any plan to support dynamic bandwidth configuration in future releases of 802.11 Reference Design?

We may add this in the future, but it's not imminent. We're currently pushing hard to finish the framework for running experiments with the 802.11 design ("wlan_exp"). This will enable some very cool features, like per-packet logging at every node in a network for offline analysis of MAC and PHY behaviors. Any new PHY features would come after this.

welsh · 2015-May-07 16:45:37

For future reference, one of our users ran into an issue when changing CLKOUT2 and CLKOUT3 to 10 MHz. You can find the issue and solution in this thread.

alice_warp · 2015-Nov-13 10:08:51

Hi to all!
I have a question about this topic.
I did what you said and all work, but it is a static view. I would create something of dynamic. I created an input that selects which filter to enable (10 MHz or 5 MHz), then I use muxs for multiplexing the generated outputs.
Obviously I changed the clocks of tx core and agc core (rx core's clock remains the same because filters have a 2x and 4x decimation, respectively).
I attach my scheme.

I generated pcores and bitstream without problems, but when I tried it doesn't work, it seems that there is a problem in the demodulation.
Can it be a synchronization problem?

Thank you in advance!

Alice

murphpo · 2015-Nov-13 14:02:26

You'll have to provide more details about what you've changed from the reference design. The screenshot above only shows FIR filters inline with the Rx ADC I/Q signals. Are these filters configured as decimators? You mention changing clocks in the Tx and AGC cores - what specifically did you change? Did you test your modified Tx/Rx PHY designs in simulation? You should run the Tx PHY sim, capture the I/Q output (saved by default to workspace variable 'wlan_tx_out'), then use this I/Q signal as the input to your Rx PHY model. This must work in simulation for anything to work in hardware.

alice_warp · 2015-Nov-14 14:48:35

murphpo wrote:
Are these filters configured as decimators?

Yes, the first 2x decimator and the second 4x decimator.

murphpo wrote:
You mention changing clocks in the Tx and AGC cores - what specifically did you change?

In the tx core nothing, but in the agc core I implemented three clocks and a mux with an input selection (from register).
I also changed the output of the clock_generator in FPGA. I'm trying to make a dynamic module for changing dinamically these clocks.
I implemented two static solutions (10 MHz and 5 MHz) and all work, but I'm trying to do these dinamically without reprogramming FPGA.

murphpo wrote:
Did you test your modified Tx/Rx PHY designs in simulation? You should run the Tx PHY sim, capture the I/Q output (saved by default to workspace variable 'wlan_tx_out'), then use this I/Q signal as the input to your Rx PHY model. This must work in simulation for anything to work in hardware.

No, I haven't tested yet, but I'll do it.

Thank you for the advice!

...

Now, I did what you suggested me. I ran the Tx PHY sim with a pulse generator with period 16 and 8 pulse width.
I captured the I/Q output and then used this I/Q signal as the input to my Rx PHY model. The Figure 1 shows what I see in the XY graph before the error in Figure 2. However, the specifications of the mux are in Figure 3.

Figure 1

Figure 2

Figure 3

Any suggestions are welcome!
Thank you!

Alice

Last edited by alice_warp (2015-Nov-16 08:06:51)

murphpo · 2015-Nov-16 08:27:35

A few suggestions:
-Make sure your Tx -> Rx simulation flow is working normally for unmodified (20 MHz bandwidth) designs. You can also check your Rx model in 20 MHz mode using one of the Rx signals included in .mat files with the reference design.

-The error "Overflow detected" indicates your changes have caused one of the I/Q signals to overflow. This will definitely cause errors during reception. You should make sure your decimation filters have gain of 1 (or less). You can use Simulink scopes to observe the input/output signals to see which filter path is generating signals too large for the Fix16_15 type.

murphpo · 2015-Nov-16 09:13:07

One other debugging step, to help isolate issues between Tx and Rx- you can start with one of the reference waveform (the .mat files in the ref design), interpolate this waveform by 2x or 4x (i.e. using MATLAB's interp or upfirdn commands), then feed this into your custom Rx model. You should be able to receive one of these "perfect" lower-bandwidth waveforms in simulation with no errors. You definitely want to see this work before trying the design in hardware.

alice_warp · 2015-Nov-16 10:18:44

murphpo wrote:
A few suggestions:
-Make sure your Tx -> Rx simulation flow is working normally for unmodified (20 MHz bandwidth) designs. You can also check your Rx model in 20 MHz mode using one of the Rx signals included in .mat files with the reference design.

One other debugging step, to help isolate issues between Tx and Rx- you can start with one of the reference waveform (the .mat files in the ref design), interpolate this waveform by 2x or 4x (i.e. using MATLAB's interp or upfirdn commands), then feed this into your custom Rx model. You should be able to receive one of these "perfect" lower-bandwidth waveforms in simulation with no errors. You definitely want to see this work before trying the design in hardware.

Ok, I'll do it, thank you very much!

murphpo wrote:
-The error "Overflow detected" indicates your changes have caused one of the I/Q signals to overflow. This will definitely cause errors during reception. You should make sure your decimation filters have gain of 1 (or less). You can use Simulink scopes to observe the input/output signals to see which filter path is generating signals too large for the Fix16_15 type.

I don't understand the reason of this error. The output signals of the both filters are Fix16_13, but the output signal of the mux is Fix18_15 when I put full precision in the output tab of the mux. Why?

Last edited by alice_warp (2015-Nov-16 10:21:52)

murphpo · 2015-Nov-16 19:14:15

I don't understand the reason of this error. The output signals of the both filters are Fix16_13, but the output signal of the mux is Fix18_15 when I put full precision in the output tab of the mux. Why?

The Rx PHY pipeline assumes the I/Q inputs are limited to ±1. This assumption carries through to the waveform processing blocks, like the CFO estimation/correction blocks and FFT. In the reference Rx PHY the I/Q inputs are Fix12_11. You should adjust your filter gains to maintain the ±1 range. You can use a Covert block to re-cast the filter outputs to FixN_(N-1), then monitor this conversion for overflow. If this conversion overflows, adjust the filter gain (average coefficient magnitude) to compensate.

alice_warp · 2015-Nov-19 02:32:05

murphpo wrote:
I don't understand the reason of this error. The output signals of the both filters are Fix16_13, but the output signal of the mux is Fix18_15 when I put full precision in the output tab of the mux. Why?
The Rx PHY pipeline assumes the I/Q inputs are limited to ±1. This assumption carries through to the waveform processing blocks, like the CFO estimation/correction blocks and FFT. In the reference Rx PHY the I/Q inputs are Fix12_11. You should adjust your filter gains to maintain the ±1 range. You can use a Covert block to re-cast the filter outputs to FixN_(N-1), then monitor this conversion for overflow. If this conversion overflows, adjust the filter gain (average coefficient magnitude) to compensate.

Thank you! It seems to work now.
It is slow to receive at 10 and 5 MHz, maybe because of the high order of the filter, but it's another problem.
Thank you so much!

Alice

Last edited by alice_warp (2015-Nov-19 02:32:30)

alice_warp · 2015-Nov-25 06:48:47

Hi to all,
I tried to fix the problem about the slow receiving. I used an Atheros board ath9k at 10 MHz. In the attachment there are the iperf logs about the throughput.
TX Atheros --> RX WARP

------------------------------------------------------------
Server listening on UDP port 12345
Receiving 1470 byte datagrams
UDP buffer size: 112 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.4.1 port 12345 connected with 192.168.4.100 port 44572
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 3] 0.0- 1.0 sec 158 KBytes 1.29 Mbits/sec 16.869 ms 8546/ 8656 (99%)
[ 3] 0.0- 1.0 sec 10 datagrams received out-of-order
[ 3] 1.0- 2.0 sec 177 KBytes 1.45 Mbits/sec 9.244 ms 0/ 123 (0%)
[ 3] 2.0- 3.0 sec 181 KBytes 1.48 Mbits/sec 10.859 ms 0/ 126 (0%)
[ 3] 3.0- 4.0 sec 167 KBytes 1.36 Mbits/sec 24.925 ms 0/ 116 (0%)
[ 3] 4.0- 5.0 sec 201 KBytes 1.65 Mbits/sec 22.856 ms 0/ 140 (0%)
[ 3] 5.0- 6.0 sec 197 KBytes 1.61 Mbits/sec 27.659 ms 0/ 137 (0%)
[ 3] 6.0- 7.0 sec 171 KBytes 1.40 Mbits/sec 12.210 ms 0/ 119 (0%)
[ 3] 7.0- 8.0 sec 189 KBytes 1.55 Mbits/sec 14.335 ms 0/ 132 (0%)
[ 3] 8.0- 9.0 sec 181 KBytes 1.48 Mbits/sec 31.356 ms 0/ 126 (0%)
[ 3] 9.0-10.0 sec 192 KBytes 1.58 Mbits/sec 8.602 ms 0/ 134 (0%)
[ 3] 10.0-11.0 sec 159 KBytes 1.31 Mbits/sec 22.620 ms 0/ 111 (0%)
[ 3] 11.0-12.0 sec 187 KBytes 1.53 Mbits/sec 27.254 ms 0/ 130 (0%)
[ 3] 12.0-13.0 sec 174 KBytes 1.42 Mbits/sec 12.809 ms 0/ 121 (0%)
[ 3] 13.0-14.0 sec 168 KBytes 1.38 Mbits/sec 28.077 ms 0/ 117 (0%)
[ 3] 14.0-15.0 sec 149 KBytes 1.22 Mbits/sec 21.836 ms 0/ 104 (0%)
[ 3] 15.0-16.0 sec 168 KBytes 1.38 Mbits/sec 10.693 ms 0/ 117 (0%)
[ 3] 16.0-17.0 sec 149 KBytes 1.22 Mbits/sec 40.912 ms 0/ 104 (0%)
[ 3] 17.0-18.0 sec 145 KBytes 1.19 Mbits/sec 29.768 ms 0/ 101 (0%)
[ 3] 18.0-19.0 sec 113 KBytes 929 Kbits/sec 19.804 ms 0/ 79 (0%)
[ 3] 19.0-20.0 sec 135 KBytes 1.11 Mbits/sec 14.309 ms 0/ 94 (0%)
[ 3] 20.0-21.0 sec 141 KBytes 1.15 Mbits/sec 12.321 ms 0/ 98 (0%)
[ 3] 21.0-22.0 sec 125 KBytes 1.02 Mbits/sec 15.322 ms 0/ 87 (0%)
[ 3] 22.0-23.0 sec 126 KBytes 1.03 Mbits/sec 17.018 ms 0/ 88 (0%)
[ 3] 23.0-24.0 sec 118 KBytes 964 Kbits/sec 23.019 ms 0/ 82 (0%)
[ 3] 24.0-25.0 sec 126 KBytes 1.03 Mbits/sec 25.963 ms 0/ 88 (0%)
[ 3] 25.0-26.0 sec 123 KBytes 1.01 Mbits/sec 38.014 ms 0/ 86 (0%)
[ 3] 26.0-27.0 sec 102 KBytes 835 Kbits/sec 17.668 ms 1/ 72 (1.4%)
[ 3] 27.0-28.0 sec 111 KBytes 906 Kbits/sec 29.646 ms 0/ 77 (0%)
[ 3] 28.0-29.0 sec 99.1 KBytes 811 Kbits/sec 14.503 ms 1/ 70 (1.4%)
[ 3] 29.0-30.0 sec 112 KBytes 917 Kbits/sec 23.439 ms 0/ 78 (0%)
[ 3] 30.0-31.0 sec 99.1 KBytes 811 Kbits/sec 17.026 ms 0/ 69 (0%)
[ 3] 31.0-32.0 sec 108 KBytes 882 Kbits/sec 23.518 ms 0/ 75 (0%)
[ 3] 32.0-33.0 sec 111 KBytes 906 Kbits/sec 39.950 ms 0/ 77 (0%)
[ 3] 33.0-34.0 sec 135 KBytes 1.11 Mbits/sec 35.104 ms 0/ 94 (0%)
[ 3] 34.0-35.0 sec 109 KBytes 894 Kbits/sec 19.136 ms 0/ 76 (0%)
[ 3] 35.0-36.0 sec 66.0 KBytes 541 Kbits/sec 34.096 ms 2/ 48 (4.2%)
[ 3] 36.0-37.0 sec 74.6 KBytes 612 Kbits/sec 19.404 ms 1/ 53 (1.9%)
[ 3] 37.0-38.0 sec 96.2 KBytes 788 Kbits/sec 34.800 ms 0/ 67 (0%)
[ 3] 38.0-39.0 sec 94.7 KBytes 776 Kbits/sec 19.939 ms 0/ 66 (0%)
[ 3] 39.0-40.0 sec 76.1 KBytes 623 Kbits/sec 24.659 ms 0/ 53 (0%)
[ 3] 40.0-41.0 sec 89.0 KBytes 729 Kbits/sec 50.883 ms 0/ 62 (0%)
[ 3] 41.0-42.0 sec 93.3 KBytes 764 Kbits/sec 24.016 ms 0/ 65 (0%)
[ 3] 42.0-43.0 sec 126 KBytes 1.03 Mbits/sec 22.923 ms 0/ 88 (0%)
[ 3] 43.0-44.0 sec 100 KBytes 823 Kbits/sec 16.362 ms 0/ 70 (0%)
[ 3] 44.0-45.0 sec 79.0 KBytes 647 Kbits/sec 55.900 ms 0/ 55 (0%)
[ 3] 45.0-46.0 sec 87.6 KBytes 717 Kbits/sec 35.615 ms 0/ 61 (0%)
[ 3] 46.0-47.0 sec 96.2 KBytes 788 Kbits/sec 19.624 ms 0/ 67 (0%)
[ 3] 47.0-48.0 sec 106 KBytes 870 Kbits/sec 32.090 ms 0/ 74 (0%)
[ 3] 48.0-49.0 sec 106 KBytes 870 Kbits/sec 14.775 ms 0/ 74 (0%)
[ 3] 0.0-49.0 sec 6.25 MBytes 1.07 Mbits/sec 58.491 ms 8550/13009 (66%)
[ 3] 0.0-49.0 sec 11 datagrams received out-of-order

It's easy to see that the throughput decreases with the time.

And TX WARP --> RX Atheros

------------------------------------------------------------
Server listening on UDP port 12345
Receiving 1470 byte datagrams
UDP buffer size: 208 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.4.100 port 12345 connected with 192.168.4.1 port 43887
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 3] 0.0- 1.0 sec 81.8 KBytes 670 Kbits/sec 16.867 ms 0/ 57 (0%)
[ 3] 1.0- 2.0 sec 66.0 KBytes 541 Kbits/sec 21.604 ms 0/ 46 (0%)
[ 3] 2.0- 3.0 sec 83.3 KBytes 682 Kbits/sec 12.788 ms 531/ 589 (90%)
[ 3] 3.0- 4.0 sec 81.8 KBytes 670 Kbits/sec 6.048 ms 4172/ 4229 (99%)
[ 3] 4.0- 5.0 sec 84.7 KBytes 694 Kbits/sec 9.796 ms 5194/ 5253 (99%)
[ 3] 5.0- 6.0 sec 79.0 KBytes 647 Kbits/sec 8.652 ms 3942/ 3997 (99%)
[ 3] 6.0- 7.0 sec 84.7 KBytes 694 Kbits/sec 6.627 ms 4329/ 4388 (99%)
[ 3] 7.0- 8.0 sec 83.3 KBytes 682 Kbits/sec 9.181 ms 4256/ 4314 (99%)
[ 3] 8.0- 9.0 sec 80.4 KBytes 659 Kbits/sec 8.896 ms 4196/ 4252 (99%)
[ 3] 9.0-10.0 sec 79.0 KBytes 647 Kbits/sec 8.163 ms 3932/ 3987 (99%)
[ 3] 10.0-11.0 sec 74.6 KBytes 612 Kbits/sec 7.482 ms 3667/ 3719 (99%)
[ 3] 11.0-12.0 sec 81.8 KBytes 670 Kbits/sec 7.397 ms 4304/ 4361 (99%)
[ 3] 12.0-13.0 sec 80.4 KBytes 659 Kbits/sec 6.783 ms 4404/ 4460 (99%)
[ 3] 13.0-14.0 sec 57.4 KBytes 470 Kbits/sec 10.635 ms 3228/ 3268 (99%)
[ 3] 14.0-15.0 sec 81.8 KBytes 670 Kbits/sec 7.006 ms 4159/ 4216 (99%)
[ 3] 15.0-16.0 sec 80.4 KBytes 659 Kbits/sec 9.731 ms 4229/ 4285 (99%)
[ 3] 16.0-17.0 sec 81.8 KBytes 670 Kbits/sec 8.549 ms 5389/ 5446 (99%)
[ 3] 17.0-18.0 sec 83.3 KBytes 682 Kbits/sec 8.472 ms 4333/ 4391 (99%)
[ 3] 18.0-19.0 sec 80.4 KBytes 659 Kbits/sec 8.669 ms 4179/ 4235 (99%)
[ 3] 19.0-20.0 sec 81.8 KBytes 670 Kbits/sec 8.520 ms 4218/ 4275 (99%)
[ 3] 20.0-21.0 sec 83.3 KBytes 682 Kbits/sec 8.873 ms 4335/ 4393 (99%)
[ 3] 21.0-22.0 sec 83.3 KBytes 682 Kbits/sec 9.080 ms 4249/ 4307 (99%)

Any ideas?

Alice

alice_warp · 2015-Nov-25 09:10:07

I tried to eliminate the filter in the receive chain and use the adc divider in the AD9963 and change only the outgoing clock to 10MHz.

Definitely, I tried two ways:
1. - change the outgoing clocks of the clk_gen_proc_bus_clks to 10MHz and 10MHz_90degphase;
- change internal clock in agc and in rx cores to 10MHz;
- change in SDK

clk_config_dividers(CLK_BASEADDR, 2, (CLK_SAMP_OUTSEL_AD_RFA | CLK_SAMP_OUTSEL_AD_RFB));
ad_config_clocks(AD_BASEADDR, AD_ALL_RF, AD_DACCLKSRC_EXT, AD_DACCLKSRC_EXT, AD_ADCCLKDIV_2, AD_DCS_OFF);
ad_config_filters(AD_BASEADDR, AD_ALL_RF, 4, 2);

2. - change the outgoing clocks of the clk_gen_proc_bus_clks to 10MHz and 10MHz_90degphase;
- change internal clock in agc core to 10MHz;
- leave internal clock in rx core to 20 MHz and add a filter with 2x decimation;
- change in SDK

clk_config_dividers(CLK_BASEADDR, 2, (CLK_SAMP_OUTSEL_AD_RFA | CLK_SAMP_OUTSEL_AD_RFB));
ad_config_filters(AD_BASEADDR, AD_ALL_RF, 4, 2);

Both solutions have the same behaviour.
Am I making any mistakes?

Thanks in advance!

Alice

murphpo · 2015-Nov-27 02:31:07

My guess is you're seeing degradations in throughput due to mis-matched MAC timing parameters between the customized 10 MHz WARP node and 10 MHz commercial Wi-Fi device.

The 10 MHz mode of 802.11 requires changing both the PHY's bandwidth and many MAC timing parameters. For example, the MAC slot time is 13 usec for 10 MHz mode (IEEE 802.11-2012 section 18.3.8.7) vs 9 usec for 20 MHz mode. Refer to Table 18-17 in 802.11-2012 for a summary of the differences. You will need to modify the MAC timing values to match the spec in order to interoperate with a Wi-Fi device in 10 MHz mode. These values are all set in the 802.11 ref design in the DCF C code / headers.

alice_warp · 2015-Nov-27 15:21:54

murphpo wrote:
My guess is you're seeing degradations in throughput due to mis-matched MAC timing parameters between the customized 10 MHz WARP node and 10 MHz commercial Wi-Fi device.

The 10 MHz mode of 802.11 requires changing both the PHY's bandwidth and many MAC timing parameters. For example, the MAC slot time is 13 usec for 10 MHz mode (IEEE 802.11-2012 section 18.3.8.7) vs 9 usec for 20 MHz mode. Refer to Table 18-17 in 802.11-2012 for a summary of the differences. You will need to modify the MAC timing values to match the spec in order to interoperate with a Wi-Fi device in 10 MHz mode. These values are all set in the 802.11 ref design in the DCF C code / headers.

Once again, thank you! It works!

Alice

Last edited by alice_warp (2015-Nov-27 15:22:19)

alice_warp · 2015-Dec-15 03:16:31

Hi to all,
I have two 10 MHz WARP and two 5 MHz WARP.
I put this setting for 10 MHz:

clk_config_dividers(CLK_BASEADDR, 2, (CLK_SAMP_OUTSEL_AD_RFA | CLK_SAMP_OUTSEL_AD_RFB));
ad_config_clocks(AD_BASEADDR, AD_ALL_RF, AD_DACCLKSRC_DLL, AD_DACCLKSRC_DLL, AD_ADCCLKDIV_1, AD_DCS_OFF);
ad_config_filters(AD_BASEADDR, AD_ALL_RF, 4, 2);

and this for 5 MHz:

clk_config_dividers(CLK_BASEADDR, 2, (CLK_SAMP_OUTSEL_AD_RFA | CLK_SAMP_OUTSEL_AD_RFB));
ad_config_clocks(AD_BASEADDR, AD_ALL_RF, AD_DACCLKSRC_DLL, AD_DACCLKSRC_DLL, AD_ADCCLKDIV_1, AD_DCS_OFF);
ad_config_filters(AD_BASEADDR, AD_ALL_RF, 8, 2);

and all works and the iperf throughput is perfect, but the ADC divider is AD_ADCCLKDIV_1, so the ADC works at 20 MHz. Is it possible?
I tried to put AD_ADCCLKDIV_2 and AD_ADCCLKDIV_4 respectively: in 10 MHz the iperf behaviour is the same, but in the 5 MHz the iperf behaviour is bad (rate 1.5 Mbps --> throughput 94 Kbps vs 1 Mbps with AD_ADCCLKDIV_1 setting).

I read these lines in another topic:

I just checked the Tx PHY in simulation to verify that using a lower frequency clock at DAC_TX_CLK will result in a longer assertion of the Tx PHY Running signal. I did see two bugs (explained below) that I'll have to fix in the next release. Can you double check the duration of the Tx PHY Active assertion in your 5MHz version? Is the duration identical to the reference (20MHz) design for a given packet length?

Bugs: there are two places in the Tx PHY control logic that assume sysgen_clk = 8*sample_clk. Both places use a constant 1 followed by an upsample-by-8 block to realize a pulse with period 8 cycles. In both cases the pulse drives a counter that counts sample periods following a Tx event. The first (Start Ctrl/Add Extension) controls how long the Tx PHY tells the MAC that a Tx is running. The second (Start Ctrl/Add Extension1) controls how long the radio is held in Tx mode after the last sample has been output to the DACs; this allows the last sample to propagate through the Tx chain (filters, DACs, radio, PA) before the radio hardware is switched back to Rx mode.

Both of these upsampled-1's should be replaced by copies of the TX_IQ_SAMP_CE goto signal, driven by the DAC_TX_CLK port. I will make this change in the next release.

You can adjust the extension values in software using wlan_phy_tx_set_extension() and wlan_phy_tx_set_txen_extension() in wlan_phy_util.c. Both functions accept an argument of an integer number of sample periods, in the range [0,255]. For your testing you probably only need to increase wlan_phy_tx_set_txen_extension() (the one that controls the radio).

Is it possible because of this reason?

Thanks,

Alice

Last edited by alice_warp (2015-Dec-15 03:17:41)

murphpo · 2015-Dec-16 09:32:11

In your XPS design what frequencies are the clocks driven to w3_ad_bridge.sys_samp_clk_Tx, sys_samp_clk_Tx_90 and sys_samp_clk_Rx ports? The Tx/Rx clocks at the w3_ad_bridge must match the frequencies of the AD9963 TXD and TRXD interfaces. The TXD and TRXD interface rates are controlled by the AD9963 configuration and will reflect changes to the AD9963 reference clock frequency and the interpolation/decimation settings.

alice_warp · 2015-Dec-17 03:56:21

murphpo wrote:
In your XPS design what frequencies are the clocks driven to w3_ad_bridge.sys_samp_clk_Tx, sys_samp_clk_Tx_90 and sys_samp_clk_Rx ports? The Tx/Rx clocks at the w3_ad_bridge must match the frequencies of the AD9963 TXD and TRXD interfaces. The TXD and TRXD interface rates are controlled by the AD9963 configuration and will reflect changes to the AD9963 reference clock frequency and the interpolation/decimation settings.

The clocks driven to w3_ad_bridge.sys_samp_clk_Tx, sys_samp_clk_Tx_90 and sys_samp_clk_Rx ports are at 10 MHz for two WARP and at 5 MHz for the other two WARP. I made a new custom clock_generator.

Thanks,

Alice

Last edited by alice_warp (2015-Dec-17 09:38:25)

alice_warp · 2015-Dec-17 09:38:31

Edit: I changed tx core as you said:

murphpo wrote:
I just checked the Tx PHY in simulation to verify that using a lower frequency clock at DAC_TX_CLK will result in a longer assertion of the Tx PHY Running signal. I did see two bugs (explained below) that I'll have to fix in the next release. Can you double check the duration of the Tx PHY Active assertion in your 5MHz version? Is the duration identical to the reference (20MHz) design for a given packet length?

Bugs: there are two places in the Tx PHY control logic that assume sysgen_clk = 8*sample_clk. Both places use a constant 1 followed by an upsample-by-8 block to realize a pulse with period 8 cycles. In both cases the pulse drives a counter that counts sample periods following a Tx event. The first (Start Ctrl/Add Extension) controls how long the Tx PHY tells the MAC that a Tx is running. The second (Start Ctrl/Add Extension1) controls how long the radio is held in Tx mode after the last sample has been output to the DACs; this allows the last sample to propagate through the Tx chain (filters, DACs, radio, PA) before the radio hardware is switched back to Rx mode.

Both of these upsampled-1's should be replaced by copies of the TX_IQ_SAMP_CE goto signal, driven by the DAC_TX_CLK port. I will make this change in the next release.

You can adjust the extension values in software using wlan_phy_tx_set_extension() and wlan_phy_tx_set_txen_extension() in wlan_phy_util.c. Both functions accept an argument of an integer number of sample periods, in the range [0,255]. For your testing you probably only need to increase wlan_phy_tx_set_txen_extension() (the one that controls the radio).

and I solved my problem.

Thanks again,

Alice

murphpo · 2015-Dec-17 16:19:51

Great, glad it's working.

The Tx PHY bugs described (two instances of a hard-coded sys_clk/8 sampling clock) have been fixed in the latest Tx PHY model, included in the v1.4 release of the 802.11 Reference Design (just posted today).

alice_warp · 2017-Mar-30 08:21:32

Hi,
I'm working with two WARP @5MHz. The bitstream was generated as you suggest.
Two WARP are transmitting packets in channel 6 (2.437 GHz).
If I transmit a sine wave @2.449 GHz with another device, I note that the throughput of WARPs decreases.
The image below shows what happen in presence and in absence of the sine wave.

I thought that it was a problem of sampling rate of ADC, but this is my code for the radio_init()

clk_config_dividers(CLK_BASEADDR, 2, (CLK_SAMP_OUTSEL_AD_RFA | CLK_SAMP_OUTSEL_RFB));
ad_config_clocks(AD_BASEADDR, AD_ALL_RF, AD_DACCLKSRC_EXT, AD_DACCLKSRC_EXT, AD_ADCCLKDIV_4, AD_DCS_OFF);
ad_config_filters(AD_BASEADDR, AD_ALL_RF, 8, 2);

In this way, is sampling rate 5MHz? Or is 20MHz?
However my sine wave is out of the bandwidth, why does my WARPs "sense" it?

Any ideas?

murphpo · 2017-Mar-30 11:56:01

One possibility is that the tone is detected above the physical carrier sensing threshold. The Rx PHY monitors the radio's RSSI output and asserts the CCA.BUSY signal when the RSSI exceeds a programmed threshold. This is part of the 802.11 standard behavior for sensing medium activity. The physical carrier sensing threshold is set with the wlan_phy_rx_set_cca_thresh(thresh) function; pass thresh=0xFFFF to effectively disable the sensing logic (the averaged RSSI can never exceed 0xFFFF, so with this threshold the sensing logic will never assert CCA.BUSY).

alice_warp · 2017-Apr-02 10:06:58

murphpo wrote:
One possibility is that the tone is detected above the physical carrier sensing threshold. The Rx PHY monitors the radio's RSSI output and asserts the CCA.BUSY signal when the RSSI exceeds a programmed threshold. This is part of the 802.11 standard behavior for sensing medium activity. The physical carrier sensing threshold is set with the wlan_phy_rx_set_cca_thresh(thresh) function; pass thresh=0xFFFF to effectively disable the sensing logic (the averaged RSSI can never exceed 0xFFFF, so with this threshold the sensing logic will never assert CCA.BUSY).

It was a spurious of the sine wave inside the channel bandwidth.
Thanks for your reply.

WARP Project Forums - Wireless Open-Access Research Platform

#1 2014-Jan-26 23:51:00

802.11 Tx/Rx PHY with narrower bandwidths

#2 2015-May-07 16:45:37

Re: 802.11 Tx/Rx PHY with narrower bandwidths

#3 2015-Nov-13 10:08:51

Re: 802.11 Tx/Rx PHY with narrower bandwidths

#4 2015-Nov-13 14:02:26

Re: 802.11 Tx/Rx PHY with narrower bandwidths

#5 2015-Nov-14 14:48:35

Re: 802.11 Tx/Rx PHY with narrower bandwidths

murphpo wrote:

murphpo wrote:

murphpo wrote:

#6 2015-Nov-16 08:27:35

Re: 802.11 Tx/Rx PHY with narrower bandwidths

#7 2015-Nov-16 09:13:07

Re: 802.11 Tx/Rx PHY with narrower bandwidths

#8 2015-Nov-16 10:18:44

Re: 802.11 Tx/Rx PHY with narrower bandwidths

murphpo wrote:

murphpo wrote:

#9 2015-Nov-16 19:14:15

Re: 802.11 Tx/Rx PHY with narrower bandwidths

#10 2015-Nov-19 02:32:05

Re: 802.11 Tx/Rx PHY with narrower bandwidths

murphpo wrote:

#11 2015-Nov-25 06:48:47

Re: 802.11 Tx/Rx PHY with narrower bandwidths

#12 2015-Nov-25 09:10:07

Re: 802.11 Tx/Rx PHY with narrower bandwidths

#13 2015-Nov-27 02:31:07

Re: 802.11 Tx/Rx PHY with narrower bandwidths

#14 2015-Nov-27 15:21:54

Re: 802.11 Tx/Rx PHY with narrower bandwidths

murphpo wrote:

#15 2015-Dec-15 03:16:31

Re: 802.11 Tx/Rx PHY with narrower bandwidths

#16 2015-Dec-16 09:32:11

Re: 802.11 Tx/Rx PHY with narrower bandwidths

#17 2015-Dec-17 03:56:21

Re: 802.11 Tx/Rx PHY with narrower bandwidths

murphpo wrote:

#18 2015-Dec-17 09:38:31

Re: 802.11 Tx/Rx PHY with narrower bandwidths

murphpo wrote:

#19 2015-Dec-17 16:19:51

Re: 802.11 Tx/Rx PHY with narrower bandwidths

#20 2017-Mar-30 08:21:32

Re: 802.11 Tx/Rx PHY with narrower bandwidths

#21 2017-Mar-30 11:56:01

Re: 802.11 Tx/Rx PHY with narrower bandwidths

#22 2017-Apr-02 10:06:58

Re: 802.11 Tx/Rx PHY with narrower bandwidths

murphpo wrote:

Board footer