discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] GRC 3.6 / 802.11 a/g test signal


From: Bastian Bloessl
Subject: Re: [Discuss-gnuradio] GRC 3.6 / 802.11 a/g test signal
Date: Mon, 6 Oct 2014 16:32:42 +0200

Hi,

On 06 Oct 2014, at 10:33, Ernest Szczepaniak <address@hidden> wrote:

> Hi, much appreciate for your reply Bastian.
> 
> I have succefully found your frame.bin signal, forwarded by my USRP
> (generated in MATLAB, received with Windows Network Monitor and wlan card). 
> 
> You were right. It is Data frame, 232323:232323 Source MAC and FFFFFF:FFFFFF
> Destination MAC. 
> 
> Still dunno what's wrong. 
> 
> Could you please check my methodology??
> 
> 1st OFDM symbol is carrying a SIGNAL field - it is decoded correctly (i
> checked all rates with your grc wlan script)  - no problem here. 
> 
> 2nd OFDM symbol is carrying Data. Assuming BPSK 1/2, it should carry 16 bit
> SERVICE field, and 8 bits from FRAME CONTROL field (together - 24 uncoded
> bits).
> 
> And my algorythm goes as follows (for 2nd OFDM symbol):
> 
> - OFDM demodulation (to get 48 complex data points)
> - BPSK demodulation (to get 48 coded bits)
> - de-interleaving (1st and 2nd permutation)
> - Viterbi decoding ([133 171 poly] to get 24 uncoded bits)
> - descrambling 
> 
> and if its correct way, i should get 24 bits of data (16x0 and 8 bits
> depending on FRAME CONTROL paylaod) right?
> 

The payload is scrambled (as opposed to the signal field). So maybe your 
scrambler has a bug. Did you try to generate the example sequence from the 
standard?

Do not try to decode the next OFDM symbol on its own, but the rest of the 
frame. The decoder is not reset with a zero sequence as with the “signal tail” 
bits. So it might not work with the same decoding function that you used for 
the first symbol.

Best,
Bastian


reply via email to

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