Re: [Discuss-gnuradio] gr-ieee802-11 tx and rx

Hi Nikita,

If you get overflows at 20MS/s, then your PC, in its current configuration, is simply not fast enough to process all the samples. You can try to make sure that your network is optimally configured (largest possible MTU, no firewalling on the interface you only use for your USRP, optimized NIC interrupt coalescing) and your operating system is configured to allow your user to require high scheduling priority for its processes.

If that doesn't help, I'm afraid 20MS/s is simply too much for your computer :(

Best regards,
Marcus Müller

On 11/22/2016 11:23 AM, Nikita Airee wrote:

Thanks Bastian, your advice solved weeks of stalemate!

My Tx was not DC calibrated. That's probably why Rx would almost continuously read a new frame.

The Rx is working perfectly at 10 MSa/s now. However, the at 20MSa/s I still get overflows and the messages I had mentioned in the previous mail.

When you say I should try sending 0s from the Tx, do you mean a constant source with a uhd sink or using the wifi_tx flowgraph?

 

On Mon, Nov 21, 2016 at 4:20 PM, Bastian Bloessl <bloessl@ccs-labs.org> wrote:

Hi,

On 21 Nov 2016, at 11:34, Nikita Airee <nikitiaa@iiitd.ac.in> wrote:

I am working on the gr-ieee802-11(https://github.com/bastibl/gr-ieee802-11)

Setup consists of 2 usrp 2953R (X310) connected via SMA and 30 dB attenuator at the Rx end.

The problem I'm facing is that the packets that are sent do not get decoded at the reciever for high sample rates of 10 and 20Msa/s.

On enabling debugging of Decode Mac block I get 2 distinct messages which indicate where the error is:

1. checksum wrong -- dropping
2. Warning: starting to receive new frame before old frame was complete

Maybe you find something useful here:

https://www.wime-project.net/installation/

The second warning sounds like there could be a DC component (i.e. a signal with a high autocorrelation) that triggers frame detection all the time. This might totally overflow the receiver.

You could send some 0s at the transmitter and check if already that triggers frame detection (use the Log/Debug option of the Sync Short block).

Also assert that there are no over/underruns. If frame detection works as expected you could try volk_profile to optimize performance.

Best,

Bastian

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