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 <[email protected]>:
> 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 <[email protected]
> > <mailto:[email protected]>>:
> >
> > 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
> > > [email protected] <mailto:[email protected]>
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > >
> >
> >
> > _______________________________________________
> > Discuss-gnuradio mailing list
> > [email protected] <mailto:[email protected]>
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> >
>
>
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
