[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
>
>