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.
On Mon, May 8, 2017 at 1:01 PM, Justin Hamilton <justham101@gmail.com> wrote:
JustinRegards,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!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...?
No comments:
Post a Comment