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 <martin.br...@ettus.com
> <mailto:martin.br...@ettus.com>>:
> 
>     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
>     > Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
>     > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>     >
> 
> 
>     _______________________________________________
>     Discuss-gnuradio mailing list
>     Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
>     https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 


_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to