Re: [Discuss-gnuradio] ofdm_chanest_vcvc_impl.cc
Hi Martin: Thank you so much for your kindly reply.So kindly of you.I understand it. Best regards, zs At 2015-02-02 18:24:25, "Martin Braun" wrote: >I'll try and keep it short and simple: > >First: What's the difference between a cyclic shift and a non-cyclic >shift? It means that sub-carriers from one end are moved the other end. >So, if we have 8 subcarriers arranged like this: > >0, 1, 2, 3, 4, 5, 6, 7 > >and do a cyclic shift, we get something like > >1, 2, 3, 4, 5, 6, 7, 0 > >Right? > >OK, here's why this would never even be an issue in practice: As you >know, a subcarrier has the same width as the corresponding FFT bin. But >you never use all FFT bins. Best example is Wi-Fi, where you have an FFT >length of 64 in the modulation/demodulation phase, but only use 52 >carriers (outside of the DC carrier). So, all bins at the edge of your >Nyquist zone are not used. Using the example before, it would be >something like: > >x, x, 0, 1, 2, 3, x, x > >Now, if do a shift (cyclic or not) of length 1 (note that in the S&C >setup, you'd have multiples of 2 for the shift), you get this: > >x, 0, 1, 2, 3, x, x, x > >Now, in the implementation, I can copy the left-most 'x' to the right, >but what's the point? There's no information there. So I just do a >memcpy with an offset. Much simpler, does the same. > >So, you might be tempted to say "non-cyclic or cyclic, it doesn't really >matter". In practice, given what I just discussed, that's kind of >correct. But, assume you have a really, really big frequency offset. >Your relevant carriers will be cut off by the resampling filters (or >even the analog filters) before they even hit the FFT. So, you'd have >something like this: > >1, 2, 3, x, x, x, x, x > >No shifting, cyclic or non-cyclic, can save you now. > >So where does this cyclic stuff come from? > >Well, in the pure discrete domain, when you do frequency shifts by >multiplying with complex sinusoids, a frequency offset *will* be >"cyclic". You might even run into this in reality even, because in >Schmidl & Cox, before you correct the integer FO, you correct the fine >FO with such a sinusoid multiplication. So, cyclic isn't "wrong", per >se. But it's not really required. > >However, if you take away a single piece of information from this, let >it be this: In practice, you design your parameters such that it doesn't >matter if you shift cyclically or non-cyclically. In that case, the >latter is less computationally heavy. > >M > >On 02/02/2015 09:09 AM, zs wrote: >> Hi Martin: >> Thank you in advance.I have read many papers on the >> topic "integer cfo of OFDM".They all said it make the subcarriers cyclic >> shift. >> For example: >> " >> http://nutaq.com/en/blog/brief-overview-frequency-synchronization-ofdm " >> It said "Integer CFO does not introduce ICI between sub-carriers, but >> does introduce a cyclic shift of data sub-carriers..." >> Is it right?And the source code ofdm_chanest_vcvc_impl.cc is right?Maybe >> I'm wrong.Can you explain it?Thank you. >> Best regards, >> zs >> >> >> >> >> >> >> >> At 2015-01-25 19:27:30, "Martin Braun" wrote: >>>On 01/25/2015 08:10 AM, zs wrote: Hi Martin: Thank you for your reply.And we know this block do "Estimate channel and coarse frequency offset for OFDM from preambles".And the coarse frequency offset is a integer.And it make the subcarriers cyclic shift.Just illustration as this: >>> >>>No cyclic shift. There must be enough space between the out subcarriers >>>and the Nyquist zone boundaries. Hope this clears things up! >>> >>>And please respond to the list. >>> >>>M >>> >>>___ >>>Discuss-gnuradio mailing list >>>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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ofdm_chanest_vcvc_impl.cc
I'll try and keep it short and simple: First: What's the difference between a cyclic shift and a non-cyclic shift? It means that sub-carriers from one end are moved the other end. So, if we have 8 subcarriers arranged like this: 0, 1, 2, 3, 4, 5, 6, 7 and do a cyclic shift, we get something like 1, 2, 3, 4, 5, 6, 7, 0 Right? OK, here's why this would never even be an issue in practice: As you know, a subcarrier has the same width as the corresponding FFT bin. But you never use all FFT bins. Best example is Wi-Fi, where you have an FFT length of 64 in the modulation/demodulation phase, but only use 52 carriers (outside of the DC carrier). So, all bins at the edge of your Nyquist zone are not used. Using the example before, it would be something like: x, x, 0, 1, 2, 3, x, x Now, if do a shift (cyclic or not) of length 1 (note that in the S&C setup, you'd have multiples of 2 for the shift), you get this: x, 0, 1, 2, 3, x, x, x Now, in the implementation, I can copy the left-most 'x' to the right, but what's the point? There's no information there. So I just do a memcpy with an offset. Much simpler, does the same. So, you might be tempted to say "non-cyclic or cyclic, it doesn't really matter". In practice, given what I just discussed, that's kind of correct. But, assume you have a really, really big frequency offset. Your relevant carriers will be cut off by the resampling filters (or even the analog filters) before they even hit the FFT. So, you'd have something like this: 1, 2, 3, x, x, x, x, x No shifting, cyclic or non-cyclic, can save you now. So where does this cyclic stuff come from? Well, in the pure discrete domain, when you do frequency shifts by multiplying with complex sinusoids, a frequency offset *will* be "cyclic". You might even run into this in reality even, because in Schmidl & Cox, before you correct the integer FO, you correct the fine FO with such a sinusoid multiplication. So, cyclic isn't "wrong", per se. But it's not really required. However, if you take away a single piece of information from this, let it be this: In practice, you design your parameters such that it doesn't matter if you shift cyclically or non-cyclically. In that case, the latter is less computationally heavy. M On 02/02/2015 09:09 AM, zs wrote: > Hi Martin: > Thank you in advance.I have read many papers on the > topic "integer cfo of OFDM".They all said it make the subcarriers cyclic > shift. > For example: > " > http://nutaq.com/en/blog/brief-overview-frequency-synchronization-ofdm " > It said "Integer CFO does not introduce ICI between sub-carriers, but > does introduce a cyclic shift of data sub-carriers..." > Is it right?And the source code ofdm_chanest_vcvc_impl.cc is right?Maybe > I'm wrong.Can you explain it?Thank you. > Best regards, > zs > > > > > > > > At 2015-01-25 19:27:30, "Martin Braun" wrote: >>On 01/25/2015 08:10 AM, zs wrote: >>> Hi Martin: >>> Thank you for your reply.And we know this block do >>> "Estimate channel and coarse frequency offset for OFDM from >>> preambles".And the coarse frequency offset is a integer.And it make the >>> subcarriers cyclic shift.Just illustration as this: >> >>No cyclic shift. There must be enough space between the out subcarriers >>and the Nyquist zone boundaries. Hope this clears things up! >> >>And please respond to the list. >> >>M >> >>___ >>Discuss-gnuradio mailing list >>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
Re: [Discuss-gnuradio] ofdm_chanest_vcvc_impl.cc
Hi Martin: Thank you in advance.I have read many papers on the topic "integer cfo of OFDM".They all said it make the subcarriers cyclic shift. For example: " http://nutaq.com/en/blog/brief-overview-frequency-synchronization-ofdm " It said "Integer CFO does not introduce ICI between sub-carriers, but does introduce a cyclic shift of data sub-carriers..." Is it right?And the source code ofdm_chanest_vcvc_impl.cc is right?Maybe I'm wrong.Can you explain it?Thank you. Best regards, zs At 2015-01-25 19:27:30, "Martin Braun" wrote: >On 01/25/2015 08:10 AM, zs wrote: >> Hi Martin: >> Thank you for your reply.And we know this block do >> "Estimate channel and coarse frequency offset for OFDM from >> preambles".And the coarse frequency offset is a integer.And it make the >> subcarriers cyclic shift.Just illustration as this: > >No cyclic shift. There must be enough space between the out subcarriers >and the Nyquist zone boundaries. Hope this clears things up! > >And please respond to the list. > >M > >___ >Discuss-gnuradio mailing list >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
Re: [Discuss-gnuradio] ofdm_chanest_vcvc_impl.cc
On 01/25/2015 08:10 AM, zs wrote: > Hi Martin: > Thank you for your reply.And we know this block do > "Estimate channel and coarse frequency offset for OFDM from > preambles".And the coarse frequency offset is a integer.And it make the > subcarriers cyclic shift.Just illustration as this: No cyclic shift. There must be enough space between the out subcarriers and the Nyquist zone boundaries. Hope this clears things up! And please respond to the list. M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ofdm_chanest_vcvc_impl.cc
Hi Martin: Thank you for your reply.And we know this block do "Estimate channel and coarse frequency offset for OFDM from preambles".And the coarse frequency offset is a integer.And it make the subcarriers cyclic shift.Just illustration as this: For example,we have 5 subcarriers,cfo=2. Right subcarriers:s1,s2,s3,s4,s5 Wrong subcarriers:s4,s5,s1,s2,s3 So the channel estimation coefficients will not be zeros.Is it right? Best regards, zswx At 2015-01-25 03:38:38, "Martin Braun" wrote: >On 01/24/2015 08:43 AM, zs wrote: >> Now the taps only have values on taps[0]---taps[63-2],and taps[62] >> taps[63] will be equal to zero.It means that the channel estimation have >> value 0.It is wrong? > >They will be zero, and it's not wrong. What else should be written here? >There's no useful information outside the frame. > >M > > >___ >Discuss-gnuradio mailing list >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
Re: [Discuss-gnuradio] ofdm_chanest_vcvc_impl.cc
On 01/24/2015 08:43 AM, zs wrote: > Now the taps only have values on taps[0]---taps[63-2],and taps[62] > taps[63] will be equal to zero.It means that the channel estimation have > value 0.It is wrong? They will be zero, and it's not wrong. What else should be written here? There's no useful information outside the frame. M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] ofdm_chanest_vcvc_impl.cc
Hi all:
Thank you in advance.I have read the source
code:ofdm_chanest_vcvc_impl.cc.But i have a question.
void
ofdm_chanest_vcvc_impl::get_chan_taps(
const gr_complex *sync_sym1,
const gr_complex *sync_sym2,
int carr_offset,
std::vector &taps)
{
const gr_complex *sym = ((d_n_sync_syms == 2) ? sync_sym2 : sync_sym1);
std::fill(taps.begin(), taps.end(), gr_complex(0, 0));
int loop_start = 0;
int loop_end = d_fft_len;
if (carr_offset > 0) {
loop_start = carr_offset;
} else if (carr_offset < 0) {
loop_end = d_fft_len + carr_offset;
}
for (int i = loop_start; i < loop_end; i++) {
if ((d_ref_sym[i-carr_offset] != gr_complex(0, 0))) {
taps[i-carr_offset] = sym[i] / d_ref_sym[i-carr_offset];
}
}
//Question:
//For example,when the carr_offset=2,then:
//loop_start =2;
//for example loop_end=64
// for (int i =2; i < loop_end; i++) {
if ((d_ref_sym[i-carr_offset] != gr_complex(0, 0))) {
taps[i-carr_offset] = sym[i] / d_ref_sym[i-carr_offset];
}
}
//
Now the taps only have values on taps[0]---taps[63-2],and taps[62] taps[63]
will be equal to zero.It means that the channel estimation have value 0.It is
wrong?
if (d_interpolate) {
for (int i = d_first_active_carrier + 1; i < d_last_active_carrier; i += 2)
{
taps[i] = taps[i-1];
}
taps[d_last_active_carrier] = taps[d_last_active_carrier-1];
}
if (d_eq_noise_red_len) {
// TODO
// 1) IFFT
// 2) Set all elements > d_eq_noise_red_len to zero
// 3) FFT
}
}
Thank you.
Best regards,
zswx
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] ofdm_chanest_vcvc_impl.cc
Hi all:
Thank you in advance.I have read the source
code:ofdm_chanest_vcvc_impl.cc.But i have a question.
void
ofdm_chanest_vcvc_impl::get_chan_taps(
const gr_complex *sync_sym1,
const gr_complex *sync_sym2,
int carr_offset,
std::vector &taps)
{
const gr_complex *sym = ((d_n_sync_syms == 2) ? sync_sym2 : sync_sym1);
std::fill(taps.begin(), taps.end(), gr_complex(0, 0));
int loop_start = 0;
int loop_end = d_fft_len;
if (carr_offset > 0) {
loop_start = carr_offset;
} else if (carr_offset < 0) {
loop_end = d_fft_len + carr_offset;
}
for (int i = loop_start; i < loop_end; i++) {
if ((d_ref_sym[i-carr_offset] != gr_complex(0, 0))) {
taps[i-carr_offset] = sym[i] / d_ref_sym[i-carr_offset];
}
}
//Question:
//For example,when the carr_offset=2,then:
//loop_start =2;
//for example loop_end=64
// for (int i =2; i < loop_end; i++) {
if ((d_ref_sym[i-carr_offset] != gr_complex(0, 0))) {
taps[i-carr_offset] = sym[i] / d_ref_sym[i-carr_offset];
}
}
//
Now the taps only have values on taps[0]---taps[63-2],and taps[62] taps[63]
will be equal to zero.It means that the channel estimation have value 0.It is
wrong?
if (d_interpolate) {
for (int i = d_first_active_carrier + 1; i < d_last_active_carrier; i += 2)
{
taps[i] = taps[i-1];
}
taps[d_last_active_carrier] = taps[d_last_active_carrier-1];
}
if (d_eq_noise_red_len) {
// TODO
// 1) IFFT
// 2) Set all elements > d_eq_noise_red_len to zero
// 3) FFT
}
}
Thank you.
Best regards,
zswx
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
