Thank you so much for your answer, Marcus. I understood everything. I'm going to try to build my own block.
Have a nice day. On Tue, Mar 3, 2020 at 9:48 PM Müller, Marcus (CEL) <muel...@kit.edu> wrote: > Hi Vinicius, > > you can directly feed the output of the OFDM channel estimation block > into a simple general block that you write yourself[1] – even in Python > – and make that block > > * either save the contents of the relevant tags to a file or > * output a vector of (inverse) channel coefficients taken from the > `ofdm_sync_eq_taps` tag. > > Generally, however, never forget that OFDM channel estimations are > *not* a property of the _channel_, but of the _receiver_: > If you recall the effects of having a cyclic prefix in OFDM, you'll > remember that it's not critical that your receiver is in perfect time > synchronity with the beginning of the actual payload part of the symbol > (after the CP). > > Instead, as long as your FFT starts *somewhere* in the cyclic prefix, > you're fine synchronization-wise, since a (simulatedly) circular time > shift (due to starting the FFT in the CP instead of exactly at the > start of symbol after the CP) is just a point-wise multiplication with > a complex sinusoid after the FFT – and that means your timing offset > will just manifest as rotation of the channel coefficients. > > And you're correcting these, anyway. So, as long as a CP-OFDM receiver > is consistent in the amount of time it starts doing the FFT before the > end of CP, the rotation each subcarrier coefficient experiences is > always the same and will thus be corrected (e.g. through pilot > estimation). > > But: That means that your channel estimate is not the same you'd get > when you're even a fraction of a sample off in timing compared to > someone else. It's still the same, ignoring complex rotation, so the > power delay profile will be right, and when you agree on e.g. an > average phase of symbols, you can compare different channel estimates, > but don't directly compare the channel estimates from different > receivers, or the same receiver over more than a frame, or after > tuning. > > Best regards, > Marcus > > [1] https://tutorials.gnuradio.org > > PS: long-term observers will know that I fought very hard to not embed > loads of LaTeX in this reply. > > On Tue, 2020-03-03 at 16:39 +0100, Vinicius Mesquita wrote: > > Hello. > > Thank you in advance for the help... > > > > I already searched the mailing list and could not find it how to > properly see/save the channel taps from the OFDM Channel Estimation block. > I saw that is in a tag, but how can I save it? > > > > What I'd love to find is a way to see the channel estimation with the 52 > taps in a QT GUI plot. Is that possible? If it's not, saving it it's > already awesome. > > > > Thank you!! >
