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 <justham...@gmail.com> 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
