WARP Project Forums - Wireless Open-Access Research Platform

Let me start by saying if your application allows you to ignore DSSS receptions, you should definitely do this. It's an absurd waveform to use in modern systems (1Mb/s in 20MHz? no coding? ugh). We only built the DSSS Rx so we could interact with Wi-Fi devices which insist on transmitting probe requests at 1Mb/s. Our Tx PHY does not implement DSSS- we found Wi-Fi devices are happy to receive management frames at OFDM rates, even if they respond at 1Mb/s. We disable DSSS completely when running experiments with all WARP v3 nodes.

1) In wlan_phy_rx_pmd > DSSS Rx, when you label something as 'Sym Sync', 'Sym Match' or simply 'Sym'. Does Sym refer to one bit, ie one iteration of the chipping sequence? DSSS does not quite have the same mean of symbol, like OFDM would. In which case for a 1Mb rate, you would expect there to be 1 symbol per us?

Right- I used the label 'sym' for the collection of 11 chips that represent 1 bit. Our implementation processes samples at 20MHz and de-spreads using an upsampled (by 20/11) version of the spreading sequence, so it's really 40 samples per 'sym'.

2) The DSSS receiver is enabled by the 'Det' signal in wlan_phy_rx_pmd > DSSS Rx. Am I correct in that this Det signal is high at the start of the DSSS SYNC field? So the first DSSS symbol that is detected in wlan_phy_rx_pmd > DSSS Rx > Sym Sync > Sym Match is at the start of the PLCP Preamble, SYNC field? (802.11-2012 16.2.2). Right at the start of the frame.

The 'Det' input comes from the auto-correlation packet detector. The pkt det block has two correlator- one with period 16, looking for the OFDM short symbols, and one with period 20, looking for the periodic sequence at the start of the DSSS waveform. The pkt det block asserts whenever the correlation output (normalized by Rx energy) exceeds some threshold. For mid-to-high SNR receptions this will be early in the Rx. For low SNR it can be early or late, depending on the actual waveform. Once the pkt det block asserts, it stays asserted until the corresponding Rx PHY resets it. For DSSS this occurs early, if the preamble is invalid, or at the end of the frame.

3) The standard states (16.2.3.6) that the LENGTH field is simply the number of microseconds required to transmit the MPDU. In wlan_phy_rx_pmd > DSSS Rx > SIGNAL Dec you extract the LENGTH field. I'm guessing that because the hardware can only demod 1Mbps (DBPSK) you assume that 1us = 1bit?

Right.

4) In the same part of the PHY you then multiply by 8 and add 5, with the comment 'Convert to bytes, pad for FCS'. I get the converting to bytes, but surely you don't need to pad for the FCS, since this is included in the length of the MPDU (from the LENGTH field)? Also, why 5? The MPDU-FCS is four bytes. Perhaps you mean to pad for the PLCP Header (not the true meaning of the LENGTH field) which ought to be 6 bytes?

Yeah, that comment is clearly wrong. I think that +5 operation accounts for the bytes in the SERVICE, LENGTH and CRC fields. The PHY needs to know the total number of bytes it must decode and write to the packet buffer. This value also establishes the index of the last byte, where the FCS result will be checked. I'm not sure why this would exclude the SIGNAL field. I'll check the model when I get back to the office.

1) It's definitely not on our roadmap

2) If you only need the 1Mb/s rate it should be pretty straightforward. The trickiest part is adapting the inherent 11Mchip/sec rate of the DSSS waveform to the 20MSps sampling rate at the ADC/DACs. For the DSSS Rx I used an interpolated version of the 11-chip spreading sequence (barker_seq20 in wlan_phy_rx_init.m). This 20-sample sequence is used as the coefficient vector for an FIR filter in the DSSS Rx path. The filter output is then accumulated over 20 samples, outputting a soft bit at 1Mb/s. In effect this de-spreads by the 11-chip sequence without actually implementing an 11MHz clock domain. I think you could build a Tx PHY the same way- just transmit ±barker_seq20 (sampled at 20Msps) as the post-spread waveform for data bits 0/1. You probably only need a ROM to store that sequence, no reason to build an actual filter with the inputs are always +1 or -1.

3) Yeah. The Rx dual-PHY state is tricker because either PHY can start a reception at any time. For Tx you will know a priori which PHY will be used, so it'll be easy to hold the other in reset.

4) Almost certainly - I'll update with any I think of.

Out of curiosity, why would DSSS Tx be useful?