discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Channel estimation OFDM saving taps


From: Vinicius Mesquita
Subject: Re: Channel estimation OFDM saving taps
Date: Wed, 4 Mar 2020 10:14:59 +0100

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) <address@hidden> 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!!

reply via email to

[Prev in Thread] Current Thread [Next in Thread]