[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 |
Hi,
> 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 3.7.10.1 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:
https://www.wime-project.net/installation/
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
works)
- 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
console.
Best,
Bastian