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: Martin Braun
Subject: Re: [Discuss-gnuradio] question about the qa_ofdm_sync_sc_cfb.py
Date: Tue, 10 Nov 2015 15:42:19 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

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]