Re: [Discuss-gnuradio] A few questions regarding gr-ieeee802-11

[Tal Peer]

Hi Bastian,

Thanks for the clarification about the matched filter -- I basically got the scaling part wrong. Now everything makes sense. 

About the next into master merge: I understand that currently master is the 3.7 branch and next the 3.8 branch (or is it?), so can we expect a 3.8 release when the merge happens?

Cheers,

Tal

On Fri, Jun 8, 2018 at 12:48 PM, Bastian Bloessl <address@hidden> wrote:

Hi,

On 06/08/2018 10:18 AM, Tal Peer wrote:

1. In the Sync Long block, the input is put through a matched filter defined by the long training sequence in time domain. I'm probably overseeing something here, but  I would expect this sequence to be the same as the sequence given in table I-6 of the standard (well, a part of it at least, since it repeats 2.5 times). Now, I understand the LONG vector is generated using the create_long.R script and not knowing any R I tried to reproduce this in MATLAB. However, after some experiments I figured that in order to reproduce the same sequence I have to run in MATLAB (a is the freq. domain sequence):

fliplr(fft(ifftshift(a)/sqrt(52)))

where from the R script I would actually expect (as we're transforming the sequence from frequency to time domain and also conjugating it to create a matched filter):

fliplr(conj(ifft(fftshift(a)/sqrt(52))))

I'm not sure if I understand you correctly. It sounds like you think the steps in the R-script are reasonable, but you fail to reproduce it in MATLAB. I don't have MATLAB, so I cannot test it, but maybe you forgot an 'i' and were using the fft instead of the ifft.

I've done it again in Python and it results in exactly the steps that you seem to expect.

To reproduce the sequence in the standard:

<snip>
import numpy as np

# frequency domain
fd = np.array([0]*6 + [1, 1, -1, -1, 1, 1, -1, 1, -1, 1, 1, 1, 1, 1, 1, -1, -1, 1, 1, -1, 1, -1, 1, 1, 1, 1, 0, 1, -1, -1, 1, 1, -1, 1, -1, 1, -1, -1, -1, -1, -1, 1, 1, -1, -1, 1, -1, 1, -1, 1, 1, 1, 1] + [0]*5)

# time domain
td = np.fft.ifft(np.fft.ifftshift(fd/64**.5), norm="ortho")

sync_long = np.append(td[32:], [td, td])
# sequence in standard considers windowing
sync_long[0] = sync_long[0] / 2

# Standard, Appendix I
sync_long

</snip>


To reproduce the sequence in the code:

<snip>

# taps for matched filter (I used a different/weird scaling)
m = np.fft.ifft(np.fft.ifftshift(fd), norm="ortho") * (64.0/52)**.5
m = np.conj(m)
m = m[::-1] # reverse for d_fir kernel (which reverses again)
# sequence in sync_long block
m

</snip>

I think I might be missing something here and would be glad if someone could shed some light on this.

2. As seen in the provided examples, the (Random) Periodic Message Source from gr-foo is useful for simulations. However, due to a bug in GR 3.7, flowgraphs using it won't stop automatically. I'm aware that this has already been fixed by this PR: https://github.com/gnuradio/gnuradio/pull/797 . However, I would like to be able to use a vanilla GR 3.7 and the fix was applied to the next branch due to API change. Are there any known workarounds not requiring patching?

No, you'll have to use `next` or wait some more time until next is merged in master. Marcus is working on thatn (see PR https://github.com/gnuradio/gnuradio/pull/1809)

Best,
Bastian