discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] question about the qa_ofdm_sync_sc_cfb.py


From: w xd
Subject: Re: [Discuss-gnuradio] question about the qa_ofdm_sync_sc_cfb.py
Date: Wed, 11 Nov 2015 16:57:41 +0800

Hi,

       Thank you so much for your kindly reply and patience.

       But I want to confirm my option whether it's right or wrong.

       The detection of the sync burst have delayed fft_len-1 because of the filters in the sync block.
       You have dalayed the signal fft_len+cp_len.And the cp_len will indicate the block(head/payload Demux) remove the cp.So the final position you find will make a mistake just one position maybe.Just because fft_len-(fft_len-1)=1.

       "I did the maths a while ago, "  Can you show me how you did the maths?Thank you.

        For example,
        
         fft_len=64
         cp_len=16;
         the signal delayed fft_len+cp_len=80
          the detect returned 71zeros+1+many zeros(the position is 72),while the true detect is 8zeros+1+many zeros(the position is 9)

         The delayed signal:
         0 0 0...0 0 0 + 0(position 72)+ 0(position 73)+0 ...+0(position 80) + the original signal position 1+the original signal position 2+....

         The detected signal returned by the sync block:
         0 0 0 0 ....0 0 0 +1(position 72)+0 ....+0

         The block(head/payload Demux):
         Firstly remove cp_len(16) from the position 72,so it remove 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87.And the start is position 88.While the true start point is 89.

        Maybe an error is 1.


Best regards,
xd



       



2015-11-11 7:42 GMT+08:00 Martin Braun <address@hidden>:
I did the maths a while ago, and I'm confident the numbers are OK, but
it's always possible mistakes were made. Feel free to investigate. The
test cases would be a good place to go for confirmation.

Cheers,
Martin

On 09.11.2015 18:11, w xd wrote:
> Hi,
>
>      Thank you so much.
>
>      I have test the block.And I find the block have delay fft_len-1.
>
>      But in the example, rx_ofdm.grc you have delayed  fft_len+cp_len.Is
> it right?
>
> Best regards,
> xd
>
> 2015-11-10 4:16 GMT+08:00 Martin Braun <address@hidden
> <mailto:address@hidden>>:
>
>     Hi,
>
>     Is your fft length really 10? The gist of it is, the detection of the
>     sync burst will be delayed, and hence you also need to delay the signal.
>     The delay is caused by the averaging filters in the sync block.
>
>     As for an example, rx_ofdm.grc should show you how it is connected.
>     You'll notice that the detection signal goes to one input of the
>     Header/Payload Demux and that triggers a capture.
>
>     Cheers,
>     Martin
>
>     On 08.11.2015 00:16, w xd wrote:
>     > Hi all,
>     >
>     >          Thank you in advance.I‘'m so confused about the block
>     Schmidl &
>     > Cox synch,
>     >
>     >          1.I'm check the qa_ofdm_sync_sc_cfb.py to try to
>     understand the
>     > block.
>     >
>     >           The original sequence: 5 zeros+4 cp_len+10 fft_len+14 data
>     >           Just like this:[0, 0, 0, 0, 0, 1, -1, -1, -1, 1, 1, -1, -1,
>     > -1, 1, 1, -1, -1, -1, -1, -1, 1, 1, -1, 1, -1, -1, -1, -1, 1, 1, 1, 1]
>     >           The result of detect:
>     >            (0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0,
>     0, 0,
>     > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0)   1 is in the position of 17
>     >
>     >           And in the example
>     > gnruadio/gr-digital/examples/ofdm/rx_ofdm.grc.You have add a delay
>     > block,and it delay cp_len+fft_len.
>     >
>     >          According to this,after the delay,our original sequence
>     will be:
>     >          14 zeros+[0, 0, 0, 0, 0, 1, -1, -1, -1, 1, 1, -1, -1, -1,
>     1, 1,
>     > -1, -1, -1, -1, -1, 1, 1, -1, 1, -1, -1, -1, -1, 1, 1, 1, 1]
>     >
>     >          Now we use the detect result to find the start point of the
>     > original sequence.we will find the start point:
>     >          14 zeros+ 0  +0  +0(the position of 17).......And I think the
>     > result may be wrong.
>     >
>     >          Can someone explain it? Clear it.
>     >
>     >          2.How the above block cooperate with the block(head/payload
>     > Demux) to find the start point of the sequence?
>     >
>     >         Can someone use the above example to explain it?
>     >
>     >
>     > Thank you so much.I'm so confused about the design of the receiver.
>     >
>     >
>     > Best regards,
>     > xd
>     >
>     >
>     > _______________________________________________
>     > Discuss-gnuradio mailing list
>     > address@hidden <mailto:address@hidden>
>     > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>     >
>
>
>     _______________________________________________
>     Discuss-gnuradio mailing list
>     address@hidden <mailto:address@hidden>
>     https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>



reply via email to

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