Re: [Discuss-gnuradio] gr-ieee802_11 not able to send or receive packets.

[Bastian Bloessl]

Hi,

On 04/15/2017 11:03 AM, Anshul Thakur wrote:
> Hi,
> 
> I have for now circumvented the problem. But I did try looking into the
> correlation values by logging the correlation after the divide block
> into a file and inspecting the values in Matlab.
> 
> Here are some statistics:
> 
> Contiguous samples considered:  4.096e8;
> # of samples with correlation > 0.7 : 2241
> # of samples with correlation in (0.6, 0.7]: 2405
> # of samples with correlation in (0.5, 0.6]: 14998
> 
> Threshold value considered in GNU RC block: 0.7
> 
> This was after removing all zero padding from delay block.


Not sure what you mean. The delay block does not do zero padding.


> 
> To get around the problem, I essentially used one of my SDRs as a dummy
> repeater that just picked all samples at one frequency and transmitted
> them at a different frequency. In this case, I was able to successfully
> receive a large number of PDUs and decode them in wireshark. This begs
> the question as to what I might be doing wrong with the original setup!
> Some more pointers I could look at?

Could you describe your current experiment again? I'm not sure what your
current problem is and what you are trying to work around.


> 
> Also, when I use the Loopback flowgraph with no packet padding, I am
> unable to receive any PDUs in wireshark. If I add some padding, they are
> detected. Is that expected behaviour?

You send frames back to back. When the frame detection algorithm sees
the second frame, it adds a tag to mark the beginning of a new frame.
With a high SNR, the autocorrelation rises fast and the tag might be
placed already in the preceding symbol. This could lead to the last OFDM
symbol of the preceding frame to be dropped.
However, since the frame detection algorithm doesn't know about the
length of the preceding frame and since that something that doesn't
happen in reality, I think it's not an issue. In simulations you could
just add some samples padding.

Best,
Bastian

> 
> I took some pointers from this
> thread 
> http://gnuradio.4.n7.nabble.com/gr-ieee802-11-receiver-td63486.html#a63508
> 
> On 30 March 2017 at 01:56, Bastian Bloessl <address@hidden
> <mailto:address@hidden>> wrote:
> 
>     Hi,
> 
>     On 03/29/2017 07:01 PM, Anshul Thakur wrote:
>     >
>     >
>     >     You could also test different RX/TX gains and parameters for the 
> padding
>     >     block (I don't have a BladeRF, so I have no experience). Also assert
>     >     that there are no overruns or underruns.
>     >
>     > I altered the values of gains and padding values (I increased the
>     > padding values). That didn't seem to help.
>     >
> 
>     Actually, I was thinking of decreasing (or completely removing) it. Did
>     you only try to increase it? Did you do anything else to debug? Like
>     sending a stream of '0' and monitor the autocorrelation?
> 
>     Best,
>     Bastian
> 
>