[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] A few questions regarding gr-ieeee802-11
From: |
CEL |
Subject: |
Re: [Discuss-gnuradio] A few questions regarding gr-ieeee802-11 |
Date: |
Fri, 8 Jun 2018 12:08:46 +0000 |
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 <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
> >
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
smime.p7s
Description: S/MIME cryptographic signature