Hi, On 06 Oct 2014, at 10:33, Ernest Szczepaniak <ernest_szczepan...@wp.pl> 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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
