Re: [Discuss-gnuradio] [BBN_USRP2] Barker (de)spreading

[Colby Boyer]

Hi Greg,

We are using the USRP2, which should have just enough bandwidth to handle the full bandwidth of the signal.

As a side note, I think I almost have 2Mbps tx/rx working. I've set it up so that it successfully merges a header and payload that have been modulated at different rates. I think I just need to fix a bug in the PLCP/demod block and it should work.

On Wed, May 20, 2009 at 5:46 AM, Greg Troxel <address@hidden> wrote:

 From my side I decided to spend some more time in understanding why
 the bbn_802.11_tx.py doesn't work when trying to receive with real
 802.11 chipsets in monitor mode (modified to disable the mac CRC
 check).

I am now fuzzy on the details, but I think the basic problem is that the
USRP doesn't have enough bandwidth to run at a rate high enough to
represent the entire transmitted signal.  I am not understanding how you
are proposing to get around that.

The receive path is basically a hack to work around this, expecting a
signal which was to-spec 802.11 received and aliases by a receiver with
too low a sampling rate, and then correlating to a representation of an
ideal signal as we expect it to be munged by the receive chain.

The receive hack does not straightforwardly work on transmit.

If you're running at higher speed with fewer samples, you might be
getting closer, but if you assume you have to represent 22 MHz of
signal, it still seems hard to fit.

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio