[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Problem with the ieee 802.11 a/g/p receiver (wifi

From: Bastian Bloessl
Subject: Re: [Discuss-gnuradio] Problem with the ieee 802.11 a/g/p receiver (wifi_rx)
Date: Thu, 2 Feb 2017 11:46:00 +0100


> On 1 Feb 2017, at 20:07, Qurat-Ul-Ann Akbar <address@hidden> wrote:
> Hi,
> I have been working with the ieee 802.11 module for GNU Radio. I have GNU 
> Radio v and I am using USRP N210 with a cbx daughterboard. 
> Right now I am just testing if the wifi_rx(the receiver) works. I am using a 
> wifi card to send beacon frames and trying to detect the frames through the 
> USRP. I get a lot of messages saying frame too short to parse length(<20). 
> And there's wireshark connector which is supposed to copy received packets 
> information into a pcap file and that pcap file shows nothing and the message 
> that the pacp is possibly corrupted pops up. 
> I tried to debug using the data flow. I see the that the frame is detected 
> properly and the symbols are copied in order to decode and the flow is fine 
> but after the data is decoded in the WiFi Decode MAC Block, the frame gets 
> dropped with the checksum wrong message. And it happens for most of the 
> packets and that's why the pcap file isn't showing anything. 
> I tried to play with the gain but that's not changing anything. I am using 
> 11g beacon frames and the sampling rate on the receiver is 20MHz. Did anyone 
> encounter the same problem? And why are almost all checksums wrong? It would 
> be very helpful if someone could guide me on this.

Maybe you can find something useful here:

In addition to that, I would recommend to
- make sure that there are no Overruns (i.e., that the receiver can catch up 
with the same stream)
- check the constellation plot (it should give you a good idea if decoding 
- try different LO offsets to tune the oscillator out of the band of interest
- make sure that frame detection works (i.e., that decoding is only triggered 
if a frame is sent)

Also note that the frame too short message is from the parser. I didn’t 
implement a complete parser that knows about all sorts of WiFi frames. However, 
decoding is completely independent from that. If there is a valid WiFi frame it 
will show up in the PCAP file, even if it’s not parsed and printed to the 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]