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.
pgph3EtAXgPOG.pgp
Description: PGP signature
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
