Hi again,
My current suspicion is that there is a triggering delay produced by
the *Schmidl
& Cox OFDM Sync* block that isn't accounted for by the *delay* block
currently running in parallel to it in the flowgraph (delays samples going
to the header/payload demux until the trigger point is found in the sync
words). On the default 64 FFT + 16 cyclic prefix arrangement for example,
if I change the delay block from 80 to 73, it results in a unity OFDM
channel estimation and I am able to decode successfully using my comb pilot
interpolation equalisation technique (also: 89 gets unity alternating
between the real and imaginary). It does appear however that the first
estimation is off before correctly reaching unity on the second packet.
This effect disappears if I bypass my *channel model *block (epsilon = 1,
taps = 1.0, noise voltage = 0, frequency offset = 0). This raises the
question of whether this triggering delay is somehow variable and depends
on what blocks are currently in the flowgraph...?
As a comparison, when I changed to having the header/payload demux
triggered by a tag instead of the trigger port, I achieved a unity channel
estimation.
Is there something I'm misinterpreting about the Schmidl & Cox method's
triggering or is this a known issue? Thanks for your help.
Regards,
Justin
On Mon, May 8, 2017 at 1:01 PM, Justin Hamilton
wrote:
> Hi everyone,
>
> I've been working on a coded-OFDM system (looks similar to the standard
> OFDM flowgraphs) and have come to the stage where I am trying to improve
> channel estimation by implementing LS, STA and comb pilot interpolation
> methods similar to gr-ieee802.11. If I follow the default technique
> outlined in *ofdm_equalizer_simpledfe* and equalise just a single
> subcarrier using its estimated tap calculated by the *OFDM Channel
> Estimation* block, everything behaves as usual and I can decode my OFDM
> packets. If however I start using neighbouring subcarriers as per STA or
> when interpolating pilots, I am unable to decode any symbols.
>
> Suspecting something strange was going on, I began investigating my
> flowgraph. Since I am running the system in simulation across a perfect
> channel, I would have expected the channel taps derived by the *OFDM
> Channel Estimation* block to all be equal to 1. Instead each channel
> appeared to be experiencing it's own arbitrary value (which explains why
> using multiple subcarriers wouldn't work). Since they are not equal to 1, I
> figured some other part of the flowgraph must be applying some unintended
> modulation.
>
> At first I suspected irreversibility between the FFT/IFFT blocks, but
> after ensuring both were using *fft.window.rectangular(fft_len)* as the
> selected window function and correctly rescaling after the FFT, I was able
> to successfully recover the original signal directly after the IFFT. Next I
> took a look at the *cyclic prefixer* and *header/payload demux* combo,
> but after using a *Keep M in N *block after the *cyclic prefixer *I was
> again able to recover the signal.
>
> This left only the *Schmidl & Cox OFDM Sync* block, *analog frequency
> modulation* block and the subsequent multiplication. Since I was on a
> perfect channel, it was no surprise that the fine frequency offset was 0Hz,
> meaning the frequency mod block resulted in a simply multiplication by 1.
> However,replacing the input to the frequency mod block with a constant
> source of zero changed the resulting channel estimations further down the
> line and meant they were correct (unity) for at least one packet (and again
> on every third packet for some reason...) I can't really explain what's
> going on...?
>
> Now I might be on the totally incorrect path here, so if anyone has any
> suspicions or could recommend something for me to try out, it would be
> greatly appreciated. I could be misinterpreting the Schmidl/Cox technique
> for example or the role of channel equalisation altogether. Thanks in
> advance for your help!
>
> Regards,
> Justin
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
