discuss-gnuradio
[Top][All Lists]
Advanced

[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

Attachment: smime.p7s
Description: S/MIME cryptographic signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]