Re: [Discuss-gnuradio] OFDM channel tap questions
Hi Bob, Thanks for your detailed explanation. I figured out the causes for non-unity channel taps in my case. One is I didn’t consider normalization. Second, it was because that the Schmidl-Cox sync has a metric plateau. Imperfect synchronization gave me the phase rotation. Regards, Edwin Sent from Mail for Windows 10 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM channel tap questions
Orthogonality (as the O in OFDM) guarantees a fixed phase relationship for every symbol unless a pattern is introduced in an effort to reduce peak to average power ratio (which I do not believe is happening here). PAPR is bane of OFDM and much research has gone in to reduce this problem which requires high linearity in the amplifiers in cell towers. Linearity is typically accompanied by poor efficiency (lots of heat goes along with watts). In addition to this , there is indeed a random process involved in the synchronization. Schmidl-Cox is imperfect and "fine tuning" of the sampling phase also has some randomness. On the air you will have phase offsets due to frequency dependent group delay through the analog components of the RF systems, group delay due to multipath, and on and on. I didn't open your grc file but I assume this was the perfect "wire" channel with additive noise in which case ignore all of the other analog stuff I added. Bob On Fri, Jan 12, 2018 at 2:22 PM, Jeff Long wrote: > Ah, normalization was the secret. The phase offset is there because the > subcarriers frequencies each look like a phasor that keeps moving (at a > rate relative to its offset). You want to predict what the phase will be at > the next symbol. > > > On 01/12/2018 01:59 PM, edwin wrote: > >> Hi Jeff, >> >> I just found out that if I normalize these taps by the FFT number(64 in >> this case), they have magnitude of 1! Now my questions are: >> >> Why are there phase offset? The phase offset for each subchannel seems >> different. Is it because of imperfect synchronization? >> >> >> Regards, >> >> Edwin >> >> > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > -- Bob McGwier Founder, Federated Wireless, Inc Founder and Technical Advisor, HawkEye 360, Inc Research Professor Virginia Tech Chief Scientist: The Ted and Karyn Hume Center for National Security and Technology Senior Member IEEE, Facebook: N4HYBob, ARS: N4HY Faculty Advisor Virginia Tech Amateur Radio Assn, Trustee K4KDJ Director of AMSAT Member of PVRC (Roanoke-Blacksburg), TAPR, life member of ARRL and AMSAT, NRVR.ORG (Rocketry) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM channel tap questions
Ah, normalization was the secret. The phase offset is there because the subcarriers frequencies each look like a phasor that keeps moving (at a rate relative to its offset). You want to predict what the phase will be at the next symbol. On 01/12/2018 01:59 PM, edwin wrote: Hi Jeff, I just found out that if I normalize these taps by the FFT number(64 in this case), they have magnitude of 1! Now my questions are: Why are there phase offset? The phase offset for each subchannel seems different. Is it because of imperfect synchronization? Regards, Edwin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM channel tap questions
Hi Jeff, I just found out that if I normalize these taps by the FFT number(64 in this case), they have magnitude of 1! Now my questions are: Why are there phase offset? The phase offset for each subchannel seems different. Is it because of imperfect synchronization? Regards, Edwin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM channel tap questions
I have to agree with you, and I don't understand what's going on. It
looks like the magnitude of the taps should be 1.0, even if there's a
phase offset.
On 01/11/2018 03:53 PM, edwin wrote:
Hi Jeff,
Thanks for the reply. What you said about the noise makes sense.
However, even if I turn the noise off, I still get the weired taps:
Offset: 2112 Source: n/a Key: ofdm_sync_chan_taps Value: #[(0,0)
(0,0) (0,0) (0,0) (0,0) (0,0) (35.5567,-53.2143) (-6.27313,-63.6921)
(-45.255,-45.255) (-63.6921,-6.27313) (-53.2143,35.5567)
(-18.5783,61.2445) (24.4919,59.1286) (56.4432,30.1695)
(62.7706,-12.4858) (40.6014,-49.4729) (2.45706e-06,-64.0003)
(-40.6014,-49.4729) (-62.7706,-12.4858) (-56.4432,30.1695)
(-24.4919,59.1286) (18.5783,61.2445) (53.2143,35.5567)
(6.36922,-0.627315) (4.52551,-4.52551) (6.27312,-63.6921)
(-3.55567,-5.32143) (-6.12445,-1.85783) (-5.91286,2.44919)
(-3.01695,5.64432) (1.24858,6.27706) (4.94729,4.06014) (0,0)
(4.94729,-4.06014) (1.24858,-6.27706) (-3.01696,-5.64433)
(-5.91286,-2.44919) (-6.12445,1.85783) (-3.55567,5.32144)
(6.27312,63.6921) (4.52551,4.52551) (6.36922,0.627312)
(5.32143,-3.55567) (1.85783,-6.12445) (-2.44919,-5.91286)
(-5.64433,-3.01696) (-6.27706,1.24858) (-4.06014,4.94729)
(-1.9985e-06,6.40003) (4.06014,4.94729) (6.27706,1.24858)
(5.64432,-3.01696) (2.44918,-5.91286) (-18.5783,-61.2445)
(-5.32143,-3.55567) (-6.36922,0.62731) (-4.52551,4.52551)
(-0.627314,6.36921) (3.55567,5.32143) (0,0) (0,0) (0,0) (0,0) (0,0)]
The piece of code you posted:
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];
}
}
I believe it comes from the ofdm_chanest_vcvc_impl.cc, doesn't it?
According to my understanding, it is calculating the channel taps by
dividing the received symbol with the sync symbols, which are known. If
the channel is perfect and there is no noise, the received symbols
should be exactly the same as the sync symbols. The channel taps should
be 1.
Regards,
Edwin
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM channel tap questions
Hi Jeff,
Thanks for the reply. What you said about the noise makes sense.
However, even if I turn the noise off, I still get the weired taps:
Offset: 2112 Source: n/a Key: ofdm_sync_chan_taps Value: #[(0,0)
(0,0) (0,0) (0,0) (0,0) (0,0) (35.5567,-53.2143) (-6.27313,-63.6921)
(-45.255,-45.255) (-63.6921,-6.27313) (-53.2143,35.5567)
(-18.5783,61.2445) (24.4919,59.1286) (56.4432,30.1695)
(62.7706,-12.4858) (40.6014,-49.4729) (2.45706e-06,-64.0003)
(-40.6014,-49.4729) (-62.7706,-12.4858) (-56.4432,30.1695)
(-24.4919,59.1286) (18.5783,61.2445) (53.2143,35.5567)
(6.36922,-0.627315) (4.52551,-4.52551) (6.27312,-63.6921)
(-3.55567,-5.32143) (-6.12445,-1.85783) (-5.91286,2.44919)
(-3.01695,5.64432) (1.24858,6.27706) (4.94729,4.06014) (0,0)
(4.94729,-4.06014) (1.24858,-6.27706) (-3.01696,-5.64433)
(-5.91286,-2.44919) (-6.12445,1.85783) (-3.55567,5.32144)
(6.27312,63.6921) (4.52551,4.52551) (6.36922,0.627312)
(5.32143,-3.55567) (1.85783,-6.12445) (-2.44919,-5.91286)
(-5.64433,-3.01696) (-6.27706,1.24858) (-4.06014,4.94729)
(-1.9985e-06,6.40003) (4.06014,4.94729) (6.27706,1.24858)
(5.64432,-3.01696) (2.44918,-5.91286) (-18.5783,-61.2445)
(-5.32143,-3.55567) (-6.36922,0.62731) (-4.52551,4.52551)
(-0.627314,6.36921) (3.55567,5.32143) (0,0) (0,0) (0,0) (0,0) (0,0)]
The piece of code you posted:
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];
}
}
I believe it comes from the ofdm_chanest_vcvc_impl.cc, doesn't it?
According to my understanding, it is calculating the channel taps by
dividing the received symbol with the sync symbols, which are known. If
the channel is perfect and there is no noise, the received symbols
should be exactly the same as the sync symbols. The channel taps should
be 1.
Regards,
Edwin
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM channel tap questions
Hmm, that wasn't the whole answer. After reading the code a little more,
it looks like the taps are a function of the sync symbols too, not just
the channel.
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];
}
}
On 01/10/2018 06:19 PM, Jeff Long wrote:
Noise has some bias and structure when measured over a short period. You
can see this on a FFT display, where larger transforms give you a
smoother noise floor. You'll notice that the taps change randomly with
every packet as the estimator adjusts to the noise.
On 01/10/2018 04:59 PM, Edwin Li wrote:
Hi all,
I run the example found in the
~/prefix/share/gnuradio/examples/digital/ofdm/rx_ofdm.grc. The ofdm
signals can be decoded correctly. But I don't understand the channel
taps.
The channel taps are shown to be
Key: ofdm_sync_chan_taps Value: #[(0,0) (0,0) (0,0) (0,0) (0,0)
(0,0) (64.2159,-3.65375) (47.2264,-42.4505) (8.44977,-62.8107)
(-32.7931,-54.5247) (-59.9085,-21.3488) (-59.8031,23.3288)
(-32.3382,55.4137) (9.05079,63.8184) (46.331,42.7923)
(65.1778,2.83559) (51.1081,-38.6363) (15.815,-62.1237)
(-27.1419,-57.8722) (-58.2753,-27.4043) (-62.3711,15.658)
(-37.9986,51.1873) (3.2302,64.2116) (5.44772,5.36124)
(6.75629,1.41069) (54.079,-33.4137) (2.19591,-6.12473)
(-1.91544,-6.56722) (-5.87699,-3.166) (-6.83039,0.994718)
(-4.49682,5.42143) (-0.363706,6.79664) (0,0) (6.653,1.39701)
(6.73628,-2.57781) (2.83963,-6.40383) (-1.3027,-7.62756)
(-5.2442,-4.20318) (-7.30496,-0.464149) (-46.0595,43.0102)
(-1.1131,6.52395) (3.2,5.98481) (6.67649,1.87579)
(6.12278,-2.4737) (3.20924,-5.88361) (-1.73027,-7.05576)
(-5.08706,-4.94171) (-6.68616,-0.0110321) (-5.45217,3.92032)
(-1.28323,7.08399) (3.24904,6.21134) (6.67752,2.90531)
(7.18779,-1.51598) (36.8116,-51.7724) (0.146267,-7.00651)
(-4.51996,-4.89137) (-7.37838,-1.41322) (-6.20339,3.98806)
(-2.49422,6.80633) (0,0) (0,0) (0,0) (0,0) (0,0)]
This is weired. The channel is just AWGN. Why are not the channel
taps 1?
I found the same question posted before.
https://lists.gnu.org/archive/html/discuss-gnuradio/2017-05/msg00057.html.
But didn't see the answer.
I'm running GNU Radio Companion 3.7.12 by the way. The example can be
found in the attachment.
Regards,
Edwin
___
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 channel tap questions
Noise has some bias and structure when measured over a short period. You can see this on a FFT display, where larger transforms give you a smoother noise floor. You'll notice that the taps change randomly with every packet as the estimator adjusts to the noise. On 01/10/2018 04:59 PM, Edwin Li wrote: Hi all, I run the example found in the ~/prefix/share/gnuradio/examples/digital/ofdm/rx_ofdm.grc. The ofdm signals can be decoded correctly. But I don't understand the channel taps. The channel taps are shown to be Key: ofdm_sync_chan_taps Value: #[(0,0) (0,0) (0,0) (0,0) (0,0) (0,0) (64.2159,-3.65375) (47.2264,-42.4505) (8.44977,-62.8107) (-32.7931,-54.5247) (-59.9085,-21.3488) (-59.8031,23.3288) (-32.3382,55.4137) (9.05079,63.8184) (46.331,42.7923) (65.1778,2.83559) (51.1081,-38.6363) (15.815,-62.1237) (-27.1419,-57.8722) (-58.2753,-27.4043) (-62.3711,15.658) (-37.9986,51.1873) (3.2302,64.2116) (5.44772,5.36124) (6.75629,1.41069) (54.079,-33.4137) (2.19591,-6.12473) (-1.91544,-6.56722) (-5.87699,-3.166) (-6.83039,0.994718) (-4.49682,5.42143) (-0.363706,6.79664) (0,0) (6.653,1.39701) (6.73628,-2.57781) (2.83963,-6.40383) (-1.3027,-7.62756) (-5.2442,-4.20318) (-7.30496,-0.464149) (-46.0595,43.0102) (-1.1131,6.52395) (3.2,5.98481) (6.67649,1.87579) (6.12278,-2.4737) (3.20924,-5.88361) (-1.73027,-7.05576) (-5.08706,-4.94171) (-6.68616,-0.0110321) (-5.45217,3.92032) (-1.28323,7.08399) (3.24904,6.21134) (6.67752,2.90531) (7.18779,-1.51598) (36.8116,-51.7724) (0.146267,-7.00651) (-4.51996,-4.89137) (-7.37838,-1.41322) (-6.20339,3.98806) (-2.49422,6.80633) (0,0) (0,0) (0,0) (0,0) (0,0)] This is weired. The channel is just AWGN. Why are not the channel taps 1? I found the same question posted before. https://lists.gnu.org/archive/html/discuss-gnuradio/2017-05/msg00057.html. But didn't see the answer. I'm running GNU Radio Companion 3.7.12 by the way. The example can be found in the attachment. Regards, Edwin ___ 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] OFDM channel tap questions
Hi all, I run the example found in the ~/prefix/share/gnuradio/examples/digital/ofdm/rx_ofdm.grc. The ofdm signals can be decoded correctly. But I don't understand the channel taps. The channel taps are shown to be Key: ofdm_sync_chan_taps Value: #[(0,0) (0,0) (0,0) (0,0) (0,0) (0,0) (64.2159,-3.65375) (47.2264,-42.4505) (8.44977,-62.8107) (-32.7931,-54.5247) (-59.9085,-21.3488) (-59.8031,23.3288) (-32.3382,55.4137) (9.05079,63.8184) (46.331,42.7923) (65.1778,2.83559) (51.1081,-38.6363) (15.815,-62.1237) (-27.1419,-57.8722) (-58.2753,-27.4043) (-62.3711,15.658) (-37.9986,51.1873) (3.2302,64.2116) (5.44772,5.36124) (6.75629,1.41069) (54.079,-33.4137) (2.19591,-6.12473) (-1.91544,-6.56722) (-5.87699,-3.166) (-6.83039,0.994718) (-4.49682,5.42143) (-0.363706,6.79664) (0,0) (6.653,1.39701) (6.73628,-2.57781) (2.83963,-6.40383) (-1.3027,-7.62756) (-5.2442,-4.20318) (-7.30496,-0.464149) (-46.0595,43.0102) (-1.1131,6.52395) (3.2,5.98481) (6.67649,1.87579) (6.12278,-2.4737) (3.20924,-5.88361) (-1.73027,-7.05576) (-5.08706,-4.94171) (-6.68616,-0.0110321) (-5.45217,3.92032) (-1.28323,7.08399) (3.24904,6.21134) (6.67752,2.90531) (7.18779,-1.51598) (36.8116,-51.7724) (0.146267,-7.00651) (-4.51996,-4.89137) (-7.37838,-1.41322) (-6.20339,3.98806) (-2.49422,6.80633) (0,0) (0,0) (0,0) (0,0) (0,0)] This is weired. The channel is just AWGN. Why are not the channel taps 1? I found the same question posted before. https://lists.gnu.org/archive/html/discuss-gnuradio/2017-05/msg00057.html. But didn't see the answer. I'm running GNU Radio Companion 3.7.12 by the way. The example can be found in the attachment. Regards, Edwin rx_ofdm.grc Description: Binary data ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
