Re: [Discuss-gnuradio] Problems with IEEE802-11 Blocks?

[Bastian Bloessl]

Hi,

> On 11. Jul 2017, at 02:04, Taylor Eisman <address@hidden> wrote:
> 
> Well, I've been trying to place Packet Pad 2 around the WiFi Phy Hier example 
> setup to get good results and still have not achieved any decent results. 
> Three things are possible, given specific placements of the Packet Pad 2 
> block: 1) WiFi MAC Decode detects 26 out of 29 packets

And what did you change with regard to the loopback flowgraph in the examples 
folder? I assume the loopback flowgraph works for you and your modifications 
leat to these problems.

> 2) WiFi MAC Decode receives the file but fails the checksum

Not sure what you mean and why there is a file involved. If the checksum fails 
the frame data (header and/or payload) was corrupted (either due to flowgraph 
modifications or bad SNR)

> 3) The Packet Pad 2 block fails to see the tagged stream.

I assume you placed it wrong. AFAIS, the screenshot doesn’t help much, as it 
shows the unmodified hier block.


> Does anybody have suggestions as to where to place Packet Pad 2 in the WiFi 
> Phy Hier example?

The hier block is not meant to be modified, but used in other blocks. The 
transceiver flow graph (meant for use with HW) and the loopback flow graph 
(runs without HW) will  show you how to use it. The loopback flow graph uses 
the Packet Pad block. Just start from that and gradually adjust the flowgraph 
for your experiments.

Best,
Bastian




> 
> Thanks,
> 
> Taylor
> 
> On Mon, Jul 10, 2017 at 2:14 AM, Bastian Bloessl <address@hidden> wrote:
> Hi,
> 
> please keep the conversation on the list.
> 
> On 7/9/2017 5:36 PM, Taylor Eisman wrote:
> Hey,
> 
> I went ahead and substituted Wifi Hier Phy into my program, and it made no 
> difference; however, I did end up using Packet Pad, and it was able to 
> receive a full frame. Using Packet Pad did not completely solve the problem 
> though because it does not pass the checksum check.
> 
> I tested the flowgraph without padding, i.e., frames back to back, and also 
> saw the problem mentioned in your previous email. So this was really related 
> to padding.
> 
> If your frames have a wrong checksum, they were not received correctly. 
> That's a different problem. What you want is not disable the checksum, but 
> understand why the frames got corrupted.
> 
> I don't know what your flowgraph is doing, but check the signal quality of 
> the stream that you feed into the WiFi receiver. Also avoid sending frames 
> padded with zeros (add a bit of noise).
> 
> Best,
> Bastian
> 
> Is there any way to quickly pass the checksum?
> 
> Thanks,
> Taylor
> 
> On Sun, Jul 9, 2017 at 1:57 AM, Bastian Bloessl <address@hidden 
> <mailto:address@hidden>> wrote:
> 
>     Hi,
> 
>     I recommend to start with the example flow graph and make sure that
>     it works works for you. If that works, just replace the constant
>     message source with the data that you want to transmit.
>     Did you maybe delete the packet pad block and just sent data back to
>     back without any space in between?
> 
>     Best,
>     Bastian
> 
> 
>     On 07/08/2017 09:20 PM, Taylor Eisman wrote:
> 
>         I've been trying to use the IEEE802-11 blocks to simulate Wi-Fi
>         environments. I've generated data from the local radio station,
>         tagged it, modulated, etc. It is never able to generate a file
>         at the end and I've tracked it down to an issue in the WiFi
>         Decode block.
> 
>         This is the error that the WiFi Decode block generates:
> 
>         Decode MAC: frame start -- len 250  symbols 29  encoding 3
>         copy one symbol, copied 0 out of 29
>         copy one symbol, copied 1 out of 29
>         copy one symbol, copied 2 out of 29
>         copy one symbol, copied 3 out of 29
>         copy one symbol, copied 4 out of 29
>         copy one symbol, copied 5 out of 29
>         copy one symbol, copied 6 out of 29
>         copy one symbol, copied 7 out of 29
>         copy one symbol, copied 8 out of 29
>         copy one symbol, copied 9 out of 29
>         copy one symbol, copied 10 out of 29
>         copy one symbol, copied 11 out of 29
>         copy one symbol, copied 12 out of 29
>         copy one symbol, copied 13 out of 29
>         copy one symbol, copied 14 out of 29
>         copy one symbol, copied 15 out of 29
>         copy one symbol, copied 16 out of 29
>         copy one symbol, copied 17 out of 29
>         copy one symbol, copied 18 out of 29
>         copy one symbol, copied 19 out of 29
>         copy one symbol, copied 20 out of 29
>         copy one symbol, copied 21 out of 29
>         copy one symbol, copied 22 out of 29
>         copy one symbol, copied 23 out of 29
>         Decode MAC: input 1
>         copy one symbol, copied 24 out of 29
>         Decode MAC: input 25
>         copy one symbol, copied 25 out of 29
>         Warning: starting to receive new frame before old frame was complete
>         Already copied 26 out of 29 symbols of last frame
> 
>         I've tried changing the source file to something else. I've
>         messed with the parameters and noticed that it is always 3
>         symbols short of a full frame, even if there are theoretically
>         3000 symbols, it would only pass 2997 symbols.
> 
>         Any ideas on what could be causing this?
> 
>         I'm attaching the WiFi Phy Hier graph to give you some idea of
>         the layout
>         .
> 
> 

--
Dipl.-Inform. Bastian Bloessl
CONNECT Center
Trinity College Dublin

GitHub/Twitter: @bastibl
https://www.bastibl.net/