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 <g...@ir.bbn.com> 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 > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
