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 <m...@bastibl.net> 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/gn >> uradio/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 > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
