WARP Project Forums - Wireless Open-Access Research Platform

You are not logged in.

#1 2016-May-01 10:57:03

zrcao
Member
From: Vienna, VA
Registered: 2007-Jan-24
Posts: 121

Is the Preamble_Gen Done signal early?

In wlan_phy_tx_pmd/Premable & Output/Preamble Gen, the negative of the bool output of the "Rational2" block directly drives the 'Done' output, which in turn drives the selection line for the MUX in the following block between the preamble I/Q and payload I/Q.

The bool output of the "Rational2" block (a<319?) turns to 0 at the same time as the address line becomes 319. Thus, the last sample of the preamble was never sent, since the MUX selection line is already 1 at that time.

Along the same line, it looks like the first sample of the preamble was sent twice (or 8 times if counting oversampling).

Am I right in the above observation? Is this by design? Thanks.

Offline

 

#2 2016-May-02 12:01:17

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

Re: Is the Preamble_Gen Done signal early?

I'm pretty sure the logic is right. You can verify the sequencing with minor modifications to the init script and model, to override the values of the preamble/payload I/Q and observe the waveforms at the DAC outputs. For example:

In the FFT subsystem drive the "I Out" port with a constant 0 (Fix16_15, sample period = 1). This will set all payload I samples to 0, leaving the payload Q samples unmodifed.

In wlan_phy_tx_init.m, redefine the Preamble_IQ_scaled vector as:

Code:

Preamble_IQ_scaled = complex([-0.25*ones(1, 319) 0.25], [0.25*ones(1, 319) -0.25]);

This will redefine the preamble I/Q such that the last sample is different from all previous samples.

Run the sim and observe the DAC I/Q outputs on the "Preamble & Outputs / Outputs" scope. When you zoom in on the preamble/payload transition you should see:

https://warpproject.org/dl/images/forum_images/tx_phy_preamble-payload_timing_const_I.png

That shows the initial preamble (-0.5,+0.5), the final preamble sample (+0.5,-0.5), then the first payload samples (0, payload Q).

You can further verify that the first payload sample is being transmitted by changing the FFT subsystem "I Out" signal again. Instead of a constant zero, you can drive "I Out" with a re-interpretted copy of the FFT's subcarrier index (xk_index) signal. There's already a loadless convert+force blocks in the FFT subsystem for this. However you must modify the Convert block for output type Fix16_4 (it's currently Fix16_0, which will lose the 4 LSB during the output scaling). Do this and re-run the sim and you should see:

https://warpproject.org/dl/images/forum_images/tx_phy_preamble-payload_timing_sc_ind_I.png

The 16 steps on the I signal immediately after the preamble are the interpreted subcarrier indexes 48:63 - the cyclic prefix of the first OFDM symbol.

Offline

 

#3 2016-May-02 16:32:32

zrcao
Member
From: Vienna, VA
Registered: 2007-Jan-24
Posts: 121

Re: Is the Preamble_Gen Done signal early?

Murph, Thank you very much. You are right. I didn't pay attention to the RdEn signal, which plays an important role in timing the signals. I really appreciate you spending time to respond my question!

Offline

 

#4 2016-Jun-09 14:43:42

zrcao
Member
From: Vienna, VA
Registered: 2007-Jan-24
Posts: 121

Re: Is the Preamble_Gen Done signal early?

According to WARP Trac on 802.11PHY, the PHY Core is designed for a clock rate at 160MHz for a maximum bandwidth of 20MHz, which should have an 8x oversampling ratio at least. So why is each sample only repeated 4x in the simulation output?

Offline

 

#5 2016-Jun-09 16:12:03

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

Re: Is the Preamble_Gen Done signal early?

That wiki page was out of date (just fixed it). As of v1.5 the Tx and Rx PHY cores require at least 4 clock cycles per sample. On WARP v3 this allows operation at 40MHz bandwidth with a 160MHz system clock. Faster clock frequencies are probably possible on newer FPGAs (keeping in mind the 802.11 ref design license only permits free use on Mango hardware; paid licenses are required for other hardware platforms). The v1.5 PHY cores use a 64-subcarrier waveform for all bandwidths. For 10MHz this implements 802.11p. For 20MHz it implements 11a/g and HT20 11n. For 40MHz it implements a non-standard waveform (i.e. not HT40). We hope to add proper HT40 waveform support in a future release.

Offline

 

#6 2016-Jun-09 16:39:59

zrcao
Member
From: Vienna, VA
Registered: 2007-Jan-24
Posts: 121

Re: Is the Preamble_Gen Done signal early?

OK, Thanks. So, how do you change the bandwidth among 10, 20, and 40 MHz? I guess there is a read enable signal you allow to adjust, right?

Offline

 

#7 2016-Jun-09 17:02:28

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

Re: Is the Preamble_Gen Done signal early?

So, how do you change the bandwidth among 10, 20, and 40 MHz? I guess there is a read enable signal you allow to adjust, right?

Right. The PHY cores use the 'samp_ce' signal from the w3_ad_bridge as the clock enable. The PHY pipelines assume this signal will assert for 1 cycle with period >= 4 cycles. The samp_ce signal is generated from the ADC's TRXCLK signal whose frequency is set by the AD9963 reference clock frequency and decimation rate.

Offline

 

Board footer