Hi Tal, 3.7 is the maint-3.7 branch, master works towards 3.8, and a milestone of that will be when next is merged into it. You can expect a 3.8 release when next is merged, and all the serious kinks that came with it are contained enough for us to risk a release :)
Best regards, Marcus On Fri, 2018-06-08 at 14:03 +0200, Tal Peer wrote: > 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/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 > > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
